Re: Split Packages files based on new section "buildlibs"

[Thomas Goirand]

On 11/9/20 11:36 PM, Joerg Jaspert wrote:
> [4] We first thought about an entire new archive, but that is much more
>    separate, creating a higher workload on maintaining it.
>    Additionally, it would create problems following the licenses of
>    packages. Then we thought about a new component besides
>    main/contrib/non-free, and while that works better, it still has
>    many negative side effects including requiring extra package
>    uploads, extra tracking for the release team and requiring multiple
>    components if we later decide that we need to support this for all
>    of main, contrib and non-free.

Hi Joerg,

First of all, thanks for working on this, and caring for the size of the
indices, which will greatly benefit our users.

I'm sorry but I don't understand everything here. If we aren't going to
have new components like main/contrib/non-free, how will it work? We
main contain a new Packages.{gz,xz} file containing these? I'm guessing
that it's not just a modification to that file, because you wrote the
goal is to diminish its size...

Cheers,

Thomas Goirand (zigo)

Re: restarting instanced systemd services on upgrade

[Simon McVittie]

On Wed, 11 Nov 2020 at 09:32:46 +0900, Norbert Preining wrote:
> once again, thanks a lot. I have now tried out your suggestion and it
> works nicely. Just to make sure, I have now the following units, see
> below. I am aware that the system instantiation service onedrive@ is not
> optimal since it expects $HOME to be /home/%i, but let us leave this
> aside for now. I will document other options like lingering etc.

I still think doing this as a user service (like pulseaudio, gpg-agent,
dbus-daemon --session, rygel, flatpak-session-helper, tracker-store, etc.)
would be a better approach to use by default: that sort of thing is exactly
what `systemd --user` is designed for.

Or perhaps it would make sense to have both implementations, like you said
you've done, but swap round their enabledness: enable the user service by
default, but provide example system units (disabled by default) that can
be used by sysadmins who consider the advantages of running this as a
system service to outweigh the disadvantages?

I assume this package is a FUSE filesystem (or some other daemon) for access
to Microsoft OneDrive? It might be useful to compare it with other
implementations of the same sort of thing. In GNOME, OneDrive access is not
currently implemented (https://gitlab.gnome.org/GNOME/gvfs/-/issues/273);
but if it was, it would be a backend for gvfs, which is a collection of
user services (gvfs already knows how to access Google Drive, but not
OneDrive). One of the motivations for `systemd --user` and the D-Bus
"user bus" (which is one per `systemd --user`) was to make services like
gvfs available to non-GUI user processes like cron jobs.

It looks as though the system service would have to be enabled manually
on a per-user basis *anyway*, because the package can't know which users
it is meant to be enabled for; so perhaps the best way would be something
like this in README.Debian, and arranging the packaging so that it becomes
true:

onedrive.service is run as a per-user systemd service for each
logged-in user by default. Individual users can disable or enable the
service for themselves only, by running one of these commands:

$ systemctl --user disable onedrive.service
$ systemctl --user enable onedrive.service

The system administrator can control whether the service is run by
default for users who have not explicitly disabled or enabled it by
running one of these commands:

# systemctl --user --global disable onedrive.service
# systemctl --user --global enable onedrive.service

It is also possible to run onedrive as a system-level service on behalf
of particular users. [explain here why you might want to do that]

For example, if a system-level instance of onedrive should run for user
"norbert", the system administrator would:

- disable the per-user service for the user:
  # runuser -u norbert -- systemctl --user disable onedrive.service

- then enable a system service that runs as that user instead:
  # systemctl enable onedrive@norbert.service

> /lib/systemd/system/onedrive@.service
> --
...
> After=network-online.target
> Wants=network-online.target
> PartOf=onedrive.target
> 
> [Service]
> ExecStart=/usr/bin/onedrive --monitor --confdir=/home/%i/.config/onedrive

If you are sure you want this to be a system service, this looks
right. However, as you said, this assumes every user's home directory
is /home/${LOGNAME}. It also won't respect the user's ${XDG_CONFIG_HOME}
(it assumes the default ~/.config).

systemd documents that it sets ${HOME} for system services that
have User= (at least in recent-ish versions, I'm not sure how
old this feature is), so you could probably do a bit better by
using --confdir=${HOME}/.config/onedrive (see systemd.service(5)
for full details of how variables introduced by $ are parsed
in ExecStart). However, that's still making an assumption about
${XDG_CONFIG_HOME}.

More generally, any per-user environment variables that have been set
for the user won't be set for system services that happen to run as
the same uid, which could lead to unexpected results. For example, if
users set PATH, XDG_CACHE_HOME, XDG_CONFIG_HOME or LANGUAGE, nothing
that onedrive does will respect those environment variables.

If onedrive wants to access the D-Bus session bus, for example to send
notifications, it also won't be able to do that reliably (but it could
if it was a user service).

For the system service approach, you'll also need a target
/lib/systemd/system/onedrive.target. If you *don't* give the target
an [Install] section:

# /lib/systemd/system/onedrive.target
[Unit]
Description=OneDrive clients
Documentation=...
# end of file

but instead give onedrive@.service a Wants on it:

# /lib/systemd/system/onedrive@.service
[Unit]
...
After=network-online.target
Wants=network-online.target onedrive.target

then it will automatically 

Bug#974214: ITP: seadrive-gui -- Seafile drive client GUI part

[Moritz Schlarb]

Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: seadrive-gui
  Version : 2.0.7
  Upstream Author : Seafile Ltd. 
* URL : https://github.com/haiwen/seadrive-gui
* License : Apache-2.0
  Programming Lang: C++
  Description : Seafile drive client GUI part

Seafile is a file syncing and sharing software with file encryption
and group sharing, emphasis on reliability and high performance.

Seafile is an open source cloud storage system with privacy protection
and teamwork features. Collections of files are called libraries. Each
library can be synced separately. A library can also be encrypted with
a user chosen password. Seafile also allows users to create groups and
easily sharing files into groups.

The Seafile drive (or SeaDrive) client is a caching, on demand downloading
client implementation.

This is also the main difference to the classical seafile client (in the
"seafile" package), which syncs the whole content of Seafile libraries onto the
local filesystem allowing offline access, too.

This is the desktop integration which relies on seadrive-fuse for the actual
filesystem implementation.

Bug#974213: ITP: seadrive-fuse -- Seafile drive client FUSE daemon

[Moritz Schlarb]

Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: seadrive-fuse
  Version : 2.0.6
  Upstream Author : Seafile Ltd. 
* URL : https://github.com/haiwen/seadrive-fuse
* License : GPL-3.0
  Programming Lang: C
  Description : Seafile drive client FUSE daemon

Seafile is a file syncing and sharing software with file encryption
and group sharing, emphasis on reliability and high performance.

Seafile is an open source cloud storage system with privacy protection
and teamwork features. Collections of files are called libraries. Each
library can be synced separately. A library can also be encrypted with
a user chosen password. Seafile also allows users to create groups and
easily sharing files into groups.

The Seafile drive (or SeaDrive) client is a caching, on demand downloading
client implementation.

This is also the main difference to the classical seafile client (in the
"seafile" package), which syncs the whole content of Seafile libraries onto the
local filesystem allowing offline access, too.

This is the main dependency for the accompanying seadrive-gui package which
provides desktop integration.

Re: Split Packages files based on new section "buildlibs"

[Joerg Jaspert]

On 15949 March 1977, Thomas Goirand wrote:

I'm sorry but I don't understand everything here. If we aren't going 
to

have new components like main/contrib/non-free, how will it work? We
main contain a new Packages.{gz,xz} file containing these? I'm 
guessing

that it's not just a modification to that file, because you wrote the
goal is to diminish its size...



From my original mail:


--8<---cut here---start->8---
The current proposal is to reduce the main Packages.xz files size by
splitting[4] out all of the packages that are not intended for users,
writing those into an own file.
--8<---cut here---end--->8---

The *exact* implementation is currently fluid, a Packages-buildlibs.xz 
and a kind of subcomponent-style for main both seem options.


--
bye, Joerg

Bug#974216: ITP: dpdk-kmods -- Microsoft Azure Kusto (Azure Data Explorer) SDK for Python

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-devel@lists.debian.org 
pkg-dpdk-de...@lists.alioth.debian.org


* Package name: dpdk-kmods
  Version     : 0~2020+git
  Upstream Author : Intel plus various authors
* URL : https://git.dpdk.org/dpdk-kmods
* License : GPL-2 and BSD-3-clause
* Programming Lang: C
* Description : Data Plane Development Kit (igb uio dkms)

DPDK is a set of libraries for fast packet processing. Applications run
in user-space and communicate directly with dedicated network
interfaces.
This package contains the source code for the igb_uio kernel module.

This was originally part of src:dpdk, but from version 20.11 upstream
split it out to a separate repository, without a version. We are going
to maintain it in parallel with src:dpdk.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Split Packages files based on new section "buildlibs"

[Matthias Klose]

On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> On 15948 March 1977, Paul Wise wrote:
> 
>> Does this include the -dev packages for C/etc libraries?
> 
> No.
> 
>> I guess it also applies to Haskell and other statically-linked languages.
>> https://wiki.debian.org/StaticLinking
> 
> StaticLinking itself is not enough. This is about languages where the actual
> development in it is discouraged from doing with the debian packaged stuff.
> Where you do not go "I need lib XY, i install libxy-perl/libxy-dev/whatever 
> the
> name" and hack around using it. But "Oh, i want to hack on foo, i go get
> foo/cargo .../whateverthetool" and the debian package only ever comes in play 
> if
> you do build debian packages using it.

If you ask some upstreams of Python based software, their recommendation would
be to use pip, and probably conda (a cross OS distribution focusing on Python)
to do upstream development.  If you ask casual users, you probably will get
another answer.

Same thing probably for Java libraries. I don't know anybody who would do
development using the Debian packaged libraries.

> 
>>> The current proposal is to reduce the main Packages.xz files size by
>>> splitting[4] out all of the packages that are not intended for users,
>>> writing those into an own file. Those packages would have a section of
>>> "buildlibs", independent of their other properties.
>> Should (almost?) everything in the existing libdevel section move to
>> the new buildlibs section?
> 
> No, if so we would have split that section out.

Reducing the size of the index file is a technical issue inside Debian, and
relating that to

  """
  languages where the actual development in it is discouraged
  from doing with the debian packaged stuff
  """

seems to be wrong, as any upstream eco system providing their own environment
for development and distribution would need to move to this section.  I don't
think the reference to upstreams doesn't help with the definition of the new
section.

Matthias

Re: Split Packages files based on new section "buildlibs"

[Antonio Terceiro]

On Tue, Nov 10, 2020 at 06:52:14PM -0500, Calum McConnell wrote:
> On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote:
> > On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> > > I'm confused. We are packaging libraries of language X but then those
> > > packages
> > > will not be used by people who write software for language X on
> > > Debian?
> > > Intuitively, should I ever start with Rust, I would've thought that I
> > > had to
> > > install librust-clap-dev if I want to write code using "clap". What
> > > else would
> > > I install?
> > 
> > The Rust community's expectation seems to be that you would install
> > cargo,
> > and use that to download and build the clap package directly from
> > upstream,
> > without apt/dpkg being involved at all.
> 
> I don't know that that means we should abandon efforts to integrate the
> debian packages into usable code.
> 
> Rubygems has a similar expectation: however, there is a package (rubygems-
> integration) that makes it work anyways.  With Ruby, the only (user-
> obvious) difference between installing via gem and via deb is the package
> version.

FWIW, that is not accurate. There is nothing in Rubygems that prevents
it from just working. That is orthogonal to what random people who
happen to use Ruby think of Debian providing Ruby packages.

What happened was that Rubygems was created *after* we already had quite
some Ruby code in Debian that was installed differently than what
Rubygems expected, and rubygems-integration was created to bridge the
two ways of installing code. The Ruby team is slowly migrating the
old-style packages to the Rubygems layout, and at some point most, if
not all, of rubygems-integration will be obsolete.

> What about Rust makes that impossible?

In the Rust world there is no such thing as installing a library
globably. A crate that provides a library can only be used to build
other stuff, and is never made available globally. "cargo install" only
applies to creates that provide binaries:

https://doc.rust-lang.org/cargo/commands/cargo-install.html


signature.asc
Description: PGP signature

Re: Split Packages files based on new section "buildlibs"

[Geert Stappers]

On Wed, Nov 11, 2020 at 02:26:55PM +0100, Matthias Klose wrote:
> On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> > On 15948 March 1977, Paul Wise wrote:
> > 
> >> Does this include the -dev packages for C/etc libraries?
> > 
> > No.
> > 
> >> I guess it also applies to Haskell and other statically-linked languages.
> >> https://wiki.debian.org/StaticLinking
> > 
> > StaticLinking itself is not enough. This is about languages where the actual
> > development in it is discouraged from doing with the debian packaged stuff.
> > Where you do not go "I need lib XY, i install libxy-perl/libxy-dev/whatever 
> > the
> > name" and hack around using it. But "Oh, i want to hack on foo, i go get
> > foo/cargo .../whateverthetool" and the debian package only ever comes in 
> > play if
> > you do build debian packages using it.
> 
> If you ask some upstreams of Python based software, their recommendation would
> be to use pip, and probably conda (a cross OS distribution focusing on Python)
> to do upstream development.  If you ask casual users, you probably will get
> another answer.
> 
> Same thing probably for Java libraries. I don't know anybody who would do
> development using the Debian packaged libraries.
> 
> > 
> >>> The current proposal is to reduce the main Packages.xz files size by
> >>> splitting[4] out all of the packages that are not intended for users,
> >>> writing those into an own file. Those packages would have a section of
> >>> "buildlibs", independent of their other properties.
> >> Should (almost?) everything in the existing libdevel section move to
> >> the new buildlibs section?
> > 
> > No, if so we would have split that section out.
> 
> Reducing the size of the index file is a technical issue inside Debian, and
> relating that to
> 
>   """
>   languages where the actual development in it is discouraged
>   from doing with the debian packaged stuff
>   """
> 
> seems to be wrong, as any upstream eco system providing their own environment
> for development and distribution would need to move to this section.  I don't
> think the reference to upstreams doesn't help with the definition of the new
> section.


The thing we should aim for, the thing I'm aiming for,
is that software developed in any programming language
can be distributed by Debian.

User point of view:   `apt install foo`

Debian policy p.o.v.  `apt-get source foo`


 
> Matthias
> 

Regards
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#974346: ITP: umtp-responder -- Lightweight USB Media Transfer Protocol responder daemon

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-devel@lists.debian.org, arnaud.ferra...@gmail.com

* Package name: umtp-responder
  Version : 1.3.10
  Upstream Author : Jean-François Del Nero 
* URL : https://github.com/viveris/uMTP-Responder
* License : GPL
  Programming Lang: C
  Description : Lightweight USB Media Transfer Protocol (MTP) responder
daemon

uMTP-responder is a daemon implementing the MTP protocol, using either
FunctionFS or GadgetFS to configure the USB interface. It allows easy
file transfer between a Linux device and a workstation.

This package will be managed by the DebianOnMobile team.

Bug#974419: ITP: meta-mobian -- Mobian -- metapackages for using Debian on mobile devices

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-devel@lists.debian.org, arnaud.ferra...@gmail.com

* Package name: meta-mobian
  Version : 1
  Upstream Author : Arnaud Ferraris 
* URL : http://salsa.debian.org/Mobian-team/meta-mobian/
* License : GPL
  Programming Lang: None
  Description : Mobian -- metapackages for using Debian on mobile devices

Mobian is a Debian blend targetting mobile devices, such as phones and tablets.
This package provides several metapackages ensuring an optimal user experience
on these devices.

It will be maintained by the Mobian team.

Bug#974422: ITP: mobian-tweaks -- Generic configuration settings for Mobian

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-devel@lists.debian.org, arnaud.ferra...@gmail.com

* Package name: mobian-tweaks
  Version : 1
  Upstream Author : Arnaud Ferraris 
* URL : https://salsa.debian.org/Mobian-team/mobian-tweaks
* License : GPL
  Programming Lang: Bash
  Description : Generic configuration settings for Mobian

Mobian is a Debian blend targetting mobile devices, such as phones and tablets.

This package provides device-independent configuration files aimed at improving
the user experience on mobile devices, including:
  * initramfs hooks for resizing the rootfs partition on initial boot
  * custom PAM & logind config, and ModemManager polkit permissions
  * diverted desktop files for several applications
  * systemd services for out-of-the-box USB networking, MTP and SD card
automounting

It will be maintained by the Mobian team.

Bug#974429: ITP: mobian-plymouth-theme -- Mobian theme for plymouth

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-devel@lists.debian.org, arnaud.ferra...@gmail.com

* Package name: mobian-plymouth-theme
  Version : 1
  Upstream Author : Arnaud Ferraris 
* URL : https://salsa.debian.org/Mobian-team/mobian-plymouth-theme
* License : GPL+LGPL
  Programming Lang: Plymouth
  Description : Mobian theme for plymouth

Mobian is a Debian blend targetting mobile devices, such as phones and tablets.
This package provides the default plymouth theme for Mobian, and will be
maintained by the Mobian team.

BinUtils /usr/bin/ld: cannot find -lGL

[Timothy M Butterworth]

All,

I'm trying to built software with Qt Creator and I get the following
error message /usr/bin/ld: cannot find -lGL. I'm running Debian 10
with KDE fully patched to the latest point release.

Timothy M Butterworth

Re: BinUtils /usr/bin/ld: cannot find -lGL

[Timothy M Butterworth]

All,

I added a symbolic link "libGL.so ->
/usr/lib/x86_64-linux-gnu/libGL.so.1" and that fixed the issue.

Timothy M Butterworth

Re: BinUtils /usr/bin/ld: cannot find -lGL

[Colin Watson]

On Wed, Nov 11, 2020 at 12:59:49PM -0500, Timothy M Butterworth wrote:
> I added a symbolic link "libGL.so ->
> /usr/lib/x86_64-linux-gnu/libGL.so.1" and that fixed the issue.

You should install the libgl-dev package instead of doing this manually.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Split Packages files based on new section "buildlibs"

[Simon McVittie]

On Wed, 11 Nov 2020 at 14:26:55 +0100, Matthias Klose wrote:
> If you ask some upstreams of Python based software, their recommendation would
> be to use pip, and probably conda (a cross OS distribution focusing on Python)
> to do upstream development.  If you ask casual users, you probably will get
> another answer.
> 
> Same thing probably for Java libraries. I don't know anybody who would do
> development using the Debian packaged libraries.

I think perhaps the key thing here is that Python does *have* a reasonably
well-defined system-wide search path for packages outside the Python
core (/usr/lib/python3/dist-packages). Even if some projects prefer to
use pip instead of dist-packages, they can't claim that dist-packages
doesn't exist.

Also analogous: just because some people use LD_LIBRARY_PATH-based
mechanisms like jhbuild or the Steam Runtime for their C/C++ libraries,
that doesn't invalidate the fact that the C compiler and runtime linker
are designed to have default search paths that contain more than just
libgcc and glibc, and can have (for example) a system copy of a
third-party library like zlib or GTK.

My understanding is that Rust and Go code literally doesn't have
analogous built-in system-wide search paths for third-party libraries,
and when building Debian packages that contain Rust and Go code, we have
to invent them in a Debian-specific way.

smcv

Re: BinUtils /usr/bin/ld: cannot find -lGL

[Imre, Nagy]

Hi Timothy,

This link might be useful for you: 
https://stackoverflow.com/questions/18406369/qt-cant-find-lgl-error


Please keep in mind, that this is more a Qt related question, thus you 
would get correct answers faster on specific Qt forums and mailing lists.
Also, please try to use google first, since the the chance that your 
question would be answered would be higher if you show that you put the 
necesseary effort to find the answer.


Best regards,
Imre

On 2020.11.11. 18:31, Timothy M Butterworth wrote:

All,

I'm trying to built software with Qt Creator and I get the following
error message /usr/bin/ld: cannot find -lGL. I'm running Debian 10
with KDE fully patched to the latest point release.

Timothy M Butterworth

Re: [Artwork] Survey for the default artwork for Bullseye (Debian 11)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2020-10-26 at 16:18 +0200, Jonathan Carter (highvoltage) wrote:
> To vote for your favourite theme, visit the following website and click
> on the "Bullseye Artwork Survey" button. From there, you can rank your
> choices from the available options to the My Choices section from most
> preferred to least preferred.
> 
> https://surveys.debian.net/
> 
> The survey is now open and closes on 2020-11-10 23:59 UTC.

Hi Jonathan,

I somehow missed the call (and even the deadline). The survey doesn't seem
available anymore (because we're after the closing date, I assume), do we have
a winner yet?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+sNpUACgkQ3rYcyPpX
RFsQ/ggAtDFOw/p4rBtsRhPaonbLgyWbFH1mYM+9OJqnGUxEIV/+48nvNl28CGX4
+mOI/0sv6ofc36O3K1E/8ufsB8wddfDgLBMAMVcYjeqPCypYvXHlyyfSyvfpuJ3d
0v/T2KIjNeZTfYLFS3S8zDxNunF/KwzlFlMEwByVlZ++pOMUtjTsg/v4JqkeZP9l
ST/SKrxDnhIiL6N2mcCq/ANCqtqvPNBKG+zJ1AHKvw6hzvCZEegrJr+h5gcSJrIV
BkT8q1eahnNoYnJmONSq34M42UPERHAIlYTX88LLZzUYgN39PbkofJRsK+t/+9PP
9r4Ay66SfB7TWvwJbRG5TfiMAIvCPQ==
=9njd
-END PGP SIGNATURE-

Re: Split Packages files based on new section "buildlibs"

[Russ Allbery]

Simon McVittie  writes:

> I think perhaps the key thing here is that Python does *have* a
> reasonably well-defined system-wide search path for packages outside the
> Python core (/usr/lib/python3/dist-packages). Even if some projects
> prefer to use pip instead of dist-packages, they can't claim that
> dist-packages doesn't exist.

Even more specifically, I think the critical difference is that software
written in Python (or JavaScript, or Java) consumes the packaged libraries
at runtime.  If you have a Python application packaged for Debian, it uses
the Python libraries packaged for Debian when you run it.

This is *not* true for Go or Rust because the binaries are statically
linked.  At runtime, no Go or Rust libraries are used by the binary
because they've already been linked into the binary.  (My understanding is
that both support dynamic libraries to some extent but that they're
discouraged in both and not generally used.)

I think this is the critical difference and I'm not sure it's been
explicitly spelled out (although there have been a lot of messages in this
thread, so maybe I missed it).

Because of that, the packaged Rust and Go libraries are *only* useful for
building Rust and Go binaries, not for running them, and that's why it
matters that the Go and Rust build tools that Debian users would use don't
know how to, and don't want to, use installed versions of those libraries.
And thus this point:

> My understanding is that Rust and Go code literally doesn't have
> analogous built-in system-wide search paths for third-party libraries,
> and when building Debian packages that contain Rust and Go code, we have
> to invent them in a Debian-specific way.

Rust and Go both vendor dependencies during their build.  Python isn't
really analogous; you *can* do something similar with virtualenvs, but (a)
Python doesn't really have a build the way that Rust and Go do because one
generally doesn't produce native code, and (b) the virtualenv approach is
optional and only one of many ways of assembling Python applications,
whereas there's largely only one way Rust and Go binaries are built.

-- 
Russ Allbery (r...@debian.org)  

Bug#974427: ITP: chance -- It is a Utility library to generate anything random like strings, numbers, etc.

[jobinjofficial]

Package: wnpp
Severity: wishlist
Owner: Jobin J 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : chance
Version : 1.1.7
Upstream Author : Victor Quinn 
* URL : https://github.com/chancejs/chancejs
* License : Expat
Programming Lang: JavaScript
Description : It is a Utility library to generate anything random like strings, 
numbers, etc.

Chance is a minimalist generator of random strings, numbers, etc.
to help reduce some monotony particularly while writing automated
tests or anywhere else you need anything random.

Hi Debian Maintainers,
chance is a utility library to generate random strings, numbers etc.
It is a dependency of HedgeDoc (early name was CodiMD).The source link
of the project is https://github.com/codimd

The upstream of this chance is developed by Victor Quinn and licensed
under Expat license.The upstream is available at
https://github.com/chancejs/chancejs

This debian package will be maintained by Debian JavaScript Team.
I think this chance will be helpful for Debian Javascript team .

Thanks,

JOBIN J

Bug#974541: ITP: deepin-gtk-theme -- Deepin Gtk Themes

[hufeng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-devel@lists.debian.org


* Package name : deepin-gtk-theme
  Version  : 17.10.11
  Upstream Author  : iceleaf916 
* URL  : https://github.com/linuxdeepin/deepin-gtk-theme
  License  : LGPL-3+
  Programming Lang : CSS
  Description  : Deepin Gtk Themes


This package contains GTK2 and GTK3 application theme for
the Deepin desktop environment,such as dark and light color configurations.
.
It is part of Deepin software and DDE (Deepin Desktop Environment).
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#974547: ITP: golang-github-adam-hanna-arrayoperations -- Small library for performing union, intersect, difference and distinct operations on slices in golang

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-adam-hanna-arrayoperations
  Version : 0.2.6-1
  Upstream Author : Adam Hanna
* URL : https://github.com/adam-hanna/arrayOperations
* License : Expat
  Programming Lang: Go
  Description : Small library for performing union, intersect, difference 
and distinct operations on slices in goLang

 A small library for performing union, intersect, difference and distinct
 operations on slices in goLang

This is a dependency for the latest version of termshark