Re: Debian Project Leader Elections 2020: Platforms
Hi Kurt, On Tue, Mar 17, 2020 at 2:14 PM Kurt Roeckx - Debian Project Secretary wrote: > The platforms for all 3 the candidates are now avaiable at: > https://www.debian.org/vote/2019/platforms/ You might mean: https://www.debian.org/vote/2020/platforms/ :) Best, Utkarsh
Re: RFC: Replacing vim-tiny with nano in essential packages
John Paul Adrian Glaubitz writes: > And I assume, once we have fixed vim everywhere, it will be broken again > at some point due to the fact vim upstream is continuously adding features > which is why it's no longer suitable being an editor to be shipped in a > minimal installation. And Debian ships vim-tiny, not vim, as part of the minimal installation. That the same source package also builds other versions doesn't really matter for vim-tiny. The only problem you mentioned was vim-tiny (arch: any) depending on vim-common (arch: all) and these sometimes getting out of sync on Debian Ports. I don't think that is a good reason to switch editors and there are other ways to work around that problem. But if we really wanted a minimal editor: `ed` is still there with an Installed-Size: 116 kB and no external dependencies besides libc6. It also works without fancy terminal features. Or have debootstrap not install any editor. But if I remember correctly that idea wasn't popular. Ansgar
Re: RFC: Replacing vim-tiny with nano in essential packages
On Tue, Mar 17, 2020 at 11:50 AM Ansgar wrote: > John Paul Adrian Glaubitz writes: > > And I assume, once we have fixed vim everywhere, it will be broken again > > at some point due to the fact vim upstream is continuously adding features > > which is why it's no longer suitable being an editor to be shipped in a > > minimal installation. > > And Debian ships vim-tiny, not vim, as part of the minimal > installation. That the same source package also builds other versions > doesn't really matter for vim-tiny. > > The only problem you mentioned was vim-tiny (arch: any) depending on > vim-common (arch: all) and these sometimes getting out of sync on Debian > Ports. I don't think that is a good reason to switch editors and there > are other ways to work around that problem. just my 5 cents: Any alternative to vi(m), which does not build, is a good from system administrator view. Talking about installer, nano/busybox/nvi all good alternatives. Thanks.
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/17/20 9:49 AM, Ansgar wrote: > John Paul Adrian Glaubitz writes: >> And I assume, once we have fixed vim everywhere, it will be broken again >> at some point due to the fact vim upstream is continuously adding features >> which is why it's no longer suitable being an editor to be shipped in a >> minimal installation. > > And Debian ships vim-tiny, not vim, as part of the minimal > installation. That the same source package also builds other versions > doesn't really matter for vim-tiny. > > The only problem you mentioned was vim-tiny (arch: any) depending on > vim-common (arch: all) and these sometimes getting out of sync on Debian > Ports. I don't think that is a good reason to switch editors and there > are other ways to work around that problem. So, are you going to fix the testsuite failures then? I don't think it's fair to downplay problems and then not be willing to provide any possible solutions to it. And the issue with vim-common being out of sync is not trivially fixable with Debian Ports as we don't have the cruft feature that DAK has. Unless someone actually goes ahead and fixes the problem, it will continue to exist which is why I made this suggestion. And with even the maintainer of the vim package saying that he would like to get rid of vim-tiny, I don't think you have a strong argument in this discussion. After all, anyone wanting to use a particular editor can just install it, for anyone else, a basic version of vi and nano are enough when boooting a rescue system. You are not going to work on software projects with a minimal system or a rescue environment, are you? Most likely, you are using the editors in d-i to fix an entry in /etc/fstab or the GRUB configuration. > But if we really wanted a minimal editor: `ed` is still there with an > Installed-Size: 116 kB and no external dependencies besides libc6. It > also works without fancy terminal features. It isn't about the size of the package. It's about src:vim constantly failing to build from source and no one stepping up to fix these problems. And I don't really see a point in using a fully fledged version of vim in a minimal environment when simple alternatives exist. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 2020-03-17 07:36:23, John Paul Adrian Glaubitz wrote: snip > > As far as priorities, whatever the project/ftp-masters decide is fine > > with me. I've wanted to drop vim-tiny altogther, but that's been met > > with resistance. > > Sounds like dropping vim-tiny and replacing it with vi from busybox > would be a good approach to fix this particular issues, doesn't it? Yes, I think this is most sensible thing to do. We're already having both (busybox and vim) in basic setup and looks like vim even in tiny version is adding maintenance overhead we don't need. Keeping compatibility with vim is something lots of people used to, so I'd hope that keeping it will help us to avoid people complaining too much. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: DFSG of disk image with contrib package
Le 17/03/2020 à 07:26, Richard Laager a écrit : > On 3/16/20 12:25 PM, Emmanuel Kasper wrote: >> For extended functionality, I build some of the disk images with a >> package from contrib, namely virtualbox-dkms > > Could you use KVM (and if necessary, libvirt) instead? > I do have KVM/libvirt disk images to use with vagrant-libvirt too. But Vagrant with VirtualBox is more popular, as it runs multiplatform, and has an extra shared folder functionality which works as unpriviledged user. vagrant-libvirt requires root rights for the shared folder functionality.
Re: RFC: Replacing vim-tiny with nano in essential packages
On Tue, 17 Mar 2020 at 10:10:22 +0100, John Paul Adrian Glaubitz wrote: > And the issue with vim-common being out of sync is not trivially fixable > with Debian Ports as we don't have the cruft feature that DAK has. It seems to me that this is a large part of the problem here. DAK presumably has that feature for good reasons, and if the Ports archive is missing features that DAK has, the Ports is going to hit bad situations that the maintainers of "Debian proper" don't necessarily consider to be a big deal because the DAK-driven Debian archive copes better with them. If anything, I would expect the Ports archive to need to be *more* featureful than the archive for release architectures, because on release architectures it's a RC bug if an architecture is long-term out-of-sync with the other release architectures, whereas on Ports there are sometimes architecture-specific modifications to packages (if I understand correctly), and there are definitely architectures that don't/can't keep up, either because their buildds are slower or because a build-dependency FTBFS on that architecture. smcv
Re: RFC: Replacing vim-tiny with nano in essential packages
Geert Stappers wrote on 17/03/2020: > On Mon, Mar 16, 2020 at 07:40:40PM -0400, Peter Silva wrote: >> On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote: >>> On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote: >>> I hadn't realised how fat nano is (not the only consideration of course, but zile is very good on this measure and surprisingly functionfull). >>> >>> You are comparing apples with oranges! The nano package comes with a lot >>> of help files and translations. You need to compare things to nano-tiny: >>> Instaled sizes: zile: 365K busybox: 786K vim-tiny: 1547K nvi: 1605K busybox-static: 2045K nano: 2469K >>> >>> nano-tiny: 234K >>> >> so maybe we just add nano-tiny as an option to vim-tiny. >> because we understand vim is not newbie friendly, but for all the old >> hands, nano is not friendly to us. >> 234K is a small price to pay. > > > Not yet seen in this thread, is the package vis Vis maintainer here, thanks for mentioning it. I really like this little editor, but I don't think it's a good fit for what we are looking for here as it has a small userbase and bus factor. Good news is that upstream is active again and a new release should be cut soon. Paride
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
[sorry for the late reply; catching up on email] On Fri, Feb 21, 2020 at 04:23:15PM -0500, Anthony DeRobertis wrote: > On 2/21/20 2:00 AM, Wouter Verhelst wrote: > > Even so, if we want to do so, this can be done correctly by a preinst > > script in new libc, by way of a script that does the following: > > > > cp -a /lib/ /usr/lib/ > > ln -sf /lib/ /usr/lib/ > > > > The first of the above two creates the new file; the second replaces the > > old file, atomically, by a symlink. > > Errr, pretty sure you meant to have the ln arguments in the opposite order. > The link name is the second argument to ln. Yes. I keep messing that up in production (ln is one of those commands that I continually need to read the man page of) > Besides that, you need a sync after the cp. Otherwise (in the event of an > ill-timed crash) the data may not be written out, and you might wind up with > /usr/lib/ being, e.g., a zero-byte file (with > /lib/ a symlink to it). Possibly you even end up with > /usr/lib/ missing, and /lib/ a > dangling link. Good point, yes. My point was mostly though that it's possible to implement this atomically, not to write a bug free script ;-) -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Bug#954160: ITP: freeipa-healthcheck -- Health check tool for FreeIPA
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: freeipa-healthcheck Version : 0.5 Upstream Author : Red Hat Inc. * URL : https://github.com/freeipa/freeipa-healthcheck * License : GPL3 Programming Lang: Python Description : Health check tool for FreeIPA The FreeIPA health check tool provides a set of checks to proactively detect defects in a FreeIPA cluster.
Re: RFC: Replacing vim-tiny with nano in essential packages
(I'm not subscribed to debian-devel, please keep me CC'ed) > It seems to me that this is a large part of the problem here. DAK > presumably has that feature for good reasons, and if the Ports archive is > missing features that DAK has, the Ports is going to hit bad situations > that the maintainers of "Debian proper" don't necessarily consider to be > a big deal because the DAK-driven Debian archive copes better with them. It still remains a problem because we don't release Debian with packages that fail to build from source. If you are just ignoring the problem here, you will postpone its solution into the future, nothing else. Eventually, someone has to fix vim. > If anything, I would expect the Ports archive to need to be *more* > featureful than the archive for release architectures, because on release > architectures it's a RC bug if an architecture is long-term out-of-sync > with the other release architectures, whereas on Ports there are sometimes > architecture-specific modifications to packages (if I understand correctly), > and there are definitely architectures that don't/can't keep up, either > because their buildds are slower or because a build-dependency FTBFS on > that architecture. vim *is* out of sync. It's not a problem that affects Debian Ports only, it's not a ports-specific bug. It just shows more prominently in Debian Ports. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#954170: ITP: anndata -- Annotated gene by sample numpy matrix
Package: wnpp Severity: wishlist Owner: Diane Trout * Package name: anndata Version : 0.7.1 Upstream Author : 2017-8 P. Angerer, F. Alexander Wolf, Theis Lab * URL : http://github.com/theislab/anndata * License : BSD 3 clause Programming Lang: Python Description : Annotated gene by sample numpy matrix AnnData provides a scalable way of keeping track of data together with learned annotations. It is used within Scanpy, for which it was initially developed. Both packages have been introduced in Genome Biology (2018). I was planning on managing this package in the debian-med team. It's a dependency of scanpy
Re: RFC: Replacing vim-tiny with nano in essential packages
Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]: > And Debian ships vim-tiny, not vim, as part of the minimal > installation. That the same source package also builds other versions > doesn't really matter for vim-tiny. > > The only problem you mentioned was vim-tiny (arch: any) depending on > vim-common (arch: all) and these sometimes getting out of sync on Debian > Ports. I don't think that is a good reason to switch editors and there > are other ways to work around that problem. Agree. > But if we really wanted a minimal editor: `ed` is still there with an > Installed-Size: 116 kB and no external dependencies besides libc6. It > also works without fancy terminal features. Well, yes. But while mostly everybody who reads this will be moderately proficient with the basic subset of vi, I don't know anybody who'd know how to drive ed (I have done it, but I surely don't remember how to). > Or have debootstrap not install any editor. But if I remember correctly > that idea wasn't popular. I agree with those that would oppose. Having an editor handy is core to be able to get a Unix system out of many unexpected situations. Having an Unix system without an editor is IMO having a broken system. Could make sense for embedded targets... but nothing else.
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/17/20 8:34 PM, Gunnar Wolf wrote: > Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]: >> And Debian ships vim-tiny, not vim, as part of the minimal >> installation. That the same source package also builds other versions >> doesn't really matter for vim-tiny. >> >> The only problem you mentioned was vim-tiny (arch: any) depending on >> vim-common (arch: all) and these sometimes getting out of sync on Debian >> Ports. I don't think that is a good reason to switch editors and there >> are other ways to work around that problem. > > Agree. The vim maintainer himself would like to get rid of the vim-tiny package and I'm not sure there is a compelling argument that you have to use a particular vi implementation in a minimal environment. I wouldn't have a problem with vim if the package didn't fail its testsuite that often. While the last upload has helped a little, it's still FTBFS on five architectures [1], three of them in Debian Ports meaning I won't be able to build usable d-i images and several users have asked me for updated images already. >> But if we really wanted a minimal editor: `ed` is still there with an >> Installed-Size: 116 kB and no external dependencies besides libc6. It >> also works without fancy terminal features. > > Well, yes. But while mostly everybody who reads this will be > moderately proficient with the basic subset of vi, I don't know > anybody who'd know how to drive ed (I have done it, but I surely don't > remember how to). It's not about the size of the editor package but more about using an editor which causes less build issues. >> Or have debootstrap not install any editor. But if I remember correctly >> that idea wasn't popular. > > I agree with those that would oppose. Having an editor handy is core > to be able to get a Unix system out of many unexpected > situations. Having an Unix system without an editor is IMO having a > broken system. Could make sense for embedded targets... but nothing else. I'm not arguing that, I just want to solve this particular problem. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
rereadmin the ln manpage
On 17.03.20 15:48, Wouter Verhelst wrote: > Yes. I keep messing that up in production (ln is one of those commands > that I continually need to read the man page of) I suggest the `tldr` command for that... *t
Re: RFC: Replacing vim-tiny with nano in essential packages
John Paul Adrian Glaubitz dijo [Tue, Mar 17, 2020 at 08:40:43PM +0100]: > >> The only problem you mentioned was vim-tiny (arch: any) depending on > >> vim-common (arch: all) and these sometimes getting out of sync on Debian > >> Ports. I don't think that is a good reason to switch editors and there > >> are other ways to work around that problem. > > > > Agree. > > The vim maintainer himself would like to get rid of the vim-tiny package > and I'm not sure there is a compelling argument that you have to use a > particular vi implementation in a minimal environment. > > I wouldn't have a problem with vim if the package didn't fail its > testsuite that often. While the last upload has helped a little, it's > still FTBFS on five architectures [1], three of them in Debian Ports > meaning I won't be able to build usable d-i images and several users > have asked me for updated images already. What about nvi? Yes, I just checked, it lists the QA group as the maintainer... but if it is not RC, giving it more visibility can attract somebody to maintain it (I won't volunteer, I know a bit what's good for the project 😉) > >> But if we really wanted a minimal editor: `ed` is still there with an > >> Installed-Size: 116 kB and no external dependencies besides libc6. It > >> also works without fancy terminal features. > > > > Well, yes. But while mostly everybody who reads this will be > > moderately proficient with the basic subset of vi, I don't know > > anybody who'd know how to drive ed (I have done it, but I surely don't > > remember how to). > > It's not about the size of the editor package but more about using an > editor which causes less build issues. ...and which still works for the users. Yes, ed _can_ be used. But I really do not think including ed would satisfy a regular user in need to unbreak a minimal system...
Re: RFC: Replacing vim-tiny with nano in essential packages
Gunnar Wolf writes: >> > Well, yes. But while mostly everybody who reads this will be >> > moderately proficient with the basic subset of vi, I don't know >> > anybody who'd know how to drive ed (I have done it, but I surely don't >> > remember how to). >> >> It's not about the size of the editor package but more about using an >> editor which causes less build issues. > > ...and which still works for the users. Yes, ed _can_ be used. But I > really do not think including ed would satisfy a regular user in need > to unbreak a minimal system... A regular user shouldn't have to deal with a minimal system, but should have a less minimal editor installed or use a rescue system. Ansgar
Re: MiniDebConf Maceió (Brazil) March 25-28, 2020
Hi all, As expected, we MiniDebConf Maceió organizers decided postpone the event. We will wait to rescheduled it on the future. Best regards, Em 18/01/2020 16:39, Paulo Henrique de Lima Santana escreveu: > Hi, > > Did you come to DebConf19 last year? It's time you come back, but now > to know the Northeast and its beautiful beaches! > What? you didn't come?? So, it's your new opportunity to visit Brazil > :-) > > The brazilian community of Debian developers and users invites you to > the MiniDebConf in Maceió, Brazil. MiniDebConf will take place from > March 27th to 28th at Federal University of Alagoas, and it will be > preceded by a MiniDebCamp from March 25th to 26th at the same location. > > Maceio is known as "paradise of waters", is considered as the > "Brazilian Caribbean" due to its natural beauties that attract tourists > from around the world. > > CfP is open until February 15th. > > Come join us the 4th MiniDebConf edition in Brazil, and the 1st in > Northeast! > > https://maceio2020.debian.net > -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 signature.asc Description: OpenPGP digital signature
