Gentoo Packages

Search

Install

Install this package:

emerge -a games-util/tennoscope

Package Information

Description:

Local-first Warframe companion for Linux, written in Rust + Tauri with a React/TypeScript frontend. It reads a running Warframe process read-only to obtain a session token, asks Warframe's own inventory endpoint for the player's collection, and stores a normalized snapshot locally. When a relic cracks it recognizes the reward cards on screen and prices them from warframe.market in an override-redirect X11 overlay. This package builds from source. It requires network access during the build to resolve the Cargo and pnpm lockfiles, so it must be emerged with FEATURES="-network-sandbox", and it needs sys-apps/pnpm-bin from the ::guru overlay. Most users want games-util/tennoscope-bin instead, which installs the prebuilt binary published upstream. The two conflict; pick one.

Homepage:

https://github.com/Deftera186/tennoscope

License:

GPL-3

Versions

Metadata

Description

• Local-first Warframe companion for Linux, written in Rust + Tauri with a React/TypeScript frontend. It reads a running Warframe process read-only to obtain a session token, asks Warframe's own inventory endpoint for the player's collection, and stores a normalized snapshot locally. When a relic cracks it recognizes the reward cards on screen and prices them from warframe.market in an override-redirect X11 overlay. This package builds from source. It requires network access during the build to resolve the Cargo and pnpm lockfiles, so it must be emerged with FEATURES="-network-sandbox", and it needs sys-apps/pnpm-bin from the ::guru overlay. Most users want games-util/tennoscope-bin instead, which installs the prebuilt binary published upstream. The two conflict; pick one.

Maintainers

• Liav Mordouch (liavmordouch@gmail.com) - Type: person

Upstream

• Bugs: https://github.com/Deftera186/tennoscope/issues
• Remote IDs:
  • github: Deftera186/tennoscope

<pkgmetadata>
	<maintainer type="person">
		<email>liavmordouch@gmail.com</email>
		<name>Liav Mordouch</name>
	</maintainer>
	<longdescription lang="en">
		Local-first Warframe companion for Linux, written in Rust +
		Tauri with a React/TypeScript frontend. It reads a running
		Warframe process read-only to obtain a session token, asks
		Warframe's own inventory endpoint for the player's collection,
		and stores a normalized snapshot locally. When a relic cracks
		it recognizes the reward cards on screen and prices them from
		warframe.market in an override-redirect X11 overlay.

		This package builds from source. It requires network access
		during the build to resolve the Cargo and pnpm lockfiles, so
		it must be emerged with FEATURES="-network-sandbox", and it
		needs sys-apps/pnpm-bin from the ::guru overlay. Most users
		want games-util/tennoscope-bin instead, which installs the
		prebuilt binary published upstream. The two conflict; pick one.
	</longdescription>
	<upstream>
		<bugs-to>https://github.com/Deftera186/tennoscope/issues</bugs-to>
		<remote-id type="github">Deftera186/tennoscope</remote-id>
	</upstream>
</pkgmetadata>

Lint Warnings

• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• [Error] Manifest entry for unused DIST file 'tennoscope-0.1.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.2.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.3.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.4.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.4.1.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.1.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.2.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.3.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.4.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.5.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.6.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.5.7.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.6.0.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.6.1.tar.gz'
• [Error] Manifest entry for unused DIST file 'tennoscope-0.7.0.tar.gz'
• [Error] Repository is missing a repo-name in metadata/layout.conf or profiles/repo_name

Manifest