Hierarchical tasksel / Blends support (Was: Debian Installer Buster Alpha 5 release)
Hi Cyril, thanks for your continuous work on the installer and lots of new great features. On Sat, Feb 02, 2019 at 12:45:32PM +0100, Cyril Brulebois wrote: > We need your help to find bugs and further improve the installer, > so please try it. Sorry for repeating my question[1] but it is not clear to me whether support of Blends is a planed feature of the Buster installer. From release to release we realise that it is missing (for Stretch it came very close - see bug #851555). From some face to face meetings at DebConf I've got the impression that it is all about having an hierarchical tasksel (historical fun fact - first bug about this was in 2003 #186085 where the request to add Blends was de facto refused since tasksel is not hierarchical). I'm long enough in Open Source that I understood asking others to implement features that do not belong into their own field of interest is not very promising. But it would help me a lot to get at least a kind of authoritative answer to my question: If I would try to work on a patch for tasksel to enable hierarchical selection in the form [ ] Debian Pure Blends --> if selected open a new screen presenting Blends would this be accepted for the Buster+1 installer? (I think its way to late for Buster to implement this.) If I get a definitive "Yes, that would be welcome" I'd stop fixing lots of bugs in Debian Med packages and shift my priorities a bit more into this direction. But before I'd give up some urgently needed QA work I'd like to hear the opinions of others whether a hierarchical tasksel is a wanted feature that has any chance to be accepted and be used in the Buster+1 installer. Kind regards Andreas. [1] https://lists.debian.org/debian-boot/2018/12/msg00266.html -- http://fam-tille.de
package management symlink
> I'm not convinced that having to remember different package manager > names is a significant problem for new people adopting a Linux > distribution. The name is a very small part of the > differences between > the package managers (they have very different > behaviour models, not > just names), and the package managers are a small part of all the > differences between distributions. Many developers don't provide their software via a repository instead they provide the source code with an INSTALL file. They depend on dependencies they resolve through the repositories. Approving "nimue" just as symlink that points to the package management system across linux systems would enable them to write just one install script for debian and red hat systems for example. But I will go the way by providing the function as package. Best wishes Sören alias Valor Naram
Should we list Patreon funding pages in d/u/metadata?
Hello, at times I now find pointers to Patron (https://www.patreon.com), Flattr (https://flattr.com/) et al. (https://alternativeto.net/software/patreon/) in the READMEs of a software I am about to package. Is this something that should be referenced in debian/upstream/metadata? Anything speaking against it? The place this should go to IMHO is d/u/metadata. Something like: Donations: - Name: Patreon Entry: ImGui These kind of requests are not too frequent, yet. I hence expect this to be a bit of a side-issue for everyone. Anyway - I think it is a nice gesture. And upstream should appreciate this extra effort to help them. Best, Steffen
Bug#921422: ITP: spirv-llvm-translator -- bi-directional translator for LLVM/SPIRV
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: spirv-llvm-translator Version : 7.0.1 Upstream Author : Khronos Group * URL : https://github.com/KhronosGroup/SPIRV-LLVM-Translator * License : BSD Programming Lang: C, C++ Description : bi-directional translator for LLVM/SPIRV SPIRV-LLVM-translator is a LLVM/SPIRV bi-directional translator. This package includes a library and a tool for translation between LLVM IR and SPIR-V. This package is needed by Intel Compute Runtime.
Re: package management symlink
Sören Reinecke writes: >> I'm not convinced that having to remember different package manager >> names is a significant problem for new people adopting a Linux >> distribution. The name is a very small part of the >> differences between >> the package managers (they have very different >> behaviour models, not >> just names), and the package managers are a small part of all the >> differences between distributions. > > Many developers don't provide their software via a repository instead > they provide the source code with an INSTALL file. They depend on > dependencies they resolve through the repositories. Approving "nimue" > just as symlink that points to the package management system across > linux systems would enable them to write just one install script for > debian and red hat systems for example. No, that already stops working when package are named differently which is frequently the case. There is no readline-devel package in Debian and no libreadline-dev in Red Had or Gentoo. Also what you suggest already exists, for example in the form of "pacapt" (but there are alternatives too!). What is the benefit of adding yet another version of these scripts? Ansgar
Bug#921426: ITP: opencl-clang -- thin wrapper for clang
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: opencl-clang Version : git Upstream Author : Intel * URL : https://github.com/intel/opencl-clang * License : public-domain Programming Lang: C++ Description : thin wrapper for clang Common clang is a thin wrapper library around clang. Common clang has OpenCL-oriented API and is capable of compiling OpenCL C kernels to SPIR-V modules. This package is needed by Intel Compute Runtime.
Re: Should we list Patreon funding pages in d/u/metadata?
On Tue, Feb 5, 2019 at 6:02 PM Steffen Möller wrote: > at times I now find pointers to Patron (https://www.patreon.com), > Flattr (https://flattr.com/) et al. > (https://alternativeto.net/software/patreon/) in the READMEs of a > software I am about to package. Is this something that should be > referenced in debian/upstream/metadata? Anything speaking against it? Yes, definitely. > The place this should go to IMHO is d/u/metadata. Something like: > > Donations: > - Name: Patreon > Entry: ImGui According to the spec, the field is named 'Donation' and should be a URL: https://wiki.debian.org/UpstreamMetadata -- bye, pabs https://wiki.debian.org/PaulWise
Bug#921453: ITP: libgraphqlparser -- parser for GraphQL
Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libgraphqlparser Version : 0.7.0 Upstream Author : Facebook Inc. * URL : https://github.com/graphql/libgraphqlparser * License : Expat Programming Lang: C++ Description : parser for GraphQL libgraphqlparser is a parser for GraphQL, a query language created by Facebook for describing data requirements on complex application data models, implemented in C++11. It can be used on its own in C++ code (or in C code via the pure C API defined in the c subdirectory), or you can use it as the basis for an extension module for your favorite programming language instead of writing your own parser from scratch.
Bug#921464: ITP: gnome-books -- ebook reader for GNOME
Package: wnpp Severity: wishlist Owner: jbi...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: gnome-books Version: 3.31.90 Upstream Authors: Cosimo Cecchi License : GPL-2+ Programming Lang: JavaScript Homepage: https://wiki.gnome.org/Apps/Books Description: ebook reader for GNOME GNOME Books is a simple application to access and organize your ebooks. It is meant to be a simple and elegant replacement for using a file manager to deal with ebooks. The app supports comic books and ePub books. Other Info -- Before GNOME 3.32, this app was bundled as part of the GNOME Documents app. It was split to allow users to easily install one app without the other. I am intending to get the new versions of these 2 apps into Debian Buster to fix the usability problem when you try to install or remove one of the apps in the GNOME Software app. Packaging is maintained by the Debian GNOME Team at https://salsa.debian.org/gnome-team/gnome-books Thanks, Jeremy Bicha
Re: package management symlink
Am Di., 5. Feb. 2019 um 12:03 Uhr schrieb Ansgar : > > Sören Reinecke writes: > >> I'm not convinced that having to remember different package manager > >> names is a significant problem for new people adopting a Linux > >> distribution. The name is a very small part of the > >> differences between > >> the package managers (they have very different > >> behaviour models, not > >> just names), and the package managers are a small part of all the > >> differences between distributions. > > > > Many developers don't provide their software via a repository instead > > they provide the source code with an INSTALL file. They depend on > > dependencies they resolve through the repositories. Approving "nimue" > > just as symlink that points to the package management system across > > linux systems would enable them to write just one install script for > > debian and red hat systems for example. > > No, that already stops working when package are named differently which > is frequently the case. There is no readline-devel package in Debian > and no libreadline-dev in Red Had or Gentoo. > [...] Additionally to what Ansgar already said, we already have had PackageKit for ages. Just use the `pkcon` tool to trigger package installations in a distribution-agnostic way - if you know the names of the packages you want to install for each distribution, of course. (for applications and very few software components, AppStream can jump in as a distro-agnostic way to install software via `appstreamcli install `. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#921496: ITP: swayidle -- Idle management daemon for Wayland
Package: wnpp Severity: wishlist Owner: Birger Schacht * Package name: swayidle Version : 1.2 Upstream Author : Drew DeVault * URL : https://github.com/swaywm/swayidle * License : MIT Programming Lang: C Description : Idle management daemon for Wayland This is sway's idle management daemon, swayidle. It is compatible with any Wayland compositor which implements the KDE idle protocol. See the man page, swayidle(1), for instructions on configuring swayidle.
Bug#921497: ITP: swaylock -- Screen locker for Wayland
Package: wnpp Severity: wishlist Owner: Birger Schacht * Package name: swaylock Version : 1.3 Upstream Author : Drew DeVault * URL : https://github.com/swaywm/swaylock * License : MIT Programming Lang: C Description : Screen locker for Wayland swaylock is a screen locking utility for Wayland compositors. It is compatible with any Wayland compositor which implements the following Wayland protocols: * wlr-layer-shell * wlr-input-inhibitor * xdg-output * xdg-shell
