Bug#782171: Updates?
Hi, On Mon, May 20, 2024 at 06:48:38AM +, Zhang, Wentao wrote: > I noticed that in the "package info" box of sources.debian.org, the "SLOC" > field > doesn't recognize Rust. Example [1]. > > After doing some research I believe it's because of the somewhat outdated > sloccount program. Similar report can be found here regarding Scala [2]. Indeed, unfortunately sloccount doesn't seem to be actively maintained, a merge request for Rust support didn't get any attention: https://sourceforge.net/p/sloccount/code/merge-requests/5/ > Do we have any plan of updating this infrastructure? In my use cases, I turn > to > sources.debian.org and that SLOC field quite often if the package is not > maintained on Salsa. I'd love to see support for more languages. We'd need to: - Find a suitable alternative (supports a superset of sloccount languages, has decent performances). - Replace the execution and parsing of sloccount output by this alternative (in https://salsa.debian.org/qa/debsources/-/blob/master/lib/debsources/plugins/hook_sloccount.py?ref_type=heads). - To keep things consistent, run it on the whole archive to replace sloccount results. Insights on the first point are particularly welcome. Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols
Hi Aurélien, On 10/01/2024 19:13, Matthieu Baerts wrote: > On 08/01/2024 21:18, Aurelien Jarno wrote: (...) >> In the latest rebuild of mptpcd, the conditions where met only on the >> riscv64 buildd, and riscv64 is not a release architecture. That said a >> few mips64el buildds also met the 3 conditions and it will be the case >> of more and more buildds once they are upgraded to bookworm. I am >> therefore filling this issue as severity serious. > > Many thanks for the explanation! > > I will wait for the different pipelines to be over, before sending a new > version to mentors.debian.net! This new version has been sent to mentors.debian.net: https://mentors.debian.net/package/mptcpd/ https://mentors.debian.net/debian/pool/main/m/mptcpd/mptcpd_0.12-3.dsc (I guess I will need to prepare a v0.12-4 because of #1060476) Cheers, Matt -- Sponsored by the NGI0 Core fund.
Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols
Hi Aurélien,
On 08/01/2024 21:18, Aurelien Jarno wrote:
> On riscv64, mptcpd fails to build from source with a segmentation fault
> in the test-mptcpwrap test:
(...)
> Investigation shows that 3 conditions are needed to trigger this issue:
> - A recent kernel that supports mptcp, to be checked with
> /proc/sys/net/mptcp/enabled
> - Something that prevents SCTP to be used, for instance on the build
> daemons /proc/sys/kernel/modules_disabled is set to 1, preventing the
> sctp.ko module to be loaded
> - A system without /etc/protocols, for instance without the netbase
> package installed.
>
> With this three conditions, this triggers the following code path from
> the mptcpwrap-tester.c file:
>
> | static void test_socket_data(struct socket_data const *data)
> | {
> | int const fd = socket(data->domain, data->type, data->protocol);
> |
> | if (fd == -1) {
> | if (errno == EPROTONOSUPPORT) {
> | struct protoent const *const p =
> | getprotobynumber(data->protocol);
> |
> | fprintf(stderr,
> | "WARNING: Ignoring unsupported "
> | "protocol: %d - %s\n",
> | data->protocol,
> | p->p_name);
> |
> | return;
> | }
>
> The output of getprotobynumber() is used directly, without checking for
> a NULL pointer in case of error, for instance because /etc/protocols
> does not exist. This causes a segmentation fault when trying to
> dereference it. A workaround is to build-depends on netbase, and a
> proper fix to test for this error.
Thank you for the very nice investigation and analysis!
The fixes were then easy to do:
- upstream: https://github.com/multipath-tcp/mptcpd/pull/286
- debian: https://salsa.debian.org/debian/mptcpd/-/commit/8069902
> In the latest rebuild of mptpcd, the conditions where met only on the
> riscv64 buildd, and riscv64 is not a release architecture. That said a
> few mips64el buildds also met the 3 conditions and it will be the case
> of more and more buildds once they are upgraded to bookworm. I am
> therefore filling this issue as severity serious.
Many thanks for the explanation!
I will wait for the different pipelines to be over, before sending a new
version to mentors.debian.net!
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
Bug#1052667: mptcpd FTBFS when systemd.pc changes systemdsystemunitdir
Hi Helmut, Sorry for the delay, I was at a conference. 25 Sept 2023 23:33:15 Helmut Grohne : > We want to change the value of systemdsystemunitdir in systemd.pc to > point below /usr. mptcpd's upstream build system consumes this variable > while its packaging hard codes the current value. Consequently, mptcpd > FTBFS when changing it. Consider applying the attached patch to avoid > that failure. Thank you for the bug report and the patch, it looks good to me. I'm sorry, it is the first time I'm getting such contributions and I'm not sure what I'm supposed to do: apply the patch in the Git repo, prepare a new release and send it? (I still need someone to sponsor my packages to have new versions accepted) Or do you plan to send a new version with this patch? Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1039711: virtualbox-dkms: kernel BUG with 6.3.0-1-amd64
Hi, using "ibt=off" in kernel cmdline solve the issue. Matthieu - Mail original ----- De: "Matthieu Castet" À: "Debian Bug Tracking System" Envoyé: Mercredi 28 Juin 2023 15:12:01 Objet: Bug#1039711: virtualbox-dkms: kernel BUG with 6.3.0-1-amd64 Package: virtualbox-dkms Version: 7.0.8-dfsg-2 Severity: important X-Debbugs-Cc: castet.matth...@free.fr Dear Maintainer, since the switch to 6.3.0-1-amd64 kernel, when I start a virtualbox image, virtualbox freeze and I have the following kernel log : [ 49.558969] traps: Missing ENDBR: 0x9ba544c4e460 [ 49.558980] [ cut here ] [ 49.558981] kernel BUG at arch/x86/kernel/traps.c:255! [ 49.558986] invalid opcode: [#1] PREEMPT SMP NOPTI [ 49.558989] CPU: 14 PID: 5012 Comm: EMT-0 Tainted: P OE 6.3.0-1-amd64 #1 Debian 6.3.7-1 [ 49.558992] Hardware name: Dell Inc. Precision 5560/0WPMMN, BIOS 1.10.1 05/09/2022 [ 49.558993] RIP: 0010:exc_control_protection+0xc2/0xd0 [ 49.558999] Code: 29 17 41 b6 b9 09 00 00 00 e8 1a 73 53 ff 44 89 e6 48 89 df 5b 5d 41 5c e9 cb 53 00 00 48 c7 43 50 00 00 00 00 e9 64 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 [ 49.559001] RSP: 0018:9ba5451fbcb8 EFLAGS: 00010002 [ 49.559004] RAX: 0028 RBX: 9ba5451fbcd8 RCX: [ 49.559005] RDX: RSI: b64371d5 RDI: [ 49.559006] RBP: 0003 R08: R09: 9ba5451fbb60 [ 49.559007] R10: 0003 R11: b6ad1fe8 R12: [ 49.559008] R13: R14: R15: [ 49.559009] FS: 7f6f3c1ff6c0() GS:8d452f78() knlGS: [ 49.559010] CS: 0010 DS: ES: CR0: 80050033 [ 49.559011] CR2: 7f6ee8c6b000 CR3: 000105bda001 CR4: 00f70ee0 [ 49.559012] PKRU: 5554 [ 49.559013] Call Trace: [ 49.559014] [ 49.559016] ? die+0x36/0x90 [ 49.559018] ? do_trap+0xda/0x100 [ 49.559020] ? exc_control_protection+0xc2/0xd0 [ 49.559022] ? do_error_trap+0x6a/0x90 [ 49.559023] ? exc_control_protection+0xc2/0xd0 [ 49.559025] ? exc_invalid_op+0x50/0x70 [ 49.559027] ? exc_control_protection+0xc2/0xd0 [ 49.559028] ? asm_exc_invalid_op+0x1a/0x20 [ 49.559031] ? exc_control_protection+0xc2/0xd0 [ 49.559033] ? exc_control_protection+0x6e/0xd0 [ 49.559034] asm_exc_control_protection+0x26/0x30 [ 49.559036] RIP: 0010:0x9ba544c4e460 [ 49.559037] Code: 89 da 5b 41 5c 41 5d 5d e9 2d 05 fb ff 48 83 c4 28 b8 8e f8 ff ff 5b 41 5c 41 5d 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 <55> 48 8d 35 98 7b 1d 00 48 89 e5 41 54 49 89 fc 53 e8 7a 11 fb ff [ 49.559038] RSP: 0018:9ba5451fbd80 EFLAGS: 00010286 [ 49.559039] RAX: 9ba544c4e460 RBX: 9ba5480f1010 RCX: [ 49.559040] RDX: RSI: 8d3dc5bda9c0 RDI: 8d3e70710c10 [ 49.559041] RBP: 9ba5451fbdd0 R08: 0024 R09: 0001 [ 49.559041] R10: 8d452f7b9df8 R11: 0002 R12: [ 49.559042] R13: c5f01320 R14: 0004 R15: 8d3e70710c10 [ 49.559045] ? supdrvIOCtl+0x2d52/0x31d0 [vboxdrv] [ 49.559066] ? _copy_from_user+0x4a/0x60 [ 49.559070] ? VBoxDrvLinuxIOCtl_7_0_8+0x162/0x260 [vboxdrv] [ 49.559082] ? __x64_sys_ioctl+0x91/0xd0 [ 49.559085] ? do_syscall_64+0x5c/0xc0 [ 49.559086] ? fpregs_assert_state_consistent+0x26/0x50 [ 49.559089] ? exit_to_user_mode_prepare+0x40/0x1d0 [ 49.559092] ? syscall_exit_to_user_mode+0x1b/0x40 [ 49.559094] ? do_syscall_64+0x6b/0xc0 [ 49.559095] ? fpregs_assert_state_consistent+0x26/0x50 [ 49.559096] ? exit_to_user_mode_prepare+0x40/0x1d0 [ 49.559098] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 49.559100] [ 49.559100] Modules linked in: ctr ccm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c nfnetlink br_netfilter bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm snd_seq_dummy snd_hrtimer snd_seq overlay qrtr cmac algif_hash algif_skcipher af_alg bnep binfmt_misc nvidia_drm(POE) nvidia_modeset(POE) x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi coretemp kvm_intel kvm nls_ascii nls_cp437 irqbypass vfat dell_laptop rapl fat nvidia(POE) dell_wmi snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp iwlmvm snd_sof hci_uart snd_ctl_led btusb snd_hda_codec_realtek snd_sof_utils btqca snd_soc_hdac_hda btrtl snd_hda_ext_core btbcm btintel snd_soc_acpi_intel_match btmtk snd_hda_codec_generic snd_soc_acpi mac80211 ledtrig_audio bluetooth snd_soc_core snd_compress soundwire_bus [ 49.559145] snd_hda_intel snd_usb_audio snd_intel_dspcfg snd_intel_sdw_acpi libarc4 uvcvideo mei_hdcp mei
Bug#1039711: virtualbox-dkms: kernel BUG with 6.3.0-1-amd64
Package: virtualbox-dkms Version: 7.0.8-dfsg-2 Severity: important X-Debbugs-Cc: castet.matth...@free.fr Dear Maintainer, since the switch to 6.3.0-1-amd64 kernel, when I start a virtualbox image, virtualbox freeze and I have the following kernel log : [ 49.558969] traps: Missing ENDBR: 0x9ba544c4e460 [ 49.558980] [ cut here ] [ 49.558981] kernel BUG at arch/x86/kernel/traps.c:255! [ 49.558986] invalid opcode: [#1] PREEMPT SMP NOPTI [ 49.558989] CPU: 14 PID: 5012 Comm: EMT-0 Tainted: P OE 6.3.0-1-amd64 #1 Debian 6.3.7-1 [ 49.558992] Hardware name: Dell Inc. Precision 5560/0WPMMN, BIOS 1.10.1 05/09/2022 [ 49.558993] RIP: 0010:exc_control_protection+0xc2/0xd0 [ 49.558999] Code: 29 17 41 b6 b9 09 00 00 00 e8 1a 73 53 ff 44 89 e6 48 89 df 5b 5d 41 5c e9 cb 53 00 00 48 c7 43 50 00 00 00 00 e9 64 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 [ 49.559001] RSP: 0018:9ba5451fbcb8 EFLAGS: 00010002 [ 49.559004] RAX: 0028 RBX: 9ba5451fbcd8 RCX: [ 49.559005] RDX: RSI: b64371d5 RDI: [ 49.559006] RBP: 0003 R08: R09: 9ba5451fbb60 [ 49.559007] R10: 0003 R11: b6ad1fe8 R12: [ 49.559008] R13: R14: R15: [ 49.559009] FS: 7f6f3c1ff6c0() GS:8d452f78() knlGS: [ 49.559010] CS: 0010 DS: ES: CR0: 80050033 [ 49.559011] CR2: 7f6ee8c6b000 CR3: 000105bda001 CR4: 00f70ee0 [ 49.559012] PKRU: 5554 [ 49.559013] Call Trace: [ 49.559014] [ 49.559016] ? die+0x36/0x90 [ 49.559018] ? do_trap+0xda/0x100 [ 49.559020] ? exc_control_protection+0xc2/0xd0 [ 49.559022] ? do_error_trap+0x6a/0x90 [ 49.559023] ? exc_control_protection+0xc2/0xd0 [ 49.559025] ? exc_invalid_op+0x50/0x70 [ 49.559027] ? exc_control_protection+0xc2/0xd0 [ 49.559028] ? asm_exc_invalid_op+0x1a/0x20 [ 49.559031] ? exc_control_protection+0xc2/0xd0 [ 49.559033] ? exc_control_protection+0x6e/0xd0 [ 49.559034] asm_exc_control_protection+0x26/0x30 [ 49.559036] RIP: 0010:0x9ba544c4e460 [ 49.559037] Code: 89 da 5b 41 5c 41 5d 5d e9 2d 05 fb ff 48 83 c4 28 b8 8e f8 ff ff 5b 41 5c 41 5d 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 <55> 48 8d 35 98 7b 1d 00 48 89 e5 41 54 49 89 fc 53 e8 7a 11 fb ff [ 49.559038] RSP: 0018:9ba5451fbd80 EFLAGS: 00010286 [ 49.559039] RAX: 9ba544c4e460 RBX: 9ba5480f1010 RCX: [ 49.559040] RDX: RSI: 8d3dc5bda9c0 RDI: 8d3e70710c10 [ 49.559041] RBP: 9ba5451fbdd0 R08: 0024 R09: 0001 [ 49.559041] R10: 8d452f7b9df8 R11: 0002 R12: [ 49.559042] R13: c5f01320 R14: 0004 R15: 8d3e70710c10 [ 49.559045] ? supdrvIOCtl+0x2d52/0x31d0 [vboxdrv] [ 49.559066] ? _copy_from_user+0x4a/0x60 [ 49.559070] ? VBoxDrvLinuxIOCtl_7_0_8+0x162/0x260 [vboxdrv] [ 49.559082] ? __x64_sys_ioctl+0x91/0xd0 [ 49.559085] ? do_syscall_64+0x5c/0xc0 [ 49.559086] ? fpregs_assert_state_consistent+0x26/0x50 [ 49.559089] ? exit_to_user_mode_prepare+0x40/0x1d0 [ 49.559092] ? syscall_exit_to_user_mode+0x1b/0x40 [ 49.559094] ? do_syscall_64+0x6b/0xc0 [ 49.559095] ? fpregs_assert_state_consistent+0x26/0x50 [ 49.559096] ? exit_to_user_mode_prepare+0x40/0x1d0 [ 49.559098] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 49.559100] [ 49.559100] Modules linked in: ctr ccm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c nfnetlink br_netfilter bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm snd_seq_dummy snd_hrtimer snd_seq overlay qrtr cmac algif_hash algif_skcipher af_alg bnep binfmt_misc nvidia_drm(POE) nvidia_modeset(POE) x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi coretemp kvm_intel kvm nls_ascii nls_cp437 irqbypass vfat dell_laptop rapl fat nvidia(POE) dell_wmi snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp iwlmvm snd_sof hci_uart snd_ctl_led btusb snd_hda_codec_realtek snd_sof_utils btqca snd_soc_hdac_hda btrtl snd_hda_ext_core btbcm btintel snd_soc_acpi_intel_match btmtk snd_hda_codec_generic snd_soc_acpi mac80211 ledtrig_audio bluetooth snd_soc_core snd_compress soundwire_bus [ 49.559145] snd_hda_intel snd_usb_audio snd_intel_dspcfg snd_intel_sdw_acpi libarc4 uvcvideo mei_hdcp mei_pxp snd_hda_codec mei_wdt snd_usbmidi_lib videobuf2_vmalloc uvc snd_hda_core snd_rawmidi videobuf2_memops videobuf2_v4l2 iwlwifi intel_rapl_msr pmt_telemetry snd_seq_device snd_hwdep pmt_class jitterentropy_rng snd_pcm
Bug#1038607: digikam: Creating new tag in captions menu reports it already exists
Package: digikam Version: 4:7.9.0-1+b2 Severity: minor Dear Maintainer, Using "captions" menu in order to complete IPTC and XMP metadata, I had to create a new tag in the existing list. After typing the word and validating with "enter", a popup windows appeared with a warning about already created and existing tag. But it was really a new tag because not proposed by the auto-completing menu. After acknowledging the warning, the tag had been created. It looks like a kind of "false postive warning" always active for each new tag. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages digikam depends on: ii digikam-data 4:7.9.0-1 ii digikam-private-libs 4:7.9.0-1+b2 ii libc6 2.36-9 ii libgcc-s1 12.2.0-14 ii libkf5configcore5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libmagick++-6.q16-8 8:6.9.11.60+dfsg-1.6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui55.15.8+dfsg-11 ii libqt5sql55.15.8+dfsg-11 ii libqt5sql5-mysql 5.15.8+dfsg-11 ii libqt5sql5-sqlite 5.15.8+dfsg-11 ii libqt5widgets55.15.8+dfsg-11 ii libstdc++612.2.0-14 ii perl 5.36.0-7 Versions of packages digikam recommends: ii chromium [www-browser] 114.0.5735.133-1~deb12u1 ii ffmpegthumbs 4:22.12.3-1 ii firefox-esr [www-browser] 102.12.0esr-1~deb12u1 ii konqueror [www-browser]4:22.12.3-1 ii lynx [www-browser] 2.9.0dev.12-1 Versions of packages digikam suggests: ii breeze-icon-theme 4:5.103.0-1 pn digikam-doc ii systemsettings 4:5.27.5-2 -- no debconf information
Bug#1000072: libapache2-mod-qos: depends on obsolete pcre3 library
Hi all, Currently, libapache2-mod-qos is still at 11.63 in stable and unstable although the latest release version is 11.74 from early May 2023 available at SF.net. I hope that our great packet maintainer Sergey finds some time to build an updated version, because many users depend on a working version of mod_qos as part of bookworm. Thanks in advance for your efforts! Matthieu On Tue, 16 May 2023 09:07:51 +0200 Stefan Baier wrote: > Package: libapache2-mod-qos > Version: 11.63-1+b2 > Followup-For: Bug #172 > X-Debbugs-Cc: tech...@planet-ic.de > > Apache mod_qos is in default bookworm sources still not useable > out-of-the-box. > If module is loaded, the daemon is not able to start and throws an error > depending > the mod_qos library: > "[…] mod_qos.so: undefined symbol: pcre_free […]" > > Purging the old pcre version is not possible, due to the dependency to > libapache2-mod-qos. > > > -- System Information: > Debian Release: 12.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libapache2-mod-qos depends on: > ii apache2-bin [apache2-api-20120211] 2.4.57-2 > ii libapr1 1.7.2-3 > ii libaprutil1 1.6.3-1 > ii libc6 2.36-9 > ii libpcre32:8.39-15 > ii libpng16-16 1.6.39-2 > ii libssl3 3.0.8-1 > ii zlib1g 1:1.2.13.dfsg-1 > > libapache2-mod-qos recommends no packages. > > libapache2-mod-qos suggests no packages. > > -- no debconf information
Bug#1036243: gwenview: Gwenview crashes opening certain JPEG files
Package: gwenview Version: 4:20.12.3-2 Severity: normal Dear Maintainer, Since a last update (I do not know which), Gwenview crashes with "old" JPEG (before 2017). It crashes everytime before browsing files in a folder. Here is what is visible in terminal : user@pc:~$ gwenview org.kde.kdegraphics.gwenview.lib: Unresolved mime type "image/x-mng" org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type "image/x-nikon-nrw" org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type "image/x-samsung- srw" terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at: __n (which is 19) >= this->size() (which is 19) KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = gwenview path = /usr/bin pid = 227715 KCrash: Arguments: /usr/bin/gwenview KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi [2]+ Stoppé gwenview user@pc:~$ QSocketNotifier: Invalid socket 8 and type 'Read', disabling... QSocketNotifier: Invalid socket 10 and type 'Read', disabling... QSocketNotifier: Invalid socket 13 and type 'Read', disabling... QSocketNotifier: Invalid socket 17 and type 'Read', disabling... 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. /tmp/drkonqi.lMIzOS:2: Error in sourced command file: No symbol "s_kcrashErrorMessage" in current context. [2]+ Stoppé gwenview I remain available if you need more tests or a sample file. Regards, Matthieu -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-23-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gwenview depends on: ii kinit 5.78.0-2 ii kio5.78.0-5 ii libc6 2.31-13+deb11u6 ii libcfitsio93.490-3 ii libexiv2-270.27.3-3+deb11u2 ii libgcc-s1 10.2.1-6 ii libjpeg62-turbo1:2.0.6-4 ii libkf5activities5 5.78.0-2 ii libkf5baloo5 5.78.0-3 ii libkf5completion5 5.78.0-3 ii libkf5configcore5 5.78.0-4 ii libkf5configgui5 5.78.0-4 ii libkf5configwidgets5 5.78.0-2 ii libkf5coreaddons5 5.78.0-4 ii libkf5filemetadata35.78.0-2 ii libkf5i18n55.78.0-2 ii libkf5iconthemes5 5.78.0-2 ii libkf5itemmodels5 5.78.0-2 ii libkf5itemviews5 5.78.0-2 ii libkf5jobwidgets5 5.78.0-2 ii libkf5kdcraw5 20.12.0-1 ii libkf5kiocore5 5.78.0-5 ii libkf5kiofilewidgets5 5.78.0-5 ii libkf5kiowidgets5 5.78.0-5 ii libkf5kipi32.0.0 4:20.12.1-1 ii libkf5notifications5 5.78.0-2 ii libkf5parts5 5.78.0-3 ii libkf5purpose-bin 5.78.0-2 ii libkf5purpose5 5.78.0-2 ii libkf5service-bin 5.78.0-2 ii libkf5service5 5.78.0-2 ii libkf5solid5 5.78.0-2 ii libkf5widgetsaddons5 5.78.0-2 ii libkf5xmlgui5 5.78.0-2 ii liblcms2-2 2.12~rc1-2 ii libphonon4qt5-44:4.11.1-4 ii libpng16-161.6.37-3 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5dbus55.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5printsupport55.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5x11extras5 5.15.2-2 ii libstdc++6 10.2.1-6 ii libtiff5 4.2.0-1+deb11u4 ii libx11-6 2:1.7.2-1 ii perl 5.32.1-4+deb11u2 ii phonon4qt5 4:4.11.1-4 Versions of packages gwenview recommends: ii kamera 4:20.12.0-1 ii kio-extras 4:20.12.2-1 ii qt5-image-formats-plugins 5.15.2-2
Bug#1031417: spamass-milter tags all DKIM signed mails as DKIM_INVALID due to CRLF issue in headers (working patch available)
Package: spamass-milter
Version: 0.4.0-2
Referring to the discussion at
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7785, it is still unclear
whether this bug will be fixed in Mail::DKIM or in spamassassin 4.0.
For the time being, I have tested the patch provided by Henrik Krohns
(https://savannah.nongnu.org/bugs/download.php?file_id=48244) attached to bug
report "#57626: Folded headers not keeping CRLF newlines”
(https://savannah.nongnu.org/bugs/index.php?57626) to spamass-milter 0.4.0-2.
It works and the milter reports DKIM status correctly.
Would be great if you could integrate the patch “header_crlf” to
debian/patches/series.
header_crlf:
Description: Spamass-milter doesn't properly maintain CRLF in folded header
newlines.
Origin: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7785
Bug: #7785
Author: Henrik Krohns, Matthieu Schapranow
mailto:schapra...@hpi.de>>
Forwarded: no
--- a/spamass-milter.cpp
+++ b/spamass-milter.cpp
@@ -1206,7 +1206,23 @@ mlfi_header(SMFICTX* ctx, char* headerf,
assassin->set_subject(headerv);
// assemble header to be written to SpamAssassin
- string header = string(headerf) + ": " + headerv + "\r\n";
+ string header = headerv;
+
+ // Replace all LF with CRLF
+ // As milter documentation says:
+ // headervHeader field value. The content of the header may
+ // include folded white space, i.e., multiple lines with following
+ // white space where lines are separated by LF (not CR/LF). The
+ // trailing line terminator (CR/LF) is removed.
+ // Need to make sure folded header line breaks are sent to SA as CRLF
+ string::size_type idx = header.size();
+ while ( (idx = header.rfind("\n", idx)) != string::npos )
+ {
+ header.replace(idx,1,"\r\n");
+ }
+
+ // final assembly
+ header = string(headerf) + ": " + header + "\r\n";
try {
// write to SpamAssassin client
Thanks,
Matthieu Schapranow
Bug#1020549: usrmerge: dpkg fatal error, duplicate file in /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/, during usrmerge package setup
Package: usrmerge Version: 31 Severity: normal During an "apt full-upgrade", the usrmerge package was installed for the first time on my system. During package setup, it immediately fails with the following message: > Setting up usrmerge (31) ... > > FATAL ERROR: > Both /lib/x86_64-linux-gnu/libpng12.so.0 and > /usr/lib/x86_64-linux-gnu/libpng12.so.0 exist. > > You can try correcting the errors reported and running again > /usr/lib/usrmerge/convert-usrmerge until it will complete without errors. > Do not install or update other Debian packages until the program > has been run successfully. > > E: usrmerge failed. > dpkg: error processing package usrmerge (--configure): > installed usrmerge package post-installation script subprocess returned > error exit status 1 > Errors were encountered while processing: > usrmerge I don't know what to do -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'stable-security'), (700, 'testing'), (700, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages usrmerge depends on: ii libfile-find-rule-perl 0.34-2 ii perl5.34.0-5 usrmerge recommends no packages. usrmerge suggests no packages. -- no debconf information
Bug#1020331: protocols: add Linux specific internal ones: RAW and MPTCP
Hi Marco,
Thank you for your reply!
On 21/09/2022 12:25, Marco d'Itri wrote:
> On Sep 20, Matthieu Baerts wrote:
>
>> Would it be acceptable to add Linux specific "internal" protocols in
>> /etc/protocols?
> If they never appear on the wire then I am not sure.
> Do tools like ss show them?
For MPTCP, it doesn't appear on the wire but the protocol number is used
when creating a socket:
fd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);
That's what was acceptable to do for Network Linux maintainers.
The protocol number is also used when listing connections.
'ss' is probably not a good example because it has already been patched
to list MPTCP sockets. Also, they use an internal function to convert
the protocol number to a name:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=9c3be2c0eee01be7832b7900a8be798a19c659a5
But other tools listing sockets might use getprotobynumber() to display
a name instead of a number (if they don't fail because MPTCP is not
supported by getprotobynumber() on Debian so far).
>> Still, having them in /etc/protocols will help programs using
>> getprotobyname() or getprotobynumber() like Perl and others are doing to
>> support these protocols but also to display the proper info about them.
> Can you point me to real world code?
The one that triggered the opening of this bug report is when we looked
at providing an example of using MPTCP in Perl. For TCP, a socket is
typically created like this (c.f. "man perlipc"):
socket(my $sock, PF_INET, SOCK_STREAM, getprotobyname("tcp"));
For MPTCP, it is not possible to use...
getprotobyname("mptcp")
... if /etc/protocols has not been updated. Instead, it is required to
define a tuple which is different from the usual way and a bit "dirty".
Regarding real world code, I'm not a Perl dev but that seems to be quite
common to do that, see:
https://codesearch.debian.net/search?q=getprotobyname%28%22tcp%22%29=1
https://github.com/search?q=getprotobyname%28%22tcp%22%29=code
It looks like a way of coding with Perl because they also do something
similar when trying to find which port to use, e.g.:
my $port = getservbyname "http", "tcp";
I don't know if there are programs having an option to use a protocol
defined in a config as a string, e.g. "tcp". Maybe some rely on
getprotobyname(), maybe others use hardcoded values.
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
Bug#1020331: protocols: add Linux specific internal ones: RAW and MPTCP
Package: netbase Version: 6.3 Severity: wishlist Dear Maintainer, Would it be acceptable to add Linux specific "internal" protocols in /etc/protocols? RAW (IPPROTO_RAW = 255) and MPTCP (IPPROTO_MPTCP = 262) are not protocol numbers defined by the IANA but they are used by the Linux kernel. RAW has been there for a very long time. MPTCP has been introduced in kernel 5.6. These two protocol numbers will not be visible on the wire. For MPTCP, the TCP protocol number will be used on the wire but there is a need to create MPTCP sockets. Still, having them in /etc/protocols will help programs using getprotobyname() or getprotobynumber() like Perl and others are doing to support these protocols but also to display the proper info about them. Would it then be acceptable to add them to the list? Or at least the MPTCP one as it is what I'm working on in the Linux kernel? :) Cheers, Matt -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.9 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#1016996: libnl-3-200-udeb: uninstallable, depends on non-udeb sgml-base
Hi Cyril, On 12/08/2022 01:33, Cyril Brulebois wrote: > Hi Matthieu, > > Matthieu Baerts (2022-08-11): >> Thank you for having CCed me, provided a fix so quickly and for the >> detailed explanations! Sorry, I didn't notice the regression when >> testing on my side. > > Absolutely no problems; it's easy to spot things when some daily build > breaks, much easier than spotting all the changes in a set of 18 binary > packages which tend to hardcode a strict dependency toward sibling > packages… Thank you! :-) >> Do we need to revert your workaround when #1015263 will be fixed? If >> yes, are you tracking this issue and planning to do the revert or do >> you prefer if someone else looks at that? > > At the moment, I didn't think that far ahead… First things first: I hope > this issue doesn't become more widespread, so I'm hoping debhelper gets > a fix sooner than later. If more hotfixes like this are needed, I'll > probably plan on tracking individual changes to coordinate reverts. In > the meanwhile, if you could take care of cancelling that change in that > particular package when the time comes, that'd be awesome! Otherwise, I > do have sticky notes and a large desk, I can deal with it. :) OK, yes, no issue for me, I just subscribed to the debhelper bug (#1015263) and I will revert the modification in debian/rules when needed. Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1016996: libnl-3-200-udeb: uninstallable, depends on non-udeb sgml-base
Hi Cyril, On 11/08/2022 02:00, Cyril Brulebois wrote: > Package: libnl-3-200-udeb > Version: 3.7.0-0.1 > Severity: grave > Tags: d-i patch > Justification: renders package unusable > X-Debbugs-Cc: Matthieu Baerts , Adam Borowski > , debian-b...@lists.debian.org > > Hi Matthieu, hi Adam, > > The set of packages you uploaded contains uninstallable udebs, as they > depend on sgml-base, which doesn't exist in the installer context > (there's no udeb for it. Current dependencies are as follows: > > $ dpkg --info libnl-3-200-udeb_3.7.0-0.1_amd64.udeb|grep Depends > Depends: sgml-base (>= 1.28), libc6-udeb (>= 2.34) > > $ dpkg --info libnl-genl-3-200-udeb_3.4.0-1+b1_amd64.udeb|grep Depends > Depends: libnl-3-200-udeb (= 3.4.0-1+b1), libc6-udeb (>= 2.28) > > This leads to the following build failure for the daily builds of the > installer: > > The following packages have unmet dependencies: > libnl-3-200-udeb : Depends: sgml-base (>= 1.28) but it is not installable > libnl-genl-3-200-udeb : Depends: sgml-base (>= 1.28) but it is not > installable > E: Unable to correct problems, you have held broken packages. > > (Note that I'm filing this bug report against only one of those udebs.) > > This is not your fault, that's debhelper's #1015263: > https://bugs.debian.org/1015263 > > but I thought I'd loop you in so that you know about this issue, and > about my current plan: the installer team (X-D-Cc'd) doesn't require an > immediate fix, but since I'm not sure when the debhelper bug is getting > fixed (and packages binNMU'd), I thought I'd prepare a workaround to > make sure this source package isn't a blocker when we plan for a Debian > Installer release. Thank you for having CCed me, provided a fix so quickly and for the detailed explanations! Sorry, I didn't notice the regression when testing on my side. Do we need to revert your workaround when #1015263 will be fixed? If yes, are you tracking this issue and planning to do the revert or do you prefer if someone else looks at that? Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1016363: fix for fvwm
XCheckIfEvent() holds the X display lock and the predicate
function it calls is not allowed to call any Xlib function that
would re-enter the lock.
libX11 1.8.1 enables X display locks unconditionnaly (it was only
enabled by XInitThreads() when called explicitely before) and
thus exposes the issue.
So don't process events in the FCheckPeekIfEvent() predicate, but
instead use a separate handler that is called for the returned event
out of the lock.
---
fvwm/events.c | 9 -
libs/FEvent.c | 22 ++
libs/FEvent.h | 8
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index ae179d62..72d85707 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -267,6 +267,12 @@ static int _pred_weed_accumulate_expose(
return 1;
}
+static int _pred_weed_is_expose(
+ Display *display, XEvent *event, XPointer arg)
+{
+ return (event->type == Expose);
+}
+
static int _pred_weed_handle_expose(
Display *display, XEvent *event, XPointer arg)
{
@@ -4546,7 +4552,8 @@ void handle_all_expose(void)
saved_event = fev_save_event();
FPending(dpy);
- FWeedIfEvents(dpy, _pred_weed_handle_expose, NULL);
+ FWeedAndHandleIfEvents(dpy, _pred_weed_is_expose,
+ _pred_weed_handle_expose, NULL);
fev_restore_event(saved_event);
return;
diff --git a/libs/FEvent.c b/libs/FEvent.c
index f3bf54d3..7e062118 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -534,6 +534,28 @@ int FWeedIfEvents(
return weed_args.count;
}
+int FWeedAndHandleIfEvents(
+ Display *display,
+ int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+ int (*handler) (Display *display, XEvent *event, XPointer arg),
+ XPointer arg)
+{
+ _fev_weed_args weed_args;
+ XEvent e;
+
+ assert(fev_is_invalid_event_type_set);
+ memset(_args, 0, sizeof(weed_args));
+ weed_args.weed_predicate = weed_predicate;
+ weed_args.arg = arg;
+ if (FCheckPeekIfEvent(display, , _fev_pred_weed_if,
+ (XPointer)_args)) {
+ handler(display, , arg);
+ }
+ _fev_pred_weed_if_finish(_args);
+
+ return weed_args.count;
+}
+
int FWeedIfWindowEvents(
Display *display, Window window,
int (*weed_predicate) (
diff --git a/libs/FEvent.h b/libs/FEvent.h
index ecfb164c..f17ac5e9 100644
--- a/libs/FEvent.h
+++ b/libs/FEvent.h
@@ -114,6 +114,14 @@ int FWeedIfEvents(
Display *display, XEvent *current_event, XPointer arg),
XPointer arg);
+/* Same as FWeedIfEvents but with a second callback out of XLockDisplay()
+ * to handle events in a lock-safe manner */
+int FWeedAndHandleIfEvents(
+ Display *display,
+ int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+ int (*handler) (Display *display, XEvent *event, XPointer arg),
+ XPointer arg);
+
/* Same as FWeedIfEvents but weeds only events for the given window. The
* weed_predicate is only called for events with a matching window. */
int FWeedIfWindowEvents(
--
2.37.1
This is: https://github.com/fvwmorg/fvwm3/pull/683
--
Matthieu Herrb
Bug#1016867: RFS: libnl3/3.7.0-0.1 [NMU] -- library for dealing with netlink sockets - generic netlink
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libnl3": * Package name: libnl3 Version : 3.7.0-0.1 Upstream Author : Thomas Haller * URL : https://github.com/thom311/libnl * License : LGPL-2.1 License * Vcs : / Section : net The source builds the following binary packages: libnl-3-200 - library for dealing with netlink sockets libnl-cli-3-200 - library for dealing with netlink sockets - cli helpers libnl-utils - Utilities for dealing with netlink sockets libnl-genl-3-200 - library for dealing with netlink sockets - generic netlink libnl-idiag-3-200 - library for dealing with netlink sockets - inetdiag interface libnl-nf-3-200 - library for dealing with netlink sockets - netfilter interface libnl-route-3-200 - library for dealing with netlink sockets - route interface libnl-xfrm-3-200 - library for dealing with netlink sockets - package transformations libnl-3-dev - development library and headers for libnl-3 libnl-cli-3-dev - development library and headers for libnl-cli-3 libnl-genl-3-dev - development library and headers for libnl-genl-3 libnl-idiag-3-dev - development library and headers for libnl-genl-3 libnl-nf-3-dev - development library and headers for libnl-nf-3 libnl-route-3-dev - development library and headers for libnl-route-3 libnl-xfrm-3-dev - development library and headers for libnl-xfrm-3 libnl-3-200-dbg - debug symbols for libnl3 libnl-3-200-udeb - library for dealing with netlink sockets libnl-genl-3-200-udeb - library for dealing with netlink sockets - generic netlink To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libnl3/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libn/libnl3/libnl3_3.7.0-0.1.dsc Changes since the last upload: libnl3 (3.7.0-0.1) unstable; urgency=low . * Non-maintainer upload (Closes: #1016485) * Again for this NMU, modifications have been limited to: - Symbols have been updated - Patches have been refreshed Like for the previous NMU upload I did for this package that seems no longer maintained, I did the minimal changes. I contacted the maintainer a week ago and I didn't get any replies. Please note that for the previous update (v3.5.0), I didn't have any replies from the official maintainer even after one year, see ticket #983310. Also, I didn't notified the MIA like I did last time because I guess there is no need to insist but feel free to tell me if this is still needed. The last version in Debian is the v3.5.0 while the latest upstream one -- v3.7.0 -- has been one month ago, a few months after the v3.6.0. This lib is used by a bunch of apps to communicate with the Linux kernel. The 3.7.0 version adds some new features but it also fixes bugs. libnl devs don't seem to maintain any stable branches for this project. This packages has a few lintian issues but if I'm not mistaken, no new ones compared to the previous version. Because it is a NMU and the situation is unclear with the official maintainer, these old lintian issues have not been addressed. Thank you for your help and your contributions to Debian! Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1016485: libnl3: please upgrade to release 3.7.0
Source: libnl3 Version: 3.5.0-0.1 Severity: wishlist Tags: upstream Dear Maintainer, Upstream has released two new versions this year: 3.6.0 and 3.7.0. Is it possible to upgrade to the latest one to get the new features and bug fixes please? Kind regards, Matt
Bug#1010246: dibbler-client: dibbler is splitting a /60 into 2 /68 preventing RA from being able
Package: dibbler-client
Version: 1.0.1-1.1
Severity: normal
Tags: patch
Dear Maintainer,
When you run dibbler-client and configure it to request a prefix
delegation and receive a /60 and want it to be split on 2 interfaces,
the current version of dibbler as packaged by Debian will create 2 /68
prefixes. Because of this you can't use router announcement as an easy
way to get IPv6 configured on the interfaces.
For instance:
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00::/60 to all
interfaces (prefix will be split to /68 prefixes if necessary).
^^^
21:35 Client Info PD: Using 2 suitable interface(s):eth2.10 eth2.30
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00:9000::/68 on the
eth2.10/9 interface.
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00:7000::/68 on the
eth2.30/7 interface.
It turns out that upstream code for dibbler-client has already a better
solution with this this commit:
https://github.com/tomaszmrugalski/dibbler/commit/41fa1dbc148331ec1a465ee3be449cf37d05943a
It would be great to fix this in the patched version of dibbler.
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dibbler-client depends on:
ii cdebconf [debconf-2.0] 0.260
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u3
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii ucf 3.0043
Versions of packages dibbler-client recommends:
pn dibbler-doc
ii resolvconf 1.87
dibbler-client suggests no packages.
-- debconf information:
* dibbler-client/start: true
* dibbler-client/options: dns
* dibbler-client/interfaces: eth1
dibbler-client/title:
diff -ur dibbler-1.0.1.bak/ClntIfaceMgr/ClntIfaceMgr.cpp
dibbler-1.0.1/ClntIfaceMgr/ClntIfaceMgr.cpp
--- dibbler-1.0.1.bak/ClntIfaceMgr/ClntIfaceMgr.cpp 2015-07-30
14:35:53.0 -0700
+++ dibbler-1.0.1/ClntIfaceMgr/ClntIfaceMgr.cpp 2022-04-26 22:18:09.259630252
-0700
@@ -433,6 +433,21 @@
return modifyPrefix(iface, prefix, prefixLen, 0, 0, PREFIX_MODIFY_DEL,
params);
}
+/// Returns number of bits required to store specific number of interfaces
+///
+/// @param i
+/// @return ceil(log2(i)) or 0 for 0
+int TClntIfaceMgr::numBits(int i) {
+int bits = 0;
+if (i == 0) {
+return (0);
+} else {
+i--;
+}
+while (i >>= 1) { ++bits; }
+return (bits + 1);
+}
+
bool TClntIfaceMgr::modifyPrefix(int iface, SPtr prefix, int
prefixLen,
unsigned int pref, unsigned int valid,
PrefixModifyMode mode,
@@ -562,66 +577,47 @@
stringstream prefix_split; // textual representation, used to pass as
script
for (TIfaceIfaceLst::const_iterator i=ifaceLst.begin(); i!=ifaceLst.end();
++i) {
-char buf[16];
-int subprefixLen;
-memmove(buf, prefix->getAddr(), 16);
-
-if (ifaceLst.size() == 1) {
-// just one interface - use delegated prefix as is
-subprefixLen = prefixLen;
-} else if (ifaceLst.size()<256) {
-subprefixLen = prefixLen + 8;
-int offset = prefixLen/8;
-if (prefixLen%8 == 0) {
-// that's easy, just put ID in the next octet
-buf[offset] = (*i)->getID();
-} else {
-// here's fun
-uint16_t existing = readUint16(buf+offset);
-uint16_t bitmask = 0xff00;
-uint16_t infixmask = ((uint8_t)(*i)->getID()) << 8;
-bitmask = bitmask >> (prefixLen%8);
-infixmask = infixmask >> (prefixLen%8);
-
-// clear out if there is anything there, i.e. server assigned
prefix
-// with garbage in host section
-existing = existing & (~bitmask);
-existing = existing | (bitmask & infixmask);
-writeUint16(buf+offset, existing);
-}
+int subprefixLen = 0;
-} else {
+int numPrefixes = ifaceLst.size();
+
+if (numPrefixes > 256) {
// users with too much time that play with virtual interfaces are
out of luck
Log(Error) << "Something is wrong. Detected more than 256
interface." << LogEnd;
return false;
}
-SPtr tmpAddr = new TIPv6Addr(buf, false);
+SPtr subprefix = calculateSubprefix(prefix, prefixLen,
+ numPrefixes,
Bug#1007937: hplip: Some of the print modes for DeskJet 815C are incorrectly defined
Package: hplip Version: 3.21.2+dfsg1-2 Severity: normal X-Debbugs-Cc: castet.matth...@free.fr Dear Maintainer, when printing in "Normal Grayscale" mode, I have the following error : "prnt/hpcups/Pcl3Gui.cpp 75: Requested resolution not supported with requested printmodeprnt/hpcups/HPCupsFilter.cpp" This seem to be solved by the patch present in https://bugs.launchpad.net/hplip/+bug/782706 Could it be applied in the next release ? -- Package-specific info: Saving output in log file: /home/mat/perso/photo/fb/branly/hp-check.log HP Linux Imaging and Printing System (ver. 3.21.2) Dependency/Version Check Utility ver. 15.1 Copyright (c) 2001-18 HP Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Note: hp-check can be run in three modes: 1. Compile-time check mode (-c or --compile): Use this mode before compiling the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper dependencies are installed to successfully compile HPLIP. 2. Run-time check mode (-r or --run): Use this mode to determine if a distro supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper dependencies installed to successfully run. 3. Both compile- and run-time check mode (-b or --both) (Default): This mode will check both of the above cases (both compile- and run-time dependencies). Check types: a. EXTERNALDEP - External Dependencies b. GENERALDEP - General Dependencies (required both at compile and run time) c. COMPILEDEP - Compile time Dependencies d. [All are run-time checks] PYEXT SCANCONF QUEUES PERMISSION Status Types: OK MISSING - Missing Dependency or Permission or Plug-in INCOMPAT - Incompatible dependency-version or Plugin-version warning: debian-11 version is not supported. Using debian-10.7 versions dependencies to verify and install... --- | SYSTEM INFO | --- Kernel: 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) GNU/Linux Host: flou Proc: 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) GNU/Linux Distribution: debian 11 Bitness: 64 bit --- | HPLIP CONFIGURATION | --- HPLIP-Version: HPLIP 3.21.2 HPLIP-Home: /usr/share/hplip warning: HPLIP-Installation: Auto installation is not supported for debian distro 11 version Current contents of '/etc/hp/hplip.conf' file: # hplip.conf. Generated from hplip.conf.in by configure. [hplip] version=3.21.2 [dirs] home=/usr/share/hplip run=/var/run ppd=/usr/share/ppd/hplip/HP ppdbase=/usr/share/ppd/hplip doc=/usr/share/doc/hplip html=/usr/share/doc/hplip-doc icon=no cupsbackend=/usr/lib/cups/backend cupsfilter=/usr/lib/cups/filter drv=/usr/share/cups/drv bin=/usr/bin apparmor=/etc/apparmor.d # Following values are determined at configure time and cannot be changed. [configure] network-build=yes libusb01-build=no pp-build=no gui-build=yes scanner-build=yes fax-build=yes dbus-build=yes cups11-build=no doc-build=yes shadow-build=no hpijs-install=yes foomatic-drv-install=yes foomatic-ppd-install=no foomatic-rip-hplip-install=no hpcups-install=yes cups-drv-install=yes cups-ppd-install=no internal-tag=3.21.2 restricted-build=no ui-toolkit=qt5 qt3=no qt4=no qt5=yes policy-kit=yes lite-build=no udev_sysfs_rules=no hpcups-only-build=no hpijs-only-build=no apparmor_build=no class-driver=no Current contents of '/var/lib/hp/hplip.state' file: Plugins are not installed. Could not access file: No such file or directory Current contents of '~/.hplip/hplip.conf' file: [commands] scan = /usr/bin/xsane -V %SANE_URI% [fax] email_address = voice_phone = [installation] date_time = 03/18/22 23:23:12 version = 3.21.2 [last_used] device_uri = "hp:/usb/DeskJet_815C?serial=HU98H1S0TJIE" printer_name = DESKJET-815C working_dir = . [polling] device_list = enable = false interval = 5 [refresh] enable = false rate = 30 type = 1 [settings] systray_messages = 0 systray_visible = 0 [upgrade] last_upgraded_time = 1643128514 notify_upgrade = false pending_upgrade_time = 0 - | External Dependencies | - error: cups
Bug#1005077: RFS: mptcpd/0.9-1 [ITP] -- Multipath TCP Daemon
Hi Bastian, Thank you for your reply! On 09/02/2022 16:02, Bastian Germann wrote: > On Sun, 6 Feb 2022 22:17:46 +0100 Matthieu Baerts > wrote: >> Package: sponsorship-requests >> Severity: wishlist >> >> Dear mentors, >> >> I am looking for a sponsor for my package "mptcpd": >> >> * Package name : mptcpd >> Version : 0.9-1 >> Upstream Author : mp...@lists.linux.dev >> * URL : https://github.com/intel/mptcpd >> * License : BSD-3-Clause, GPL-2.0+, PERMISSIVE, >> __AUTO_PERMISSIVE__ >> * Vcs : https://gitlab.com/matttbe/mptcpd-debian > > I suggest using Debian's Gitlab instance salsa for this. > I can make your repo available as https://salsa.debian.org/debian/mptcpd > and give you permissions when you tell me your handle. I I created an account a few days ago but it is still pending approval and hence blocked. I don't know if I missed something. This why I pushed my modification on this repo for the moment. My username is matttbe. Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1005133: RFS: libnl3/3.5.0-0.1 [NMU] -- library for dealing with netlink sockets - generic netlink
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libnl3": * Package name: libnl3 Version : 3.5.0-0.1 Upstream Author : Thomas Haller * URL : https://github.com/thom311/libnl * License : LGPL-2.1 License * Vcs : / Section : net It builds those binary packages: libnl-cli-3-dev - development library and headers for libnl-cli-3 libnl-genl-3-dev - development library and headers for libnl-genl-3 libnl-idiag-3-dev - development library and headers for libnl-genl-3 libnl-nf-3-dev - development library and headers for libnl-nf-3 libnl-route-3-dev - development library and headers for libnl-route-3 libnl-xfrm-3-dev - development library and headers for libnl-xfrm-3 libnl-3-200-dbg - debug symbols for libnl3 libnl-3-200-udeb - library for dealing with netlink sockets libnl-genl-3-200-udeb - library for dealing with netlink sockets - generic netlink libnl-3-200 - library for dealing with netlink sockets libnl-cli-3-200 - library for dealing with netlink sockets - cli helpers libnl-utils - Utilities for dealing with netlink sockets libnl-genl-3-200 - library for dealing with netlink sockets - generic netlink libnl-idiag-3-200 - library for dealing with netlink sockets - inetdiag interface libnl-nf-3-200 - library for dealing with netlink sockets - netfilter interface libnl-route-3-200 - library for dealing with netlink sockets - route interface libnl-xfrm-3-200 - library for dealing with netlink sockets - package transformations libnl-3-dev - development library and headers for libnl-3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libnl3/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libn/libnl3/libnl3_3.5.0-0.1.dsc Changes since the last upload: libnl3 (3.5.0-0.1) unstable; urgency=low . * Non-maintainer upload (Closes: #983310): * For this NMU, modifications have been limited to: - Symbols have been updated - Patches have been refreshed I really did the minimal changes here for this package that seems no longer maintained. I contacted the maintainer a year ago and again a few weeks ago but I never got any replies. I notified the MIA a week ago. The last version in Debian is the v3.4.0 while the latest upstream one -- v3.5.0 -- has been released in 2019. This lib is used by a bunch of apps to communicate with the Linux kernel. The 3.5.0 version adds some new features but it also fixes bugs, some can be considered as important, e.g. avoiding a crash in some cases. This packages has a few lintian issues but if I'm not mistaken, no new ones compared to the previous version. Because it is a NMU and the situation is unclear with the official maintainer, these old lintian issues have not been addressed. Regards, -- Matthieu Baerts -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#1005077: RFS: mptcpd/0.9-1 [ITP] -- Multipath TCP Daemon
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mptcpd": * Package name: mptcpd Version : 0.9-1 Upstream Author : mp...@lists.linux.dev * URL : https://github.com/intel/mptcpd * License : BSD-3-Clause, GPL-2.0+, PERMISSIVE, __AUTO_PERMISSIVE__ * Vcs : https://gitlab.com/matttbe/mptcpd-debian Section : net It builds those binary packages: mptcpd - Multipath TCP Daemon libmptcpd3 - Multipath TCP Daemon Library libmptcpd3-dev - Multipath TCP Daemon Library - Development files libmptcpd3-doc - Multipath TCP Daemon Library - documentation mptcpd-plugins - Multipath TCP Daemon Plug-ins mptcpize - Multipath TCP Converter libmptcpwrap0 - Multipath TCP Converter Library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mptcpd/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mptcpd/mptcpd_0.9-1.dsc Changes for the initial release: mptcpd (0.9-1) unstable; urgency=low . * Initial release. Closes: #1005012 Regards, -- Matthieu Baerts
Bug#1005012: ITP: mptcpd -- Multipath TCP Daemon
Package: wnpp Severity: wishlist Owner: Matthieu Baerts X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mptcpd Version : 0.9 Upstream Author : Ossama Othman * URL : https://github.com/intel/mptcpd * License : BSD-3-Clause Programming Lang: C Description : Multipath TCP Daemon The Multipath TCP Daemon - mptcpd - is a daemon for Linux based operating systems that performs Multipath TCP path management related operations in the user space. It interacts with the Linux kernel through a generic Netlink connection to track per-connection information (e.g. available remote addresses), available network interfaces, request new MPTCP subflows, handle requests for subflows, etc. Why is this package useful/relevant? MPTCP support is available in the Linux kernel since v5.6. The work on the kernel side is still in progress: https://github.com/multipath-tcp/mptcp_net-next/wiki This userspace daemon is useful to configure a host to support Multipath TCP: it interacts with the kernel to track and request MPTCP-related features. How do you plan to maintain it? I'm part of the Linux MPTCP Upstream Project team, mostly working on the kernel side. But here, I'm also helping to package this software. We have regular meetings to follow up on different aspects linked to this project. We then keep track of mptcpd development as well which should help to maintain it. I don't know if this package would fit into an existing team. mptcpd is fairly standard and is not really complex to package. Do you need a sponsor? I will need a mentor as even if it is not the first time I'm packaging softwares for Debian/Ubuntu, it is the first time I'm going to send the initial version of a package for Debian.
Bug#911997: git: Apply diff from Ubuntu
Hello, On 15/09/2019 04:55, Anders Kaseorg wrote: > Never mind, it looks like I wasn’t added to the Debian upload ACL, so my > upload was rejected. Sorry to jump into this discussion but it looks like the "git" package in Ubuntu is still different from the one in Debian. It looks like everything is/was ready but it was not applied for some reasons. Is there anything blocking to apply this diff from Ubuntu? Is there something I can do to help? Cheers, Matt PS: oops, it looks like I accidentally sent the previous draft of this message, pressing "Send" instead of "Save", sorry for that... The week is starting well... :) -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#911997: git: Apply diff from Ubuntu
On 15/09/2019 04:55, Anders Kaseorg wrote: > Never mind, it looks like I wasn’t added to the Debian upload ACL, so my > upload was rejected. > > Anders > > -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
I'm running Bullseye, and the bug is still present, despite having bash 5. $ cat /etc/debian_version 11.1 $ dpkg -l console-setup bash Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii bash 5.1-2+b3 amd64GNU Bourne Again SHell ii console-setup 1.205all console font and keymap setup program -- Matthieu
Bug#977367: debsources: search results point to not existing sources?
On Wed, Apr 28, 2021 at 10:40:54PM +0200, Michael Stapelberg wrote: > > Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has > > been open forever, so I think it's quite unlikely it's gonna be picked > > up within a reasonable timeframe. I myself won't have time to take > > care of this anytime soon. > > > > I can empathize regarding not having enough time, but just want to point > out that the change itself ended up being quite simple in terms of lines of > code and mental complexity: > https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d > — as you can see, we just loop over *.tar.* and call “tar xf”. > > I’m not saying this to push you to implement it, just mentioning this for > your information should you eventually get around to it :) Thank you very much! CCing the original bug for reference, might come handy sooner or later. :) Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#977367: debsources: search results point to not existing sources?
Hi Michael, On Sun, Apr 11, 2021 at 10:41:10AM +0200, Michael Stapelberg wrote: > We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80 > (from 2017!), > but apparently didn’t think it through far enough regarding sources.d.o :) Thanks for your answer! And I think we can reasonably assume this edge case doesn't happen too often. :) > Would adding support for unpacking tarballs be something you would consider > in debsources? > I know that tarballs *technically are the source*, but humans clearly find > the contents of these tarballs more interesting. Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has been open forever, so I think it's quite unlikely it's gonna be picked up within a reasonable timeframe. I myself won't have time to take care of this anytime soon. > Otherwise, we could handle these with our own /show handler by checking if > the source is present in debsources first, > but that obviously involves one additional request per /show handler, so > it’s not exactly cheap. That'd work indeed. Doing nothing also sounds like a reasonable strategy, given the (assumed) low rate of this failure and the efforts involved to implement a work-around. But I'm glad we know where that comes from. Thanks for your thoughts! Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#977367: debsources: search results point to not existing sources?
Control: usertag -1 debsources Control: merge 761077 -1 Hi Tomas, On Mon, Dec 14, 2020 at 02:13:49PM +0100, Tomas Pospisek wrote: > Go to > https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server > select first link > https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go=1798 > get a 404 with a list of 12 alternative source files of different > versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go > each returning a 404. > > I have now clicked through quite a few links to source files, but > have yet to find one that won't return a 404...? > > Maybe the search index would need to be purged of source files that > have disappeared (been updated) or something? Thank you very much for the detailed bug report, and apologies for the delay in getting back to you. After further inspection, it turns out the tarball containing the source for gcc-10 contains embedded tarballs. See http://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.2.1.orig.tar.xz and https://sources.debian.org/src/gcc-10/10.2.0-3/ Debsources unpacked the first tarball, and the embedded ones are technically the "source" of gcc-10. The path you obtained from codesearch.debian.net points to a file inside the tarball inside the tarball; this is unfortunately not supported by sources.d.o. I didn't know codesearch supported this feature. CCing Michael, in case you have an idea on how not to point to sources.d.o for code results originating from unpacked archives. :) Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#983310: libnl3: Upgrade to version 3.5.0
Source: libnl3 On Mon. 22 feb. 2021 at 11:18, Matthieu Baerts wrote: > > Package: libnl3 Arf, my bad, I didn't see reportbug used "Package" instead of "Source" because I disabled all my deb-src on this system. I hope that's not a big issue but I can re-submit if needed. Cheers, Matt
Bug#983310: libnl3: Upgrade to version 3.5.0
Package: libnl3 Version: 3.5.0 Severity: normal Dear libnl3 Maintainer, I just noticed libnl3 on Debian (and Ubuntu) was a bit outdated. The last upstream version is the v3.5.0 released in 2019 but Debian still has the previous one (v3.4.0). This v3.5.0 contains a bunch of fixes and new features: https://github.com/thom311/libnl/compare/libnl3_4_0...libnl3_5_0 e.g. the PR #199 avoid crashes. Is there anything blocking to switch to this version 3.5.0? Or are you looking for help on this one? On my side, I manually compiled this new version but I guess it is better if everybody can easily get it to avoid issues (crashes) and enjoy some new features. Cheers, Matt
Bug#964609: pyxdg: Proposed solution for pyxdg test failure and ftbfs
Package: pyxdg
Version: 0.26-3
Followup-For: Bug #964609
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch
Dear Maintainer,
While reviewing GCC10 FTBFS with ubuntu 20.10 Groovy, I worked on pyxdg failure.
After reproducing the failure in a sbuild environment I noticed that this wasn't
a ftbfs issue but more likely an issue introduced with python 3.8.4
In Python 3.8.4 rc1, Custom AST constant naming became more strict and raised
ValueError when True, False and Node are used within a ast.Name node [1]
After some research I found a similar issue reported here [2] and inspired from
it to write a solution for pyxdg
This patch has been submitted for groovy and is in proposed. This test failure
was also blocking nose to migrate from proposed which shoudl now be able to
migrate to groovy devel
* Fix compatibility issue with python 3.8.4 (Closes: #964609, #968399)
Thanks for considering the patch.
Matthieu
[1] https://bugs.python.org/issue40870
[2] https://github.com/nestorsalceda/mamba/pull/151
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-42-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pyxdg-0.26/debian/patches/python384compat.diff
pyxdg-0.26/debian/patches/python384compat.diff
--- pyxdg-0.26/debian/patches/python384compat.diff 1969-12-31
18:00:00.0 -0600
+++ pyxdg-0.26/debian/patches/python384compat.diff 2020-08-12
17:41:44.0 -0500
@@ -0,0 +1,57 @@
+Description: Fix Pytyhon 3.8.4 compatibility Issue
+ Starting with Python 3.8.4 rc1, Custom AST constant naming became more strict
+ and raised ValueError when True, False and Noe are used within a ast.Name
node
+ Solution inspired from https://github.com/nestorsalceda/mamba/pull/151
+Author: Matthieu Clemenceau
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964609
+Last-Update: 2020-08-17
+
+--- pyxdg-0.26.orig/xdg/Menu.py
pyxdg-0.26/xdg/Menu.py
+@@ -21,6 +21,8 @@ import os
+ import locale
+ import subprocess
+ import ast
++import sys
++
+ try:
+ import xml.etree.cElementTree as etree
+ except ImportError:
+@@ -34,6 +36,17 @@ from xdg.util import PY3
+ import xdg.Locale
+ import xdg.Config
+
++def _ast_const(name):
++# fixes compat issue with python 3.8.4+
++# c.f https://github.com/pytest-dev/pytest/issues/7322
++if sys.version_info >= (3, 4):
++name = ast.literal_eval(name)
++if sys.version_info >= (3, 8):
++return ast.Constant(name)
++else:
++return ast.NameConstant(name)
++else:
++return ast.Name(id=name, ctx=ast.Load())
+
+ def _strxfrm(s):
+ """Wrapper around locale.strxfrm that accepts unicode strings on Python 2.
+@@ -763,7 +776,8 @@ class XMLMenuBuilder(object):
+ if expr:
+ tree.body = expr
+ else:
+-tree.body = ast.Name('False', ast.Load())
++#tree.body = ast.Name('False', ast.Load())
++tree.body = _ast_const('False')
+ ast.fix_missing_locations(tree)
+ return Rule(type, tree)
+
+@@ -790,7 +804,7 @@ class XMLMenuBuilder(object):
+ expr = self.parse_bool_op(node, ast.Or())
+ return ast.UnaryOp(ast.Not(), expr) if expr else None
+ elif tag == 'All':
+-return ast.Name('True', ast.Load())
++return _ast_const('True')
+ elif tag == 'Category':
+ category = node.text
+ return ast.Compare(
diff -Nru pyxdg-0.26/debian/patches/series pyxdg-0.26/debian/patches/series
--- pyxdg-0.26/debian/patches/series2020-03-27 09:30:55.0 -0500
+++ pyxdg-0.26/debian/patches/series2020-08-12 17:41:44.0 -0500
@@ -2,3 +2,4 @@
set-default-menu.patch
gettext-support.patch
test_mime_skip_symlink.patch
+python384compat.diff
Bug#968034: xidle: introduction of setsid() call introduces undocumented behaviour changes
On Fri, Aug 07, 2020 at 09:41:01PM +, Thorsten Glaser wrote: > Marcel Partap dixit: > > >in my user .tmux.conf, I have put following mechanism > > This is a very complex setup; I cannot easily reproduce what exactly > makes this fail for you. > > >https://www.mail-archive.com/tech@openbsd.org/msg49105.html > > As I said in my earlier mail, this patch combines multiple changes > and is… tricky. > > Matthieu, can you have a look at it as well as the change > http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/xidle/xidle.c.diff?r1=1.3=1.4 > possibly introducing the problem for our user? Hi, I'm currently on vacation. I will look at this when I come back later next week. > > I’m seeing multiple things here: > > • closing stdout and stderr: I agree with that output should go > to .xsession-errors (if open) and would remove that, redirecting > only stdin from /dev/null > > • using execvp: this makes me cringe, both the change and the > current code also. I’d propose introducing two new ways of > specifying the command to run. One would take one argument, > like -program does, but actually run sh -c (with > shell interpolation, pipes, I/O redirection, etc. possible); > the other (probably a double dash) would collect all remaining > arguments and create an argument vector from them (whitespace- > safe), perhaps with an -argv0 option (like exec -a in some shells) > and retire -program entirely (or keep it for a while but document > it as deprecated, to avoid breaking users right now) > > • calling setsid(2): is this deliberate? What are the effects of > doing so vs. not doing so for the programs run? > > If this is deliberate, perhaps we can introduce a -keepsession > flag that would omit the call to setsid(2) only, for use cases > like Marcel’s. > > >noticed the introduction of a setsid() call, which seem to be the source of > >the > > Are you sure about this? That is, if you locally recompile xidle with > just the call to setsid removed, does your scenatio work? > > Thanks, > //mirabilos > -- > (gnutls can also be used, but if you are compiling lynx for your own use, > there is no reason to consider using that package) > -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL -- Matthieu Herrb
Bug#959138: nipy: resolve nipy autopkgtest failure due to numpy testing decorators
Source: nipy
Followup-For: Bug #959138
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch
Dear Maintainer,
While working on numpy proposed-migration for groovy, I realize nipy
autopkgtest was failing. It appears that numpy changed the pass to the
module decorators from numpy.testing.decorators to
numpy.testing._private.decorators.
In Ubuntu, the attached patch was applied allowing nipy to pass autopkg
test and migrate from groovy-proposed to groovy.
The Changelog below was added to nipy-0.4.2-3ubuntu1
* Resolved test failure due to numpy 1:1.18.4-1. (Closes: #959138)
Thanks for considering the patch.
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-29-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Fix Autopkgtest failure caused by the new numpy 1:1.18.4-1
Author: Matthieu Clemenceau
Origin: vendor
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959138#5
Forwarded: yes
Last-Update: 2020-05-15
--- a/nipy/algorithms/clustering/tests/test_vmm.py
+++ b/nipy/algorithms/clustering/tests/test_vmm.py
@@ -13,7 +13,7 @@
select_vmm_cv)
from nose.tools import assert_true, assert_equal
-from numpy.testing import decorators
+from numpy.testing._private import decorators
from nibabel.optpkg import optional_package
--- a/nipy/algorithms/diagnostics/tests/test_screen.py
+++ b/nipy/algorithms/diagnostics/tests/test_screen.py
@@ -23,7 +23,8 @@
from nose.tools import (assert_true, assert_false, assert_equal, assert_raises)
from numpy.testing import (assert_array_equal, assert_array_almost_equal,
- assert_almost_equal, decorators)
+ assert_almost_equal)
+from numpy.testing._private import decorators
from nipy.testing import funcfile
from nipy.testing.decorators import needs_mpl_agg
--- a/nipy/fixes/numpy/testing/nosetester.py
+++ b/nipy/fixes/numpy/testing/nosetester.py
@@ -21,7 +21,7 @@
Examples
->>> from numpy.testing import nosetester
+>>> from numpy.testing._private import nosetester
>>> nosetester.get_package_name('nonsense')
'numpy'
--- a/nipy/testing/decorators.py
+++ b/nipy/testing/decorators.py
@@ -8,7 +8,7 @@
from __future__ import print_function
from __future__ import absolute_import
-from numpy.testing.decorators import *
+from numpy.testing._private.decorators import *
from nipy.utils import templates, example_data, DataError
--- a/nipy/tests/test_scripts.py
+++ b/nipy/tests/test_scripts.py
@@ -19,7 +19,9 @@
from nose.tools import assert_true, assert_false, assert_equal, assert_raises
from ..testing import funcfile
-from numpy.testing import decorators, assert_almost_equal
+
+from numpy.testing._private import decorators
+from numpy.testing import assert_almost_equal
from nipy.testing.decorators import make_label_dec
Bug#940939: Bug
On Sunday, September 22, 2019 9:24:58 PM CEST you wrote: > Hello, > > Sorry for the confusion, the fix proposal is in https://phabricator.kde.org/ > D24147 . > > Best regards https://phabricator.kde.org/D24147 has landed in master branch of Kirigami2
Bug#940939: Bug
Hello, Sorry for the confusion, the fix proposal is in https://phabricator.kde.org/ D24147 . Best regards
Bug#940939: Upstream
Hello, I have open https://phabricator.kde.org/D22974 to propose a solution. Best regards
Bug#940939: More info
Hello, This is a Kirigami2 issue. I am trying to find a solution upstream. Please move it to this package. It may be a good idea to change the severity given that all applications using Kirigam2 are broken. Best regards
Bug#933294: Kernel quirks on QNAP TS-109 (Marvell orion)
Le 02/08/2019 à 10:58, Arnaud Patard (Rtp) a écrit : > Hi, > > Martin Michlmayr writes: > >> * Arnaud Patard [2019-07-29 14:45]: >>> As promised, please fix the updated patch. Please note that there are 2 >> Can you submit it upstream for review, or if you have already, send us >> a link. > Sorry for the delay. I was waiting for some feedback before sending and > then got busy with other stuff. I've now sent it: > https://marc.info/?l=linux-netdev=156473570707976=2. > > Arnaud That's awesome, thank you Arnaud :) About the qcontrol-related issues, I have a conjecture you guys might be experienced enough to debunk (or confirm), I also noticed that the TS-109 fails to shutdown properly, either using systemd or sysvinit (After "[ 243.405182] qnap_tsx09_power_off: triggering power-off...", it panic()'s with systemd getting killed, and stalls without powering off, and with sysvinit it simply stalls) After some quick research, it seems that both qcontrol related stuff (buzzer, leds, ...) and shutting down are handled by the NAS PIC, available through proprietary kernel stuff on stock QNAP kernel and through GPIO / ttyS1,19200n8 on vanilla ones. I get some: ---8<--- [ 44.325898] synth uevent: /gpiochip0: failed to send uevent [ 44.325949] gpio gpiochip0: uevent: failed to send synthetic uevent ---8<--- In dmesg during boot, which I suspect means that something is wrong in GPIO / PIC communication. I tried to replicate the way Linux shuts the NAS down (send 'A' over ttyS1,19200n8) and nothing happened, neigher shutdown or line echo. Are there known ways for the PIC access to be broken, is this specific to my NAS (but QTS seems to work fine with it) or maybe a regression specific to TS-X09 ? Thanks for your time. -- Matthieu CERDA
Bug#933298: qcontrold systemd unit possible typo
Package: qcontrol Version: 0.5.6-4~bpo9+1 Severity: important Tags: patch Hello maintainer! There seems to be a small typo, related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781886, in the qcontrold systemd unit. The unit depends on: /dev/input/by-path/platform-gpio_keys-event The actual file to watch for seems to be: /dev/input/by-path/platform-gpio-keys-event Here's a patch: ---8<--- --- a/lib/systemd/system/qcontrold.service 2018-05-27 12:00:11.0 +0200 +++ b/etc/systemd/system/qcontrold.service 2019-07-28 21:22:34.048521392 +0200 @@ -1,7 +1,7 @@ [Unit] Description=qcontrold -Requires=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device -After=dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device +Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device +After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device # If the config file is there, we assume qcontrol works on this machine. ConditionPathExists=/etc/qcontrol.conf ---8<--- Thank you! -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armel (armv5tel) Kernel: Linux 4.19.0-0.bpo.5-marvell Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qcontrol depends on: ii libc62.24-11+deb9u4 ii liblua5.1-0 5.1.5-8.1+b2 ii udev 232-25+deb9u11 qcontrol recommends no packages. qcontrol suggests no packages. -- no debconf information
Bug#933294: qcontrol fails to do anything on QNAP TS-109
Package: qcontrol Version: 0.5.6-4~bpo9+1 Severity: important Greetings, package maintainer! I am running a QNAP TS-109 NAS on Debian, and post installation I noticed that qcontrol seemed not to work properly: the NAS does not beep post-boot, and the status led stays red/green blinking. Trying to use qcontrol directly outputs no error, but does nothing: ---8<--- root@vault:~# qcontrol --direct statusled greenon Register evdev on /dev/input/by-path/platform-gpio-keys-event confdir: loading from /etc/qcontrol.d... (no led change) root@vault:~# qcontrol --direct buzzer short Register evdev on /dev/input/by-path/platform-gpio-keys-event confdir: loading from /etc/qcontrol.d... (no buzzer sound) ---8<--- It looks like it might be a kernel-related problem, as I can see in dmesg: ---8<--- root@vault:~# dmesg|grep gpio [ 21.616406] synth uevent: /gpiochip0: failed to send uevent [ 21.616455] gpio gpiochip0: uevent: failed to send synthetic uevent [ 31.732294] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 34.725122] synth uevent: /gpiochip0: failed to send uevent [ 34.725173] gpio gpiochip0: uevent: failed to send synthetic uevent ---8<--- -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armel (armv5tel) Kernel: Linux 4.19.0-0.bpo.5-marvell Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qcontrol depends on: ii libc62.24-11+deb9u4 ii liblua5.1-0 5.1.5-8.1+b2 ii udev 232-25+deb9u11 qcontrol recommends no packages. qcontrol suggests no packages. -- no debconf information
Bug#932403: emacs-gtk: Running helm-ucs command (package helm-unicode) leads to emacs crash
Package: emacs-gtk Version: 1:26.1+1-3.2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? - Installed emacs-gtk - Added MELPA in the package repositories - Installed helm-unicode * What exactly did you do (or not do) that was effective (or ineffective)? - when issueing "helm-ucs" -> emacs just crashes - I uninstalled emacs, and installed it with nixpkgs (nix-env): this version does not have the problem *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-gtk depends on: ii emacs-bin-common 1:26.1+1-3.2 ii emacs-common 1:26.1+1-3.2 ii libacl12.2.53-4 ii libasound2 1.1.8-1 ii libatk1.0-02.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-31.12.16-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgif75.1.4-3 ii libglib2.0-0 2.58.3-2 ii libgnutls303.6.7-4 ii libgomp1 8.3.0-6 ii libgpm21.20.7-5 ii libgtk-3-0 3.24.5-1 ii libice62:1.0.9-2 ii libjpeg62-turbo1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libm17n-0 1.8.0-2 ii libmagickcore-6.q16-6 8:6.9.10.23+dfsg-2.1 ii libmagickwand-6.q16-6 8:6.9.10.23+dfsg-2.1 ii libotf00.9.13-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-01.42.4-6 ii libpng16-161.6.36-6 ii librsvg2-2 2.44.10-2.1 ii libselinux12.8-1+b1 ii libsm6 2:1.2.3-1 ii libsystemd0241-5 ii libtiff5 4.0.10-4 ii libtinfo6 6.1+20181013-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb12:1.6.7-1 ii libxcb11.13.1-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxft22.3.2-2 ii libxinerama1 2:1.1.4-2 ii libxml22.9.4+dfsg1-7+b3 ii libxpm41:3.5.12-1 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii zlib1g 1:1.2.11.dfsg-1 emacs-gtk recommends no packages. Versions of packages emacs-gtk suggests: pn emacs-common-non-dfsg -- no debconf information
Bug#928544: debsources: wheezy gone missing
Hi Jakub, On Mon, May 06, 2019 at 09:58:28PM +0200, Jakub Wilk wrote: > Some (all?) wheezy packages have disappeared from sources.d.o. Thank you for catching that. We failed to take the necessary measures to prevent wheezy from disappearing from debsources after it disappeared from the mirrors. I'm now re-adding the packages, which takes some time to process. Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#818792: qa.debian.org: improve license rendering
Hi Ryan, On Fri, Jun 15, 2018 at 08:28:22AM +0800, Ryan wrote: > Am I missing something or do the links in the report no longer seem to appear > as > reported. Could you please provide more details? Are the links missing on a particular URL? Thanks, -- Matthieu
Bug#898074: Confirming that it seems to be solved
With 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07), the problem disappeared from two different laptops that where affected. Seems like it is fixed. -- Matthieu Dubuget
Bug#898074: Maybe some more information on this bug
I experience the same problem (and got around it by reverting to linux-image-4.9.0-5-amd64). In my case, the problem does not prevent gdm3 to start: it just take a vry looong time (around 5 min). I reproduced it on a freshly installed (with Debian 9.4) computer. -- Matthieu Dubuget
Bug#895253: ITP: elisa -- Simple music player with a focus on Plasma desktop integration and privacy
Hello, I would like to clarify the local versus online music features in Elisa. We plan to first focus on very good support for local music before trying to support online services. Local music was the focus of the 0.1 version and will probably be also the focus of the next version. I have started looking at online services and most of the popular ones no longer provide a simple way to use them outside their clients. We will need time to add support for them. We would also want to add support for MusicBrainz for example even if again the priority is to first support correctly local music before adding support for that. Best regards -- Matthieu Gallien
Bug#854545: dvb-usb not working with kernel compiled from linux-source-4.9.2-2~bpo8+1
Package: src:linux Version: 4.9.82-1+deb9u3 Followup-For: Bug #854545 Dear Maintainer, with the current kernel, my DVB-T adaptater no longer work. It seems related to the error "transfer buffer not dma capable". Regards -- Package-specific info: ** Version: Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=426ca88b-4a62-4386-ba38-2dc4aa367bed ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 11.281807] dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in warm state. [ 11.281935] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 11.286085] DVB: registering new adapter (LITE-ON USB2.0 DVB-T Tuner) [ 12.292699] [ cut here ] [ 12.292729] WARNING: CPU: 3 PID: 29 at /build/linux-YDazDa/linux-4.9.82/drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x394/0x590 [usbc ore] [ 12.292730] transfer buffer not dma capable [ 12.292731] Modules linked in: dvb_usb_dibusb_mc dvb_usb_dibusb_mc_common dvb_usb_dibusb_common hid_generic dib3000mc dibx000_common dvb_usb dvb_core rc_core usbhid hid intel_powerclamp coretemp kvm_intel amdkfd kvm radeon snd_hda_codec_realtek snd_hda_codec_generic irqbypass snd_hda_ intel snd_hda_codec snd_hda_core iTCO_wdt iTCO_vendor_support ttm snd_hwdep hp_wmi sparse_keymap rfkill drm_kms_helper evdev snd_pcm drm serio_r aw i2c_algo_bit pcspkr crct10dif_pclmul snd_timer crc32_pclmul snd ghash_clmulni_intel intel_cstate intel_uncore soundcore shpchp button lpc_ich mfd_core mei_me mei sg wmi tpm_infineon acpi_cpufreq sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_gener ic fscrypto ecb mbcache sr_mod cdrom sd_mod crc32c_intel aesni_intel ahci aes_x86_64 glue_helper [ 12.292811] lrw gf128mul libahci ablk_helper cryptd libata psmouse ehci_pci ehci_hcd scsi_mod e1000e usbcore ptp usb_common pps_core [ 12.292830] CPU: 3 PID: 29 Comm: kworker/3:0 Not tainted 4.9.0-6-amd64 #1 Debian 4.9.82-1+deb9u3 [ 12.292832] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.05 06/09/2010 [ 12.292845] Workqueue: usb_hub_wq hub_event [usbcore] [ 12.292846] ac92e074 b92080d7b550 [ 12.292848] ac6776be 8ffd8e7b1d80 b92080d7b5a8 [ 12.292849] b92080d7b76c 8ffd8d5f5000 0002 ac67773f [ 12.292851] Call Trace: [ 12.292856] [] ? dump_stack+0x5c/0x78 [ 12.292859] [] ? __warn+0xbe/0xe0 [ 12.292861] [] ? warn_slowpath_fmt+0x5f/0x80 [ 12.292863] [] ? lock_timer_base+0x74/0x90 [ 12.292869] [] ? usb_hcd_map_urb_for_dma+0x394/0x590 [usbcore] [ 12.292870] [] ? try_to_del_timer_sync+0x4d/0x80 [ 12.292875] [] ? usb_hcd_submit_urb+0x34d/0xaf0 [usbcore] [ 12.292877] [] ? del_timer_sync+0x50/0x50 [ 12.292878] [] ? list_del+0x9/0x30 [ 12.292884] [] ? usb_start_wait_urb+0xaa/0x170 [usbcore] [ 12.292889] [] ? usb_start_wait_urb+0x6d/0x170 [usbcore] [ 12.292892] [] ? dvb_usb_generic_rw+0x157/0x1c0 [dvb_usb] [ 12.292894] [] ? dibusb_i2c_msg+0xcf/0x130 [dvb_usb_dibusb_common] [ 12.292896] [] ? dibusb_i2c_xfer+0x129/0x140 [dvb_usb_dibusb_common] [ 12.292898] [] ? __i2c_transfer+0x10e/0x3e0 [ 12.292899] [] ? dvb_usb_start_feed+0x10/0x10 [dvb_usb] [ 12.292901] [] ? dvb_usb_fe_sleep+0x50/0x50 [dvb_usb] [ 12.292902] [] ? i2c_transfer+0x5d/0xc0 [ 12.292904] [] ? dib3000mc_read_word+0x9a/0x100 [dib3000mc] [ 12.292905] [] ? dib3000mc_identify+0x14/0x100 [dib3000mc] 12.292907] [] ? dib3000mc_attach+0x68/0x460 [dib3000mc] [ 12.292908] [] ? dibusb_dib3000mc_frontend_attach+0x4b/0x150 [dvb_usb_dibusb_mc_common] [ 12.292910] [] ? dvb_usb_adapter_frontend_init+0xe6/0x190 [dvb_usb] [ 12.292911] [] ? dvb_usb_device_init+0x4e9/0x660 [dvb_usb] [ 12.292917] [] ? usb_probe_interface+0x162/0x2c0 [usbcore] [ 12.292919] [] ? driver_probe_device+0x223/0x430 [ 12.292920] [] ? __driver_attach+0xe0/0xe0 [ 12.292923] [] ? bus_for_each_drv+0x64/0xb0 [ 12.292924] [] ? __device_attach+0xd9/0x150 [ 12.292925] [] ? bus_probe_device+0x8a/0xa0 [ 12.292927] [] ? device_add+0x36b/0x620 [ 12.292932] [] ? usb_set_configuration+0x5c8/0x8c0 [usbcore] [ 12.292938] [] ? generic_probe+0x28/0x80 [usbcore] [ 12.292939] [] ? driver_probe_device+0x223/0x430 [ 12.292940] [] ? __driver_attach+0xe0/0xe0 [ 12.292941] [] ? bus_for_each_drv+0x64/0xb0 [ 12.292942] [] ? __device_attach+0xd9/0x150 [ 12.292943] [] ? bus_probe_device+0x8a/0xa0 [ 12.292945] [] ? device_add+0x36b/0x620 [ 12.292950] [] ? usb_new_device+0x263/0x470 [usbcore] [ 12.292955] [] ? hub_event+0xbfc/0x15c0 [usbcore] [ 12.292957] [] ? process_one_work+0x18a/0x420 [ 12.292958] [] ? worker_thread+0x4d/0x490 [ 12.292959] [] ?
Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling
Hi, On Mon, Dec 18, 2017 at 11:05:28AM +0800, Boyuan Yang wrote: > See also the attached image (the same). > > The scrollbar will disappear if I set "overflow-y: hidden" to the pre tag > highlighted in the screenshot. Thanks for the screenshot. I failed to reproduce it or understand where the scrollbar comes from. I also notice an horizontal scrollbar below the code that is not supposed to be there. Since the element or its parents don't have any height set, there shouldn't be a scrollbar. While I don't mind applying this CSS hack, I'd prefer to fix this properly. Are you using any extension that might change how the elements are displayed, or any parameter I'm not aware of that could have an impact? Thanks in advance, -- Matthieu signature.asc Description: PGP signature
Bug#890076: PTS: broken "browse source code" links
Hi, On Sat, Feb 10, 2018 at 09:56:03PM +0100, Jakub Wilk wrote: > On <https://packages.qa.debian.org/d/dash.html>, "browse source code" points > to <https://sources.debian.org/src/dash/unstable/>, which is 404. Sounds like a debsources bug, however it doesn't 404 for me, it redirects correctly to <https://sources.debian.org/src/dash/0.5.8-2.10/>. Maybe it was a temporary glitch, is it still broken for you? Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#819013: debsources: deduplicate the html setting the background image
Hi, On Sun, Jan 21, 2018 at 06:43:41PM +0100, pixthor wrote: > i know that this bug is a little bit outdated, but i'd like to tackle it > anyway. You're very welcome to do that! Don't hesitate to join #debian-debsources on irc if you have any question. Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#874003: nautilus: Nautilus does not launch applications
Well, this fix is nice, but has the side-effect that now when opening a place (such as Home, Desktop, Document), or invoking my file manager with my Ctrl-Alt-E keyboard shortcut, it runs Thunar instead of Nautilus :-( I'm trying to see if I can get it to work correctly without having to uninstall xfce / thunar. Any help appreciated :-) cheers, On Sun, 14 Jan 2018 12:15:48 +0100 Matthieu Imbert <matthieu.imb...@inria.fr> wrote: Here's a more detailed fix: -- Matthieu
Bug#874003: nautilus: Nautilus does not launch applications
Here's a more detailed fix:
deleting ~/.config was not a very appealing fix for me since I don't
want to lost everything :-)
When double clicking a file in nautilus, it ends up calling "gio open".
stracing gio:
$ strace -f gio open 2>&1 | grep '\.config'
it shows that at some point an xfce4 helper file is read (I do have xfce
installed as well on my laptop):
stat("/home//.config/xfce4/helpers.rc", {st_mode=S_IFREG|0644,
st_size=41, ...}) = 0
this file contained the following lines:
FileManager=nautilus
MailReader=icedove
I moved away this file and it fixes the issue.
Anyway I don't know why, at some point, gio reads this xfce file, it
seems a bit strange.
For information here is the full ouput of
$ strace -f gio open 2>&1 | grep '\.config'
[pid 16711] access("/home//.config", R_OK|X_OK) = 0
[pid 16711] inotify_add_watch(7, "/home//.config",
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR
[pid 16711] openat(AT_FDCWD,
"/home//.config/gnome-mimeapps.list", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 16711] openat(AT_FDCWD, "/home//.config/mimeapps.list",
O_RDONLY) = 8
mkdir("/home//.config", 0700)= -1 EEXIST (File exists)
stat("/home//.config", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
stat("/home//.config/xfce4/helpers.rc", {st_mode=S_IFREG|0644,
st_size=41, ...}) = 0
openat(AT_FDCWD, "/home//.config/xfce4/helpers.rc", O_RDONLY) = 7
--
Matthieu
Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling
Control: user qa.debian@packages.debian.org Control: usertag -1 debsources signature.asc Description: PGP signature
Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling
Control: usertags -1 debsources Hi, On Thu, Dec 14, 2017 at 02:58:28PM +0800, Boyuan Yang wrote: > For any random page that shows the content of source code, there is an > unnecessary vertical scroll bar between the line number and the content of > source code. When the user put focus (e.g., by clicking the content of src), > the whole page will not be able to scroll up or down anymore till the user > moves the focus out the the webpage itself. > > I believe we could eliminate the vertical scroll bar completely and solves > this > problem. > > I'm using Debian unstable with Firefox 57. I tested Chromium and the page on > Chromium seems don't get affected by the problem. Thanks for reporting this bug. However I could not reproduce it, with either Firefox 57 or older. Could you maybe provide a screenshot, or try to identify the broken element/property through the inspector? Thanks, -- Matthieu signature.asc Description: PGP signature
Bug#874003: nautilus: Nautilus does not launch applications
On 10/10/2017 11:20 AM, Phil Wyett wrote: On Tue, 2017-10-10 at 09:42 +0200, Matthieu Imbert wrote: I confirm, same behavior for me since the upgrade nautilus:amd64 3.22.3-1 -> 3.25.92-1: - not opening files when double clicking or when right clicking and choosing the first entry "open with " (xxx being the default application) - workaround possible by right clicking, selecting "open with other application", then choosing any application (including the default one) Hi, The versions you are using are outdated. Can you update and retest? If the issue persists can you provide one or two document types/examples so others may try reproduce what you are experiencing. Regards Phil Actually I forgot to mention that I'm now using 3.26.0-1, and the behaviour is still the same. I also may have not been clear enough: It's not just on some particular documents: The inability to open a document occurs on every kind of document. So any document can be used to reproduce (any text file, image, music, pdf doc, etc.). I attach a simple text file example. If you cannot reproduce it it means there is some configuration difference between our environments, but I have no idea where to start searching. I don't know if it's relevant, but I'm using regular gnome, with a few extensions that make it behave more like traditional gnome 2, and I run in xorg (not wayland). Feel free to ask me whatever other details of my configuration that may be relevant to debug that issue. -- Matthieu lorem ipsum
Bug#874003: nautilus: Nautilus does not launch applications
I confirm, same behavior for me since the upgrade nautilus:amd64 3.22.3-1 -> 3.25.92-1: - not opening files when double clicking or when right clicking and choosing the first entry "open with " (xxx being the default application) - workaround possible by right clicking, selecting "open with other application", then choosing any application (including the default one) -- Matthieu
Bug#862058: python-debian: required dependency on python-apt
Control: reopen -1 Control: tags -1 + patch Hi Stuart, On Sun, Sep 10, 2017 at 01:47:22AM +1000, Stuart Prescott wrote: > That iter_paragraphs works with compressed indexes at all is somewhat > accidental. I don't believe it is documented anywhere that this is a > supported > use of iter_paragraphs. (But it's rather handy that it does work!) In fact, > the documentation says that iter_paragraphs accepts: > > sequence: a string, or any any object that returns a line of > input each time, normally a file. > > (not a compressed file). > > Further, my feeling is that if a user chooses to break a Recommends, they get > what is coming to them and policy is quite clear about that. Thanks for your explanation, I agree with your conclusions. > As a user of the iter_paragraphs (and other!) functions, if you are in a > position to add to the docstrings of these functions so that this contract is > more clear to programmer, then that would be greatly appreciated. Building > some API docs with sphinx is something we should aim for but at present, > there > is not nearly enough documentation to make that worthwhile. I attached a patch that adds a couple lines of doc. In the process I realised there was a deprecated example with shared_storage in a README, which I took the opportunity to remove. Cheers, -- Matthieu From 86df0a5b86ec44f07e4fa624d33a5a002a479359 Mon Sep 17 00:00:00 2001 From: Matthieu Caneill <m...@brokenwa.re> Date: Fri, 6 Oct 2017 21:47:35 +0200 Subject: [PATCH] deb822: add clarifications for iter_paragraphs with compressed files --- README.deb822| 6 ++ lib/debian/deb822.py | 4 +++- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.deb822 b/README.deb822 index 89e7d64..4480c87 100644 --- a/README.deb822 +++ b/README.deb822 @@ -68,10 +68,8 @@ For example: print src['Package'], src['Version'] This method uses python-apt if available to parse the file, since it -significantly boosts performance. The downside, though, is that yielded -objects share storage, so they should never be kept accross iterations. -To prevent this behavior, pass a "shared_storage=False" keyword-argument -to the iter_paragraphs() function. +significantly boosts performance. If python-apt is not present and the +file is a compressed file, it must first be decompressed manually. Sample usage (TODO: Improve) diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py index 26f4b68..84af3c2 100644 --- a/lib/debian/deb822.py +++ b/lib/debian/deb822.py @@ -313,7 +313,9 @@ class Deb822(Deb822Dict): :param sequence: a string, or any any object that returns a line of input each time, normally a file. Alternately, sequence can -be a dict that contains the initial key-value pairs. +be a dict that contains the initial key-value pairs. When +python-apt is present, sequence can also be a compressed object, +for example a file object associated to something.gz. :param fields: if given, it is interpreted as a list of fields that should be parsed (the rest will be discarded). -- 2.8.1 signature.asc Description: PGP signature
Bug#862058: python-debian: required dependency on python-apt
Package: python-debian Version: 0.1.28 Severity: normal Dear Maintainer, python-debian has a Recommends: dependency on python-apt, and a mechanism to import alternatives when it is not present. However, when using Sources.iter_paragraphs(f), with f being a file object of a compressed file (e.g. Sources.gz), python-debian will decompress the file when python-apt is present, and try to read the compressed file when it is not (and fail with an expected UnicodeDecode error). This affects all current versions. Cheers, -- Matthieu -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-debian depends on: ii python-chardet 2.3.0-2 ii python-six 1.10.0-3 pn python:any Versions of packages python-debian recommends: ii python-apt 1.1.0~beta4 Versions of packages python-debian suggests: ii gpgv 1.4.20-6 -- no debconf information signature.asc Description: PGP signature
Bug#861379: debsources: /patches/api/list/ contains packages with no patches (such as 0xffff)
Hi, On Fri, Apr 28, 2017 at 03:30:58PM +0800, Paul Wise wrote: > The debsources patches list API mentions the package 0x but this > package doesn't contain any patches according to the debsources website > and apt-file and downloading the source package. Thanks for the report. I'm not sure this is a bug. The /api/list endpoint was meant to list all packages, containing 0 or more patches. Orestis, any memory of this rationale? Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#861168: qa.debian.org: msg parameter inserts extra line numbers
Hi, On Tue, Apr 25, 2017 at 01:49:13PM -0400, James McCoy wrote: > When I view that URL, it looks as per your expectations. After > disabling Javascript, I see that the line numbers aren't adjusted. Thanks for the report and the additional information! I've dug it a bit, and it indeed comes from the fact the additional space needed between line numbers to align well (when a popup message is present) is done in javascript in debsources.js. A solution could be adding these empty lines server-side. It was the case before e246fcf, but it was needed to fix #762941… Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#856278: webfs: web_extraS : README.Debian exemple use $web_extra whereas /etc/init.d/webfs use $web_extras
Package: webfs Version: 1.21+ds1-12 Severity: normal Tags: patch In README.Debian, the config to enable SSL is $web_extra, but init script does not use this variable, bug $web_extras instead. The README.Debian file should be modified to match the init file. This bug exist in oldstable to unstable. patch : diff -uri webfs-1.21+ds1_orig/debian/README.Debian webfs-1.21+ds1/debian/README.Debian --- webfs-1.21+ds1_orig/debian/README.Debian2017-02-27 13:11:50.182758616 +0100 +++ webfs-1.21+ds1/debian/README.Debian 2017-02-27 13:12:28.514948695 +0100 @@ -25,7 +25,7 @@ - Recently the configuration file '/etc/webfsd.conf' was expanded to - include a Debconf entry "web_extra". This is suitable for activating + include a Debconf entry "web_extras". This is suitable for activating the HTTPS-server. Observe that each instance of Webfsd is able to serve either HTTP or HTTPS on a single port, not both protocols in a single server instance. @@ -33,9 +33,9 @@ Using an entry in '/etc/webfsd.conf' like (this file is sourced by the init-script at startup time) -web_extra="-S -C /etc/ssl/certs/webfsd.pem -K /etc/ssl/private/key.pem" -web_extra="$web_extra -A /etc/ssl/certs/webfsd-ca.pem" -web_extra="$web_extra -Q NORMAL:!AES-128-CBC" +web_extras="-S -C /etc/ssl/certs/webfsd.pem -K /etc/ssl/private/key.pem" +web_extras="$web_extras -A /etc/ssl/certs/webfsd-ca.pem" +web_extras="$web_extras -Q NORMAL:!AES-128-CBC" would enable HTTPS (using -S), with certificate (-C), key file (-K), CA-chain (-A), and would exclude the crypto method AES-128-CBC (-Q). -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages webfs depends on: ii debconf [debconf-2.0] 1.5.60 ii libc6 2.24-9 ii libgnutls303.5.8-3 ii lsb-base 9.20161125 ii ucf3.0036 webfs recommends no packages. webfs suggests no packages. -- debconf information excluded
Bug#850173: qa.debian.org: debsources: Please provide link from decorated patch view to download/raw view
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: debsources [Forwarding the message below, from Christoph Biedl, to BTS.] -- Matthieu Hello, the patch view at e.g. https://sources.debian.net/patches/vblade/23-1/manpage-escape-dash.patch/ adds some decoration to a patch, suitable for human inspection. It was nice if that page could contain a link to the raw view which is https://sources.debian.net/data/main/v/vblade/23-1/debian/patches/manpage-escape-dash.patch At the moment, you'd have to pick the version number from the breadcrumb to get the full patch, then identify the applicable one and click "download". While feasible, a shortcut as above would be of some help, espcially for people outside the Debian project, in my case: upstream. Christoph signature.asc Description: PGP signature
Bug#843250: qml-module-qtquick-controls is broken and breaks software using it
Package: qml-module-qtquick-controls Version: 5.7.1~20161021-2 Severity: important Since the last upload (5.7.1~20161021-2) it seems something is broken. plasmashell is giving me errors of type: file:///usr/lib/x86_64-linux- gnu/qt5/qml/QtQuick/Controls/Styles/Plasma/TextFieldStyle.qml:76: TypeError: Property 'hasOwnProperty' of object TextField_QMLTYPE_151(0x3aeed10) is not a function I have a software build locally (I rebuilt it agains current Qt) that is giving me the same type of errors: file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/ScrollView.qml:198: TypeError: Property 'hasOwnProperty' of object QQuickListView_QML_56(0x561fa9169fe0) is not a function file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/ScrollView.qml:198: TypeError: Property 'hasOwnProperty' of object QQuickListView_QML_56(0x561fa9321770) is not a function I believe bug #843208 is a symptom of this. Best regards (and by the way thanks for your work that is really appreciated). -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qml-module-qtquick-controls depends on: ii dpkg 1.18.10 ii libc6 2.24-5 ii libqt5core5a [qtbase-abi-5-7-1] 5.7.1~20161021+dfsg-5 ii libqt5gui55.7.1~20161021+dfsg-5 ii libqt5qml5 [qtdeclarative-abi-5-7-0] 5.7.1~20161021-4 ii libqt5quick5 5.7.1~20161021-4 ii libqt5widgets55.7.1~20161021+dfsg-5 ii libstdc++66.2.0-11 ii qml-module-qtgraphicaleffects 5.7.1~20161021-3 ii qml-module-qtquick-layouts5.7.1~20161021-4 ii qml-module-qtquick-window25.7.1~20161021-4 ii qml-module-qtquick2 5.7.1~20161021-4 qml-module-qtquick-controls recommends no packages. qml-module-qtquick-controls suggests no packages. -- no debconf information
Bug#839773: qa.debian.org: debsources: packages with upstream signature listed in .dsc are not added
Package: qa.debian.org Severity: important User: qa.debian@packages.debian.org Usertags: debsources debsources fails to unpack source packages, complaining on upstream signatures being listed in the .dsc: dpkg-source: error: unrecognized file for a v2.0 source package: libtool_2.4.6.orig.tar.xz.asc dpkg-source: info: extracting libtool in /srv/debsources/sources/main/libt/libtool/2.4.6-2 This is due to our outdated version of dpkg-source. Relevant discussion can be found at https://lists.debian.org/debian-dpkg/2016/05/msg00041.html Cheers, -- Matthieu -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature
Bug#835033: debsources: Retain line context on 404s by appending the hash for specific links
On Thu, Aug 25, 2016 at 03:27:28PM +0100, Chris Lamb wrote: > Has it been deployed yet? I don't see it on, for example: > > https://sources.debian.net/src/nostalgy/0.2.33-1/build.sh/#L75 It is now! Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#833394: wmweather: URL of data source has changed
On Thu 04.08.2016 at 10:20:17PM +0200, Cristian Ionescu-Idbohrn wrote: > On Wed, 3 Aug 2016, Matthieu Weber wrote: > > > > The URL of the source of the data used by wmweather has changed, > > causing the software to exit immediately upon start. > > > > The fix is trivial, and a patch is included. > > Yeah, I thought of that too. And tested (from strace): > > GET /pub/data/observations/metar/decoded/YBRM.TXT HTTP/1.1\r\nHost: > tgftp.nws.noaa.gov\r\nUser-Agent: wmweather 2.4.5\r\nAccept: > */*\r\n\r\n Remove the "/pub" in the beginning of the path, it shouldn't be there. This url works: http://tgftp.nws.noaa.gov/data/observations/metar/decoded/YBRM.TXT This one does not: http://tgftp.nws.noaa.gov/pub/data/observations/metar/decoded/YBRM.TXT > `wmfrog' manages to get somthing out, using some other url: > > http://weather.noaa.gov/mgetmetar.php?=YBRM Looks like a web page with the METAR data in it, but you then need to parse the HTML. > It seems `wmweather' can't handle redirections That is true, but I guess that the original URL is going to go out of comission at some point, so we would then face the same problem at that time, since wmweather cannot "learn" the new URL from the redirection. wmweather has been working fine for 36h with my patch, so it seems that the new URL has been working all this time. I'm quite happy with that solution, and I'll work on another one if there is ever a problem more complex than changing the URL. Matthieu -- (~._.~)Matthieu Weber - mwe...@free.fr (~._.~) ( ? )http://weber.fi.eu.org/( ? ) ()- -() public key id : 0x85CB340EFCD5E0B3 ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Otto J. Bierbaum)" (_)-(_)
Bug#833394: wmweather: URL of data source has changed
Package: wmweather
Version: 2.4.5-2
Severity: grave
Tags: upstream patch
Justification: renders package unusable
Dear Maintainer,
The URL of the source of the data used by wmweather has changed, causing
the software to exit immediately upon start.
The fix is trivial, and a patch is included.
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-1)
(ignored: LC_ALL set to en_US.iso88591)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages wmweather depends on:
ii libc62.19-18+deb8u4
ii libcurl3-gnutls 7.38.0-4+deb8u4
ii libx11-6 2:1.6.2-3
ii libxext6 2:1.3.3-1
ii libxpm4 1:3.5.11-1+b1
Versions of packages wmweather recommends:
ii x11-utils 7.7+2
Versions of packages wmweather suggests:
ii wmaker 0.95.5-2+b2
-- no debconf information
diff -Nru wmweather-2.4.5/debian/changelog wmweather-2.4.5/debian/changelog
--- wmweather-2.4.5/debian/changelog 2013-12-30 17:28:13.0 +0200
+++ wmweather-2.4.5/debian/changelog 2016-08-03 21:52:36.0 +0300
@@ -1,3 +1,10 @@
+wmweather (2.4.5-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Updated NOAA URL
+
+ -- Matthieu Weber <mwe...@free.fr> Wed, 03 Aug 2016 21:52:24 +0300
+
wmweather (2.4.5-2) unstable; urgency=low
* Updated build system.
diff -Nru wmweather-2.4.5/debian/patches/series wmweather-2.4.5/debian/patches/series
--- wmweather-2.4.5/debian/patches/series 1970-01-01 02:00:00.0 +0200
+++ wmweather-2.4.5/debian/patches/series 2016-08-03 21:52:50.0 +0300
@@ -0,0 +1 @@
+update-url.patch
diff -Nru wmweather-2.4.5/debian/patches/update-url.patch wmweather-2.4.5/debian/patches/update-url.patch
--- wmweather-2.4.5/debian/patches/update-url.patch 1970-01-01 02:00:00.0 +0200
+++ wmweather-2.4.5/debian/patches/update-url.patch 2016-08-03 21:53:29.0 +0300
@@ -0,0 +1,11 @@
+--- a/src/wmweather.c
b/src/wmweather.c
+@@ -62,7 +62,7 @@
+ static struct memory
+ header = {NULL, 0};
+ char
+- url[] = "http://weather.noaa.gov/pub/data/observations/metar/decoded/\0\0\0\0.TXT;,
++ url[] = "http://tgftp.nws.noaa.gov/data/observations/metar/decoded/\0\0\0\0.TXT;,
+ xtitle[]= "weather report for \0\0\0\0\0",
+ *station= NULL,
+ *report = NULL,
Bug#828831: debsources: merge all config files in the repo into an unique one
Hi John! Sorry for late reply. On Mon, Jul 18, 2016 at 01:07:13PM +0200, John Giannelos wrote: > I was wondering what's your opinion on moving towards a 12factor app > config structure on debsources [1]? In many of the web projects I am > involved we've been using python-decouple [2] for that. > > The idea is that you can separate configuration from code by having a > single config module with default settings (optional) that gets > overridden by values on each different env. These values can be defined > in either a local config file (eg. settings.ini or .env file) or as > environment variables. > > If you think that's a good way forward I would be interested to work on > that. python-decouple is not yet packaged for Debian but I am also > interested to help on that too. It looks really exciting! And honestly, perfectly answers the problem. :) I read the page you mentioned, but I'm not familiar with the tool. I suppose keeping the values in files is the way to proceed, since environment variables would have to be guessed/remembered somehow at every deploy, including the Docker one that we do every day on our dev machines. Also, keep in mind the current configuration files are read in many different places on the codebase (updater, webapp, etc), so it might incur many changes here and there. I would suggest to create an RFP or ITP bug for python-decouple. Unfortunately I doubt I'll have time to help on that front. However I will happily review any patch on debsources when we get to that. Thank you for working on this! Cheers, -- Matthieu signature.asc Description: PGP signature
Bug#828831: debsources: merge all config files in the repo into an unique one
Package: qa.debian.org Severity: normal Usertags: debsources Currently we have many config files around: - etc/config.ini, used for sources.d.n - contrib/docker/config.ini used for docker images - etc/config.travis.ini used for travis - doc/examples/sample-config.local.ini as a documentation example It is difficult to keep them up-to-date, and finding a way to have an unique one would make things easier. Cheers, -- Matthieu -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#761083: #761083 - debsources: inject binary packages metadata into the DB
On Fri, Jun 24, 2016 at 04:41:57PM +0200, Raphael Hertzog wrote: > > I don't mind at all you using sources.d.n for that purpose, but why > > not tracker.d.o? > > I thought the same when I saw this report... and the reason is likely that > the tracker has almost no REST API at all right now and that it thus looked > harder to implement there. Thanks for the clarification Raphael! Makes sense indeed to use debsources for that purpose. Cheers, -- Matthieu
Bug#761083: #761083 - debsources: inject binary packages metadata into the DB
y
> index c0e4583..468d28b 100644
> --- a/debsources/models.py
> +++ b/debsources/models.py
> @@ -207,8 +207,10 @@ class Binary(Base):
> ForeignKey('packages.id', ondelete="CASCADE"),
> index=True, nullable=False)
>
> -def __init__(self, version, area="main"):
> -self.version = version
> +def __init__(self, name_id, package_id, version=None):
> +self.version= version
> +self.name_id= name_id
> +self.package_id = package_id
>
> def __repr__(self):
> return self.version
Overall, looks really good! If you fix the (very small) comments and
add a test case I'll happily merge it.
Thanks for your work!
Cheers,
--
Matthieu
Bug#826770: libqt5network5: Backport fix for bug QTBUG-47011 in Qt 5.5.1
Package: libqt5network5 Version: 5.5.1+dfsg-17 Severity: wishlist Hello Dear maintainers, Could you please include fix for bug QTBUG-47011 in qtbase 5.5.1 in case you upload another package of version 5.5.1 ? Can you please close my bug report in case you only plan to upload 5.6.y >= 0 ? The fix is already in 5.6.0. Thanks in advance Best regards PS: Thanks for your work, I appreciate it. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqt5network5 depends on: ii libc62.22-11 ii libproxy1v5 0.4.11-5 ii libqt5core5a [qtbase-abi-5-5-1] 5.5.1+dfsg-17 ii libqt5dbus5 5.5.1+dfsg-17 ii libstdc++6 6.1.1-5 ii zlib1g 1:1.2.8.dfsg-2+b1 libqt5network5 recommends no packages. libqt5network5 suggests no packages. -- no debconf information
Bug#764961: debsources: port to Python 3
On Sun, 12 Oct 2014 17:40:45 +0200 Stefano Zacchiroli <z...@debian.org> wrote: > As per subject: please port Debsources to Python 3.x. To prevent duplicated efforts: I'm working on this! Cheers, -- Matthieu
Bug#820905: python-keyring: ImportError: No module named Gnome
This is probably because you hardcoded Gnome in Keyring configuration file, however that backend was removed in Keyring 8.x (moved to keyrings.alt package). The recommeneded alternative is to install python-secretstorage and let Keyring use the default secretstorage-based backend instead (which is compatible with GNOME Keyring too). Hi Dmitry You're right, i forgot that there was a config file and indeed it contained: [backend] default-keyring=keyring.backends.Gnome.Keyring After removing these lines, keyring works again You can close this one. Thanks, -- Matthieu
Bug#820905: python-keyring: ImportError: No module named Gnome
Package: python-keyring
Version: 8.5.1-1
Severity: serious
Hi,
python-keyring is broken, at least on my system
$ python
>>> import keyring
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6, in
from .core import (set_keyring, get_keyring, set_password, get_password,
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 185, in
init_backend()
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 69, in
init_backend
load_config()
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 139, in
load_config
return load_keyring(keyring_name)
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 107, in
load_keyring
class_ = _load_keyring_class(keyring_name)
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 97, in
_load_keyring_class
__import__(module_name)
ImportError: No module named Gnome
cheers,
Matthieu
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python-keyring depends on:
ii python-dbus 1.2.4-1
pn python:any
Versions of packages python-keyring recommends:
ii python-keyrings.alt 1.1.1-1
ii python-secretstorage 2.1.3-1
Versions of packages python-keyring suggests:
ii gnome-keyring 3.18.3-1
ii libkf5wallet-bin 5.16.0-1
-- no debconf information
Bug#782171: Benchmark of linux and chromium
Hey, On Wed, Apr 06, 2016 at 07:37:53AM +0200, Orestis Ioannou wrote: > (I had to run latest cloc from github because the one in testing has an > older release that affects chromium :D ) That point makes me feel pretty confident that cloc can be broken for other packages. It would be relevant to carefully log errors when we run the plugin on the whole archive! > - time cloc-1.66.pl --by-file-by-lang -csv linux-4.4.6 > > files,language,blank,comment,code > 22558,C,2217923,2064183,11330129 That is awesome to have the comments, it adds a good value IMO. Can't wait to query debsources, asking which license is the most popular among non-commented code, and other funny queries :) > 159.95s user > 21.10s system > 81% cpu > 3:40.93 total That's significantly slower than sloccount, but well, looks ok for something as big as the linux package. Have you had the chance to see if it parallelizes well? > 14,Ruby,59,81,309 > 8,vim script,75,112,264 > 2,Racket,17,51,255 > 4,DTD,44,166,245 > 1,Korn Shell,39,46,223 > 4,XAML,30,50,90 > 4,Standard ML,9,0,61 > 4,Groovy,17,96,57 > 4,PHP,9,0,54 > 9,Verilog-SystemVerilog,0,0,52 > 4,sed,12,21,38 > 1,R,5,5,37 > 1,Prolog,1,-1,32 > 1,Swift,2,0,7 ... is that even true? That's off-topic now, but I'm looking forward to see in which files of chromium we can find php and ML :) Thanks for you work on this bug! Cheers, -- Matthieu
Bug#819861: contributors.debian.org: the From: email header is not in rfc822 format
Package: nm.debian.org
Severity: normal
Tags: patch
Dear Maintainer,
When claiming a new email through the web interface, I receive a
confirmation email with this header:
From: ('Debian New Member Frontdesk', 'n...@debian.org')
which doesn't display well in email clients (they expect rfc822
format).
Attached is a patch to fix it!
Cheers,
--
Matthieu
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From d8b268491422180e06a8ea03c5a3e6745fec1d8f Mon Sep 17 00:00:00 2001
From: Matthieu Caneill <matthieu.cane...@imag.fr>
Date: Sun, 3 Apr 2016 09:46:45 +0200
Subject: [PATCH] Fix email 'From:' format when emailing a claim message
Instead of having:
From: ('Debian New Member Frontdesk', 'n...@debian.org')
we now get:
From: Debian New Member Frontdesk <n...@debian.org>
This is to respect rfc822.
---
contributor/views.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contributor/views.py b/contributor/views.py
index 1420632..a2a7de6 100644
--- a/contributor/views.py
+++ b/contributor/views.py
@@ -179,8 +179,10 @@ Thank you,
contributors.debian.org
""".format(user=email, claim=claim, url=url)
+mail_from = '{0} <{1}>'.format(settings.ADMINS[0][0],
+ settings.ADMINS[0][1])
send_mail('Verify contributors.debian.org claim', message,
- settings.ADMINS[0], [claim], fail_silently=False)
+ mail_from, [claim], fail_silently=False)
messages.warning(request, 'Email sent to ' + claim +
'. Click on the verification link to complete the process')
return redirect("contributor_detail", name=email)
--
2.7.0
Bug#819013: debsources: deduplicate the html setting the background image
Package: qa.debian.org Severity: minor Tags: newcomer User: qa.debian@packages.debian.org Usertags: debsources The few lines of html setting the background image on some pages are duplicated many times (try grepping bg_wrapper). It would be nice to see this in a separate file that would be included on demand! Cheers, -- Matthieu -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#803639: gwakeonlan package is empty, no more binaries, icons, etc.
Package: gwakeonlan Version: 0.5.1-1.1 Severity: important Dear Maintainer, Latest version of gwakeonlan package has dropped gwakeonlan files. Here is what we can found in this package: /usr/share/doc/gwakeonlan/buildinfo_all.gz /usr/share/doc/gwakeonlan/changelog.Debian.gz /usr/share/doc/gwakeonlan/changelog.gz /usr/share/doc/gwakeonlan/copyright That's it! -- System Information: Debian Release: stretch/sid APT prefers xenial APT policy: (500, 'xenial') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-16-generic (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gwakeonlan depends on: ii librsvg2-common 2.40.11-1 ii python-gtk2 2.24.0-4ubuntu1 gwakeonlan recommends no packages. gwakeonlan suggests no packages. -- no debconf information
Bug#794315: rkhunter: Path names not working in PORT_WHITELIST
Package: rkhunter
Version: 1.4.2-0.4
Severity: normal
Dear Maintainer,
The PORT_WHITELIST option related to the hidden_ports test seems to fail when
an executable path name is specified.
The documentation mentions the ability to filter by executable. I used the
proposed sample option from the configuration file which fails with the
following error:
Invalid entry specified in PORT_WHITELIST configuration option: /home/user1/abc
Invalid entry specified in PORT_WHITELIST configuration option: /opt/xyz
Please note that the issue occurs as well with a valid executable:
# rkhunter --enable-tests hidden_ports
Invalid entry specified in PORT_WHITELIST configuration option: /bin/ls
-- System Information:
Debian Release: 8.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.14.10-Dalmat (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages rkhunter depends on:
ii binutils 2.25-5
ii debconf [debconf-2.0] 1.5.56
ii file 1:5.22+15-2
ii net-tools 1.60-26+b1
ii perl 5.20.2-3+deb8u1
ii ucf3.0030
Versions of packages rkhunter recommends:
ii curl7.38.0-4+deb8u2
ii iproute 1:3.16.0-2
ii lsof4.86+dfsg-1
ii lynx2.8.9dev1-2
ii postfix [mail-transport-agent] 2.11.3-1
ii unhide 20121229-1+b1
ii wget1.16-1
Versions of packages rkhunter suggests:
ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-2
pn libdigest-whirlpool-perl none
ii liburi-perl 1.64-1
ii libwww-perl 6.08-1
pn powermgmt-basenone
pn tripwire none
-- Configuration Files:
/etc/apt/apt.conf.d/90rkhunter changed:
// Makes sure that rkhunter file properties database is updated after each
remove or install only if hashes test is enabled
DPkg::Post-Invoke { if [ -x /usr/bin/rkhunter ] ( ! grep -q -E
'^DISABLE_TESTS=.*(hashes.*attributes|attributes.*hashes|properties)'
/etc/rkhunter.conf || grep -q -E
'^ENABLE_TESTS=.*(hashes|attributes|properties)' /etc/rkhunter.conf); then
/usr/bin/rkhunter --propupd --nolog; fi }
/etc/default/rkhunter a7083f49a7dad11ce1ae4e5e20d00cf2 [Errno 2] Aucun fichier
ou dossier de ce type: u'/etc/default/rkhunter a7083f49a7dad11ce1ae4e5e20d00cf2'
/etc/rkhunter.conf changed:
ROTATE_MIRRORS=1
UPDATE_MIRRORS=1
MIRRORS_MODE=0
MAIL-ON-WARNING=
MAIL_CMD=mail -s [rkhunter] Warnings found for ${HOST_NAME}
TMPDIR=/var/lib/rkhunter/tmp
DBDIR=/var/lib/rkhunter/db
SCRIPTDIR=/usr/share/rkhunter/scripts
BINDIR=/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin
/usr/libexec /usr/local/libexec
UPDATE_LANG=
LOGFILE=/var/log/rkhunter.log
APPEND_LOG=0
COPY_LOG_ON_ERROR=0
COLOR_SET2=0
AUTO_X_DETECT=1
WHITELISTED_IS_WHITE=0
ALLOW_SSH_ROOT_USER=no
ALLOW_SSH_PROT_V1=0
ENABLE_TESTS=all
DISABLE_TESTS=suspscan hidden_procs deleted_files
SCRIPTWHITELIST=/bin/egrep
SCRIPTWHITELIST=/bin/fgrep
SCRIPTWHITELIST=/bin/which
SCRIPTWHITELIST=/usr/bin/groups
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/usr/bin/lwp-request
SCRIPTWHITELIST=/usr/sbin/adduser
ALLOWHIDDENDIR=/dev/.udev
ALLOWHIDDENDIR=/etc/.hg
ALLOWHIDDENFILE=/dev/shm/.run-transition
ALLOWPROCDELFILE=/usr/lib/dovecot/imap-login
ALLOWPROCDELFILE=/usr/lib/dovecot/imap:/srv/Mails/**/dovecot.index
ALLOWPROCDELFILE=/usr/lib/apache2/mpm-prefork/apache2:/run/apache2/ssl_mutex
ALLOWPROCDELFILE=/usr/sbin/dovecot:/run/dovecot/login-master-n*
ALLOWPROCDELFILE=/usr/sbin/mysqld:/tmp/ib*
ALLOWPROCDELFILE=/bin/dash:/tmp/tmp*
ALLOWPROCDELFILE=/bin/dash:/var/log/tt-rss*
ALLOWPROCDELFILE=/usr/sbin/smbd:/var/log/samba/log*
ALLOWPROCDELFILE=/usr/sbin/cron:/tmp/tmp*
ALLOWPROCDELFILE=/bin/run-parts:/tmp/tmp*
ALLOWPROCDELFILE=/usr/bin/php5:/var/lib/tt-rss/update_daemon.lock
ALLOWPROCDELFILE=/usr/bin/php5:/var/log/tt-rss*
ALLOWDEVFILE=/dev/shm/network/ifstate
ALLOWDEVFILE=/dev/.udev/*
ALLOWDEVFILE=/dev/.udev/*/*
ALLOW_SYSLOG_REMOTE_LOGGING=0
SUSPSCAN_DIRS=/tmp /var/tmp
SUSPSCAN_TEMP=/dev/shm
SUSPSCAN_MAXSIZE=1024
SUSPSCAN_THRESH=200
PORT_WHITELIST=/home/user1/abc /opt/xyz TCP:2001 UDP:32011
USE_LOCKING=0
LOCK_TIMEOUT=300
SHOW_LOCK_MSGS=1
INSTALLDIR=/usr
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783584: debsources: improve webapp 404 handling (e.g. jessie - stretch move)
Package: qa.debian.org Severity: normal Usertags: debsources During the move jessie-stretch, many 404 errors were not logged, and hence more difficult to debug. It would be nice to log the type of errors that lead to massive 404s. Cheers, -- Matthieu -- System Information: Debian Release: 7.8 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782171: debsources: consider using cloc instead of sloccount
Package: qa.debian.org Severity: wishlist Usertags: debsources cloc (http://cloc.sourceforge.net/#Languages) supports more languages than sloccount (e.g. Scala, Javascript), and could be used to count the lines of code in every package. This has to be carefully tested, since it needs to run of very big packages, and be fast enough. Cheers, -- Matthieu -- System Information: Debian Release: 7.8 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 1/2] Removed Valac and 'debian/clean' file
According to Vala devs (and Sébastien), it's better to compile these .c files. --- debian/changelog | 3 +++ debian/clean | 3 --- debian/control | 3 +-- 3 files changed, 4 insertions(+), 5 deletions(-) delete mode 100644 debian/clean diff --git a/debian/changelog b/debian/changelog index 3706f85..807abce 100644 --- a/debian/changelog +++ b/debian/changelog @@ -16,10 +16,13 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium + Added hicolor-icon-theme as recommended: icons theme used as fallback. + Added latex-beamer, texlive-latex-extra and texlive-xetex as suggested packages: can be useful for beginners. ++ Build-Depends: removed valac, see 'debian/clean' * debian/latexila.install: + Run wrap-and-sort script. * debian/rules: + Added --parallel as generally recommended. + * debian/clean: ++ Removed: according to Vala devs, it's better to compile these .c files -- Tanguy Ortolo tanguy+deb...@ortolo.eu Mon, 27 Oct 2014 16:31:31 +0100 diff --git a/debian/clean b/debian/clean deleted file mode 100644 index 552fa2b..000 --- a/debian/clean +++ /dev/null @@ -1,3 +0,0 @@ -# Regenerated files, that are not really necessary, and that would be detected -# as modified by the VCS -src/*.c diff --git a/debian/control b/debian/control index a918853..5465f90 100644 --- a/debian/control +++ b/debian/control @@ -13,8 +13,7 @@ Build-Depends: autotools-dev, libgtk-3-dev (= 3.14), libgtksourceview-3.0-dev (= 3.10), libgtkspell3-3-dev (= 3.0.4), - libxml2-utils, - valac (= 0.25.4) + libxml2-utils Standards-Version: 3.9.6 Homepage: https://wiki.gnome.org/Apps/LaTeXila Vcs-Git: git://git.ortolo.eu/pkg-latexila.git -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 0/2] deb packages: a few suggestions: part 2
Hello Tanguy, Here are two more patches: * one to not re-generate .c files as recommanded by Vala devs and Sébastien. * one to prepare the next LaTeXila versions (= 3.14.3) due to GtkSourceView's Vala API break between version 3.14.2 and 3.14.3 Matthieu Baerts (2): Removed Valac and 'debian/clean' file Prepare 3.14.3 version: GtkSourceView = 3.14.3 debian/changelog | 6 +- debian/clean | 3 --- debian/control | 5 ++--- 3 files changed, 7 insertions(+), 7 deletions(-) delete mode 100644 debian/clean -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 2/2] Prepare 3.14.3 version: GtkSourceView = 3.14.3
--- debian/changelog | 3 ++- debian/control | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index 807abce..912e2c5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -latexila (3.14.2-1) UNRELEASED; urgency=medium +latexila (3.14.3-1) UNRELEASED; urgency=medium [ Tanguy Ortolo ] * New upstream release. @@ -17,6 +17,7 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium + Added latex-beamer, texlive-latex-extra and texlive-xetex as suggested packages: can be useful for beginners. + Build-Depends: removed valac, see 'debian/clean' ++ Build-Depends: GtkSourceView: min version: 3.14.3 * debian/latexila.install: + Run wrap-and-sort script. * debian/rules: diff --git a/debian/control b/debian/control index 5465f90..5756440 100644 --- a/debian/control +++ b/debian/control @@ -11,7 +11,7 @@ Build-Depends: autotools-dev, libgee-0.8-dev (= 0.10), libglib2.0-dev (= 2.40), libgtk-3-dev (= 3.14), - libgtksourceview-3.0-dev (= 3.10), + libgtksourceview-3.0-dev (= 3.14.3), libgtkspell3-3-dev (= 3.0.4), libxml2-utils Standards-Version: 3.9.6 -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774808: debsources: line number undefined
On 9 January 2015 at 05:05, Jason Pleau ja...@jpleau.ca wrote: I was wrong in my previous email, the code I mentionned is not the cause of the bug in question. It was an error that I did not catch when testing with Firefox. Matthieu, can you test the attached patch and see if it fixes the issue for you? Hi Jason, Thank you for your fast answer. I encountered this week-end hardware problems and won't be able to test your patch before I fix my laptop. I'll come back here later, sorry. Cheers, -- Matthieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774808: debsources: line number undefined
On 7 January 2015 at 20:43, Reiner Herrmann rei...@reiner-h.de wrote: I'm using Iceweasel 34.0, and when I'm viewing a source file on sources.debian.net and click on a line number, it jumps to the current URL with #Lundefined appended (instead of e.g. #L123). It is working correctly with konqueror, but it occurs even with a new iceweasel profile (i.e. no addons installed). Hi, Thanks for the report. I can reproduce this bug. As it works fine when I manually enter such an URL, I believe the bug is due to the new javascript module (debsources.js) which automatically highlights lines with internal links (#L42). Jason: any idea where this comes from? Cheers, -- Matthieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: latexila: deb packages: a few suggestions
Subject: latexila: deb packages: a few suggestions Package: latexila Version: 2.12.1-0ubuntu1 Severity: minor Hello Tanguy, First, thank you for maintaining LaTeXila packages on Debian :-) I'm still maintaining these packages on Ubuntu and I have a few suggestions. I'm going to send you a few git patches, feel free to use/comment them! Best Regards, Matt -- System Information: Debian Release: jessie/sid APT prefers vivid APT policy: (500, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-28-generic (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: upstart (via init_is_upstart()) Versions of packages latexila depends on: ii gsettings-desktop-schemas 3.14.1-1ubuntu1 ii latexila-data 2.12.1-0ubuntu1 ii latexmk1:4.39-1 ii libc6 2.19-13ubuntu3 ii libgdk-pixbuf2.0-0 2.31.1-2 ii libgee20.6.8-2 ii libglib2.0-0 2.43.2-1ubuntu1 ii libgtk-3-0 3.14.6-0ubuntu1 ii libgtksourceview-3.0-1 3.12.3-1ubuntu1 ii libgtkspell3-3-0 3.0.6-1 ii libpango-1.0-0 1.36.8-3 Versions of packages latexila recommends: ii hicolor-icon-theme 0.13-1 ii texlive2014.20141024-1ubuntu1 ii texlive-latex-recommended 2014.20141024-1ubuntu1 Versions of packages latexila suggests: pn rubber none ii texlive-latex-extra 2014.20141024-1 ii texlive-xetex2014.20141024-1ubuntu1 signature.asc Description: This is a digitally signed message part
Bug#774572: [PATCH 5/6] Added hicolor-icon-theme as recommended
Icons theme used as fallback.
---
debian/changelog | 1 +
debian/control | 1 +
2 files changed, 2 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index e93e38e..f267cdf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,7 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium
+ Updated homepage.
+ Added gsettings-desktop-schemas as recommended because LaTeXila supports
it and it contains schemas for the fonts, etc. used by LaTeXila.
++ Added hicolor-icon-theme as recommended: icons theme used as fallback.
* debian/latexila.install:
+ Run wrap-and-sort script.
* debian/rules:
diff --git a/debian/control b/debian/control
index a15d90f..39920d2 100644
--- a/debian/control
+++ b/debian/control
@@ -26,6 +26,7 @@ Depends: latexila-data (= ${source:Version}),
${misc:Depends},
${shlibs:Depends}
Recommends: gsettings-desktop-schemas,
+hicolor-icon-theme,
latexmk (= 4.31),
texlive
Description: LaTeX editor designed for the GNOME desktop
--
2.1.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 1/6] Run wrap-and-sort script as generally recommended
---
debian/changelog| 7 +++
debian/control | 25 +
debian/latexila.install | 2 +-
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 6d2f894..881a08a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,11 +1,18 @@
latexila (3.14.2-1) UNRELEASED; urgency=medium
+ [ Tanguy Ortolo ]
* New upstream release.
* debian/control:
+ update dependency versions.
+ update Standards-Version to 3.9.6 (no change needed).
* debian/patches: remove two patches, as they were applied upstream.
+ [ Matthieu Baerts (matttbe) ]
+ * debian/control:
++ Used wrap-and-sort as generally recommended.
+ * debian/latexila.install:
++ Run wrap-and-sort script.
+
-- Tanguy Ortolo tanguy+deb...@ortolo.eu Mon, 27 Oct 2014 16:31:31 +0100
latexila (3.14.0-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 6c5e628..e6224c8 100644
--- a/debian/control
+++ b/debian/control
@@ -2,12 +2,19 @@ Source: latexila
Section: tex
Priority: optional
Maintainer: Tanguy Ortolo tanguy+deb...@ortolo.eu
-Build-Depends: debhelper (= 9~), autotools-dev,
-libglib2.0-dev (= 2.40), libgtk-3-dev (= 3.14), libgtksourceview-3.0-dev
(= 3.10),
-libgtkspell3-3-dev (= 3.0.4), libgee-0.8-dev (= 0.10),
-gettext, gsettings-desktop-schemas-dev,
-valac (= 0.25.4),
-intltool, itstool, libxml2-utils
+Build-Depends: autotools-dev,
+ debhelper (= 9~),
+ gettext,
+ gsettings-desktop-schemas-dev,
+ intltool,
+ itstool,
+ libgee-0.8-dev (= 0.10),
+ libglib2.0-dev (= 2.40),
+ libgtk-3-dev (= 3.14),
+ libgtksourceview-3.0-dev (= 3.10),
+ libgtkspell3-3-dev (= 3.0.4),
+ libxml2-utils,
+ valac (= 0.25.4)
Standards-Version: 3.9.6
Homepage: http://projects.gnome.org/latexila/
Vcs-Git: git://git.ortolo.eu/pkg-latexila.git
@@ -15,8 +22,10 @@ Vcs-Browser: http://git.ortolo.eu/pkg-latexila.git
Package: latexila
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, latexila-data (=
${source:Version})
-Recommends: texlive, latexmk (= 4.31)
+Depends: latexila-data (= ${source:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Recommends: latexmk (= 4.31), texlive
Description: LaTeX editor designed for the GNOME desktop
LaTeXila is a LaTeX editor for GNOME. It integrates the various tools required
for processing LaTeX documents. It provides menus, buttons and templates to
diff --git a/debian/latexila.install b/debian/latexila.install
index a5ef488..d749ed3 100644
--- a/debian/latexila.install
+++ b/debian/latexila.install
@@ -1,2 +1,2 @@
-usr/bin
debian/latexila.xpm usr/share/pixmaps
+usr/bin
--
2.1.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 4/6] Added gsettings-desktop-schemas as recommended
LaTeXila supports it and it contains schemas for the fonts, etc. used by
LaTeXila.
---
debian/changelog | 2 ++
debian/control | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index a25e2e6..e93e38e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,8 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium
* debian/control:
+ Used wrap-and-sort as generally recommended.
+ Updated homepage.
++ Added gsettings-desktop-schemas as recommended because LaTeXila supports
+ it and it contains schemas for the fonts, etc. used by LaTeXila.
* debian/latexila.install:
+ Run wrap-and-sort script.
* debian/rules:
diff --git a/debian/control b/debian/control
index cc6dfd5..a15d90f 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,9 @@ Architecture: any
Depends: latexila-data (= ${source:Version}),
${misc:Depends},
${shlibs:Depends}
-Recommends: latexmk (= 4.31), texlive
+Recommends: gsettings-desktop-schemas,
+latexmk (= 4.31),
+texlive
Description: LaTeX editor designed for the GNOME desktop
LaTeXila is a LaTeX editor for GNOME. It integrates the various tools required
for processing LaTeX documents. It provides menus, buttons and templates to
--
2.1.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 6/6] Added latex-beamer, texlive-latex-extra and xetex
Suggested packages: can be useful for beginners. --- debian/changelog | 2 ++ debian/control | 1 + 2 files changed, 3 insertions(+) diff --git a/debian/changelog b/debian/changelog index f267cdf..3706f85 100644 --- a/debian/changelog +++ b/debian/changelog @@ -14,6 +14,8 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium + Added gsettings-desktop-schemas as recommended because LaTeXila supports it and it contains schemas for the fonts, etc. used by LaTeXila. + Added hicolor-icon-theme as recommended: icons theme used as fallback. ++ Added latex-beamer, texlive-latex-extra and texlive-xetex as suggested + packages: can be useful for beginners. * debian/latexila.install: + Run wrap-and-sort script. * debian/rules: diff --git a/debian/control b/debian/control index 39920d2..a918853 100644 --- a/debian/control +++ b/debian/control @@ -29,6 +29,7 @@ Recommends: gsettings-desktop-schemas, hicolor-icon-theme, latexmk (= 4.31), texlive +Suggests: latex-beamer, texlive-latex-extra, texlive-xetex Description: LaTeX editor designed for the GNOME desktop LaTeXila is a LaTeX editor for GNOME. It integrates the various tools required for processing LaTeX documents. It provides menus, buttons and templates to -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 0/6] deb packages: a few suggestions
Hello Tanguy, First, thank you for maintaining LaTeXila packages on Debian :-) I'm still maintaining these packages on Ubuntu and I have a few suggestions. Feel free to apply/comment these patches! Best Regards, Matt Matthieu Baerts (6): Run wrap-and-sort script as generally recommended Update homepage d/rules: Added --parallel as generally recommended Added gsettings-desktop-schemas as recommended Added hicolor-icon-theme as recommended Added latex-beamer, texlive-latex-extra and xetex debian/changelog| 15 +++ debian/control | 31 ++- debian/latexila.install | 2 +- debian/rules| 2 +- 4 files changed, 39 insertions(+), 11 deletions(-) -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 3/6] d/rules: Added --parallel as generally recommended
--- debian/changelog | 2 ++ debian/rules | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index bb360c9..a25e2e6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -13,6 +13,8 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium + Updated homepage. * debian/latexila.install: + Run wrap-and-sort script. + * debian/rules: ++ Added --parallel as generally recommended. -- Tanguy Ortolo tanguy+deb...@ortolo.eu Mon, 27 Oct 2014 16:31:31 +0100 diff --git a/debian/rules b/debian/rules index c4ed0fb..3cb4c4a 100755 --- a/debian/rules +++ b/debian/rules @@ -8,7 +8,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed %: - dh $@ + dh $@ --parallel override_dh_installchangelogs: dh_installchangelogs NEWS -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774572: [PATCH 2/6] Update homepage
https://mail.gnome.org/archives/latexila-list/2013-November/msg1.html --- debian/changelog | 1 + debian/control | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 881a08a..bb360c9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,6 +10,7 @@ latexila (3.14.2-1) UNRELEASED; urgency=medium [ Matthieu Baerts (matttbe) ] * debian/control: + Used wrap-and-sort as generally recommended. ++ Updated homepage. * debian/latexila.install: + Run wrap-and-sort script. diff --git a/debian/control b/debian/control index e6224c8..cc6dfd5 100644 --- a/debian/control +++ b/debian/control @@ -16,7 +16,7 @@ Build-Depends: autotools-dev, libxml2-utils, valac (= 0.25.4) Standards-Version: 3.9.6 -Homepage: http://projects.gnome.org/latexila/ +Homepage: https://wiki.gnome.org/Apps/LaTeXila Vcs-Git: git://git.ortolo.eu/pkg-latexila.git Vcs-Browser: http://git.ortolo.eu/pkg-latexila.git -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770365: debsources: 403 on /src/beignet/1.0.0-1/README.md/
Hi, Thanks for your report! On 20 November 2014 at 20:05, Jérémy Bobbio lu...@debian.org wrote: When visiting https://sources.debian.net/src/beignet/1.0.0-1/README.md/ I'm told “403 Permission Denied”. This is a bit annoying as the file is listed on https://sources.debian.net/src/beignet/1.0.0-1/ Due to security reasons, we deactivated all symbolic links on Debsources (even the ones internal to a package, but this isn't implemented yet). Zack what do you think? Cheers, -- Matthieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken
On Tue, Aug 19, 2014 at 04:14:25PM +0200, Páll Sigurðsson wrote: What does the debian package for shinken do ? If they bundle their javascripts i see no reason for us not to do the same. I don't know how it's done in Shinken, but it doesn't change the fact that having embedded javascript shouldn't be the way to go. Anyway, I've implemented the use of Bower for the front-end dependencies management: https://github.com/savoirfairelinux/adagios/compare/savoirfairelinux:master...feature-bower-dependencies?expand=1 It should help to easily sort packages and use Debian dependencies whenever they exist :-) Let me know if you saw things like this. Cheers, -- Matthieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken
On Mon, Aug 04, 2014 at 08:46:15PM +0200, Páll Sigurðsson wrote: Yeah that is a bug which you are more than welcome to fix. Instead of @darkstar i use @opensource.is Does debian specifically oppose bundling javascripts ? What are projects like foreman doing ? Using bower (http://bower.io) could be the way to go. Then, at build-time, * depend on already-packaged JS libs, * and bower install the others. Does that seem reasonable? The only downside I can see would be the adjustment of paths, which could be done by a patch to the Apache configuration. Thoughts? Cheers, -- Matthieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
