Re: Removing more packages from unstable
Hi helmut, +1 On 20-08-2024 07:28, Helmut Grohne wrote: * As packages fail to migrate to testing for a long time, a release team member eventually looks at the package. I recognize myself here. But to be totally fair, that's *mostly* about testing, and we have processes for that. Once removed from testing, what's in unstable is hardly a matter for the release team. Except we do monitor packages in transitions, as we schedule binNMU's so some of those FTBFS bugs come from us. * There are many more people doing various forms of QA and sending patches. Although I hardly send patches, I do file *loads* of bugs for autopkgtest failures and other QA related checks. Again, mostly for testing, but occasionally for unstable too. For autopkgtest, typically when I need to add packages to our reject_list, which needs maintenance too. My personal motivation for looking into this actually is the /usr-move work and the cross build support work. Please do consider me biased. I'm biased too, but I don't think that's bad. You and I are doing quite a bit of this work, so we have a say. As is quite common, I agree with a lot of what Niels replied too on the topic of automating this. autoremoval from testing currently is mostly handled by udd, which was great to get this bootstrapped, but at this moment makes me uncomfortable as a Release Team member. The tool should be owned and maintained by us. When I first wanted to make changes to it, I couldn't even do it because I wasn't member of the right team, which feels weird. The same is true for the key package set calculation (which is strongly related). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Hi! > I'd like to rephrase your quest. What you really want is unstable to be > less unstable. Whilst a number of people disagree with that notion, I I don't think anybody disagrees that breaking a core packages and stopping (nearly) all other DDs from doing development for a day or two is acceptable. I do agree that there are some developers who view unstable as a CI system by itself, and we occasionally see certain DDs do multiple uploads in a few days for the same package after they read the QA system results. This is better than nothing, and maybe OK for small/unimportant packages. For important packages I think it would be vital to have enough CI should run before upload unstable, and use unstable only to detect stuff that is hard to gate keep with automatic testing (as you wrote in slightly different words). > One complaint I've seen about this workflow and one that I agree with is > the waiting time. Checking salsa-ci before uploading incurs an extra > context switch. What we'd really like to do is click the equivalent to The CI waiting time is always less than human review waiting time. For example in https://salsa.debian.org/debian/entr/-/merge_requests/10 the CI took 10 minutes, but it will take several days for a reviewer to respond on the MR itself. Also, I think a 10-minute break is a good thing for the author themselves. The maintainer should get some fresh air and do the final review of their changes after a small break to ensure nothing was done too hastily. > "Auto-merge" (if the pipeline passes). As I write this, Sean or Ian will > likely come along and say tag2upload. Working in this direction and > enabling a "upload if ci passes" would bring the salsa-ci experience to > another level. This would be super cool, in particular if it was extensible to get triggered automatically when a new upload has had a minimum number of approvers in the MR, and it would got merged and tagged and uploaded automatically. > Let me suggest that there are more ways to do this. Freexian is putting > a ton of effort into https://debusine.debian.net. It can do much of the > same tasks as salsa-ci already (with less flexibility). Extending it to > act as an upload-proxy that forwards your upload to the archive if > builds pass could be another option of improving unstable quality. In > earlier times, debomatic.debian.net was used as a pre-upload QA tool if > I remember correctly. I used to use debomatic.debian.net, and I have been reading about Debusine and the funding it gets from the Sovereign Fund. I tried to use Debusine back in March, but the client requires Python 3.11+ which my system does not have. I will need to make a new attempt soon. Thus, I don't have any good opinion about it yet. However, as you probably guess, I have a strong preference for workflows that integrate version control and code reviews and CI. This is what Salsa does (and GitLab, GitHub and alike). > Then the top-150 packages tend to be packages with unusual aspects. For > instance, the git repositories for gcc-VER, glibc and linux all lack > upstream sources. For linux, there is a pipeline, but in order to > complete in a timely manner, it enables the pkg.linux.quick build > profile and the pipeline is elaborate with a complex extract-source > stage. It's not a matter of just enabling the pipeline for our core > packages but spending a lot of time fiddling with the settings until it I have been reading the Kernel team Salsa CI before, and I am impressed how the pipeline has been customized, and glad to see it was green for the latest upload: https://salsa.debian.org/kernel-team/linux/-/pipelines/720187 I suspect you are right that some of the top-150 packages are special case that can't use Salsa CI easily, but for example the setuptools that had #1079175 yesterday would have been able to run Salsa CI without anything custom (just a debian/gbp.conf file to define how it needs to be built from git, see https://salsa.debian.org/python-team/packages/setuptools/-/commits/debian/latest/). > works. I guess that sending a working pipeline configuration for these > could improve the situation. Would it also make sense to source I have done that - details visible in my MR history at https://salsa.debian.org/dashboard/merge_requests?scope=all&state=all&author_username=otto&search=%22enable+salsa%22 - and will continue to. For example, after #1071245 happened, I sent to GnuPG an MR that enabled Salsa CI and included fixes to make it green. Inspired by #1021336 I just sent one to PAM this week. Some maintainers happily accept it, but surprisingly many reject, and I have no backbone from any DEP or GR or policy to ask them to seriously consider using Salsa CI. Some even say that they don't want to look at MRs at all, no matter how many fixes might be pending there on a silver plate. It is a lot of work to do these contributions and frustrating when people reject them without any real reason, just some expression of personal prefe
Bug#1079305: ITP: tty-record -- Simple tool to record a terminal session
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, vil...@debian.org * Package name: tty-record Version : 0.1.0+git20240821.2a020f5 Upstream Contact: Vasile Popescu * URL : https://github.com/elisescu/tty-record * License : Expat Programming Lang: Go Description : Simple tool to record a terminal session tty-record is a tool that records a terminal session (well, any command you run it with) and saves the output in a self contained html file that can be run in the browser. . It is based on asciinema-player to playback the recorded session. . See also tty-share for sharing a terminal session.
Bug#1079340: ITP: itkgenericlabelinterpolator -- Insight Toolkit module to interpolate label images
Package: wnpp Severity: wishlist Owner: Pierre Gruet X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: itkgenericlabelinterpolator Version : 1.2.1 Upstream Contact: https://github.com/InsightSoftwareConsortium/ITKGenericLabelInterpolator/ * URL : https://github.com/InsightSoftwareConsortium/ITKGenericLabelInterpolator/ * License : Apache-2.0 Programming Lang: C++ Description : Insight Toolkit module to interpolate label images This module for the Insight Toolkit (ITK) provides a generic interpolator for label images to interpolate each label with an ordinary image interpolator, and return the label with the highest value. This is the idea used by the itk::LabelImageGaussianInterpolateImageFunction interpolator. Unfortunately, this class is currently limited to Gaussian interpolation. Using generic programming, the proposed interpolator extends this idea to any image interpolator. Combined with linear interpolation, this results in similar or better accuracy and much improved computation speeds on a test image. The package is needed as a dependency of ants, which is maintained by the Debian-med team. It will be team-maintained inside this team.
Bug#1079341: ITP: itkadaptivedenoising -- Insight Toolkit module for image denoising
Package: wnpp Severity: wishlist Owner: Pierre Gruet X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: itkadaptivedenoising Version : 0.0+git20240619.005bd0e Upstream Contact: Nick Tustison * URL : https://github.com/ntustison/ITKAdaptiveDenoising/ * License : Apache-2.0 Programming Lang: C++ Description : Insight Toolkit module for image denoising This module of Insight Toolkit allows one to denoise an image using a spatially adaptive filter. The package is needed as a dependency of ants, which is maintained by the Debian-med team. It will be team-maintained inside this team.
Re: Removing more packages from unstable
Hi, Am Tue, Aug 20, 2024 at 02:51:49PM +0900 schrieb Simon Richter: > > enigmail > > Thunderbird has native GPG support now, including (well-hidden) support for > calling into the installed gpg binary to use a smartcard. > > > mutextrace > > Oof, I should fix that finally, because in principle a debugging layer to > find lock hierarchy violations would be good to have. > > > obs-websocket > > Websocket support was merged into the main program a while ago. To my understanding this reads like: We can remove enigmail and obs-websocket or what do you want to express? If so would you mind filing removal bugs? Kind regards Andreas. -- https://fam-tille.de
Re: Removing more packages from unstable
Am Tue, Aug 20, 2024 at 11:09:31AM +0200 schrieb Helmut Grohne: > > I considered adding popcon to the criteria before hitting send. In the > end, I opted for not including it based on my own cost/benefit analysis. > While popcon may be a signal for the benefit-of-keeping aspect, it > provides little value for the cost-of-keeping part that feels most > important to me. As you point out, popcon is partially considered via > the key package constraint. As others (e.g. Niels) point out, the cost > of a package largely is a function of our ability to modify it and long > lasting RC bugs are a relatively high quality signal indicating that a > package is difficult to modify. Either some of those many users > (according to popcon) eventually gets interested in doing the hard work, > or we should put it onto the chopping block. Even mailing the rc bug > would reset its last modified timer. These are very good arguments. > If there ends up being consensus for adding popcon as a signal, so be > it. I've explained my reasons and am not too strongly attached to > excluding popcon. Anyway I think while a low popcon should not really put a package on the potential removal list but a high popcon might be a good reason to remove the package from the list. My guess is that you will not find that many high popcon packages in your list so it will probably not become way shorter by removing high (by whatever definition of high) popcon packages. Thank you in any case for your investigation Andreas. -- https://fam-tille.de
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kekäläinen: > ... ACK to everything. > However, pushing for wider Salsa CI adoption I think makes sense as a > goal by itself, and I would be keen to hear what people think is a > reasonable way to proceed with that? ACK. What about configuring Salsa that Salsa CI is switched on by default? Since 2021 I'm discussing with Debian Java team (last mail about this in my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which makes it extra hard to get Salsa CI for these packages. Not sure about other teams but IMHO the better strategy would be to make it extra hard to switch of Salsa CI. Kind regards Andreas. [1] https://lists.debian.org/debian-java/2024/06/msg7.html -- https://fam-tille.de
Re: Removing more packages from unstable
On Wed, Aug 21, 2024 at 08:40:15PM +, weepingclown wrote: > Hi, > > I believe at least some of these packages were probably packaged as > dependencies for packaging lazygit. I am not sure which all, but I remember > atleast gocui, pty and termbox-go to be needed by lazygit in one way or > another. There has been further work on packaging lazygit towards the end of > the previous year, which I believe was mostly finished, that was then delayed > by the person primarily focusing on this being the chief organizer for > DebConf24. I am not sure removing them is the best idea, given it is part of > an ongoing work. Is there any further intended effort for lazygit? > Best, > Ananthu > > >golang-github-jesseduffield-asciigraph > >golang-github-jesseduffield-gocui > >golang-github-jesseduffield-pty > >golang-github-jesseduffield-roll > >golang-github-jesseduffield-rollrus > >golang-github-jesseduffield-termbox-go > >golang-github-jesseduffield-yaml > >golang-github-manyminds-api2go > > I am fixing riscv64 FTBFS in some of these now so it migrates properly. If the work is mostly done, we can quickly wrap up lazygit in a month or two. Want to give a hand? Best, Nilesh signature.asc Description: PGP signature
Re: Removing more packages from unstable
On Wed, Aug 21, 2024 at 08:40:15PM +, weepingclown wrote: > I believe at least some of these packages were probably packaged as > dependencies for packaging lazygit. I am not sure which all, but I > remember atleast gocui, pty and termbox-go to be needed by lazygit in > one way or another. There has been further work on packaging lazygit > towards the end of the previous year, which I believe was mostly > finished, that was then delayed by the person primarily focusing on this > being the chief organizer for DebConf24. I am not sure removing them is > the best idea, given it is part of an ongoing work. This reminded me of some "library" packages (I don't remember the language) that are RC-buggy and IIRC orphaned that are stated to be deps of some large project which is no longer in unstable. I wonder if such leaf libraries should be removed even when not RC-buggy, but it's unclear who can decide that (in those cases it could be the one who orphaned them). -- WBR, wRAR signature.asc Description: PGP signature
Re: Representing Debian Metadata in Git
Hi ! Le mercredi 21 août 2024, 23:37:38 CEST Chris Hofstaedtler a écrit : > Hi Simon, > > * Simon Richter [240820 09:11]: > > One of the long-standing issues is that there are multiple ways Debian > > packaging can be represented in a git tree, and none of them are optimal. […] > > Any feelings/objections/missed requirements? > > In the current DEP14/DEP18 discussions a lot of discussion was had > about how we should represent Debian things in git; your mail also > goes into this direction. In the Qt/KDE Team (~600-700 source packages) we’ve taken the complete opposite approach. We keep debian/ only repos in salsa and don’t put the upstream source in git anywhere, only in the uploads to the archive. Updating a package to a new upstream version is then as simple as a new changelog entry, and uscan / dpkg-builpackage / sbuild handle the rest for us. I personally think it’s crazy / not a good use of my time to try and mix both upstream and packaging history in the same repo and try to make git dance around that when handling new upstream releases. The extents of the ongoing d-devel discussions on the topic tend to reinforce that feeling. Keeping debian and upstream changes separate is a nice feature. I’d even qualify the debian-only workflow as essential for packages with large source trees like Qt WebEngine that embeds Chromium. The source-included workflows add orders of magnitude of overhead in this kind of situation. (For some value of $fun, try cloning the mesa or Firefox repos from a sloppy Internet connection for a packaging analysis or an occasional contribution.) Happy hacking, -- Aurélien
Re: RFC: packages that can be installed by the user but not used as build dependencies
On Mon, 19 Aug 2024 at 20:21, Samuel Thibault wrote: > > Hello, > > Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a > ecrit: > > But users would love to have something like 'qt6-full-dev'. And the > > reason we never provided them with this meta-package is that package > > maintainers would use it almost everywhere, dragging the whole Qt > > installation on each package depending on it... This is a _huge_ waste > > of resources and buildd time (or is it not??) > > It is, but also on maintainer systems when testing in bare chroots etc. > So I don't think maintainers would use it that much in practice. > (similarly to no package currently build-depending on texlive-full) Oh, we've seen that before, that's why we did not add these metapackages to start with :-/ Now back at that time things weren't as big as the latest Qt 5 or 6. Thanks for the feedback! -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: RFC: packages that can be installed by the user but not used as build dependencies
Thanks Samuel and Russ for the feedback! On Mon, 19 Aug 2024 at 20:52, Russ Allbery wrote: > > Lisandro Damián Nicanor Pérez Meyer writes: > > > So, what about if we could have [meta] packages that can be installed by > > the user but not used as Build-Depends entries? Please note that for the > > moment I'm targeting more at the idea itself rather than at the > > implementation (but I'll certainly love to know if you have an idea on > > how could this be implemented). > > > At one point I thought of adding a Lintian test checking for this kind > > of usage, but first and foremost I would like to know if you think this > > is a viable/acceptable idea, maybe even adding a special section in our > > policy. > > I could have sworn that we already had tags like that in Lintian. > Certainly, this is a concept that has already existed in Debian for some > time. There have always been metapackages or other similar cases that are > only intended for end users and would make no sense as build dependencies, > such as all of the task-* packages. > > Lintian feels like the right place to put a test like this. If there are > dependencies like that which could potentially cause serious issues, those > could even be an auto-reject tag. > > I'm not sure that Policy would have much to say about this unless we need > some mechanism for labeling such packages other than a MR to Lintian. The > important information is the list of packages that shouldn't be used this > way, and the hard part is probably gathering that list. Thanks, I'll try to research this idea then! -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: Representing Debian Metadata in Git
On 2024-08-20 15:10, Simon Richter wrote: (...) > Right now, git is used mainly as a network file system, and only tagged > releases are expected to be consistent enough to compile, because often > going from one consistent state to another as an atomic operation would > require multiple changes to be applied in the same commit. > > The imported archive is represented either directly as a tree (which may > be imported from the upstream project if no files are undistributable > for Debian), or via a mechanism that can reproduce a compressed archive > that is bitwise identical to the upstream release, from a tree and some > additional patch data. > > The patch stack is stored as a set of patches inside a directory, and > rebased using quilt. > > An alternate representation stores the patch stack as a branch that is > rebased using git, and then exported to single files. > > The Debian changelog is stored as a file inside Git, but some automation > exists to update this from Git commit messages. > > Debian changelog entries refer to bugs in the Debian Bug Tracking > system. There is a desire to also incorporate forges (currently, GitLab) > and refer to the forges' issue tracker from commit messages (where the > issue tracker is used for team collaboration, while the Debian BTS is > used for user-visible bugs). > > All of this is very silly, because we're essentially storing metadata as > data because we cannot express in Git what we're actually doing, and the > conflicting priorities people have have led to conflicting solutions. > > I'd like to xkcd 927 this now, and find a common mapping. Here's my very likely very naive 2 cents: we are basically maintaining a fork for each non-native package. Being a fork, a "Debianized" package can also live like other "upstream" forks: with its own branch based on the original, make necessary changes and record them as commits; merge original onto its own branch, dealing with conflicts; maintain its own changelog; rinse and repeat. Debian-specific metadata can be represented structurally in commit messages, or if necessary, (still) in a plain debian/ subdirectory that won't conflict with upstream. Then, > From a requirements perspective, I'd like to be able to > > - express patches as commits: > - allow cherry-picking upstream commits as Debian patches > - allow cherry-picking Debian patches for upstream submission > - generate the Debian changelog from changes committed to Git > - express filter steps for generating the upstream archive(s) from a > tree‑ish and some metadata > - store upstream signatures inside Git > - keep a history of patches, including patches applied to previously > released packages these are naturally met; and (...) > Changes to packaging would still be represented as commit objects > containing a tree, but that tree would contain a special entry for the > "debian" subdirectory that points to the last packaging change. no more needed. > This is very high-level so far, because I'd like to get some feedback > first on whether it makes sense to pursue this further.This would use > up the last unused three-bit object type in Git, so it will have to be > very generic on this side to not block future development -- and it > would require a lot of design effort on the Debian side as well to > hammer out the details. Even less thought out, but probably easier to implement once the design is finished. ;) -- Sdrager, Blair Noctis pgpKPKc_MGGaO.pgp Description: OpenPGP digital signature
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Hi, Andreas Tille ezt írta (időpont: 2024. aug. 22., Cs, 17:22): > > Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kekäläinen: > > ... > > ACK to everything. > > > However, pushing for wider Salsa CI adoption I think makes sense as a > > goal by itself, and I would be keen to hear what people think is a > > reasonable way to proceed with that? > > ACK. What about configuring Salsa that Salsa CI is switched on by > default? > > Since 2021 I'm discussing with Debian Java team (last mail about this in > my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which > makes it extra hard to get Salsa CI for these packages. Not sure about > other teams but IMHO the better strategy would be to make it extra > hard to switch of Salsa CI. I wholeheartedly agree with Otto's goals in his first email and wanted to propose the same, just make Salsa CI opt-out instead of opt-in. The default (recipes/debian.yml@salsa-ci-team/pipeline) should work well for most packages. There is another thread about enabling Salsa CI team-wide involving multiple teams and it did not progress much: https://salsa.debian.org/salsa/support/-/issues/170 Enabling CI by default Salsa-wide would finally end those time consuming discussions, too. Cheers, Balint > Kind regards > Andreas. > > [1] https://lists.debian.org/debian-java/2024/06/msg7.html > > -- > https://fam-tille.de >
Re: Representing Debian Metadata in Git
On Aug 22, Aurélien COUDERC wrote: > I personally think it’s crazy / not a good use of my time to try and > mix both upstream and packaging history in the same repo and try to > make git dance around that when handling new upstream releases. The > extents of the ongoing d-devel discussions on the topic tend to > reinforce that feeling. Oh well. FWIW I think it's crazy and not a good use of my time to NOT have the complete upstream history in the same repository that I use for Debian packaging. :-) > (For some value of $fun, try cloning the mesa or > Firefox repos from a sloppy Internet connection for a packaging > analysis or an occasional contribution.) But --depth 1 should work around this. -- ciao, Marco signature.asc Description: PGP signature
Re: Intent to MBF: move from fuse to fuse3
On Wed, 21 Aug 2024 23:24:23 +0200, Chris Hofstaedtler wrote: > Stephen, > and everyone else who pointed out that coinstallability is a > non-issue - thanks! You’re welcome! > About the additional work in fuse/fuse3, #918984 and #927291, I > wonder if they are relevant to the libfuse consumers. Anyway, if we > believe fuse3 works just fine with libfuse2-* consumers, then it > seems like we should fix the package relationships between fuse3 and > fuse. > I'll followup in #927291 with suggestions. Your suggestion there seems fine to me. I’d love to hear Laszlo’s thoughts on the topic too! > Updated MBF text proposal: > > > Subject: SOURCE: move from fuse to fuse3 > > > > Source: SOURCE > > Version: VERSION > > Severity: normal > > > > Dear Maintainer, > > > > your package currently (Build-)Depends on fuse - that is fuse 2.x. > > A newer version of fuse, fuse3, is available since at least > > buster. > > > > Please migrate your package to fuse3, which is actively > > maintained. It would be great if we could remove fuse 2.x in > > the forky development cycle. I would add a reference to https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 (which isn’t a great migration guide but does list all the significant changes people working on this will encounter). > > If you cannot migrate yet, please at least update your Depends: > > line. If you currently have: > > Depends: fuse > > please update that to: > > Depends: fuse3 (>= 3.10.1-3) | fuse (<< 3) > > > > This allows mount.fuse and fusermount to be provided by fuse3, > > which is what the majority of new installs already have [1]. > > > > [1] compare https://qa.debian.org/popcon.php?package=fuse > > and https://qa.debian.org/popcon.php?package=fuse3 > > Does that sound good? It does to me, with the added reference above! Regards, Stephen pgpZen7hGYit8.pgp Description: OpenPGP digital signature
Re: Representing Debian Metadata in Git
Hello, I think that more than you realise of this already exists :) On Tue 20 Aug 2024 at 04:10pm +09, Simon Richter wrote: > From a requirements perspective, I'd like to be able to > > - express patches as commits: >- allow cherry-picking upstream commits as Debian patches >- allow cherry-picking Debian patches for upstream submission git-debrebase and git-dpm already achieve this. > - express filter steps for generating the upstream archive(s) from a tree‑ish > and some metadata Excluded-Files in d/copyright is for this. I guess that you disprefer that because it's part of the tree, though. > - store upstream signatures inside Git Well, there's signatures on their tags. > - keep a history of patches, including patches applied to previously released > packages This is already there with git-debrebase and git-dpm, though it is a bit fiddly to dig it out. -- Sean Whitton signature.asc Description: PGP signature
