Bug#1073121: ITP: emacs-lsp-docker -- LSP Docker integration for lsp-mode
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-lsp-docker Version : 0.0~git20240507.16a0cfb-1 Upstream Author : Ivan Yonchovski * URL or Web page : https://github.com/emacs-lsp/lsp-docker * License : GPL-3+ Programming lang: Emacs Lisp Description : LSP Docker integration for lsp-mode lsp-mode uses lsp-docker to run language servers in containers This is a build dependency of dap-mode. I plan to maintain this within the Debian Emacsen Team .
Bug#1074569: ITP: emacs-dape -- Debug Adapter Protocol for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dape Version : 0.13.0 Upstream Author : Daniel Pettersson * URL or Web page : https://github.com/svaante/dape * License : GPL-3+ Programming lang: Emacs Lisp Description : Debug Adapter Protocol for Emacs Dape is a debug adapter client for Emacs. The debug adapter protocol, much like its more well-known counterpart, the language server protocol, aims to establish a common API for programming tools. However, instead of functionalities such as code completions, it provides a standardized interface for debuggers. . To begin a debugging session, invoke the `dape' command. In the minibuffer prompt, enter a debug adapter configuration name from `dape-configs'. . For complete functionality, make sure to enable `eldoc-mode' in your source buffers and `repeat-mode' for more pleasant key mappings. . Package looks is heavily inspired by gdb-mi.el I intend to maintain this package in the Debian Emacsen Team. I'll need a sponsor for uploading.
Re: DD's, Debian Mentors needs you!
Soren Stoutner writes: > [[PGP Signed Part:Undecided]] > After reading a number of comments to the email below, I thought I would > provide a bit of context for this email and Phil’s excellent work on Mentors. > > Recently Phil has taken it upon himself to triage every package that requests > sponsorship on mentors.debian.net. Here is an example of the work he does: > > https://lists.debian.org/debian-mentors/2024/07/msg00032.html > > When he feels a package is ready for sponsorship, he indicates that with an > email to the list. > > https://lists.debian.org/debian-mentors/2024/07/msg00024.html > > In some cases, nobody picks these up. The email below was sent to debian- > devel with a curated list of packages that Phil has already reviewed and > feels > are ready for a DD to sponsor. > > At any point, anyone can look at all of the packages on Mentors requesting a > sponsor. > > https://mentors.debian.net/ > > But I have found Phil’s work to be very helpful, as I have limited time to > handle sponsorships. When I look at a package Phil has endorsed, I can be > sure that the simple and obvious things have already been taken care of. > > I would heartily hope that Phil continues to send periodic emails to debian- > devel with lists of packages that he considers ready, but that are > languishing > on the vine because nobody has noticed them. I would also encourage anyone > else to get involved in this process if they feel so inclined. I think that > one of the most important aspects of attracting people to Debian is to make > it > easy for someone who is not yet a DD or DM to submit packages and have them > be > reviewed promptly. There is probably nothing as demotivating to a first-time > contributor as putting a lot of effort into a package, having it be in good > shape, and then never having it be sponsored simply because it didn’t get > noticed. > > Soren > > P.S. Based on Phil’s work on Mentors and my interactions with him, I have > advocated for him to become a Debian Developer, uploading. I think his > contributions to Debian will be even more impactful when he can sponsor the > packages he feels are ready. > > https://nm.debian.org/process/1305/ > > On Saturday, July 6, 2024 6:45:33 AM MST Phil Wyett wrote: >> Hi all DD's >> >> Debian Mentors[1] always struggles to find available Debian Developers for >> final reviewing and sponsoring of packages submitted too our part of the >> project. >> >> We believe some packages are ready or very close to the quality for >> sponsorship and we would request any DD who has the time and is willing, to >> have a look at one or more of the packages below and possibly sponsor them >> into Debian. >> >> Mentors page: >> https://mentors.debian.net/package/hexwalk/ >> Request For Sponsorship (RFS): >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 >> >> Mentors page: >> https://mentors.debian.net/package/uriparser/ >> Request For Sponsorship (RFS): >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 >> >> Mentors page: >> https://mentors.debian.net/package/mailgraph/ >> Request For Sponsorship (RFS): >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 >> >> Mentors page: >> https://mentors.debian.net/package/dmidecode/ >> Request For Sponsorship (RFS): >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 >> >> Mentor page: >> https://mentors.debian.net/package/selint/ >> Request For Sponsorship (RFS): >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 >> >> Your assistance will be extremely appreciated and if announcing a few at a >> time on the 'devel' list works, this could become a weekly thing. >> >> [1] https://mentors.debian.net >> >> Regards >> >> Phil As one of those who received help from Phil who kindly helped review my packages and finding potential sponsors, I want to take this opportunity to thank Phil again for his kind works and Gianfranco for sponsoring many of my packages. With that said, I want to echo Soren's word that I believe what Phil and Gianfranco has been doing is greatly helpful for new and potential Debian Maintainers, and it would be great that this process can have more people involved and get improved to make the review and sponsor process smoother. -- Xiyue Deng
Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing
IOhannes m zmölnig (Debian GNU|Linux) writes: > [[PGP Signed Part:Undecided]] > On 9/2/24 03:19, Jonathan Kamens wrote: >> However, the pipeline is still failing, now in reprotest. For >> example >> <https://salsa.debian.org/debian/apt-listchanges/-/jobs/6215633#L1650>. >> Perhaps >> this is because I haven't yet finalized the changelog for the >> upcoming release so the trailer line is badly formatted. :shrug: > > > > nope. > it's failing, because the .deb files are not identical. > if you do not want to run reprotest locally and still have a closer > look at the differences, you can download the build-artifacts (that > is: the .deb files produced by the job at [1]) and inspect them with > diffoscope, to see that the files in the tarballs have different > timestamps (which obviously makes them non-reproducible. > > note: this is just general advice, i haven't looked at the *actual* > package. > > gfmasdr > IOhannes > > > > [1] > <https://salsa.debian.org/debian/apt-listchanges/-/jobs/6215633/artifacts/download> > > [2. OpenPGP public key --- application/pgp-keys; > OpenPGP_0xB65019C47F7A36F8.asc]... > > [[End of PGP Signed Part]] Actually you can customize the Salsa CI configuration to enable diffoscope directly[1] and the result will include the diffoscope report so that you don't have to set up diffoscope separately. [1] https://salsa.debian.org/salsa-ci-team/pipeline#customizing-reprotest -- Xiyue Deng
Bug#1080374: ITP: emacs-oauth2 -- OAuth 2.0 Authorization Protocol for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-oauth2 Version : 0.17 Upstream Author : Julien Danjou * URL or Web page : https://elpa.gnu.org/packages/oauth2.html * License : GPL-3+ Programming lang: Emacs Lisp Description : OAuth 2.0 Authorization Protocol for Emacs Implementation of the OAuth 2.0 draft. . The main entry point is `oauth2-auth-and-store' which will return a token structure. This token structure can be then used with `oauth2-url-retrieve-synchronously' or `oauth2-url-retrieve' to retrieve any data that need OAuth authentication to be accessed. . If the token needs to be refreshed, the code handles it automatically and store the new value of the access token. I will maintain this package within the Debian Emacsen Team . -- Xiyue Deng
Re: Why does Salsa use reCAPTCHA?
Piper McCorkle writes: > On Friday, 6 September 2024 11.30.44 CDT Ceppo wrote: >> I feel it's a contradiction that Debian relies on a non-free service, and >> especially that its forge is dedicated to DFSG-compliant software but forces >> its users to use a third-party, non-DFSG-compliant service to sign up and >> to connect to it whenever they load a page. > > There are also Free software CAPTCHA solutions available that we may > be able to use if we want to keep CAPTCHAs on Salsa, > e.g. [mCaptcha]. I strongly agree that we shouldn't be requiring > running non-Free software to use any Debian development tools. > > [mCaptcha]: https://mcaptcha.org/ Looks like this was extensively discussed in GitLab[1], and as a result "invisible captcha" was added in GitLab FOSS as an alternative[2]. So it looks like it is just a matter to change it in Salsa. [1] https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548 [2] https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31625#2808b8afa6e824bd6f3a8562c5a993da3653d14b -- Xiyue Deng
Re: Debian 9/stretch moved to archive.debian.org
xiao sheng wen(肖盛文) writes: > [[PGP Signed Part:Undecided]] > Hi, > > 在 2023/4/24 04:39, Ansgar 写道: >> This has happened now, just according to 計画[1]. It might take a moment >> to reach mirrors. >> >> Ansgar >> >>[1]: Translator's note: 計画 means plan. > > In chinese word, plan means "计划"， it's not "計画". "計画" is actually Japanese (keikaku). It means the same thing though. > > :-) > > Thanks! -- Manphiz
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-devel@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#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.
Question regarding uscan check on UDD
Hi, I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on UDD and locally on my bookworm system. For example, for magit-popup, UDD reports error[1] while testing locally it worked for me. On further inspection, it turns out that the @ANY_VERSION@ expands to a different regexp: the error message shows [2] while locally it expands to [3] (in fact more recent version uses [Vv]? which is even better). So it looks like UDD is probably still using an older version of uscan/devscripts. Is it possible to upgrade it to more recent version (e.g. Bookworm version) in UDD? [1] Error "Problems while searching for a new upstream version" https://tracker.debian.org/pkg/magit-popup [2] (?:[-_]?(\d[\-+\.:\~\da-zA-Z]*)) [3] (?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)) -- Xiyue Deng signature.asc Description: PGP signature
Re: Question regarding uscan check on UDD
Xiyue Deng writes: > Hi, > > I noticed a discrepancy of the uscan @ANY_VERSION@ substitute string on > UDD and locally on my bookworm system. For example, for magit-popup, > UDD reports error[1] while testing locally it worked for me. On further > inspection, it turns out that the @ANY_VERSION@ expands to a different > regexp: the error message shows [2] while locally it expands to [3] (in > fact more recent version uses [Vv]? which is even better). So it looks > like UDD is probably still using an older version of uscan/devscripts. > Is it possible to upgrade it to more recent version (e.g. Bookworm > version) in UDD? > > [1] Error "Problems while searching for a new upstream version" > https://tracker.debian.org/pkg/magit-popup > [2] (?:[-_]?(\d[\-+\.:\~\da-zA-Z]*)) > [3] (?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)) > > -- > Xiyue Deng > Now tracking in https://bugs.debian.org/1059892 as suggested by doge-tech@ on IRC. -- Xiyue Deng signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
PICCA Frederic-Emmanuel writes: > One missing piece for me in order to migrate to meson is the integration > between flymake and the autotools. > > https://www.emacswiki.org/emacs/FlyMake#h5o-7 > There is an unofficial Meson LSP[1]. Maybe it can be configured with Eglot or lsp-mode. -- Xiyue Deng [1] https://github.com/JCWasmx86/mesonlsp
Bug#1068440: ITP: emacs-corfu-terminal -- Corfu popup on terminal
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-corfu-terminal Version : 0.7 Upstream Author : Akib Azmain Turja * URL or Web page : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3 Programming lang: Emacs Lisp Description : Corfu popup on terminal Corfu uses child frames to display candidates. This makes Corfu unusable on terminal. This package replaces that with popup/popon, which works everywhere. I intend to maintain this package in the Debian Emacsen Team .
Bug#1068441: ITP: emacs-popon -- Pop floating text on an Emacs window
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-popon Version : 0.13 Upstream Author : Akib Azmain Turja * URL or Web page : https://codeberg.org/akib/emacs-popon * License : GPL-3 Programming lang: Emacs Lisp Description : Pop floating text on an Emacs window Popon allows you to pop text on a window, what we call a popon. Popons are window-local and sticky, they don't move while scrolling, and they even don't go away when switching buffer, but you can bind a popon to a specific buffer to only show on that buffer. This package is a dependency of emacs-corfu-terminal[1]. I intend to maintain this package in the Debian Emacsen Team . [1] https://bugs.debian.org/1068440
Bug#1068677: ITP: emacs-activities -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-activities Version : 0.7 Upstream Author : Adam Porter * URL or Web page : https://github.com/alphapapa/activities.el * License : GPL-3 Programming lang: Emacs Lisp Description : Save/restore sets of windows, tabs/frames, and their buffers in Emacs Inspired by Genera's and KDE's concepts of "activities", this library allows the user to select an "activity", the loading of which restores a window configuration into a `tab-bar' tab or frame, along with the buffers shown in each window. Saving an activity saves the state for later restoration. Switching away from an activity saves the last-used state for later switching back to, while still allowing the activity's initial or default state to be restored on demand. Resuming an activity loads the last-used state, or the initial/default state when a universal argument is provided. . The implementation uses the bookmark system to save buffers' states--that is, any major mode that supports the bookmark system is compatible. A buffer whose major mode does not support the bookmark system (or does not support it well enough to restore useful state) is not compatible and can't be fully restored, or perhaps not at all; but solving that is as simple as implementing bookmark support for the mode, which is usually trivial. . Integration with Emacs's `tab-bar-mode' is provided: a window configuration or can be restored to a `tab-bar' tab or to a frame. . Various hooks are provided, both globally and per-activity, so that the user can define functions to be called when an activity is saved, restored, or switched from/to. For example, this could be used to limit the set of buffers offered for switching to within an activity, or to track the time spent in an activity. I intend to maintain this package within the Debian Emacsen Team .
Bug#1070096: ITP: emacs-cfrs -- Child-frame based read-string for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-cfrs Version : 1.6.0 Upstream Author : Alexander Miller * URL or Web page : https://github.com/Alexander-Miller/cfrs * License : GPL-3+ Programming lang: Emacs Lisp Description : Child-frame based read-string for Emacs cfrs.el is a simple alternative to `read-string' that allows reading input via a small child-frame spawned at the position of the cursor. Its goal is to make the string input interface closer to those used in modern GUI programs and to help the user with having to switch focus from whatever they are doing currently to look at the minibuffer. This is a dependency of newer Emacs treemacs versions. I intend to maintain this package within the Debian Emacsen team .
Bug#1071204: ITP: emacs-bazel-mode -- Bazel support for GNU Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-bazel-mode Version : 0.0~git20230919.769b30d Upstream Author : Google LLC * URL or Web page : https://github.com/bazelbuild/emacs-bazel-mode * License : Apache-2.0 Programming lang: Emacs Lisp Description : Bazel support for GNU Emacs This repository provides support for Bazel in GNU Emacs. It consists of a single file, bazel.el, which only depends on GNU Emacs and not on other libraries. . The library provides major modes for editing Bazel BUILD files, WORKSPACE files, .bazelrc files, as well as Starlark files. It also provides commands to run Bazel commands and integration with core GNU Emacs infrastructure like compilation and xref. I intended to maintain this package within the Debian Emacsen Team .
Bug#1071708: ITP: emacs-dart-mode -- An Emacs major mode for editing Dart files
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dart-mode Version : 1.0.7+git20240507.ef6cc89 Upstream Author : Google Inc., Brady Trainor * URL or Web page : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ Programming lang: Emacs Lisp Description : An Emacs major mode for editing Dart files This package implements a major-mode for the Dart language, providing basic syntax highlighting and indentation support. I plan to maintain this package within the Debian Emacsen Team .
Re: tag2upload & orig.tar
Otto Kekäläinen writes: > > I just want to re-iterate that I like the idea of having DD signed git > tags trigger uploads to Debian. It has many benefits in quality and > security. I just wish we could get it without taking steps backward on > security aspects. > Not a DD (yet), though I would like to think that in the post Jia-Tan-xz-incident world we should reconsider the security guarantee of an upstream tarball, which can be intentionally prepared by a malicious upstream with payload not available in the Git tag. A Git tag may be more trustworthy as the content is more easily accessible and hence more eyes of scrutiny. Of course if upstream doesn't use Git it's another story. Just my 2 cents. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Problems to find sponsors (Was: Bits from DPL)
Andreas Tille writes: > Am Wed, Dec 04, 2024 at 10:46:03PM +0500 schrieb Andrey Rakhmatullin: >> On Wed, Dec 04, 2024 at 10:39:52AM -0700, Soren Stoutner wrote: >> > I have directed several RFS (Request For Sponsor) towards appropriate >> > teams, >> > when then exist. However, my personal experience is that the majority of >> > RFS >> > that come into Debian Mentors do not fit neatly into any existing team. >> >> Yeah. We have a lot of leaf applications and so on that can't have a team. > > To be precise, we have both: packages that may not fit neatly into any > team, and many packages that align perfectly with existing teams, such > as the scientific team, games team, multimedia team, phototools team, > and others. I've moved many packages to these teams. Additionally, the > software in question is written in a specific programming language, > making it easier to find maintainers fluent in that language within the > dedicated language team. These maintainers can help with issues, or, > even better, the newcomer may contribute to resolving problems within > the language-specific team. I don't want to suggest that current team > members are eager for more work, but the potential for new, active team > members might be compelling enough to take on the responsibility of > sponsoring. > > Kind regards >Andreas. > > -- > https://fam-tille.de > Having a team to maintain a group of related packages is supposed to improve velocity and usually works well. However there is a chance that a team may be understuffed, both temporarily and gradually. I have recently become a DM, so technically if my RFS bugs have been sponsored I can work autonomously on those packages. Unfortunately my RFS bug list is still growing[1] as my team becomes relatively less active recently. I totally understand as this is voluntary work and people have their lives to attend to (I do), and I am grateful for all comments and sponsoring from my team. On the other hand, seeing my packages being removed from mentors.d.n because of no sponsorship after 20 weeks is also discouraging. It would be great to have a group of DDs that are willing to regularly check for RFS bugs / mentors.d.n and offer sponsorship, even for team maintained packages. Some teams also maintain a team policy either on wiki[2] or in a document in team repo, which can be a good guideline for outside sponsors. Just my 2 cents. P.S. I would also like to take this chance to appreciate Phil Wyett's automatic RFS checking that adds "confirmed" tag to RFS bugs that passed the checks, which helps ensure a minimum quality of a prepared package ready for sponsorship that can reduce the review rounds and potentially save some time for potential sponsors. [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com [2] https://wiki.debian.org/Teams/DebianEmacsenTeam -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Towards DEP-14 acceptance and recently proposed changes
Julien Plissonneau Duquène writes: > > [..snip..] > > Could you please give us a few examples of projects where that already > works out-of-the-box, ie the package is built and uploaded to the > archive exactly as provided by upstream, debian/changelog and all? > I'm not Marco, but I happen to come across some packages that has "debian/" maintained in upstream repo because the Debian maintainer is also upstream maintainer, e.g. notmuch[1]. [1] https://git.notmuchmail.org/git/notmuch -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Is Salsa CI easy to use for anyone learning Debian packaging?
Richard Lewis writes: > Otto Kekäläinen writes: > >> Hi! >> >>> > Salsa CI is a great system for all aspiring Debian packagers to test >>> > their packages before requesting review from mentors >>> >>> > However, as there are still packages not using Salsa CI, I wonder is >>> > it straightforward enough for everyone? >>> > >>> >>> I think the best solution would be to make it opt-in rather than >>> opt-out? >>> >>> i think the barrier is likely to be "i didnt know you could do that?" >>> rather than "how do i use that?" >> >> Salsa CI is and has always been opt-in. > > oops - i meant the oppposite, ie make people have to opt out of having > it run, rather than have to enable it > I recently asked on the Emacsen team whether people would like to enable Salsa CI by default[1], and people seems to prefer not to as it could be distracting. Even though I find Salsa CI beneficial and it helped me catch bugs, I think their concerns are also valid. [1] https://lists.debian.org/debian-emacsen/2024/09/msg00052.html -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1095199: ITP: emacs-llama -- Llama - Compact syntax for short lambda
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-llama Version : 0.6.0 Upstream Author : Jonas Bernoulli * URL or Web page : https://github.com/tarsius/llama * License : GPL-3+ Programming lang: Emacs Lisp Description : Llama - Compact syntax for short lambda This package implements a macro named `##', which provides a compact way to write short `lambda' expressions. . The signature of the macro is (## FN &rest BODY) and it expands to a `lambda' expression, which calls the function FN with the arguments BODY and returns the value of that. The arguments of the `lambda' expression are derived from symbols found in BODY. This package is a new dependency of magit 4.3.0. I intend to maintain this package under the Debian Emacsen Team umbrella. signature.asc Description: PGP signature
Re: Problems to find sponsors (Was: Bits from DPL)
Hi Sam, Sam Hartman writes: >>>>>> "Andrey" == Andrey Rakhmatullin writes: > > Andrey> On Wed, Dec 04, 2024 at 03:30:23PM -0800, Xiyue Deng wrote: > >> It would be great to have a group of DDs that are willing to > >> regularly check for RFS bugs / mentors.d.n and offer sponsorship > > Andrey> Sure. This is true since the beginning of the RFS process, > Andrey> and as nothing stops people from doing this, but based on my > Andrey> observations such a group was never larger than 1-3 people, > Andrey> just knowing that this is a good idea is not enough. > > Perhaps sharing reasons why people don't do this would help us > understand what a change might look like. > > For myself, my reasons for not being involved in RFS have varied across > my Debian Journey. > > 1) Right now, I am behind on Debian work I have committed to, and I'd > rather get that done than work on picking up new obligations. > > 2) Sponsoring a package if you do it right is a lot of work. If it is > going through new, it's really important that you review all the > copyright and license statements and make a determination about whether > it fits the DFSG. I firmly believe that work needs to be done by a DD > and should never be outsourced to someone who hasn't been trusted to do > that work by the project. > I hate doing that. tooling has made it easier over the years. > > 3) I think it is important to grab a pristine copy of the upstream > 3) I think it's important to make sure that all changes are documented. > If not in Debian, that means going back to the upstream, grabbing > pristine upstream sources and diffing what is proposed at the upstream > source for Debian against those. If it is already in Debian, it means > effectively doing a debdiff between the version already in Debian and > the version proposed. The tooling for all that isn't great, and used to > be really bad. > > 4) At least back in the day there was an expectation that if you > sponsored a package you would test it. So it would involve learning how > to use the software and then testing to make sure it worked. Perhaps we > care about this less today. > > 5) At least back in the day there was an expectation that if you > sponsored an upload you would be available to sponsor any fixes to bugs > introduced in the upload. > For me, promising future availability was a big ask. > > 6) I felt there was an obligation to work with the person you were > sponsoring to get the package into shape. Sometimes that was a long > process. If they didn't have good email turn-around time I got into the > situation above where I had inadvertantly made a longer term commitment > than I was ready for. > > There are many points in my Debian journey where if I could have made a > 2-3 hour commitment to sponsoring packages without taking on future > responsibilities at future times, I would have been willing to do so. > (Not today unfortunately). > As I understand it there never has been (and is not today) a responsible > way to sponsor without at least taking on some chance of future > commitments. > These are valid concerns. I think the tooling from Phil should help with your point 2 and 3. For 4-6, I personally never expect the same DD would provide long-term support after sponsoring. Maybe making that clear on the Debian wiki[1] would help with aligning the expectations. [1] https://wiki.debian.org/DebianMentorsFaq -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Problems to find sponsors (Was: Bits from DPL)
Hi Phil, Phil Wyett writes: > > [..snip..] > > Morning Xiyue and all, > > Xiyue mentions tooling after Sam raised an issue. > > Xiyue, Many thanks for entering this conversation as I feel you are an ideal > person (through our many interactions) to detail/discuss what you feel mentors > is, is not, what is expected of the submitter and the reviewer; and what > mentors should be. > > As a none DD I do basic build testing and validation of packages and their > files in-order to bring them up to a minimum standard for a DD to then look > at. > This is to encourage Debian Developers to review and sponsor packages in > mentors. A mentors package submission at the stage tagged 'confirmed' on the > RFS bug means it is decent shape and be less of a strain on a DD's time. > > I use the sbuild using unshare[1] setup which can also run lintian, piuparts > and autopkgtest test when configured. > > pbuilder I have historically used in the same minimal build VM sbuild for > build > after successful build tests. > > We use 'licenserecon' command 'lrc' to do validation checking of > 'd/copyright'. > This tool is new and improving. Manual checking are also used. > > I do not use scripts or have it automated. I do these tests manually across > two > laptops for each package I review. Automation and documentation is on the > to-do > list. > > My work on mentors is with primarily already available Debian tools and Visual > Studio Code. The key thing is the time I am fortunate to be able to give to > Debian due to my circumstances. > > An expectation that once a DD does an upload for you, they are obligated to do > them for you from that point on I have seen in and around mentors. Unless a DD > specifically makes a commitment to a package, I believe that all package > uploads by a a DD are a one shot and there should be no expectation a DD will > be available to do it in the future. All submitters I feel should file an RFS > and an available DD can be canvassed for or waited for. > > [1] https://wiki.debian.org/sbuild#Setup > Thanks for explaining your workflow in detail! I didn't realize this also involves manual work, and my kudos for working on so many RFS bugs nonetheless! I think Phil's checking work provides many good feedback on many obvious packaging issues, and once an RFS bug is confirmed, the package will be in a sufficiently good shape for sponsoring. Any further issue may require more domain knowledge and may be beyond the scope of automated tools. I'm really looking forward to see Phil continuing on automating and documenting these tools. Once that happens, I wonder whether there would be interest in making Phil's work a service on mentors.d.n or BTS (like bartm@d.o)? I think it would be a great addition to complement local Lintian runs and Salsa CI. > Regard > > Phil > > -- > > Donations... > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Liberapay: https://liberapay.com/kathenas > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Wiki: https://wiki.kathenas.org > > Instagram: https://instagram.com/kathenasorg > > Threads: https://www.threads.net/@kathenasorg > > -- > > > > > > > > > > > > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Problems to find sponsors
Hi Sean, Sean Whitton writes: > Hello, > > On Mon 09 Dec 2024 at 03:58pm -08, Xiyue Deng wrote: > >> These are valid concerns. I think the tooling from Phil should help >> with your point 2 and 3. For 4-6, I personally never expect the same DD >> would provide long-term support after sponsoring. Maybe making that >> clear on the Debian wiki[1] would help with aligning the expectations. >> >> [1] https://wiki.debian.org/DebianMentorsFaq > > Huh. This has always been my expectation. The sponsee is committing to > maintaining it through the end of the next stable release (as any > package maintainer does) and the DD is committing to reviewing and > sponsoring the uploads so it's actually possible for them to do that. > > Of course, it's best effort as ever with volunteers, but that's not > nothing. > Thanks for your input! For sure if what-you-suggest happens on a regular basis it would be great. I am just hoping to let perspective DD sponsors have less concerns that we as sponsees don't necessarily want to take even more of their previous free time for granted. I think for general questions we can ask on debian-devel@l.d.o or #debian-devel@OFTC (or the corresponding debian-mentors places) instead of relying on a dedicated sponsor so as to lower their burden. All that is to make perspective DD sponsors have less concerns to start reviewing and sponsoring. As your said, "it's best effort as ever with volunteers." > Teams are a bit different, I guess. But, for example when I said on > emacs-devel today that I could sponsor that C library you might be able > to help upload, I meant that it would be on a continuing basis. > Thanks for your support! > It doesn't seem good for Debian, or the sponsee, for the DD to sponsor > it through NEW and then leave the sponsee in limbo. > Ack. I would also hope for the best. > -- > Sean Whitton -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Let's make 2025 a year when code reviews became common in Debian
Hi Colin, Colin Watson writes: > On Thu, Jan 23, 2025 at 10:57:56PM -0800, Xiyue Deng wrote: >> Actually there may be another reason to turn off MR feature: some >> packaging workflows don't preserve a linear Git history and hence may >> not work well with merging from MR on Salsa. For example, the "git-dpm" >> and "git-debrebase" workflows, which use a more complex >> merge/fast-forward strategy and merge requests don't integrate well. In >> such case it's better to turn off MR to avoid any confusions and let >> contributors post patches on BTS, and then the maintainer can apply >> those accordingly. > > I don't completely agree with the last part of this: I use git-dpm for > many packages and I leave MRs switched on anyway, even though it does > mean that sometimes I might need to do merges by hand. It's not ideal, > but it's OK. (I understand why people might feel differently, though.) > Thanks for sharing your experience. And yes, merging from MR does work for these workflow to some extents, though it does require understanding of how they work and handles the merge / fast-forward correctly. This would require people to be familiar with those workflows to deal with those, otherwise a directly merged MR would cause the repository layout becomes dpm/debrebase incompatible. I brought this up because personally I had done something similar before on a git-debrebase repository and made the repository a mess. I had to reach out to more knowledgeable team members to help fix it, and it was then decided disabling MR could help avoid this happening again. For those repositories the team and I have added debian/README.source describing the workflow and people need to consult git-dpm(1), git-debrebase(1), dgit-maint-debrebase(7), etc. to understand how to handle those cases properly. Again, this does not mean the developer is not accepting collaboration, and contributors are welcome to use BTS for the purpose. Lastly, I want to clarify I'm in support of keeping MRs open and promoting a standard workflow for most packages. Meanwhile I would also like to acknowledge that many other workflows exist because they handle different use cases well (e.g. carrying Debian-specific patches for a long time, complex custom packaging checks, etc.). Letting different workflows exist and work together, though not easy, is also beneficial for collaboration. > -- > Colin Watson (he/him) [cjwat...@debian.org] > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Fabio Fantoni writes: > > ... > > There is also another thing to consider, if you keep a generic one as > default it always points to the latest version, while a specific one > might not be the latest version and if the contributors do not check > well the branches they could risk wasting time (and maybe also the > reviewers) doing work that does not include work in progress on more > recent branch or that conflicts with it > I would like to echo on this point. I had worked on a repository that has the "master" branch marked as the default branch on Salsa, which lacks many changes compared to the released version. I tried to manually incorporate those changes, and only later found out that the actual latest branch is "debian/sid" and it did have everything up-to-date. (Note that this has since been fixed[1]). I think for new repository, standardizing on a name (either "debian/latest" or people's liking) helps identify where the latest work goes to. And as Salvo pointed out, it's the tag names that indicate where the releases go to, not the branch names. [1] https://salsa.debian.org/debian/mozc >> >> >>> There were cases when git wont let me use debian/foo "branch subdir" since >>> it >>> clashed with other objects in the git repository, but I don't remember what >>> it >>> was. >> (Maybe that you cannot have <$branch> and <$branch>/something) >> >>> Thanks, >>> >>> /mjt >>> > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Let's make 2025 a year when code reviews became common in Debian
Hi Otto, First I want to thank you for your work on Salsa. I find it pleasant to use and the Salsa CI has also helped catch many lurking bugs for me. Otto Kekäläinen writes: > ... > > I understand that some people like to turn of the MR feature > completely on their repositories, but I would advise against that, as > it is a major killer to collaboration. Not only does it signal to > contributors to the existing package that the maintainer is not > interested in spending time/effort on accepting contributions, but it > also makes it hard for abandoned packages to have spontaneous > collaboration arise and salvaging started as the potential > collaborators would never end up seeing each others MR submissions. > Actually there may be another reason to turn off MR feature: some packaging workflows don't preserve a linear Git history and hence may not work well with merging from MR on Salsa. For example, the "git-dpm" and "git-debrebase" workflows, which use a more complex merge/fast-forward strategy and merge requests don't integrate well. In such case it's better to turn off MR to avoid any confusions and let contributors post patches on BTS, and then the maintainer can apply those accordingly. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
tho...@goirand.fr writes: > On Jan 24, 2025 22:24, Xiyue Deng wrote: > >> > >> Fabio Fantoni writes: > >> > > >> > ... > >> > > >> > There is also another thing to consider, if you keep a generic one as > >> > default it always points to the latest version, while a specific one > >> > might not be the latest version and if the contributors do not check > >> > well the branches they could risk wasting time (and maybe also the > >> > reviewers) doing work that does not include work in progress on more > >> > recent branch or that conflicts with it > >> > > >> > >> I would like to echo on this point. I had worked on a repository that > >> has the "master" branch marked as the default branch on Salsa, which > >> lacks many changes compared to the released version. I tried to > >> manually incorporate those changes, and only later found out that the > >> actual latest branch is "debian/sid" and it did have everything > >> up-to-date. (Note that this has since been fixed[1]). I think for new > >> repository, standardizing on a name (either "debian/latest" or people's > >> liking) helps identify where the latest work goes to. And as Salvo > >> pointed out, it's the tag names that indicate where the releases go to, > >> not the branch names. > >> > >> [1] https://salsa.debian.org/debian/mozc > > > What you experience shows one thing: having the default branch being > set correctly should be what we mandate. Indeed. Though IIRC the default branch was not a native git concept until 2.28, so user of older git may still get confused. > NOT the name of it, which could be different than the standards for > many reason. I think for new package repositories having a recommended name is a good thing to avoid confusions like this, which I think DEP-14 was for. > > > Thomas Goirand (zigo) > > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Hi Fabio, Fabio Fantoni writes: > Il 24/01/2025 22:24, Xiyue Deng ha scritto: >> Fabio Fantoni writes: >>> ... >>> >>> There is also another thing to consider, if you keep a generic one as >>> default it always points to the latest version, while a specific one >>> might not be the latest version and if the contributors do not check >>> well the branches they could risk wasting time (and maybe also the >>> reviewers) doing work that does not include work in progress on more >>> recent branch or that conflicts with it >>> >> I would like to echo on this point. I had worked on a repository that >> has the "master" branch marked as the default branch on Salsa, which >> lacks many changes compared to the released version. I tried to >> manually incorporate those changes, and only later found out that the >> actual latest branch is "debian/sid" and it did have everything >> up-to-date. (Note that this has since been fixed[1]). I think for new >> repository, standardizing on a name (either "debian/latest" or people's >> liking) helps identify where the latest work goes to. And as Salvo >> pointed out, it's the tag names that indicate where the releases go to, >> not the branch names. >> >> [1] https://salsa.debian.org/debian/mozc > > I wrote this because I also saw this issue over the years. > > Check the tags is useful if there are new upstream or debian version (so > new tags) but not unreleased work excluding new upstream version, this > require to look on branches those with the most recent activity, > excluding those of fixes released for stable and backports. > > It might seem obvious but unfortunately it is not, I fear that someone > does not check by looking only at the default branch or maybe quickly > not noticing something, for example in cases with particular and > different names that are not common, linked to versions of the distro or > software (at least not numbers). > > For this reason, trying to standardize with a single name the branches > where the most current work is carried out (with some exceptions), if > not recommended by DEP-14 (because in some cases it is > counterproductive) but at least suggested being able to have in the > future the majority of uniform gits I think can be useful. > > Then there were cases where the problem was that the default branch was > no longer actually used but was not updated, so in addition to the name > it would be good to make sure to keep the default branch updated. I have > seen for example cases of those who created the repository with master > but then immediately used another working branch (like "debian"), or who > had switched from master to main but kept the default on master and > these are just 2 examples of what I had seen. > > While I was finishing I saw @zigo's answer regarding this last part, > "default branch being set correctly should be what we mandate" would > help even if is not for all cases (excluding any separate branches for > "test" work, that is ok more updated but not default) > > 2 other particular cases that hinder could also be when someone work on > another git without updating the fields in d/control and that do not > work on the default branch because maybe only someone with lower > permission remained active in the repository and who cannot push to the > default branch by setting (rare but it happened), it would be necessary > to better define how to act (and also have the means in some cases) to > reduce the problematic cases to which I add a last example, "abandoned" > package in which those who continue cannot modify in the repository and > proceed in another repository but unfortunately until a new upload is > made with the updated vcs fields others don't know and there is a risk > of doing duplicate work elsewhere (it happened also to me) > Thanks for providing more real world use cases. I think these may help people (me included) understand the rationale on trying to suggest a name for the branch of the latest work better. >> >>>> >>>>> There were cases when git wont let me use debian/foo "branch subdir" >>>>> since it >>>>> clashed with other objects in the git repository, but I don't remember >>>>> what it >>>>> was. >>>> (Maybe that you cannot have <$branch> and <$branch>/something) >>>> >>>>> Thanks, >>>>> >>>>> /mjt >>>>> > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Hi Colin, Colin Watson writes: > On Fri, Jan 24, 2025 at 01:24:12PM -0800, Xiyue Deng wrote: >> I would like to echo on this point. I had worked on a repository that >> has the "master" branch marked as the default branch on Salsa, which >> lacks many changes compared to the released version. I tried to >> manually incorporate those changes, and only later found out that the >> actual latest branch is "debian/sid" and it did have everything >> up-to-date. (Note that this has since been fixed[1]). I think for new >> repository, standardizing on a name (either "debian/latest" or people's >> liking) helps identify where the latest work goes to. > > I find myself in this situation from time to time as well. However, I > disagree with your conclusion. At least for me, and I'm going to guess > for most contributors, I wouldn't reliably think to look for a > non-default branch at all unless I was doing something a little more out > of the ordinary such as preparing an update for a stable release; it > wouldn't really matter whether that branch was called debian/master or > debian/main or debian/sid or debian/latest. I usually work on the > assumption that the branch I get by "git clone" from Salsa is the one I > should be working on for the usual case of developing on unstable, and > since that assumption is nearly always correct, it saves me time and > energy over explicitly looking around for different branch names every > time I clone a repository (I work on a lot of different packages). > > In the situation you outlined, it wouldn't have mattered to me one bit > whether the actual latest branch was called debian/sid or debian/latest; > I probably wouldn't have noticed it either way. What would have > mattered to me was that it wasn't the default branch (HEAD on Salsa). > > So, rather than worrying about the _name_ of the default branch, I'd > like to suggest a change to DEP-14 that I think would have broader > consensus and be more useful. > > Currently, there's only one place where DEP-14 talks about the default > branch: the "Native packages" section says "the default branch of the > repository (as pointed by the HEAD reference) should be a development > branch". I suggest that this recommendation should not be just for > native packages. The "For development releases" section should say that > the branch for uploads to the current development release of the > furthest-upstream distribution handled in a given repository (typically > Debian) should be the default branch, as pointed to by the HEAD > reference. > > DEP-14 needn't prescribe exactly what the name of that branch should be, > and if it does then we should pragmatically regard it only as an > indication of what tools that _create_ Debian packaging repositories > should do. Renaming branches is intrusive (it still typically requires > manual action from anyone who has an existing clone and wants to pull > changes!), and so there can be no realistic expectation that existing > repositories will reliably change to follow a new suggested default > name. > Thanks for your comments! I agree with you that with the improvements on tooling (e.g. git), the default branch matters the most for avoiding confusion. However, there is an inconvenience if there is not a recommended default branch name. When I switch among several projects, the default branch name changes between "master", "main", "debian/master", "debian/latest", etc., which is kind of distracting. I think recommending a name helps to reduce this fragmentation in the long run. This may not be an issue for experienced git user, but helps newcomers a lot. > -- > Colin Watson (he/him) [cjwat...@debian.org] > -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1094423: ITP: emacs-jsonrpc -- Emacs JSON-RPC library
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-jsonrpc Version : 1.0.25 Upstream Author : João Távora * URL or Web page : https://elpa.gnu.org/packages/jsonrpc.html * License : GPL-3+ Programming lang: ELisp Description : Emacs JSON-RPC library This library implements the JSONRPC 2.0 specification as described in https://www.jsonrpc.org/. As the name suggests, JSONRPC is a generic Remote Procedure Call protocol designed around JSON objects. To learn how to write JSONRPC programs with this library, see Info node `(elisp)JSONRPC'." . This library was originally extracted from eglot.el, an Emacs LSP client, which you should see for an example usage. This package is required to fix the RC Bug#1094421[1]. I intend to maintain this package under the Debian Emacsen team umbrella. As I am a DM, I would need a sponsor for the initial upload. [1] https://bugs.debian.org/1094421 -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1091386: ITP: tp-el -- Utilities for transient menus that POST to an API
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: tp-el Version : 0.6 Upstream Author : Marty Hiatt * URL or Web page : https://codeberg.org/martianh/tp.el/src/branch/main/tp.el * License : GPL-3+ Programming lang: Emacs Lisp Description : Utilities for transient menus that POST to an API Some functions, classes and methods to make it easier to create transient menus that send complex POST, PUT, or PATCH requests to JSON APIs. . A typical use-case is where you have a single endpoint that takes many different parameters. It's handy for a user to be able to set all the options, then make a single request to change all the settings on the server. It's also expected that they'll be able to view all the current settings on the server, and make modifications to them for sending. This is a dependency of newer versions of mastodon.el. I will maintain this under the Debian Emacsen Team umbrella, and I will need a sponsor for the first upload. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1095796: ITP: emacs-peg -- Parsing Expression Grammars for Emacs Lisp
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-peg Version : 1.0.1 Upstream Author : Helmut Eller * URL or Web page : https://elpa.gnu.org/packages/peg.html * License : GPL-3+ Programming lang: Emacs Lisp Description : Parsing Expression Grammars for Emacs Lisp This package implements Parsing Expression Grammars for Emacs Lisp. . Parsing Expression Grammars (PEG) are a formalism in the spirit of Context Free Grammars (CFG) with some simplifications which makes the implementation of PEGs as recursive descent parsers particularly simple and easy to understand [Ford, Baker]. PEGs are more expressive than regexps and potentially easier to use. This package is a dependency of newer emacs-pg-el versions. I intend to maintain this package under the Debian Emacsen team umbrella. I'll need a sponsor for the initial upload. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: My personal recommendation on how to create Debian packages from upstream Git
Hi Holger, Holger Levsen writes: > On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote: >> If you suggest that using "debian/latest" should *not* be done by >> default, then it seems that requires reverting changes to DEP-14. > > yes. dep14 currently says "that uploads to unstable and experimental should > be prepared either in the debian/latest branch or respectively in the > debian/unstable and debian/experimental branches." > > I think it should (instead) recommend debian/unstable (for uploads to > unstable) > (and in very brief) allow any debian/* branch layout & probably specifically > name certain common ones. > >> Personally, I don't see a problem in finalizing DEP-14 with its current >> wording, but I might miss something (more generally relevant than "let's >> just all use git-buildpackage" which I don't think is what you are >> saying here). > > my biggest problem with dep14 is that it doesnt recommend *one* layout. my > biggest problem with how I see that interpreted is that I think > debian/unstable > is much better than debian/latest *as a default recommendation*. > > because IMO debian/latest is rather *not* helpful when uploads to > experimental are involved. and because debian/unstable is rather very clear > what this > branch is about. I am not yet a DD, but I maintain packages as a DM. Just want to provide a perspective from a "debian/latest" user, as I found using "debian/latest" easier personally. When I need to experiment something on experimental and intend to upload to unstable as soon as the experiment succeeded, using "debian/latest" provides a simple linear git timeline. If I were to use "debian/unstable", I would need to sync "debian/experimental" with "debian/unstable", do experiment there, upload; and once done, I would need merge "debian/unstable" with "debian/experimental"; and after future upload to unstable, "debian/experimental" becomes stale again and requires another merge in the future. As I don't intend to let the experimental version stay long, I think using two different branches for unstable and experimental unnecessarily complicates the process. Just my two cents. > [...] -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1108067: ITP: emacs-geiser-racket -- Support for Racket in Geiser
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-geiser-racket Version : 0.16 Upstream Author : Jose A. Ortega Ruiz * URL or Web page : https://gitlab.com/emacs-geiser/racket * License : BSD-3-clause Programming lang: Emacs Lisp Description : Support for Racket in Geiser This package extends the `geiser' core package to support the Racket "scheme" implementation. I will maintain this package within the Debian Emacsen team. As a DM, I would need a sponsor for the initial upload. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1108028: ITP: emacs-geiser-guile -- Guile and Geiser talk to each other
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-geiser-guile Version : 0.28.3 Upstream Author : Jose Antonio Ortega Ruiz * URL or Web page : https://gitlab.com/emacs-geiser/guile * License : BSD-3-Clause Programming lang: Emacs Lisp Description : Guile and Geiser talk to each other This package extends the `geiser' core package to support GNU Guile. I will maintain this within the Debian Emacsen team. As a DM, I would need a sponsor for the initial upload. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Bug#1106739: ITP: emacs-wfnames -- A mode to edit filenames in Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-wfnames Version : 1.2 Upstream Author : Thierry Volpiatto * URL or Web page : https://github.com/thierryvolpiatto/wfnames * License : GPL-3+ Programming lang: Emacs Lisp Description : A mode to edit filenames in Emacs A mode to edit filenames, similar to wdired. . This package have no user interface, but you can easily use it with Helm package by customizing `helm-ff-edit-marked-files-fn' variable. If you are not using Helm you will have to define yourself a function that call `wfnames-setup-buffer' with a list of files as argument. This is a dependency of newer helm version, which is required to fix RC bugs (Bug#1099238, and in turn Bug#1020160). I'm maintain this within the Debian Emacsen team. I am a DM, so I would need a sponsor for the initial upload. TIA! -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: github repo with submodules: non usable source tarball
Hi Jerome, Jerome BENOIT writes: > Hi, > > I am considering to package a software stored at GitHub. > It is under active development and it builds well in Sid. > However it appears that its source tarball at GitHub does not > contain all the necessary material: its submodules are not included. > This issue seems to be an old GitHub issue. Whatever. > I am wondering how we can grab its source tarball with uscan(1). > The best solution I come with is to write a script that would git-clone > with the option `--recurse-submodule` the git repo and then build a > source ball from this. However this approach sounds heavy to me. > Is there any better way ? Any example of a package with such an issue > is welcome. > > Cheers, > Jerome > > > > -- > Jerome BENOIT | calculus+at-rezozer^dot*net > https://qa.debian.org/developer.php?login=calcu...@rezozer.net > AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B > I have recently encountered the similar issue with gptel, which makes its tests in a submodule. I think gbp support submodules, but it's not really compatible with uscan, so the tarball created by uscan is still missing the submodules. I have proposed a few solutions. The one upstream accepted is to let the submodule have the same release schedule as the main repo (basically same tag versions). Then in Debian I use uscan with the multiple upstream tarball (MUT) settings. uscan(1) manpage has examples (search for MUT). Of course, it would be better to persuade upstream to merge the repo, which would make their CI setup easier, though they may well reject it (with good reasons). -- Regards, Xiyue Deng signature.asc Description: PGP signature
