:: [devuan-dev] Meeting notes 2022-12-…
Top Page
Delete this message
Reply to this message
Author: B Stack
To: devuan developers internal list
Subject: [devuan-dev] Meeting notes 2022-12-29
# Devuan meet 2022-12-29 @20:30 UTC

Present: Altoid, golinux, plasma41, John Faulk

## Old Business

### Altoid golinux: Research zeitgeist ... Thanks Altoid! Please have a
  read here previous to the meet: https://launchpad.net/zeitgeist/
  There's a lot more but this should suffice to get the gist of things.
  * (gl) Is there one individual present is all these discussions that
    is stirring the pot? I don't know that I will have the time/patience
    to read before tomorrow. They are all from 10 or so years ago!
    Selected bits (bold is mine):
* ... a service which logs the users's activities ...
* ... establish relationships between items based on similarity and
  usage patterns by applying **data association algorithms** ...
* ... currently logs file usage, web activity, plus chat and email
  conversations. **More to come**.
* ... allows any application to store this information and **makes it
  readily available** over a DBus API.
* ... using machine-learning algorithms ...
* ... establish relationships between items based on **similarity and
  usage patterns.**
* ... supports extensions to **enhance its engine’s core feature set**.
* ... can be used to include information **about activity and experience
  beyond the desktop**, such as geo-logging and geo-tagging.
*-- Proposal to consider and discuss in the next meet: In my opinion,
  there is a very disturbing/alarming similarity/parallel between what
  systemd and zeitgeist do. The first started out as relatively small
  albeit obscure idea to *replace all inits* from MS' new-ish star
  employee and ended up being the developer sanctioned monolithic virus
  it is now. Let's not forget that **Devuan Linux was born** of the
  urgent need to escape that scenario. As I understand it, zeitgeist is
  aiming to end up being the tool that, if not nipped in the bud, will
  end up taking control of *all* the data available at any one (or
  *all*) the time inside the box it is installed in, storing and
  eventually "making it available" to [abcdefgh] ... (fill in, there are
  literally millons of options) Just like systemd ended up wrapping its
  tentacles around so many parts/processes in the Linux
  systems/distributions that happily allow it. Harvesting, storing and
  analysing all the data in the system where it is installed, data which
  is ordinarily available **only** to root, to a privileged user or to
  the logged in user. Beware the day when systemd and zeigeist end up
  being co-dependent or merge their respective codes because it may take
  time but it **will** eventually happen. zeigeist is Orwellian
  nightmare software and the writing *is* on the wall.
* (plasma41) As I stated last week, if removing zeitgeist from Debian's
  repository is important to you, then file a bug report in Debian
  bugtracker. Until you've done that, posting about it here IMO just
  feels spammy.

### John Faulk In tandem with Altoid's concerns, I intend to propose
  bringing this problem up with Dr. Richard Stallman himself. GNOME is
  part of the GNU project, and GTK4 -Which is part of GNOME- depends on
  Zeitgeist. If anyone has the authority to stop GNOME from moving
  forward with this threatening software, it is Dr. Stallman. And anyone
  who has read his blog on Stallman.org knows he is a very paranoid man
  indeed, so we may actually have a fighting chance here.
* (plasma41) AFAIU, GNOME hasn't been a GNU project in quite some time.
  I think it is best to have direct dialog with other projects rather
  than try to involve another party to act as a mouthpiece. I now have a
  list of packages that directly depend upon zeitgeist-core, using
  apt-rdepends -r zeitgeist-core:
* zeitgeist
* zeitgiest-datahub
* **diodon**
* clipit
* **lxqt**
* **task-lxqt-desktop**
* **live-task-lxqt**
* python3-zeitgiest
* gnome-activity-journal (formerly gnome zeitgeist) Ladies and
  Gentlemen, this issue just got a ***whole lot worse***
* (altoid) **lxqt** ? Look at that ...
  * (plasma41) I see no mention of a zeitgeist dependency on lxqt on
    <https://packages.debian.org/unstable/lxqt>. Am I missing something?
    * (plasma41) Ok, the dependency chain is "lxqt -> clipit -> diodon
      -> zeitgeist-core". So it's only one tool that pulls it in. Easy
      enough to request an alternate tool in the lxqt metapackage, just
      file a wishlist bug in the Debian BTS.
    *- (gl) Did you also check "recommends" and "suggests"
* (altoid) Just a thought ... I fully support the idea of bringing this
  issue up with RS, but without showing our hand (ie: Devuan's)  *yet*,
  for two reasons: The first one is this: does what *we* are discussing
  here actually represent Devuan's *official* stance on zeitgeist? And
  the second one is this: like gl pointed out, Devuan is *heavily
  dependent* on Debian and we really don't know what *their* official
  stance on zeitgeist is. Or if they *have* one. Maybe (like us) they
  were not aware of zeigeist up to *now*, as I'm sure they read Dev1 and
  have seen all the relevant posts. I think that gl's proposal of
  silently filing a bug against whatever package is setting a dependency
  on zeigeist is a very wise one. ie: putting on a *don't know much
  about this* face while asking Debian, via a bug report, *what gives*
  wrt the zeitgeist dependency on a package. If they ignore/stonewall
  the report, we'll know what we are up against. And if they claim
  ignorance, we'll just take it with a good amount of salt. Later ...
  *(gl) - Yeah, let's not get ahread of ourselves and imagine a problem
    where there may not be one and please keep Devuan out of your
    queries . . .
* (altoid) I expect the best of outcomes *but* plan for the worst.

## Old Actions

## New Business

### LeePen

#### ci.devuan.org Added preliminary support for individual binary
builds to fail. This is required because pdns-recursor now uses the
architecture-is-64-bit build dependency to target the correct build
archs. Failed builds are marked 'UNSTABLE' (yellow), but if at least
one succeeds, then the build is deployed to dak.

#### Packaging

##### xorg using libseat The first xorg-xserver-core packages are
available in suites/experimental for testing. They work for us, but we
would be grateful for wider testing.

##### Other updates
* ceres: openvpn (×2), pdns-recursor, devuan-lintian-profile (with fix
for inclusion of parent profile spelling checks).

#### Amprolla
* Support for [out of date source notifications to
deployed and reporting on

## New Actions