Re: [DEVEL] Enable support for Renesas platform
On Fri, 2022-11-18 at 15:20 +0700, Huỳnh Thành Hưng wrote: > I’m from Renesas Electronics Corporation, Welcome to Debian! In case your company would like to help out Debian, please review our suggestions for ways that companies can contribute: https://www.debian.org/intro/help#organizations > My group is developing to support running Debian OS on our devices, > also for getting ARM System Ready IR certificate. It would be great to see Renesas contribute to the Debian ARM ports, some resources for the ports are at the links below. https://wiki.debian.org/Arm64Port https://www.debian.org/ports/arm/ https://lists.debian.org/debian-arm/ This document about creating new ports should also apply to contributing to the existing Debian ports to ARM. https://wiki.debian.org/PortsDocs/New > I recognize that the latest Debian 11 (Bullseye) has the kernel which > do not enable support for Renesas platform. Please refer to the Debian Linux kernel team documentation for how to submit patches enabling this support in Debian unstable. I don't know what the policy is for enabling Linux kernel config options in stable, but it should be documented somewhere in the documentation here: https://kernel-team.pages.debian.net/kernel-handbook/ > Can you help me to enable those configs, also support the official > release version of Debian Live Installer ISO which support Renesas > platform? Debian does not yet support the ARM architecture at all with our live images, please contact the Debian Live Team about that. Currently the live images for the future Debian bookworm release are not being built, but that may change before the final release. https://wiki.debian.org/Teams/Live -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [DEVEL] Enable support for Renesas platform
On Sat, 2022-11-19 at 09:06 +0200, Josua Mayer wrote: > However note I am not part of the Debian project. > I don't know if joining makes sense, I don't know if the Debian > project would like to incorporate some developers who specifically > would collaborate to support certain vendors in Debian. > Just - there are things outsiders cannot do - like maintaining a > "Blend" e.g. You don't need to be a Debian member to contribute to Debian nor to maintain a Debian blend, everyone is welcome to do that. All package uploads will need to go via a sponsor or the maintainers though. Usually a "Blend" isn't needed to support specific hardware, as the support just goes into the existing hardware support packages like u-boot/linux/mesa. Blends are more for specific areas of use-cases like gaming or medicine or astronomy. https://mentors.debian.net/intro-maintainers/ https://wiki.debian.org/DebianPureBlends -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1024424: ITP: golang-github-max-sum-base32768 -- go implementation of base32768, optimized for UTF-16
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-max-sum-base32768 Version : 0.0~git20191205.7937843-1 Upstream Author : Max Sum * URL : https://github.com/Max-Sum/base32768 * License : Expat Programming Lang: Go Description : go implementation of base32768, optimized for UTF-16 Check (https://github.com/qntm/base32768) for information about base32768. Required by latest version of rclone To be maintained by the Debian Go Team
Bug#1024430: ITP: golang-github-coreos-go-oidc -- A Go OpenID Connect client.
Package: wnpp Severity: wishlist Owner: Leo Antunes * Package name: golang-github-coreos-go-oidc-v3 Version : 3.4.0-1 Upstream Author : CoreOS * URL : https://github.com/coreos/go-oidc * License : Apache-2.0 Programming Lang: Go Description : Go libraries for implementing OIDC clients and servers This package provides a comprehensive collection of golang libraries for other projects to implement OpenID Connect (OIDC) server and client components.
Re: libpaper and gnulib
On Wed, 16 Nov 2022 at 09:47, Helmut Grohne wrote: > > I think bug fixes is something you'd want. API changes less so. > My point was that there are frequently bug fixes and API changes since whatever version of gnulib is packaged in Debian. > Also note that gnulib is a piece that regularly faces portability issues > (as it tries to provide portability). As such, it is particularly > annoying for porters to not only have to fix gnulib, but then also have > to get it updated in tons of downstreams. How is this a problem for Debian packagers? Once software is packaged for Debian, it's already known to build and run. I stopped counting the number > of bug reports "... ships a broken, outdated, embedded copy of gnulib" > that I've sent. As a porter, I very much wish people wouldn't embed > gnulib. > I agree, gnulib as a whole shouldn't be embedded. I also agree that software that uses gnulib, even small parts of it (like libpaper) will have to update from time to time to fix bugs and portability problems. -- https://rrt.sc3d.org
Bug#1024432: ITP: golang-github-artyom-mtab -- Package to read /proc/self/mounts entries
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-artyom-mtab Version : 1.0.0-1 Upstream Author : Artyom Pervukhin * URL : https://github.com/artyom/mtab * License : Expat Programming Lang: Go Description : Package to read /proc/self/mounts entries Provides /proc/self/mounts in the Go language Required by the latest version of rclone. To be packaged by the Debian Go Team.
Re: Bug #1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
On Fri, 18 Nov 2022 at 22:23:05 +, Mike Gabriel wrote:
> The flaw in mate-polkit is that the
> /etc/xdg/autostart/.desktop file so far has been shipped in
> mate-polkit-common (which usually got built on amd64 builders) and that that
> .desktop file contains a multi-arch path in the Exec= key.
Probably a silly question, but could you build mate-polkit with
--libdir=/usr/libexec instead of /usr/lib/x86_64-linux-gnu/polkit-mate,
so that the polkit auth agent is at a location that does not vary between
architectures?
mate-polkit is currently Multi-Arch: same, but that seems wrong to me:
on a dual-architecture amd64/i386 system (or arm64/armhf or any other
combination), there is no point in running more than one architecture's
copy of the MATE polkit authentication agent. They'll all have the same
UI and the same behaviour, so any single architecture is enough. This
seems like a textbook case of a Multi-Arch: foreign package.
(On amd64 it would maybe be nice to leave behind a symlink
/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1 ->
/usr/libexec/polkit-mate-authentication-agent-1 so that if a sysadmin has
edited the conffile and therefore doesn't receive the new version, then
the agent will still start. But that's an optional quality-of-implementation
thing.)
Another possible solution to this would be to not install an XDG
autostart file into /etc at all, and instead do one or more of these:
1. teach MATE to read additional autostart files from a location below
/usr as a lower priority than XDG_CONFIG_DIRS, for instance if it
is currently reading
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":")]
then that could be changed to
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":"),
"/usr/share/mate/autostart"]
2. launch this polkit agent programmatically in MATE code (perhaps via
D-Bus activation) instead of relying on XDG autostart as a way to
discover it
3. integrate it into the desktop shell so it doesn't need to be launched
separately at all
People who have been thinking about image-based OSs are already trying to
move the community towards a model where the "factory-installed" state
of /etc is empty, and every file in /etc represents a local divergence
from that original state (sysadmin configuration). I think that's a
good goal in general: /etc has traditionally been a mixture of sysadmin
configuration (/etc/fstab, /etc/hostname) and system-integration glue
(/etc/ld.so.conf.d, /etc/xdg/autostart), and if we separated those two,
it would become a lot more obvious what is sysadmin configuration and
what is part of the OS.
Solving the problem of "the design of /etc/xdg/autostart conflicts with
wanting a factory install to have an empty /etc" *in general* is hard
because it's an interoperability point between multiple desktop environments
(e.g. people don't want to break /etc/xdg/aa-notify.desktop), so changing
it in an interoperable/consistent way requires changing the spec and every
implementation. For instance some people are advocating changing the
autostart spec so that implementations will read
/usr/etc/xdg/autostart/*.desktop or /usr/etc/autostart/*.desktop or
/usr/share/xdg/autostart/*.desktop or some standardized path like that.
AIUI there's currently no real consensus on specific paths.
However, solving it for a component that has OnlyShowIn=MATE is easy,
because by design only MATE is going to launch that component anyway -
so it's entirely reasonable for it to rely on implementation-specific
MATE behaviours. For instance, if MATE developers decided that they are
going to read /usr/share/mate/autostart as an additional search path
component of lower priority than $XDG_CONFIG_DIRS/autostart, then that
wouldn't harm interoperability with other desktops and is something
that MATE can do unilaterally.
Alternatively, integrating the polkit agent into the desktop shell is
what GNOME does: GNOME's polkit agent is part of GNOME Shell, which
has some other advantages, such as the compositor (which is also Shell)
being able to give it special handling around input-grabbing to protect
the secure input path.
If you evaluate those options and decide that you still need
conffile handling for /etc/xdg/autostart/*.desktop here:
> To simplify life (and yes, this is debatable): Do situations exist, where an
> enforced conffile update (overwriting it) is allowed / justifiable?
The Policy requirement is not "don't overwrite conffiles", the Policy
requirement is "don't revert sysadmin changes". Doing the overwrite
correctly is not going to be trivial (particularly where dpkg conffiles
interact with moving files between packages), but one technique that
I've seen used is to hard-code one or more known md5sums of unmodified
"old" conffiles with the bad path in them, and overwrite the file with
the new, "good" version if and only if it matche
Bug#1024436: ITP: golang-github-buengese-sgzip -- Experiments for a seekable gzip for use in rclone. Based on pgzip
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-buengese-sgzip Version : 0.0~git20220517.9bca1b6-1 Upstream Author : Sebastian Bünger * URL : https://github.com/buengese/sgzip * License : Expat Programming Lang: Go Description : experiments for a seekable gzip for use in rclone based on pgzip This is an experimental implementation of gzip that allows seeking in the compressed file. In normal gzip files that can only be achieved by decompressing from the start and discarding all data until the selected offset. This gzip implementation works around this by creating a special metadata file that maps uncompressed blocks to compressed blocks allowing it to only read the compressed blocks required. . Due to necessity of being able to start decompression from any block the dictionary is reset after every block. This somewhat negatively effects compression ratio but is a necessary tradeof in our use case. The gzip files created by this library are valid normal gzip files and can be decompressed by any other gzip implementation. . Warning . This library was purpose build for the rclone compression backend. If you are looking for a multithreaded golang gzip implementation you should be using klauspost/pgzip (https://github.com/klauspost/pgzip) which is the base for this library. . License . This contains large portions of code from the go repository - see GO_LICENSE for more information. The changes are released under MIT License. See LICENSE for more information. Required by the latest version of rclone. To be maintained by the Debian Go Team.
Bug#1024442: ITP: hdfs -- A native go client for HDFS
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-colinmarc-hdfs Version : 2.3.0-1 Upstream Author : Colin Marc * URL : https://github.com/colinmarc/hdfs * License : Expat Programming Lang: Go Description : A native go client for HDFS This is a native golang client for hdfs. It connects directly to the namenode using the protocol buffers API. . It tries to be idiomatic by aping the stdlib os package, where possible, and implements the interfaces from it, including os.FileInfo and os.PathError. . Along with the library, this repo contains a commandline client for HDFS. Like the library, its primary aim is to be idiomatic, by enabling your favorite unix verbs: Required by the latest version of rclone. To be maintained by the Debian Go Team.
Bug#1024445: ITP: gokrb5 -- Pure Go Kerberos library for clients and services
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-jcmturner-gokrb5 Version : 8.4.3-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/gokrb5 * License : Apache-2.0 Programming Lang: Go Description : Pure Go Kerberos library for clients and services * Server Side * HTTP handler wrapper implements SPNEGO Kerberos authentication * HTTP handler wrapper decodes Microsoft AD PAC authorization data * Client Side * Client that can authenticate to an SPNEGO Kerberos authenticated web service * Ability to change client's password * General * Kerberos libraries for custom integration * Parsing Keytab files * Parsing krb5.conf files * Parsing client credentials cache files such as /tmp/krb5cc_$(id -u $(whoami)) v5 of this package is already available in golang-gopkg-jcmturner-gokrb5.v5-dev but the latest version of rclone requires gokrb5 v8. This package is intended to provide the latest version of gokrb5 (without using a -v version tag) To be maintained by the Debian Go Team.
Bug#1024446: ITP: libstring-tagged-terminal-perl -- module to format terminal output using String::Tagged
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libstring-tagged-terminal-perl Version : 0.05 Upstream Author : Paul Evans * URL : https://metacpan.org/release/String-Tagged-Terminal * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to format terminal output using String::Tagged String::Tagged::Terminal is subclass of String::Tagged and provides a method, build_terminal, for outputting the formatting tags embedded in the string as terminal escape sequences, to render the output in the appropriate style. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024448: ITP: libcommandable-perl -- utilities for commandline-based programs
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcommandable-perl Version : 0.08 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Commandable * License : Artistic or GPL-1+ Programming Lang: Perl Description : utilities for commandline-based programs The Commandable distribution contains a collection of utilities extracted from various commandline-based programs, in the hope of trying to find a standard base to build these from in future. "Commandline" does not necessarily mean "plain-text running in a terminal"; simply that the mode of operation is that the user types a textual representation of some action, and the program parses this text in order to perform it. This could equally apply to a command input text area in a GUI program. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024449: ITP: libdevel-mat-perl -- Perl Memory Analysis Tool
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdevel-mat-perl Version : 0.49 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Devel-MAT * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl Memory Analysis Tool The Devel::MAT ecosystem allows developers of perl programs to inspect and analyse memory-related problems such as memory leaks, unexpected memory consumption, or odd state. This is an "offline" analysis system, in the sense that the analysis tools all run in a different process, possibly at a later time, than the perl process that is being analysed. The basic workflow consists of two main stages: first a heap dump file is generated from the perl process being debugged, at or around the time that the problem becomes apparent, and secondly this file is loaded by an analysis tool in order to inspect the contents. To generate the heap dump file that captures the contents of the heap, the Devel::MAT::Dumper (libdevel-mat-dumper-perl) module is used. Now that we have a .pmat file, we can load it and start to inspect the contents. A lot of the smaller, simpler tools are built as plugins for the main pmat command shell (contained in libdevel-mat-perl, together with Devel::MAT), so we can start by loading the heap file there. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: setuptools-gettext Version : 0.0.1 Upstream Author : Breezy Team * URL : https://github.com/jelmer/setuptools-gettext * License : GPL Programming Lang: Python Description : Compile .po files into .mo files This extension for setuptools compiles gettext .po files found in the source directory into .mo files and installs them.
Bug#1024463: ITP: golang-github-twpayne-go-shell -- platform-independent library for determining a user's shell
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh Control: block 1012721 by -1 * Package name: golang-github-twpayne-go-shell Version : 0.3.1-1 Upstream Author : Tom Payne * URL : https://github.com/twpayne/go-shell * License : Expat Programming Lang: Go Description : platform-independent library for determining a user's shell A go library that returns a user's shell on Darwin, Plan9, POSIX, and Windows systems. -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#1024464: ITP: golang-github-muesli-combinator -- slice generator for all possible combinations of values
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh Control: blocks -1 1012721 * Package name: golang-github-muesli-combinator Version : 0.3.0-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/combinator * License : Expat Programming Lang: Go Description : slice generator for all possible combinations of values Generates a slice of all possible value combinations for any given struct and a set of its potential member values. This can be used to generate extensive test matrixes among other things. -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#1024466: ITP: libpass-otp-perl -- Perl implementation of HOTP / TOTP algorithms
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libpass-otp-perl Version : 1.5 Upstream Author : Jan Baier * URL : https://metacpan.org/release/Pass-OTP * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl implementation of HOTP / TOTP algorithms The Pass::OTP module provides implementation of HOTP and TOTP algorithms according to the RFC 4226 and RFC 6238. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024470: ITP: golang-github-hirochachacha-go-smb2 -- SMB2/3 client library written in Go.
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-hirochachacha-go-smb2 Version : 1.1.0-1 Upstream Author : xHiroshi Ioka * URL : https://github.com/hirochachacha/go-smb2 * License : BSD-2-clause Programming Lang: Go Description : SMB2/3 client library written in Go. SMB2/3 client implementation for the Go language. Required by the latest version of rclone To be maintained by the Debian Go Team.
