Bug#1000369: ITP: ocaml-stringext -- extra string functions for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-stringext
  Version : 1.6.0
  Upstream Author : Rudi Grinberg
* URL : https://github.com/rgrinberg/stringext
* License : MIT
  Programming Lang: OCaml
  Description : extra string functions for OCaml

 Extra string functions for OCaml. Mainly splitting. All functions are
 in the Stringext module.

This is a new transitive dependency of ocsigenserver.

Bug#1000371: ITP: ocaml-bigstringaf -- bigstring intrinsics and fast blits for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-bigstringaf
  Version : 0.8.0
  Upstream Author : Inhabited Type LLC
* URL : https://github.com/inhabitedtype/bigstringaf
* License : BSC-C3
  Programming Lang: OCaml, C
  Description : bigstring intrinsics and fast blits for OCaml

 The OCaml compiler has a bunch of intrinsics for Bigstrings, but
 they're not widely-known, sometimes misused, and so programs that use
 Bigstrings are slower than they have to be. And even if a library got
 that part right and exposed the intrinsics properly, the compiler
 doesn't have any fast blits between Bigstrings and other string-like
 types.

This is a new (transitive) dependency of ocsigenserver.

Bug#1000372: ITP: ocaml-magic-mime -- OCaml library to map filenames to common MIME types

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-magic-mime
  Version : 1.2.0
  Upstream Author : Anil Madhavapeddy
* URL : https://github.com/mirage/ocaml-magic-mime
* License : ISC
  Programming Lang: OCaml
  Description : OCaml library to map filenames to common MIME types

 This library contains a database of MIME types that maps filename
 extensions into MIME types suitable for use in many Internet
 protocols such as HTTP or e-mail. It is generated from the mime.types
 file found in Unix systems, but has no dependency on a filesystem
 since it includes the contents of the database as an ML
 datastructure.

This is a new transitive dependency of ocsigenserver.

Bug#1000375: ITP: deepin-terminal-gtk -- Default terminal emulation application for Deepin the old gtk version

[clay stan]

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

* Package name: deepin-terminal-gtk
  Version : 5.0.4.5
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/deepin-terminal-gtk
* License : GPL-3+
  Programming Lang: Vala
  Description : Default terminal emulation application for Deepin,
the old gtk version

deepin-terminal is now developed based on qt, while the previous
version of deepin-terminal is based on vala. These two packages can be
considered as different software, but the upstream did not rename the
qt version of deepin-terminal, but instead renamed the previous
version of vala The version has been renamed, so the deepin-terminal
of the debian repository has been upgraded to the qt version, and the
vala version has been overwritten, so I reapplied for an ITP to
maintain the deepin-terminal based on vala version.

deepin-terminal is an advanced terminal emulator with window-splitting,
workspaces, remote management, Quake mode and other features.

Re: merged-/usr transition: debconf or not?

[Simon McVittie]

On Sat, 20 Nov 2021 at 14:54:30 -0800, Russ Allbery wrote:
> That would make it akin to dpkg
> --add-architecture, which feels like a good model (although as you mention
> I don't think we want --remove-architecture).

Instead of dpkg --add-architecture, which is a top-level "verb" like
dpkg --remove or dpkg --install [1], probably a better thing to resemble
would be the options that already exist to change dpkg's behaviour,
and in particular --path-exclude and --path-include?

Options to make path A an alias for path B would be a lot like --path-exclude
in that they really only make sense in a configuration file in
/etc/dpkg/dpkg.cfg.d, although for symmetry they would presumably also
have to exist as command-line options just like --path-exclude does.

Here's a possible design (not fully thought out, and maybe wrong or
unimplementable):

--path-alias ALIAS=TARGET
When unpacking or querying packages, paths below ALIAS will be
transformed into the corresponding path below CANONICALIZED, where
CANONICALIZED is the result of resolving TARGET relative to the
directory containing ALIAS. This transformation is done before
checking for file conflicts.

ALIAS must be an absolute path.

If the file list of any unpacked package contains a directory at
ALIAS and/or CANONICALIZED, then ALIAS will be created as a symbolic
link to TARGET, with its target directory created at CANONICALIZED.

It is an error to have multiple --path-alias directives for
the same ALIAS with different TARGET paths.

This option should usually be set via /etc/dpkg/dpkg.cfg.d rather
than as a command-line option.

For example, a series of directives like path-alias=/bin=usr/bin
can be used to implement the "/usr merge", causing /bin/bash to be
unpacked as /usr/bin/bash while creating a symbolic link
/bin -> usr/bin.

With that, I believe a full implementation of merged-usr for all known
architectures would be to install something like this, perhaps via
base-files:

# in /etc/dpkg/dpkg.cfg.d/merged-usr
path-alias=/bin=usr/bin
path-alias=/lib32=usr/lib32
path-alias=/lib64=usr/lib64
path-alias=/lib=usr/lib
path-alias=/libo32=usr/libo32
path-alias=/libx32=usr/libx32
path-alias=/sbin=usr/sbin

Rationale for TARGET being allowed to be relative: I believe the compat
symlinks in merged-/usr are preferred in the form /bin -> usr/bin, to
make sysroots (containers, chroots, btrfs root filesystem snapshots,
etc.) easier to manipulate from outside.

Rationale for ALIAS only being created if ALIAS and/or CANONICALIZED
really exist in a package: we would probably prefer the multilib
directories to be created "lazily", rather than having a /libo32 on
systems that will never install a mips* package and a /libx32 on systems
that will never install an x32 package. This is slightly nicer than the
current implementation in convert-usrmerge and debootstrap, which creates
those directories "eagerly" whenever the appropriate architectures are
configured as either primary or foreign architectures.

smcv

[1] if dpkg had been designed with more recent CLI conventions in mind,
I expect these "verbs" might have been subcommands like "dpkg remove",
etc. as seen in apt/git/flatpak, which makes it a bit more obvious
that only one is allowed

Bug#1000391: ITP: ocaml-eqaf -- constant-time equal function on string for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-eqaf
  Version : 0.8
  Upstream Author : Romain Calascibetta
* URL : https://github.com/mirage/eqaf
* License : MIT
  Programming Lang: OCaml
  Description : constant-time equal function on string for OCaml

 This package provides an equal function on string in constant-time to
 avoid timing-attack with crypto stuff.

This is a new dependency of ocsigenserver.

Bug#1000392: ITP: ocaml-hmap -- heterogeneous value maps for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-hmap
  Version : 0.8.1
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/hmap
* License : ISC
  Programming Lang: OCaml
  Description : heterogeneous value maps for OCaml

 Hmap provides heterogeneous value maps for OCaml. These maps bind
 keys to values with arbitrary types. Keys witness the type of the
 value they are bound to which allows one to add and lookup bindings
 in a type safe manner.

This is a new dependency of ocsigenserver.

Bug#1000393: ITP: ocaml-gmap -- heterogenous maps over a GADT for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-gmap
  Version : 0.3.0
  Upstream Author : Hannes Mehnert
* URL : https://github.com/hannesm/gmap
* License : ISC
  Programming Lang: OCaml
  Description : heterogenous maps over a GADT for OCaml

 Gmap exposes the functor Make which takes a key type (a GADT 'a key)
 and outputs a type-safe Map where each 'a key is associated with a 'a
 value. This removes the need for additional packing. It uses OCaml's
 stdlib Map data structure.

This is a new dependency of ocsigenserver.

Bug#1000394: ITP: ocaml-mtime -- monotonic wall-clock time for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-mtime
  Version : 1.3.0
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/mtime
* License : ISC
  Programming Lang: OCaml
  Description : monotonic wall-clock time for OCaml

 Mtime has platform independent support for monotonic wall-clock time
 in pure OCaml. This time increases monotonically and is not subject
 to operating system calendar time adjustments. The library has types
 to represent nanosecond precision timestamps and time spans.

This is a new dependency of ocsigenserver.

Bug#1000395: ITP: ocaml-ptime -- POSIX time for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-ptime
  Version : 0.8.5
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/ptime
* License : ISC
  Programming Lang: OCaml
  Description : POSIX time for OCaml

 Ptime has platform independent POSIX time support in pure OCaml. It
 provides a type to represent a well-defined range of POSIX timestamps
 with picosecond precision, conversion with date-time values,
 conversion with RFC 3339 timestamps and pretty printing to a
 human-readable, locale-independent representation.

This is a new dependency of ocsigenserver.

Bug#1000397: ITP: prometheus-frr-exporter -- Prometheus export for the FRR daemon

[Daniel Swarbrick]

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

* Package name: prometheus-frr-exporter
  Version : 0.2.20
  Upstream Author : Tynan Young 
* URL : https://github.com/tynany/frr_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for the FRR daemon

Prometheus exporter for FRR version 3.0+ that collects metrics by using
vtysh and exposes them via HTTP, ready for collecting by Prometheus.

My employer currently uses this exporter and since I have already
packaged it inhouse, I wanted to also share it with the Debian
community. I feel that the package would be useful to service providers
and network operators who wish to monitor the health of e.g. BGP peering
with Prometheus.

I will maintain this package with the help of Debian Go packaging /
Prometheus team(s).

Re: merged-/usr transition: debconf or not?

[Johannes Schauer Marin Rodrigues]

Quoting Russ Allbery (2021-11-20 18:22:27)
> * Create a new essential package that contains these symlinks and that
>   needs to be unpacked before any binaries are executed in the target file
>   system.  This has many of the advantages and drawbacks of the approach
>   of putting the symlinks in base-files, but may make it easier to handle
>   the upgrade problem.  Ideally an upgrade would then involve installing
>   usrmerge, letting it run, and then installing this new essential package
>   so that it takes over ownership of those symlinks.
> 
>   This still feels kind of complex and messy to me, but maybe less so.
> 
> * Create the symlinks directly in the bootstrapping script.  In other
>   words, after unpacking base-files, the bootstrapping script would
>   directly create the required symlinks in the target file system, before
>   unpacking any other package.
> 
>   This has the obvious drawback of moving things outside the packaging
>   system and creating a new special case that every bootstrapping script
>   needs to be aware of (and I know we have at least four or five that
>   would need modifications).  It has the advantage that the usrmerge
>   symlinks are now not in the dpkg database and thus not subject to
>   rewriting, and therefore won't need to be special-cased.  However, that
>   comes with the obvious disadvantage that they're not in the dpkg
>   database, so for instance dpkg -S /lib wouldn't find that symlink unless
>   it was added as some sort of dpkg-query special case (which doesn't seem
>   like a great idea).
> 
>   The advantage of this approach is that it closely mimicks what's already
>   happening now with the usrmerge package, and for which we therefore have
>   a lot of existing experience.

Please don't. Since 2014 it is possible to create a Debian chroot without
taking care of the unpack order and without running any special setup
beforehand that cannot be put into apt or dpkg itself (like creating
/var/lib/dpkg/info which is not needed anymore since dpkg 1.20.0). One of my
biggest motivations in writing mmdebstrap was to get rid of all the quirks that
currently live in debootstrap, move them into apt and dpkg so that we end up
with a declarative bootstrap process that is driven by the package contents,
their metadata and maintainer scripts but does not need magic from the outside
other than standardized interfaces. Requiring the merged-/usr setup to be done
by the bootstrap script would be a step backwards. Think about the following
points:

 * you create a Debian unstable chroot using snapshot.d.o -- now you have to
   somewhere put code that identifies that this is a chroot from the past and
   that has to decide whether that chroot should be merged-/usr or not. If
   merged-/usr setup was living somewhere in the Essential:yes package set
   the chroots would be created the right way automatically
 * same for derivatives -- now every bootstrap script has to learn which
   derivative defaults to merged-/usr, which ones do not and when they switched
 * we somehow need to convert installations of users that only run testing
   or unstable but never do full stable installation to merged-/usr -- one way
   to do that is to let one package in the Essential:yes set drive the
   conversion at which point the bootstrap script doesn't need to know about
   merged-/usr because the Essential:yes set knows how to set it up
 * think about it from a software engineering point of view: Debian as a
   component based software distribution should move specific functionality
   into its packages and global functionality into declarative metadata.

Just as we are currently trying to reduce maintainer scripts and replace them
by declarative approaches, we should also try to reduce the magic in our
bootstrap scripts and move it either to our package managers or replace them by
declarative solutions. We have been moving into the right direction during the
last few years as apt and dpkg have picked up functionality I had earlier put
into mmdebstrap (thanks a lot to guillem, DonKult and juliank for picking up my
patches or writing the functionality themselves). It would mean a step
backwards if all bootstrap scripts would have to carry the setup_merged_usr()
function from debootstrap and then decide by some $magic when this function
should be executed or not.

Thanks!

cheers, josch

signature.asc
Description: signature

Looking for DDs to sign my keys in Norway, Bergen area

[Marius Gripsgard]

Hi,


I am looking for someone to sign my keys, but due to covid this has not 
been easy to do, so im looking for someone in my local area that would 
be up to do a key signing. I have already looked at the offering page, 
but none is close to me. (closed is oslo, this might be an option, but 
its a 8H drive/train). If you are close to bergen, norway and are 
willing to sign my key, please hit me up.



Thank you,

Marius Gripsgard

Re: merged-/usr transition: debconf or not?

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> Please don't. Since 2014 it is possible to create a Debian chroot
> without taking care of the unpack order and without running any special
> setup beforehand that cannot be put into apt or dpkg itself (like
> creating /var/lib/dpkg/info which is not needed anymore since dpkg
> 1.20.0). One of my biggest motivations in writing mmdebstrap was to get
> rid of all the quirks that currently live in debootstrap, move them into
> apt and dpkg so that we end up with a declarative bootstrap process that
> is driven by the package contents, their metadata and maintainer scripts
> but does not need magic from the outside other than standardized
> interfaces. Requiring the merged-/usr setup to be done by the bootstrap
> script would be a step backwards.

I understand why you want this, but unfortunately it doesn't answer the
question of how to safely perform the upgrade and reconfigure dpkg.  Do
you have any thoughts on the drawbacks of the approach of putting the
symlinks in base-files that led me to lean away from doing that?

I'd love to get all of the machinery into packages as well, but I think
safely upgrading existing systems is even more important than that, and
I'm worried about our ability to do so if we put the machinery in
base-files.

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

Bug#1000409: ITP: dyssol -- tool for dynamic flowsheet simulation

[Anton Gladky]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: dyssol
  Version : 1.0
  Upstream Author : Dyssol Development Team
* URL : https://github.com/FlowsheetSimulation/Dyssol-open
* License : MIT
  Programming Lang: C++
  Description : tool for dynamic flowsheet simulation


Dyssol, the dynamic simulation of solids processes, is a novel dynamic
flowsheet modelling system designed to simulate the time-dependent behaviour
of complex production processes in solids processing technology. Key features 
including:

1. Dynamic simulation of flowsheets to reflect the time-dependent behaviour of 
processes
   and to take into account the accumulation of mass and energy;
2. Proper calculation of multidimensional distributed parameters of the solid 
phase,
   considering their possible interdependence;
3. Flexibility and extensibility of the system for adding new models of 
apparatuses and solvers.

And distinctive features including:
  * Dynamic simulation of complex process structures;
  * Advanced calculation algorithm for dynamic simulations;
  * Consideration of solid, liquid, gas phases and their mixtures;
  * Proper handling of multidimensional interdependent distributed parameters 
of solids;
  * Providing standardized interfaces and templates for implementation of new 
units;
  * High modularity and extensibility.

The package will be maintained under the roof of Debian Science Team.


Anton
  

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmGb41ARHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbdxA//aq+1NKUl9sJHwOuSTKTNJhvnckSaQNMa
sGMW4z0oMJFzn15TWN960SeNdBufQzydJHhQ9Ee6wvjOIZGxD0iSFFwkXKYEucwk
+fgx4sZQP85P+nnp3YbnPHpsnHGnNgffVOpkCc2ugJwU3KqVpF+v4S4rjc894orl
I2R7jZycy9ynay3V+400Cb77IJAz2FFvkYXhXvUryZ4BeSdhuSPQ/lWQdBUqaJ+I
h4PVAnCUQTS140wUsbsfiVWELXSId0Z6BRQO+39tPAWg/mj67lRIYyO/FgzbOFaS
H1f5sm1nOKNw3/VF3mDpYjf5n6ha4ARI+6bHvCC8DeST/8bSjRlG/vFfIDmvtAeW
uzJ5Ov8xLiwEYJQ1PwYLMGg0yITJC+YXBJYvTzi4uvpoNQuhKtTtjFoE7TtelC3Q
HBpW99r1vc3pVD5z9w22ETsdFrbhqzITz0u0DoZjgq8ooY1vTEXgZxCfNdqJzsWw
2Rrr9MnCiulngQQYFza/TCudJdEx4TBjB2BUyQnBL9FYwlxXYPKzR16ouwdaiRMe
n6fY4MAREcO8vRmnv3nNLydIa14nt7tP0/CPQWDwQoalAapi1gU8yvP3RBZWXAeA
uyrIVrlS6/Q0p3dVcSJ0DEDDHkQZN3DDQVzW/nHmynI5VXxtwLLRvGbhr9fYODfO
PSRlod/B114=
=Sxnh
-END PGP SIGNATURE-

Re: merged-/usr transition: debconf or not?

[Ansgar]

On Mon, 2021-11-22 at 12:24 +, Simon McVittie wrote:
> Options to make path A an alias for path B would be a lot like --path-
> exclude in that they really only make sense in a configuration file in
> /etc/dpkg/dpkg.cfg.d, although for symmetry they would presumably also
> have to exist as command-line options just like --path-exclude does.

I would expect using --path-exclude when installing individual packages
to work: you just don't get the files from that package. (I haven't
tried.)

Merged-/usr (or --path-alias as you propose) does not work like this:
Unlike --path-exclude, you would almost always need to specify a
superset of --path-alias options for all future operations.

So I do not think there should be a command-line option for this;
unless it would behave like `--add-architecture` and register the
setting somewhere.

>     # in /etc/dpkg/dpkg.cfg.d/merged-usr
>     path-alias=/bin=usr/bin
>     path-alias=/lib32=usr/lib32
>     path-alias=/lib64=usr/lib64
>     path-alias=/lib=usr/lib
>     path-alias=/libo32=usr/libo32
>     path-alias=/libx32=usr/libx32
>     path-alias=/sbin=usr/sbin

I do not think this should be a configuration file (unless you suggest
supporting other values or removing individual lines; after all a
configuration file exists to be changed).

(Though we have various other settings that don't make sense as
configuration files in /etc, such as Debian's bugtracker and other
settings in /etc/dpkg/origins/debian, the version in
/etc/debian_version and so on.)

Ansgar

Re: merged-/usr transition: debconf or not?

[Russ Allbery]

Ansgar  writes:

> So I do not think there should be a command-line option for this; unless
> it would behave like `--add-architecture` and register the setting
> somewhere.

Agreed.

I also think it needs to be a two-phase thing, because dpkg has to convert
its internal database to respect the new aliases.  So there should be a
desired configuration and then an applied configuration, and the latter is
only updated once the database conversion is complete, with dpkg refusing
to perform package operations if the desired configuration doesn't match
the applied configuration.

Even if the command that changes the configuration also does the database
conversion, I think we need this, since I don't believe it's possible to
do the database conversion atomically (or at least it would involve extra
complexity that I don't think we want), so we have to handle the database
conversion being interrupted.

> I do not think this should be a configuration file (unless you suggest
> supporting other values or removing individual lines; after all a
> configuration file exists to be changed).

Are you thinking of perhaps shipping this configuratino somewhere in
/usr/lib instead so that it's not marked as a configuration file?

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

Bug#1000415: ITP: golang-github-tklauser-go-sysconf -- sysconf for Go, without using cgo

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-tklauser-go-sysconf
  Version : 0.3.9-1
  Upstream Author : Tobias Klauser
* URL : https://github.com/tklauser/go-sysconf
* License : BSD-3-clause
  Programming Lang: Go
  Description : sysconf for Go, without using cgo

This package is needed for golang-github-shirou-gopsutil v3.
Cheers,

Bug#1000416: ITP: golang-github-tklauser-numcpus -- Go module to get the number of CPUs on a Linux/BSD system

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-tklauser-numcpus
  Version : 0.3.0-1
  Upstream Author : Tobias Klauser
* URL : https://github.com/tklauser/numcpus
* License : Apache-2.0
  Programming Lang: Go
  Description : Go module to get the number of CPUs on a Linux/BSD system

This package is needed for golang-github-shirou-gopsutil v3.
Cheers,

Re: merged-/usr transition: debconf or not?

[Sam Hartman]

> "Zack" == Zack Weinberg  writes:
Zack> Maybe it was not obvious to anyone in 2016 that the package
Zack> database being inconsistent with the filesystem could cause
Zack> actual data loss.  However, I think it was the responsibility
Zack> of the developers of usrmerge to find out how bad that problem
Zack> actually was, rather than dismissing it.  And, as it has
Zack> proven to be a genuinely critical problem, it is also their
Zack> responsibility to fix it, per the 'no one can be forced to do
Zack> anything' rule.

I agree with the above, but very definitely not with the further
conclusions you draw.

I think that the usrmerge proponents need to fix the problem before
encouraging moving  files from / to /usr in packages.
They can do that either by:

* proposing fixes to dpkg

or

* As Michael has pointed out, proposing mechanisms to guarantee that no
  Debian release both includes file migrations and package migrations.

We disagree about the rollback.
If we're ever communicating in a more realtime context I'd love to chat
about the balances around making sure we do not reward bad behavior.