Re: Disabling automatic upgrades on Sid by default?
On Вс, 2020-12-27 at 22:58 +, Lyndon Brown wrote: > As I envision it, we could have "rolling" and maybe "rolling-unstable" > (or "rolling-testing") with continual upgrades typically going directly > into "rolling", or with a 0-day migration from "rolling-unstable", with > the purpose of "rolling-unstable" being (1) for preparing multi-package > upgrades like with ppp and network-manager as which kicked off this > discussion, to avoid the upgrade conflict that caused, and (2) for > testing of anything with greater than normal potential to cause serious > will-not-boot type breakage (which might thus be given an unusual > larger migration delay, or a non-automatic migration). We thus get the > best of both worlds of current testing & unstable without the worst. > When it gets to "freeze time" for prepping a new stable release, a > snapshot of "rolling" could be taken as the new "stable-prep", and > worked on for a couple months or so with selective (direct or from- > rolling) upgrades until ready for release as stable. The big problem > would be how best to migrate those on current testing/unstable > channels. We could invent such "rolling" where packages enter by the same rules as for "testing" but with zero delay. And probably, automatic removals due to RC-bugs would happen more quickly to stop rollout of broken software. So all linked packages would go together as soon as they become ready.
Re: Reconsider sending ITP bugs to debian-devel: a new list?
For the record, the latest digest of the debian-devel@ list #194 consists of 17 emails. 13 of them are ITP forwards, the remaining 4 emails are about ITP forwarding. And Evolution, due to a bug[1], opens the digest for 2 minutes 14 seconds. 😞️ If the ITP reports went to a different list, Evolution would be 76% faster in the case. One who want to track these reports can subscribe to the wnpp pseudo- package through tracker.d.o. Is anyone going to discuss them here? [1]: https://launchpad.net/bugs/1908656 signature.asc Description: This is a digitally signed message part
Re: Re: Debian choice of upstream tarballs for packaging
> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz I think you should add +ds version suffix or similar to indicate repacking for Debian. Does it still make sense provided that upstream does not care much of tarballs? signature.asc Description: This is a digitally signed message part
Re: enabling link time optimizations in package builds
LTO significantly increase memory requirements for buildd machines. Do we have enough RAM and swap on each build server? > Link time optimizations are also at least turned on in other distros like > Fedora, OpenSuse (two years) and Ubuntu (one year). I know Ubuntu has builders with 8 GB RAM + 4 GB swap which is not enough in all cases. https://answers.launchpad.net/launchpad/+question/694428 signature.asc Description: This is a digitally signed message part.
Re: how about telegram channel
On Tue, 19 Jul 2022 21:01:22 +0200 Bartosz Fenski wrote: > I created one > > https://t.me/debian_devel > > Of course I'm willing to give admin access to it to whoever we decide is > correct person / group to cover that. You created broadcasting channel. Only you and admins can post there. signature.asc Description: This is a digitally signed message part.
Bug#960543: ITP: vim-ale -- Asynchronous Lint Engine for Vim 8 and NeoVim
Package: wnpp Severity: wishlist Owner: Nicholas Guriev Control: forwarded -1 https://github.com/dense-analysis/ale/issues/3160 * Package name: vim-ale Version : 2.6.0 Upstream Author : w0rp * URL : https://github.com/dense-analysis/ale * License : BSD-2-Clause Programming Lang: VimScript Description : Asynchronous Lint Engine for Vim 8 and NeoVim ALE (Asynchronous Lint Engine) is a plugin providing linting (syntax checking and semantic errors) in NeoVim 0.2.0+ and Vim 8 while you edit your text files, and acts as a Vim Language Server Protocol client. I have done some of work on packaging, you can see a Git repository in my namespace at salsa.d.o. https://salsa.debian.org/mymedia/vim-ale/-/tree/mymedia/master
Bug#960544: ITP: vim-vader -- simple vimscript test framework
Package: wnpp Severity: wishlist Owner: Nicholas Guriev * Package name: vim-vader Upstream Author : Junegunn Choi * URL : https://github.com/junegunn/vader.vim * License : Expat (MIT-like) Programming Lang: VimScript Description : simple vimscript test framework Vader.vim is a simple tool designed to help you write VimScript tests in a readable way. It will be a dependency of the vim-ale package. I have done some of work on packaging, you can see a Git repository in my namespace at salsa.d.o. https://salsa.debian.org/mymedia/vim-vader/-/tree/mymedia/master
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, 2020-10-07 at 19:17 -0400, Jeremy Bicha wrote: > On Wed, Oct 7, 2020 at 7:15 PM Jeremy Bicha wrote: > > You should be aware that Ubuntu implemented this idea 2 years ago. > > Oh, I misread. Ubuntu used /usr/bin/browse but 'open' sounds a lot better. In my view, both of these words, "browse" or "open" do not look like a command for computer. Their drawback is that they are too general. signature.asc Description: This is a digitally signed message part
