Bug#708812: [aptitude] aptitude segfaults upon being called.
Package: aptitude Version: 0.6.8.2-1 Followup-For: Bug #708812 Same symptom as original reporter. Also got similar strace log. I'll add a gdb backtrace (with aptitude-dbg installed), but there's almost no useful information either. -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude linkage: libapt-pkg.so.4.12 = /usr/lib/mipsel-linux-gnu/libapt-pkg.so.4.12 (0x773ec000) libncursesw.so.5 = /lib/mipsel-linux-gnu/libncursesw.so.5 (0x773b) libtinfo.so.5 = /lib/mipsel-linux-gnu/libtinfo.so.5 (0x7738) libsigc-2.0.so.0 = /usr/lib/mipsel-linux-gnu/libsigc-2.0.so.0 (0x7736c000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7723c000) libept.so.1.aptpkg4.12 = /usr/lib/libept.so.1.aptpkg4.12 (0x77174000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x76f3) libz.so.1 = /lib/mipsel-linux-gnu/libz.so.1 (0x76f08000) libsqlite3.so.0 = /usr/lib/mipsel-linux-gnu/libsqlite3.so.0 (0x76e3c000) libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 (0x76e14000) libpthread.so.0 = /lib/mipsel-linux-gnu/loongson2f/libpthread.so.0 (0x76de8000) libstdc++.so.6 = /usr/lib/mipsel-linux-gnu/libstdc++.so.6 (0x76cdc000) libm.so.6 = /lib/mipsel-linux-gnu/loongson2f/libm.so.6 (0x76c54000) libgcc_s.so.1 = /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x76c18000) libc.so.6 = /lib/mipsel-linux-gnu/loongson2f/libc.so.6 (0x76aa) libutil.so.1 = /lib/mipsel-linux-gnu/loongson2f/libutil.so.1 (0x76a8c000) libdl.so.2 = /lib/mipsel-linux-gnu/loongson2f/libdl.so.2 (0x76a78000) libbz2.so.1.0 = /lib/mipsel-linux-gnu/libbz2.so.1.0 (0x76a54000) libuuid.so.1 = /lib/mipsel-linux-gnu/libuuid.so.1 (0x76a3c000) librt.so.1 = /lib/mipsel-linux-gnu/loongson2f/librt.so.1 (0x76a24000) /lib/ld.so.1 (0x) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: mipsel (mips64) Kernel: Linux 3.2.0-4-loongson-2f Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aptitude depends on: ii aptitude-common 0.6.8.2-1 ii libapt-pkg4.120.9.7.8 ii libboost-iostreams1.49.0 1.49.0-3.2 ii libc6 2.17-3 ii libcwidget3 0.5.16-3.4 ii libept1.4.12 1.0.9 ii libgcc1 1:4.8.0-7 ii libncursesw5 5.9+20130504-1 ii libsigc++-2.0-0c2a2.2.10-0.2 ii libsqlite3-0 3.7.16.2-1 ii libstdc++64.8.0-7 ii libtinfo5 5.9+20130504-1 ii libxapian22 1.2.15-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages aptitude recommends: ii apt-xapian-index0.45 pn aptitude-doc-en | aptitude-doc none pn libparse-debianchangelog-perl none ii sensible-utils 0.0.7 Versions of packages aptitude suggests: pn debtags none ii tasksel 3.15 -- no debconf information Load new symbol table from /usr/bin/aptitude-curses? (y or n) Reading symbols from /usr/bin/aptitude-curses...Reading symbols from /usr/lib/debug/.build-id/56/4839ff0ae3b7a066789b92ee4488379f904c07.debug...done. done. Starting program: /usr/bin/aptitude [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/mipsel-linux-gnu/loongson2f/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Thread 1 (Thread 0x77fed130 (LWP 14804)): #0 0x in ?? () No symbol table info available. #1 0x00418e80 in _PROCEDURE_LINKAGE_TABLE_ () No symbol table info available. Backtrace stopped: frame did not save the PC A debugging session is active. Inferior 1 [process 14804] will be killed. Quit anyway? (y or n)
Bug#629351: Segfault on startup (Loongson2F mipsel system)
Package: gnome-settings-daemon Version: 3.4.2+git20121218.7c1322-3 Followup-For: Bug #629351 Sorry for the long long delay. It took time to fix the X server issue on my Yeeloong mipsel box. It turned out this issue still persists, and the same solution, dropping -Wl,-z,defs from LDFLAGS still fixes the problem. I'm attaching the patch that modifies debian/rules that also exclude mipsel from add the flag, together with ia64. Long story: after X server started to work, gdm3 would display the Oh no! Something has gone wrong dialog, the same as #687569 [1]. However it was not cause by graphic driver, and after inspecting :0-greeter.log, it turned out it was actually gnome-settings-daemon that segfaulted. As stated above, this bug renders GNOME unusable on mipsel on wheezy. As the change is trivial, I would like to suggest incorporate the patch on stable release as well, and include it in the next point release. Thanks. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687569 -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 3.2.0-4-loongson-2f Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii dpkg 1.16.10 ii gsettings-desktop-schemas3.4.2-3 ii libatk1.0-0 2.4.0-2 ii libc62.13-38 ii libcairo-gobject21.12.2-3 ii libcairo21.12.2-3 ii libcanberra-gtk3-0 0.28-6 ii libcanberra0 0.28-6 ii libcolord1 0.1.21-1 ii libcomerr2 1.42.5-1.1 ii libcups2 1.5.3-5 ii libdbus-glib-1-2 0.100.2-1 ii libfontconfig1 2.9.0-7.1 ii libgcrypt11 1.5.0-5 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnome-desktop-3-2 3.4.2-1 ii libgnomekbd7 3.4.0.2-1 ii libgnutls26 2.12.20-7 ii libgssapi-krb5-2 1.10.1+dfsg-5 ii libgtk-3-0 3.4.2-6 ii libgudev-1.0-0 175-7.2 ii libk5crypto3 1.10.1+dfsg-5 ii libkrb5-31.10.1+dfsg-5 ii liblcms2-2 2.2+git20110628-2.2 ii libnotify4 0.7.5-1 ii libnspr4 2:4.9.2-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3 2:3.14.3-1 ii libnss3-1d 2:3.14.3-1 ii libpackagekit-glib2-14 0.7.6-3 ii libpango1.0-01.30.0-1 ii libpolkit-gobject-1-00.105-3 ii libpulse-mainloop-glib0 2.0-6.1 ii libpulse02.0-6.1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libupower-glib1 0.9.17-1 ii libwacom20.6-1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxfixes3 1:5.0-4+deb7u1 ii libxi6 2:1.6.1-1+deb7u1 ii libxklavier165.2.1-1 ii libxtst6 2:1.2.1-1+deb7u1 ii nautilus-data3.4.2-1+build1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages gnome-settings-daemon recommends: ii pulseaudio 2.0-6.1 Versions of packages gnome-settings-daemon suggests: ii gnome-screensaver3.4.1-1 ii metacity [x-window-manager] 1:2.34.3-4 ii x11-xserver-utils7.7~3 -- no debconf information diff -urN gnome-settings-daemon-3.4.2+git20121218.7c1322/debian/rules gnome-settings-daemon-3.4.2+git20121218.7c1322.new/debian/rules --- gnome-settings-daemon-3.4.2+git20121218.7c1322/debian/rules 2012-05-24 22:45:53.0 -0700 +++ gnome-settings-daemon-3.4.2+git20121218.7c1322.new/debian/rules 2013-05-29 21:36:24.584047598 -0700 @@ -7,7 +7,7 @@ include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk -ifneq ($(DEB_HOST_ARCH_CPU),ia64) +ifneq ($(DEB_HOST_ARCH_CPU),$(filter $(DEB_HOST_ARCH_CPU),ia64 mipsel)) LDFLAGS += -Wl,-z,defs endif
Bug#699649: Boost.Locale library security flaw
Package: libboost-locale1.49-dev Version: 1.49.0-3.1 Severity: grave Tags: security Boost has issued a security notice: http://www.boost.org/users/news/boost_locale_security_notice.html Boost versions from 1.48.0 to 1.52.0 are affected. A patch is provided: http://cppcms.com/files/locale/boost_locale_utf.patch Please incorporate the patch. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: mipsel (mips64) Kernel: Linux 3.2.0-4-loongson-2f Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost-locale1.49-dev depends on: ii libboost-locale1.49.0 1.49.0-3.1 ii libboost1.49-dev 1.49.0-3.1 libboost-locale1.49-dev recommends no packages. libboost-locale1.49-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566947: emacs23-nox fails to install
Hi Emacs maintainers, It looks like the same problem is coming back again. Currently installing emacs23-nox at version 23.4+1-4 will fail by assertion on wheezy stable install with the same assertion as before. According to build log[1], binutils is at 2.22-7.1, and linux-libc-dev is at 3.2.23-1, which should have included loongson2f fixes (or anyone confirm it?). Rebuilding on my local wheezy pbuilder using the same packages provided by wheezy fixes the problem, again. As this involves binutils, I'm CCing binutils maintainers to have their opinion on this. [1] https://buildd.debian.org/status/fetch.php?pkg=emacs23arch=mipselver=23.4%2B1-4stamp=1347257874 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710894: pu: package gnome-settings-daemon/3.4.2+git20121218.7c1322-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu (please explain the reason for this update here) Hi stable release managers, I'm here proposing a stable update for gnome-settings-daemon to fix #629351[1]. The bug causes this package to segfault on mipsel, and even causes gdm3 to display Oh no! Something has gone wrong screen, which basically makes gdm3 and GNOME desktop unusable. [1] http://bugs.debian.org/629351 The way to fix this is to disable -Wl,-z,defs flags to ld. The same approach has already been applied on ia64. The proposed patch is attached. Admittedly, the real problem may lie in toolchain support, and I have already CCed binutils maintainer in original bug report[1]. However, given the workaround has already been applied on other architecture, the patch is IMHO more convenient for stable release. Please review and comment. Also put Debian GNOME packaging team in CC so once acked they can help preparing the upload. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Index: debian/changelog === --- debian/changelog (.../unstable/gnome-settings-daemon) (revision 36620) +++ debian/changelog (.../wheezy/gnome-settings-daemon) (working copy) @@ -1,3 +1,10 @@ +gnome-settings-daemon (3.4.2+git20121218.7c1322-3+deb7u1) UNRELEASED; urgency=low + + * Backport from sid: +- Disable -Wl,-z,defs on mipsel to fix segfault. (Closes: #629351) + + -- Xiyue Deng manphiz-gu...@users.alioth.debian.org Mon, 03 Jun 2013 00:53:30 -0700 + gnome-settings-daemon (3.4.2+git20121218.7c1322-3) unstable; urgency=low * 06_a11y_gdm_leak.patch: backported from git master. Reset keyboard Index: debian/rules === --- debian/rules (.../unstable/gnome-settings-daemon) (revision 36620) +++ debian/rules (.../wheezy/gnome-settings-daemon) (working copy) @@ -7,7 +7,7 @@ include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk -ifneq ($(DEB_HOST_ARCH_CPU),ia64) +ifneq ($(DEB_HOST_ARCH_CPU),$(filter $(DEB_HOST_ARCH_CPU),ia64 mipsel)) LDFLAGS += -Wl,-z,defs endif LDFLAGS += -Wl,-O1 -Wl,--warn-unresolved-symbols -Wl,--as-needed
Bug#710894: pu: package gnome-settings-daemon/3.4.2+git20121218.7c1322-3
On Mon, Jun 3, 2013 at 3:54 AM, Emilio Pozuelo Monfort po...@debian.org wrote: On 03/06/13 12:13, Xiyue Deng wrote: Please review and comment. Also put Debian GNOME packaging team in CC so once acked they can help preparing the upload. Please commit this change to the unstable branch on svn too. It needs to be uploaded to unstable before it can be accepted for wheezy, otherwise the version in wheezy will be higher than the one in unstable. Done. In fact I updated experimental page hoping that all GNOME 3.8 may enter unstable soon. Anyway it is always good to be thorough. Thanks for the notice. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736326: emacs24: please provide a backport for Debian stable
Package: emacs24 Version: 24.3+1-2 Severity: wishlist Will be great to have emacs24 available to stable release as a backport, given that it has been staying in testing for a few months already without major RC bugs. Thanks. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: mipsel (mips64) Kernel: Linux 3.2.0-4-loongson-2f 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#1005960: linux-image-5.15.0-0.bpo.3-amd64: Failed to boot due to "Failed to look up module alias 'autofs4': Function not implemented"
Package: src:linux Version: 5.15.15-2~bpo11+1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** Booting with linux-image-5.15.0-0.bpo.3-amd64 fails and drops to root shell due to the following error message: [3.925863] systemd[1]: Failed to look up module alias 'autofs4': Function not implemented Boot using the linux-image-5.15.0-0.bpo.2-amd64 works. Will attach dmesg to help with debugging. If more information is needed please let me know. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: SYSTEM_MANUFACTURER product_name: HX90 product_version: Default string chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends International, LLC. bios_version: 5.19 board_vendor: Default string board_name: HX90 board_version: Default string ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex [1022:1630] Subsystem: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus [1022:1635] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 51) Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: nvme Kernel modules: nvme 02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 01) DeviceName: Onboard LAN Brodcom Subsystem: Intel Corporation Ethernet Controller I225-V [8086:] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: igc Kernel modules: igc 03:00.0
Bug#1051677: emacs: Provides backport of 29.1
Package: emacs Version: 1:28.2+1-15 Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng It would be great to have 29.1 backported to bookworm (or potentially bullseye if it's not too much of a trouble :) I acknowledge that some of the addons in bookworm don't work with 29.1 yet, while use-package users may just upgrade to latest versions on Elpa/Melpa so that they continues to work. Meanwhile I will also help with backporting the addons gradually. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-15 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Sean Whitton writes: > Hello, > > On Mon 16 Oct 2023 at 03:51am -07, Xiyue Deng wrote: > >> Looks like I got confused about what you suggested as there was a "0.3" >> tag that was from the upstream repo which I assume "git deborig" can use >> so I thought an "upstream" may help more. >> >> I've now also pushed an "upstream/0.3" tag at the commit that matches >> the "0.3" tag, but not sure whether this is what you were referring to. >> If this works better I can remove the upstream branch to avoid further >> complications. Please advice. Thanks! > > What I meant was simply pushing the 0.3 tag to salsa. Ah got it, and done. Sorry for the confusion. I have also dropped the unnecessary tag "upstream/0.3" and the upstream branch, which is not actually used much in the dgit-maint-merge workflow AIUI. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Sean Whitton writes: > Hello, > > On Sun 15 Oct 2023 at 10:45pm -07, Xiyue Deng wrote: > >> Ah I see. So for d/copyright we need to stick to the source >> information. Dropped Wilfred from the list of copyright holders for >> now. Also opened a PR upstream for tracking[1]. > > Cool. Just to note, in your commit message you wrote that he's not a > copyright holder yet, but we can't assert that -- in fact, he probably > is a copyright holder. You could have written that he's not > /documented/ as a copyright holder. > Ack. Yeah I should have said that in the commit message. I guess doing a reword and letting everyone having to do a force pull is a no-go so I think I'll have to leave it as-is. Will be more precise in future. >> As this is the first time I attempt of ITP/RFS, I'd like to go over the >> steps for packaging as much as possible if OK. But AIUI this package >> will need to go through the NEW queue, so I guess if you sponsor my >> upload to mentors.d.n it may require some extra steps, then I'm OK if >> what you propose can save some trouble. > > Okay, go ahead and let me know when you've done 'dch -r'. > > I will still work out of git, so please don't push a signed tag there. > See dgit-sponsorship(7) for more. Pushed the commit with 'dch -r' to salsa and also uploaded to mentors[1]. Please proceed as you see fit. Thanks for the sponsorship! [1] https://mentors.debian.net/package/bison-mode/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053976: elpa-eglot: eglot-server-programs doesn't provide mappings for *-ts-modes
Package: elpa-eglot Version: 1.9-2 Severity: normal X-Debbugs-Cc: none, Xiyue Deng Emacs 29 includes support fro tree-sitter and the new "*-ts-mode" major modes. However the current eglot version doesn't work out-of-the-box for those new tree-sitter based modes as the mappings for those new major modes are not available yet. This has been fixed upstream in this commit[1], and syncing to a new upstream version should fix this. [1] https://github.com/joaotavora/eglot/commit/fb8111d8222b09641a6aaab02d846ceac3ae97ed -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-eglot depends on: ii dh-elpa-helper 2.0.17 ii elpa-project0.8.1-1 ii elpa-seq2.24-1 ii elpa-xref 1.6.3-1 ii emacsen-common 3.0.5 elpa-eglot recommends no packages. elpa-eglot suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: Xiyue Deng , debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "bison-mode": * Package name : bison-mode Version : 0.3-1 Upstream contact : [fill in name and email of upstream] * URL : https://github.com/Wilfred/bison-mode * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/bison-mode Section : editors The source builds the following binary packages: elpa-bison-mode - Emacs major mode for editing lex, yacc, and bison grammars To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bison-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bison-mode/bison-mode_0.3-1.dsc Changes for the initial release: bison-mode (0.3-1) UNRELEASED; urgency=medium . * Initial release. Closes: #1053906. Please note that I am currently intentionally leaving the distribution as "UNRELEASE" in case any changes is required. Will change this to "unstable" when uploading the final package. Regards, -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Sean Whitton writes: > Hello Xiyue, > > On Sun 15 Oct 2023 at 04:32am -07, Xiyue Deng wrote: > >> Package: sponsorship-requests >> Severity: wishlist >> X-Debbugs-Cc: Xiyue Deng , debian-emac...@lists.debian.org >> >> Dear mentors, >> >> I am looking for a sponsor for my package "bison-mode": >> >> * Package name : bison-mode >>Version : 0.3-1 >>Upstream contact : [fill in name and email of upstream] >> * URL : https://github.com/Wilfred/bison-mode >> * License : GPL-2+ >> * Vcs : https://salsa.debian.org/emacsen-team/bison-mode > > Can you give me a git repo to clone, please? I'll create and push it to > that team repo, then review and sponsor. Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have also filed an RFS bug#1053987. Thanks in advance for taking a look! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Arto Jantunen writes:
> Xiyue Deng writes:
>
>> Arto Jantunen writes:
>>
>>> Xiyue Deng writes:
>>>
>>>> Hi Arto,
>>>>
>>>> Arto Jantunen writes:
>>>>
>>>>> Xiyue Deng writes:
>>>>>> Package: sponsorship-requests
>>>>>> Severity: important
>>>>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>>>>>
>>>>>> Dear mentors,
>>>>>>
>>>>>> I am looking for a sponsor for my package "lsp-mode":
>>>>>>
>>>>>> * Package name : lsp-mode
>>>>>>Version : 8.0.0-6
>>>>>>Upstream contact : Vibhav Pant
>>>>>> * URL : https://github.com/emacs-lsp/lsp-mode
>>>>>> * License : GPL-3+
>>>>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>>>>>Section : lisp
>>>>>>
>>>>>> The source builds the following binary packages:
>>>>>>
>>>>>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>>>>>
>>>>>> To access further information about this package, please visit the
>>>>>> following URL:
>>>>>>
>>>>>> https://mentors.debian.net/package/lsp-mode/
>>>>>>
>>>>>> Alternatively, you can download the package with 'dget' using this
>>>>>> command:
>>>>>>
>>>>>> dget -x
>>>>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>>>>>
>>>>>> Changes since the last upload:
>>>>>>
>>>>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>>>>>> .
>>>>>>* Add patch to fix test failures (Closes: #1052939).
>>>>>>* Update Standards-Version to 4.6.2. No change needed.
>>>>>>* Add myself as uploader (Closes: #1042568).
>>>>>>* Add signing key verification to d/watch.
>>>>>>* Add d/upstream/metadata.
>>>>>>* Add Upstream-Contact and update year in d/copyright.
>>>>>>* Add patch to fix non-UTF-8 encoding.
>>>>>>* Drop unused lintian overrides.
>>>>>
>>>>> Thanks for taking over this package.
>>>>>
>>>>> When I try to build this (under sbuild) I get the following build
>>>>> failure:
>>>>>
>>>>> Test ‘lsp-text-document-hover-request’ redefined
>>>>>
>>>>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>>>> mapbacktrace(#f(compiled-function (evald func args flags) #>>>> -0x187de6214517952>))
>>>>> debug-early-backtrace()
>>>>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>>>>> redefined"))
>>>>> error("Test `%s' redefined" lsp-text-document-hover-request)
>>>>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>>>> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
>>>>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures"))
>>>>> (find-file
>>>>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
>>>>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq
>>>>> 'initialized
>>>>> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
>>>>> (goto-char
>>>>> (point-min)) (search-forward "fn1") (lsp-def-request-async
>>>>> "textDocument/hover"
>>>>> (lsp--text-document-position-params #'(lambda (contents) (let*
>>>>> ((fn-566
>>>>> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>>>>> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>>>>> #'signal) (list (car err) (cdr err))) (let ((value-568
>>>>> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>>>>> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>>>>> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list
>>>>> :form
>
Bug#1054255: qa.debian.org: UDD/upstream: consider using d/watch from source repository when available
Package: qa.debian.org User: qa.debian@packages.debian.org Severity: wishlist Usertags: udd X-Debbugs-Cc: none, Xiyue Deng The uscan results provided by UDD are based on d/watch file from the latest released version of the package which it fetches using .dsc[1]. While this works, it also means that fixing any existing uscan errors requires a new release of the package. This shouldn't be a big issue if the upstream provides regular releases. However, for upstream that is not very active, making a new release just to fix uscan errors may be a bit overkill. Alternatively, I wonder whether it can be considered that if the d/control provides the location of Debian packaging source repository either through Vcs-* or Dgit, UDD can optionally use that information to checkout the repository and use the d/watch file there to update uscan results so that any errors can be fixed through a commit only. Of course this adds some more complexities and points of failure such as - invalid Vcs-* or Dgit, or - broken d/watch in the repo. In such cases we may just fall back to the old ways to use the d/watch in the release package which effectively reverts to the current behavior. Just wondering whether this is a direction that's worth considering. [1] https://salsa.debian.org/qa/udd/-/blob/master/rimporters/upstream.rb#L20-35
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Xiyue Deng writes:
> Hi Bo,
>
> Bo YU writes:
>
>> Hi!
>>
>> On Thu, Oct 26, 2023 at 7:02 AM Xiyue Deng wrote:
>>
>> ...
>>>
>>> For the unlikely but possible cause that tests with a long name is a
>>> prefix of other tests that may trigger this issue, I have modified the
>>> test name for testing purposes. Can you help get the latest upload on
>>> mentors and try again? TIA.
>>>
>> I tried this and it seems the issue was raised with my sbuild build
>> environment.
>> I still got this:
>> https://paste.debian.net/1296268/
>>
>> My sbuilderrc is here:
>> https://paste.debian.net/1296269/
>>
>> But if use pbuilder[0] to build your package, it is ok.
>> So I think your package which is no problem.
>>
>> BTW, I suspect the network accessing leads to the issue and I am annoy how to
>> disable network access during building for sbuild.
>>
>> BR,
>> Bo
>> [0]: https://wiki.ubuntu.com/PbuilderHowto
>
> Thanks for testing! The reason I'm interested in reproducing this error
> is that in the report of the RC bug that this upload is trying to solve
> - https://bugs.debian.org/1052939 - the build log from Lucas has exactly
> the same error:
>
> ,
> | ...
> | > Test ‘lsp-text-document-hover-request’ redefined
> | >
> | > Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
> | ...
> `
>
> But I haven't been able to reproduce this until Arto and you sent your
> reports, and this being reproduced by two people makes this more
> interesting. There must be something that may trigger this unlikely
> error. Also I'm not sure whether the network accessing may have been
> the cause as sbuild needs to download the dependencies and without
> something like apt-cacher{,-ng} it does need network access for that to
> happen.
>
> I suspected that the parallel setting in $DEB_BUILD_OPTIONS may have
> affected it so I copied your sbuild settings and tried again but
> unfortunately it still succeeded for me. For the unlikely event and for
> completeness, can you also try to turn that off in your sbuild config
> and retry just in case? TIA.
>
Actually scratch my previous mail, as I found how to produce the issue.
In `lsp-clangd-test.el' it does `(require 'lsp-integration-test)', so if
`lsp-clangd-test.el' is loaded before `lsp-integration-test.el', it
seems the test symbols in the latter are loaded twice that triggers the
error regardless of whether there is an actual duplicated test name. I
can confirm that in your build log that the clangd one was loaded first
which causes this error. I assume Arto sees it due to the same cause.
I have added another change to override dh_elpa_test to ensure
`lsp-clangd-test' is loaded last and uploaded to mentors. Please help
test again.
I'll probably also report this issue upstream to see how it should be
handled.
>>> ,
>>> | $ dget -x
>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>> | $ sbuild lsp-mode_8.0.0-6.dsc
>>> `
>>>
>>> P.S. If you can provide the failed build log and ~/.sbuildrc it may
>>> still help to eliminate potential sbuild differences in our environment.
>>>
>>> >>
>>> >> BR,
>>> >> Bo
>>> >>>
>>> >>> --
>>> >>> Arto Jantunen
>>> >>>
>>>
>>> --
>>> Xiyue Deng
--
Xiyue Deng
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Hi Bo,
Bo YU writes:
> Hi!
>
> On Wed, Oct 25, 2023 at 5:06 PM Arto Jantunen wrote:
>>
>> Xiyue Deng writes:
>>
>> > Arto Jantunen writes:
>> >
>> >> Xiyue Deng writes:
>> >>
>> >>> Hi Arto,
>> >>>
>> >>> Arto Jantunen writes:
>> >>>
>> >>>> Xiyue Deng writes:
>> >>>>> Package: sponsorship-requests
>> >>>>> Severity: important
>> >>>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>> >>>>>
>> >>>>> Dear mentors,
>> >>>>>
>> >>>>> I am looking for a sponsor for my package "lsp-mode":
>> >>>>>
>> >>>>> * Package name : lsp-mode
>> >>>>>Version : 8.0.0-6
>> >>>>>Upstream contact : Vibhav Pant
>> >>>>> * URL : https://github.com/emacs-lsp/lsp-mode
>> >>>>> * License : GPL-3+
>> >>>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>> >>>>>Section : lisp
>> >>>>>
>> >>>>> The source builds the following binary packages:
>> >>>>>
>> >>>>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>> >>>>>
>> >>>>> To access further information about this package, please visit the
>> >>>>> following URL:
>> >>>>>
>> >>>>> https://mentors.debian.net/package/lsp-mode/
>> >>>>>
>> >>>>> Alternatively, you can download the package with 'dget' using this
>> >>>>> command:
>> >>>>>
>> >>>>> dget -x
>> >>>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>> >>>>>
>> >>>>> Changes since the last upload:
>> >>>>>
>> >>>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>> >>>>> .
>> >>>>>* Add patch to fix test failures (Closes: #1052939).
>> >>>>>* Update Standards-Version to 4.6.2. No change needed.
>> >>>>>* Add myself as uploader (Closes: #1042568).
>> >>>>>* Add signing key verification to d/watch.
>> >>>>>* Add d/upstream/metadata.
>> >>>>>* Add Upstream-Contact and update year in d/copyright.
>> >>>>>* Add patch to fix non-UTF-8 encoding.
>> >>>>>* Drop unused lintian overrides.
>> >>>>
>> >>>> Thanks for taking over this package.
>> >>>>
>> >>>> When I try to build this (under sbuild) I get the following build
>> >>>> failure:
>> >>>>
>> >>>> Test ‘lsp-text-document-hover-request’ redefined
>> >>>>
>> >>>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>> >>>> mapbacktrace(#f(compiled-function (evald func args flags) #> >>>> -0x187de6214517952>))
>> >>>> debug-early-backtrace()
>> >>>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>> >>>> redefined"))
>> >>>> error("Test `%s' redefined" lsp-text-document-hover-request)
>> >>>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>> >>>> lsp-text-document-hover-request :documentation nil :body (closure (t)
>> >>>> nil
>> >>>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures"))
>> >>>> (find-file
>> >>>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp)
>> >>>> (deferred:sync!
>> >>>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq
>> >>>> 'initialized
>> >>>> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
>> >>>> (goto-char
>> >>>> (point-min)) (search-forward "fn1") (lsp-def-request-async
>> >>>> "textDocument/hover"
>> >>>> (lsp--text-document-position-params #'(lambda (contents) (let*
>> >>>> ((fn-566
>> >>&g
Bug#1054419: RFS: go-mode.el/3:1.6.0+git202300823.8dce1e3-1 [RC] [Team] -- Emacs mode for editing Go code
Xiyue Deng writes: > Package: sponsorship-requests > Severity: important > X-Debbugs-CC: debian-emac...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "go-mode.el": > > * Package name : go-mode.el >Version : 3:1.6.0+git202300823.8dce1e3-1 >Upstream contact : Dominik Honnef > * URL : https://github.com/dominikh/go-mode.el > * License : BSD-3-clasue > * Vcs : https://salsa.debian.org/emacsen-team/go-mode.el >Section : lisp > > The source builds the following binary packages: > > elpa-go-mode - Emacs mode for editing Go code > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/go-mode.el/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/g/go-mode.el/go-mode.el_1.6.0+git202300823.8dce1e3-1.dsc > > Changes since the last upload: > > go-mode.el (3:1.6.0+git202300823.8dce1e3-1) unstable; urgency=medium > . >* Team upload. >* Sync to latest upstream head (8dce1e3). >* Apply patch to drop duplicated test (Closes: #1052922). >* Drop Built-Using which should not be used on an "arch:all" package. >* Add DEP5 headers for fix-test-path.patch. >* Update year and add Upstream-Contact in d/copyright. >* Use git mode and fix lintian warnings in d/watch. > > Regards, The previous uploads had a typo in the version number. This has been fixed in the latest upload. -- Xiyue Deng
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Hi Arto, Bo,
Xiyue Deng writes:
> Hi Bo,
>
> Bo YU writes:
>
>> Hi!
>>
>> On Wed, Oct 25, 2023 at 5:06 PM Arto Jantunen wrote:
>>>
>>> Xiyue Deng writes:
>>>
>>> > Arto Jantunen writes:
>>> >
>>> >> Xiyue Deng writes:
>>> >>
>>> >>> Hi Arto,
>>> >>>
>>> >>> Arto Jantunen writes:
>>> >>>
>>> >>>> Xiyue Deng writes:
>>> >>>>> Package: sponsorship-requests
>>> >>>>> Severity: important
>>> >>>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>> >>>>>
>>> >>>>> Dear mentors,
>>> >>>>>
>>> >>>>> I am looking for a sponsor for my package "lsp-mode":
>>> >>>>>
>>> >>>>> * Package name : lsp-mode
>>> >>>>>Version : 8.0.0-6
>>> >>>>>Upstream contact : Vibhav Pant
>>> >>>>> * URL : https://github.com/emacs-lsp/lsp-mode
>>> >>>>> * License : GPL-3+
>>> >>>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>> >>>>>Section : lisp
>>> >>>>>
>>> >>>>> The source builds the following binary packages:
>>> >>>>>
>>> >>>>> elpa-lsp-mode - Emacs client/library for the Language Server
>>> >>>>> Protocol
>>> >>>>>
>>> >>>>> To access further information about this package, please visit the
>>> >>>>> following URL:
>>> >>>>>
>>> >>>>> https://mentors.debian.net/package/lsp-mode/
>>> >>>>>
>>> >>>>> Alternatively, you can download the package with 'dget' using this
>>> >>>>> command:
>>> >>>>>
>>> >>>>> dget -x
>>> >>>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>> >>>>>
>>> >>>>> Changes since the last upload:
>>> >>>>>
>>> >>>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>>> >>>>> .
>>> >>>>>* Add patch to fix test failures (Closes: #1052939).
>>> >>>>>* Update Standards-Version to 4.6.2. No change needed.
>>> >>>>>* Add myself as uploader (Closes: #1042568).
>>> >>>>>* Add signing key verification to d/watch.
>>> >>>>>* Add d/upstream/metadata.
>>> >>>>>* Add Upstream-Contact and update year in d/copyright.
>>> >>>>>* Add patch to fix non-UTF-8 encoding.
>>> >>>>>* Drop unused lintian overrides.
>>> >>>>
>>> >>>> Thanks for taking over this package.
>>> >>>>
>>> >>>> When I try to build this (under sbuild) I get the following build
>>> >>>> failure:
>>> >>>>
>>> >>>> Test ‘lsp-text-document-hover-request’ redefined
>>> >>>>
>>> >>>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>> >>>> mapbacktrace(#f(compiled-function (evald func args flags) #>> >>>> -0x187de6214517952>))
>>> >>>> debug-early-backtrace()
>>> >>>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>>> >>>> redefined"))
>>> >>>> error("Test `%s' redefined" lsp-text-document-hover-request)
>>> >>>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>> >>>> lsp-text-document-hover-request :documentation nil :body (closure (t)
>>> >>>> nil
>>> >>>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures"))
>>> >>>> (find-file
>>> >>>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp)
>>> >>>> (deferred:sync!
>>> >>>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq
>>> >>>> 'initialized
>>> >>>&g
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Hi Sean, Thanks for the review! I initially thought d/changelog should mainly be about user-facing changes. But looks like it's better to be thorough. Please see replies inline below. Sean Whitton writes: > control: tag -1 + moreinfo > control: owner -1 ! > > Hello Xiyue, > > Thank you for working on this. > A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a: > > I'm wondering why you've updated git watch to check for the git HEAD, > since upstream seems to now be tagging releases? > I could have mixed the impression with other repos that don't have it. Now tracking tags and slightly modernize it using "@ANY_VERSION@". > The changelog should mention the switch d/compat -> debhelper-compat. > Done. > The typo fix in d/control should be mentioned in d/changelog. > Done. > You should say that it's --parallel that you dropped from d/rules. > Done. > Your justification for dropping the Built-Using should not be that > Lintian suggested dropping it. Please determine the real reason :) I thought mentioning dropping Built-Using from arch:all package could be an acceptable reason, which in turn also follows Lintian's suggestion :) But do let me know if I should further clarify. New updates pushed to team repo and reuploaded to mentors. PTAL. TIA! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054422: RFS: pointback/0.2-5 [RC] [Team] -- restore window points when returning to buffers
Tobias Frost writes: > On Mon, Oct 23, 2023 at 10:12:50AM -0700, Xiyue Deng wrote: >> Package: sponsorship-requests >> Severity: important >> X-Debbugs-CC: debian-emac...@lists.debian.org >> >> Dear mentors, >> >> I am looking for a sponsor for my package "pointback": >> >> * Package name : pointback >>Version : 0.2-5 >>Upstream contact : Markus Triska >> * URL : https://www.metalevel.at/pointback/ >> * License : GPL-3+ >> * Vcs : https://salsa.debian.org/emacsen-team/pointback >>Section : lisp >> >> The source builds the following binary packages: >> >> elpa-pointback - restore window points when returning to buffers >> >> To access further information about this package, please visit the following >> URL: >> >> https://mentors.debian.net/package/pointback/ >> >> Alternatively, you can download the package with 'dget' using this command: >> >> dget -x >> https://mentors.debian.net/debian/pool/main/p/pointback/pointback_0.2-5.dsc >> >> Changes since the last upload: >> >> pointback (0.2-5) unstable; urgency=medium >> . >>* Team upload. >> . >>[ Nicholas D Steeves ] >> * Drop emacs24 and emacs25 from Enhances (packages do not exist in >> bullseye). >> . >>[ Debian Janitor ] >>* Bump debhelper from old 10 to 13. >>* Set debhelper-compat version in Build-Depends. >> . >>[ Xiyue Deng ] >>* Add patch migrate-from-removed-assoc-el.patch to migrate from >> obsoleted functions in assoc.el which has been removed since Emacs >> 29.1 (Closes: #1042900). >>* Drop Built-Using which should not be used for an "arch: all" package. >>* Update Standards-Version to 4.6.2. No change needed. >>* Drop emacs version in Recommends which is from oldoldstable. >>* Add d/watch with comments of no real upstream version control. >>* Update d/copyright year and add Upstream-Contact. >> >> Regards, >> -- >> Xiyue Deng > > Looks good, but one question: > Upstream says: > > As of Emacs 26.1, switch-to-buffer-preserve-window-point defaults to t, which > solves the problem that pointback.el addresses. > Indeed, I've tested that this flag enables the same effect of pointback.el. > Is this pacakge (pointback) obsolete and should it be kept in Debian? > Will file an RM request. Thanks for looking into this! > (As the package is fine, I'm uploadig it, but if it is obsolete, please > file a bug for removal.) > > > Please also investiate: > I: elpa-pointback: wrong-section-according-to-package-name lisp => editors -- Xiyue Deng
Bug#1055351: RM: pointback -- RoQA; obsolete
Tobias Frost writes: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: pointb...@packages.debian.org, Xiyue Deng > Control: affects -1 + src:pointback > > During sponsoring of pointback I found this message upstream: > >> As of Emacs 26.1, switch-to-buffer-preserve-window-point defaults to t, >> which solves the problem that pointback.el addresses. > > Xiyue confirmed that this is the case, so I guess pointback should be retired. Thanks Tobias! Also adding Sean who is the uploader to CC as a FYI. -- Xiyue Deng
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "clojure-mode": * Package name : clojure-mode Version : 5.18.0-1 Upstream contact : Bozhidar Batsov * URL : https://github.com/clojure-emacs/clojure-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/clojure-mode Section : lisp The source builds the following binary packages: elpa-clojure-mode - Emacs major mode for Clojure code elpa-clojure-mode-extra-font-locking - extra font-locking for clojure-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/clojure-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/clojure-mode/clojure-mode_5.18.0-1.dsc Changes since the last upload: clojure-mode (5.18.0-1) unstable; urgency=medium . * Team upload. . [ Sean Whitton ] * New upstream release. * Update path in d/elpa-test. * Update copyright years. . [ Nicholas D Steeves ] * Drop emacs25 from Enhances (package does not exist in bullseye). . [ Xiyue Deng ] * New upstream release (Closes: #1052961). * Refresh patches. * Migrate from d/compat to debhelper-compat version 13. * Drop emacs version requires as they were met since oldoldstable. * Update Standards-Version to 4.6.2. No change needed. * Modernize d/watch using special strings. * Add d/upstream/metadata. * Update year and add Upstream-Contact in d/copyright. * Add d/gbp.conf. Regards, -- Xiyue Deng
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Package: sponsorship-requests
Severity: important
X-Debbugs-CC: debian-emac...@lists.debian.org
Dear mentors,
I am looking for a sponsor for my package "persp-projectile":
* Package name : persp-projectile
Version : 1:1.0.0+git20210618.4e374d7-1
Upstream contact : Bozhidar Batsov
* URL : https://github.com/bbatsov/persp-projectile
* License : GPL-3+
* Vcs : https://salsa.debian.org/emacsen-team/persp-projectile
Section : lisp
The source builds the following binary packages:
elpa-persp-projectile - integrate perspective.el with projectile
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/persp-projectile/
Alternatively, you can download the package with 'dget' using this command:
dget -x
https://mentors.debian.net/debian/pool/main/p/persp-projectile/persp-projectile_1.0.0+git20210618.4e374d7-1.dsc
Changes since the last upload:
persp-projectile (1:1.0.0+git20210618.4e374d7-1) unstable; urgency=medium
.
* Team upload.
.
[ David Krauser ]
* Update maintainer email address
.
[ Dhavan Vaidya ]
* d/control: Change Vcs-{Browser,Git} URL to salsa.debian.org
.
[ Nicholas D Steeves ]
* Drop emacs24 from Enhances (package does not exist in bullseye).
.
[ Xiyue Deng ]
* Team upload.
* Sync to latest upstream head.
- Fix compatibility with elpa-perspective. Closes: #919035.
- Refresh patches.
* Update d/watch to check for head.
* Update debhelper-compat to version 13.
* Update Standards-Version to 4.6.2. No change needed.
* Drop unnecessary parameter in d/rules.
* Drop Built-Using from arch:all package as per lintian suggestion.
* Drop unused and update renamed lintian overrides.
* Update year and Upstream-Contact in d/copyright.
* Add d/upstream/metadata.
Regards,
--
Xiyue Deng
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Hi Arto,
Arto Jantunen writes:
> Xiyue Deng writes:
>> Package: sponsorship-requests
>> Severity: important
>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "lsp-mode":
>>
>> * Package name : lsp-mode
>>Version : 8.0.0-6
>>Upstream contact : Vibhav Pant
>> * URL : https://github.com/emacs-lsp/lsp-mode
>> * License : GPL-3+
>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>Section : lisp
>>
>> The source builds the following binary packages:
>>
>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>
>> To access further information about this package, please visit the following
>> URL:
>>
>> https://mentors.debian.net/package/lsp-mode/
>>
>> Alternatively, you can download the package with 'dget' using this command:
>>
>> dget -x
>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>
>> Changes since the last upload:
>>
>> lsp-mode (8.0.0-6) unstable; urgency=medium
>> .
>>* Add patch to fix test failures (Closes: #1052939).
>>* Update Standards-Version to 4.6.2. No change needed.
>>* Add myself as uploader (Closes: #1042568).
>>* Add signing key verification to d/watch.
>>* Add d/upstream/metadata.
>>* Add Upstream-Contact and update year in d/copyright.
>>* Add patch to fix non-UTF-8 encoding.
>>* Drop unused lintian overrides.
>
> Thanks for taking over this package.
>
> When I try to build this (under sbuild) I get the following build
> failure:
>
> Test ‘lsp-text-document-hover-request’ redefined
>
> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
> mapbacktrace(#f(compiled-function (evald func args flags) # -0x187de6214517952>))
> debug-early-backtrace()
> debug-early(error (error "Test ‘lsp-text-document-hover-request’
> redefined"))
> error("Test `%s' redefined" lsp-text-document-hover-request)
> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) (find-file
> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 'initialized
> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
> (goto-char
> (point-min)) (search-forward "fn1") (lsp-def-request-async
> "textDocument/hover"
> (lsp--text-document-position-params #'(lambda (contents) (let* ((fn-566
> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
> #'signal) (list (car err) (cdr err))) (let ((value-568
> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list :form
> (cons fn-566 args-567)) (if (eql value-568 'ert-form-evaluation-aborted-569)
> nil
> (list :value value-568)) (if (eql value-568 'ert-form-evaluation-aborted-569)
> nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
> -explainer- (list :explanation (apply -explainer- args-567)) nil)
> (ert--signal-should-execution form-description-570)) nil (ert-fail
> form-description-570))) value-568) (kill-buffer)
> (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
> :most-recent-result nil :expected-result-type :passed :tags nil :file-name
> "/<>/test/lsp-integration-test.el"))
> load-with-code-conversion("/<>/test/lsp-integration-test.el"
> "/<>/test/lsp-integration-test.el" nil t)
> command-line-1(("-l" "package" "--eval" "(add-to-list
> 'package-directory-list
> \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list
> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" "-f"
> "package-initialize" "-L" "clients/" "-L" "." "-L" "test" "-l"
> "test/lsp-clangd-test.el" "-l" "test/lsp-completion-test.el" "-l"
> "test/lsp-file-watch-test.el" "-l" "test/lsp-integration-test.el" "
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Arto Jantunen writes:
> Xiyue Deng writes:
>
>> Hi Arto,
>>
>> Arto Jantunen writes:
>>
>>> Xiyue Deng writes:
>>>> Package: sponsorship-requests
>>>> Severity: important
>>>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>>>
>>>> Dear mentors,
>>>>
>>>> I am looking for a sponsor for my package "lsp-mode":
>>>>
>>>> * Package name : lsp-mode
>>>>Version : 8.0.0-6
>>>>Upstream contact : Vibhav Pant
>>>> * URL : https://github.com/emacs-lsp/lsp-mode
>>>> * License : GPL-3+
>>>> * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode
>>>>Section : lisp
>>>>
>>>> The source builds the following binary packages:
>>>>
>>>> elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>>>
>>>> To access further information about this package, please visit the
>>>> following URL:
>>>>
>>>> https://mentors.debian.net/package/lsp-mode/
>>>>
>>>> Alternatively, you can download the package with 'dget' using this command:
>>>>
>>>> dget -x
>>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>>>
>>>> Changes since the last upload:
>>>>
>>>> lsp-mode (8.0.0-6) unstable; urgency=medium
>>>> .
>>>>* Add patch to fix test failures (Closes: #1052939).
>>>>* Update Standards-Version to 4.6.2. No change needed.
>>>>* Add myself as uploader (Closes: #1042568).
>>>>* Add signing key verification to d/watch.
>>>>* Add d/upstream/metadata.
>>>>* Add Upstream-Contact and update year in d/copyright.
>>>>* Add patch to fix non-UTF-8 encoding.
>>>>* Drop unused lintian overrides.
>>>
>>> Thanks for taking over this package.
>>>
>>> When I try to build this (under sbuild) I get the following build
>>> failure:
>>>
>>> Test ‘lsp-text-document-hover-request’ redefined
>>>
>>> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>> mapbacktrace(#f(compiled-function (evald func args flags) #>> -0x187de6214517952>))
>>> debug-early-backtrace()
>>> debug-early(error (error "Test ‘lsp-text-document-hover-request’
>>> redefined"))
>>> error("Test `%s' redefined" lsp-text-document-hover-request)
>>> ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
>>> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) (find-file
>>> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
>>> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 'initialized
>>> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_)
>>> (goto-char
>>> (point-min)) (search-forward "fn1") (lsp-def-request-async
>>> "textDocument/hover"
>>> (lsp--text-document-position-params #'(lambda (contents) (let* ((fn-566
>>> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>>> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>>> #'signal) (list (car err) (cdr err))) (let ((value-568
>>> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>>> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>>> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list
>>> :form
>>> (cons fn-566 args-567)) (if (eql value-568
>>> 'ert-form-evaluation-aborted-569) nil
>>> (list :value value-568)) (if (eql value-568
>>> 'ert-form-evaluation-aborted-569)
>>> nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>>> -explainer- (list :explanation (apply -explainer- args-567)) nil)
>>> (ert--signal-should-execution form-description-570)) nil (ert-fail
>>> form-description-570))) value-568) (kill-buffer)
>>> (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
>>> :most-recent-result nil :expected-result-type :passed :tags nil :file-name
>>> "/<>/test/lsp-integration-test.el"))
>>> load-with-code-conversion(&
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Hi Bo,
Bo YU writes:
> Hi!
>
> On Thu, Oct 26, 2023 at 7:02 AM Xiyue Deng wrote:
>
> ...
>>
>> For the unlikely but possible cause that tests with a long name is a
>> prefix of other tests that may trigger this issue, I have modified the
>> test name for testing purposes. Can you help get the latest upload on
>> mentors and try again? TIA.
>>
> I tried this and it seems the issue was raised with my sbuild build
> environment.
> I still got this:
> https://paste.debian.net/1296268/
>
> My sbuilderrc is here:
> https://paste.debian.net/1296269/
>
> But if use pbuilder[0] to build your package, it is ok.
> So I think your package which is no problem.
>
> BTW, I suspect the network accessing leads to the issue and I am annoy how to
> disable network access during building for sbuild.
>
> BR,
> Bo
> [0]: https://wiki.ubuntu.com/PbuilderHowto
Thanks for testing! The reason I'm interested in reproducing this error
is that in the report of the RC bug that this upload is trying to solve
- https://bugs.debian.org/1052939 - the build log from Lucas has exactly
the same error:
,
| ...
| > Test ‘lsp-text-document-hover-request’ redefined
| >
| > Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
| ...
`
But I haven't been able to reproduce this until Arto and you sent your
reports, and this being reproduced by two people makes this more
interesting. There must be something that may trigger this unlikely
error. Also I'm not sure whether the network accessing may have been
the cause as sbuild needs to download the dependencies and without
something like apt-cacher{,-ng} it does need network access for that to
happen.
I suspected that the parallel setting in $DEB_BUILD_OPTIONS may have
affected it so I copied your sbuild settings and tried again but
unfortunately it still succeeded for me. For the unlikely event and for
completeness, can you also try to turn that off in your sbuild config
and retry just in case? TIA.
>> ,
>> | $ dget -x
>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>> | $ sbuild lsp-mode_8.0.0-6.dsc
>> `
>>
>> P.S. If you can provide the failed build log and ~/.sbuildrc it may
>> still help to eliminate potential sbuild differences in our environment.
>>
>> >>
>> >> BR,
>> >> Bo
>> >>>
>> >>> --
>> >>> Arto Jantunen
>> >>>
>>
>> --
>> Xiyue Deng
--
Xiyue Deng
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "scala-mode-el": * Package name : scala-mode-el Version : 1:1.1.0+git20221025.5d7cf21-1 Upstream contact : Heikki Vesalainen * URL : https://github.com/hvesalai/emacs-scala-mode * License : SCALA-LICENSE, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/scala-mode-el Section : editors The source builds the following binary packages: elpa-scala-mode - Emacs major mode for editing scala source code scala-mode-el - transitional dummy package, scala-mode-el to elpa-scala-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scala-mode-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scala-mode-el/scala-mode-el_1.1.0+git20221025.5d7cf21-1.dsc Changes since the last upload: scala-mode-el (1:1.1.0+git20221025.5d7cf21-1) unstable; urgency=medium . * Team upload. . [ Debian Janitor ] * Set upstream metadata fields: Repository-Browse. * Update standards version to 4.6.1, no changes needed. * Set upstream metadata fields: Repository. * Update standards version to 4.6.2, no changes needed. . [ Xiyue Deng ] * Sync to latest upstream head (5d7cf21). * Override clean rules in d/rules to fix building. (Closes: #1052917) * Modernize d/watch using special substitute strings. * Add more metadata in d/upstream/metadata. * Update year and Upstream-Contact and add myself in d/copyright. * Use xz compression in d/gbp.conf. Regards, -- Xiyue Deng
Bug#1052483: emacs-gtk: rcirc doesn't rejoin channels on reconnecting
Package: emacs-gtk Version: 1:29.1+1-5~bpo12+1manphiz1 Severity: normal X-Debbugs-Cc: none, Xiyue Deng rcirc can be set up to automatically join a list of channels on connecting to a server. However, in case of network issue and rcirc reconnecting to the server, it won't rejoin those channels. A more detailed analysis and fix can be found on the upstream bug. I'll provide the patch in a follow-up email. Please note that the package version looks funny as it's built locally with the patch to confirm it works. It can be reproduced in the current packaged 28.2 or 29.1 versions. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-gtk depends on: ii emacs-bin-common 1:29.1+1-5~bpo12+1manphiz1 ii emacs-common 1:29.1+1-5~bpo12+1manphiz1 ii libacl1 2.3.1-3 ii libasound2 1.2.8-1+b1 ii libc62.36-9+deb12u1 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-2~deb12u1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgccjit0 12.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgif7 5.2.1-2.5 ii libglib2.0-0 2.74.6-2 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libgnutls30 3.7.9-2 ii libgpm2 1.20.7-10+b1 ii libgtk-3-0 3.24.37-2 ii libharfbuzz0b6.0.0+dfsg-3 ii libice6 2:1.0.10-1 ii libjansson4 2.14-2 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libm17n-01.8.0-6 ii libotf1 0.9.16-4 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-16 1.6.39-2 ii librsvg2-2 2.54.7+dfsg-1~deb12u1 ii libselinux1 3.4-1+b6 ii libsm6 2:1.2.3-1 ii libsqlite3-0 3.40.1-2 ii libsystemd0 252.12-1~deb12u1 ii libtiff6 4.5.0-6 ii libtinfo66.4-4 ii libtree-sitter0 0.20.7-1 ii libwebp7 1.2.4-0.2+deb12u1 ii libwebpdemux21.2.4-0.2+deb12u1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcomposite1 1:0.4.5-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxrender1 1:0.9.10-1.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages emacs-gtk recommends: ii fonts-noto-color-emoji 2.038-1 Versions of packages emacs-gtk suggests: ii emacs-common-non-dfsg 1:29.1+1-1~bpo12+0manphiz1 -- no debconf information
Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1
Control: tags 62 + pending Dear maintainer, I've prepared an NMU for silversearcher-ag (versioned as 2.2.0+git20200805-1.1) and uploaded it to mentors.debian.net. Please feel free to tell me if I should delay it longer. Regards. diff -Nru silversearcher-ag-2.2.0+git20200805/debian/changelog silversearcher-ag-2.2.0+git20200805/debian/changelog --- silversearcher-ag-2.2.0+git20200805/debian/changelog2020-08-04 18:55:35.0 -0700 +++ silversearcher-ag-2.2.0+git20200805/debian/changelog2023-09-21 23:41:55.0 -0700 @@ -1,3 +1,14 @@ +silversearcher-ag (2.2.0+git20200805-1.1) unstable; urgency=medium + + * Non-maintainer upload + * Enable pcre2 support to replace deprecated pcre1 (Closes: #62) +- Add d/p/enable_pcre2_support.patch cherrypicked from upstream pcre2 + branch +- Build-Depends on libpcre2-dev instead of libpcre3-dev + * Update d/copyright with copyright owners of the pcre2 patch and m4/* + + -- Xiyue Deng Thu, 21 Sep 2023 23:41:55 -0700 + silversearcher-ag (2.2.0+git20200805-1) unstable; urgency=medium * New upstream snapshot (Closes: #957798) diff -Nru silversearcher-ag-2.2.0+git20200805/debian/control silversearcher-ag-2.2.0+git20200805/debian/control --- silversearcher-ag-2.2.0+git20200805/debian/control 2020-08-04 18:55:35.0 -0700 +++ silversearcher-ag-2.2.0+git20200805/debian/control 2023-09-06 02:57:08.0 -0700 @@ -2,7 +2,7 @@ Section: utils Priority: optional Maintainer: Hajime Mizuno -Build-Depends: debhelper-compat (= 13), pkg-config, libpcre3-dev, zlib1g-dev, liblzma-dev +Build-Depends: debhelper-compat (= 13), pkg-config, libpcre2-dev, zlib1g-dev, liblzma-dev Standards-Version: 4.5.0 Homepage: https://github.com/ggreer/the_silver_searcher diff -Nru silversearcher-ag-2.2.0+git20200805/debian/copyright silversearcher-ag-2.2.0+git20200805/debian/copyright --- silversearcher-ag-2.2.0+git20200805/debian/copyright2020-08-04 18:55:35.0 -0700 +++ silversearcher-ag-2.2.0+git20200805/debian/copyright2023-09-21 23:39:19.0 -0700 @@ -7,10 +7,21 @@ Copyright: 2013-2018 Geoff Greer License: Apache-2.0 +Files: m4/* +Copyright: + 2008 Steven G. Johnson + 2011 Daniel Richard G. +License: GPL-3+ + Files: debian/* Copyright: 2013-2018 Hajime Mizuno License: Apache-2.0 +Files: debian/patches/* +Copyright: 2016 Allen Wild + 2023 Xiyue Deng +License: Apache-2.0 + License: Apache-2.0 Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. @@ -26,3 +37,17 @@ . On Debian systems, the complete text of the Apache version 2.0 license can be found in "/usr/share/common-licenses/Apache-2.0". + +License: GPL-3+ + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + . + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. diff -Nru silversearcher-ag-2.2.0+git20200805/debian/patches/enable_pcre2_support.patch silversearcher-ag-2.2.0+git20200805/debian/patches/enable_pcre2_support.patch --- silversearcher-ag-2.2.0+git20200805/debian/patches/enable_pcre2_support.patch 2020-08-04 18:55:35.0 -0700 +++ silversearcher-ag-2.2.0+git20200805/debian/patches/enable_pcre2_support.patch 2023-09-06 02:57:08.0 -0700 @@ -1,6 +1,6 @@ Description: enable pcre2 support Cherrypick and adapt patch set that adds pcre2 support. -Author: Xiyue Deng +Author: Xiyue Deng Bug-Debian: https://bugs.debian.org/62 Forwarded: not-needed Applied-Upstream: @@ -75,12 +75,13 @@ CFLAGS="$CFLAGS -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces -std=gnu89 -D_GNU_SOURCE" LDFLAGS="$LDFLAGS" -@@ -40,6 +38,25 @@ esac +@@ -40,6 +38,26 @@ esac LIBS="$PTHREAD_LIBS $LIBS" +AC_ARG_WITH([pcre2], +[AS_HELP_STRING([--with-pcre2], [Enable experimental support for libpcre2])]) ++with_pcre2=yes + +AS_IF([test "x$with_pcre2" = "xyes"], [ + PKG_CHECK_MODULES([PCRE2], [libpcre2-8], [
Bug#1052824: flycheck: FTBFS if gawk is installed
Hi Nicholas, Nicholas D Steeves writes: > Hi, > > Manphiz writes: > >> Finally got access from David. I have prepared a revision for the fix >> and uploaded to mentors[1]. Now looking for sponsors :) >> >> [1] https://mentors.debian.net/package/flycheck/ > > If you'd like me to sponsor, please refinalise, because 9222c3db occurs > after the 33~git20230824.e56e30d-2 release commit. Also, when following > best practises, that full version will appear in the release commit > message, so this is a good opportunity to dtrt and fix that. > Indeed. I've refinalized, recompiled, and reuploaded it to mentors[1]. PTAL. Will create tag once it's uploaded to unstable. > Alternatively, if you're looking for off-team sponsors, then you should > file an RFS in addition to uploading to mentors. > Still prefer to let you sponsor here ;) > Thank you for comaintaining this package :) > Happy to help :) > Regards, > Nicholas > [1] https://mentors.debian.net/package/flycheck/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1052929: yasnippet: FTBFS: make: *** [debian/rules:4: binary] Error 25
Nicholas D Steeves writes: > Control: forwarded -1 https://github.com/joaotavora/yasnippet/issues/1173 > Control: tag -1 upstream fixed-upstream > > Lucas Nussbaum writes: > >> Source: yasnippet >> Version: 0.14.0+git20200603.5cbdbf0d-2 >> Severity: serious >> Justification: FTBFS >> Tags: trixie sid ftbfs >> User: lu...@debian.org >> Usertags: ftbfs-20230925 ftbfs-trixie > > This looks like it's probably fixed upstream, and I've requested a new > tagged release there. Also, the last time either of the existing > Uploaders worked on this package was 2016, so they should be dropped at > this time. I've CCed everyone involved. > > Aymeric and Xiyue Deng, would you to take responsibility for this > package? > Glad to, or co-maintain if Aymeric is also onboard. Will take a look later this week. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1041293: elpa-boxquote: New upstream release 2.3
Amin Bandali writes: > Control: tags -1 pending > X-Debbugs-CC: Tobias Frost > > Hi Xiyue, > > Xiyue Deng writes: > >> Hi Amin, >> >> Amin Bandali writes: >> >>> Hey Manphiz, >>> >>> Thanks for the patch! >>> >>> However, looking at https://salsa.debian.org/emacsen-team/boxquote-el >>> I see we have an 'upstream' branch in the repo, for tracking latest >>> upstream commits. But it appears that for your MR you essentially >>> cherry-picked the commits from the upstream repo, resulting in >>> different commit hashes. >>> >>> But we'd like to preserve the original upstream commits, including >>> in the 'master' branch where we have the 'debian' packaging directory. >>> So, you'd want to add to your local clone of the boxquote-el repo a >>> new remote pointing to the upstream repo residing on GitHub, fetch the >>> remote, pull from its 'main' branch into our 'upstream', then merge >>> the 'v2.3' tag (now the tip of 'upstream') into our 'master' branch: >>> >>> cd boxquote-el >>> git checkout upstream >>> git remote add upstreamvcs https://github.com/davep/boxquote.el.git >>> git fetch upstreamvcs >>> git pull upstreamvcs main >>> git checkout master >>> git merge v2.3 >>> # followed by the rest of your changes (to the debian/ dir) >>> >>> You may be able to use tooling to automate this (e.g. using 'gbp' from >>> the 'git-buildpackage' package), or do it manually as shown above. >>> >>> It's a bit inconvenient since you're not [yet] a member of the Emacsen >>> team or the repository itself, so you won't be able to do this in the >>> emacsen-team/boxquote-el repo itself just yet. Please do this in your >>> own fork - push your updated 'master' and 'upstream' branches and the >>> new 'v2.3' tag - and let me know. I'll then pull your changes from >>> your fork into emacsen-team/boxquote-el. >>> >>> Lastly, once ready, would you like to try uploading your changes to >>> mentors.debian.net and open an RFS (Request for Sponsorship) bug for >>> this? It might be a useful exercise for your future contributions >>> as well. :-) (ref: https://mentors.debian.net/sponsors/rfs-howto/) >>> >>> Please let me know if anything's unclear or if you have any questions >>> or comments. >>> >>> Thanks, >>> -a >>> >> >> Thanks for the detailed instructions! This was one of the early >> packaging works and I didn't really understand the workflow back then. >> Glad to have your help! I've now reworked the merge request[1] and sync >> an upstream branch in my repo, also opened another merge request[2] for >> updating the upstream branch in the team repo. I've also built the >> package using gbp and uploaded to mentors[3]. I didn't create a tag as >> I don't think gitlab support merge requests for tags. Also I didn't >> file a separate RFS bug yet as I may have to update the changelog to >> close that bug again, or maybe I can just manually close that later. >> Anyway, would be great to have your suggestions again. >> >> Thanks again, and PTAL. >> >> [1] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/3 >> [2] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/4 >> [3] https://mentors.debian.net/package/boxquote-el/ > > Cheers, and thanks for the quick update. Looks good to me. > > I've merged both your MRs, though I did so directly, by pulling from > your fork and pushing to the corresponding branch of the main repo > under emacsen-team, to avoid merge commits (particularly important for > the 'upstream' branch where we want our history to exactly match that > of upstream repo's main branch). I also added an annotated, signed > 'debian/2.3-1' tag pointing to the latest commit, since like you said > you couldn't do that at the moment. > Makes sense. The git merge vs rebase workflows have served different purposes well. > And yeah we don't really *need* an RFS bug here, since I'm asking Tobi > to sponsor the upload for us. > Sounds good. > Tobi, would you please sponsor the upload from mentors to unstable? > https://mentors.debian.net/package/boxquote-el/ > Thanks in advance, Tobi! > Thanks, > -a -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054419: RFS: go-mode.el/3:1.6.0+git202300823.8dce1e3-1 [RC] [Team] -- Emacs mode for editing Go code
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "go-mode.el": * Package name : go-mode.el Version : 3:1.6.0+git202300823.8dce1e3-1 Upstream contact : Dominik Honnef * URL : https://github.com/dominikh/go-mode.el * License : BSD-3-clasue * Vcs : https://salsa.debian.org/emacsen-team/go-mode.el Section : lisp The source builds the following binary packages: elpa-go-mode - Emacs mode for editing Go code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/go-mode.el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/go-mode.el/go-mode.el_1.6.0+git202300823.8dce1e3-1.dsc Changes since the last upload: go-mode.el (3:1.6.0+git202300823.8dce1e3-1) unstable; urgency=medium . * Team upload. * Sync to latest upstream head (8dce1e3). * Apply patch to drop duplicated test (Closes: #1052922). * Drop Built-Using which should not be used on an "arch:all" package. * Add DEP5 headers for fix-test-path.patch. * Update year and add Upstream-Contact in d/copyright. * Use git mode and fix lintian warnings in d/watch. Regards, -- Xiyue Deng
Bug#1054420: RFS: js2-mode/0.0~git20230628.79bc78d-1 [RC] [Team] -- Emacs mode for editing Javascript programs
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "js2-mode": * Package name : js2-mode Version : 0.0~git20230628.79bc78d-1 Upstream contact : Dmitry Gutov * URL : https://github.com/mooz/js2-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/js2-mode Section : editors The source builds the following binary packages: elpa-js2-mode - Emacs mode for editing Javascript programs js2-mode - Emacs mode for editing Javascript programs (dummy package) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/js2-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/j/js2-mode/js2-mode_0.0~git20230628.79bc78d-1.dsc Changes since the last upload: js2-mode (0.0~git20230628.79bc78d-1) unstable; urgency=medium . * Team upload. . [ Debian Janitor ] * Remove constraints unnecessary since buster (oldstable): + elpa-js2-mode: Drop versioned constraint on emacsen-common (>= 2.0.8) in Depends. + elpa-js2-mode: Drop conflict with removed package js2-mode (<< 0~20150909-1) in Breaks. . [ Xiyue Deng ] * Update to new upstream version 0.0~git20230628.79bc78d (Closes: #1052865). * Update d/watch to track savannah's canonical js2-mode branch. * Update Standards-Version to 4.6.2. No change needed. * Update debhelper-compat to 13. * Simplify handling in d/rules. * Fix non-canonical URL for Vcs-Browser and drop trailing whitespace. * Use secure protocol in URL and add Upstream-Contact in d/copyright. * Update year and contributor in d/copyright. * Add d/upstream/metadata. Regards, -- Xiyue Deng
Bug#1054422: RFS: pointback/0.2-5 [RC] [Team] -- restore window points when returning to buffers
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "pointback": * Package name : pointback Version : 0.2-5 Upstream contact : Markus Triska * URL : https://www.metalevel.at/pointback/ * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/pointback Section : lisp The source builds the following binary packages: elpa-pointback - restore window points when returning to buffers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pointback/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pointback/pointback_0.2-5.dsc Changes since the last upload: pointback (0.2-5) unstable; urgency=medium . * Team upload. . [ Nicholas D Steeves ] * Drop emacs24 and emacs25 from Enhances (packages do not exist in bullseye). . [ Debian Janitor ] * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. . [ Xiyue Deng ] * Add patch migrate-from-removed-assoc-el.patch to migrate from obsoleted functions in assoc.el which has been removed since Emacs 29.1 (Closes: #1042900). * Drop Built-Using which should not be used for an "arch: all" package. * Update Standards-Version to 4.6.2. No change needed. * Drop emacs version in Recommends which is from oldoldstable. * Add d/watch with comments of no real upstream version control. * Update d/copyright year and add Upstream-Contact. Regards, -- Xiyue Deng
Bug#1053906: ITP: bison-mode -- Emacs major mode for editing lex, yacc, and bison files
Package: wnpp Owner: Xiyue Deng Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: bison-mode Version : 0.3 Upstream Author : Eric Beuscher , Wilfred Hughes * URL or Web page : https://github.com/Wilfred/bison-mode * License : GPL-2+ Description : Emacs major mode for editing lex, yacc, and bison files This package provides a GNU Emacs major mode for editing lex, yacc files, as well as their extension formats like flex, bison, and jison. It provides flex-mode, bison-mode, and jison-mode to add syntax highlighting and electric support when editing the corresponding types of files. I intend to maintain this package within the Debian Emacsen team.
Bug#1041293: elpa-boxquote: New upstream release 2.3
Tobias Frost writes: > Hi, > > I'm going to upload the package soon, but I will change d/copyrigt: > > This concerns this part of the patch: > Files: debian/* > -Copyright: (C) 2018-2020 David Bremner > -License: GPL-2+ > +Copyright: (C) 2018-2023 David Bremner > +License: GPL-3+ > > Even if GPL2+ includes GPL3+, and makes the package effecitvly > GPL3+, you cannot reclicense David's contribution, without an > ACK from David; (Such an ACK would need documentation somewhere, > e.g in d/changelog) Acknowledged. Thanks for taking a close look and the suggestions! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hi Sean, Thanks for your comments. Replies are inline below. Sean Whitton writes: > Hello, > > On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: > >> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >> also filed an RFS bug#1053987. > > Alright, pushed that to a team repo, let's work from there. > Thanks! Pushed the new changes with detailed below. > Review of 8123e6e09fa1591dc2182682661421d9be80c328: > > - d/copyright is required to say where upstream sources were obtained -- > see Debian Policy > Added in the `Source' field. Also added upstream maintainer to the `Upstream-Contact' field. > - It looks like you made up the copyright statement for Wilfred Hughes, > right? > > While he may indeed hold copyright, what the GPL requires is just that > we reproduce the copyright notices we actually find in the source. > So it's probably best to drop it for now, and consider offering a pull > request upstream. > Ah I see. So for d/copyright we need to stick to the source information. Dropped Wilfred from the list of copyright holders for now. Also opened a PR upstream for tracking[1]. > - I'd like to suggest dropping the .gitignore, because it interferes > with me uploading using dgit. Can explain more if you want. > Got it. Also dropped ".gitignore". > - description "electric support" is ambiguous. Support for doing what? > It should have been "electric indentation". Fixed now. > - in general, do you mind if when I upload I commit the 'dch -r' change > for you? I.e. the upload is signed off by me, but there'd be [ Xiyue > Deng ] in the changelog. This avoids an e-mail roundtrip. Totally up > to you. As this is the first time I attempt of ITP/RFS, I'd like to go over the steps for packaging as much as possible if OK. But AIUI this package will need to go through the NEW queue, so I guess if you sponsor my upload to mentors.d.n it may require some extra steps, then I'm OK if what you propose can save some trouble. Thanks! [1] https://github.com/Wilfred/bison-mode/issues/15 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Sean Whitton writes: > Hello, > > On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: > >> Hello, >> >> On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: >> >>> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >>> also filed an RFS bug#1053987. >> >> Alright, pushed that to a team repo, let's work from there. > > It would be a good idea to push upstream's git tags to the repo, so that > I can just type 'git deborig'. Done. The `upstream' branch should be available now. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Xiyue Deng writes: > Sean Whitton writes: > >> Hello Xiyue, >> >> On Sun 15 Oct 2023 at 04:32am -07, Xiyue Deng wrote: >> >>> Package: sponsorship-requests >>> Severity: wishlist >>> X-Debbugs-Cc: Xiyue Deng , >>> debian-emac...@lists.debian.org >>> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "bison-mode": >>> >>> * Package name : bison-mode >>>Version : 0.3-1 >>>Upstream contact : [fill in name and email of upstream] >>> * URL : https://github.com/Wilfred/bison-mode >>> * License : GPL-2+ >>> * Vcs : https://salsa.debian.org/emacsen-team/bison-mode >> >> Can you give me a git repo to clone, please? I'll create and push it to >> that team repo, then review and sponsor. > > Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have > also filed an RFS bug#1053987. > Apparently I meant the ITP bug#1053906 :P > Thanks in advance for taking a look! signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Sean Whitton writes: > Hello, > > On Sun 15 Oct 2023 at 10:46pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> Hello, >>> >>> On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: >>> >>>> Hello, >>>> >>>> On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: >>>> >>>>> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >>>>> also filed an RFS bug#1053987. >>>> >>>> Alright, pushed that to a team repo, let's work from there. >>> >>> It would be a good idea to push upstream's git tags to the repo, so that >>> I can just type 'git deborig'. >> >> Done. The `upstream' branch should be available now. > > I did mean the tags -- I myself prefer not to push an upstream branch. > The idea is that from our point of view the upstream source is > immutable, like tags, and unlike branches. But of course it's fine to > have one. Looks like I got confused about what you suggested as there was a "0.3" tag that was from the upstream repo which I assume "git deborig" can use so I thought an "upstream" may help more. I've now also pushed an "upstream/0.3" tag at the commit that matches the "0.3" tag, but not sure whether this is what you were referring to. If this works better I can remove the upstream branch to avoid further complications. Please advice. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1052824: flycheck: FTBFS if gawk is installed
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Indeed. I've refinalized, recompiled, and reuploaded it to mentors[1]. >> PTAL. Will create tag once it's uploaded to unstable. > > There was some undocumented churn with python3-sphinx, but this release > isn't at fault, and it solves an RC bug, so I went ahead and uploaded. > Please consider double checking for stuff like this in the future. You > can do this with something like > > cd $project_root > git diff $latest_tagged_version_in_the_archive -- debian > Ah indeed current version based on upstream snapshot also fixes bug#1042670[1], which is from this commit[2] I assume. I verified locally with experimental-enabled sbuild that it builds successfully. Will close that bug with a version. [1] https://bugs.debian.org/1042670 [2] https://github.com/flycheck/flycheck/commit/646de81bfef309aeb3204992ef4d129e1cb53e14 >>> Alternatively, if you're looking for off-team sponsors, then you should >>> file an RFS in addition to uploading to mentors. >>> >> >> Still prefer to let you sponsor here ;) > > Fine with me, but if no one on the team (including myself) has time, > then please keep this in mind. > > Cheers, > Nicholas > -- Xiyue Deng signature.asc Description: PGP signature
Bug#1042670: flycheck: FTBFS with Sphinx 7.1, docutils 0.20: TypeError: not all arguments converted during string formatting
Control: fixed -1 flycheck 33~git20230824.e56e30d-1 thanks Hi, Lucas Nussbaum writes: > Source: flycheck > Version: 32~git.20200527.9c435db3-4 > Severity: important > Tags: ftbfs > User: python-modules-t...@lists.alioth.debian.org > Usertags: sphinx7.1 > > Hi, > > flycheck fails to build with Sphinx 7.1 and docutils 0.20, both of which > are currently available in experimental. > > Relevant part (hopefully): >> make[2]: Entering directory '/<>/doc' >> sphinx-build -b html -d _build/doctrees -j4 . -Dflycheck_offline_html=1 >> _build/html >> Running Sphinx v7.1.1 >> making output directory... done >> Building offline documentation without external resources! >> building [mo]: targets for 0 po files that are out of date >> writing output... >> building [html]: targets for 22 source files that are out of date >> updating environment: [new config] 22 added, 0 changed, 0 removed >> >> Sphinx parallel build error: >> TypeError: not all arguments converted during string formatting >> make[2]: *** [Makefile:90: html] Error 2 > > > The full build log is available from: > http://qa-logs.debian.net/2023/07/30/exp/flycheck_32~git.20200527.9c435db3-4_unstable_sphinx-exp.log > > Please see [1] for Sphinx changelog and [2] for Docutils changelog. > > Also see [3] for the list of deprecated/removed APIs in Sphinx and possible > alternatives to them. > > Some notable changes in Sphinx 6 and Sphinx 7: > > - Sphinx no longer includes jquery.js and underscore.js by default. > Please use python3-sphinxcontrib.jquery package if you are using a custom > template and it still needs jquery. > > - The setup.py build_sphinx command was removed. Please instead call > sphinx-build or "python3 -m sphinx" directly. > > - For packages using the extlinks extension, the caption should contain > exactly one "%s" placeholder (if caption is not None). > > In case you have questions, please Cc sph...@packages.debian.org on reply. > > [1]: https://www.sphinx-doc.org/en/master/changes.html > [2]: > https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.20.1:/RELEASE-NOTES.txt > [3]: > https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx7.1;users=python-modules-t...@lists.alioth.debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=sphinx7.1=python-modules-t...@lists.alioth.debian.org=1=1=1=1#results > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > Didn't notice that the latest upstream snapshot which got packaged and uploaded already fixed this issue, which I believe is from this commit[1]. Also verified locally with experimental-enabled sbuild to be working. Marking as done with version. [1] https://github.com/flycheck/flycheck/commit/646de81bfef309aeb3204992ef4d129e1cb53e14 -- Xiyue Deng
Bug#1041293: elpa-boxquote: New upstream release 2.3
Hi Amin, Amin Bandali writes: > Hey Manphiz, > > Thanks for the patch! > > However, looking at https://salsa.debian.org/emacsen-team/boxquote-el > I see we have an 'upstream' branch in the repo, for tracking latest > upstream commits. But it appears that for your MR you essentially > cherry-picked the commits from the upstream repo, resulting in > different commit hashes. > > But we'd like to preserve the original upstream commits, including > in the 'master' branch where we have the 'debian' packaging directory. > So, you'd want to add to your local clone of the boxquote-el repo a > new remote pointing to the upstream repo residing on GitHub, fetch the > remote, pull from its 'main' branch into our 'upstream', then merge > the 'v2.3' tag (now the tip of 'upstream') into our 'master' branch: > > cd boxquote-el > git checkout upstream > git remote add upstreamvcs https://github.com/davep/boxquote.el.git > git fetch upstreamvcs > git pull upstreamvcs main > git checkout master > git merge v2.3 > # followed by the rest of your changes (to the debian/ dir) > > You may be able to use tooling to automate this (e.g. using 'gbp' from > the 'git-buildpackage' package), or do it manually as shown above. > > It's a bit inconvenient since you're not [yet] a member of the Emacsen > team or the repository itself, so you won't be able to do this in the > emacsen-team/boxquote-el repo itself just yet. Please do this in your > own fork - push your updated 'master' and 'upstream' branches and the > new 'v2.3' tag - and let me know. I'll then pull your changes from > your fork into emacsen-team/boxquote-el. > > Lastly, once ready, would you like to try uploading your changes to > mentors.debian.net and open an RFS (Request for Sponsorship) bug for > this? It might be a useful exercise for your future contributions > as well. :-) (ref: https://mentors.debian.net/sponsors/rfs-howto/) > > Please let me know if anything's unclear or if you have any questions > or comments. > > Thanks, > -a > Thanks for the detailed instructions! This was one of the early packaging works and I didn't really understand the workflow back then. Glad to have your help! I've now reworked the merge request[1] and sync an upstream branch in my repo, also opened another merge request[2] for updating the upstream branch in the team repo. I've also built the package using gbp and uploaded to mentors[3]. I didn't create a tag as I don't think gitlab support merge requests for tags. Also I didn't file a separate RFS bug yet as I may have to update the changelog to close that bug again, or maybe I can just manually close that later. Anyway, would be great to have your suggestions again. Thanks again, and PTAL. [1] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/3 [2] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/4 [3] https://mentors.debian.net/package/boxquote-el/ -- Xiyue Deng
Bug#1042568: O: lsp-mode -- Emacs client/library for the Language Server Protocol
Control: retitle -1 ITA: lsp-mode -- Emacs client/library for the Language Server Protocol thanks Hi, Arto Jantunen writes: > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-emac...@lists.debian.org > Control: affects -1 + src:lsp-mode > > Since I no longer use it (eglot is now included in Emacs and I have converted > my workflow to use it instead) I intend to orphan the lsp-mode package. The > change removing my name from Uploaders has already been applied in git. > > This is a team-maintained package, so the adoptor should either replace me in > Uploaders, or alternatively take the package out of the team's hands. > > The package description is: > A Emacs Lisp library for implementing clients for servers using Microsoft's > Language Server Protocol (v3.0)[1]. > . > The library is designed to integrate with existing Emacs IDE frameworks > (completion-at-point, xref (beginning with Emacs 25.1), flycheck, etc). > . > [1]: https://github.com/Microsoft/language-server-protocol When working on fixing RC bugs for lsp-mode I found that it was orphaned and to make lintian happy it needs a new uploader, so I'm adopting the package and preparing the fix for #1052939. Thanks! -- Xiyue Deng
Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-emac...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "lsp-mode": * Package name : lsp-mode Version : 8.0.0-6 Upstream contact : Vibhav Pant * URL : https://github.com/emacs-lsp/lsp-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode Section : lisp The source builds the following binary packages: elpa-lsp-mode - Emacs client/library for the Language Server Protocol To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsp-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc Changes since the last upload: lsp-mode (8.0.0-6) unstable; urgency=medium . * Add patch to fix test failures (Closes: #1052939). * Update Standards-Version to 4.6.2. No change needed. * Add myself as uploader (Closes: #1042568). * Add signing key verification to d/watch. * Add d/upstream/metadata. * Add Upstream-Contact and update year in d/copyright. * Add patch to fix non-UTF-8 encoding. * Drop unused lintian overrides. Regards, -- Xiyue Deng
Bug#1050605: linux-image-6.4.0-3-amd64: Unable to boot on 2009 13inch MacBook Pro
Package: src:linux Version: 6.4.11-1 Severity: grave Justification: renders package unusable The recent update of linux-image to version 6.4.0-3 causes this laptop unable to boot. As the boot was not successful I could not check the log through dmesg so I will attach a photo later. The relevant part of the error of the end of the boot messages when trying to boot in recovery mode is hand-typed below: , | [3.453462] ACPI Warning: \_SB.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20230331/nsarguments-61) | [3.454515] ACPI: \_SB_.PCI0.IXVE.IGPU: failed to evaluate _DSM | [3.455576] nouveau :02:00.0: enabling device (0002 -> 0003) | [3.456812] ACPI: \_SB_.PCI0.LGPU: Enabled at IRQ 18 ` After this the boot process stuck like when trying to boot normally. Using linux-image-6.4.0-2-amd64 and early kernel versions the laptop can boot without issues. I saw there is #1050460 reporting a similar error error on nVidia GPU but as my laptop cannot even boot I figured it may be better to file a separate bug and let the maintainer to decide whether to merge the bugs. Note that the system info is generated when booted with a 6.4.0-2 kernel. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Apple Inc. product_name: MacBookPro5,5 product_version: 1.0 chassis_vendor: Apple Inc. chassis_version: Mac-F2268AC8 bios_vendor: Apple Inc. bios_version:MBP55.88Z.00AC.B03.0906151708 board_vendor: Apple Inc. board_name: Mac-F2268AC8 board_version: ** PCI devices: 00:00.0 Host bridge [0600]: NVIDIA Corporation MCP79 Host Bridge [10de:0a82] (rev b1) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: nForce2_smbus Kernel modules: i2c_nforce2, nv_tco 00:03.3 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller [10de:0a89] (rev b1) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:04.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller [10de:0aa6] (rev b1) (prog-if 20 [EHCI]) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:06.0 USB controller [0c03]: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller [10de:0aa7] (rev b1) (prog-if 10 [OHCI]) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:06.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller [10de:0aa9] (rev b1) (prog-if 20 [EHCI]) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:08.0 Audio device [0403]: NVIDIA Corporation MCP79 High Definition Audio [10de:0ac0] (rev b1) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:09.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Bridge [10de:0aab] (rev b1) (prog-if 01 [Subtractive decode]) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn- Capabilities: 00:0a.0 Ethernet controller [0200]: NVIDIA Corporation MCP79 Ethernet [10de:0ab0] (rev b1) Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF-
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
Package: elpa-debian-el
Version: 37.10
Severity: normal
X-Debbugs-Cc: none, Xiyue Deng
I've encountered an error when using "M-x debian-bug" on certain binary
package, such as linux-image-6.4.0-3-amd64. The error backtrace look
like this:
,
| Debugger entered--Lisp error: (wrong-type-argument processp nil)
| set-process-sentinel(nil (lambda (process event)
(debian-bug-script-sentinel process event "linux-image-6.1.0-11-amd64" "normal"
"Test" nil "/tmp/debian-bug-016wM9" #)))
| debian-bug-run-bug-script("linux-image-6.1.0-11-amd64" "normal" "Test" nil)
| debian-bug-package()
| debian-bug()
| funcall-interactively(debian-bug)
| command-execute(debian-bug record)
| execute-extended-command(nil "debian-bug" "debian-bug")
| funcall-interactively(execute-extended-command nil "debian-bug"
"debian-bug")
| command-execute(execute-extended-command)
`
This happens on both stable and testing, so it's not Emacs 29.1 related.
Due to my lacking in elisp I haven't figured out a fix, but
preliminarily I suspect that in the triggering case the error originates
from [1] where "term-exec" may have failed so that the next
"get-buffer-process" returns nil which in turn caused this error at [2].
[1]
https://salsa.debian.org/emacsen-team/debian-el/-/blob/master/debian-bug.el#L892-895
[2]
https://salsa.debian.org/emacsen-team/debian-el/-/blob/master/debian-bug.el#L906
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages elpa-debian-el depends on:
ii bzip2 1.0.8-5+b1
ii dh-elpa-helper 2.0.16
ii dpkg1.21.22
ii emacsen-common 3.0.5
ii reportbug 12.0.0
ii xz-utils5.4.1-0.2
Versions of packages elpa-debian-el recommends:
ii emacs 1:28.2+1-15
ii emacs-gtk [emacs] 1:28.2+1-15
ii wget 1.21.3-1+b2
elpa-debian-el suggests no packages.
-- no debconf information
Bug#1050459: elpa-buttercup: FTBFS with Emacs 29.1
Package: elpa-buttercup Version: 1.26-4 Severity: serious X-Debbugs-Cc: none, Xiyue Deng Currently elpa-buttercup is incompatible with Emacs 29.1. As this is a testing library used by other packages, it indirectly breaks them on Emacs 29.1 as well. I have a WIP merge request[1] that sync it to the latest version that fixes this. [1] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1 -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-buttercup depends on: ii dh-elpa-helper 2.0.16 ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 ii emacsen-common 3.0.5 elpa-buttercup recommends no packages. elpa-buttercup suggests no packages. -- no debconf information
Bug#1009169: please package new emacs version 28.1
Package: emacs Followup-For: Bug #1009169 Hi Rob, Thanks for maintaining Emacs in Debian! I've been a long time Emacs user and would like to help in anyway you prefer. I had some experiences in Debian packaging a few years ago and have been relearning everything from the docs like [1] and [2]. If there's anything that I can help with (e.g. testing, bug triaging, etc.) please let me know. [1] https://www.debian.org/doc/devel-manuals#debmake-doc [2] https://www.debian.org/doc/devel-manuals#devref
Bug#1032400: virt-manager: Windows 11 VM starts to cause system lock-up after upgrading to Bookworm
Package: virt-manager Version: 1:4.1.0-2 Severity: important Dear Maintainer, I have been using a virt-manager created Windows 11 VM on Bullseye for a few years without problem. Recently after upgrading to Bookworm after soft freeze, it starts to cause my system to freeze and it does not accept any input. I've also created a cronjob that checks for network access every 5 minutes and the script stopped working once this happens, which kind of confirms that the system is locked up. The only way to solve this is to force shutdown and restart the system. Right be for I upgrade to Bookworm, I was using packages with the following versions: * virt-manager 1:3.2.0-3 * qemu 7.1+dfsg~2-bpo11+3 * Linux kernel 5.19.11-1~bpo11+1 Now * qemu 1:7.2+dfsg-4 (with other package versions below). I'm not sure whether this is an issue of virt-manager, qemu-system, or a Linux kernel. Please help triage this issue, and I'm willing to provide more information and test to further diagnose this as instructed. Thanks in advance. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-gtk-3.0 3.24.36-4 ii gir1.2-gtk-vnc-2.0 1.3.1-1 ii gir1.2-gtksource-4 4.8.4-4 ii gir1.2-libosinfo-1.0 1.10.0-2 ii gir1.2-libvirt-glib-1.0 4.0.0-2 ii gir1.2-vte-2.91 0.70.3-1 ii python3 3.11.2-1 ii python3-gi 3.42.2-3+b1 ii python3-gi-cairo 3.42.2-3+b1 ii python3-libvirt 9.0.0-1 ii virtinst 1:4.1.0-2 Versions of packages virt-manager recommends: ii gir1.2-ayatanaappindicator3-0.1 0.5.92-1 ii gir1.2-spiceclientglib-2.0 0.41-2 ii gir1.2-spiceclientgtk-3.00.41-2 ii libvirt-daemon-system9.0.0-1 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.20.5-3 ii gnome-keyring42.1-1+b1 pn python3-guestfs pn ssh-askpass ii virt-viewer 11.0-2 Versions of packages virt-manager is related to: ii libvirt-clients 9.0.0-1 ii libvirt-daemon 9.0.0-1 ii libvirt0 9.0.0-1 ii osinfo-db0.20221130-2 -- no debconf information
Bug#1041367: src:emacs: Detect default GCC version instead of hard-coding.
Source: emacs Version: 1:28.2+1-15 Severity: normal X-Debbugs-Cc: none, Xiyue Deng Dear maintainers, Currently Emacs hard-codes the GCC version - more specifically the GCC JIT version - for the native compile feature. As the default GCC version may change once in a while, it may be beneficial to avoid hard-coding the version and instead generate it using default GCC. I have prepared a merge request on salsa[1], however as inexperienced as I am this will surely look crude, but may be an okay-ish start of discussion. Thanks! [1] https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/3 -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1041293: elpa-boxquote: New upstream release 2.3
Package: elpa-boxquote Version: 2.2-1 Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Dear maintainers, A new upstream release 2.3 of boxquote is available. I've prepared a merge request on salsa[1] and it would be great if someone can review and comment. Thanks in advance! [1] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/3 -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-boxquote depends on: ii dh-elpa-helper 2.0.16 ii emacsen-common 3.0.5 Versions of packages elpa-boxquote recommends: ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 elpa-boxquote suggests no packages. -- no debconf information
Bug#1041330: elpa-with-editor: New upstream release 3.3.0
Package: elpa-with-editor Version: 3.0.5-1 Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Dear Maintainer, A new upstream release 3.3.0 of with-editor is available. I have prepared a merge request[1] on salsa. Would be great if someone can review and comment. Thanks in advance! [1] https://salsa.debian.org/emacsen-team/with-editor/-/merge_requests/3 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-with-editor depends on: ii dh-elpa-helper 2.0.16 ii emacsen-common 3.0.5 elpa-with-editor recommends no packages. elpa-with-editor suggests no packages. -- no debconf information
Bug#1036545: Missing "#include " in boost/asio/awaitable.hpp in newer GCC versions
Source: boost1.74
Version: 1.74.0+ds1-20
Severity: important
Tags: patch
When using asio, one may encounter an error when the header
"boost/asio/awaitable.hpp" is used that shows that std::exchange symbol cannot
be found. To reproduce this issue, one can use the daytime udp example from
boost.org[1] using the following meson.build file:
,
| project('daytime', 'cpp',
| default_options : ['cpp_std=c++20'])
|
| boost_dep = dependency('boost')
| default_cpp_args = ['-ggdb3', '-O2', '-Wall']
|
| executable(
| 'daytime_udp_client',
| sources : 'daytime_udp_client.cpp',
| cpp_args : default_cpp_args,
| dependencies : [
| boost_dep
| ],
| )
`
And build using "meson setup builddir && cd builddir && meson compile -v". The
error message is as follows:
,
| -*- mode: compilation; default-directory:
"/sudo:root@localhost|docker:xiyueden@programming_learning_cpp_run_e19d94e6c210:/home/xiyueden/cpp/asio/daytime/builddir/"
-*-
| Compilation started at Mon May 22 01:49:57
|
| cd builddir && meson compile -v
| INFO: autodetecting backend as ninja
| INFO: calculating backend command to run: /bin/ninja -v
| [1/2] c++ -Idaytime_udp_client.p -I. -I.. -I/usr/include
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=c++20 -O0 -g -DBOOST_ALL_NO_LIB -ggdb3 -O2 -Wall -MD -MQ
daytime_udp_client.p/daytime_udp_client.cpp.o -MF
daytime_udp_client.p/daytime_udp_client.cpp.o.d -o
daytime_udp_client.p/daytime_udp_client.cpp.o -c ../daytime_udp_client.cpp
| FAILED: daytime_udp_client.p/daytime_udp_client.cpp.o
| c++ -Idaytime_udp_client.p -I. -I.. -I/usr/include -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O0 -g -DBOOST_ALL_NO_LIB
-ggdb3 -O2 -Wall -MD -MQ daytime_udp_client.p/daytime_udp_client.cpp.o -MF
daytime_udp_client.p/daytime_udp_client.cpp.o.d -o
daytime_udp_client.p/daytime_udp_client.cpp.o -c ../daytime_udp_client.cpp
| In file included from /usr/include/boost/asio.hpp:23,
| from ../daytime_udp_client.cpp:3:
| /usr/include/boost/asio/awaitable.hpp: In constructor
‘boost::asio::awaitable::awaitable(boost::asio::awaitable&&)’:
| /usr/include/boost/asio/awaitable.hpp:68:19: error: ‘exchange’ is not a
member of ‘std’; did you mean ‘std::__atomic_impl::exchange’?
|68 | : frame_(std::exchange(other.frame_, nullptr))
| | ^~~~
| In file included from /usr/include/c++/12/bits/shared_ptr_atomic.h:33,
| from /usr/include/c++/12/memory:78,
| from /usr/include/boost/asio/associated_allocator.hpp:19,
| from /usr/include/boost/asio.hpp:20:
| /usr/include/c++/12/bits/atomic_base.h:976:7: note:
‘std::__atomic_impl::exchange’ declared here
| 976 | exchange(_Tp* __ptr, _Val<_Tp> __desired, memory_order __m)
noexcept
| | ^~~~
| ninja: build stopped: subcommand failed.
|
| Compilation exited abnormally with code 1 at Mon May 22 01:49:59
`
The GCC in use is the current in sid:
,
| Using built-in specs.
| COLLECT_GCC=gcc
| COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
| OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
| OFFLOAD_TARGET_DEFAULT=1
| Target: x86_64-linux-gnu
| Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
| Thread model: posix
| Supported LTO compression algorithms: zlib zstd
| gcc version 12.2.0 (Debian 12.2.0-14)
`
I have also tried different standard versions (11/14/17) and all shows the same
error.
The fix is to add "#include " in "boost/asio/awaitable.hpp". I'll
attach a patch. Note that the boost1.81 package already included this fix.
[1]
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/tutorial/tutdaytime4/src.html
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT
Bug#1043257: auctex: New upstream release 13.2
Package: auctex Version: 12.2-1 Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Dear maintainers, A new upstream release of auctex has been available for a while, and I've prepared a (somewhat crude) merge request[1] with refreshed patches which maybe useful as a base to work on. There are still several lintian warnings that I haven't figured out how to fix and will add new commits once those are resolved. PTAL. Thanks in advance! [1] https://salsa.debian.org/salve/auctex/-/merge_requests/2 -- Package-specific info: Content of '/usr/share/auctex' 364d5de2337d7cb3a0f572f398d061a3 /usr/share/auctex/bib-cite.el ab7fa94a4405b729aec22d88b9a8f7ee /usr/share/auctex/context.el 9bec7c2dcf0179d8a4b7bf59e9398ca2 /usr/share/auctex/context-en.el 8667f268ce0eabaa7aa99fb961be71c1 /usr/share/auctex/context-nl.el f1ea037263d610d7f15b92c79bd8cde6 /usr/share/auctex/font-latex.el f176261b5a5511cbe1401ee72ffb8947 /usr/share/auctex/images/amstex.xpm d33121019448617a3ad3bcafdeb8db40 /usr/share/auctex/images/bibtex.xpm 1a43d6438010bceb374ab0a5f2bd05a8 /usr/share/auctex/images/dropdown.xpm 41f1ae0341ae2e307d92a7b8b815f868 /usr/share/auctex/images/dvipdf.xpm 2e4b8669b0168f32247411be3f999437 /usr/share/auctex/images/dvips.xpm 55f7600cadc3a209e94bacf6bbc42a7c /usr/share/auctex/images/error.xpm 79b958849511c67d6b13ef9f5b3673e8 /usr/share/auctex/images/execbibtex.xpm a8570e26e9f96b6f527cdbe218d6c55f /usr/share/auctex/images/execdvips.xpm e647bc601aef2dc71b134a989df1adff /usr/share/auctex/images/execerror.xpm 4610ec6133f89ceb441c43dfee077361 /usr/share/auctex/images/execpdftex.xpm c9cd1fc9fe4fd122cbf900fae654a67b /usr/share/auctex/images/exectex.xpm 6a6b9af945d4735f048ea8e475f8d9b8 /usr/share/auctex/images/execviewdvi.xpm 466466f6d1867510b058a9c184ffce5d /usr/share/auctex/images/execviewpdf.xpm 39d8ccaffb40b0c118e000f45272db05 /usr/share/auctex/images/execviewps.xpm c29ad797273fd27201a40bd939a95fe0 /usr/share/auctex/images/exec.xpm 6767e2583c668dcb47495197b9e8cb65 /usr/share/auctex/images/gv.xpm ff9c61ef5148a0cacd5422d7c0d99396 /usr/share/auctex/images/jumpdvi.xpm ece6608586b591f50f20d17cdb316a1c /usr/share/auctex/images/ltx-symb-turn-off.xpm b1f10de33dcf1b5ca9ac6155c13683a3 /usr/share/auctex/images/ltx-symb-turn-on.xpm 44e35faa18ab34f3c13ac3b0082bcc47 /usr/share/auctex/images/pdftex.xpm 84673eb20ac3be7bf0eb4e84e23e828f /usr/share/auctex/images/prverr16.xpm 59e6a0dddb00ab16c4209a2e4c6e283d /usr/share/auctex/images/prverr20.xpm 225929f8131bdd7b9b8207494a59619a /usr/share/auctex/images/prverr24.xpm e1b3c9d6a6eb6fb6f096736cdfc059cf /usr/share/auctex/images/prvtex12.xpm cc4101ee6a3ab6a1f4e9991b91b3ff0b /usr/share/auctex/images/prvtex16.xpm d4dbe057a8d3b2facd61cf7583c1e97c /usr/share/auctex/images/prvtex20.xpm 28ac0855d853f606dd91e3cfacaa8a14 /usr/share/auctex/images/prvtex24.xpm 0dac3d8eb00c902037cc5fa6a03e53e3 /usr/share/auctex/images/prvtex-cap-up.xpm 6ce704103821329336489e990bc6f267 /usr/share/auctex/images/prvwrk12.xpm 5607f4e8bc0eb555206e6a3542205f45 /usr/share/auctex/images/prvwrk14.xpm 878a72cde3bb6f0ea6d586cff56e619c /usr/share/auctex/images/prvwrk16.xpm 41811748a97673381115957d42a6529b /usr/share/auctex/images/prvwrk20.xpm 9690511307f3693e6f28e4db93fdc58c /usr/share/auctex/images/prvwrk24.xpm e30a80ecb0711ceb42a2ca966ad74bbb /usr/share/auctex/images/pspdf.xpm 5cc696e2c69ae401c0c223d84d013c8e /usr/share/auctex/images/sep.xpm e975868b87770a0e1a404292a314d246 /usr/share/auctex/images/spell.xpm 861fc288565e624ce8b34c1fc42e3496 /usr/share/auctex/images/tex.xpm 8147722e0061799437edf36d4466e5ab /usr/share/auctex/images/viewdvi.xpm 67d7ed652615a027038610f8370ba172 /usr/share/auctex/images/viewpdf.xpm 000ba76725a4fb8489916250544310c7 /usr/share/auctex/images/viewps.xpm 338158cc358b16daf9b58ee54bd14bad /usr/share/auctex/images/view.xpm 8e57849ce1b32fdc79f3af9a531f3c5f /usr/share/auctex/latex.el c80a148fe783337369442e6b7bc1e9a1 /usr/share/auctex/latex-flymake.el 33695ffcb286ad2f6d4a1c141afd5997 /usr/share/auctex/multi-prompt.el bb4bd6f32da75c8abfb8b3ba2e4cb1a1 /usr/share/auctex/plain-tex.el ad9fe893c52c9aa2dc8c58d2408060d1 /usr/share/auctex/preview.el a4571ecde21c37163c25a2661be73f9e /usr/share/auctex/prv-emacs.el b2f7fec24beb1618ef9403ea480d8b24 /usr/share/auctex/style/acro.el 98172ba71dbfede787fbd8adce1fcf1a /usr/share/auctex/style/acronym.el 6372c3c56c5fde251e63f5c712bceb5d /usr/share/auctex/style/afterpage.el 9e97d5c15649144da8cf3c0c42325c56 /usr/share/auctex/style/Alegreya.el 5cf77acd7dded30324812467c9acad44 /usr/share/auctex/style/AlegreyaSans.el 06c93bf07caf76e6df0ed21184f8bc81 /usr/share/auctex/style/alltt.el e1f6ad4e33c78d334be4758c8cf45a3a /usr/share/auctex/style/alphanum.el d7929d0be7ae2a95448c3c6331910b9c /usr/share/auctex/style/amsart.el ebc0470ca534d78dca178e4487cad5c0 /usr/share/auctex/style/amsbook.el
Bug#1041824: src:volume-el: Enable merge request on salsa
Source: volume-el Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Dear maintainers, I have been trying to fix uscan error of Emacs addon packages. When working on volume-el, I found that the repo on salsa didn't accept merge requests while most other packages did. If it can open up merge request access it would be great and I have some pending d/watch fixes. Thanks in advance! -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1039451: New upstream version 2.8.0
Package: elpa-zenburn-theme Severity: wishlist Tags: patch A new upstream version (2.8.0) of zenburn theme is available. I've created a pull request at https://salsa.debian.org/emacsen-team/zenburn-emacs/-/merge_requests/2. Thanks for considering! -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-zenburn-theme depends on: ii dh-elpa-helper 2.0.16 ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 ii emacsen-common 3.0.5 Versions of packages elpa-zenburn-theme recommends: ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 elpa-zenburn-theme suggests no packages.
Bug#1032400: virt-manager: Windows 11 VM starts to cause system lock-up after upgrading to Bookworm
Package: virt-manager Followup-For: Bug #1032400 It turns out that the issue has nothing to do with virt-manager or qemu but the BIOS of the system that could cause the system to freeze when accessing the TPM[1]. Closing and sorry for the trouble. [1] https://lists.debian.org/debian-user/2023/04/msg00425.html -- 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-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-gtk-3.0 3.24.37-2 ii gir1.2-gtk-vnc-2.0 1.3.1-1 ii gir1.2-gtksource-4 4.8.4-4 ii gir1.2-libosinfo-1.0 1.10.0-2 ii gir1.2-libvirt-glib-1.0 4.0.0-2 ii gir1.2-vte-2.91 0.70.3-1 ii python3 3.11.2-1+b1 ii python3-gi 3.42.2-3+b1 ii python3-gi-cairo 3.42.2-3+b1 ii python3-libvirt 9.0.0-1 ii virtinst 1:4.1.0-2 Versions of packages virt-manager recommends: ii gir1.2-ayatanaappindicator3-0.1 0.5.92-1 ii gir1.2-spiceclientglib-2.0 0.42-1 ii gir1.2-spiceclientgtk-3.00.42-1 ii libvirt-daemon-system9.0.0-3 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.20.5-3 ii gnome-keyring42.1-1+b2 pn python3-guestfs pn ssh-askpass ii virt-viewer 11.0-2 Versions of packages virt-manager is related to: ii libvirt-clients 9.0.0-3 ii libvirt-daemon 9.0.0-3 ii libvirt0 9.0.0-3 ii osinfo-db0.20221130-2 -- no debconf information
Bug#1052939: marked as done (lsp-mode: FTBFS: make: *** [debian/rules:4: binary] Error 25)
Control: reopen -1 Control: found -1 8.0.0-6 It looks like the attempted fix in 8.0.0-6 is not reliable and still fails in ppc64el[1] and s390x[2]. I'm working on a better fix which is also forwarded upstream. [1] https://ci.debian.net/packages/l/lsp-mode/testing/ppc64el/40221847/ [2] https://ci.debian.net/packages/l/lsp-mode/testing/s390x/40222364/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1059065: RFS: lsp-mode/8.0.0+git20231219.2cdb9bc-1 [RC] -- Emacs client/library for the Language Server Protocol
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lsp-mode": * Package name : lsp-mode Version : 8.0.0+git20231219.2cdb9bc-1 Upstream contact : Vibhav Pant * URL : https://github.com/emacs-lsp/lsp-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/lsp-mode Section : lisp The source builds the following binary packages: elpa-lsp-mode - Emacs client/library for the Language Server Protocol To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsp-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0+git20231219.2cdb9bc-1.dsc Changes since the last upload: lsp-mode (8.0.0+git20231219.2cdb9bc-1) unstable; urgency=medium . * Sync to latest upstream head (2cdb9bc) (Closes: #1052939) * Drop obsolete version from Recommends and emacs25 from Enhances * Add newly required elpa-elenv to Build-Depends in d/control * Override dh auto clean to avoid using eask * Drop workaround of dh_elpa_test in favor of upstream fix * Skip test that fails in autopkgtest trying to overwrite without ACL * Allow stderr in autopkgtest * Use @builddeps@ in autopkgtest Depends to ensure B-D are available Regards, -- Xiyue Deng
Bug#1059073: RFS: debian-el/37.11 [Team] -- Emacs helpers specific to Debian users
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "debian-el":
* Package name : debian-el
Version : 37.11
Upstream contact : Debian Emacsen team
* URL : https://salsa.debian.org/emacsen-team/debian-el
* License : GPL-2+
* Vcs : https://salsa.debian.org/emacsen-team/debian-el
Section : lisp
The source builds the following binary packages:
elpa-debian-el - Emacs helpers specific to Debian users
debian-el - Transition package, debian-el to elpa-debian-el
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/debian-el/
Alternatively, you can download the package with 'dget' using this command:
dget -x
https://mentors.debian.net/debian/pool/main/d/debian-el/debian-el_37.11.dsc
Changes since the last upload:
debian-el (37.11) unstable; urgency=medium
.
* Team upload.
.
[ Salman Mohammadi ]
* apt-utils.el: fix broken example, replace emacs21 with emacs
.
[ Nicholas D Steeves ]
* Drop emacs25 from Enhances (package does not exist in bullseye).
.
[ Debian Janitor ]
* Remove constraints unnecessary since buster (oldstable):
+ elpa-debian-el: Drop versioned constraint on dpkg and reportbug in
Depends.
+ elpa-debian-el: Drop versioned constraint on emacs in Recommends.
.
[ Hermógenes Oliveira ]
* Make apt-utils-search honour apt-utils-use-current-window.
.
[ Łukasz Stelmach ]
* debian-bug.el: Highlight Control: pseudo-header
.
[ Fabrice Bauzac ]
* Fix Emacs 28.2 warnings about beginning/end-of-buffer.
+ {beginning,end}-of-buffer functions are for interactive use only.
* Fix warning about save-excursion+set-buffer.
* Fix warning about next-line.
* Fix warning about mapcar's unused return value.
* Fix byte-compilation warning about dired-load-hook.
.
[ Xiyue Deng ]
* Documentation fixes.
+ Fixes a few typos.
+ Revise some wording.
+ Stop using obsoleted versioned emacs21 in examples.
* Handle process error more gracefully (Closes: #1050685).
* Run term-exec without hooks to be more robust.
* Resolve comp warnings (Closes: #1024695, #1034734, #1037179, #1051478).
* Fix install status detection of "Multi-Arch:same" packages
(Closes: #664083).
* Update Standards-Version to 4.6.2. No change needed.
* Use secure URI in d/copyright.
* Add lintian override for info page outside of /usr/share/doc.
* Migrate to debhelper-compat version 13.
* Add "Rules-Requires-Root: no" in d/control.
* Update year in d/copyright.
* Add team as Upstream-Contact in d/copyright.
* Use dh_elpa to handle *-{autoloads,pkg}.el generations.
+ Add package info comments to debian-el.el.
+ Drop debian-autoloads.el and debian-el-pkg.el in favor of dh_elpa
generated ones.
Regards,
--
Xiyue Deng
Bug#1059074: RFS: dpkg-dev-el/37.10 [Team] -- Emacs helpers specific to Debian development
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dpkg-dev-el": * Package name : dpkg-dev-el Version : 37.10 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/dpkg-dev-el Section : lisp The source builds the following binary packages: elpa-dpkg-dev-el - Emacs helpers specific to Debian development dpkg-dev-el - Transition package, dpkg-dev-el to elpa-dpkg-dev-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dpkg-dev-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dpkg-dev-el/dpkg-dev-el_37.10.dsc Changes since the last upload: dpkg-dev-el (37.10) unstable; urgency=medium . * Team upload . [ Nicholas D Steeves ] * Drop emacs25 from Enhances (package does not exist in bullseye). . [ Amin Bandali ] * Fix a few warnings. . [ Xiyue Deng ] * Convert debian-changelog-mode file encoding to UTF-8 * Drop emacs version from recommends * Update Standards-Version to 4.6.2, no changes needed * Migrate to debhelper-compat version 13 * Mark Rules-Requires-Root as no in d/control * Use dh_elpa to generate autoloads and pkg el files * Add "Package" to debian-control-binary-fields * Fix a few more warnings Regards, -- Xiyue Deng
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Sean Whitton writes:
> Hello,
>
> On Sun 10 Dec 2023 at 09:09pm -08, Xiyue Deng wrote:
>
>> So a little further reading from the policy[1] and the lintian bug[2]
>> helped me understand the usage of "Built-Using" a bit better: it's used
>> to include other source package required for building without having to
>> depend on them. So technically it's not mutually exclusive with
>> arch:all as stated in the bug. However, in the case of
>> persp-perspective, I tried with or without it and it doesn't make any
>> difference. What's important is that ${elpa:Depends} correctly added
>> elpa-perspective and elpa-projectile to the dependency list of the
>> binary package. So I think in the end dropping it should be OK.
>>
>> Still, it makes sense to clarify the actual reason to drop it, so I've
>> updated the changelog entry to reflect this fact[3]. PTAL, TIA!
>
> Well, it's more about ensuring that those source package versions aren't
> dropped from the archive by dak, rendering us license-incompliant.
> Thanks for looking into it further. I've made a further change to your
> changelog message. Please take a look.
LGTM. Thanks!
>
> I've also noticed that there has been an upload to the archive,
> 1:0.2.0-4, which is not accounted for in our history. Please merge it
> in. 'gbp import-dsc apt:persp-projectile/sid', and then a manual merge,
> is probably what you want, because of how the patches are unapplied.
Not sure how I missed this, sorry about that. Somehow `apt source`
cannot find persp-projectile, and I see that there is actually a
"debian/1:0.2.0-4" tag created but the change is not merged to master
since I worked on it, so I just merged from the tag and resolved the
conflicts. Also rebuilt and pushed to mentors[1]. PTAL, TIA!
[1] https://mentors.debian.net/package/persp-projectile/
--
Xiyue Deng
signature.asc
Description: PGP signature
Bug#1058780: RFS: emacs-wgrep/3.0.0-3 [Team] -- edit multiple Emacs buffers with a helm-grep-mode buffer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-wgrep": * Package name : emacs-wgrep Version : 3.0.0-3 Upstream contact : Masahiro Hayashi * URL : https://github.com/mhayashi1120/Emacs-wgrep * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-wgrep Section : editors The source builds the following binary packages: elpa-wgrep - edit multiple Emacs buffers using a master grep pattern buffer elpa-wgrep-ack - edit multiple Emacs buffers using a master ack pattern buffer elpa-wgrep-ag - edit multiple Emacs buffers using a master ag pattern buffer elpa-wgrep-helm - edit multiple Emacs buffers with a helm-grep-mode buffer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-wgrep/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-wgrep/emacs-wgrep_3.0.0-3.dsc Changes since the last upload: emacs-wgrep (3.0.0-3) unstable; urgency=medium . * Team upload. * Keep wgrep-test-helper.el in autopkgtest to fix missing file issue. * Add d/upstream/metadata. * Refresh patch to more aligned with upstream applied version. Regards, -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Sean Whitton writes:
> Hello,
>
> On Fri 03 Nov 2023 at 05:01pm -07, Xiyue Deng wrote:
>
>> I thought mentioning dropping Built-Using from arch:all package could be
>> an acceptable reason, which in turn also follows Lintian's suggestion :)
>> But do let me know if I should further clarify.
>
> But why couldn't an arch:all package have Built-Using? Built-Using, per
> Policy, is for license issues. arch:any vs. arch:all isn't
> determinative.
So a little further reading from the policy[1] and the lintian bug[2]
helped me understand the usage of "Built-Using" a bit better: it's used
to include other source package required for building without having to
depend on them. So technically it's not mutually exclusive with
arch:all as stated in the bug. However, in the case of
persp-perspective, I tried with or without it and it doesn't make any
difference. What's important is that ${elpa:Depends} correctly added
elpa-perspective and elpa-projectile to the dependency list of the
binary package. So I think in the end dropping it should be OK.
Still, it makes sense to clarify the actual reason to drop it, so I've
updated the changelog entry to reflect this fact[3]. PTAL, TIA!
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999785
[3]
https://salsa.debian.org/emacsen-team/persp-projectile/-/commit/a0c39b5d53d96f7e85b163f9cb530efbf34b6166
--
Xiyue Deng
signature.asc
Description: PGP signature
Bug#1059200: RFS: elenv/0.1.0+git20231211.94cf71e-1 -- Emacs Lisp Environment Detection Library
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "elenv": * Package name : elenv Version : 0.1.0+git20231211.94cf71e-1 Upstream contact : Jen-Chieh Shen * URL : https://github.com/jcs-elpa/elenv * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/elenv Section : editors The source builds the following binary packages: elpa-elenv - Emacs Lisp Environment Detection Library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elenv/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elenv/elenv_0.1.0+git20231211.94cf71e-1.dsc Changes since the last upload: elenv (0.1.0+git20231211.94cf71e-1) unstable; urgency=medium . * Sync to latest upstream master (94cf71e). - Fix lint warnings. - Add debugging flag. Notes: according to the tracker page[1], it requires another source-only upload for it to be allowed to migrate to testing, so I took this chance to also updated to a newer upstream snapshot with more added functions. [1] https://qa.debian.org/excuses.php?package=elenv Regards, -- Xiyue Deng
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Hi Sean, Thanks for taking care of it! Please also see the replies below inline. Sean Whitton writes: > Hello, > > On Sat 09 Dec 2023 at 04:23pm GMT, Sean Whitton wrote: > >> Hello Xiyue, >> >> I made some commits before uploading. Please review. >> >> For the dgit-maint-merge(7) workflow, there is no need to manually >> refresh patches. dgit will do it for us whenever necessary. See the >> automatic commit now on the branch. Ack. Looks like I was still using the old quilt-based approach. Will take a look at how dgit does it. > > Hmm. Looks like I might have deleted some changes. Could you take a > look? Thank you. Looks like the deleted changes are the patches that dropped the package.el based installation instructions from README.md and an extra loading path of Eldev based directory. I don't think they'll matter much to be honest (especially the latter doesn't cause any issue for the tests), so please feel free to leave them as is. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1059892: qa.debian.org: uscan version too old and not using recent @ANY_VERSION@ expansion
Package: qa.debian.org User: qa.debian@packages.debian.org Usertags: udd Severity: normal Control: affects -1 tracker.debian.org The uscan used by UDD and tracker.d.o seems a little old that the @ANY_VERSION@ expansion doesn't contain the optional "v?" part. As seen by the magit-popup error[1], the @ANY_VERSION@ expands to [2], while the version in Bookworm uses [3] which works fine when I tested locally. As pointed out by doge-tech@ on IRC, this was added since uscan 2.23.2, and since 2.23.7 it uses [4] which covers more use cases. Is it possible to upgrade uscan/devscripts on those services to more recent versions? [1] https://tracker.debian.org/pkg/magit-popup [2] (?:[-_]?(\d[\-+\.:\~\da-zA-Z]*)) [3] (?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)) [4] (?:[-_]?[Vv]?(\d[\-+\.:\~\da-zA-Z]*))
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Xiyue Deng writes: > Hi Sean, > > Thanks for the review! I initially thought d/changelog should mainly be > about user-facing changes. But looks like it's better to be thorough. > Please see replies inline below. > > Sean Whitton writes: > >> control: tag -1 + moreinfo >> control: owner -1 ! >> >> Hello Xiyue, >> >> Thank you for working on this. >> A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a: >> >> I'm wondering why you've updated git watch to check for the git HEAD, >> since upstream seems to now be tagging releases? >> > > I could have mixed the impression with other repos that don't have it. > Now tracking tags and slightly modernize it using "@ANY_VERSION@". > >> The changelog should mention the switch d/compat -> debhelper-compat. >> > > Done. > >> The typo fix in d/control should be mentioned in d/changelog. >> > > Done. > >> You should say that it's --parallel that you dropped from d/rules. >> > > Done. > >> Your justification for dropping the Built-Using should not be that >> Lintian suggested dropping it. Please determine the real reason :) > > I thought mentioning dropping Built-Using from arch:all package could be > an acceptable reason, which in turn also follows Lintian's suggestion :) > But do let me know if I should further clarify. > > New updates pushed to team repo and reuploaded to mentors. PTAL. TIA! Friendly ping :) -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Nicholas D Steeves writes: >> >> >>> Have you asked upstream to tag a release? >>> >> >> Not before your review but done by now at [1] > > Thank you. You may have heard that Debian is a distribution that > privileges the stable release model... When the human maintainer of a > Debian package tracks stable releases, why is importing a snapshot > justified? > There are about 3 years of newer commits since 1.1.0, and one of the major changes is that it adds support of scala 3 syntax which is not yet in a tagged release and would be good to have. Also seeing the last commit is from the end of last year, I sense that upstream may becoming a bit dormant for the time being, which is why I prefer to package the latest snapshot instead of waiting for a stable release. > Also, do you use this package? > Not on a regular basis, but I do use it a bit once in a while as I try to learn a bit of new programming languages every few months. >>>>* Override clean rules in d/rules to fix building. (Closes: >>>>#1052917) >>> >>> I believe you already know that >>> >>> override_dh_auto_clean: >>>/bin/true >>> >>> is an incorrect approach. >>> >> >> Indeed it was not ideal. Upstream depends on Cask to generated the >> scala-mode-pkg.el file that is used in the clean target to get the name >> of the generated tarball, and indeed using this lazy approach is >> incorrect. I've now included the generated pkg file through a patch to >> make this work in [2]. > > Consistency is essential between an explanation (in a comment or > changelog) and the work that was done. > > Statically defining package metadata is fine, but in this case you can't > claim that you're generating the pkg.el file. Oh yes it's generated using Cask following upstream practice. I just include it as a patch as we don't use Cask for Debian packaging. > Either make the changelog and patch description consistent with what > is actually happening, or change the implementation so that something > is actually generated (there are multiple approaches here). I think I > tend to use makefile substvars for this. Personally I prefer not to patch upstream source if not necessary, otherwise we end up carrying the patch for the foreseeable future. Though arguably in this case the scala-mode-pkg.el file needs to be generated/patched which requires I use Cask locally, so it's more or less the same effort. And then I just realized: why not just host the scala-mode-pkg.el file and substitute the version so that we don't need to update it manually on each update? This is now implemented at [1]. > Do you see what will happen when the package is updated to > 1.1.1 or newer? Also, why did you choose to set the version to "0.23" > rather than "1.1.0"? Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version specified in scala-mode.el[2]. > Did you verify that elpa package version is consistent with the > upstream version of the Debian package in bin:elpa-scala-mode that is > consumed by users (the binary package)? > I tried install it from stable.melpa.org and yeah it's being installed as scala-mode-0.23 even if it's registered as version 1.1.0 there[3]. So it's consistent in a sense :P Anyway, I have just made a pull request to update this upstream[4] so hopefully the versioning will be sane. >>>>* Modernize d/watch using special substitute strings. >>> >>> Ok, but why? >>> >> >> I believe this provides a more robust way of detecting tags and should >> be an encouraged practices. From my own experience, when I find a >> d/watch file that doesn't work I may search for other packages to learn >> from existing practices, and some may not work well as different >> upstream may follow different conventions. The substitute strings use a >> more robust and tested regexp that works most of the time, and promoting >> its use may save people's time instead of working on an ad-hoc regexp. > > Sounds good! This is the kind of rationale that should be in the > changelog, so please add it there :) From now on, read your changelog > and patche desriptions, and imagine I'm asking you "ok, but why" for > each point. Yes, rarely something is self-evident and/or an > implementation detail, but most of the time you should say a few words > explaining "why"--particularly when you want to find a sponsor quickly. > My expectation is that you get better at this with each review, and that > you will apply everything you learned to all pending sponsorship > requests i
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Hi Nicholas, Thanks for your review! Please see my replies inline below. Nicholas D Steeves writes: > Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] > [Team] -- Emacs major mode for editing scala source code > > Xiyue Deng writes: > > [snip] >>[ Xiyue Deng ] >>* Sync to latest upstream head (5d7cf21). > > Have you asked upstream to tag a release? > Not before your review but done by now at [1] >>* Override clean rules in d/rules to fix building. (Closes: >>#1052917) > > I believe you already know that > > override_dh_auto_clean: >/bin/true > > is an incorrect approach. > Indeed it was not ideal. Upstream depends on Cask to generated the scala-mode-pkg.el file that is used in the clean target to get the name of the generated tarball, and indeed using this lazy approach is incorrect. I've now included the generated pkg file through a patch to make this work in [2]. >>* Modernize d/watch using special substitute strings. > > Ok, but why? > I believe this provides a more robust way of detecting tags and should be an encouraged practices. From my own experience, when I find a d/watch file that doesn't work I may search for other packages to learn from existing practices, and some may not work well as different upstream may follow different conventions. The substitute strings use a more robust and tested regexp that works most of the time, and promoting its use may save people's time instead of working on an ad-hoc regexp. >>* Add more metadata in d/upstream/metadata. > > https://github.com/hvesalai/emacs-scala-mode/commits/master > > is a git history log, not a changelog nor release notes. > I thought the git history log may be considered an alternative form of a Changelog. Looks like I was wrong except for projects that requires the same format across changelog/git history/release notes. I've dropped that line in [3]. >>* Update year and Upstream-Contact and add myself in d/copyright. > > Why did you add yourself? > https://en.wikipedia.org/wiki/Threshold_of_originality > > I'm happy to support your claim, but you'll need to work for it in more > than a "sweat of the brow"/mechanical sense. > To be honest, the only reason I did this is to suppress the "update-debian-copyright" lintian warning which is actually experimental. I believe what I did was in the same nature as Sławomir did in 2020 though admittedly not to the same extent, so I've reverted this part in [4]. >>* Use xz compression in d/gbp.conf. > > Why is this useful when it has been the default since gbp 0.9.15? > I'm pretty sure that if I don't add this "git deborig" will create the tarball using gzip instead. And it looks like the commit from 0.9.15 just changed the value in the comment[5]. Please let me know if there is any other option that I missed that makes it use xz. > > Best, > Nicholas > I've committed the new changes (sans "Release to unstable" commit) to the team repo and reuploaded to mentors[6]. PTAL, and TIA! [1] https://github.com/hvesalai/emacs-scala-mode/issues/182 [2] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/bc32e3dbf3983c5cf8d4eab98be25e67a9016310 [3] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/0ddf10c8e88ae0e6d52ce02968dd678aceeab6f7 [4] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/203a3d718956f14bc991b61e4bf9a02bdacd1756 [5] https://salsa.debian.org/agx/git-buildpackage/-/commit/d1960b3dc0dfbb6be2183e555e615864468b234c [6] https://mentors.debian.net/package/scala-mode-el/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Hi Paul, Paul Wise writes: > On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: > >> I think dh_auto_clean is the right place, because the build failure is >> because that the clean target requires the existence of >> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >> we need to provide this before dh_auto_clean runs. > > I think it is against ftp-master rules to have generated files > present that can't be built using only tools from Debian main. > > So I think you would need to package Cask first? Cask and similar tools like Eask and Eldev are tools that automatically install dependencies of an Emacs addon package, which doesn't use and circumvents the system package management. I think the Emacsen team chooses not to package those tools and prefers using dh-elpa for the job, and may override build target to avoid using those tools. See also [1] and [2] for some previous discussions. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837922#15 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875722#16 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1057559: emacs-wgrep: FTBFS: Error: error ("Test ‘wgrep-normal’ redefined")
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Done. Also reuploaded to mentors just in case. >> > > Thanks, I've sponsored your upload. Please push the release tag to git > at your earliest convenience. > Thanks Nicholas! Just pushed the tag 'debian/3.0.0-2' to team repo. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1056939: auctex: auctex is incompatible with use-package/elpa
Package: auctex Severity: normal X-Debbugs-Cc: none, Xiyue Deng Hi, auctex is not compatible use-package / elpa handling. As a use-package user, after installing auctex from Debian, it will try to install auctex from elpa.gnu.org nonetheless. This is because the current auctex layout doesn't follow elpa convention so that it cannot be detected by use-package. It would be great to make it compatible so that use-package users don't have to install auctex twice. I have attempted to convert auctex to use dh-elpa and prepared a MR[1], please review. Thanks in advance for considering! [1] https://salsa.debian.org/salve/auctex/-/merge_requests/3 -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Nicholas D Steeves writes: > Hi, > > Paul Wise writes: > >> On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: >> >>> I think dh_auto_clean is the right place, because the build failure is >>> because that the clean target requires the existence of >>> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >>> we need to provide this before dh_auto_clean runs. > > The generation of this metadata, and file, is one of dh_elpa's primary > functions. See the section of the dh_elpa man page that discusses > DEB_VERSION_UPSTREAM. Ah I see what you mean: as long as dh_elpa can detect the version correctly we don't need to provide an actual *-pkg.el file and can just let dh_elpa generate it, which also avoids the potential policy violation Paul pointed out. So now I make override_dh_auto_clean to call dh_elpa to generate this file for use. However, as the generated file is "buried" pretty deep in the generated directory, the command becomes pretty long, but it works. Admittedly that requiring a generated file during clean is pretty exotic and I haven't encountered it elsewhere (yet) which is good. New handling strategy pushed to team repo. PTAL. > > Read Policy §4.9 closely; Cask cannot be used. > > Grep the buildlog for "dh_" and if you'd like to see a more > comprehensive list of applicable entry points in the sequence, try > > $ dh binary-indep --no-act > > It's also worth reading the dh man page. Ack. > >> I think it is against ftp-master rules to have generated files >> present that can't be built using only tools from Debian main. > > Yes, and thank you for bringing this up. > >> So I think you would need to package Cask first? > > Cask is not relevant nor needed, and dh_elpa is used. Whenever this > topic comes up on IRC, new contributors are briefed and are additionally > referred to the RFP for Cask, where the unsuitability of this type of > tool for Debian packaging is discussed (#837922). It's also worth > noting that dh_elpa was written by people by current and/or past members > of the Debian TC. > > Xiyue Deng writes: > >> Cask and similar tools like Eask and Eldev are tools that automatically >> install dependencies of an Emacs addon package, which doesn't use and >> circumvents the system package management. I think the Emacsen team >> chooses not to package those tools and prefers using dh-elpa for the >> job, and may override build target to avoid using those tools. > > If you're familiar with the concept of "hats", then when you're working > on debian/* you need to put on your Debian packaging hat, and when > you're working on !(debian/*) you use your upstream > development/debugging/packaging hat. These tools are not relevant to > Debian packaging and referring to them is not useful for describing > packaging problems or decisions; there will always be a more direct and > useful description. I think those external tools are not completely irrelevant but just in the sense that we do it the Debian way. Usually they provide two types of functions: 1) automatic dependency management, and 2) automatic file generation required for testing and distribution through elpa. In Debian, the former is handled by apt, and the latter by dh_elpa, and we take effort to make sure they behave the same. > > Cheers, > Nicholas > -- Xiyue Deng signature.asc Description: PGP signature
Bug#1057559: emacs-wgrep: FTBFS: Error: error ("Test ‘wgrep-normal’ redefined")
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Control: tags -1 pending >> >> Hi, >> >> I have prepared a patch[1] that fixes this issue and also forwarded it >> upstream[2]. I have also prepared the package on mentors[3]. Please >> consider reviewing and sponsoring it. TIA! >> >> [1] >> https://salsa.debian.org/emacsen-team/emacs-wgrep/-/commit/62bc99d768bcb290612b834c668f131e9f5b53f0 >> [2] https://github.com/mhayashi1120/Emacs-wgrep/pull/93 >> [3] https://mentors.debian.net/package/emacs-wgrep/ >> -- >> Xiyue Deng > > Looks good. Go ahead and finalise the package, and delete changelog:L4 > whitespace at that time. > > --N > Done. Also reuploaded to mentors just in case. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1057559: emacs-wgrep: FTBFS: Error: error ("Test ‘wgrep-normal’ redefined")
Control: tags -1 pending Hi, I have prepared a patch[1] that fixes this issue and also forwarded it upstream[2]. I have also prepared the package on mentors[3]. Please consider reviewing and sponsoring it. TIA! [1] https://salsa.debian.org/emacsen-team/emacs-wgrep/-/commit/62bc99d768bcb290612b834c668f131e9f5b53f0 [2] https://github.com/mhayashi1120/Emacs-wgrep/pull/93 [3] https://mentors.debian.net/package/emacs-wgrep/ -- Xiyue Deng
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Nicholas D Steeves writes: >>> Xiyue Deng writes: >>>> Nicholas D Steeves writes: >>>> >> >> There are about 3 years of newer commits since 1.1.0, and one of the >> major changes is that it adds support of scala 3 syntax which is not yet >> in a tagged release and would be good to have. > > Ok, you've convinced me :) Convey this information in your changelog > (that's what it's for), because the human maintainer (and any interested > users) of this package deserves to know why you made this change. Indeed, updated the changelog with this[2]. > >> Also seeing the last commit is from the end of last year, I sense that >> upstream may becoming a bit dormant for the time being, which is why I >> prefer to package the latest snapshot instead of waiting for a stable >> release. > > This can also mean that we run the risk of becoming defacto upstream if > they quit at this point, but that said, I agree it's a good cut point as > well as the right thing to do. > >>> Also, do you use this package? >>> >> >> Not on a regular basis, but I do use it a bit once in a while as I try >> to learn a bit of new programming languages every few months. > > Thanks for confirming! > > [snip] > >> And then I just realized: why not just host the scala-mode-pkg.el file >> and substitute the version so that we don't need to update it manually >> on each update? This is now implemented at [1]. > > Substvars make sense ;) > > Also, neat use of a makefile target called from within the dh sequence. > > Are you sure dh_auto_clean is the right place for this override? Skim > its man page, as well as the one for dh_clean before replying. Also, > whenever one overrides something in rules, one needs to document this in > the changelog. I think dh_auto_clean is the right place, because the build failure is because that the clean target requires the existence of scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, we need to provide this before dh_auto_clean runs. > > Please use "cp -a" so timestamps between builds will be reproducible. Done. > What is the rationale for CURDIR? From what I can tell it isn't needed > and should be dropped. I can't find a packaging suggestion on $(CURDIR), but it looks like it also works without it, so I dropped it[3]. > >>> Do you see what will happen when the package is updated to >>> 1.1.1 or newer? Also, why did you choose to set the version to "0.23" >>> rather than "1.1.0"? >> >> Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version >> specified in scala-mode.el[2]. > > I like your choice, and so what if upstream has that! Is it correct? > >>> Did you verify that elpa package version is consistent with the >>> upstream version of the Debian package in bin:elpa-scala-mode that is >>> consumed by users (the binary package)? >>> >> >> I tried install it from stable.melpa.org and yeah it's being >> installed as scala-mode-0.23 even if it's registered as version 1.1.0 >> there[3]. So it's consistent in a sense :P > > Oh my! Sorry for the convoluted sentence I wrote, and I'm impressed > that you were able to make sense of it. Yes, stable.melpa.org publishes > a scala-mode version 1.1.0 elpa package, which contains a scala-mode.el > file with "Package-Version: 0.23", and it also contains a > scala-mode-pkg.el file that overrides the Package-Version to `1.1.0`. > It is because of this pkg.el file that elpa/scala-mode-1.1.0 subdir. > > Meanwhile our elpa-scala-mode 1.1.0-* all declare 0.23, and install to a > scala-mode-0.23 subdir. Thank you for your kind optimism, that's very > gracious. > > Your work reveals that I missed this issue when reviewing 1.1.0-1, > which I appreciate having pointed out. Lets fix it in the upload you've > proposed. Somehow I didn't include this patch I submitted upstream in my last changes. This is done now[1]. > >> Anyway, I have just made a pull request to update this upstream[4] so >> hopefully the versioning will be sane. > > Thank you, and hopefully they'll agree. > >>>>>>* Modernize d/watch using special substitute strings. >>>>> >>>>> Ok, but why? >>>>> >>>> >>>> I believe this provides a more robust way of detecting tags and should >>>> be an encouraged practices. From my own experience, when I find a >>>> d/watch file that doesn't work I may search for other packages to learn >>&
Bug#1061653: RFS: dpkg-dev-el/37.11 [RC] [Team] -- Emacs helpers specific to Debian development
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "dpkg-dev-el": * Package name : dpkg-dev-el Version : 37.11 Upstream contact : Debian Emacsen Team * URL : https://salsa.debian.org/emacsen-team/dpkg-dev-el * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/dpkg-dev-el Section : lisp The source builds the following binary packages: elpa-dpkg-dev-el - Emacs helpers specific to Debian development dpkg-dev-el - Transition package, dpkg-dev-el to elpa-dpkg-dev-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dpkg-dev-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dpkg-dev-el/dpkg-dev-el_37.11.dsc Changes since the last upload: dpkg-dev-el (37.11) unstable; urgency=medium . * Team upload. * d/control: add elpa-debian-el to Build-Depends (Closes: #1061650). Regards, -- Xiyue Deng
Bug#1061650: elpa-dpkg-dev-el: fails to install: debian-bts-control.el:85:2: Error: Cannot open load file: No such file or directory, debian-bug
Control: tags -1 pending Hi Andreas, Andreas Beckmann writes: > Package: elpa-dpkg-dev-el > Version: 37.10 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install. > >>From the attached log (scroll to the bottom...): > > Setting up elpa-dpkg-dev-el (37.10) ... > Install emacsen-common for emacs > emacsen-common: Handling install of emacsen flavor emacs > Install elpa-dpkg-dev-el for emacs > install/dpkg-dev-el-37.10: Handling install of emacsen flavor emacs > install/dpkg-dev-el-37.10: byte-compiling for emacs > > In toplevel form: > debian-bts-control.el:85:2: Error: Cannot open load file: No such file or > directory, debian-bug > > In debian-changelog-mode: > debian-changelog-mode.el:1382:4: Warning: `easy-menu-add' is an obsolete > function (as of 28.1); this was always a no-op in Emacs and can be safely > removed. > debian-changelog-mode.el:1382:18: Warning: reference to free variable > `debian-changelog-menu' > debian-changelog-mode.el:1423:4: Warning: `make-face' called with 2 > arguments, but accepts only 1 > debian-changelog-mode.el:1428:4: Warning: `set-face-foreground' called with > 5 arguments, but accepts only 2 or 3 > > In end of data: > debian-changelog-mode.el:1679:12: Warning: the function > `set-extent-property' is not known to be defined. > debian-changelog-mode.el:1676:25: Warning: the function `make-extent' is > not known to be defined. > debian-changelog-mode.el:1654:18: Warning: the function `delete-extent' is > not known to be defined. > debian-changelog-mode.el:1653:42: Warning: the function > `extent-end-position' is not known to be defined. > debian-changelog-mode.el:1652:42: Warning: the function > `extent-start-position' is not known to be defined. > debian-changelog-mode.el:1651:22: Warning: the function `extent-detached-p' > is not known to be defined. > debian-changelog-mode.el:1625:14: Warning: the function `set-keymap-name' > is not known to be defined. > debian-changelog-mode.el:880:4: Warning: the function > `debian-bug-build-bug-menu' is not known to be defined. > > In toplevel form: > debian-control-mode.el:198:11: Warning: `max-specpdl-size' is an obsolete > variable (as of 29.1). > debian-control-mode.el:206:11: Warning: `max-specpdl-size' is an obsolete > variable (as of 29.1). > > In debian-control-mode: > debian-control-mode.el:269:4: Warning: `easy-menu-add' is an obsolete > function (as of 28.1); this was always a no-op in Emacs and can be safely > removed. > debian-control-mode.el:270:34: Warning: reference to free variable > `goto-address-highlight-p' > > In end of data: > debian-control-mode.el:424:28: Warning: the function `position' is not > known to be defined. > debian-control-mode.el:408:43: Warning: the function `subseq' is not known > to be defined. > > In debian-copyright-mode: > debian-copyright.el:76:16: Warning: reference to free variable > `goto-address-highlight-p' > > In toplevel form: > dpkg-dev-el.el:118:44: Warning: reference to free variable `filename' > > In readme-debian-update-timestamp: > readme-debian.el:64:2: Warning: docstring wider than 80 characters > readme-debian.el:67:6: Warning: `goto-line' is for interactive use only; > use `forward-line' instead. > > In readme-debian-mode: > readme-debian.el:119:14: Warning: `write-contents-hooks' is an obsolete > variable (as of 22.1); use `write-contents-functions' instead. > > In end of data: > readme-debian.el:118:8: Warning: the function `make-local-hook' is not > known to be defined. > ERROR: install script from elpa-dpkg-dev-el package failed > dpkg: error processing package elpa-dpkg-dev-el (--configure): >installed elpa-dpkg-dev-el package post-installation script subprocess > returned error exit status 1 > Errors were encountered while processing: >elpa-dpkg-dev-el > > > Cheers, > > Andreas > > Thanks for detecting the bug! It looks like without byte-compiling we weren't able to detect such issue when building. I have added the missing dependency of elpa-debian-el[1] and prepared another version on mentors[2] for which I would need a sponsor. TIA! [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/5d6a77b97440ee9da7d0209bf7e7579506c8b8b2 [2] https://mentors.debian.net/package/dpkg-dev-el/ -- Xiyue Deng
Bug#1043257: auctex: New upstream release 13.2
Hi Davide, "Davide G. M. Salvetti" writes: > tags 1043257 +confirmed +pending > thanks > >>>>>> XD == Xiyue Deng [2023-8-7] > > [...] > > XD> Dear maintainers, > > XD> A new upstream release of auctex has been available for a while, and > XD> I've prepared a (somewhat crude) merge request[1] with refreshed > XD> patches which maybe useful as a base to work on. > > Dear Xiyue, > > I reviewed your work: the patches have to be refreshed the way you did, > thanks. I'm working on 13.2 packaging right now and will upload soon. > > XD> There are still several lintian warnings that I haven't figured out > XD> how to fix > > I've worked on and fixed them. Glad to see you started working on this! BTW, would you consider maintaining auctex with the Emacsen team? I'm also considering elpify auctex so that it's compatible with use-package. Would be great if you are open to collaboration. -- Xiyue Deng
Bug#1055827: ITP: elenv -- Emacs Lisp Environment Detection Library
Xiyue Deng writes: > Package: wnpp > Owner: Xiyue Deng > Severity: wishlist > > * Package name: elenv > Version : 0.1.0+git20231106.e7619ff > Upstream Author : Jen-Chieh Shen > * URL or Web page : g...@github.com:jcs-elpa/elenv.git > * License : GPL-3+ > Description : Emacs Lisp Environment Detection Library > > Elenv is an Emacs Lisp library that provides a consistent interface to > detect operating sytem types, graphic environments, environmental > variables, executables, etc. > > I intent to maintain this within the Debian Emacsen team. Forgot to mention that this package is a dependency of newer lsp-mode package. More packages will potentially use this in the future as well. -- Xiyue Deng
Bug#1055827: ITP: elenv -- Emacs Lisp Environment Detection Library
Package: wnpp Owner: Xiyue Deng Severity: wishlist * Package name: elenv Version : 0.1.0+git20231106.e7619ff Upstream Author : Jen-Chieh Shen * URL or Web page : g...@github.com:jcs-elpa/elenv.git * License : GPL-3+ Description : Emacs Lisp Environment Detection Library Elenv is an Emacs Lisp library that provides a consistent interface to detect operating sytem types, graphic environments, environmental variables, executables, etc. I intent to maintain this within the Debian Emacsen team.
Bug#1068847: RFS: circe/2.13-1 [RC] [Team] -- client for IRC in Emacs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "circe": * Package name : circe Version : 2.13-1 Upstream contact : Jorgen Schäfer * URL : https://github.com/jorgenschaefer/circe * License : GPL-2+, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/cgit/emacsen-team/circe.git Section : net The source builds the following binary packages: elpa-circe - client for IRC in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/circe/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/circe/circe_2.13-1.dsc Changes since the last upload: circe (2.13-1) unstable; urgency=medium . * Team upload * New upstream release * Refresh patches using quilt-fixup * Backport patch adding lexical-cast to test-tracking.el to fix tests (Closes: #1068754) * Drop Built-Using on arch:all binary package * Modernize d/watch with special strings to be more robust * Use secure copyright file specification URI. * debian/copyright: use spaces rather than tabs to start continuation lines. * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Update standards version to 4.7.0, no changes needed. * Add Upstream-Contact in d/copyright * Add "Rules-Requires-Root: no" in d/control Regards, -- Xiyue Deng
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Control: reopen -1 Xiyue Deng writes: > Hi Nicholas, > > Nicholas D Steeves writes: > >> Nicholas D Steeves writes: >> >>> This package cannot be uploaded without a human Uploader. See #1019031 >>> and current git history for more info. Either >>> >>> 1. Add yourself to Uploaders >> >> Yes, this requires a changelog entry too, in case that wasn't obvious. >> > > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. > > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? I took the liberty to opt for reopening. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1065302: Acknowledgement (RFS: elpa-rust-mode/1.0.5+git20240301.6d86af4-1 -- Major Emacs mode for editing Rust source code)
Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240329.b2b18aa-1 -- Major Emacs mode for editing Rust source code Now synced to the latest snapshot that adds support for 29.3. Team repo[1] and mentors[2] are updated accordingly. PTAL. -- Xiyue Deng [1] https://salsa.debian.org/emacsen-team/rust-mode [2] https://mentors.debian.net/package/elpa-rust-mode/
Bug#1054420: RFS: js2-mode/0.0~git20230628.79bc78d-1 [RC] [Team] -- Emacs mode for editing Javascript programs
Control: retitle -1 RFS: js2-mode/0.0~git20240310.e92829d-1 [RC] [Team] -- Emacs mode for editing Javascript programs Hi, A new snapshot was available and I have updated the package according with a few more improvements. Please find the latest package on mentors[1] and changes on salsa[2] (sans the finalizing commit.) TIA! -- Xiyue Deng [1] https://mentors.debian.net/package/js2-mode/ [2] https://salsa.debian.org/emacsen-team/js2-mode
Bug#1069137: auctex: New upstream version 13.3
Package: auctex Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Hi, A new upstream version 13.3 is available[1]. It is also a little confusing in that the auctex version on ELPA is already at 14.0.4[2]. It may worth figuring out which is the authentic upstream. I have made 2 pull requests based on the 13.3 release, one is for the upstream branch[3] and the other is for the master branch[4]. As noted in [3], a tag `upstream/13.3' should be created on upstream branch for `git deborig' to work. [1] https://www.gnu.org/software/auctex/ [2] https://elpa.gnu.org/packages/auctex.html [3] https://salsa.debian.org/salve/auctex/-/merge_requests/5 [4] https://salsa.debian.org/salve/auctex/-/merge_requests/6 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1056939: auctex: auctex is incompatible with use-package/elpa
I have made a new MR[1] using a separate branch so that I can continue to experiment on master. It also changes how *-pkg.el is generated. PTAL. -- Xiyue Deng [1] https://salsa.debian.org/salve/auctex/-/merge_requests/4
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Package: dh-elpa
Version: 2.0.17
Severity: wishlist
Hi,
Currently dh-elpa installs all *.el files directly under the root of
ELPA installation directory. This handles most ELPA packages without
issues, though there are some packages that starts to use nested
directory structures, e.g. auctex[1].
Therefore I'd like to propose to add nested directory support in
dh-elpa. I have a draft implementation that adds support for
recursively create symlink in subdirectories as well as recursive
byte-compiling. You can check it out in my salsa repo[2], and the
patches are also attached. I have tested with the work-in-progress
auctex which seems to work, but it would be good to know whether there
are any aspects that I missed from the dh-elpa handling.
Any comments are welcome.
[1] When installing elpa.gnu.org auctex will have a nested `style/'
directory, though for the auctex packaged in Debian has not been
elpafied (which I'm trying to experiment in
https://bugs.debian.org/1056939)
[2]
https://salsa.debian.org/manphiz/dh-elpa/-/tree/nested-directory-support?ref_type=heads
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-elpa depends on:
ii debhelper 13.11.4
ii emacs 1:29.3+1-2~bpo12+0manphiz1
ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1
ii libarray-utils-perl 0.5-3
ii libconfig-tiny-perl 2.28-2
ii libdebian-source-perl 0.122
ii libdpkg-perl1.21.22
ii libfile-find-rule-perl 0.34-3
ii libtext-glob-perl 0.11-3
ii perl5.36.0-7+deb12u1
dh-elpa recommends no packages.
dh-elpa suggests no packages.
-- no debconf information
>From 2df1f0d70c62e322618e7ed64515b33566c2f5f2 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Mon, 15 Apr 2024 13:03:16 -0700
Subject: [PATCH 1/3] Byte compile recursively during install to handle nested
directories
* This handles addons that have source files under nested directories
in ELPA install directories.
---
helper/install | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/helper/install b/helper/install
index 39db695..eb68ef5 100755
--- a/helper/install
+++ b/helper/install
@@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
${FLAVOR} --quick --batch -l package \
--eval "(setq package-user-dir \"/nonexistent\")" \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
- -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1
+ -f package-initialize \
+ --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1
if test $? -ne 0
then
cat Install.log
--
2.39.2
>From 5729f59dfa29bf9acda3959ff00aab179744e6d0 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 17 Apr 2024 14:06:42 -0700
Subject: [PATCH 2/3] Create symlink from elpa-src to elpa recursively
* Instead of using `ln -s', use `cp -rs' so that directories are
handled recursively.
* In remove we use `rmdir --ignore-fail-on-non-empty' so this was
handled automatically as well.
---
helper/install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/helper/install b/helper/install
index eb68ef5..8d748c8 100755
--- a/helper/install
+++ b/helper/install
@@ -50,7 +50,7 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
# policy). This makes complation easy, and also allows find-function
# and find-library to work properly. Also link all other top level
# files and directories into the flavor directory
-(cd "${elc_dir}" && ln -sf "${el_dir}"* .)
+(cd "${elc_dir}" && cp -rsf "${el_dir}"* .)
# Byte compile them
(cd "${elc_dir}"
--
2.39.2
>From b15e026ce0d4166d427aca14d3451eb9b60fb1c9 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 17 Apr 2024 14:17:41 -0700
Subject: [PATCH 3/3] Update d/changelog
---
debian/changelog | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 161b05c..20026ae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,7 +13,13 @@ dh-elpa (2.1.2) UNRELEASED; urgency=medium
* Add transient to the list of packages packaged separately as well as
provided with emacs.
- -- Xiyue Deng Sat, 06 Apr 2024 16:41:14 -0700
+ [ Xiyue Deng ]
+ * Add support for nested directory in elpa installation.
+- Byte compile recursively during install to handle nested
+ directories.
+- Create symlink from elpa-src to elpa recursively.
+
+ -- Xiyue Deng Wed, 17 Apr 2024 14:16:00 -0700
dh-elpa (2.1.1) experimental; urgency=medium
--
2.39.2
Bug#1069326: dh-elpa: Don't rename files under test directories during autopkgtest by default
Package: dh-elpa
Version: 2.0.17
Severity: normal
X-Debbugs-Cc: none, Xiyue Deng
During autopkgtest, dh_elpa_test will rename the non-test source files
so as to ensure we are running the test using the Emacs add-on modules
from the installed package instead of from the source directories. The
way that dh_elpa_test currently works is to only keep files that have a
test case defined in it. However, this doesn't take utilities and
artifacts, which are usually defined under test directories, under
consideration, and without those the tests are broken as well.
Therefore I'd like to propose retaining all files under test directories
from being renamed in autopkgtest. I have been testing a fix in [1]
which seems to work in common cases. I have also attached the patches
at the end of the email as well. Please review and comment. TIA!
[1]
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...retain-test-files-in-autopkgtest?from_project_id=18920
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-elpa depends on:
ii debhelper 13.11.4
ii emacs 1:29.3+1-2~bpo12+0manphiz1
ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1
ii libarray-utils-perl 0.5-3
ii libconfig-tiny-perl 2.28-2
ii libdebian-source-perl 0.122
ii libdpkg-perl1.21.22
ii libfile-find-rule-perl 0.34-3
ii libtext-glob-perl 0.11-3
ii perl5.36.0-7+deb12u1
dh-elpa recommends no packages.
dh-elpa suggests no packages.
-- no debconf information
>From 48514b41927f8601c6e1af7ebcf49c4af9a16b54 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Fri, 19 Apr 2024 14:14:31 -0700
Subject: [PATCH 1/2] Exclude test directories from renaming in autopkgtest by
default
* Files under test directories may also include utilities that are
used in tests but don't have any test in them. It makes sense to keep
them by default during autopkgtest to make it work out-of-the-box.
---
dh_elpa_test | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dh_elpa_test b/dh_elpa_test
index 14e31dd..b9f1152 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -271,7 +271,9 @@ if ($autopkgtest) {
my $rule = File::Find::Rule->new;
$rule
->or(File::Find::Rule
- ->name('.pc', 'debian', '.git')
+ ->name('.pc', 'debian', '.git', # exclude non-source directories
+ 'test', 'tests', # exclude test directories
+ )
->directory->prune->discard,
File::Find::Rule->new);
$rule
--
2.39.2
>From eb4f407d6c1541fda298dcfe8bcaee1fdebd5677 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Fri, 19 Apr 2024 14:24:40 -0700
Subject: [PATCH 2/2] Add more comments to describe the purpose of renaming
source files
---
dh_elpa_test | 4
1 file changed, 4 insertions(+)
diff --git a/dh_elpa_test b/dh_elpa_test
index b9f1152..c0e99e0 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -268,6 +268,10 @@ if ($autopkgtest) {
exit 0;
}
+# Compile a list of files to be renamed during autopkgtest. This usually
+# renames source *.el file outside the test directories so that during
+# autopkgtest we are testing the installed package instead of relying on
+# source files from the source directory.
my $rule = File::Find::Rule->new;
$rule
->or(File::Find::Rule
--
2.39.2
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Sean Whitton writes: > Hello, > > On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> control: tag -1 + moreinfo >>> >>> Hello Xiyue, >>> >>> Please explain the autopkgtest_keep change. Remember that autopkgtests >>> are to test the installed package. If you need to keep the .el files, >>> it must be for some reason other than because the test suite actually >>> just tests those. >>> >> >> I think this is another example of buttercup tests that requires source >> .el files to run. I'll probably open a bug on buttercup to see whether >> this is required for buttercup. Meanwhile I think it'd probably be >> better to just disable autopkgtest as the tests are already run as part >> of the build process. > > I agree. It is important not to use autopkgtest_keep without being sure > it's the right answer. > So it turns out using "disable" in d/elpa-test also disable dh_elpa_test in d/rules so that the test is not run as part of the package building, which would be suboptimal in that we don't run any test at all. I'll try to see a way to disable it only in autopkgtest in dh-elpa. On the other hand, it looks like I misjudged the situation of the buttercup tests that with "autopkgtest_keep = test/*" it just works, which is much better than disabling. >>> You've removed the Built-Using with the justification that it's an >>> arch:all package, but that doesn't make sense; Built-Using is for >>> licensing reasons, and may well be applicable to an arch:all package (I >>> think this came up before with one of your uploads?). >> >> Ah I was following the suggestions of Lintian which said it cannot be >> used by arch:all packages which is probably wrong. > > See #999785. > Ack. I also checked that bug before and wondering why that lintian tag is still enabled. Hopefully Bug#1069256 will move things forward. >> On the other hand, on a closer look at the policy regarding >> Built-Using on section 7.8[1], it has the following passage: >> >> , >> | This field should be used only when there are license or DFSG >> | requirements to retain the referenced source packages. It should not be >> | added solely as a way to locate packages that need to be rebuilt against >> | newer versions of their build dependencies. >> ` >> >> I checked that lua-mode is of GPL-2+[2], and of all its dependencies >> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL >> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using >> requirement. The change was introduced in [3] but it was part of the >> modernization effort so there is no direct justification of adding the >> field. May be I'm missing something here? > > It sounds like it shouldn't have been introduced. So you can remove it > based on your reading of Policy, and briefly note your reasoning in > d/changelog. Updated d/changelog accordingly. Also took this opportunity to add myself to uploaders. That way we don't have to deal with the "team upload" complications for sponsors. Mentors and team repo are both updated. PTAL. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20240113.4c6d636-1 [RC] [Team] -- Emacs major mode for editing scala source code Xiyue Deng writes: > Hi, > > Xiyue Deng writes: > >> Nicholas D Steeves writes: >> >>> Hi, >>> >>> Paul Wise writes: >>> >>>> On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: >>>> >>>>> I think dh_auto_clean is the right place, because the build failure is >>>>> because that the clean target requires the existence of >>>>> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >>>>> we need to provide this before dh_auto_clean runs. >>> >>> The generation of this metadata, and file, is one of dh_elpa's primary >>> functions. See the section of the dh_elpa man page that discusses >>> DEB_VERSION_UPSTREAM. >> >> Ah I see what you mean: as long as dh_elpa can detect the version >> correctly we don't need to provide an actual *-pkg.el file and can just >> let dh_elpa generate it, which also avoids the potential policy >> violation Paul pointed out. >> >> So now I make override_dh_auto_clean to call dh_elpa to generate this >> file for use. However, as the generated file is "buried" pretty deep in >> the generated directory, the command becomes pretty long, but it works. >> Admittedly that requiring a generated file during clean is pretty exotic >> and I haven't encountered it elsewhere (yet) which is good. >> >> New handling strategy pushed to team repo. PTAL. >> >>> >>> Read Policy §4.9 closely; Cask cannot be used. >>> >>> Grep the buildlog for "dh_" and if you'd like to see a more >>> comprehensive list of applicable entry points in the sequence, try >>> >>> $ dh binary-indep --no-act >>> >>> It's also worth reading the dh man page. >> >> Ack. >> >>> >>>> I think it is against ftp-master rules to have generated files >>>> present that can't be built using only tools from Debian main. >>> >>> Yes, and thank you for bringing this up. >>> >>>> So I think you would need to package Cask first? >>> >>> Cask is not relevant nor needed, and dh_elpa is used. Whenever this >>> topic comes up on IRC, new contributors are briefed and are additionally >>> referred to the RFP for Cask, where the unsuitability of this type of >>> tool for Debian packaging is discussed (#837922). It's also worth >>> noting that dh_elpa was written by people by current and/or past members >>> of the Debian TC. >>> >>> Xiyue Deng writes: >>> >>>> Cask and similar tools like Eask and Eldev are tools that automatically >>>> install dependencies of an Emacs addon package, which doesn't use and >>>> circumvents the system package management. I think the Emacsen team >>>> chooses not to package those tools and prefers using dh-elpa for the >>>> job, and may override build target to avoid using those tools. >>> >>> If you're familiar with the concept of "hats", then when you're working >>> on debian/* you need to put on your Debian packaging hat, and when >>> you're working on !(debian/*) you use your upstream >>> development/debugging/packaging hat. These tools are not relevant to >>> Debian packaging and referring to them is not useful for describing >>> packaging problems or decisions; there will always be a more direct and >>> useful description. >> >> I think those external tools are not completely irrelevant but just in >> the sense that we do it the Debian way. Usually they provide two types >> of functions: 1) automatic dependency management, and 2) automatic file >> generation required for testing and distribution through elpa. In >> Debian, the former is handled by apt, and the latter by dh_elpa, and we >> take effort to make sure they behave the same. >> >>> >>> Cheers, >>> Nicholas >>> It looks like the bug was archived so the previous mail didn't reach BTS. So unarchived, reopened, and retitle the bug with newer snapshot, and also resending the following from previous message. > > With the release of the new policy version, I have done some more clean > up to the package and update team repo and mentors. PTAL. TIA! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Sean Whitton writes: > control: tag -1 + moreinfo > > Hello Xiyue, > > Please explain the autopkgtest_keep change. Remember that autopkgtests > are to test the installed package. If you need to keep the .el files, > it must be for some reason other than because the test suite actually > just tests those. > I think this is another example of buttercup tests that requires source .el files to run. I'll probably open a bug on buttercup to see whether this is required for buttercup. Meanwhile I think it'd probably be better to just disable autopkgtest as the tests are already run as part of the build process. > You've removed the Built-Using with the justification that it's an > arch:all package, but that doesn't make sense; Built-Using is for > licensing reasons, and may well be applicable to an arch:all package (I > think this came up before with one of your uploads?). Ah I was following the suggestions of Lintian which said it cannot be used by arch:all packages which is probably wrong. On the other hand, on a closer look at the policy regarding Built-Using on section 7.8[1], it has the following passage: , | This field should be used only when there are license or DFSG | requirements to retain the referenced source packages. It should not be | added solely as a way to locate packages that need to be rebuilt against | newer versions of their build dependencies. ` I checked that lua-mode is of GPL-2+[2], and of all its dependencies lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using requirement. The change was introduced in [3] but it was part of the modernization effort so there is no direct justification of adding the field. May be I'm missing something here? -- Xiyue Deng [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using [2] Upstream switched to GPL-3+ in 2022 but we haven't packaged that yet. [3] https://salsa.debian.org/emacsen-team/lua-mode/-/commit/2e207a6835a3899f6eba0675c4763c1757335bcc signature.asc Description: PGP signature
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Sean Whitton writes: > Hello, > > On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> Hello, >>> >>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>> this bug, please? I'm not sure it's the straightforward way to do it. >>> >>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>> for the relationships. >> >> Ah indeed, I should update the versions after the Emacs 29.3 upload, >> though I think you meant "1:29.3+1-2". Also, as we are just moving >> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >> from emacs-pgtk to emacs-common but no the other way around, so I >> dropped the breaks on emacs-pgtk from emacs-common. >> >> I have updated the patch accordingly and attached here. PTAL. > > Thanks. > >> (BTW, I'm always curious about the "+1" part of the version number. I >> would expect something like "+dfsg" or "+ds" as we are dropping some >> of the non-DFSG conformant files, but why "+1"? :) > > It's just in case the DFSG split is done incorrectly and another attempt > is required -- given how complex it is. Ack, totally understandable. With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it and bumped the breaks/replaces version. PTAL. -- Xiyue Deng >From c0a4ee1d76f2206594ce9897b651bbdd22baf716 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 13 Mar 2024 10:22:46 -0700 Subject: [PATCH] Install GSettings schema in pgtk build only (Closes: #1050393) * In PGTK build it generates the GSettings schema file "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which is not needed in other variant. * Move the file from emacs-common to emacs-pgtk, and adds proper breaks/replaces to ensure a smooth upgrade. --- debian/changelog | 7 +++ debian/control | 11 +-- debian/rules | 9 - 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5d4e9f050ae..e2a31a36fcb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-3) UNRELEASED; urgency=medium + + * Team upload. + * Install GSettings schema in pgtk build only (Closes: #1050393) + + -- Xiyue Deng Wed, 13 Mar 2024 10:22:10 -0700 + emacs (1:29.3+1-2) unstable; urgency=medium * Change native-comp-async-report-warnings-errors to `silent'. diff --git a/debian/control b/debian/control index e168717089f..3c04652c769 100644 --- a/debian/control +++ b/debian/control @@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg Conflicts: emacs-gtk, emacs-lucid, emacs-nox -Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Replaces: + emacs-gtk, + emacs-lucid, + emacs-nox, + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface diff --git a/debian/rules b/debian/rules index 6250f60ea9b..205c45dff65 100755 --- a/debian/rules +++ b/debian/rules @@ -425,6 +425,9 @@ override_dh_auto_install: $(autogen_install_files) cp -a $(install_dir_pgtk)/* $(pkgdir_common) rm -r $(pkgdir_common)/usr/bin + # PGTK builds a GSettings schema that is PGTK specific and + # should not be shipped in emacs-common + rm -r $(pkgdir_common)/usr/share/glib-2.0 rm \ $(pkgdir_common)/$(libexec_dir_emacs)/hexl \ $(pkgdir_common)/$(libexec_dir_emacs)/emacs-*.pdmp \ @@ -548,7 +551,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-pgtk -ifneq (,$(findstring emacs, $(shell dh_listpackages))) +ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages))) $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk) # install desktop entries @@ -557,6 +560,10 @@ override_dh_auto_install: $(autogen_install_files) debian/emacs.desktop \ debian/emacs-term.desktop \ $(pkgdir_pgtk)/usr/share/applications/ + # install GSettings schema + install -d $(pkgdir_pgtk)/usr/share/glib-2.0 + cp -a $(install_dir_pgtk)/usr/share/glib-2.0/* \ + $(pkgdir_pgtk)/usr/share/glib-2.0 endif ## -- 2.39.2
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes: > Sean Whitton writes: > >> Hello, >> >> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: >> >>> Sean Whitton writes: >>> >>>> Hello, >>>> >>>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>>> this bug, please? I'm not sure it's the straightforward way to do it. >>>> >>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>>> for the relationships. >>> >>> Ah indeed, I should update the versions after the Emacs 29.3 upload, >>> though I think you meant "1:29.3+1-2". Also, as we are just moving >>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >>> from emacs-pgtk to emacs-common but no the other way around, so I >>> dropped the breaks on emacs-pgtk from emacs-common. >>> >>> I have updated the patch accordingly and attached here. PTAL. >> >> Thanks. >> >>> (BTW, I'm always curious about the "+1" part of the version number. I >>> would expect something like "+dfsg" or "+ds" as we are dropping some >>> of the non-DFSG conformant files, but why "+1"? :) >> >> It's just in case the DFSG split is done incorrectly and another attempt >> is required -- given how complex it is. > > Ack, totally understandable. > > With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it > and bumped the breaks/replaces version. PTAL. Rob suggested on IRC to be a bit more conservative by removing the file and remove the directories upwards recursively so that we can catch future addition to the directories more easily. The patch has been adjusted accordingly. PTAL. -- Xiyue Deng >From 400a3efac8f0d2ab02ba18ac4cb5ee2324bf7c23 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 13 Mar 2024 10:22:46 -0700 Subject: [PATCH] Install GSettings schema in pgtk build only (Closes: #1050393) * In PGTK build it generates the GSettings schema file "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which is not needed in other variant. * Move the file from emacs-common to emacs-pgtk, and adds proper breaks/replaces to ensure a smooth upgrade. --- debian/changelog | 7 +++ debian/control | 11 +-- debian/rules | 12 +++- 3 files changed, 27 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5d4e9f050ae..e2a31a36fcb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-3) UNRELEASED; urgency=medium + + * Team upload. + * Install GSettings schema in pgtk build only (Closes: #1050393) + + -- Xiyue Deng Wed, 13 Mar 2024 10:22:10 -0700 + emacs (1:29.3+1-2) unstable; urgency=medium * Change native-comp-async-report-warnings-errors to `silent'. diff --git a/debian/control b/debian/control index e168717089f..3c04652c769 100644 --- a/debian/control +++ b/debian/control @@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg Conflicts: emacs-gtk, emacs-lucid, emacs-nox -Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Replaces: + emacs-gtk, + emacs-lucid, + emacs-nox, + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface diff --git a/debian/rules b/debian/rules index 6250f60ea9b..1262e568c80 100755 --- a/debian/rules +++ b/debian/rules @@ -489,6 +489,12 @@ override_dh_auto_install: $(autogen_install_files) rm -f $(pkgdir_common)/usr/share/info/emacs/dir.old install -d $(pkgdir_common)/usr/local/share/emacs/site-lisp + + # PGTK builds a GSettings schema that is PGTK specific and + # should not be shipped in emacs-common + cd $(pkgdir_common)/usr/share \ + && rm glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml \ + && rmdir --parents glib-2.0/schemas endif ## @@ -548,7 +554,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-pgtk -ifneq (,$(findstring emacs, $(shell dh_listpackages))) +ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages))) $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk)
Bug#1065302: RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major Emacs mode for editing Rust source code)
Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major Emacs mode for editing Rust source code Another sync to latest snapshot that fixes precedence with rust-ts-mode. (Mentors[1], team repo[2].) PTAL, TIA! -- Xiyue Deng [1] https://mentors.debian.net/package/elpa-rust-mode/ [2] https://salsa.debian.org/emacsen-team/rust-mode
