Bug#1006640: Additional own rules are ignored
Package: sa-compile Version: 3.4.6-1 Severity: normal Hello, please refer to this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006439 because there is no answer so far that helps to solve the problem. How can be checked that the compiled rules are used by spamd instead of the *.cf files? How it is possible to check which rules are compiled using re2c (https://re2c.org) ? How own rules can be added that they are not overwritten by an package update ? Please help to understand how the construct of spamassassin is working. Best regards karsten -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#1006132: ifrench-gut: please stop build-depending on myspell-tools
El dom, 27 feb 2022 a las 22:32, Agustin Martin () escribió: > > Control: tags -1 +patch > > El vie, 25 feb 2022 a las 8:51, Lionel Élie Mamane > () escribió: > > > > On Fri, Feb 25, 2022 at 12:51:32AM +0100, Agustin Martin wrote: > > > El jue, 24 feb 2022 a las 16:09, Lionel Élie Mamane > > > () escribió: > > > > > I have been looking at popcons and seems that regarding ispell dicts > > > ifrench-gut is way more popular than ifrench, but on the hunspell side > > > the winner is hunspell-fr (which pulls hunspell-fr-classical) > > > > > I do not know about the merits of the different ispell dicts, but > > > keeping ifrench-gut ispell dict seems reasonable. On the other hand, > > > unless it provides something better, dropping myspell-fr-gut as a real > > > dict seems also reasonable, but this really requires more feedback > > > from french users. > > > > If the -gut variant has a "better" word list, then I expect it is > > better for both ispell and myspell? > > Hi, Lionel, > > myspell is gone, only hunspell is available and supports old myspell > dictionaries like this one. Usually hunspell specific dicts are > better than old myspell and ispell dicts, but sometimes they are just > different and each one has its merits. Note that hunspell-fr-*dicts > come from different source (https://grammalecte.net/home.php?prj=fr) > than both ispell french dicts. > > If you think is useful to keep a myspell/hunspell version of gutenberg > dict I am attaching a patch with a possible migration to > ispellaff2myspell. In my limited tests it works better than old dict > since it includes ' and - as wordchars. Whether to remove it or not in > favour of hunspell-fr-* is something that can be decided later by > french dicts maintainers (and will require some coordination). I have > also noticed that while package contains a couple of patches with > dpatch extension it does nor really use dpatch, so that would not be a > problem, The mismatch in ispell hash format should be fixed by the new > build (although I suggest to migrate to ispell-autobuildhash), so this > patch should be enough if no side effects are found, Hi, Lionel Forgot to mention, but if you agree with the changes but are too busy to prepare an upload I can prepare a NMU. Regards, -- Agustin
Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools
On Tue, Mar 01, 2022 at 09:48:04AM +0100, Agustin Martin wrote: > Forgot to mention, but if you agree with the changes but are too > busy to prepare an upload I can prepare a NMU. By all means, please do. Thanks.
Bug#1006604: debian-edu-config: Debian Edu clients without GOsa system entry loose IP address after 30min
[Holger Levsen] > I wonder if this is a bug in Debian Edu at all: don't we require hosts to be > added to GOsa in the first place? Well, it is a bug in Debian Edu that the problem is obscure and hard to debug. I guess the issue should be detected and reported in the face of the person trying to set up a new machine, instead of the machine silently failing to keep its IP address Traditionally it was required to register clients in GOsa to ensure home directories could be mounted, not for it to get an IP address. -- Happy hacking Petter Reinholdtsen
Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1
On 2022-02-28 at 15:31:58 -0500, nick black wrote: > agreed, so long as it's not required by most outputs (i.e. you > can run pypandoc without it and it works). Latex is only used for pdf output, and even there it's just the default option, but there is support for other engines as well. If that wasn't the case, I agree that it should be a dependency, but it should be a dependency of pandoc rather than pypandoc. The issue here is that the tests of pypandoc do try to generate a pdf (as it is a pretty common usecase), and thus they do need latex installed, but that's only a requirement for the tests. > alrightie. this was my NM application bug; i guess i will find > another one. have a good day! I'm even more sorry about having wasted your time then :( -- Elena ``of Valhalla'' signature.asc Description: PGP signature
Bug#1006643: RFA: ifrench-gut -- French dictionary for ispell (GUTenberg version)
Package: wnpp Severity: normal X-Debbugs-Cc: agmar...@debian.org Control: affects -1 src:ifrench-gut Having dropped away from active participation in Debian, I request an adopter for the ifrench-gut package. The package description is: This is a French dictionary, to be used with the ispell program, version 3.1.20 and following. . This is the GUTenberg version. -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#1006644: RFA: dvidvi -- Manipulate .dvi files
Package: wnpp Severity: normal Control: affects -1 src:dvidvi Having dropped off from active participation in Debian, I request an adopter for the dvidvi package. The package description is: Allows you to select, change the order, and/or shift the pages in a .dvi file. . This can for example be used to print an A5 booklet on A4 paper, in such a way that you can put a staple through the bundle. A shell script that does just that is provided. -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Le lun. 28 févr. 2022 à 06:37, a écrit : > Dear Olivier, > > sorry for the delay with my message and thanks for your input. > > olivier sallou писал 2022-02-25 12:12: > > ok, > > after a quick look, issue is Logol is compiled against swi-prolog, and > > there is an ABI issue I think, getting error: > > > > incompatible version (file: 67, Prolog: 68)] > > > > Recompiling logol in sid against swi-prolog 8.4.2+dfsg-2 results in > > correct execution/tests. > > > > So, 2 things: > > > > * As swi-prolog is only a debian update (-1 to -2), I wonder why we > > have this break now > > * Possible fix is to rebuild logol package against this version in > > sid, with a dep requirement on swi-prolog>=8.4.2+dfsg-2. But I don't > > know how this should be managed (logol in testing will still prevent > > swi-prolog to go, and logol in sid won't either go to testing because > > will need swi-prolog version from sid...) > > It is not just Debian update. I've uploaded new upstream version of > SWI-Prolog on Feb 15 (upgrade from 8.2.4 to 8.4.2). It is a new major > update of stable branch of SWI-Prolog, and it breaks compatibility. As > I can see logol tests failed already with 8.4.2+dfsg-1. There was an > issue with ODBC support for SWI-Prolog on 32-bit platforms, so I > uploaded > 8.4.2+dfsg-2 fixing this issue. > > I think swi-prolog and (updated) logol may migrate simultaneously as it > is the case for swi-prolog and eye (another package depending on > swi-prolog). Otherwise, we could ask someone from Debian Release team to > trigger the migration for the involved packages. > ok, I uploaded logol 1.7.9+dfsg-2 built against swi-prolog 8.4.2 and closing the issue with upload. Let's see what happens for migration. Olivier > > Cheers! > Lev > > > Le jeu. 24 févr. 2022 à 19:36, Paul Gevers a > > écrit : > > > >> Source: swi-prolog, logol > >> Control: found -1 swi-prolog/8.4.2+dfsg-2 > >> Control: found -1 logol/1.7.9+dfsg-1 > >> Severity: serious > >> Tags: sid bookworm > >> X-Debbugs-CC: debian...@lists.debian.org > >> User: debian...@lists.debian.org > >> Usertags: breaks needs-update > >> > >> Dear maintainer(s), > >> > >> With a recent upload of swi-prolog the autopkgtest of logol fails in > >> > >> testing when that autopkgtest is run with the binary packages of > >> swi-prolog from unstable. It passes when run with only packages from > >> > >> testing. In tabular form: > >> > >> passfail > >> swi-prolog from testing8.4.2+dfsg-2 > >> logol from testing1.7.9+dfsg-1 > >> all others from testingfrom testing > >> > >> I copied some of the output at the bottom of this report. > >> > >> Currently this regression is blocking the migration of swi-prolog to > >> > >> testing [1]. Due to the nature of this issue, I filed this bug > >> report > >> against both packages. Can you please investigate the situation and > >> reassign the bug to the right package? > >> > >> More information about this bug and the reason for filing it can be > >> found on > >> > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > >> > >> Paul > >> > >> [1] https://qa.debian.org/excuses.php?package=swi-prolog > >> > >> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/19529867/log.gz > >> > >> calling logol with parameters -g 1799.logol -s 1799.fasta -dna > >> log4j:ERROR setFile(null,true) call failed. > >> java.io.FileNotFoundException: /var/log/logol/logol.log (Permission > >> denied) > >> at java.base/java.io [1].FileOutputStream.open0(Native > >> Method) > >> at java.base/java.io > >> [1].FileOutputStream.open(FileOutputStream.java:298) > >> at java.base/java.io > >> [1].FileOutputStream.(FileOutputStream.java:237) > >> at java.base/java.io > >> [1].FileOutputStream.(FileOutputStream.java:158) > >> at > >> org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > >> at > >> org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > >> at > >> > > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > >> at > >> > > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > >> at > >> > > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > >> at > >> > > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > >> at > >> > > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > >> at > >> > > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > >> at > >> > > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > >> at > >> > > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > >> at > >> > > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > >> at org.apache.log4j.LogManager.(LogManager.java:127) > >> at
Bug#1006641: linux-image: Kernel reports IPMI error, repeated VERY often
Package: src:linux Version: 5.16.7-2 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading to kernel 5.16.7-2 * What exactly did you do (or not do) that was effective (or ineffective)? apt -u dist-upgrade * What was the outcome of this action? Kernel reports IPMI error in journalctl, message repeated very often and floods the log file * What outcome did you expect instead? No error message from kernel in the current Debian/testing, my system (A HP ProLiant ML110 G6) reports this error in jounalctl: mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. mars 01 10:10:02 g6.lan.dac kernel: ipmi_si IPI0001:00: IPMI message handler: IPMI message received with no owner. This could be because of a malformed message, or because of a hardware error. Contact your hardware vendor for assistance. The message is repeated VERY often and floods the log file! I would be very gladful for a fix. Thank you in advance. Sincerely, Adrian Kiess -- Package-specific info: ** Version: Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220130) #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) ** Command line: BOOT_IMAGE=/vmlinuz-5.16.0-1-amd64 root=UUID=96d5fdb9-5d4e-46f2-89e3-34fcfc7bfe14 ro resume=UUID=7c16d6e7-d89d-4155-9381-7d25ed882953 ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: HP product_name: ProLiant ML110 G6 product_version: chassis_vendor: HP chassis_version: N/A bios_vendor: HP bios_version: O27 board_vendor: Wistron Corporation board_name: ProLiant ML110 G6 board_version: ** Loaded modules: qrtr mptcp_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag dm_mod vhost_net vhost vhost_iotlb tap tun snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_seq nfnetlink cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_ondemand bridge stp llc uinput binfmt_misc quota_v2 quota_tree intel_powerclamp kvm_intel kvm irqbypass intel_cstate intel_uncore pcspkr joydev amdgpu snd_hda_codec_hdmi snd_usb_audio snd_usbmidi_lib snd_hda_intel snd_rawmidi evdev snd_intel_dspcfg snd_seq_device mc snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm_oss iTCO_wdt intel_pmc_bxt iTCO_vendor_support snd_mixer_oss sg watchdog snd_pcm snd_timer snd gpu_sched soundcore ipmi_ssif button acpi_cpufreq coretemp ipmi_watchdog squashfs loop acpi_ipmi ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler msr i2c_dev parport_pc ppdev nfsd lp parport nfs_acl fuse lockd auth_rpcgss grace configfs sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic btrfs xor raid6_pq zstd_compress libcrc32c uhci_hcd hid_generic usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic sr_mod cdrom crct10dif_common radeon i2c_algo_bit ahci drm_ttm_helper libahci tg3 xhci_pci ttm libata xhci_hcd libphy ehci_pci drm_kms_helper ehci_hcd scsi_mod usbcore cec rc_core drm ptp i2c_i801 crc32c_intel i2c_smbus
Bug#1006642: osk-sdl: autopkgtest failure (with gcc-12)
Source: osk-sdl Version: 0.66-4 Severity: serious Justification: makes the package in question unusable or mostly so Dear Maintainer, The autopkgtest for you package fail (with gcc-12): autopkgtest [05:11:09]: test test-functional: [--- ** Testing key script with 'physical' key input INFO: osk-sdl v0.66 ERROR: Syntax error on line 4 ERROR: Could not parse config file: ./osk.conf ERROR: No valid config file specified, use -c [path] ERROR: Unexpected result! got: expected: postmarketOS ** Testing osk toggle button and 'mouse' key input INFO: osk-sdl v0.66 ERROR: Syntax error on line 4 ERROR: Could not parse config file: ./osk.conf ERROR: No valid config file specified, use -c [path] ERROR: Unexpected result! got: expected: qwerty autopkgtest [05:11:25]: test test-functional: ---] autopkgtest [05:11:25]: test test-functional: - - - - - - - - - - results - - - - - - - - - - test-functional FAIL non-zero exit status 2 autopkgtest [05:11:25]: summary test-machine-functional SKIP Test requires machine-level isolation but testbed does not provide that test-functional FAIL non-zero exit status 2 https://ci.debian.net/data/autopkgtest/testing/amd64/o/osk-sdl/19643682/log.gz
Bug#1006604: debian-edu-config: Debian Edu clients without GOsa system entry loose IP address after 30min
[ Petter Reinholdtsen, 2022-03-01 ] > > [Holger Levsen] > > I wonder if this is a bug in Debian Edu at all: don't we require hosts to be > > added to GOsa in the first place? > > Well, it is a bug in Debian Edu that the problem is obscure and hard to > debug. I guess the issue should be detected and reported in the face of > the person trying to set up a new machine, instead of the machine > silently failing to keep its IP address Sure. But then this seems to be a site specific non-standard use case, so site specific modification could be sufficient, I figure. Fixing it for bookworm would be good, though. > Traditionally it was required to register clients in GOsa to ensure > home directories could be mounted, not for it to get an IP address. Yes, that's still the case. I'm just wondering about the reported 30 minutes. It seems to be the default lease time on the backbone network (1800). Maybe raise it to a site specific value? (Can't test it, can't contribute more for the time being.) Wolfgang signature.asc Description: PGP signature
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Package: libeclipse-jdt-core-java Version: 3.27.0+eclipse4.21-1 Severity: normal Dear Maintainer, The 3.27.0+eclipse4.21-1 version of the package has switched to using the 4.21 version of the upstream package (libeclipse-jdt-core-java). This is problematic for us and potentially others who are still forced to use JDK 8, since this version has a strict Java 11 requirement. (This is also listed in the changelog entry for the package.) More so, this package is used as-is in Ubuntu (including the upcoming Ubuntu 22.04 release), which means that the decision to bump the libeclipse-jdt-core-java to a version which only works on Java 11 and greater has significant ramifications to the ecosystem at large. The 4.21 version is not _required_ by Tomcat 9.0.58. It works fine on 4.20 (and perhaps older versions as well, as we also indicate by the libeclipse-jdt-core-java (>= 3.18.0) dependency line for the libtomcat9-java package. I see some ways this could be handled by the Debian project: * Live with it. People who still are using JDK 8 are on their own anyway (Oracle does not support it). Unfortunately, this will cause problems for a number of people, who will be forced to find other ways than using the vendor-provided Tomcat package if their software cannot run on Java 11. * Downgrade the version in Debian to 4.20. This should make our Tomcat work on JDK 8 and 11 alike, and be the "most compatible" approach in this case. I think this would be preferable if possible. I don't know, but I wonder if providing a 4.21-based package in Debian in this case could be an unintentional mistake? I just downloaded the Tomcat 9.0.58 tarball from https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.58/, and it contains the lib/ecj-4.20.jar file, i.e. containing Eclipse JDT version 4.20. I would _guess_ that this is specifically done to avoid enforcing a Java 11 dependency on all Tomcat users. Tomcat 9 (and 10.0) still supports Java 8 in their upstream versions. I'm not in charge of this decision in any way, but I think it does make sense if Debian would consider doing the same. Especially given that Debian is a project which takes backwards compatibility very seriously and works hard to avoid unnecessary breakage for our end users. (In this case, some of "our end users" are using Ubuntu. :) Best regards, Per -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/16 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=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1006648: transition: numerical stack: slepc petsc hypre scotch scalapack
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition We've got a pile-up of numerical libraries waiting in experimental. I'd like to clear them out into unstable. This will also let scalapack rebuild against mpich 4. The transitions are: scalapack 2.1 → 2.2 scotch 6.1 → 7.0 hypre 2.22 → 2.23 petsc 3.15 → 3.16 slepc 3.15 → 3.16 hypre is now built with proper versioned library package names, so it won't cause the same transition jam with petsc that it made last time. auto-transitions are already generated: https://release.debian.org/transitions/html/auto-scalapack.html https://release.debian.org/transitions/html/auto-scotch.html https://release.debian.org/transitions/html/auto-hypre.html https://release.debian.org/transitions/html/auto-petsc.html https://release.debian.org/transitions/html/auto-slepc.html We're waiting for mpich 4 to migrate to testing. Probably best for that to complete before starting this transition (not sure why bagel is failing amd64 tests, perhaps it needs to rebuild against mpich 4). Ben file: title = "petsc"; is_affected = .depends ~ "libpetsc-real3.15" | .depends ~ "libpetsc-real3.16"; is_good = .depends ~ "libpetsc-real3.16"; is_bad = .depends ~ "libpetsc-real3.15";
Bug#1006352: bsfiltger: "Cannot load such file -- sdbm (LoadError)"
On Thu, Feb 24, 2022 at 10:51:16AM +0900, YABUKI Yukiharu wrote: > Package: bsfilter > Version: 1:1.0.19-2.1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Due to ruby transition, ruby could not load sdbm module. > > I use bsfilter which classifies spam mail. > > ``` > $ bsfilter > :85:in > `require': cannot load such file -- sdbm (LoadError) > Did you mean? dbm > from > :85:in > `require' > from /usr/bin/bsfilter:3106:in `get_options' > from /usr/bin/bsfilter:3262:in `setup' > from /usr/bin/bsfilter:3413:in `' > ``` Yes, `sdbm` has been removed from the standard library. Thanks for the bug report, since bsfilter has no automated tests (otherwise we would have caught this earlier). I just uploaded a standalone ruby-sdbm package to NEW now, and will upload a bsfilter update with the right dependency as soon as that's in the archive. signature.asc Description: PGP signature
Bug#1006632: Please upgrade to 22.1.0 (1st stable release!)
Nicholas D Steeves wrote: > I would prefer if someone else would update and upload, because I'm > not sure to what degree the changes affect the rdeps, and I don't want > to carelessly make trouble for others. Well, pretty much all of the previous uploads of Black to Debian could have caused regressions, at least in the sense that reformatted Python code changed ever so slightly between each version. :) In other words, an upload of 22.1.0 will not be much worse than the past and, as you outline, should limit (if not avoid) future issues. I'll be happy to upload this once Salsa returns. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1003659: bullseye-pu: package python-django/2:2.2.26-1~deb11u1
Hi Adam, >> > > * Fix a traceback around the handling of >> > > RequestSite/get_current_site() due >> > > to a circular import by backporting commit 78163d1a from >> > > upstream. Thanks >> > > to Raphaël Hertzog for the report. (Closes: #1003478) >> > >> > That change doesn't look like it made it to unstable yet; is that >> > correct? >> >> I'm sorry, I had assumed it would have been incorporated into the >> latest upstream releases that I uploaded around the same time. Now >> that I look, it is not in the cutting-edge version in experimental >> either. >> > > No worries. I have to admit that I was surprised that it hadn't made it > into a release upstream yet either. > >> (I assume you would want to see it there before accepting this pu, >> right?) > > Yes, please. In general, any issues that are being resolved in (o)pu > shouldn't affect unstable, either because they're not relevant there or > because a fix was already applied. This change is now in unstable and testing (2:3.2.12-2). :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1006633: procmail is unmaintained upstream
severity 1006633 important retitle 1006633 procmail is unmaintained upstream Hi. I could understand that we want to get rid of unmaintained software, but please do not inflate severities, at least while the discussion takes place and a consensus that the package should be removed has not been reached. This package is optional, and we are not forcing anybody to use it. If we had kept the extra priority, I would be glad to put it in "extra", but extra does not exist anymore. There are some things which need a clarification because they are not 100% accurate. El 1/3/22 a las 3:11, Antoine Beaupre escribió: # unmaintained procmail is unmaintained. the "Final release", according to Wikipedia[1], dates back to September 10, 2001 (3.22). this is the release that is shipped with Debian, although we do have *26* debian-specific uploads on top of that (3.22-26, in all suites since buster). The Debian package is actually based on version "3.23pre" since version 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I think it's important to state the facts right. While it's true that procmail has not been maintained upstream for a long time, Debian is absolutely in his right to maintain its own version without an upstream, that's one of the properties of free software. the last maintainer of procmail explicitly advised us (in #769938) and other projects (e.g. OpenBSD, in [2]) to stop shipping it. Same as before, Debian is in his right to follow this advice or not. That Debian bug report is still open, and concerns a NULL pointer dereference. I've just make an upload to fix such bug. Debian security people: Is there a CVE for Bug #769938? Maybe this should backported for stable as well. I do not know if it is exploitable. Strangely, the original procmail author (Stephen R. van den Berg, presumably) wrote in that bug report *last year* saying that was "Fixed in upcoming 3.23 release", which has been targeted for release for all of those last 20 years. I guess he did not refer to the version which was "upcoming 20 years ago", but to the git version on which he was working in the last years. In either case, I'm Cc:ing Stephen, who some time ago was preparing a release which included all the Debian fixes so far. Stephen: If you intend to release a new procmail version, please do so. Thanks.
Bug#1006621: ITP: boofcv -- Real-time computer vision library
This is probably a dumb question since I don't know anything about java build systems, but I'll ask it anyway. Most build systems think about: - Which commands are needed to build stuff - Which commands are needed to rebuild stuff (if some artifacts are built already or if we're not building everything) - Obtaining and/or verifying dependencies When building a package for Debian, we only care about the first one of these. debian/control defines the Build-Depends, so once the build system runs, the dependencies are all in place (and if they aren't, we need to fix debian/control, which is not the build system's responsibility). And the build happens just once, so we always start at zero, and we don't need to care about rebuilds. Given this, would it be reasonable to distro-patch all the gradle stuff away, and to co-maintain a parallel (and really simple) build that is mostly a glorified script or better yet, a GNU Makefile, or something? If everything that gradle does boils down to a bunch of "javac" invocations and some "cp" commands to install stuff, then this could be a viable approach. Since this would be a separate, independent build system, this only makes sense if it's REALLY simple, and I don't know enough about gradle or boofcv to answer that. If this doesn't sound too crazy for this project, and if somebody can tell me how to get the "javac" commands, I can put something together. Peter: if I do the build as described in the instructions, using the "gradlew" commands, and I grep the log for "javac", would that give me the bulk of the commands that are needed? What else is needed other than the "javac" commands?
Bug#1006660: init script uses wrong config
Package: pyspf-milter Version: 2.9.2-1 Hello, pyspf-milter comes with config file /etc/pyspf-milter/pyspf-milter.conf but init script uses $sysconfdir/$NAME.conf which resolves to /etc/pyspf-milter.conf: pyspf-m+ 7197 0.0 0.1 126124 19400 ?Sl 19:58 0:00 /usr/bin/python3 /usr/bin//pyspf-milter /etc/pyspf-milter.conf as a result, defaults are used instead of config file. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK]
Bug#1006656: Intel NUC 11: kodi doesn't show
See attachments. Regards Harri glxinfo.txt.gz Description: GNU Zip compressed data libva info: VA-API version 1.14.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: va_openDriver() returns -1 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_8 libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit
Bug#933870: qbittorrent: Qbittorrent 4.1.6 Debian Testing updated 8/4/19 Fails upon start and immediately exits
The stack trace above is very similar to the one in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926062. The Qt version (which is under suspicion in #926062) is the same (5.11.3) Even the symptom (segmentation fault upon start) is similar. This bug might be a duplicate of #926062. Regards BZ
Bug#1006656: Intel NUC 11: kodi doesn't show
See attachments. Regards Harri glxinfo.txt.gz Description: GNU Zip compressed data libva info: VA-API version 1.14.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: va_openDriver() returns -1 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_8 libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit
Bug#1006615: python3-pybind11: Handle Python 3.10's default sysconfig paths
Hi Debian (2022.02.28_13:58:36_-0400) > Attached are a pair of patches to address the issue. I've forwarded them > upstream in https://github.com/pybind/pybind11/pull/3764 And it has been merged, upstream. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1006664: python3-fonttools has unmet dependencies
Package: python3-fonttools Version: 4.29.1-2 Severity: serious Installing python3-fonttools is currently not possible: # apt install python3-fonttools Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python3-fonttools : Depends: python3-unicodedata2 (>= 14.0.0) but it is not installable or python3-all (>= 3.11.0) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.15-0+deb11u1
On Sun, 2022-02-20 at 00:03 -0800, Otto Kekäläinen wrote: > Control: retitle -1 buster-pu: package mariadb-10.5 10.5.15-0+deb11u1 > > According to https://release.debian.org/ the next stable update is > due > in February. Please include this update to MariaDB. > That was the plan, yes. As you probably noticed, we're a little behind schedule > mariadb-10.5 (1:10.5.15-0+deb11u1) bullseye; urgency=medium > > [ Otto Kekäläinen ] > * New upstream version 10.5.15. Includes security fixes for > Please go ahead. Regards, Adam
Bug#1000341: buster-pu: package mariadb-10.3 10.3.34-0+deb10u1
Control: tags -1 + confirmed On Sun, 2022-02-20 at 00:03 -0800, Otto Kekäläinen wrote: > mariadb-10.3 (1:10.3.34-0+deb10u1) buster; urgency=medium > > * New upstream version 10.3.34. Includes security fixes for: > - CVE-2021-46661 > - CVE-2021-46663 > - CVE-2021-46664 > - CVE-2021-46665 > - CVE-2021-46668 > * Previous upstream version 10.3.33 included security fixes for: > - CVE-2021-46659 > - CVE-2022-24048 > - CVE-2022-24050 > - CVE-2022-24051 > - CVE-2022-24052 > * Previous upstream version 10.3.32 included security fixes for: > - CVE-2021-35604 > - CVE-2021-46662 > - CVE-2021-46667 > Please go ahead. Regards, Adam
Bug#1006666: emacsql-sqlite3: FTBFS with SQLite3 3.38.0+
Source: emacsql-sqlite3 Version: 1.0.2-1 Severity: serious Tags: bookworm sid ftbfs patch Hi, Your package fails to build with SQLite 3.38.0; the reason is simple. The output for creating an already existing table changed from 'Error:' to 'Parse error'. The attached patch updates the source accordingly. Regards, Laszlo/GCS Description: fix build with SQLite3 3.38.0+ It changed the error message for creating an already existing table. Forwarded: no Author: Laszlo Boszormenyi (GCS) Last-Update: 2022-03-01 --- --- emacsql-sqlite3-1.0.2.orig/emacsql-sqlite3.el +++ emacsql-sqlite3-1.0.2/emacsql-sqlite3.el @@ -214,7 +214,7 @@ each arg will be quoted first." (cl-defmethod emacsql-parse ((conn emacsql-sqlite3-connection)) (with-current-buffer (emacsql-buffer conn) (goto-char (point-min)) -(if (looking-at (rx "Error: " (group (1+ any)) eol)) +(if (looking-at (rx "Parse error " (group (1+ any)) eol)) (signal 'emacsql-error (list (match-string 1))) (cl-macrolet ((sexps-in-line! () `(cl-loop until (looking-at "\n")
Bug#1006668: u-boot-menu: Support for custom initrd configuration
Package: u-boot-menu
Version: 4.0.3
Severity: normal
Tags: patch
X-Debbugs-Cc: undef
Dear Maintainer,
Currently the initrd section of the generated extlinux.conf will only use
discovered
initrd.img-* files from /boot. However, some systems (discovered on the
PinePhone Pro,
but other reclaimed Android devices are affected) require a custom "miniramfs"
to be used.
Would it be possible to include the ability to manually set the initrd record in
/etc/default/u-boot? The attached patch allows a static configuration which
will be used
for all kernels. An alternative would be setting "/miniramfs-${_VERSION}".
Thanks for considering,
Undef.
-- System Information:
Debian Release: 11.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.11-1.fc32.qubes.x86_64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages u-boot-menu depends on:
ii linux-base 4.6
u-boot-menu recommends no packages.
Versions of packages u-boot-menu suggests:
pn flash-kernel
-- no debconf information
*** 0001-Allow-configuration-of-initrd-file.patch
>From 14daba63b9c1036b7672f144d29a848e306992b0 Mon Sep 17 00:00:00 2001
From: Undef
Date: Wed, 2 Mar 2022 00:02:12 +
Subject: [PATCH] Allow configuration of initrd file
Some devices have initrd requirements that cause the standard
initrd.img-${_VERSION} to fail to boot. For example, the PinePhone Pro
will fail to boot with large initrd files, solved by using a
miniramfs[0] to chainload the real initrd.
This allows specifying the INITRD manually in /etc/default/u-boot. If
the configuration is either not present or empty, the existing initrd
discovery functionality will continue to be used.
[0] https://gitlab.com/mobian1/miniramfs
---
u-boot-update | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/u-boot-update b/u-boot-update
index da92918..4d3b395 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -92,6 +92,7 @@ U_BOOT_TIMEOUT="${U_BOOT_TIMEOUT:-50}"
U_BOOT_MENU_LABEL="${U_BOOT_MENU_LABEL:-${PRETTY_NAME:-Debian GNU/Linux
kernel}}"
U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
U_BOOT_FDT_DIR="${U_BOOT_FDT_DIR:-/usr/lib/linux-image-}"
+U_BOOT_INITRD="${U_BOOT_INITRD:-}"
# Find parameter for root from fstab
if [ -z "${U_BOOT_ROOT}" ]
@@ -169,7 +170,10 @@ do
_NUMBER="${_NUMBER:-0}"
_ENTRY="${_ENTRY:-1}"
- if [ -e /boot/initrd.img-${_VERSION} ]
+ if [ -n "${U_BOOT_INITRD}" ]
+ then
+ _INITRD="initrd ${U_BOOT_INITRD}"
+ elif [ -e /boot/initrd.img-${_VERSION} ]
then
_INITRD="initrd ${_BOOT_DIRECTORY}/initrd.img-${_VERSION}"
else
--
2.30.2
Bug#1006662: nx-x11-common: x2go font path not set correctly
Package: nx-x11-common Version: 2:3.5.99.26-2 After setting up a new remote x2go instance (using Devuan, it's a Debian package though), the font path was set to /usr/share/fonts/X11/Type1,/usr/share/fonts/X11/75dpi,/usr/share/fonts/X11/100dpi,built-ins which was missing (xterm complained) /usr/share/fonts/X11/misc. Comparing with the old (Ubuntu) instance, it showed that a symlink from /usr/share/nx/fonts to /usr/share/fonts/X11 was missing. dpkg -L nx-x11-common /. /usr /usr/share /usr/share/doc /usr/share/doc/nx-x11-common /usr/share/doc/nx-x11-common/changelog.Debian.gz /usr/share/doc/nx-x11-common/changelog.gz /usr/share/doc/nx-x11-common/copyright /usr/share/nx /usr/share/nx/SecurityPolicy /usr/share/nx/X11 /usr/share/nx/X11/XErrorDB /usr/share/nx/X11/Xcms.txt According to upstream, it should be there. https://github.com/ArcticaProject/nx-libs/issues/1039#issuecomment-1055296928 Packaging issue, or what am I missing here? Hanno
Bug#1006477: Problem does not happen in kernel 5.16.11
I read at [1] (see at bottom) that there was a problem with xhci in kernel 5.10 (which was fixed in a later kernel than 5.10) which could cause these USB cards to not work. So, I compiled the latest vanilla kernel (5.16.11) from kernel.org and booted up Bullseye with it. The boot did not succeed 100% (some other things broke, such as lightdm), but it did bring up the networking correctly and gave me access to a shell. I was able to verify that the ethernet port on the USB card worked fine. Also, the "xhci_hcd :1c:00.0: WARNING: Host System Error" log was not present and neither were the ax88179_178a kernel failure logs. So, it looks like whatever kernel software changes fixed the xhci also address the ethernet port issue (or perhaps the entire card in general because now I realize even the USB ports on it were not working in kernel 5.10). However, I have no idea what the kernel software changes that fixed this are, and I have less of a clue as to how to figure that out. [1] = https://community.ipfire.org/t/update-158-to-161-problems-with-usb-ethernet-adpater/6854/5
Bug#1006477: Problem does not happen in kernel 5.16.11
On Tuesday, 1 March 2022 21:38:03 CET Flacusbigotis wrote: > I read at [1] (see at bottom) that there was a problem with xhci in > kernel 5.10 (which was fixed in a later kernel than 5.10) which could > cause these USB cards to not work. So, I compiled the latest vanilla > kernel (5.16.11) from kernel.org and booted up Bullseye with it. > > The boot did not succeed 100% (some other things broke, such as lightdm), IIUC that pertains to commit 09f736aa95476631227d2dc0e6b9aeee1ad7ed58 from Linus' tree and that was included in 5.16-rc4. In commit fa75f593c867cde772e2d87ca36ab735c4aa4a09 it was included in the 5.15 branch and part of 5.15.7 release and there is a stable backport kernel version 5.15.15-2~bpo11+1 which should be safe to install on a Debian Stable system and with that you can check whether f.e. lightdm works properly. (The default config of upstream kernel is not the same as Debian uses, which could cause the issues you still saw.) But I just found in 90c915051c3df2d6d98d506323ab805bc1da7ae3 that it was also applied to the 5.10 branch and included in the 5.10.84 release. Your initial report mentioned a 5.10.92-1 kernel so that should already have it?!? I don't know all that is needed to get it fixed as it appears that this commit alone isn't enough. I hope it's still useful info which could bring the full solution closer. signature.asc Description: This is a digitally signed message part.
Bug#1006661: exim4-base: Syntax Error in exiqgrep
Package: exim4-base
Version: 4.95-4
Severity: normal
Dear Maintainer,
When running /usr/sbin/exiqgrep, a Syntax Error is reported, and the
program quits:
$ /usr/sbin/exiqgrep
syntax error at /usr/sbin/exiqgrep line 56, near ") {"
syntax error at /usr/sbin/exiqgrep line 56, near ";}"
syntax error at /usr/sbin/exiqgrep line 57, near ";}"
syntax error at /usr/sbin/exiqgrep line 58, near ";}"
Execution of /usr/sbin/exiqgrep aborted due to compilation errors.
Looking at the code, the problem appears to be that line 56 is of the
form:
if (!getops(...) { ...}
The unbalanced parentheses are the problem. Adding a second closing
bracket after the getopts call fixes the issue.
-- Package-specific info:
Exim version 4.95 #2 built 19-Feb-2022 13:49:28
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2020
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS TLS_resume
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP
PIPE_CONNECT PRDR PROXY Experimental_Queue_Ramp SOCKS SPF SRS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot external plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (550, 'testing'), (500, 'stable-updates'), (450, 'unstable'),
(450, 'stable'), (445, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages exim4-base depends on:
ii adduser3.118
ii cron [cron-daemon] 3.0pl1-137
ii debconf [debconf-2.0] 1.5.79
ii exim4-config [exim4-config-2] 4.95-4
ii libc6 2.33-7
ii libdb5.3 5.3.28+dfsg1-0.8
ii lsb-base 11.1.0
ii netbase6.3
ii systemd-sysv 250.3-2
Versions of packages exim4-base recommends:
ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2
ii psmisc 23.4-2
Versions of packages exim4-base suggests:
ii bsd-mailx [mail-reader] 8.1.2-0.20180807cvs-2
pn exim4-doc-html | exim4-doc-info
pn eximon4
ii file 1:5.41-2
ii gnutls-bin 3.7.3-4+b1
ii mutt [mail-reader] 2.1.4-1
ii openssl 1.1.1m-1
ii spf-tools-perl 2.9.0-5
ii swaks20201014.0-2
ii thunderbird [mail-reader]1:91.6.1-1
-- debconf information:
exim4/purge_spool: false
exim4-base/drec:
Bug#1006656: Intel NUC 11: kodi doesn't show
Does it work now? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#996953: perl: make -j72 failing with a text file busy error
Control: tag -1 patch confirmed On Wed, Feb 16, 2022 at 12:57:11PM +0100, gypt...@gyptazy.ch wrote: > I can confirm this issue when rebuilding Perl on powerful systems. Multiple > builds of ‚generate_uudmap.o‘ are > created during the compile time and at some point it fails with: > > make -j88 […] > ./generate_uudmap uudmap.h bitcount.h mg_data.h > 6584make[3]: ./generate_uudmap: Text file busy > 6585make[3]: *** [Makefile:329: bitcount.h] Error 127 > > As a result, I patched the ‚rules‘ file to run ‚dh_auto_build‘ with > ‚--no-parallel‘ option. Thanks. This seems to be a build system corner case that only happens when the Configure run is split in two with -E and -S, which we do for the benefit of cross builds. I think it can be fixed by injecting a 'make depend' call at the end of debian/config.debian, mimicking what Configure does when run "normally" with -e. That would be preferrable to the dh --no-parallel workaround as it would not slow the builds. Could you please try if the attached patch fixes it? -- Niko Tyni nt...@debian.org >From 26b11231d66447ae0ed0d3ba032ae1b0523a26c0 Mon Sep 17 00:00:00 2001 From: Niko Tyni Date: Tue, 1 Mar 2022 21:17:00 +0200 Subject: [PATCH] Fix massively parallel builds by first making depend This is what Configure does at the end when run "normally" with -e. The Makefile dependencies are not quite robust for parallel builds if generate_uudmap is not pre-built (which happens during the 'make depend' phase.) Closes: #996953 --- debian/config.debian | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/config.debian b/debian/config.debian index e27858c07..7afc379e7 100644 --- a/debian/config.debian +++ b/debian/config.debian @@ -242,6 +242,9 @@ fi # now continue with extracting Makefile et al. /bin/bash ./Configure -S $crossargs +# mimic what 'Configure -e' does, unbreaking parallel builds (#996953) +make depend + # append PERL_BUILD_DATE before the last #endif in config.h # massive quoting problems prevent passing this to Configure sed -i "\$i #define PERL_BUILD_DATE \"$PERL_BUILD_DATE\"" config.h -- 2.30.2
Bug#1006667: python-biopython - build-dependencies unsatisfiable on most architectures.
source: python-biopython version: 1.79+dfsg-1 severity: serious tags: patch muscle was recently removed from most architectures[1], leaving python-biopython's build-dependencies unsatisfiable on those architectures. The build-dependency is already marked as nocheck so presumably is only used for tests. I added an architecture restriction to the dependency and was able to perform a successfully test build in an environment without muscle installed. Note that I used python3-fonttools from testing for the test build as unstable's version is currently uninstallable. A debdiff is attached. The recent upload of python-biopython 1.79+dfsg-2 also moved w3-dtd-mathml from Suggests to Depends. Unfortunately w3-dtd-mathml is rc buggy[2] and not in testing. There is a patch available for the rc bug, but discussion in the bug report suggests that it may be better to migrate to w3c-sgml-lib which has a newer version of the mathml dtd. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006161 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994795 diff -Nru python-biopython-1.79+dfsg/debian/changelog python-biopython-1.79+dfsg/debian/changelog --- python-biopython-1.79+dfsg/debian/changelog 2022-02-17 19:15:09.0 + +++ python-biopython-1.79+dfsg/debian/changelog 2022-03-01 20:39:50.0 + @@ -1,3 +1,11 @@ +python-biopython (1.79+dfsg-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Restrict architecture list of muscle build-dependency to reflect +architectures where the current version of muscle is available. + + -- Peter Michael Green Tue, 01 Mar 2022 20:39:50 + + python-biopython (1.79+dfsg-2) unstable; urgency=medium * Move w3-dtd-mathml from Suggests to Depends to avoid dangling symlink diff -Nru python-biopython-1.79+dfsg/debian/control python-biopython-1.79+dfsg/debian/control --- python-biopython-1.79+dfsg/debian/control 2022-02-17 19:15:09.0 + +++ python-biopython-1.79+dfsg/debian/control 2022-03-01 20:39:50.0 + @@ -25,7 +25,7 @@ emboss , fasttree , mafft , - muscle , + muscle [i386 amd64 x32] , ncbi-blast+ , phylip , phyml [any-amd64 any-i386] ,
Bug#1006656: Intel NUC 11: kodi doesn't show
Found it on https://forum.ubuntuusers.de/topic/va-api-meldet-fehler-bei-vainfo/: The intel-media-va-driver package was missing, as it seems. Thanx for your help Harri
Bug#1006663: ITP: python-pyrcb2 -- A powerful asynchronous IRC bot library
Package: wnpp Severity: wishlist Owner: Agathe Porte X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org * Package name: python-pyrcb2 Version : 0.6.2 Upstream Author : taylor.fish * URL : https://github.com/taylordotfish/pyrcb2 * License : LGPLv3+ Programming Lang: Python Description : A powerful asynchronous IRC bot library pyrcb2 is an asyncio-based library for writing IRC bots. It is designed to be easy to use, customizable, and high-level. pyrcb2 includes features such as account tracking, user prefix tracking (voice, op, etc.), messaging delaying to prevent throttling, and long message splitting. pyrcb2 also makes use of asyncio and coroutines in Python. This allows you to write asynchronous code in a linear fashion—you can handle responses to commands right after you send them. === I intent to maintain this package under the umbrella of the Debian Python Team. I need it to properly package an IRC bot designed for the DPT itself.
Bug#995636: transition: openssl
Control: tags -1 - moreinfo Removing moreinfo tag since I provide more information in my previous reply. On 2022-02-28 00:23:22 [+0100], To 995...@bugs.debian.org wrote: > On 2022-02-14 15:01:34 [+0100], To Sebastian Ramacher wrote: > > On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > > > Could you please update this transition request? It's open for four > > > > months and no visible response. > > > > > > Kurt mention some 100 packages failing to build. I only see a handfull > > > of bugs filed. So what's the status on those build failures? > > > > So new logs probably… > > Gathered new logs and finally processed them \o/. The list at > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 > > has been updated accordingly. I added bugs for packages for FTBFS which > existed without new openssl (say due new gcc, old debhelper, …). I was > not able to build a few packages (25) because the build dependency could > not have been satisfied at the time. Sebastian
Bug#1006665: python-propka-doc: provide doc-base registration for docs
Package: python-propka-doc Version: 3.4.0-2 Severity: normal Thanks for packaging propka! Could you provide a doc-base file to register the docs? (handled by dh_installdocs) That makes the docs more convenient to access. I guess the Science/Chemistry section would be the place for it (Science/Biology would be my second choice). Drew
Bug#1006657: bowtie2 breaks optimir autopkgtest: Error with system call: Bowtie2 index creation failed
Source: bowtie2, optimir Control: found -1 bowtie2/2.4.5-1 Control: found -1 optimir/1.1-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of bowtie2 the autopkgtest of optimir fails in testing when that autopkgtest is run with the binary packages of bowtie2 from unstable. It passes when run with only packages from testing. In tabular form: passfail bowtie2from testing2.4.5-1 optimirfrom testing1.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of bowtie2 to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=bowtie2 https://ci.debian.net/data/autopkgtest/testing/amd64/o/optimir/19635699/log.gz No output file specified! Bowtie 2 version 2.4.5 by Ben Langmead (lang...@cs.jhu.edu, www.cs.jhu.edu/~langmea) Usage: bowtie2-build [options]* reference_incomma-separated list of files with ref sequences bt2_index_base write bt2 data to files with this dir/basename *** Bowtie 2 indexes will work with Bowtie v1.2.3 and later. *** Options: -f reference files are Fasta (default) -c reference sequences given on cmd line (as ) --large-index force generated index to be 'large', even if ref has fewer than 4 billion nucleotides --debug use the debug binary; slower, assertions enabled --verbose log the issued command -a/--noauto disable automatic -p/--bmax/--dcv memory-fitting -p/--packed use packed strings internally; slower, less memory --bmax max bucket sz for blockwise suffix-array builder --bmaxdivn max bucket sz as divisor of ref len (default: 4) --dcv diff-cover period for blockwise (default: 1024) --nodc disable diff-cover (algorithm becomes quadratic) -r/--noref don't build .3/.4 index files -3/--justrefjust build .3/.4 index files -o/--offrate SA is sampled every 2^ BWT chars (default: 5) -t/--ftabchars # of chars consumed in initial lookup (default: 10) --threads # of threads --seed seed for random number generator -q/--quiet verbose output (for debugging) --h/--help print this message and quit --version print version information and quit # ## OPTIMIR ## # Starting workflow for sample S1 > Starting Library preparation... Error with system call: Bowtie2 index creation failed: command line = bowtie2-build -f /tmp/autopkgtest-lxc.ej3c3g68/downtmp/autopkgtest_tmp/OptimiR_Results_Dir/OptimiR_lib/fasta/optimiR_library.fa /tmp/autopkgtest-lxc.ej3c3g68/downtmp/autopkgtest_tmp/OptimiR_Results_Dir/OptimiR_lib/bowtie2_index/optimiR_alignment_library -q Check that path to Bowtie2, Cutadapt, Samtools are well defined. autopkgtest [18:11:44]: test run-sample-analysis OpenPGP_signature Description: OpenPGP digital signature
Bug#1006659: python-django-timezone-field breaks python-django-celery-beat autopkgtest: type object 'TimeZoneField' has no attribute 'default_choices'
Source: python-django-timezone-field, python-django-celery-beat Control: found -1 python-django-timezone-field/5.0-1 Control: found -1 python-django-celery-beat/2.2.1-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of python-django-timezone-field the autopkgtest of python-django-celery-beat fails in testing when that autopkgtest is run with the binary packages of python-django-timezone-field from unstable. It passes when run with only packages from testing. In tabular form: passfail python-django-timezone-field from testing5.0-1 python-django-celery-beat from testing2.2.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python-django-timezone-field to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python-django-timezone-field https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-celery-beat/19656491/log.gz = test session starts == platform linux -- Python 3.10.2, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 Django settings: t.proj.settings (from ini file) rootdir: /tmp/autopkgtest-lxc.boenfl9l/downtmp/autopkgtest_tmp, configfile: setup.cfg, testpaths: t/unit/ plugins: case-1.5.3, django-3.5.1, timeout-2.1.0 collected 87 items / 1 error / 3 deselected / 83 selected ERRORS ERROR collecting t/unit/test_models.py t/unit/test_models.py:85: in class CrontabScheduleTestCase(TestCase, TestDuplicatesMixin): t/unit/test_models.py:87: in CrontabScheduleTestCase TimeZoneField.default_choices[0][0].zone E AttributeError: type object 'TimeZoneField' has no attribute 'default_choices' === warnings summary === ../../../../usr/lib/python3/dist-packages/kombu/utils/compat.py:82 /usr/lib/python3/dist-packages/kombu/utils/compat.py:82: DeprecationWarning: SelectableGroups dict interface is deprecated. Use select. for ep in importlib_metadata.entry_points().get(namespace, []) t/unit/test_schedulers.py:155 /tmp/autopkgtest-lxc.boenfl9l/downtmp/autopkgtest_tmp/t/unit/test_schedulers.py:155: PytestUnknownMarkWarning: Unknown pytest.mark.celery - is this a typo? You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/stable/mark.html @pytest.mark.celery(timezone='Europe/Berlin') t/unit/test_schedulers.py:187 /tmp/autopkgtest-lxc.boenfl9l/downtmp/autopkgtest_tmp/t/unit/test_schedulers.py:187: PytestUnknownMarkWarning: Unknown pytest.mark.celery - is this a typo? You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/stable/mark.html @pytest.mark.celery(timezone='Europe/Berlin') t/unit/test_schedulers.py:223 /tmp/autopkgtest-lxc.boenfl9l/downtmp/autopkgtest_tmp/t/unit/test_schedulers.py:223: PytestUnknownMarkWarning: Unknown pytest.mark.celery - is this a typo? You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/stable/mark.html @pytest.mark.celery(timezone='America/New_York') -- Docs: https://docs.pytest.org/en/stable/warnings.html === short test summary info ERROR t/unit/test_models.py - AttributeError: type object 'TimeZoneField' has... Interrupted: 1 error during collection == 3 deselected, 4 warnings, 1 error in 0.55s == autopkgtest [17:17:01]: test upstream OpenPGP_signature Description: OpenPGP digital signature
Bug#1006656: Intel NUC 11: kodi doesn't show
Hi Harald, Can you please run "glxinfo" and "vainfo" as the user you're running Kodi? For me it looks like a permission problem which I posted the solution for on Kodi Wiki: https://kodi.wiki/view/HOW-TO:Install_Kodi_for_Linux#Installing_Kodi_on_Debian_Unstable_or_Testing Please let me know if it works for you! -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#1006658: libobject-pad-perl breaks libtickit-widget-scrollbox-perl autopkgtest: malloc_consolidate(): unaligned fastbin chunk detected
Source: libobject-pad-perl, libtickit-widget-scrollbox-perl Control: found -1 libobject-pad-perl/0.61-1 Control: found -1 libtickit-widget-scrollbox-perl/0.11-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of libobject-pad-perl the autopkgtest of libtickit-widget-scrollbox-perl fails in testing when that autopkgtest is run with the binary packages of libobject-pad-perl from unstable. It passes when run with only packages from testing. In tabular form: passfail libobject-pad-perl from testing0.61-1 libtickit-widget-scrollbox-perl from testing0.11-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of libobject-pad-perl to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libobject-pad-perl https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtickit-widget-scrollbox-perl/19636133/log.gz t/00use.t ... ok 1 - use Tickit::Widget::ScrollBox; 1..1 ok t/01scrollbox-horizontal.t .. ok 1 - defined $widget ok 2 - $widget has refcount 1 initially ok 3 - $widget has refcount 1 after adding child ok 4 - $widget wants 11 lines ok 5 - $widget wants 159 cols ok 6 - $widget has ->hextent ok 7 - $static has window after $widget->set_window ok 8 - $static window starts on line 0 ok 9 - $static window starts on column 0 ok 10 - $static given 24 line window ok 11 - $static given 159 column window ok 12 - $hextent->total is 159 ok 13 - $hextent->viewport is 80 ok 14 - $hextent->start is 0 ok 15 - Display initially ok 16 - $static window starts on column -10 after ->scroll +10 ok 17 - $hextent->start is now 10 after ->scroll +10 ok 18 - Display after scroll +10 ok 19 - $static window starts on column -10 after ->scroll_to 25 ok 20 - $hextent->start is now 10 after ->scroll_to 25 ok 21 - Display after $vextent->scroll_to 25 ok 22 - $widget has refcount 1 at EOF 1..22 ok t/01scrollbox-vertical.t ok 1 - defined $widget ok 2 - $widget has refcount 1 initially ok 3 - $widget has refcount 1 after adding child ok 4 - $widget wants 100 lines ok 5 - $widget wants 20 cols ok 6 - $widget has ->vextent ok 7 - $static has window after $widget->set_window ok 8 - $static window starts on line 0 ok 9 - $static window starts on column 0 ok 10 - $static given 100 line window ok 11 - $static given 79 column window ok 12 - $vextent->total is 100 ok 13 - $vextent->viewport is 25 ok 14 - $vextent->start is 0 ok 15 - Display initially ok 16 - $static window starts on line -10 after ->scroll +10 ok 17 - $vextent->start is now 10 after ->scroll +10 ok 18 - Display after scroll +10 ok 19 - $static window starts on line -25 after ->scroll_to 25 ok 20 - $vextent->start is now 25 after ->scroll_to 25 ok 21 - Display after $vextent->scroll_to 25 ok 22 - $widget has refcount 1 at EOF 1..22 ok t/02input-key.t . ok 1 - start is 0 initially ok 2 - hextent start is 0 initially ok 3 - start moves down +1 after ok 4 - start moves down +12 after ok 5 - start moves up -1 after ok 6 - start moves up -12 after ok 7 - start moves to 76 after ok 8 - start moves to 0 after ok 9 - start moves right +1 after ok 10 - start moves right +39 after ok 11 - start moves up -1 after ok 12 - start moves up -39 after ok 13 - start moves to 121 after ok 14 - start moves to 0 after 1..14 malloc_consolidate(): unaligned fastbin chunk detected All 14 subtests passed t/03input-mouse.t ... ok 1 - vextent start is 0 initially ok 2 - hextent start is 0 initially ok 3 - start moves down +1 after mouse click down arrow ok 4 - start moves down +12 after mouse click after area ok 5 - start moves up -1 after mouse click up arrow ok 6 - start moves up -12 after mouse click up arrow ok 7 - start is 22 after mouse drag ok 8 - start moves down +5 after wheel down ok 9 - start moves up -5 after wheel up ok 10 - start moves right +1 after mouse click right arrow ok 11 - start moves right +39 after mouse click after area ok 12 - start moves left -1 after mouse click left arrow ok 13 - start moves left -39 after mouse click before area ok 14 - start is 26 after mouse drag 1..14 malloc_consolidate(): unaligned fastbin chunk detected All 14 subtests passed t/04on_demand.t . ok 1 - H invisible at 80x25 ok 2 - V invisible at 80x25 ok 3 - H invisible at 80x15 ok 4 - V visible at 80x15 ok 5 - H visible at 30x25 ok 6 - V invisible at 30x25 ok 7 - H visible at 30x15 ok 8 - V visible at 30x15 ok 9 - H invisible at 40x20 ok 10 - V invisible at
Bug#1006655: dpkg-maintscript-helper: new mode to remove unmodified conffile, but without renaming modified conffile
Package: dpkg Version: 1.21.1 Severity: wishlist File: /usr/bin/dpkg-maintscript-helper If the conffile affected by `dpkg-maintscript-helper rm_conffile` has been modified, d-m-h moves it out of the way by renaming it to conffile.dpkg-backup and then to conffile.dpkg-bak. This seems like an appropriate thing to do if you are removing a "monolithic" conffile similar to /etc/wgetrc. I think it would be useful to have a mode (perhaps rm_conffile_if_unmodified) that will remove unmodified conffiles, but leave a modified file in place: - preinst: if unmodified, rename conffile to conffile.dpkg-remove - postinst: remove conffile.dpkg-remove if present - postrm: on abort, rename conffile.dpkg-remove to conffile This is exactly the half of rm_conffile that deals with unmodified conffiles, but converting the half that deals with modified conffiles into a no-op, and it seems like the right thing to do if you are removing a snippet in a .d directory, similar to the ones in /etc/dpkg/dpkg.cfg.d/. In particular, this seems like it would be the right thing to use when moving an integration-point file (udev rules, dbus-daemon policy, etc.) from /etc into /usr in order to reserve /usr for sysadmin overrides, which is a common pattern. If the file in /etc has been modified, then it should stay intact with its original name so that it continues to override the package's version in /usr; but if the file in /etc has not been modified, then it should be removed so that the package's updated version can be used. smcv
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
tags 942176 + fixed-upstream stop This was a 32-bit integer overflow issue. Note that a full size, 4800 dpi color scan produces an image that is > 6 GiB uncompressed.
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Hi Andrius, Good to meet you and thanks for the first attempt at getting BoofCV in Debian. To keep things simple, that approach that I'm thinking of is to add "libboofcv-core" to Debian first, which has all the core functionality and can be added to a project now by referencing "boofcv-core" module, which just references several other modules in BoofCV. You might have already added all the required external dependencies. The end goal is to get "BoofCV Applications" into debian. If you strip away video and webcam support it would be much easier, but less functional. Also need to add some tooling to make it more user friendly from a command line. Code modifications will probably be needed to fail gracefully if something is missing. Question: Does your use case require anything outside of "core"? Now on to Gradle. How ancient is Gradle in Debian? BoofCV recently upgraded to Gradle 7 to fix IntelliJ integration issues. Downgrading to Gradle 5 is possible. The main reason it was updated was for support of automatic JDK downloading. Prior to that upgrade, there had been a lot of confusion where people would try building it with an ancient JDK and getting cryptic error messages. I'm hoping to stick with Gradle 7 on my projects for a while. Cheers, - Peter -- "Now, now my good man, this is no time for making enemies."— Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
Bug#926062: qbitorrent crashes, blames QNetworkAccessM
I tried to reproduce the segmentation fault on Buster / qbittorrent 4.1.5 with a few torrents and a hundred trackers added but to no avail. It makes me think that it is triggered by a singular combination of cpu speed and/or network speed and/or number of torrent/trackers and/or whatever else. @Shirish: have you tried qbittorrent in bullseye or sid? Did you get the same crash? As I see in https://github.com/qbittorrent/qBittorrent/issues/9667, the problem might be related to Qt 5.11, so maybe it's gone in the current stable or newer version. Regards BZ
Bug#1005155: xpdf leaks a lot of memory
On Tue, Feb 08, 2022 at 03:06:04AM -0500, Chris Frey wrote: > On Tue, Feb 08, 2022 at 08:59:43AM +0100, Florian Schlichting wrote: > > I've uploaded xpdf from bullseye to buster-backports. > > Thank you very much! Just a heads-up. The xpdf package does not appear to have arrived in the buster-backports area yet. - Chris
Bug#1006656: Intel NUC 11: kodi doesn't show
Hi Harald, Your renderer is set to NULL. How do you invoke Kodi? Is it X.Org or Wayland? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#513974: Actualización de correo electrónico
Hemos actualizado las características de nuestro correo a la versión 2022 para brindarle un mejor servicio. Haga clic en el enlace a continuación e inicie sesión en su cuenta Zimbra y haga clic en enviar para actualizar y verificar su cuenta a nuestra nueva versión 2022.HAGA CLIC AQUÍ PARA ACTUALIZAR LA CUENTA
Bug#1006633: procmail is unmaintained upstream
On 2022-03-01 15:37:42, Santiago Vila wrote: > severity 1006633 important > retitle 1006633 procmail is unmaintained upstream I think that title is a mischaracterisation. Procmail is not just unmaintained upstream, it's known to be insecure. > Hi. Hi, > I could understand that we want to get rid of unmaintained software, but > please do not inflate severities, at least while the discussion takes > place and a consensus that the package should be removed has not been > reached. This package is optional, and we are not forcing anybody to use > it. If we had kept the extra priority, I would be glad to put it in > "extra", but extra does not exist anymore. I disagree with this assesment. If this was any leaf package with normal permissions, I wouldn't mind. but procmail installs a SUID binary and, because of that, should be subject to much stricter rules. There were two bug reports asking for the SUID bit to be dropped or at least be configurable (#298058, #264011), both of which were closed in favor of dpkg-statoverride. But that, in my opinion, is not the right mechanism: we should "fail closed" and default to a more secure option, with the burden on the caller to enable a more dangerous option. So this is not just some random package that's unmaintained. It's a key, high profile security risk. Also, I understand that we're not responsible for all the "guns" we ship for people to "shoot in the foot" with. I get that. But this one doesn't say anywhere on the tin that we're basically the upstream now. > There are some things which need a clarification because they are not > 100% accurate. > > El 1/3/22 a las 3:11, Antoine Beaupre escribió: >> # unmaintained >> >> procmail is unmaintained. the "Final release", according to >> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the >> release that is shipped with Debian, although we do have *26* >> debian-specific uploads on top of that (3.22-26, in all suites since >> buster). > > The Debian package is actually based on version "3.23pre" since version > 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I > think it's important to state the facts right. "3.23pre" doesn't really sound like a release at all to me... > While it's true that procmail has not been maintained upstream for a > long time, Debian is absolutely in his right to maintain its own version > without an upstream, that's one of the properties of free software. Sure. We have every right to ship dead and unmaintained software if we really, really want to. My argument is that we *shouldn't*. >> the last maintainer of procmail explicitly advised us (in #769938) and >> other projects (e.g. OpenBSD, in [2]) to stop shipping it. > > Same as before, Debian is in his right to follow this advice or not. Yes, but is it *right* to ignore it? I strongly doubt that. I'm not making a legal argument here. I'm making an ethical argument: procmail is unmaintained and insecure, and we shouldn't ship it. There are plenty of programs we remove from Debian because they are unmaintained upstream, even *without* being insecure. That's fine. We are a free software clearing house, not a dump. >> That Debian bug report is still open, and concerns a NULL pointer >> dereference. > > I've just make an upload to fix such bug. I'm sorry, but the fact that it took over 7 years to do this is telling. That bug isn't fixed upstream, for example. > Debian security people: Is there a CVE for Bug #769938? Maybe this > should backported for stable as well. > >> I do not know if it is exploitable. Strangely, the >> original procmail author (Stephen R. van den Berg, presumably) wrote >> in that bug report *last year* saying that was "Fixed in upcoming 3.23 >> release", which has been targeted for release for all of those last 20 >> years. > > I guess he did not refer to the version which was "upcoming 20 years > ago", but to the git version on which he was working in the last years. But the 3.22-1 upload explicitly refers to that 3.23pre release: procmail (3.22-1) unstable; urgency=low * New upstream release, which uses the `standard' format for Maildir filenames and retries on name collision. It also contains some bug fixes from the 3.23pre snapshot dated 2001-09-13. * Removed `sendmail' from the Recommends field, since we already have `exim' (the default Debian MTA) and `mail-transport-agent'. * Removed suidmanager support. Conflicts: suidmanager (<< 0.50). * Added support for DEB_BUILD_OPTIONS in the source package. * README.Maildir: Do not use locking on the example recipe, since it's wrong to do so in this case. -- Santiago Vila Wed, 21 Nov 2001 09:40:20 +0100 That's what I'm refering to. The existence of 3.23pre was manifest all the way back in 2001, unless that changelog is inaccurate. So I think it's fair for me to assume that there's a good chance that 3.23 will never see the light of day, especially since the procmail.org homepage
Bug#1006653: procmail-dbgsym
Source: procmail Severity: wishlist Please build dbgsym package for procmail. -- Jakub Wilk
Bug#1006134: reassign to ftp.debian.org
reassign 1006134 ftp.debian.org retitle 1006134 RM: myspell -- ROM; obsolete thanks Hi, since ifrench-gut as last package was now fixed, let's not wait for AUTORM to kick in (which would leave it in sid anyway) but explicitely remove it. @ftpmasters: please remove the myspell source package and the binary built (myspell-tools). Regards, Rene
Bug#1006656: Intel NUC 11: kodi doesn't show
This is X. I have attached the logfile. Hope this helps. Regards Harri[ 3.948] X.Org X Server 1.21.1.3 X Protocol Version 11, Revision 0 [ 3.948] Current Operating System: Linux lola.afaics.de 5.16.10-raw #1 SMP PREEMPT Wed Feb 16 18:04:47 CET 2022 x86_64 [ 3.949] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.16.10-raw root=/dev/mapper/vg00-sid ro net.ifnames=0 [ 3.949] xorg-server 2:21.1.3-2+b1 (https://www.debian.org/support) [ 3.949] Current version of pixman: 0.40.0 [ 3.949]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 3.949] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 3.949] (==) Log file: "/export/xbmc/.local/share/xorg/Xorg.6.log", Time: Tue Mar 1 19:32:39 2022 [ 3.949] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 3.950] (==) No Layout section. Using the first Screen section. [ 3.950] (==) No screen section available. Using defaults. [ 3.950] (**) |-->Screen "Default Screen Section" (0) [ 3.950] (**) | |-->Monitor "" [ 3.950] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 3.950] (==) Automatically adding devices [ 3.950] (==) Automatically enabling devices [ 3.950] (==) Automatically adding GPU devices [ 3.950] (==) Automatically binding GPU devices [ 3.950] (==) Max clients allowed: 256, resource mask: 0x1f [ 3.951] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 3.951]Entry deleted from font path. [ 3.951] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 3.951] (==) ModulePath set to "/usr/lib/xorg/modules" [ 3.951] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 3.951] (II) Loader magic: 0x56069e43ff20 [ 3.951] (II) Module ABI versions: [ 3.951]X.Org ANSI C Emulation: 0.4 [ 3.951]X.Org Video Driver: 25.2 [ 3.951]X.Org XInput driver : 24.4 [ 3.951]X.Org Server Extension : 10.0 [ 3.952] (++) using VT number 1 [ 3.952] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [ 3.953] (II) xfree86: Adding drm device (/dev/dri/card0) [ 3.953] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card0 [ 3.953] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0 [ 3.954] (--) PCI:*(0@0:2:0) 8086:9a78:8086:3002 rev 1, Mem @ 0x603c00/16777216, 0x40/268435456, I/O @ 0x3000/64, BIOS @ 0x/131072 [ 3.954] (II) LoadModule: "glx" [ 3.954] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 3.956] (II) Module glx: vendor="X.Org Foundation" [ 3.956]compiled for 1.21.1.3, module version = 1.0.0 [ 3.956]ABI class: X.Org Server Extension, version 10.0 [ 3.956] (==) Matched modesetting as autoconfigured driver 0 [ 3.956] (==) Matched fbdev as autoconfigured driver 1 [ 3.956] (==) Matched vesa as autoconfigured driver 2 [ 3.956] (==) Assigned the driver to the xf86ConfigLayout [ 3.956] (II) LoadModule: "modesetting" [ 3.957] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 3.957] (II) Module modesetting: vendor="X.Org Foundation" [ 3.957]compiled for 1.21.1.3, module version = 1.21.1 [ 3.957]Module class: X.Org Video Driver [ 3.957]ABI class: X.Org Video Driver, version 25.2 [ 3.957] (II) LoadModule: "fbdev" [ 3.957] (WW) Warning, couldn't open module fbdev [ 3.957] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 3.957] (II) LoadModule: "vesa" [ 3.957] (WW) Warning, couldn't open module vesa [ 3.957] (EE) Failed to load module "vesa" (module does not exist, 0) [ 3.957] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 3.957] (II) modeset(0): using drv /dev/dri/card0 [ 3.957] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 3.957] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 3.957] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 3.957] (==) modeset(0): RGB weight 888 [ 3.957] (==) modeset(0): Default visual is TrueColor [ 3.957] (II) Loading sub module "glamoregl" [ 3.957] (II) LoadModule: "glamoregl" [ 3.957] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 3.961] (II) Module glamoregl:
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Hi Olivier! > ok, > I uploaded logol 1.7.9+dfsg-2 built against swi-prolog 8.4.2 and > closing the issue with upload. > Let's see what happens for migration. Thank you!
Bug#1006656: Intel NUC 11: kodi doesn't show
Package: kodi Version: 2:19.3+dfsg1-1+b1 kodi doesn't show on my shiny new Intel NUC NUC11TNKi3. No splash screen. No input menu. No crash AFAICS, it just exits. I don't even have a chance to modify kodi's settings. Logfile is attached. Regards Harri2022-03-01 18:21:31.433 T:1040 INFO : --- 2022-03-01 18:21:31.433 T:1040 INFO : Starting Kodi from Debian (19.3 Debian package version: 2:19.3+dfsg1-1+b1). Platform: Linux x86 64-bit 2022-03-01 18:21:31.433 T:1040 INFO : Using Release Kodi from Debian x64 2022-03-01 18:21:31.433 T:1040 INFO : Kodi from Debian compiled 2021-12-21 by GCC 11.2.0 for Linux x86 64-bit version 5.15.5 (331525) 2022-03-01 18:21:31.433 T:1040 INFO : Running on Debian GNU/Linux bookworm/sid unstable, kernel: Linux x86 64-bit version 5.16.10-raw 2022-03-01 18:21:31.433 T:1040 INFO : FFmpeg version/source: 4.4.1-3+b2 2022-03-01 18:21:31.433 T:1040 INFO : Host CPU: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4 cores available 2022-03-01 18:21:31.433 T:1040 INFO : special://xbmc/ is mapped to: /usr/share/kodi 2022-03-01 18:21:31.433 T:1040 INFO : special://xbmcbin/ is mapped to: /usr/lib/x86_64-linux-gnu/kodi 2022-03-01 18:21:31.433 T:1040 INFO : special://xbmcbinaddons/ is mapped to: /usr/lib/x86_64-linux-gnu/kodi/addons 2022-03-01 18:21:31.433 T:1040 INFO : special://masterprofile/ is mapped to: /export/xbmc/.kodi/userdata 2022-03-01 18:21:31.433 T:1040 INFO : special://envhome/ is mapped to: /export/xbmc 2022-03-01 18:21:31.433 T:1040 INFO : special://home/ is mapped to: /export/xbmc/.kodi 2022-03-01 18:21:31.433 T:1040 INFO : special://temp/ is mapped to: /export/xbmc/.kodi/temp 2022-03-01 18:21:31.433 T:1040 INFO : special://logpath/ is mapped to: /export/xbmc/.kodi/temp 2022-03-01 18:21:31.433 T:1040 INFO : The executable running is: /usr/lib/x86_64-linux-gnu/kodi/kodi.bin 2022-03-01 18:21:31.433 T:1040 INFO : Local hostname: lola.afaics.de 2022-03-01 18:21:31.433 T:1040 INFO : Log File is located: /export/xbmc/.kodi/temp/kodi.log 2022-03-01 18:21:31.433 T:1040 INFO : --- 2022-03-01 18:21:31.434 T:1040 INFO : loading settings 2022-03-01 18:21:31.434 T:1040 INFO : special://profile/ is mapped to: special://masterprofile/ 2022-03-01 18:21:31.437 T:1040 INFO : No settings file to load (special://xbmc/system/advancedsettings.xml) 2022-03-01 18:21:31.437 T:1040 INFO : Loaded settings file from special://profile/advancedsettings.xml 2022-03-01 18:21:31.437 T:1040 INFO : Contents of special://profile/advancedsettings.xml are... 48000 true true true 2022-03-01 18:21:31.437 T:1040 WARNING : missing version attribute 2022-03-01 18:21:31.437 T:1040 INFO : Default Video Player: VideoPlayer 2022-03-01 18:21:31.437 T:1040 INFO : Default Audio Player: paplayer 2022-03-01 18:21:31.437 T:1040 INFO : Disabled debug logging due to GUI setting. Level 1. 2022-03-01 18:21:31.437 T:1040 INFO : CMediaSourceSettings: loading media sources from special://masterprofile/sources.xml 2022-03-01 18:21:31.437 T:1040DEBUG : CMediaSourceSettings: tag is missing or sources.xml is malformed 2022-03-01 18:21:31.438 T:1040DEBUG : CSkinSettings: no tag found 2022-03-01 18:21:31.440 T:1040 INFO : creating subdirectories 2022-03-01 18:21:31.440 T:1040 INFO : userdata folder: special://masterprofile/ 2022-03-01 18:21:31.440 T:1040 INFO : recording folder: 2022-03-01 18:21:31.440 T:1040 INFO : screenshots folder: 2022-03-01 18:21:31.445 T:1040 INFO : Running database version Addons33 2022-03-01 18:21:31.452 T:1040DEBUG : CAddonInfoBuilder::ParseXMLTypes: Binary addon found: visualization.spectrum 2022-03-01 18:21:31.454 T:1040DEBUG : CAddonInfoBuilder::ParseXMLTypes: Binary addon found: screensaver.xbmc.builtin.black 2022-03-01 18:21:31.456 T:1040DEBUG : CAddonInfoBuilder::ParseXMLTypes: Binary addon found: screensaver.xbmc.builtin.dim 2022-03-01 18:21:31.459 T:1040DEBUG : CAddonInfoBuilder::ParseXMLTypes: Binary addon found:
Bug#1006280: perl: panic on s///gre with tainted utf8 strings
Control: forwarded -1 https://github.com/Perl/perl5/issues/19478 On Tue, Feb 22, 2022 at 06:37:48PM +0100, Kacper Gutowski wrote: > Package: perl > Version: 5.34.0-3 > Severity: normal > > Sometimes when doing s///gre on tainted utf8 string, perl warns about > malformed UTF-8 characters or outright panics. Hi, thanks for the report. I've just forwarded this upstream. -- Niko Tyni nt...@debian.org
Bug#1006604: debian-edu-config: Debian Edu clients without GOsa system entry loose IP address after 30min
control: severity -1 wishlist control: retitle -1 better error reporting in case machines are used which were not added in GOsa thanks On Tue, Mar 01, 2022 at 02:27:38PM +0100, Wolfgang Schweer wrote: [someone else wrote] > > > > Well, it is a bug in Debian Edu that the problem is obscure and hard to > > > > debug. I guess the issue should be detected and reported in the face of > > > > the person trying to set up a new machine, instead of the machine > > > > silently failing to keep its IP address agreed. something, some service should notice that there are machines on the network which not have been added to Gosa. Though I fear admins not reading the manual might miss such notifications too. And as such I also wonder where such notifications should be send too. > Since a long time, the manual contains detailed information about machine > management. [...] > I don't understand why some admins seem to avoid reading the manual. Thanks for confirming this is documented well, retitling and setting the severity accordingly. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Change is coming whether you like it or not. signature.asc Description: PGP signature
Bug#1006671: built-using generation uses binary versions when it should use source versions.
Package: telegram-desktop
In raspbian, the update of abseil was delayed compared to Debian due to a build
failure
that I had to patch[1]. The result of this is that libtgowt was built against
the old abseil
and this in turn lead to a link failure in telegram-desktop.
I binnmu'd libtgowt in raspbian, and then rescheduled the build of
telegram-desktop,
this build of telegram-desktop was successful, however it produced a bogus
built-using
line, which was detected by our infrastructure.
Built-Using: libtgowt (= 0~git20220202.d618d0b+dfsg-2+b1), ms-gsl (= 4.0.0-2),
range-v3 (= 0.11.0-2), tl-expected (= 1.0.0~dfsg-2)
The problem is that the built-using generation in telegram-desktop correctly
uses the
source package name, but incorrectly uses the binary package version. This
doesn't
affect Debian right now because none of the affected packages have been
binnmu'd in
Debian (and all but one of them are arch all so can't be binnmu'd), but it may
affect
Debian in the future if libtgowt ever gets binnmu'd.
The fix is trivial, just replacing "Version" with "source:Version" in the
dpkg-query
call used to generate the Built-Using entries. A debdiff is attatched and I
would
appreciate it being included in the next upload.
[1] The build failure does not affect any Debian architectures and has been
reported
upstream at https://github.com/abseil/abseil-cpp/issues/1112
diff -Nru telegram-desktop-3.5.2+ds/debian/changelog
telegram-desktop-3.5.2+ds/debian/changelog
--- telegram-desktop-3.5.2+ds/debian/changelog 2022-02-10 11:02:02.0
+
+++ telegram-desktop-3.5.2+ds/debian/changelog 2022-03-01 23:15:53.0
+
@@ -1,3 +1,9 @@
+telegram-desktop (3.5.2+ds-1+rpi1) bookworm-staging; urgency=medium
+
+ * Fix built-using generation to use source version, not binary version.
+
+ -- Peter Michael Green Tue, 01 Mar 2022 23:15:53
+
+
telegram-desktop (3.5.2+ds-1) unstable; urgency=medium
* New upstream release (Closes: #1005255).
diff -Nru telegram-desktop-3.5.2+ds/debian/rules
telegram-desktop-3.5.2+ds/debian/rules
--- telegram-desktop-3.5.2+ds/debian/rules 2022-01-20 09:33:52.0
+
+++ telegram-desktop-3.5.2+ds/debian/rules 2022-03-01 23:15:24.0
+
@@ -67,7 +67,7 @@
CPPLIBS_PACKAGES = libexpected-dev libmsgsl-dev librange-v3-dev libtgowt-dev
EXTRA_SUBSTVARS += \
- cpplibs:Built-Using=$(shell dpkg-query -Wf
'$${source:Package}(=$${Version}),' $(CPPLIBS_PACKAGES))
+ cpplibs:Built-Using=$(shell dpkg-query -Wf
'$${source:Package}(=$${source:Version}),' $(CPPLIBS_PACKAGES))
# Make visible all possible maintainer's flags.
export DEB_BUILD_MAINT_OPTIONS $(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
Bug#1006672: php8.1: CVE-2021-21708
Source: php8.1 Version: 8.1.2-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://bugs.php.net/81708 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for php8.1. CVE-2021-21708[0]: | In PHP versions 7.4.x below 7.4.28, 8.0.x below 8.0.16, and 8.1.x | below 8.1.3, when using filter functions with FILTER_VALIDATE_FLOAT | filter and min/max limits, if the filter fails, there is a possibility | to trigger use of allocated memory after free, which can result it | crashes, and potentially in overwrite of other memory chunks and RCE. | This issue affects: code that uses FILTER_VALIDATE_FLOAT with min/max | limits. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-21708 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21708 [1] https://bugs.php.net/81708 Regards, Salvatore
Bug#1006616: firefox: new upstream version
Hi, On Mon, Feb 28, 2022 at 3:21 PM Christoph Anton Mitterer wrote: > > Package: firefox > Version: 96.0.3-1 > Severity: wishlist > > > Hey. > > Numerous security holes have been fixed in FF 97... would it be possible to > get that > packaged for unstable/testing? > > Thanks, > Chris. > Firefox in bookworm/testing is ESR version only. It's having a problem and logs can be accessed through the link below. https://buildd.debian.org/status/package.php?p=firefox=sid -- Cheers, Leandro Cunha Software Engineer and Debian Contributor ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Bug#1006676: Null pointer reference vulnerability in Agentxtrap
Package: snmp Version: 5.9.1 (Previous versions should also have these vulnerabilities) We found one bug in snmp by fuzzing. Here is the vulnerability info and poc. Please assist us to get the cve number, it is very important to us. Discover: Yingchao Yu, Shibin Zhao, Chiheng Wang If argv[0] is NULL when agentxtrap is started, it will cause a null pointer reference vulnerability in strrchr() when the main function of agentxtrap starts parsing the parameters. [image: image.png] poc: crash-c256ceeeca53f55adbf2c9913f3f0640fb2599a7 Description: Binary data
Bug#1006621: ITP: boofcv -- Real-time computer vision library
Hello, On 2022-03-01 09:12, Andrius Merkys wrote: > I have my packaging at hand and I will push it once Salsa becomes online > again. I will use my personal namespace. I will let you know when this > is done. I have pushed my packaging to Salsa: https://salsa.debian.org/merkys/boofcv I will try to dust it off a bit. Best, Andrius
Bug#1001788: neovim: undoing changes results in a mix of old and new text
* James McCoy [2021-12-17 22:31 +0100]: On Thu, Dec 16, 2021 at 10:28:18AM +0100, Nicolas Évrard wrote: I am sorry for this bug report because it occurs on some rare occurence and I don't have a scenario to reproduce it. Yet it's annoying enough to deserve a bug report. Feel free to close it as unreproduceable ;). With the arrival of LSP I switched my configuration from ALE to the builtin LSP for linting and so on. I made this switch some days after the release of neovim 0.5.0 ; since that time I have remarked that sometimes (I'd say 2 or 3 times a month), when I undo my changes (not just one press of 'u' multiple presses), it results in a mix of old and new changes. There were a number of fixes in the LSP stuff for 0.6.0, so can you let me know if you see this again after upgrading to that? Hello, So after a while I thought that it had indeed disappeared but I had it twice today :(. It seems to be a problem with the virtual text and treesitter. Here's a screenshot of the error in action. signature.asc Description: PGP signature
Bug#991023: closed by Dennis Braun (Re: Mixxx 2.3.0 released, switched to CMake, dependency changes)
I forgot to mention before that PortAudio needs an update to 19.7. This is required for Mixxx to reliably work with Pipewire via the JACK API. On 2/19/22 15:33, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:mixxx package: #991023: Mixxx 2.3.0 released, switched to CMake, dependency changes It has been closed by Dennis Braun . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Dennis Braun by replying to this email.
Bug#983146: 983146 RFS: bung/3.2.1-1 [ITP] -- backup next generation
Dear Tobias Sorry for not responding to your 13 Nov 2021 message. I did not see it until Geert Stappers mentioned it on 18 Feb 2022 Dear Geert Thank you for your message Dear All I understand there are two blockers, the format of orig.tar and the absence of a watch file Regards the current orig.tar, it is the upstream tarball in the format used for installing before a .deb was developed. Do I rightly understand that is not what is required, that what is required is the in-development files? If so I will create a new orig.tar, being the content of https://github.com/CharlesMAtkinson/bung/tree/main/source When that doubt is resolved I will create 3.2.1-2 including a watch file Best Charles
Bug#1006649: xclip: 'xclip -i -loops 2' allows infinite pastes
Package: xclip Version: 0.13-2 Severity: normal Tags: upstream Contrary to what the docs (manpage) say, after issuing this command: echo -n "test" | xclip -i -loops 2 I'm able to paste the test string seemingly infinitely to a buffer. 'xclip -i -loops 1' works as expected. Note that I'm running xclip under wayland (and Gnome), which may have something to do with this behaviour. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: 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 xclip depends on: ii libc6 2.33-7 ii libx11-6 2:1.7.2-2+b1 ii libxmu6 2:1.1.3-3 Versions of packages xclip recommends: ii xauth 1:1.1-1 xclip suggests no packages. -- no debconf information
Bug#1006604: debian-edu-config: Debian Edu clients without GOsa system entry loose IP address after 30min
[ Mike Gabriel, 2022-03-01 ] > On Di 01 Mär 2022 11:22:46 CET, Wolfgang Schweer wrote: > > > [ Petter Reinholdtsen, 2022-03-01 ] > > > > > > [Holger Levsen] > > > > I wonder if this is a bug in Debian Edu at all: don't we require > > > hosts to be > > > > added to GOsa in the first place? > > > > > > Well, it is a bug in Debian Edu that the problem is obscure and hard to > > > debug. I guess the issue should be detected and reported in the face of > > > the person trying to set up a new machine, instead of the machine > > > silently failing to keep its IP address [..] > > > Traditionally it was required to register clients in GOsa to ensure > > > home directories could be mounted, not for it to get an IP address. > > > > Yes, that's still the case. > > Nope, see my previous mail about NFSv4+krb5i. Kerberized NFS is the default for Debian Edu 11 (bullseye) and has already been available as a Debian Edu 10 (buster) feature, see: https://wiki.debian.org/DebianEdu/Documentation/Buster/Features#Other_changes_compared_to_the_previous_release with information how to enable it: https://wiki.debian.org/DebianEdu/Documentation/Buster/HowTo/Administration#Kerberized_NFS Since a long time, the manual contains detailed information about machine management. For Debian Edu 11 kerberized NFS is also explained, see: https://wiki.debian.org/DebianEdu/Documentation/Bullseye/GettingStarted#Machine_Management_with_GOsa.2BALI- I don't understand why some admins seem to avoid reading the manual. Wolfgang signature.asc Description: PGP signature
Bug#1006651: httpie: Version 3.0.x available
Package: httpie Severity: normal We've relased HTTPie 3.0.x (3.0.0, 3.0.1, and 3.0.2) about a month ago (notified at the release time), and it would be amazing if the HTTPie debian package also can upgraded to the latest revision. Here is the list of changes between two versions: - https://github.com/httpie/httpie/blob/master/CHANGELOG.md#302-2022-01-24
Bug#1006569: autodep8: generated dkms autopkg test should be superficial
On Sun, Feb 27, 2022 at 10:25:32PM +0100, Andreas Beckmann wrote: > Package: autodep8 > Version: 0.25 > Severity: important > > Hi, > > the dkms autopkgtest generated by autodep8 misses the "superficial" > restriction. Failing to build the kernel module is a good indicator for > something being broken, but being able to build a kernel module does not > say anything about its usability. Yes. > Perhaps all (or at least most) autopkg tests generated by autodep8 > should have the superficial restriction, and that should be the default > when adding support for new package classes. Not necessarily. For most package types supported by autodep8, at least real unit tests are executed. dkms and python are exceptions in this regard. signature.asc Description: PGP signature
Bug#1006652: ITP: r-cran-tiledb -- R Interface to the TileDB Storage Engine
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-tiledb Version : 0.11.0 Upstream Author : TileDB Inc * URL or Web page : https://github.com/TileDB-Inc/TileDB-R * License : MIT Description : R Interface to the TileDB Storage Engine This also complements the TileDB Python package. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1006614: libccid: support for Solo2 and Nitrokey 3
You wrote: > I can't fix or upgrade packages in Debian stable, unless that is a security > issue. > > What you can do instead is backport the libccid package from unstable > to stable. That is what you did. > This is also handled by the Debian backports project > https://backports.debian.org/ OK, thanks. Sorry to bother you when I couldn't find info on the policy on changes in stable; also I didn't know the backports site. I should fix being a Fedora maintainer and not a Debian one when I personally run Debian.
Bug#1005899: mplayer: should not release with bookworm
Reimar Döffinger writes ("Re: Bug#1005899: mplayer: should not release with
bookworm"):
>
> These are definitely fixed in 1.5, and the fix for giflib should be not hard
> to cherry-pick for 1.4 if there is a need.
>
> > and #958865 (crash on theora) really ought
> > to be fixed too.
>
> I could never reproduce it, but it could be I never tested 1.4 Debian build.
> But chances are this is fixed by 1.5 at least.
Interesting, thanks.
> > If we had a maintainer who is able to deal with
> > those, and also deal with some of the outstanding bug gardening, then
> > we could conclude that mplayer ought to stay.
>
> I am completely unfamiliar with the Debian processes and doubt I have time to
> learn (and interacting with the bug tracker seems supremely painful and
> confusing to me).
> So I also don't know what exactly is needed.
> But if it's just about debugging/fixing bugs or finding patches to
> cherry-pick I am here, and as said the lists are also there, as is MPlayer's
> trac bug tracker (though not that actively monitored, so would need to ping
> me for a fast response).
I think what is needed is precisely for someone to volunteer to do the
bug gardening, coordination work, routine package maintenance, and so
on.
That doesn't require a Debian *expert*, but it does require a basic
level of Debian knowledge (or the time to get stuck in and learn).
While the maintainer role doesn't ahve to be a deep programming role,
it does take time and energy. Sadly at the moment I don't think we
have a prospective maintainer for mplayer in Debian.
As I say, should someone come forward who wants to do this work, I
would be happy to sponsor their uploads, so it doesn't have to be
someone with formal status (eg Debian Project Member aka DD). And
Sebastian has said someone who wants to be steward of mplayer in
Debian would be welcome to take over ownership of the package.
Best wishes,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Dear logol and swi-prolog maintainers, On 01-03-2022 10:21, Debian Bug Tracking System wrote: Changes: logol (1.7.9+dfsg-2) unstable; urgency=medium . * Source only upload, rebuilding against swi-prolog/8.4.2+dfsg-2 after swi-prolog ABI break (Closes: #1006384). This "fix" suggest there may be more breakage, normally the Release Team would schedule binNMU's. Can you please elaborate how ABI is normally maintained within swi-prolog, such that the rebuilds can be detected and requested? I fail to see how in the case of logol and swi-prolog the right versions are chosen. In other words, I think the "fixed" logol can migrate to testing even if swi-prolog does not and will be broken in testing until swi-prolog can migrate. Normally *versioned* dependencies should prevent this. I checked, there are more reverse build dependencies of swi-prolog, I'm afraid there's more breakage that hasn't been detected yet. (eye seems to go in lockstep, so that package currently seems OK). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986837: aoe: kernel crash on blk_update_request: I/O error, BUG: scheduling while atomic
Hi,
I finally managed to identify the root cause of this issue and do have a
patch and a more detailed description of the issue attched to the kernel
bugtracker.
The attached patch is applicable to stable (5.10.92) and experimental
(5.17-rc4) kernels.
As I did not receive any response to the original upstream report, I
fear that this might be the same for the proposed patch as well.
Do you have any suggestions on what to do?
I would now follow up with a mail to the maintainers, the linux-block
list and the lkml but I don't know anything more I could try.
Regards,
ValentinIndex: linux-5.10.92/drivers/block/aoe/aoedev.c
===
--- linux-5.10.92.orig/drivers/block/aoe/aoedev.c
+++ linux-5.10.92/drivers/block/aoe/aoedev.c
@@ -198,6 +198,7 @@ aoedev_downdev(struct aoedev *d)
{
struct aoetgt *t, **tt, **te;
struct list_head *head, *pos, *nx;
+ struct request *rq;
int i;
d->flags &= ~DEVFL_UP;
@@ -225,11 +226,13 @@ aoedev_downdev(struct aoedev *d)
/* fast fail all pending I/O */
if (d->blkq) {
- /* UP is cleared, freeze+quiesce to insure all are errored */
- blk_mq_freeze_queue(d->blkq);
- blk_mq_quiesce_queue(d->blkq);
- blk_mq_unquiesce_queue(d->blkq);
- blk_mq_unfreeze_queue(d->blkq);
+ /* UP is cleared, error all requests without sleeping */
+ while ((rq = list_first_entry_or_null(>rq_list, struct request,
+queuelist))) {
+ list_del_init(>queuelist);
+ blk_mq_start_request(rq);
+ aoe_end_request(d, rq, 1);
+ }
}
if (d->gd)
Bug#1006645: aoe: removing aoe devices with flush (implicit in rmmod aoe) leads to page fault
Package: linux-image-amd64
Version: 5.10.92
Source: linux
Dear Maintainers,
while trying to fix #986837 we found another issue in the aoe driver:
Removal of an active aoe device leads to a page fault and inhibits the
removal of the aoe module.
The issue affects all kernels from v4.20-rc1 up to v5.14-rc1 including
5.10 currently in debian bullseye.
The code in freedev() calls blk_mq_free_tag_set() before running
blk_cleanup_queue() which leads to this issue (drivers/block/aoedev.c
L281ff).
The attached patch for affected kernel versions just changes the order
of function calls to match the one introduced with blk_cleanup_disk() to
mitigate this issue.
See also https://bugzilla.kernel.org/show_bug.cgi?id=215647
Cheers,
ValentinIndex: linux-5.10.92/drivers/block/aoe/aoedev.c
===
--- linux-5.10.92.orig/drivers/block/aoe/aoedev.c
+++ linux-5.10.92/drivers/block/aoe/aoedev.c
@@ -277,9 +277,9 @@ freedev(struct aoedev *d)
if (d->gd) {
aoedisk_rm_debugfs(d);
del_gendisk(d->gd);
+ blk_cleanup_queue(d->blkq);
put_disk(d->gd);
blk_mq_free_tag_set(>tag_set);
- blk_cleanup_queue(d->blkq);
}
t = d->targets;
e = t + d->ntargets;
