Re: Naming of network devices - how to improve it in buster
On Wed, Jul 19, 2017 at 10:53:34PM +0200, Guus Sliepen wrote: > rename mac/00:16:0a:26:99:c6/=en0 > auto en0 > iface en0 ... This should now work in ifupdown 0.8.22. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
User-installable Debian packages?
Hello, There is a fairly new trend out there, best represented by brew.sh and conda.io, to have user-installable packages. These come very handy in HPC-near environments or other shared resources that do not grant root access. In computational biology it is bioconda that is attracting many users. I have not completely thought this through. Admittedly, there is something in me that says that it does not matter since Debian should care more about what the OS is and not what the users use on it. But then again, it is exactly via those user-centric bits that we attract new developers for our distribution. And quite some packages in our distribution do not really need to be installed as root if they were installed where the user has write permissions. There would hence be little overhead over what we have now. Should we not somehow find ways to tag any such location-agnostic packages and prepare dpkg for installing e.g. in $HOME/.debian when it is executed as non-root? Best, Steffen
Re: User-installable Debian packages?
On Sat, Jul 22, 2017 at 8:28 PM, Steffen Möller wrote: > user-installable packages That sounds like Flatpak/Snappy/etc. I would wager most Debian packages are not bit-for-bit identical when you vary the installation prefix (and Debian build tools don't support doing that AFAICT), but you can almost fake user-installable packages using existing binary packages using something like this (sorry about the wrapping). If we were all using Hurd then a few extra overlay mount points would be enough of course. ==> .bash.d/software <== export PATH=$PATH:~/software/usr/bin:~/software/bin export LD_LIBRARY_PATH=~/software/usr/lib:~/software/usr/lib/x86_64-linux-gnu:~/software/lib:~/software/lib/x86_64-linux-gnu export PERL5LIB=~/software/usr/share/perl5 export PYTHONPATH=~/software/usr/lib/python2.7/dist-packages ==> software/update <== #!/bin/sh rm -rf usr apt/archives/*.deb rsync --delete --archive --exclude archives /var/cache/apt/ apt/ rsync --delete --archive --exclude lock --exclude Lock /var/lib/dpkg/ dpkg/ apt-get -o 'Dir::Cache=/home/pabs/software/apt' -o 'Dir::State::status=/home/pabs/software/dpkg/status' --download-only install foo for f in apt/archives/*.deb ; do dpkg -x $f . done -- bye, pabs https://wiki.debian.org/PaulWise
Re: User-installable Debian packages?
On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote: > And quite some packages in our > distribution do not really need to be installed as root if they were > installed where the user has write permissions. There would hence be > little overhead over what we have now. Should we not somehow find ways > to tag any such location-agnostic packages and prepare dpkg for > installing e.g. in $HOME/.debian when it is executed as non-root? Rather than inventing a new wheel and having another Debian-specific thing that can only be used on Debian (and not even on derivatives without it being a "Frankendebian" system), might it be better to use Debian's source, binaries or a mixture of the two as input to creating something cross-distribution like Flatpak, AppImage or Snap? I would personally recommend Flatpak. A Flatpak runtime (the library/platform layer shared by multiple Flatpak apps) is basically just a copy of /usr after applying the /usr merge (as in usrmerge or debootstrap --merged-usr). The reference runtimes produced by Flatpak upstream consist of a Yocto base system with flatpak-builder build scripts (flatpak-builder is a bit like Flatpak's equivalent of debhelper) layering useful libraries above it; but there is nothing to stop a distribution from building their own runtimes from dpkg or RPM packages without using flatpak-builder, and I believe Fedora and Endless are already doing this. Debian could too. A Flatpak app (the user-facing part) is basically the app and any bundled libraries that are needed in addition to what's in the runtime, all built with --prefix=/app. Again, the apps produced by upstreams like GNOME and KDE are typically built from source with flatpak-builder, but that is not required. I believe Fedora are already building their leaf packages into Flatpak apps using their normal RPM spec files (which are mostly position-independent), by overriding the prefix used for their standard macros to /app. Relocatable packages like the ones you describe are trivial to convert into a Flatpak app (just move the files around, like I did for rxvt in http://smcv.pseudorandom.co.uk/2016/xdg-app/ - xdg-app is the old name for Flatpak). Non-relocatable packages (those that hard-code paths) need rebuilding from source, but I have some ideas about using dh-exec to parameterize the packaging (a bit like the way it works in RPM spec files, but simpler) so that can be done automatically. If this interests you, there are two talks at Debconf that you could attend or stream, both on Monday: one by Cosimo Cecchi of Endless, covering both OSTree and Flatpak, and one by me, focusing on Flatpak. I'm hoping to have a proof-of-concept Debian runtime and a couple of apps that use it (probably games) ready by the time I give my talk. S
Re: User-installable Debian packages?
Simon McVittie:
> On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote:
>> And quite some packages in our
>> distribution do not really need to be installed as root if they were
>> installed where the user has write permissions. There would hence be
>> little overhead over what we have now. Should we not somehow find ways
>> to tag any such location-agnostic packages and prepare dpkg for
>> installing e.g. in $HOME/.debian when it is executed as non-root?
>
> [...]
>
> [...] I believe Fedora and Endless are already doing this. Debian could too.
>
I believe that Endless have a patched version of debhelper to do
this[1]. FWIW, I am happy to work with people who are interested in
improving debhelper's support for flatpak et al.
I have mostly been stuck with making this generally applicable without
doing "magic" rewrites of all paths (a la [2]).
> [...] Non-relocatable packages (those
> that hard-code paths) need rebuilding from source, but I have some ideas
> about using dh-exec to parameterize the packaging (a bit like the way it
> works in RPM spec files, but simpler) so that can be done automatically.
>
Do you have an example of these ideas/parameterizations?
I personally toyed with the following two models for doing this:
1) Merge back the substitution that dh-exec supports and have packages
replace usr/bin/X with ${bindir}/X, OR
2) Move from "Install path X" to
"Install (program|doc|...) basename(X)". Then debhelper would be
responsible for figuring out where "basename(X)" was based on what
it requested from the build system.
Either approach would be combined with alternative paths for --prefix
etc. when building the package. For most packagers, I think 2) approach
would be easier compared to having to remember the 10+ substitution
variables that are in play for 1). Though, I think 2) will be a lot
harder to get right for special cases or for items put in locations not
known by debhelper.
Anyway, lets move technical debhelper related follow ups to
debhelper-devel@l.a.d.o (Reply-To accordingly).
Thanks,
~Niels
[1] https://github.com/endlessm/debhelper/
[2]
https://github.com/endlessm/debhelper/commit/25cfa6fc7f974ea799fc6e5ccca469919f233e64
Re: [debhelper-devel] User-installable Debian packages? -> uapt-get
Hi, Niels Thykier wrote: > Simon McVittie: > > On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote: > >> And quite some packages in our > >> distribution do not really need to be installed as root if they were > >> installed where the user has write permissions. There would hence be > >> little overhead over what we have now. Should we not somehow find ways > >> to tag any such location-agnostic packages and prepare dpkg for > >> installing e.g. in $HOME/.debian when it is executed as non-root? There is https://github.com/alexmyczko/uapt-get which also tries to achieve that. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#869368: ITP: golang-github-gin-contrib-sse -- Server-Sent Events implementation in Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 865134 by -1 * Package name: golang-github-gin-contrib-sse Version : 0.0~git20170109.0.22d885f-1 Upstream Author : Manuel Martínez-Almeida * URL : https://github.com/gin-contrib/sse * License : Expat Programming Lang: Go Description : Server-Sent Events implementation in Go Server-sent events (SSE) is a technology where a browser receives automatic updates from a server via HTTP connection. The Server-Sent Events EventSource API is standardized as part of HTML5 by the W3C. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-github-gin-gonic-gin #865134 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869369: ITP: golang-gopkg-go-playground-validator.v8 -- Go Struct and Field validation (version 8.x)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 865134 by -1 X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-gopkg-go-playground-validator.v8 Version : 8.18.1-1 Upstream Author : Dean Karn * URL : https://github.com/go-playground/validator * License : Expat Programming Lang: Go Description : Go Struct and Field validation (version 8.x) Package validator implements value validations for structs and individual fields based on tags. . It has the following unique features: * Cross Field and Cross Struct validations by using validation tags or custom validators. * Slice, Array and Map diving, which allows any or all levels of a multidimensional field to be validated. * Handles type interface by determining it's underlying type prior to validation. * Handles custom field types such as sql driver Valuer see Valuer * Alias validation tags, which allows for mapping of several validations to a single tag for easier defining of validations on structs * Extraction of custom defined Field Name e.g. can specify to extract the JSON name while validating and have it available in the resulting FieldError Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-github-gin-gonic-gin #865134 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869370: ITP: golang-gopkg-go-playground-assert.v1 -- Basic Assertion Library used along side native go testing
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 869369 by -1 X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-gopkg-go-playground-assert.v1 Version : 1.2.1-1 Upstream Author : Dean Karn * URL : https://github.com/go-playground/assert * License : Expat Programming Lang: Go Description : Basic Assertion Library used along side native go testing Package assert is a Basic Assertion library used along side native go testing, with building blocks for custom assertions. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-gopkg-go-playground-validator.v8 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869389: ITP: libmpsse -- SPI/I2C control via FTDI chips
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: libmpsse Version : 1.3+git-2-a2eafa2 Upstream Author : Craig Heffner * URL or Web page : https://github.com/devttys0/libmpsse * License : BSD-2-Clause Description : SPI/I2C control via FTDI chips Libmpsse is a library for interfacing with SPI/I2C devices via FTDI's FT-2232 family of USB to serial chips. Additionally, it provides control over the GPIO pins on the FTDI chips and supports a raw bitbang mode as well. This package contains the development header files. -- This library is the first part of an effort to package all software necessary to run a TheThingsNetwork LoRaWAN Gateway, see https://github.com/ttn-zh/ic880a-gateway My packaging work so far can be found at https://github.com/xtaran/libmpsse-debian-packaging Help welcome! If anyone wants to join this effort, I'm happy to create and according Alioth/Pagura/whatever project.
