Re: Urgent help with upload of netatalk to prevent being autoremoval from testing
Am 29. Juni 2024 13:32:40 MESZ schrieb Daniel Markstedt : > >Normally I would be more patient, but right now netatalk is slated to get >removed from Trixie testing on July 4th due to one of the bugs >(libgcrypt-config deprecation.) > I cannot offer any action right now (busy IRL as well), but: don't panic. There's nothing wrong with being removed from testing. Once the package is updated to unstable, it will migrate to testing as normal (except during freeze times, but we aren't there currently). So: relax :-) mfh.her.fsr IOhannes
Bug#1073195: ITP: hyprwayland-scanner -- Implementation of wayland-scanner for Hyprland
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: hyprwayland-scanner Version : 0.3.10 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprwayland-scanner * License : BSD-3-Clause Programming Lang: C++ Description : Implementation of wayland-scanner for Hyprland hyprwayland-scanner is "a Hyprland implementation of wayland-scanner, in and for C++." This is a dependency for the Hyprland window manager for Wayland[1][2]. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
Bug#1073158: ITP: hyprutils -- C++ library for utilities used across the Hypr ecosystem
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: hyprutils Version : 0.1.2 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprutils * License : BSD-3-Clause Programming Lang: C++ Description : C++ library for utilities used across the Hypr ecosystem >From the github repo: "Hyprutils is a small C++ library for utilities used across the Hypr* ecosystem." Hyprutils is library dependency required by the Hyprland[1][2] window manager. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
Bug#1072274: ITP: fcitx5-varnam -- Fcitx5 wrapper for Varnam input method.
Package: wnpp Severity: wishlist Owner: Anoop M S X-Debbugs-Cc: debian-devel@lists.debian.org, anoo...@disroot.org * Package name: fcitx5-varnam Version : 0.0.1 Upstream Contact: Anoop M S * URL : https://github.com/varnamproject/varnam-fcitx5 * License : GPL Programming Lang: C++ Description : Fcitx5 wrapper for Varnam input method. Fcitx5 wrapper for Varnam(https://www.varnamproject.com) Input Method Engine. Easily type Indian languages on Linux desktops. I would like to join Debian Input Method Team, and package and maintain it. And I would need a sponsor to upload it as well.
Bug#1069659: ITP: rust-lifeguard -- An object pool manager in Rust
Package: wnpp Severity: wishlist Owner: "Loren M. Lang" X-Debbugs-Cc: debian-devel@lists.debian.org, lor...@north-winds.org * Package name: rust-lifeguard Version : 0.6.1 Upstream Contact: Zack Slayton * URL : https://crates.io/crates/lifeguard * License : MIT Programming Lang: Rust Description : An object pool manager in Rust Allows values to be stored in a pool and retrieved when needed to access or mutate their contents. Values can be unwrapped and detached from the pool when needed and later returned to the pool or new values added in efficiently. This is needed for rust-adblock -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Debian packaging for git-credential-libsecret
Hi. It'd be great to package Git credential helper git-credential-libsecret in Debian. There's a patch prepared, but it needs the attention of a Debian developer. Is anyone here able to help? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599 Kind regards -M
Bug#1067116: ITP: libhyprcursor -- hyprland cursor format, library and utilities
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: libhyprcursor Version : 0.1.4 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprcursor * License : BSD-3-Clause Programming Lang: C, C++ Description : hyprland cursor format, library and utilities >From the README: " XCursor sucks, and we still use it today. - Scaling of XCursors is horrible - XCursor does not support vector cursors - XCursor is ridiculously space-inefficient Hyprcursor fixes all three. It's an efficient cursor theme format that doesn't suck as much. ### Notable advantages over XCursor - Automatic scaling according to a configurable, per-cursor method. - Support for SVG cursors - Way more space-efficient. As an example, Bibata-XCursor is 44.1MB, while it's 6.6MB in hyprcursor. " hyprcursor is a new dependency for hyprland[1]. The package would generate a library and a binary utility to convert xcursor themes to hyprcursor format. The utility has a runtime dependency on xcur2png[2], which is also not available in Debian. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [2] https://github.com/eworm-de/xcur2png
Re: Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland
Hello Mo, May I address you Mo? I am happy to co-maintain hyprland with you. :) The ITP for hyprland[0] was created by werdahias@ who had created an initial skeleton for the packaging a while ago. Under his advise, I decided to de-vendor all of udis86, tracy and hyprland-protocols. As far as I understand, the Debian policy recommends de-vendoring over including files from other sources. I have been working on this for a while and just uploaded them all to mentors and created RFS for them. Currently I have completed packaging hyprland and all its dependencies to the best of my ability. Regarding the points you shared: 1. I wasn't sure what to do with tracy. I have however de-vendored it and created an RFS for it[1]. But, I am unable to get the GPU traces working on my AMD RX 6600 (for a debug build of Hyprland with tracy enabled). I am not sure if this is because of my device or something else. I have seen some discussion upstream that tracy's GPU traces are not always reliable. Tracy seems to work fine, otherwise. 2. I have de-vendored udis86 too. The library and the included CLI seems to run fine. Here is the RFS[2]. 3. Again, I have separated hyprland-protocols and the RFS is here[3]. You can find the VCS for all hyprland related stuff I did, under the NyxTrail namespace in salsa[4]. The packages all seem to run fine so far. This is my first time packaging for Debian and any feedback is welcome. Let me know how you wish to proceed. Regards, Alan [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868 [4] https://salsa.debian.org/NyxTrail On 3/15/24 01:10, Mo Zhou wrote: Hi Alan, Thank you for your work! I did not check the ITP bugs before we make overlapping efforts: https://salsa.debian.org/debian/hyprlang https://salsa.debian.org/debian/hyprland I just rushed the two packages within a short time the last night. They work properly on Sid with my laptop. I have uploaded hyprlang to NEW without checking ITP https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html The hyprland is still pending as I've not yet finished the debian/copyright part. In terms of build depends of hyprland: 1. tracy is optional. USE_TRACY is by default off. We can build the package without tracy. 2. the udis86 is embedded in the upstream tarball as well. Maybe we can keep it embedded as udis86 is only needed by hyprland 3. hyprland-protocols is also embedded. I suppose it is ok to keep this specific project, instead of splitting the package to increase the required amount of work. Shall we merge our work and co-maintain this? On 3/14/24 14:46, Alan M Varghese wrote: Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: a...@digistorm.in Dear mentors, I am looking for a sponsor for my package "libhyprlang": * Package name : libhyprlang Version : 0.5.0-1 Upstream contact : vaxerski * URL : https://github.com/hyprwm/hyprlang * License : LGPL-3+ * Vcs : https://salsa.debian.org/NyxTrail/hyprlang Section : x11 The source builds the following binary packages: libhyprlang2 - Configuration language for Hyprland (library) libhyprlang-dev - Configuration language for Hyprland (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhyprlang/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc Changes for the initial release: libhyprlang (0.5.0-1) UNRELEASED; urgency=low . * Initial release. Closes: #1065352 Regards,
Bug#1065699: ITP: hyprpaper -- Wallpaper utility for Hyprland
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: hyprpaper Version : 0.6.0 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprpaper * License : BSD-3-Clause Programming Lang: C++ Description : Wallpaper utility for Hyprland Hyprpaper is a blazing fast wallpaper utility for Hyprland (or any wlroots-based compositors) with the ability to dynamically change wallpapers through sockets. This program is suggested by Hyprland[1][2] and is created by the same team. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
Bug#1065352: ITP: libhyprlang -- Configuration language for Linux applications
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: libhyprlang Version : 0.4.1 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprlang * License : GPL Programming Lang: C++ Description : Configuration language for Linux applications The hypr configuration language is an extremeley efficient, yet easy to work with, configuration language for Linux applications. This is a dependency for the Hyprland window manager for Wayland[1][2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [2] https://github.com/hyprwm/Hyprland/
Re: Another take on package relationship substvars
Am 24. Februar 2024 11:26:56 MEZ schrieb Bernd Zeimetz :
>On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
>>
>> While I like the idea in general, I wonder how I could override these
>> automatic additions.
>> I think there are some packages that even demote `${shlibs:Depends}`
>> to Recommends.
>>
>
>Absolutely. collectd for example
Yes, that's what I had in mind.
mfh.her.fsr
IOhannes
Re: Another take on package relationship substvars
Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang :
>在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
>> I think our package helper tooling should just automatically aggregate
>> all provided substvars of the format ${*:Depends} and append it the
>> Depends field. Rinse and repeat for other relationship fields.
>>
>> The list of fields where this is applied would be curated, so it only
>> applies to known relationship fields where we feel it makes sense. My
>> starting list would be:
>>
>> * Any dependency field, that is: Pre-Depends, Depends, Recommends, and
>> Suggests
>>
>> * The Provides field.
>>
>> I am omitting Breaks, Conflicts, and Replaces because I am not aware of
>> any users of these at the moment. I am open to adding them, if there is
>> a strong use-case.
>
>Can we also consider ${*:Built-Using} as typically seen in
>${sphinxdoc:Built-Using}?
While I like the idea in general, I wonder how I could override these automatic
additions.
I think there are some packages that even demote `${shlibs:Depends}` to
Recommends.
mfh.her.fsr
IOhannes
Re: Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang
On Sat, Feb 17, 2024 at 02:28:41AM +0100, Guillem Jover wrote: > Hi! > > On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Loren M. Lang > > > * Package name: golang-github-cheggaaa-pb > > This is already packaged as: > > golang-github-cheggaaa-pb.v3-dev > golang-gopkg-cheggaaa-pb.v2-dev > golang-gopkg-cheggaaa-pb.v1-dev I discovered v3-dev shortly after submitting that ITP. My script for detecting missing dependencies was being too literal and only looked for a package named golang-github-cheggaaa-pb-v3-dev. A simple search for cheggaaa very quickly found the matching package I was missing. Closing this as not-a-bug / duplicate. > > Thanks, > Guillem > -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang
Package: wnpp
Severity: wishlist
Owner: Loren M. Lang
* Package name: golang-github-cheggaaa-pb
Version : 3.1.5-1
Upstream Author : Sergey Cherepanov
* URL : https://github.com/cheggaaa/pb
* License : BSD-3-clause
Programming Lang: Go
Description : Console progress bar for Golang
Terminal progress bar for Go
.
Coverage Status (https://coveralls.io/github/cheggaaa/pb)
.
Installation
.
go get github.com/cheggaaa/pb/v3
.
Documentation for v1 bar available here (/README_V1.md).
.
Quick start
.
package main
.
import (
"time"
.
"github.com/cheggaaa/pb/v3"
)
.
func main() {
count := 10
.
// create and start new bar
bar := pb.StartNew(count)
.
// start bar from 'default' template
// bar := pb.Default.Start(count)
.
// start bar from 'simple' template
// bar := pb.Simple.Start(count)
.
// start bar from 'full' template
// bar := pb.Full.Start(count)
.
for i := 0; i < count; i++ {
bar.Increment()
time.Sleep(time.Millisecond)
}
.
// finish bar
bar.Finish()
}
.
Result will be like this:
.
> go run test.go
37158 / 10 [>___] 37.16% 916
p/s
.
Settings
.
// create bar
bar := pb.New(count)
.
// refresh info every second (default 200ms)
bar.SetRefreshRate(time.Second)
.
// force set io.Writer, by default it's os.Stderr
bar.SetWriter(os.Stdout)
.
// bar will format numbers as bytes (B, KiB, MiB, etc)
bar.Set(pb.Bytes, true)
.
// bar use SI bytes prefix names (B, kB) instead of IEC (B, KiB)
bar.Set(pb.SIBytesPrefix, true)
.
// set custom bar template
bar.SetTemplateString(myTemplate)
.
// check for error after template set
if err := bar.Err(); err != nil {
return
}
.
// start bar
bar.Start()
.
Progress bar for IO Operations
.
package main
.
import (
"crypto/rand"
"io"
"io/ioutil"
.
"github.com/cheggaaa/pb/v3"
)
.
func main() {
var limit int64 = 1024 * 1024 * 500
.
// we will copy 500 MiB from /dev/rand to /dev/null
reader := io.LimitReader(rand.Reader, limit)
writer := ioutil.Discard
.
// start new bar
bar := pb.Full.Start64(limit)
.
// create proxy reader
barReader := bar.NewProxyReader(reader)
.
// copy from proxy reader
io.Copy(writer, barReader)
.
// finish bar
bar.Finish()
}
.
Custom Progress Bar templates
.
Rendering based on builtin text/template
(https://pkg.go.dev/text/template) package. You can use existing pb's
elements or create you own.
.
All available elements are described in the element.go (/v3/element.go)
file.
.
All in one example:
.
tmpl := `{{ red "With funcs:" }} {{ bar . "<" "-" (cycle . "↖" "↗" "↘"
"↙" ) "." ">"}} {{speed . | rndcolor }} {{percent .}} {{string .
"my_green_string" | green}} {{string . "my_blue_string" | blue}}`
.
// start bar based on our template
bar := pb.ProgressBarTemplate(tmpl).Start64(limit)
.
// set values for string elements
bar.Set("my_green_string", "green").Set("my_blue_string", "blue")
This is a dependency for pwru which is in RFP and I plan to complete packaging
shortly. pwru is an eBPF-based Linux kernel networking debugger.
Bug#1064081: ITP: golang-github-cloudflare-cbpfc -- cBPF to C or eBPF compiler
Package: wnpp Severity: wishlist Owner: Loren M. Lang * Package name: golang-github-cloudflare-cbpfc Version : 0.0~git20231012.992ed75-1 Upstream Author : Cloudflare * URL : https://github.com/cloudflare/cbpfc * License : BSD-3-clause Programming Lang: Go Description : cBPF to C or eBPF compiler cbpfc . GoDoc (https://godoc.org/github.com/cloudflare/cbpfc) . cbpfc is a classic BPF (cBPF) to extended BPF (eBPF) compiler. It can compile cBPF to eBPF, or to C, and the generated code should be accepted by the kernel verifier. . cbpfc/clang (https://godoc.org/github.com/cloudflare/cbpfc/clang) is a simple clang wrapper for compiling C to eBPF. . Tests . Dependencies . * clang * Path can be set via environment variable $CLANG . . Unprivileged . * go test -short . Full . * Requires: * root or CAP_SYS_ADMIN to load XDP programs * Recent (4.14+) Linux kernel * sudo go test This is a dependency for pwru which is in RFP and I plan to complete packaging shortly. pwru is an eBPF-based Linux kernel networking debugger.
Bug#1063929: ITP: golang-github-go-quicktest-qt -- Quick helpers for testing Go applications using generics.
Package: wnpp
Severity: wishlist
Owner: Loren M. Lang
* Package name: golang-github-go-quicktest-qt
Version : 1.101.0-1
Upstream Author :
* URL : https://github.com/go-quicktest/qt
* License : Expat
Programming Lang: Go
Description : Quick helpers for testing Go applications using generics.
qt: quicker Go tests
.
go get github.com/go-quicktest/qt
.
Package qt provides a collection of Go helpers for writing tests. It
uses generics, so requires Go 1.18 at least.
.
For a complete API reference, see the package documentation
(https://pkg.go.dev/github.com/go-quicktest/qt).
.
Quicktest helpers can be easily integrated inside regular Go tests, for
instance:
.
import "github.com/go-quicktest/qt"
.
func TestFoo(t *testing.T) {
t.Run("numbers", func(t *testing.T) {
numbers, err := somepackage.Numbers()
qt.Assert(t, qt.DeepEquals(numbers, []int{42, 47})
qt.Assert(t, qt.ErrorMatches(err, "bad wolf"))
})
t.Run("nil", func(t *testing.T) {
got := somepackage.MaybeNil()
qt.Assert(t, qt.IsNil(got), qt.Commentf("value: %v",
somepackage.Value))
})
}
.
Assertions
.
An assertion looks like this, where qt.Equals could be replaced by any
available checker. If the assertion fails, the underlying t.Fatal method
is called to describe the error and abort the test.
.
qt.Assert(t, qt.Equals(someValue, wantValue))
.
If you don’t want to abort on failure, use Check instead, which calls
Error instead of Fatal:
.
qt.Check(t, qt.Equals(someValue, wantValue))
.
The library provides some base checkers like Equals, DeepEquals,
Matches, ErrorMatches, IsNil and others. More can be added by
implementing the Checker interface.
.
Other helpers
.
The Patch helper makes it a little more convenient to change a global or
other variable for the duration of a test.
This package is being added to support cilium/pwru which is RFP in BTS
#1063031.
Bug#1063442: ITP: tracy -- Real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: tracy Version : 0.10.0 Upstream Contact: Bartosz Taudul * URL : https://github.com/wolfpld/tracy * License : BSD-3-Clause Programming Lang: C++, C Description : Real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications Tracy is a real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications. Tracy supports profiling CPU (Direct support is provided for C, C++, and Lua integration. At the same time, third-party bindings to many other languages exist on the internet, such as Rust, Zig, C#, OCaml, Odin, etc.), GPU (All major graphic APIs: OpenGL, Vulkan, Direct3D 11/12, OpenCL.), memory allocations, locks, context switches, automatically attribute screenshots to captured frames, and much more. Tracy is a "debug build" dependency for Hyprland[1] and is included in the upstream tarball for that project. I am attempting to package it separately to meet the requirements and guidelines of the Debian project[2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
Bug#1062455: ITP: tiv -- Small command-line image viewer using RGB ANSI colors and Unicode block characters to render image
Package: wnpp Severity: wishlist Owner: "Loren M. Lang" X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tiv Version : 1.2.1 Upstream Author : Aaron Liu , Stefan Haustein * URL : https://github.com/stefanhaustein/TerminalImageViewer * License : GPL3, ASL Programming Lang: C++ Description : Small command-line viewer using RGB colors and Unicode block characters to render image Small command-line image viewer using 24-bit RGB ANSI colors and Unicode block characters which create a 4x8 pixel cell for each character. With the use of these Unicode block characters, this can provide a higher resolution image for the same screen real estate. It was compared with timg and catimg and can get out finer detail than those tools and make a sharper presentation. The mail_new.png icon seems to have a lot of fine detail with the text on the page. Here is my comparision case: catimg -H 32 /usr/share/icons/mate/256x256/actions/mail_new.png timg -g 32x32 /usr/share/icons/mate/256x256/actions/mail_new.png ./tiv -h 32 -w 32 /usr/share/icons/mate/256x256/actions/mail_new.png I am currently planning on maintaining it myself, but I am open if there is a team that is more appropriate to help with it. The package itself is very lightweight and should not require much maintenance. I will need a sponsor to get this package into Debian. -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Adding an optional dependency for test suite
I have a package which has an extensive test suite that relies on using docker/podman to create a container for it's test runner and mounts the build tree read-only inside it. If docker or podman is found at the time of configure, it will include a check target to run the full suite and dh_auto_test will automatically invoke it as part of the binary package build. Otherwise, it is just skipped with a message and builds without running any tests. When I run dpkg-buildpage to build locally, I get the test suite as I have it installed, but when I build with pbuilder or schroot, the tests get skipped. Should I add a build-depenency on podman or is there some mechanism to make it optional? I suppose I could just try adding the package to my referenec images so it's there when I build inside a chroot(), but does buildd normally try to run test suites when available after a new source package is uploaded? Or it that not normally done on the build server? -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Proper handling of Lintian warnings due to other packages
While building a package preparing for a possible upload, I am getting a large number of warnings from groff-message due to invalid fonts for C and CB in the manpages that are generated from Markdown with pandoc. From what I understand, this is a known issue with how pandoc generates nroff man pages and more recent versions of groff have started complaining about the issue. Here is an example warning I am getting: groff-message troff::89: warning: cannot select font 'C' And it seems to match the issue documented here: https://github.com/jgm/pandoc/issues/9020 My question is how to handle this. Should I just ignore it for now and upload anyways since it's only a warning or should I add an override to suppress it as it doesn't seem to be causing any breaking issues at the moment? Have other developers dealt with this warning before? -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Bug#1061940: ITP: libudis86 -- Disassembler for the x86 and x86-64 class of instructions set
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: libudis86 Version : #5336633 Upstream Contact: https://github.com/canihavesomecoffee/udis86/issues * URL : https://github.com/canihavesomecoffee/udis86 * License : BSD 2-Clause Programming Lang: C, Python Description : Disassembler for the x86 and x86-64 class of instructions set Udis86 is a disassembler for the x86 and x86-64 class of instruction set architectures. It consists of a C library called libudis86 which provides a clean and simple interface to decode and inspect a stream of raw binary data as disassembled instructions in a structured manner, and a command line tool called udcli that incorporates the library. canihavesomecoffee/udis86 is a dependency for Hyprland[1][2] that I am interested in packaging. This project is a fork of another of similar name[3][4] with fixes and additions merged from other forks[6]. It looks like there was an ITP created for the original[7] which was later abandoned. @werdahias has prepared initial packaging here[8]. My attempt[9] is based on this. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [3] https://github.com/vmt/udis86 [4] https://sourceforge.net/projects/udis86/ [6] https://github.com/canihavesomecoffee/udis86?tab=readme-ov-file#author-and-contributors [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893807 [8] https://salsa.debian.org/werdahias/udis86-wip/ [9] https://salsa.debian.org/NyxTrail/udis86
Bug#1040971: ITP: hyprland -- dynamic tiling Wayland compositor based on wlroots
Package: wnpp Followup-For: Bug #1040971 Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: hyprland Version : 0.34.0 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/Hyprland * License : BSD-3-Clause Programming Lang: C++ Description : dynamic tiling Wayland compositor based on wlroots - From the readme: " Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks. It supports multiple layouts, fancy effects, has a very flexible IPC model allowing for a lot of customization, a powerful plugin system and more. " Upstream for Hyprland provides a source tarball with all its submodules packaged together. I intend to package them as-is and not separate out wlroots (don't know if that would even be possible; a custom wlroots binary is built and linked against during the build process).
Bug#1060113: ITP: debgpt -- Chatting LLM with Debian-Specific Knowledge
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: debgpt Version : ? (CLI not yet stablized) Upstream Contact: me * URL : https://salsa.debian.org/deeplearning-team/debgpt * License : MIT/Expat Programming Lang: python Description : Chatting LLM with Debian-Specific Knowledge This tool is still under development. I may not upload it very soon, but an ITP number helps me silent lintian. I will not upload untill I finish the CLI re-design, and finish the documentation parts. There are some interesting findings while experimenting. For instance, I find this rather convenient: $ debgpt -HQ --cmd 'git diff --staged' -A 'Briefly describe the change as a git commit message.' So I further wrapped the git commit command into $ debgpt git commit which automatically generates a description for staged changes and commit them for you. Currently, some of the code of debgpt is written by debgpt, some of the git commit messages are written by `debgpt git commit`. I will try to explore more possibilities and add them in future releases. The only missing dependency before uploaindg this is only src:python-openai, which awaits in NEW as the time of writing. The following is the full package description: Large language models (LLMs) are newly emerged tools, which are capable of handling tasks that traditional software could never achieve, such as writing code based on the specification provided by the user. In this tool, we attempt to experiment and explore the possibility of leveraging LLMs to aid Debian development, in any extent. Essentially, the idea of this tool is to gather some pieces of Debian-specific knowledge, combine them together in a prompt, and then send them all to the LLM. This tool provides convenient functionality for automatically retrieving information from BTS, buildd, Debian Policy, system manual pages, tldr manuals, Debian Developer References, etc. It also provides convenient wrappers for external tools such as git, where debgpt can automatically generate the git commit message and commit the changes for you. This tool supports multiple frontends, including OpenAI and ZMQ. The ZMQ frontend/backend are provided in this tool to make it self-contained. Thank you for using reportbug
DebGPT: how LLM can help debian development? demo available.
Hi folks, Following what has been discussed in d-project in an offtopic subthread, I prepared some demo on imagined use cases to leverage LLMs to help debian development. https://salsa.debian.org/deeplearning-team/debgpt To run the demo, the least requirement is a CUDA GPU with > 6GB memory. You can run it on CPU of course, but that will require > 64GB RAM, and it may take > 20 minutes to give you a reply (I tested this using Xeon Gold 6140). A longer context will require more memory. If you cannot run the demo, I also provided a couple of example sessions. You can use `reply.py` to replay my llm session to figure out how it works. Installation and setup guide can be found in docs/. First start the LLM inference backend: $ debgpt backend --device cuda --precision 4bit Then you can launch the frontend to interact with it. The complete list of potential use cases are listed in demo.sh . I have recorded my session as an example for every single command inside. The following are some selected examples use cases: (the results are not always perfect. You can ask LLM to retry though) 1. let LLM read policy section 4.9.1 and implement "nocheck" support in pytorch/debian/rules command: debgpt x -f examples/pytorch/debian/rules --policy 4.9.1 free -i replay: python3 replay.py examples/84d5a49c-8436-4970-9955-d14592ef1de1.json 2. let LLM add armhf, and delete kfreebsd-amd64 from archlist in pytorch/debian/control command: debgpt x -f examples/pytorch/debian/control free -i replay: python3 replay.py examples/e98f8167-be4d-4c27-bc49-ac4b5411258f.json 3. I always forget which distribution should I target when uploading to stable. Is it bookworm? bookworm-pu? bookworm-updates? bookworm-proposed-updates? We let llm read devref section 5.1 and let it answer the question command: debgpt devref -s 5.5 free -i replay: python3 replay.py examples/6bc35248-ffe7-4bc3-93a2-0298cf45dbae.json 4. Let LLM explain the difference among proposals in vote/2023/vote_002 . command: debgpt vote -s 2023/vote_002 diff replay: python3 replay.py examples/bab71c6f-1102-41ed-831b-897c80e3acfb.json Note, this might be sensitive. I added a big red warning in the program if you ask LLM about vote questions. Do not let LLM affect your vote. 5. Mimic licensecheck. The licensecheck perl implementation is based on regex. It has a small knowledge base, and does not work when the text is very noisy. command: debgpt file -f debgpt/llm.py licensecheck -i replay: python3 replay.py examples/c7e40063-003e-4b04-b481-27943d1ad93f.json 6. My email is too long and you dont want to read it. LLM can summarize it. command: debgpt ml -u 'https://lists.debian.org/debian-project/2023/12/msg00029.html' summary -i replay: python3 replay.py examples/95e9759b-1b67-49d4-854a-2dedfff07640.json 7. General chat with llm without any additional information. command: debgpt none -i replay: python3 replay.py examples/da737d4c-2e93-4962-a685-2a0396d7affb.json The core idea of all those sub functionalities are the same. Just gather some task-specific information. And send them together to the LLM. I felt the state-of-the-art LLMs are much better than that in a few months ago. I'll leave it to the community to evaluate how LLM can help debian development, as well as how useful it is, and how reliable it is. You can also tell me more ideas on how we can interact with LLM for debian-specific tasks. It is generally not difficult to implement. The difficulty stems from the hardware capacity, and hence the context length. Thus, the client program has to fetch the most-relevant information regarding the task. How do you think?
Bug#1058940: ITP: libaaf -- library for Advanced Authoring Format (AAF) file reading
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libaaf Version : 0.1 Upstream Contact: Adrien Gesta-Fline * URL : https://github.com/agfline/LibAAF * License : GPL2 Programming Lang: C Description : library for Advanced Authoring Format (AAF) file reading LibAAF is a C coded library for Advanced Authoring Format (AAF) file handling. The Advanced Authoring Format (AAF) is a file format for professional cross-platform data interchange, designed for the video post-production and authoring environment, and is commonly used by commercial video editors. For now, LibAAF only supports reading AAF files LibAAF is a new build dependency of ardour. I intend to maintain this unter the multimedia-team umbrella.
Re: Signature strength of .dsc
Am 8. Dezember 2023 18:56:00 MEZ schrieb Simon Josefsson : > >I think that is unfortunate and not sustainable over time: you need to >have access to the public keys to verify old signatures, and for as long >as the old signatures are published we should make a public keyring for >them easily available. Which I suspect means essentially forever, due >to archive.debian.org. But certainly there are keyring packages on archive.d.o in the archived releases that hold the keys for the packages found within the resp. release? (modulo the problem we are facing right now: missing keys of packages uploaded aeons before the resp. release). I probably agree that it would be /nice/ (though I don't think: necessary) to have a keyring package in a given release that includes all keys that were used to bring the packages into that very release (that is: if a package was uploaded 10 years ago, the old key used to upload this package should be included somehow). But I don't see why we would need to ship (in a current package) all keys that were ever used in the history of Debian, just because somebody might do some archeology in the archives. mfh.her.fsr IOhannes
Bug#1056159: ITP: python3-browser-cookie3 -- Python module for extracting cookies from browser
Package: wnpp Severity: wishlist Owner: Eduardo M Kalinowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : python3-browser-cookie3 Version : 0.19.1 Upstream Contact: Boris Babic * URL : https://github.com/borisbabic/browser_cookie3/ * License : LGPL-3 Programming Lang: Python Description : Python module for extracting cookies from browser This module extracts cookies from a web browser (Chrome, Firefox, LibreWolf, Opera, Opera GX, Edge, Chromium, Brave, Vivaldi, and Safari) and stores them in a cookiejar object. I hope to maintain this part as part of the Python team. -- Do not flush. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: RFC: advise against using Proton Mail for Debian work?
On Tue, 2023-11-14 at 18:40 -0500, Nicholas D Steeves wrote: > > I see three outcomes: > > A) Continue to explain this to new contributors on a one-by-one > basis. > B) Advise against using Proton Mail for Debian work (where? our > wiki?) > C) Proton Mail begins to do something differently on their end, such > as > offering some features to Debian contributors that currently require > a > subscription. Instead, is it possible to make BTS reject encrypted (unreadable) mails? In that way no particular service name has to be mentioned and Debian members will be able to figure out the mail service has got an issue. Discouraging the usage of a certain service publically just because of some technical issues (instead of ethical/moral/legal) is very much likely problematic, as an organization. Plus, the 5-th clause if DFSG is "no discrimination against persons or groups". People outside the community will mock us if we ban it like this. I just felt some sort of resemblance to "XXX operating system is evil, do not use it". Whether or not people agrees with it personally, it is inappropriate to make such opinion official.
Re: reference Debian package of multiple binaries sharing one man page
Am 10. November 2023 20:20:35 MEZ schrieb Norwid Behrnd : >Hello, > >I seek a maintained Debian package which provides multiple binaries sharing one >man page in common -- do you know an example? > faust mfh.her.fsr IOhannes
Bug#1055677: ITP: monaspace -- An innovative superfamily of fonts for code
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: monaspace * URL : https://github.com/githubnext/monaspace/tree/main * License : OFL-1.1 Programming Lang: N/A Description : An innovative superfamily of fonts for code I'll maintain this under the fonts team. It is not easy to find a good coding font. This one looks great. The Monaspace type system: a monospaced type superfamily with some modern tricks up its sleeves. It is comprised of five variable axis typefaces. Each one has a distinct voice, but they are all metrics- compatible with one another, allowing you to mix and match them for a more expressive typographical palette. Thank you for using reportbug
Re: ITP: art/6.1-1 --ASCII art
Am 23. Oktober 2023 02:33:37 MESZ schrieb Yogeswaran Umasankar : >Package: wnpp >Owner: Yogeswaran Umasankar >Severity: wishlist > >* Package name : art > Version : 6.1-1 > Upstream contact : Sepand Haghighi > * URL : https://github.com/sepandhaghighi/art > * License : MIT > * Vcs : https://salsa.debian.org/NGC2023/art > Section : python > Description: ASCII art > >ASCII art is also known as "computer text art". It involves the From the package name, I gather that this is a collection of art pieces. From the package description, I gather it is a collection of ASCII art pieces. Since such collection is probably not "complete", the genetic name seems a bit pretentious. If the package is not a collection of art pieces, would you consider a more specific name for both the source and binary packages, like "python-art" (resp "python3-art"), as mandated by the python policy? mfh.her.fsr IOhannes
Re: Is there a generic canonical way for a package script to check network connectivity?
Am 9. Oktober 2023 09:17:07 MESZ schrieb Thomas Goirand : >After many wrong designs, I ended up having a process that pings the service I >need to access to, Unless of course there is some paranoid firewall that considers ICMP malicious and therefore blocks pings. (We had that at university here. In the meantime they at least opened outgoing pings, but even those were initially blocked. Go figure) As for the original suggestion using `nmcli` I would probably consider this a rather rude dependency (I'm very happy with network manager on my desktop machines, but there's other systems as well). Even if the package you are talking about is "solely" targeted at desktop machines (the other week I learned the hard way that you cannot run some "software center" on the raspberry pi (based on bullseye) unless `nmcli` reported connectivity, even though the system was clearly online). I very much agree with Simon's sentiment about checking your *actual* prerequisites. mfh.her.fsr IOhannes
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sun, 2023-09-17 at 22:16 +0200, Joerg Jaspert wrote: > > I do not think wasting space is any good idea. > > > ## More bandwidth > > According to https://www.speedtest.net/global-index, broadband > > bandwidth > > in Nicaragua becomes almost 10x > > And elsewhere it may have gone up a different factor. > Still, there are MANY places where its still bad. I fully agree. I forgot to mention this point in my other response in the thread. The thing is, while the average bandwidth do increase as time goes by, the bottom-1% will not likely increase like that. In many corners in the world, people are still using poor and expensive network. Those networks might be even metered. Significantly bloating up the mirror size will directly increase the metered network bill for those people. I was one of them. It will also increase the pressure on mirror hosting. Some universities host linux mirrors on their own. Debian is always the most bulky repository to mirror. They are not always commercially supported -- sometimes supported only by volunteer's funds. A significantly bloated up debian mirrors can make their life more difficult. Things can be worse if they the uploading bandwidth is limited of even metered. I was one of such hosts. I know, this is a difficult trade-off between Debian's accessibilty and software performance. > > And, xz cannot use multi core CPUs for decompression but zstd can. > > It means that if we use xz, we just get 2x CPU power, but change > > to > > zst, > > we can get more than 10x CPU power than 2012. > > In ideal conditions, maybe, but still, thats the first (to me) good > reason. IMO not good enough to actually do it. > > > - Not sure how repository size will be, need an experiment > > And keep in mind the repository is mirrored a trillion times, stored > in > snapshots, burned into images here and there, so any "small" increase > in > size actually means a *huge* waste in the end. > > If we switch formats, going to something that's at least as good as > the > one we currently have should be the goal. (And I do not mean > something > like "its code/algorithm is bad", really, that argument is dead > before > it begins even). > > Now, thats for .debs. There might be a better argument when talking > about the index files in dists/, they are read so much more often, it > *may* make more sense there. >
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Just one comment.
Be careful if it bloats up our mirrors. Is there any estimate on
the extra space cost for a full debian mirror?
If we trade-off the disk space with decompression speed, zstd -19
is not necessarily very fast. I did not benchmark, but it is slow.
On Sat, 2023-09-16 at 10:31 +0530, Hideki Yamane wrote:
> Hi,
>
> Today I want to propose you to change default compression format in
> .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
Re: bookworm+½ needed (Arc GPUs, ...)
Intel is also slow in upstreaming their SYCL implementation to LLVM upstream. So that there is still a very far way to go towards the pytorch variant that can use intel ARC GPU. On Mon, 2023-09-11 at 12:47 +0200, Adam Borowski wrote: > So... > If you've watched our Dear Leader's talk, a prominent problem listed > was problems with new graphics cards. > > While he didn't elaborate, I assume it was about Intel Arc -- ie, new > DG2 > discrete GPUs. And the problem is, proper support didn't hit the > kernel > until after 6.1. You can kinda-sorta run on 6.1 by whitelisting it > by PCIe > ID on the kernel cmdline, and it even works (6.0 couldn't cope with > my > setup, 6.1 was ok), but such an intentional block doesn't suggest > it's > something wise for a normal user to do. > > I'm not sure if firmware shipped with Bookworm is good enough, either > (having grabbed a copy of the files much earlier, would need to > test). > > Of course, this wasn't Debian's fault. The group at Intel > responsible > for upstreaming kernel/etc bits was too slow, not providing drivers > until > after the hardware has already been shipping to regular non-NDAed > customers. > > But then, hardware makers do this all the time. Intel Arc just gives > a > more prominent reason to have an installer with backported > kernel+stuff. > > Before we go and bother the relevant folks (or maybe even do part of > the > work ourselves...), could someone name other pieces of hardware that > would > be wanted for Bookworm+½? > > > Meow?
Re: Default font: Transition from DejaVu to Noto
On Sun, 2023-09-10 at 11:23 +0800, Paul Wise wrote: > On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote: > > > My personal view is that it is a change in the right direction, and > > I > > have taken a couple of follow-up steps in Debian. There are still > > loose > > ends and more work to be done to achieve a consistent configuration > > in > > this respect. However, before taking further steps, I feel there is > > a > > need to reach out to a broader audience about the change. Hence > > this > > message. Basically I'm asking if this move towards Noto is > > desirable > > and, if so, I plea for relevant input for the completion of the > > transition. > > Personally, I found Noto Mono to be very ugly in comparison to the > DejaVu fonts that I was used to, so my knee-jerk reaction was to > override the fontconfig settings to avoid all of the Noto fonts. > I haven't yet evaluated the non-monospace Noto fonts though. > > Related discussion on the various IRC channels suggested that: > > Noto is meant to be a fallback font (something like unifont but > not using bitmaps) not the default font for all or any languages. > > Noto makes the font selector useless because each alphabet shows up. > Apparently fixing this requires changing the OpenType file format. > > Apparently the Noto meta package installs 700+ MB of font data, > which seems a bit excessive to some folks. > > Some folks are setting explicit fonts in applications they use to > avoid > relying on system defaults and also seeing changes to those defaults. > I have similar personal feelings. Aesthetic matter differs from person to person. As font can be seen as kind of artwork, can we make a pool for the default font just like our wallpaper? Noto is usually annoying to me. It provides too many "Noto .*" fonts in whatever software which shows you a font selection menu. It is likely that at least 1/3 of the whole fonts menu will be overwhelmed by the Noto .* fonts that I'll never use, even if I only keep fonts-noto-core and fonts-noto-cjk. The number of fonts is overwhelming especially when I frequently change the font in software like libreoffice, inkscape, etc. I usually end up deleting the ttf files that I will never need. Just a negative vote on Noto. Anything else is better.
Bug#1051520: ITP: python-expecttest -- expect test for python
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-expecttest * URL : https://github.com/ezyang/expecttest/ * License : MIT Programming Lang: (python Description : expect test for python Unit testing package for pytorch packages. Will be maintained by debian deep learning team. Thank you for using reportbug
Bug#1050308: ITP: golang-github-seancfoley-bintree -- Golang library Binary trees and tries
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: golang-github-seancfoley-bintree * URL : https://github.com/seancfoley/bintree * License : Apache2 Programming Lang: Go Description : Golang library Binary trees and tries Transitive dependency for kitty
Bug#1042861: ITP: git-credential-azure -- A Git credential helper for Azure Repos
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: git-credential-azure Version : 0.1.0 * URL : https://github.com/hickford/git-credential-azure * License : Apache2 Programming Lang: Go Description : A Git credential helper for Azure Repos git-credential-azure is a Git credential helper that authenticates to Azure Repos (dev.azure.com). Azure Repos is part of Azure DevOps.
Bug#1039471: ITP: golang-github-azuread-microsoft-authentication-library-for-go -- allows you to sign in users or apps with Microsoft identities (Azure AD and Microsoft Accounts) and obtain tokens to
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: golang-github-azuread-microsoft-authentication-library-for-go Version : 1.0.0 * URL : https://github.com/AzureAD/microsoft-authentication-library-for-go * License : MIT Programming Lang: Go Description : allows you to sign in users or apps with Microsoft identities (Azure AD and Microsoft Accounts) and obtain tokens to call Microsoft APIs such as Microsoft Graph or your own APIs registered with the Microsoft identity platform
Re: opencl-icd virtual package(s)?
On Sun, 2023-06-18 at 10:37 +0800, Paul Wise wrote:
> [BCCed to OpenCL ICD implementation package maintainers]
>
> I noticed that some packages have a dep on specific OpenCL ICD
> packages, but don't dep on the opencl-icd virtual package(s).
> Presumably any of the OpenCL ICDs work for most packages?
Theoretically any of them is expected to work. That's the point of ICD.
But, while I'm not an OpenCL user, I have heard that different OpenCL
implementations have their own quirk... (forgotten source)
> $ grep-aptavail --no-field-names --show-field Package --field
> Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
> and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'
>
> In addition, I noticed that hashcat-nvidia (which presumably doesn't
> need to depend on the opencl-icd virtual package) only depends on two
> of the nvidia OpenCL ICD packages, while there are lots of other nvidia
> OpenCL ICD packages that presumably work too.
It won't surprise me if .*-nvidia fails to work with a non-nvidia OpenCL
implementation.
> I have attached a package list and dd-list for these issues.
>
> Perhaps there should be a default-opencl-icd virtual package?
Usable OpenCL implementation is very device specific. We cannot make
sure what OpenCL implementation will always be avaialble on user devices,
and even our buildd.
If there must be a default, pocl-opencl-icd is the solution. It supports runing
OpenCL kernels on CPU, so it should be working on most hosts.
Just don't expect any higher performance from CPU-based OpenCL.
FYI: to verify what OpenCL is usable on your host, you may just
$ sudo apt install clinfo; clinfo
> Perhaps lintian should flag situations where the dep isn't just
> default-opencl-icd | opencl-icd? or is missing opencl-icd?
>
> Thoughts?
I think the current status for some typical packages, like python3-pyopencl
is already correct.
$ apt show python3-pyopencl
Depends: ..., pocl-opencl-icd | mesa-opencl-icd | opencl-icd, ...
You see pocl there as the first choice. For any other packages
that depend on opencl, I think maintainers might have an idea
on what opencl implementation is preferred, either inclusively
or exclusively.
> PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
> only OpenCL ICD implementation package I can see that supports Intel
> Ivy Bridge, but it is hard to tell which other packages support this,
> because some descriptions don't mention which hardware is supported.
It looks the intel-opencl-icd does not support very old CPUs,
(as listed here https://github.com/intel/compute-runtime )
but I think most major users of OpenCL depends on dedicated GPUs.
The performance of integrated graphics seems no different than nothing.
I think all OpenCL ICD providers can be found by $ apt search opencl-icd .
The AMD opencl implementation is missing.
It is a part of ROCm (https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime
),
and indeed something to work on for the ROCm team in the
future.
Bug#1038326: ITP: transformers -- State-of-the-art Machine Learning for JAX, PyTorch and TensorFlow (it ships LLMs)
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: transformers Upstream Contact: HuggingFace * URL : https://github.com/huggingface/transformers * License : Apache-2.0 Description : State-of-the-art Machine Learning for JAX, PyTorch and TensorFlow I've been using this for a while. This package provides a convenient way for people to download and run an LLM locally. Basically, if you want to run an instruct fine-tuned large language model with 7B parameters, you will need at least 16GB of CUDA memory for inference in half/bfloat16 precision. I have not tried to run any LLM with > 3B parameters with CPU ... that can be slow. LLaMa.cpp is a good choice for running LLM on CPU, but that library supports less models than this one. Meanwhile, the cpp library only supports inference. I don't know how many dependencies are still missing, but that should not be too much. Jax and TensorFlow are optional dependencies so they can be missing from our archive. But anyway, I think running a large language model locally with Debian packages will be interesting. The CUDA version of PyTorch is already in the NEW queue. That said, this is actually a very comprehensive library, which provides far more functionalities than running LLMs. Thank you for using reportbug
Bug#1033345: ITP: nvitop -- An interactive NVIDIA-GPU process viewer and beyond
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: nvitop * URL : https://github.com/XuehaiPan/nvitop * License : Apache-2.0 / GPL-3.0 dual license Programming Lang: Python Description : An interactive NVIDIA-GPU process viewer and beyond We have a couple of nvidia GPU utility monitors. Nvidia's nvidia-smi is standard but far not readable enough for heavy GPU users like me. I packaged gpustat -- it is good, but it does not show the standard top informantion, and as a result I have to open another tmux window for glances or htop, in order to make sure the neural network does not blow up the system memory. This nvitop just combines both gpu monitoring and CPU/ram monitoring. Have used it for a while on GPU servers. It cannot be better. This package will be maintained under the umbrella of the nvidia packaging team. I suppose the package has to enter contrib because it depends on the non-free nvidia driver. Thank you for using reportbug
Re: Adding epoch to kworkflow package to correct a wrong upstream version
Am 12. März 2023 19:13:46 MEZ schrieb Peter Wienemann : >Dear IOhannes, > >On 12.03.23 18:48, IOhannes m zmölnig wrote: >> Could lintian warn when a date based version is used? > >Lintian already does this - see [0]. Ah. Thx. Praise to the lintian maintainers then, and sorry for not doing all the background research myself (but I'm currently afk) mfh.her.fsr IOhannes
Re: Adding epoch to kworkflow package to correct a wrong upstream version
Am 12. März 2023 15:58:00 MEZ schrieb Simon McVittie : >On Sun, 12 Mar 2023 at 09:15:35 +0100, Tobias Frost wrote: >> >> > Version 20191112-1.2 was created because the upstream had no official >> > release at that time; for this reason, the 20191112-1.2 was created and >> > named based on a date. > >In future, please use a lower version number when packaging unreleased >software. A version starting with an 8-digit date is almost guaranteed >to compare greater than whatever upstream eventually chooses, Could lintian warn when a date based version is used? (I haven't checked how many upstreams use date-based versions intentionally and fully aware of the consequences, but I think the problem appears mostly if upstream does not do any formal releases at all, so the package maintainer concocts some arbitrary version number on their own) mfh.her.fsr IOhannes
Re: Unlock LUKS with login/password
On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov wrote: > > > On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC wrote: > >> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit : >> >> Hello! >> >> I have an idea about how modern linux should work with encrypted LUKS >> partitions. >> >> Hi, >> >> I'm using LUKS for a long time on both my personal (desktop) and >> professional (laptop) computers. Since they are single user (me), I use >> autologin in the display manager, lightdm in my case. Because there is only >> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin >> safely. >> >> However, you are proposing to solve the case for multiple user computers. >> In that case, I would think about a much simpler design: >> >> - Remember which slot was used to unlock the LUKS root partition >> >> - Make a map with slot -> user to autologin >> >> - Autologin that user on boot >> >> No more passing password, no more password update headache. But only a >> root user can update the map "slot -> user". >> >> Adrien >> > Right. But you still have to remember passpharse and your main account > password. This is not about autologin. This is about unlocking your machine > LUKS with only login/password without having an additional passphrase to > remember. > The reason you can not use Login/Password as the LUKS passphrase is because The Passphrase can not be different for different users. The passphrase is not simply a password but instead it is part of the key material used to decrypt and encrypt. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Grub Password configuration during install
All, Would it be possible to add a section to the installer when Grub is being installed and configured to configure a grub password? Thanks Tim -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Bug#1031973: ITP: nvidia-cutlass -- CUDA Templates for Linear Algebra Subroutines
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-cutlass * URL : https://github.com/NVIDIA/cutlass * License : BSD-3-Clause (has to enter contrib due to non-free deps) Programming Lang: C++ Description : CUDA Templates for Linear Algebra Subroutines This is needed for the cuda version of pytorch. The package will be maintained by Debian NVIDIA Maintainers
Bug#1031972: ITP: nvidia-cudnn-frontend -- c++ wrapper for the cudnn backend API
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-cudnn-frontend * URL : https://github.com/NVIDIA/cudnn-frontend * License : MIT (but will enter contrib due to non-free deps) Programming Lang: C++ Description : c++ wrapper for the cudnn backend API This is needed for the cuda version of pytorch. The package will be maintained by Debian NVIDIA Maintainers
Bug#1031565: ITP: nvidia-nccl -- Optimized primitives for collective multi-GPU communication
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-nccl * URL : https://github.com/NVIDIA/nccl * License : BSD-3-Clause but has to enter non-free. Programming Lang: C/C++ Description : Optimized primitives for collective multi-GPU communication This is needed for some cuda applications like pytorch-cuda. The package will be maintained by Debian NVIDIA Maintainers
Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
Am 1. Februar 2023 01:30:10 MEZ schrieb Dan Jacobson : >So he must do Google Search. Do you think this problem only affects make users? mfh.her.fsr IOhannes
Re: Populating non-free firmware?
On Sat, Dec 24, 2022 at 12:15 PM M. Zhou wrote: > On Sat, 2022-12-24 at 11:44 +0200, Jonathan Carter wrote: > > > > The non-free-firmware [component] has been created, but so far it > > only > > contains the rasbpi-firmware package. > > Please ensure to include the packages for wifi cards, especially > the iwlwifi since I don't use desktop pc. > > One of the most painful ways to install Debian is to realize that > iwlwifi is missing during the netinstall process, while RJ45 cable > is not available. As a result, one may download the package using > cellphone and find a way to transmit that file to the laptop. > If it's iphone then game is sadly over. > > In the past, such frustration had once irritated one of the new > users to whom I have recommended Debian. The user's anger has > finally converted into personal/emotional attacks, blaming > me as a Debian developer being incompetent to make the wifi > card working. As a result, I as a Debian developer, would never > recommend Debian to any new user, nor discussing linux with > any new user since then. > > iwlwifi is the very only reason that forced me to never use the > the default iso again. > > That said, my word only counts as a vote for the wifi card packages. > Just wanted to mention that iwlwifi may hurt people. > > I agree WiFi is needed. I have Realtek and it needs non-free firmware. I also need the binary blobs for AMD Radeon. I use the non-free installer. If not all firmware is going to be included in the installer will there still be a non-free installer image? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Populating non-free firmware?
On Sat, 2022-12-24 at 11:44 +0200, Jonathan Carter wrote: > > The non-free-firmware [component] has been created, but so far it > only > contains the rasbpi-firmware package. Please ensure to include the packages for wifi cards, especially the iwlwifi since I don't use desktop pc. One of the most painful ways to install Debian is to realize that iwlwifi is missing during the netinstall process, while RJ45 cable is not available. As a result, one may download the package using cellphone and find a way to transmit that file to the laptop. If it's iphone then game is sadly over. In the past, such frustration had once irritated one of the new users to whom I have recommended Debian. The user's anger has finally converted into personal/emotional attacks, blaming me as a Debian developer being incompetent to make the wifi card working. As a result, I as a Debian developer, would never recommend Debian to any new user, nor discussing linux with any new user since then. iwlwifi is the very only reason that forced me to never use the the default iso again. That said, my word only counts as a vote for the wifi card packages. Just wanted to mention that iwlwifi may hurt people.
Re: looking for debian friendly web app technology
On Thu, Dec 15, 2022 at 8:51 AM Alastair McKinstry < alastair.mckins...@sceal.ie> wrote: > Hi, > > Is Qt6-base not in testing, for bookworm? I've an app (metview) that I > switched over Qt5->Qt6, should I move it back? > > Bookworm currently has Qt 6.3.1 and 6.4.0 packaged. > regards > > Alastair > > On 13/12/2022 20:27, Andreas Josef Heil wrote: > > Well qt5 is fine too. I don't need fancy features. I will make a kde app. > > > > On 13.12.22 05:22, Imre Nagy wrote: > >> The downside of these things, that current Debian does not seem to > >> include Qt6 at all and I have no idea when it can go into the > >> mainstream Debian, while there are a lot of project could be waiting > >> for it. (Even my one is still pending for Debian). Qt6 for Debian is > >> still in unstable/experimental state, which drives the developers > >> like me to find other alternatives instead of Debian or for Debian. > >> > >> Best regards, > >> Imre > >> > >> 2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta: > I wrote too early sry. A desktop app is also possible. I will use qt. > > > -- > Alastair McKinstry, > GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 > ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: looking for debian friendly web app technology
On Tue, Dec 13, 2022 at 12:51 AM Imre Nagy wrote: > Hi, > > What do we think about "accessibility" in this thread? The MSAA like > helping for visually challenged, or the global avaiblity (and > acceptance) of QT? > > As of Qt 5.15, (and Qt 6.4.x lately) you do not have to make the hard > choice between responsive webpage or desktop application, since you can > generate both from the same QT source code. The native is native, the > browser based using WebAssembly technology. (I think MSAA is not yet > supported for WebAssembly till this date, but please double check this > information!) > > The downside of these things, that current Debian does not seem to > include Qt6 at all and I have no idea when it can go into the mainstream > Debian, while there are a lot of project could be waiting for it. (Even > my one is still pending for Debian). Qt6 for Debian is still in > unstable/experimental state, which drives the developers like me to find > other alternatives instead of Debian or for Debian. > > Qt 6 will not be in debian until debin 13. Bookworm will still have Qt 5 and KDE 5. You can manually download and install Qt6 on Debian. If you target Debian 13 for inclusion of your app that will give you about two years to finish it. > Best regards, > Imre > > 2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta: > >> I wrote too early sry. A desktop app is also possible. I will use qt. > >> Thanks for your time. > > > > QT accessibility has improved a lot, but I suspect that a single page > > web app with vuejs and a good widget set on top of that is going to be > > more accessible than a QT app even today. > > I find I stumble less with web app accessibility than I do with linux > > desktop accessibility, although both are usable. > > > > > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote: > ]] Robie Basak > > > But are you in essence saying that libpam-tmpdir requires that *every > > maintainer script* that runs things as non-root, or starts processes > > that do that, unset TMPDIR first? > > I think it's more wide than that: If you change UID, you need to > sanitise the environment. Your HOME is likely to be wrong. PATH might > very well be pointing at directories which are not appropriate for the > user you're changing the UID to, etc. I believe this is the best practice. For example, sudo typically passes through only a handful of environment variables, such as TERM, to avoid things like insecure PATH entries. For example, if MySQL invoked a binary in PATH and I had a custom script named the same thing that had insecure behaviour when invoked as another user, that would be bad. OpenSSH also sanitizes the environment passed over the connection. Without getting into a debate about systemd, this is one the pieces of functionality it provides, since it runs binaries in a clean environment. You can probably get most of that in a sysvinit script by using `env -i` with a handful of environment variables specifically overridden if necessary. Then it would be very obvious what dependencies the binary had on the outside environment. > > I think the answer to this should probably be established by the > > libpam-tmpdir maintainer and documented first, for fear of someone else > > later coming along and saying that the maintainer script incorrectly > > ignores TMPDIR because we started ignoring it to resolve this bug. So I > > copied debian-devel@ for comment. > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > general: what are the expectations that maintainer scripts can have > about the environment they're running in, and how do we make those > expectations hold? This should probably then be documented in policy. I agree documentation here is helpful. For reference, this was an invocation from `sudo aptitude` as part of a normal package upgrade, which I think is a relatively common situation to be in. Possibly also an initscript helper which enables developers to do the right thing automatically, or a flag to start-stop-daemon, or other tooling would be beneficial to help people easily solve this problem without thinking too much about it. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: > > contributing work. In some sense, contributing to Debian becomes > mostly > about waiting. (Sure, there is something to be said about extremely > short, fragmented attention spans being unhealthy – but some > contributions are naturally short and easy, and we certainly don't > want > to drive those away.) That's why I still hope ftp team to recruit more people. This is a very direct and constructive way to speed up everything. More volunteers = higher bandwidth. Recruiting more people doesn't seem to have a serious disadvantage. In my fuzzy memory, the last discussion on NEW queue improvement involves the disadvantages by allowing SOVERSION bump to directly pass the NEW queue. I'm not going to trace back, because I know this will not be implemented unless someone proposes a GR. > > If one's enthusiasm on working on some package is eventually > > worn out after a break, then try to think of the following > > question: > > > > Is it really necessary to introduce XXX to Debian? > > I hope we won't try to define what "necessary" means, or have it > become > a criterion for inclusion :-) > > > Must I do this to have fun? > > I don't think Debian contribution has ever been a necessary condition > for fun. That's an incredibly high bar. If we were only to attract > people whose only idea of fun was contributing to Debian, I think > we'd > become a very unhealthy project (and one severely lacking in > contributors). For newcomers, a long wait wears out their interest of course. I'm not sure what would be the reason for a potential newcomer to reach us if they do not find contributing this project "fun/interesting", or "worthwhile/useful". For people who chose to stay in this community, there must be a reason behind them. Because I believe no body can contribute to a volunteer project without payment / fame / enjoyment. Without such a high bar, the member list will be much more volatile. > > Strong motivations such as "I use this package, seriously" are not > > likely to wear out very easily through time. Packages maintained > > with a strong motivation are better cared among all packages in our > > archive. > > I humbly disagree. Even from my own point of view, I may well be very > motivated to package something I use seriously all the time, > seriously. But then I see its dependency chain of 10 unpackaged > items, > start thinking about the probability that they'll *all* clear the NEW > queue, and how long that would take, and I give up. And then there's > the > problem of attracting smaller contributions, as mentioned above: I > really believe that people get put off from putting in 30 minutes of > work for a nice MR on Salsa if they can't expect their work to hit > the > archives for months and months (suppose for example they contributed > to > a package whose SONAME is being bumped). I agree with your disagreement but I keep my opinion. My track record involves maintaining loads of reverse dependency libraries. I've already gone through all kinds of pains from the NEW queue and eventually learned to take a break immediately after uploading something to new. That said, if someone presents a GR proposal I'll join. In Debian, it is not that easy to push something forward unless it hurts everyone. Our NEW queue mechanism has been there for decades, and people are already accustomed to it (including me). From multiple times of discussion in the past, I don't see the NEW queue problem hurting too many people. If nothing gets changed in the NEW queue mechanism, people may gradually get used to it, following the "do not fix it if it ain't wrong" rule. The voice will gradually vanish. This is surely unhealthy. But as an individual developer I don't find many feasible ways to push things forward unless someone figure out a reason that as many people feel hurt about it as possible. > > Why not calm down, and try to do something else as interesting > > as Debian development when waiting for the NEW queue? > > Sure. That's what I do. My list of joyful and less joyful things to > fill > my days with is enormous. **BUT: I worry for the project if our > solution > to the problem at hand is "maybe just contribute less to Debian".** > Is > that really what we want? > I forecast this thread will eventually end up with "calm down and take a break" solution again.
Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
To be honest, in terms of volunteered reviewing work, waiting for several months is not something new. In academia, it may take several months to years to get a journal paper response. I've ever tried to think of possible ways to improve the process, but several observations eventually changed my mind, and I'm willing to accept the status quo. * there is a trade-off between rigorousness and efficiency. Any change in the process may induce disadvantages, where the most difficult thing is to reach an agreement. * we will add more work for ftp team if we get them involved in the discussion of possible (but unsure) ways to improve NEW. My ultimate opinion on NEW processing is neutral, and my only hope for ftp team is to increase the pace of hiring new members. To be concrete, it is much harder to write a concrete proposal to debian-vote@l.d.o than discussing possibilities. I understand we may have the enthusiasm to sprint on something. However, in terms of the long-term endeavor on Debian development, the negligible popcon number won't be less disappointing than a long-term wait to clear the NEW queue. If one's enthusiasm on working on some package is eventually worn out after a break, then try to think of the following question: Is it really necessary to introduce XXX to Debian? Must I do this to have fun? Strong motivations such as "I use this package, seriously" are not likely to wear out very easily through time. Packages maintained with a strong motivation are better cared among all packages in our archive. Why not calm down, and try to do something else as interesting as Debian development when waiting for the NEW queue? Or simply think of NEW queue as a Debian holiday application. I just realized these over the years, and these are only my personal opinion. On Fri, 2022-08-26 at 09:18 +0200, Gard Spreemann wrote: Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) > > On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" > > wrote: > > > PS: To preempt any questions as for why, the background for my > > > decision > > > to stop maintaining any packages is this thread, but it's really > > > just > > > the straw that broke the camel's back > > > > > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > > > > > > > A bit off-topic, but I think we really ought to discuss (address?) > > this elephant in the room once more. I don't have the answers, but > > Sebastian's email yet again clearly illustrates how the status quo > > is hurting the project. This clear example comes in addition to > > worries raised before about what the status quo does to recruitment > > of new developers. > > > > PS: I do not imply that the elephant in the room is the > > ftpmasters. I'm thinking of the *process*. The people involved put > > in admirable work in carrying out said process. > > The way I see it, the process is clear: provide *source* to build > from. > > If there is "source" built from another source, then that other > source > is the true source. > > If ftpmasters sometimes approve intermediary works as source, then > that > is not a reason to complain that they are inconsistent - it is a > reason > to acknowledge that ftpmasters try their best just as the rest of us, > and that the true source is the true source regardless of misssing it > sometimes. > > Yes, this is painful. Yes, upstreams sometimes consider us stupid to > care about this. Nothing new there, and not a reason to stop do it. > > If you disagree, then please *elaborate* on what you find sensible - > don't assume we all agree and you can only state that the process is > an > elephant. Apologies, I should have been a lot clearer. I did not mean the exact issue of what is the "true source" of something in a package. Rather, I was referring to the process itself (looking in particular to the last three paragraphs and the PS in Sebastian's linked email [1]). Whatever the correct answer to what a "true source" is, in the current process, a developer has to make an attempt at doing the right thing, and then wait *weeks or possibly months* to know for sure whether it was OK. And if it's deemed not OK, the reasoning may be entirely specific to the exact package and situation at hand, and therefore extremely hard to generalize and to learn from. (Do not construe the above as "ftpmasters should work faster and give more lengthy reasoning!" – adding *more* work to the process would make things even worse in my opinion.) Although I maintain a very small number of packages, and ones that also very rarely have to re-clear NEW, even I feel sapped of motivation from the process. And I read Sebastian's email partly as an expression of the same thing (apologies if I misconstrue your views, Sebastian). I do believe similar points of view have been aired on the list before by others too. As to your last point, elaborating on what I find sensible: I sadly don't have a
Re: Automatic trimming of changelogs in binary packages
On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > * The `--no-trim` option allows package maintainers that want to ship > the whole changelog a way to do so. > > * The full changelogs are preserved in the source packages and thus > available via `apt changelog` and similar mechanisms. > > Does anybody have objective objections against activating automatic > changelog trimming in binary packages? Thank you for working on this. My original concern about automatically trimming logs was about convenience of debugging -- I sometimes need to search among the full history to see what happened to the package of interest in the past, or to quickly figure out what change has been made at what time. Since `apt changelog` can still retrieval the full history, my concerns are gone.
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Sat, Jul 16, 2022 at 10:19 PM Guillem Jover wrote: > Hi! > > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > project and does see releases (even though with a long cadence). > > This has been discussed somehow in #982253 and #987729. > > These packages currently use a pair of virtual packages to denote > that they are a telnet or telnetd implementation (telnet-client and > telnet-server). One problem is that currently the netkit implementations > use the generic telnet and telnetd package names, which is a clear way > to mark them as the default implementations (instead of say the other > convention of naming or providing a default-foo package). Another is > that several packages depend on these generic names instead of the > virtual packages, see below for a list that would deserve a non-blocking > "mass" bug filing, which I can handle as part of the switch. > > The inetutils-telnet recently got support for the missing «-b» option > for compatibility with netkit-telnet. > > The inetutils-telnetd and netkit-telnetd have diverging options and some > conflicting ones, but after pondering about it I don't think this should > be a major issue, as the daemon does not tend to get called by users from > scripts and similar. For completeness the divergences are these: > >inetutils-telnetd netkit-telnetd >- -- >short and long options short options > -D (unimplemented «exercise» mode) >-D (debug modes «auth», «encr») -edebug >-S, --server-principal -S (used to set the IP TOS) >-E, --exec-login-L >-l, --linemode >-U, --reverse-lookup-N (related but not exactly the same) > > > Simon Josefsson (CCed), who is one of the inetutils upstream maintainers, > recently adopted the netkit-telnet source package in Debian, which he'd > prefer to keep around for a smoother transition period, in case users > want or need to revert back. > > > > So, the idea would be for src:inetutils to take over the telnet and > telnetd binary packages and make them transitional packages depending > on the inetutils variants, for a smooth upgrade, and in addition also > start providing them by the inetutils- packages. > > The src:netkit-telnet would then switch to ship netkit-telnet and > netkit-telnetd binary packages (this would ideally be uploaded to > experimental first, so that once ACCEPTED it can be uploaded to sid > once we start the switch, with no missing implementation in between). > > I'm inclined to do it in this order to potentially avoid two trips over > NEW, and to reduce any potential disruption period. > > In the future (after the next stable release) the telnet/telnetd > packages could be switched to be pure virtual packages, taking the role > of denoting the current default implementation, instead of introducing > default- variants, as that's what users are currently used to, and > it would keep working even if the depending packages below do not update > their dependencies. > > We'd file an override request against ftp.debian.org to get the > inetutils-telnet Priority bumped to standard to match the current > telnet package (which could get then its Priority lowered to optional). > > Currently inetutils and netkit have the same alternative priority > for telnet, I'd probably bump it also to 150 for inetutils to take > precedence. > > > If there are no objections, we could probably start working on this > switch in a couple of weeks or so. > > > > List of packages depending on telnet (but not telnet-client): > > forensics-extra (Depends) > lava (Depends) > live-task-standard (Depends) > mininet (Depends) > vland (Depends) > zssh (Depends) > > dish (Recommends against all current implementations) > lava-dev (Recommends) > lava-dispatcher (Recommends) > live-task-extra (Recommends) > pdudaemon (Recommends) > > libtelnet-dev (Suggests) > libtelnet-utils (Suggests) > procserv (Suggests) > ser2net (Suggests) > tucnak (Suggests) > > List of packages depending on telnetd (but not telnet-server): > > telnetd-ssl (Conflicts) > nyancat-server (Conflicts) > > > Thanks, > Guillem > > Telnet is old, insecure and should not be used any more. What is the point of packaging a Telnet daemon when everyone should be using SSH. Telnet Client I can see because a person may need to connect to a router or switch that is still using telnet or hasn't had SSH Certificates generated yet. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Bug#1014661: ITP: lodepng -- LodePNG is a PNG image decoder and encoder
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lodepng Version : git master Upstream Author : Lode Vandevenne * URL : https://lodev.org/lodepng/ * License : Zlib Programming Lang: C Description : LodePNG is a PNG image decoder and encoder More than one package of my insterest has this dependency, including the mujoco physics simulator. Thank you for using reportbug
Re: needs suggestion on LuaJit's IBM architecture dilemma
>From the buildlogs / testlogs / local tests (ppc64el qemu), it seems that there is completely no improvement for ppc64el. Simple scripts can still encounter segmentation faults (e.g., autopkgtest for src:lua-moses). s390x is newly enabled. I still have not seen enough test log to give any preliminary conclusion. On Thu, 2022-06-09 at 16:19 +0200, Frédéric Bonnard wrote: > Hi Mo, Paul, > did you see any improvement with luajit2 ? > I was looking at luakit, which still fails "silently" on ppc64el, a lua > script generating a .h with no symbols with luajit2, where it does work > with lua. > Also I see that the autopkgtest of knot-resolver still fails on > ppc64el. > > F. > > On Thu, 19 May 2022 22:14:01 -0400 "M. Zhou" wrote: > > On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > > > Hi, > > > > > > I've followed luajit closely since 2015 on ppc64el as a porter > > > without enough knowledge to port it, but trying to ease on the > > > packaging/Debian side (being both IBMer/DD). > > > That port has been a mixed effort between a code bounty and an IBM > > > effort (some devs) . > > > It didn't started well ( > > > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > > > and it has never grown and be really part of the upstream project > > > sadly. > > > > > > With the years, I'm even less optimistic as no IBM nor external > > > developer seem to be working on that. Mike Pall seems to be around > > > though as you said there's no release (not necessarily a bad sign). > > > I can ping inside IBM but I'm not sure there will be any positive > > > feedback. > > > > > > So I'd say we have no choice, i.e. let's drop IBM arches . > > > What I did a few times for packages depending on libluajit was to use > > > liblua instead : > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > > > > > Thanks, > > > F. > > > > Nobody want to spend time on an bottomless hole ... > > I'll simply remove ppc64el architecture support from src:luajit, > > and give src:luajit2 (openresty) a try. > >
Re: How to handle packages which build themselves with bazel?
Hi David, Debian has a group of people working on bazel packaging. https://lists.debian.org/debian-bazel/2022/06/threads.html And bazel itself has been a years-long pain for tensorflow packaging. I'm not following the updates for bazel packaging, but you may browse the packaging work of the corresponding team to see whether there is anything you are interested in: https://salsa.debian.org/bazel-team/bazel On Wed, 2022-06-08 at 17:18 +0200, David Given wrote: > I'm looking into converting some of my upstream packages to use Google's > bazel build system, because it makes life > much easier as a developer. > > Unfortunately, with my other hat on, it makes life much harder as a package > maintainer: bazel is very keen on > downloading source packages and then building them locally, resulting in a > mostly-statically-linked executable. > protobuf is the most obvious culprit here, because if you do anything with > Google's ecosystem you inevitably end up > using protobufs, and as soon as you refer to a cc_proto_library rule in bazel > you get a statically linked libprotobuf. > > Are there any known best practices yet in Debian on how to persuade bazel not > to do this, and to use the system one > instead? >
Re: how to convey package porting details?
I like this idea. I would personally recommend adding negative priority as well. You know, it is completely meaningless to port some high performance scientific computing software to archs like armel... Meanwhile, different packages varies in the difficulty to port as well. A software that heavily leverages architecture specific intrisics is not likely easy to port. Packages that does not require hardware performance, and simply misses several arch-specific C macros should be easy to port. Since package maintainers should have somehow skimmed the whole codebase, they could provide an accurate hint about this, as long as such hints are useful for porters. On Mon, 2022-06-06 at 10:02 +0800, Paul Wise wrote: > > There are lots of packages that need porting to every new architecture > that comes along. There are others that don't require porting but > benefit in some way from porting to some aspect of the architecture. > > In order to help porters to prioritise those packages and quickly add > support for their architecture, it would be nice to have a standard > mechanism for source packages to indicate that they potentially require > porting for each new architecture, the nature of the porting required > and where in the source package the changes are required. > > For example packages like autotools-dev, linux, gcc or linuxinfo could > state that they require porting to all new arches and have a pointer to > Debian and or upstream porting info. Packages containing a JIT but with > interpreter fallback could list themselves as having optional porting. > > Once we have a mechanism for this, the documentation for creating new > Debian ports could provide a way to find the list of packages that need > porter attention; via codesearch.d.n, apt, apt-file, grep-available etc. > > https://wiki.debian.org/PortsDocs/New >
Bug#1011667: ITP: mujoco -- A general purpose physics simulator.
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mujoco Version : 2.2.0 Upstream Author : DeepMind * URL : https://mujoco.org/ * License : Apache-2.0 Programming Lang: C Description : A general purpose physics simulator. I plan to maintain this under Debian Deep Learning Team.
questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
I wonder why an irrelevant package suddenly triggered autoremoval of a very large portion of packages from testing. https://udd.debian.org/cgi-bin/autoremovals.cgi Searched for keyword nvidia-graphics-drivers-tesla-470, and I got 68866 entries. There must be something wrong. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=nvidia-graphics-drivers-tesla-470 Looking at the bug report of the package itself, and it does not look like glibc package is made broken by it. Any idea?
Bug#1011460: ITP: gnome-shell-extension-flypie -- an innovative marking menu written as a GNOME Shell extension
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gnome-shell-extension-flypie Upstream Author : Simon Schneegans * URL : https://github.com/Schneegans/Fly-Pie * License : MIT/X Programming Lang: Javascript Description : an innovative marking menu written as a GNOME Shell extension Generally I don't like packaging fancy stuff for Debian. But this literally surprised me, and brings me a very familiar feeling for game menus designed for quick operation. If you are a gamer who like recent action games a lot, I think you may like this extension as well. Basically the marking menu is to pop up a circle-shaped menu, where selection is made by the mouse position relative to the circle center upon key release. And it has got an achievement system like games... LOL
Re: needs suggestion on LuaJit's IBM architecture dilemma
On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > Hi, > > I've followed luajit closely since 2015 on ppc64el as a porter > without enough knowledge to port it, but trying to ease on the > packaging/Debian side (being both IBMer/DD). > That port has been a mixed effort between a code bounty and an IBM > effort (some devs) . > It didn't started well ( > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > and it has never grown and be really part of the upstream project > sadly. > > With the years, I'm even less optimistic as no IBM nor external > developer seem to be working on that. Mike Pall seems to be around > though as you said there's no release (not necessarily a bad sign). > I can ping inside IBM but I'm not sure there will be any positive > feedback. > > So I'd say we have no choice, i.e. let's drop IBM arches . > What I did a few times for packages depending on libluajit was to use > liblua instead : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > Thanks, > F. Nobody want to spend time on an bottomless hole ... I'll simply remove ppc64el architecture support from src:luajit, and give src:luajit2 (openresty) a try.
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Dipack, I filed an ITP bug for luajit2 and will look into it. Thank you! On Mon, 2022-05-16 at 16:22 +, Dipak Zope1 wrote: > Hello all, > It'd be better to switch to luajit2 if it is possible. We can see > right now the main issue with luajit project is no response from > upstream of LuaJIT to previous merge request attempts. And luajit2 > already contains almost everything needed for s390x support. > > Thanks, > -Dipak >
Bug#1011320: ITP: luajit2 -- OpenResty's Branch of LuaJIT 2
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: luajit2 * URL : https://github.com/openresty/luajit2 * License : MIT/X Description : OpenResty's Branch of LuaJIT 2 I'm going to remove ppc64el support from src:luajit, let's see if this derivative works for IBM architectures based on suggestions.
needs suggestion on LuaJit's IBM architecture dilemma
Hi folks, I learned in disappointment after becoming LuaJit uploader that the LuaJit upstream behaves uncooperatively especially for IBM architectures [1]. IIUC, the upstream has no intention to care about IBM architectures (ppc64el, s390x). The current ppc64el support on stable is done through cherry-picked out-of-tree patch. And I learned that the patch is no longer functional[2] for newer snapshots if we step away from that ancient 2.1.0~beta3 release. However, architectures like amd64 needs relatively newer version[3], while IBM architecture still has demand luajit[4] (only the ancient version will possibly work on IBM archs). I'm looking for suggestions on what to do next: option 1: drop IBM architectures that the upstream cannot support from src:luajit, and provide archs like amd64 with relatively newer snapshot versions[5]. and package reliable alternatives (if any) for IBM archs. option 2: use latest source for amd64 architecture, and rollback the source specifically for IBM architectures to keep it functional. option 3: rollback to the ancient stable release and screw it option 4: ... Thanks. [1] https://github.com/LuaJIT/LuaJIT/pull/140 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 [5] Yes ... the upstream do not release anymore.
bullseye-updates does not have a Release file
When I run sudo apt update I receive the following error messages: Err:5 http://security.debian.org/debian-security bullseye-updates Release 404 Not Found [IP: 2a04:4e42:77::644 80] *E: *The repository 'http://security.debian.org/debian-security bullseye-updates Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. Here is the settings from /etc/apt/sources.list: deb http://security.debian.org/debian-security/ bullseye-updates main deb-src http://security.debian.org/debian-security/ bullseye-updates main Is anyone else having this problem? Thanks Tim
Re: Firmware - what are we going to do about it?
On Sat, Apr 23, 2022 at 4:50 PM Paul van der Vlis wrote: > Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin: > > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > >>> I see several possible options that the images team can choose from > here. > >>> However, several of these options could undermine the principles of > Debian. We > >>> don't want to make fundamental changes like that without the clear > backing of > >>> the wider project. That's why I'm writing this... > >> > >> I have an idea for an extra option: > >> > >> 6. Put the closed source firmware somewhere in the Debian images, but > never > >> install closed source firmware by default. "No" should be the default. > > That's the option 3 more or less. > > Option 3 says to publish two sets of images. > And it says nothing about defaults. > > > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need them, > but is likely to cause users to question why we still make any images > without firmware if they're otherwise identical. > > This is the option I like. As a user who needs the closed source binary blobs they should be easier to find. > >> to put "non-free" into sources.list should also be an non-default > choice, > >> even when you install closed source firmware. > > No, that's a bad idea, which is one of the main reasons for the option 5. > > The idea is not to promote closed source firmware in any way. Have it > available, but only for the people who really want it. > > Maybe it's also an idea to put the firmware in a seperate partition. > > With regards, > Paul > > BTW: I sell Debian media like USB-sticks. I know about the problems > people have to choose a medium-type etc. > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl > >
Re: Firmware - what are we going to do about it?
Am 22. April 2022 07:18:50 MESZ schrieb Andreas Tille : >Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery: >> >> I've been a Debian Developer for quite some time and can usually manage to >> figure out most tasks like this, and providing separate firmware to the >> installer has completely defeated me every time I've tried it. > >I confirm that I never ever managed to provide the needed firmware to >the free official installer. This is just a "me too". (similar to Russ and Andreas) I have spent many years with Debian (~25 for me), and if the old folks can't manage to use the free official installers, then I think/agree that it's outright hypocrisy to nudge new users into this pitfall. I'd be very happy with option 5, and I'm in the camp of those who like a strictly opt-in solution (that can be preseeded) mfh.her.fsr IOhannes
Re: Firmware - what are we going to do about it?
> > My laptop requires the non-free binary blobs for WiFi, AMD GPU and HDMI > Sound. I think making the non-free images easier to find is a good idea. I > didn't know they even existed until I got this new laptop and nothing was > working with the regular installer. Placing the non-free and non-free live > images along side with the free installer images would be very nice. > Tim
Re: Is there room for improvement in our collaboration model?
On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote: > > > > I think this will also improve newcomer's contributing experience. > > This proposal is also filed at > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 > > What about doing something even simpler - rather than having additional > generic/core tags/teams/groups, for packages where one wants to say > "please help yourself/ourselves", simply set the Maintainer field to > debian-devel@lists.debian.org, have the Salsa repository in the debian/ > namespace, and that's it? From thereon, anyone can do team-uploads by > pushing to salsa and uploading directly, no need for > acks/delays/permissions/requests. > A simpler solution sounds good to me, except that change would be somewhat "permanent" in stating the original maintainer's preference. I forgot to mention in my original post that the tags can optionally expire. So, things like, `tag all my packages as "feel free to nmu" within the next two weeks` would be trackable. BTW, setting debian-devel@ as maintainer will result in mail flood. An alternative should be considered.
Is there room for improvement in our collaboration model?
Hi, I just noted this problem recently. Our model for team collaboration (specifically for package maintenance) is somewhat primitive. We are volunteers. Nobody can continuously maintain a package for decades like a machine. Currently our practice for accepting other people's help involves: (1) low-threshold NMU. This is not quite easy to lookup (only shows on tracker.d.o, etc) (2) VAC note in debian-private channel. Who remembers you said the others can help you upload a package? And when does that temporary permission expire? What tracks that? (3) salsa permission. Yes, after joining the salsa team, others can commit code as they like. However, when it needs to be uploaded, the others still have to write mail to the maintainer for an ack. Whether multiple peoples should commit at the same time is coordinated through emails in order to avoid duplicated work. (4) last-minute NMU/delayed. When the others cannot bear an RC bug anymore, they may want to nmu upload to the delayed queue. (5) intend to salvage. When the others cannot hear from me for very long time, this is the only formal way to take over maintanence (afaik). The problems are: (1) whether multiple people should work on the same package at the same time is based on human communication. Namely, acquiring lock and releasing lock on a package is done through human communication. This is clearly something could be improved. It should be some program to acquire and release the lock. (2) different packages are clearly regarded differently by people. I'm actually very open to the other people hijacking some of my selected packages and fix these packages as they like. Namely, I think there should be a system where we can optionally tag our packages as: A. The other DDs can do whatever they like to this package and upload directly without asking me in a hijacking way. B. May git commit but should ask before upload. C. Must ask before any action. D. ... You know that in parallel programming, optimizing IPC (in this context it would be inter-DD communication) and optimizing the locking mechanism could help. My motivation for pointing these stems from some uncomfortable feelings when it's hard to get response from busy maintainers. If I understand correctly, technically DDs have enough permission to hijack any package and do the upload. People are polite and conservative to not abuse that power. But ... in order to improve contributor experience in terms of collaboration ... maybe we can use that tagging mechanism to formally allow a little bit of upload permission abuse. I think this will also improve newcomer's contributing experience. This proposal is also filed at https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
Re: Debian doesn't have a "core team", should it? can it?
Hi,
"Core team" is already ambiguous enough. I'd suggest leave it alone and do not
try to define it. Attempts to define it are likely lead to nowhere other than
a definition hell. Unless there is such need in Debian constitution, I think
Debian should not try to do that.
The intention of that post is simply transferring some packages to more
suitable maintainers. As long as the new maintainer (rpm team as you mentioned)
feels suitable to take over, I don't see any problem here.
I'm even ok with non-debian member being maintainers for critical packages
as long as the work goes through some kind of peer review.
On Sun, 2022-04-10 at 21:23 +0100, Peter Michael Green wrote:
> Recently andreas-tille sent the following message about libzstd to
> debian-devel
>
> > I'd like to repeat that I'm really convinced that libzstd should *not*
> > be maintained in the Debian Med team but rather some core team in
> > Debian. It is here for historic reasons but should have moved somewhere
> > more appropriately since it became its general importance.
>
> It ended up being transferred to the rpm team, which got it out of the med
> team's
> hair but I'm not convinced the rpm team satisfies "some core team" any better
> than the med team does.
>
> As far as I can tell Debian has broadly 3 types of teams.
>
> 1. Teams focussed on an application area, for example the med team, the
> science team, the games team.
> 2. Teams focussed on a programming language, for example the python team,
> the perl team, the rust team. There is
> however no such team for software written in C, C++ or shell script.
> 3. Teams focussed on a particular piece of software
>
> As far as I can tell this means that there are a bunch of packages that
> "fall between the gaps", packages
> that are of high importance to Debian as a whole but are not a great fit for
> any team. They either end up not
> associated with a team at all or sometimes associated with a team who
> happened to be the first to
> use the library.
>
> I decided to get a sample of packages that could be considered "core",
> obviously different people have different
> ideas of what should be considered core but I decided to do the following to
> get a list of packages that hopefully
> most people would consider core.
>
> debootstrapped a new sid chroot
> ran tasksel install standard (a bit less spartan than just the base system)
> ran apt-get install build-essential (we are an opensource project,
> development tools are essential to us)
> ran apt-get install dctrl-tools (arguablly not core, but I needed it to run
> the test commands and it's only one
> package)
>
> There were 355 packages installed, built from 223 source packages. I got a
> list of source packages with
> the command
>
> grep-dctrl installed /var/lib/dpkg/status -n -ssource:package | cut -d ' '
> -f 1 | sort | uniq > sourcepks.txt
>
> I then extracted the source stanzas with.
>
> grep-dctrl -e -F Package `sed "s/.*/^&$/" sourcepks.txt | paste -s -d '|'`
> /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources >
> sourcestanzas.txt
>
> Then wrote a little python script to extract teams from those stanzas.
>
> #!/usr/bin/python3
> from debian import deb822
> import collections
> import sys
> f = open(sys.argv[1])
> counts = collections.defaultdict(int)
> for source in deb822.Sources.iter_paragraphs(f):
> maintainers = [source['maintainer']]
> if 'uploaders' in source:
> maintainers += source['uploaders'].split(',')
> maintainers = [s.strip() for s in maintainers if s.strip() != '']
> teams = [s for s in maintainers if ('team' in s.lower()) or ('lists' in
> s.lower()) or ('maintainers' in
> s.lower()) or ('group' in s.lower())]
> teams.sort()
> counts[tuple(teams)] += 1
> #print(repr(maintainers))
> #print(repr(teams));
>
> for teams , count in sorted(counts.items(), key = lambda x: x[1]):
> if len(teams) == 0:
> teamtext = 'no team'
> else:
> teamtext = ', '.join(teams)
> print(str(count) + ' ' + teamtext)
>
> This confirms my suspiscions, of the 223 source packages responsible
> for the packages installed in my "reasonablly but not super minimal"
> environment more than half of them were not associated with a team at all.
>
> I also saw a couple of packages in there maintained by the science team
> and the med team. two source packages telnet and apt-listchanges
> were orphaned.
>
> I do not know what the soloution is, whether a "core team" is a good idea
> or even whether one is possible at all but I feel this is an elephant that
> should have some light shone on it.
>
Bug#1008626: RFH: qiskit-aer
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Control: affects -1 src:qiskit-aer Hello, I request help with maintaining this package. With upstream moving faster than originally anticipated and with my co-maintainer and mentor retiring from Debian, I no longer have the bandwidth and skills to realistically maintain the packaging effort on par with the latest upstream releases by myself. Since the version currently packaged in Debian, upstream has included usage of conan along with a number of dependencies and changes. The package also has a strong relationship with (also RFH-ed) qiskit-terra, and ideally help would also be needed with the latter (potentially expanding to other qiskit-related packages). Best, --- Diego M. Rodriguez
Bug#1008625: RFH: qiskit-terra
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Control: affects -1 src:qiskit-terra Hello, I request help with maintaining this package. With upstream moving faster than originally anticipated and with my co-maintainer and mentor retiring from Debian, I no longer have the bandwidth and skills to realistically maintain the packaging effort on par with the latest upstream releases by myself. One of the challenges in order to bring back the package to speed is packaging additional dependencies (~3 required, some of them not pure Python) into Debian. The package also has a strong relationship with (also RFH-ed) qiskit-aer, and ideally help would also be needed with the latter (potentially expanding to other future qiskit-related packages). Best, --- Diego M. Rodriguez
Re: isa-support -- exit strategy?
On Sat, 2022-03-26 at 11:42 +0100, Stephan Lachnit wrote: > On Sat, Mar 26, 2022 at 2:36 AM M. Zhou wrote: > > > > Indeed supporting number crunching programs on ancient > > hardware is not meaningful, but the demand on Debian's > > support for number crunching is not that strong according > > to my years of observation. > > > > For popular applications that can take advantage of above-baseline > > instruction sets, they will eventually write the dynamic code > > dispatcher and add the fallback. > > > > For applications seriously need performance, they will > > leave CPU and go to GPU or other hardware. If the user correctly > > write the code and fully leverage GPU, the non-optimal CPU > > code won't necessarily be a bottleneck. > > > > For applications seriously need CPU performance, they are > > possibly going to tell the users how to tweak compiling > > parameters and how to compile locally. > > I have to disagree on this one. Yes, runtime detection and GPU > acceleration is great and all, but not every scientific library does > it and I think it's unrealistic for us to patch them all up. Please note I wrote "they (i.e. the upstream)" will implement the runtime detection or GPU acceleration, instead of us (Debian). > Also I don't like the point "since there is low demand for number > crunching on Debian, so let's just continue to ignore this problem". If it was 6 years ago, I would disagree with what I've said in the original post. Whether you like it or not, what I said is my changed mind after closely working on numerical related libraries for 6 years in Debian. And to be clear, I hold a negative opinion on what we Debian could actually change besides the upstream. If the upstream does not write runtime detection or GPU acceleration, they are either not facing a wide range of audience, or the problem does not matter, or simply the software isn't appropriate for Debian packaging. I mentioned infinite times that the eigen3 library which implements the core numerical computation part of TensorFlow does not support runtime detection -- because CPU acceleration does not matter for most of the users. Sane users who really need CPU performance are able to recompile tensorflow themselves. > At least I know a decent amount of people that use Debian (or > downstream distros) for scientific number crunching. Compiling > optimized for large workloads will always be a thing no matter the > baseline, but when getting started distro packages are just one less > thing to care about. I humbly believe over 1/3 of packages I (co-)maintained for Debian are for number crunching. And I INSIST in my NEGATIVE opinion after trying to do some experiments over the years. The number of people who really care about the ISA baseline for Debian distributed package is very likely less than you expected. I appreciate people who speak for ISA baseline, and appreciate any actual effort in this regard. But the lack of care eventually changed my mind and make me hold a negative opinion. If you think I was simply unsuccessful in promoting any solution for the topics in this discussion, please go ahead and I will support you in a visible way. > On Sat, Mar 26, 2022 at 7:25 AM Andrey Rahmatullin wrote: > > > > A partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and > > optionally raise the main amd64 baseline to x86-64-v2? > > +1 So again, that's possibly something like a partial debian archive with a dpkg fork I mentioned. That's probably the same idea as the ancient SIMDebian proposal. See the example patch for dpkg: https://github.com/SIMDebian/dpkg/commit/13b062567ac58dd1fe5395fb003d6230fd99e7c1 So that a partial archive with selected source packages can be rebuilt automatically in bumped ISA baseline. To be clear, the fact that tensorflow does not support runtime detection while the baseline code sucks in performance is the direct reason why I proposed SIMDebian. The project is abandoned, and patch is only for reference.
Re: isa-support -- exit strategy?
Hi Adam, I think the problems that apt/dpkg are trying to deal with is already complicated enough, and the architecture specific code are still not significant enough to introduce change there. Indeed supporting number crunching programs on ancient hardware is not meaningful, but the demand on Debian's support for number crunching is not that strong according to my years of observation. For popular applications that can take advantage of above-baseline instruction sets, they will eventually write the dynamic code dispatcher and add the fallback. For applications seriously need performance, they will leave CPU and go to GPU or other hardware. If the user correctly write the code and fully leverage GPU, the non-optimal CPU code won't necessarily be a bottleneck. For applications seriously need CPU performance, they are possibly going to tell the users how to tweak compiling parameters and how to compile locally. Eventually, my thoughts about above-baseline support are still either source-based package distribution like portage, or small deb repository built with a customized dpkg-dev, like I mentioned in the past. On Fri, 2022-03-25 at 23:34 +0100, Adam Borowski wrote: > Hi! > While packages are allowed to not support entire architectures > outright, there's a problem when some code requires a feature that is > not present in the arch's baseline. Effectively, this punishes an > arch > for keeping compatibility. The package's maintainers are then > required > to conform to the baseline even when this requires a significant work > and/or is a pointless exercise (eg. scientific number-crunching code > makes no sense to run on a 2002 box). > > With that in mind, in 2017 I added "isa-support" which implements > install-time checks via a dependency. Alas, this doesn't work as > well > as it should: > > * new installs fail quite late into installation process, leaving you > with a bunch of packages unpacked but unconfigured; some apt > frontends don't take this situation gracefully. > > * upgrades when an existing package drops support for old hardware > are > even worse. > > * while a hard Depends: works for leafy packages, on a library it > disallows having alternate implementations that don't need the > library in question. Eg, libvectorscan5 blocks a program that > uses it from just checking the regexes one by one. > > Suggestions? > > > Meow!
Re: Bug#1006885: ITP: lumin -- pattern match highlighter
Meh... an interesting package name. On Mon, 2022-03-07 at 20:29 +0100, Vincent Bernat wrote: > ❦ 7 March 2022 18:33 +01, Adam Borowski: > > > > lumin highlights matches to a specified pattern (string or > > > regular > > > expression) in files, using color. This is similar to grep with > > > colorized output, but it outputs all lines in the given files, > > > not > > > only matching lines. > > > > .--[ ~/bin/hl ] > > #!/bin/sh > > sed 's/'"$*"'/\c[[1;33m&\c[[0m/g' > > ` > > grep --color -C4000 pattern > > There are other suggestions here: > https://stackoverflow.com/questions/981601/colorized-grep-viewing-the-entire-file-with-highlighted-matches
Re: Seeking consensus for some changes in adduser
On Tue, Mar 8, 2022 at 6:18 PM Richard Laager wrote: > > On 3/8/22 10:49, Marc Haber wrote: > > (1) > > #202943, #202944, #398793, #442627, #782001 > > The bug reporters are requesting the default for DIR_MODE to be changed > > from 0755 to 0700, making home directories readable for the user only. > > Policy 10.9 states that directories should be 0755, but the policy > > editors probably didn't have user home directories in mind when they > > wrote that. > > As a data point, Ubuntu moved to 750 a year ago: > https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 > > At my day job, we then followed that across the board (despite not yet > being on an Ubuntu release where the change was made), and it was > essentially fine. We already considered home directories on our file > server to be "private", and on everything else, there are only accounts > for admins (who can use sudo in the rare event they need a file from > someone else's home directory). > > > (1a) would it be necessary to handle --system accounts differently? I > > think yes. > (1b) should we stay with 0755 for --system accounts? > > I don't see why system accounts need to be different. > > > (1c) does a change to 0700 for user accounts make sense? > > Yes. > > > (1d) should it be 0751 (#398793)? > > Pro: That helps ~/public_html. > > Con: That seems like a trap for non-expert users. It _feels_ like other > people can't get at things, but they actually can, if they know the next > directory down. I (and probably everyone reading this list) understands > the "1" in 751, but do end users? > > > (1e) how about ~/public_html that would break with 0750? > > As a comment on the bug mentioned, public_html not a default thing. > Changing DIR_MODE and/or ACLs are also options for those who want a > ~/public_html concept. > > > All those bugs referenced have more or less heated exchanges ranging > > from "it's fine" to "we should issue a DSA ASAP", most of them a decade > > old, so the times might have changed since then. Please note that the > > DIR_MODE _IS_ configurable in adduser, we're just discussing the > > default (which also applies for home directories created while still > > inside the Installer before a local admin can properly configure > > adduser). > > I think there is merit to defaulting to the most secure (but still > reasonable) option, and letting people loosen it if desired. > > > (2) > > #774046 #520037 > > Which special characters should we allow for account names? > > > > People demand being able to use a dot (which might break scripts using > > chown) and non-ASCII national characters in account names. The regex > > used to verify non-system accounts is configurable, so the policy can be > > locally relaxed at run-time. > > > > For system-accounts, I'd like to stick to ASCII letters, numbers, > > underscores. > > I support dashes, as was already discussed. That's already in use. > > I think the idea of dot in a username is perfectly reasonable on its > own. For some people this is very desirable. My wife, for example, uses > a dot in her email username as her first name plus my-now-her last > initial makes a word that is awkward. (This sort of problem is not > uncommon in usernames, especially at companies that make them via some > algorithm.) > > I always use colon for chown, which is what is documented, but I'm aware > it takes dot too. Is there any code in chown to handle the dot case > intelligently? Please add support for "." so we can use first.last names as user names. Other Linux's are already doing this so it should not break anything. > Non-ASCII does feel a little concerning to me (since those code paths > won't be exercised very often). > > But to recognize my bias, I have no need for a non-ASCII username. I'd > probably feel quite differently if my name wasn't correctly > representable in ASCII. Put differently, if usernames were currently > required to be Han or Cyrillic characters, I'd certainly be up in arms > asking for Latin character support. > > On the other hand, Debian probably can't go it alone here. If, as people > have mentioned, systemd isn't going to support those usernames, there's > not much point in adduser allowing them. > > > (3) > > #625758 > > --disabled-password just does not set a password for the newly created > > account (resulting in '*' in shadow) while --disabled-login places a '!' > > in shadow. On modern systems with PAM, both variants seem to be > > identical, allowing login via ssh. Aside from the documentation needing > > change to document reality > > Simon McVittie's explanation matches my understanding of what the > current behaviors of '*' and '!' are (but I haven't tested the empty > password nuance). > > While I get the general idea of locking in a way that allows unlocking > later (and keeping the original password hash), I don't see > --disabled-login as being particularly useful for adduser, since it > leads to an identical result as --disabled-password. >
Bug#1006296: ITP: git-credential-libsecret -- Git helper for accessing credentials via libsecret.
Package: wnpp Severity: wishlist Owner: M Hickford X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com * Package name: git-credential-libsecret * URL : https://github.com/git/git/commits/master/contrib/credential/libsecret/git-credential-libsecret.c * License : GPL Programming Lang: C Description : Git helper for accessing credentials via libsecret.
Re: Rakudo has a transition tracker and then what ?
Hi Sebastian, Building the files upon installation is exactly the original behavior. The problem is that compilation speed is too slow. Three raku packages could take more than 2 minutes every time when there is a raku upgrade to any version. On Fri, 2022-02-04 at 13:55 +0100, Sebastian Ramacher wrote: > On 2022-02-03 17:58:24, M. Zhou wrote: > > @dod: It looks that we have to change the Architecture: of raku-* > > packages into any (instead of "all") because there is no binnmu > > for Arch:all package. Then upon each time we bump the rakudo API > > version, we just need to file a regular transition bug to the > > release team and trigger the rebuild. > > If the pre-compiled files are like pyc files for Python, is there are > a > reason to not follow the same approach? That is, build the pre- > compiled > files on install. > > Cheers > > > > > On Thu, 2022-02-03 at 19:13 +0100, Jonas Smedegaard wrote: > > > Quoting Paul Gevers (2022-02-03 19:08:34) > > > > On 03-02-2022 18:53, Dominique Dumont wrote: > > > > > Hoping to automate this process, I've setup a transition > > > > > tracker > > > > > for Rakudo > > > > > [1]. > > > > > > > > See > > > > https://lists.debian.org/debian-release/2022/02/msg00029.html a > > > > nd > > > > follow-up messages. > > > > > > As I understand it, librust-* packages are released as arch:any > > > (not > > > arch:all) for this exact reason (I seem to recall some discussion > > > with > > > the ftpmaster and/or release team about that - evidently leading > > > to > > > that > > > praxis being tolerated, except I am totally wrong and the cause > > > for > > > Rust > > > is a different one). > > > > > > > > > - Jonas > > > > > > > >
Re: Rakudo has a transition tracker and then what ?
@dod: It looks that we have to change the Architecture: of raku-* packages into any (instead of "all") because there is no binnmu for Arch:all package. Then upon each time we bump the rakudo API version, we just need to file a regular transition bug to the release team and trigger the rebuild. On Thu, 2022-02-03 at 19:13 +0100, Jonas Smedegaard wrote: > Quoting Paul Gevers (2022-02-03 19:08:34) > > On 03-02-2022 18:53, Dominique Dumont wrote: > > > Hoping to automate this process, I've setup a transition tracker > > > for Rakudo > > > [1]. > > > > See > > https://lists.debian.org/debian-release/2022/02/msg00029.html and > > follow-up messages. > > As I understand it, librust-* packages are released as arch:any (not > arch:all) for this exact reason (I seem to recall some discussion > with > the ftpmaster and/or release team about that - evidently leading to > that > praxis being tolerated, except I am totally wrong and the cause for > Rust > is a different one). > > > - Jonas >
Re: Legal advice regarding the NEW queue
On Wed, 2022-02-02 at 13:44 +0100, Andreas Tille wrote: > Hi Wookey, > > Am Tue, Feb 01, 2022 at 02:07:21PM + schrieb Wookey: > > Has anyone on the actual FTP team responded to this thread yet? > > (sorry, I can't remember who that is currently) > > > > Either on Andreas's original simple question: 'Do we still _have_ > > to keep the binary-NEW thing?' > > Or this more complex question: Is NEW really giving us a pain:risk > > ratio that is appropriate? > > > > Andreas tried hard to get someone to just stick to the first matter > > and answer that. I don't recall seeing an answer from FTP-master > > yet? > > Me neither. In my eyes its a problem that it is hard to comminicate > with ftpmaster team. I tried on IRC as well but I prefer mailing > list > since this is recorded online. > Without answer from FTP team, it's hard to reach anywhere constructive with respect to this problem. They have the most accurate understanding on what part needs to be improved or revised. Of course I can propose ideas based on my shallow experience and speculation, but ideas in this thread will largely going to sink unless there is any effective way to make real progress on it.
Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Hi Andreas, Thank you for mentioning this. Your post inspired me to came up a new choice. On Fri, 2022-01-21 at 11:33 +0100, Andreas Tille wrote: > > This recently happed for me in the case of onetbb (which was not > uploaded by myself - so I'm not even asking for myself while other > packages of mine (new ones and ones with just renames) are waiting in > the queue.) There are lots of other packages (namely numba and lots > of > other packages depending from numba that FTBFS) depending from onetbb > - > thus I pinged on #debian-ftp more than once (which I really hate). When I was once an ftp-trainee (now I'm not in ftp-team), there was no popcon query when doing dak review. Whether a package is of high priority depends on one's experience to some extent. Even if I knew some packages must have a high popcon, their bulky size make the review process (checking files one by one) not quite easy. > Due to this I'd like to have a clear statement here (which would > prove myself in pinging either right or wrong and thus I'm asking): > > A. Packages with new binary package names should not undergo > the copyright inspection by ftpmaster and can be > auto-approved (either technically or manually) > > B. Any package in the new queue needs to be inspected by > ftpmaster for copyright issues and it takes as long as > it takes no matter whether it is a new package or a > package with changed binary name. > I'd rather propose choice C. Because I to some extent understand both sides who support either A or B. I maintain bulky C++ packages, and I also had a little experience reviewing packages on behalf of ftp-team. A -- Some (e.g. C++) packages may frequently enter the NEW queue, with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs feel it is not necessary for frequently because it drastically slows down the maintainer's work. In the worst case, when the package finally passed the NEW queue, the maintainer may have to go through NEW queue again upon the next upload. (This is very likely to happen for tensorflow, etc). B -- Uploads with OLD src and OLD bin are not required to go through NEW queue, even if a decade as passed as long as the src names and bin names are kept unchanged. One of the supports for B is that the d/copyright file may silently rot (get outdated), as uploads without updated d/copyright won't be rejected. Checking packages when they bump SOVERSION is to some extent a "periodical" check. This worked very well for packages with stable ABI. But for pacakges without stable ABI, especially bulky (C++) packages, this is painful for both uploaders and ftp checkers. Given the understanding of both options, I propose choice C: C. Lottery NEW queue: if (src is new): # completely new package require manual-review elif (src is old) but (bin is new): if not-checked-since-last-stable-release: # approximate advantage of choice B. require manual-review elif src.version already exists in archive # choice A wants to avoid this case. auto-accept else: if (lottery := random()) < threshold require manual-review else: # I expect a faster pace of debian development. auto-accept In this way concerns for both people supporting A and B can be partly addressed. The old-src-new-bin case have a large chance to pass NEW as long as they have been reviewed once after the last stable release. The burden for ftp-team can be reduced. And pace of maitnainers can be faster with less chance of being blocked and unstable to do anything but wait. > I would love to have this clearly documented since in case B. I would > stop wasting my and ftpmaster time with nagging which is not > rectified > than. > > I personally clearly prefer A. and I wish we could clarify this > situation. Me too. I perfer A personally as well. Debian might be the only major distribution which checks the license so thoroughly. Unconditionally allow an old-src-new-bin upload to pass is basically impossible, I speculate. Choice C might be more practical and feasible. It must be many outdated d/copyright in our archive. Letting eligible uploads automatically pass with a high probability is not likely causing problem even if yet another outdated d/copyright sneaked in. > Kind regards > > Andreas. > > [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html > [2] https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html >
Re: ROCm installation
On Wed, 2022-01-12 at 21:06 +0100, Maxime Chambonnet wrote:
>
> > Headers and libraries should installed under the standard path,
> > so that the compiler and linker should be able to find them without
> > additional flags. Just install all stuff to /usr should be enough.
> Currently for example rocm-hipamd installs to /usr/hip, and
> lintian yells a lot. All to /usr is quite not clear enough.
Then it sounds like that the upstream CMake installation targets
are primarily written for somewhere like /opt instead of /usr.
I looked into one Gentoo ebuild for ROCm and the problem is
rather distinct.
https://github.com/gentoo/gentoo/blob/2ed748a3b6412f99bc249e089e9221e38417a8f8/dev-util/hip/hip-4.1.0.ebuild
If shlibs are installed to somewhere like /usr/lib/rocm/lib/,
we are still able to tamper with ld.so.conf.
If binary executables are installed to /usr/lib/rocm/bin/,
then we are screwing up with the default shell PATH.
This is a deadend because we are not going to patch all
POSIX and non-POSIX shell configs. Neither do we introduce weird
scripts for the user to source.
Standarlizing the upstream install target is inevitable
to some extent.
A flag can be introduced for the upstream cmake file along
with some code, which by default install things to /usr/local
like most other existing software.
>
> >
> > I did not understand this question. Do you mean something like
> > /usr/lib/rocm-{4.5.2,5.0.0},
> > or
> > /usr/lib/rocm-4.5.2/llvm ?
> Rather the first, not sure I see a difference, in all cases, it looks
> nested under "rocm-something" to me. And we further down agree
> that nested is probably not the way.
Yes. We should just stay away from nesting things.
> > How are these files read by ROCm? Is there anything like
> > "PYTHONPATH" for the gpu code files? We should choose a
> > supported path compatible to debian policy.
> There is a cmake flag / environment variable for now,
> HIP_DEVICE_LIB_PATH :<
> The current preferred layout is /usr/amdgcn/*.bc
Anything like
/usr/share/amdgcn/ (in case they are arch-indep)
or
[/usr/lib/amdgcn, /var/lib/amdgcm, /var/cache/amdgcn]
(in ase they are arch-dep) could be better.
> > BTW, are these files architecture-independent? Namely,
> > can arm64 and amd64 produce the exactly the same (e.g.
> > md5sum-identical) output?
> I don't know, we discussed it last jitsi meeting and
> I believe that no one tried yet :)
Then we regard them as architecture-dependent for initial
debian packaging.
I looked around in the Gentoo ebuild repository,
https://github.com/gentoo/gentoo/search?q=hip=commits
https://github.com/gentoo/gentoo/search?q=rocm=commits
from which we can borrow a lot. Namely, starting from
scratch by ourselves is not necessary.
>
>
Re: ROCm installation
Hi,
Thanks for the updates.
On Wed, 2022-01-12 at 18:14 +0100, Maxime Chambonnet wrote:
"Native" Debian packages are starting to cover a significant portion of
the
stack [2], and it would be great to figure out the installation topic
The word "native" is ambiguous to a portion of developers as it may
also refer a native (debian/source/format) package.
For other readers: it's "offician debian package" in contrast to
"third-party debian packages by upstream.
on how to install ROCm today.
After skimming through the mail I realize what you actually meant
is the "ROCm file installation layout" right?
The installation options and paths generally looked for by CMake
Lists/configs
are currently:
- various cmake project-specific flags for the install paths of the
components
HIP_CLANG_PATH, HIP_DEVICE_LIB_PATH, HIP_PATH, ROCM_PATH, ... see
[5]
Headers and libraries should installed under the standard path,
so that the compiler and linker should be able to find them without
additional flags. Just install all stuff to /usr should be enough.
- /opt/rocm as a default backup
There is no way for `/opt` as official debian package. If any component
breaks without any specific file under /opt, then it is a bug to fix.
I see at least three choices, and sub-decisions to be made:
- Multi-arch or not
nvidia toolkit supports aarch64 and a few others.
Cross-compiling ROCm from Debian could be interesting in a near-
future.
The rocm libraries and binary executables are architecture dependent.
Most of them should have Architecture: any in d/control.
Cross-compiling ROCm is not something worth being looked at IMHO.
ROCm targets on high performance computing. A hardware architecture
really capable of "high performance computing" can't be too weak
to compile ROCm itself.
That said, making the installation layout Multi-Arch aware is a
good practice. Most of the packages may have Multi-Arch: same
as long as they contain architecture-dependent files.
- Nested or not
Other stacks and relatively important projects, such as postgresql
or
llvm go
nested (there is a central /usr/lib/{llvm-13, postgresql} directory,
often with a sub ./bin, ...)
I did not understand this question. Do you mean something like
/usr/lib/rocm-{4.5.2,5.0.0},
or
/usr/lib/rocm-4.5.2/llvm ?
- Where to install machine-readable GPU code
There is at least 3 types of device-side (aka GPU) binary files -
.bc for bitcode,
.hsaco for HSA code object and
.co for code object.
How are these files read by ROCm? Is there anything like
"PYTHONPATH" for the gpu code files? We should choose a
supported path compatible to debian policy.
BTW, are these files architecture-independent? Namely,
can arm64 and amd64 produce the exactly the same (e.g.
md5sum-identical) output?
Bitcode files are the machine readable form of the LLVM intermediate
representation. HSA (Heterogeneous System Architecture) and other
code object
files are AMD containers for GPU machine code. PostgreSQL does use
llvm
bitcode files: since the install path is nested, they are in
/usr/lib/postgresql/14/lib/bitcode.
Since it is arch-independent in the sense of the CPU architecture, I
have
been proposed that such code should reside in /usr/share.
Nested layout for llvm and postgresql intends to allow multiple
versions of the software co-exist on the same system. For example,
llvm-{11,12,13} may be installed simultaneously on Debian.
We debian rocm team does not have so many contributors to support
multiple versions. Just do it the simplest way as we can.
The official repacked nvidia-cuda-toolkit is not relevant
to such nested layout.
What I tried to keep in mind is that:
- shared libraries should be easily discoverable in paths looked by
/etc/ld.so.conf
- there are only so much paths that cmake find_package in config mode
looks for [8].
Shared objects from Multi-arch aware library packages should be
put at /usr/lib// as long as they are indended
for public usage.
Don't be misled by complicated setups such as llvm, postgresql or
the upstream non-standard installation path. In the standard setup
everything is likely becoming simpler. When you started to think
about ld.so.conf for a regular official debian shlib package, I
doubt something had been going wrong.
Gentoo has basically finished their ROCm packaging. Feel free to
borrow them as their license permits.
I attached as an image a direct comparison between some arbitrary
combinations
of these decisions. The directories are bundled in the attached archive
too.
- install_layout_proposal_v1 goes
multi-arch, flattened, and with GPU code in /usr/share
- install_layout_proposal_v2 goes
"ante-multi-arch", nested, and with GPU code in /usr/lib
1. header.
installation path of architecture-dependent headers should contain
multi-arch triplet (e.g. x86_64-linux-gnu). In this case,
Architecture: any, Multi-Arch: same
if the headers are identical across all architectures, the
Bug#1001894: ITP: spacecadetpinball -- Decompilation and port of "3D Pinball for Windows - Space Cadet"
Package: wnpp Severity: wishlist Owner: Lucy M X-Debbugs-Cc: debian-devel@lists.debian.org, lucylikesyourf...@gmail.com * Package name: spacecadetpinball Version : 2.0 Upstream Author : Andrey Muzychenko * URL : https://github.com/k4zmu2a/SpaceCadetPinball * License : MIT Programming Lang: C++ Description : Decompilation and port of "3D Pinball for Windows - Space Cadet" Reverse Engineered Decompilation of "3D Pinball for Windows - Space Cadet", Ported to be cross-platform. Doesn't contain the original (proprietary) data files, but requires them to run. These are to be sourced seperatly. and placed in a relevent dir. Free assets do not exist yet, but may be possible in future (upstream issue #96) This game is fun and nostalgic for many who played it when it was included with Windows. I believe at least a handful of people will find it useful to install this without having to manually build it, as I would have. User packages of this already exist for some (non-debian) distros (eg AUR) I am new to packaging and have produced a package for this using debhelper. I am unsure of its quality at the moment but im interested in getting it up to standard and getting it out there, especially as upstream does not provide prebuilt linux binaries. If my understanding is correct, I need a sponsor & possibly a mentor to provide guidance and get any packaging approved? Please forgive me if I am wrong about this whole process. Below is what I have so far, if that helps. https://github.com/LucyLikesYourFace/SpaceCadetPinball
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
All, I am against automatically setting HTTPS. Their should be an option in the installer to set or unset HTTPS while configuring the mirror! I like a lot of folks am on a metered internet connection with a UTM proxy firewall. I have multiple computers that need patched and only having to download the package once is a great convenience to both data usage and download time as my internet is not fast 4G LTE usually only operating at 3G speed. Tim
Re: testing for rootfs vs. /usr reproducibility regressions
On 8/21/21, Andy Smith wrote: > Hi Tim, > > On Fri, Aug 20, 2021 at 05:29:54PM -0400, Timothy M Butterworth wrote: >> I have a new-be question, what is the point of merged-usr? > > I put "debian merged-usr" into my favourite search engine and the > first result was: > > https://wiki.debian.org/UsrMerge > > Does this page and those linked from it answer your question > sufficiently as to what the point of the effort is? > > The link near to the bottom: > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > is quite informative. Thanks for the links, I have read them and I am all caught up now. This seems like something that Linux Standard Base LSB should have resolved regarding the installation directory. > If you read those and it still isn't clear, it might be best to ask > about it on debian-user, as debian-devel would really be for Debian > Developers (who are mostly up to speed on this already to varying > degrees) to decide about *how* to do it, not the basics of *why* or if > it even *should* be done. > > It has been the default for some time for new installs and the > tech-ctte already decided that it will be the only supported > configuration for the next release after bookworm. At this point > rehashing the whys of it would be repeating conversations had over > the last several years, so I feel like it's a user documentation > issue at this point if that's necessary. > > Cheers, > Andy > >
Re: Debian 11 Bullseye Setup Problems Error Report
I have been using Debian 11 since Alpha 1 release. I installed with non-free live DVD using the calamaris installer. I have it installed on three systems one Intel Celeron, one Intel i5 and one AMD Ryzen 7. I give the installer a 5 star rating although I would like to see some improvements made to the disk configuration utility. Currently the disk configuration utility is non-intuitive and appears to be designed for keyboard only navigation as opposed to mouse navigation. No matter how many times I use the disk utility I just can not get used to using it. I have not found any show stopper bugs. I am having an issue in KDE Plasma where the desktop fails to load including the wall paper. The screen is just black with a functional task bar. Simply logging off and logging back in fixes it, so it is just a minor annoyance. Having a dedicated email list and IRC channel for installation related concerns seems like a good idea. I could see it getting used. Tim
Re: testing for rootfs vs. /usr reproducibility regressions
All, Sorry I am a little late to this party so I have a new-be question, what is the point of merged-usr? It seems like a lot of work for a little reward, as the packages already work. Is there a legitimate benefit for changing all these file paths that I am missing? Thanks Tim
Debian package manager privilege escalation attack
All, I just ran across this article https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested the attacks on Debian 11 and they work successfully giving me a root shell prompt. Tim
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
I am fine with Debian's release cycle but It would be nice to see more packages. For example Debian is missing KDE's Amarok music manager. I am happy to see Debian 11 gained KDE Elisa music manager. I am sad to see that VirtualBox is not available on Debian 11. I had to jerry-rig it using the Ubuntu Focal repo from Oracle. OpenSUSE Tumbleweed is a good rolling distro, I am surprised Steam did not use it. OpenSUSE was the repo Plasma Active shipped with. I tried Tumbleweed but I got tired of the constant need to download all of the packages. I am on a metered internet connection and a Rolling Distro is just not for me. Debian needs to have a mechanism like the openSUSE OBS Open Build Service, where people can create Repo's of newer software versions to use with stable Debian. On openSUSE I use the stable KDE Repo's to keep KDE up-to-date with the latest stable releases. Tim
Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"
On Mon, 2021-07-05 at 02:09 +, Paul Wise wrote: On Sun, Jul 4, 2021 at 11:20 AM Mo Zhou wrote: > (2) use the "hardware capabilities" feature of ld.so(8) ... > Solution (2) will result in very bulky binary packages; Solution (2) seems like the only option that can be done entirely within Debian, how bulky are the packages that use this? For example, the latest tensorflow packaging (in NEW queue) results in these binary debs: (thanks to Wookey, Michael, and Andreas for their work!) ~/Debian/tensorflow ls -lh *.deb 18:57:24 -rw-r--r-- 1 root root 36M Jul 5 15:25 libtensorflow-cc2_2.3.1-1_amd64.deb -rw-r--r-- 1 root root 1.7G Jul 5 15:25 libtensorflow-cc2-dbgsym_2.3.1-1_amd64.deb -rw-r--r-- 1 root root 629K Jul 5 15:25 libtensorflow-dev_2.3.1-1_amd64.deb -rw-r--r-- 1 root root 5.6M Jul 5 15:25 libtensorflow-framework2_2.3.1-1_amd64.deb -rw-r--r-- 1 root root 128M Jul 5 15:25 libtensorflow-framework2-dbgsym_2.3.1-1_amd64.deb Supporting multiple ISA variants based on ld.so means a multiple of the current package size.
Re: Package mailutils provides mailx but do not implement command Mail
On Tue, Jun 22, 2021 at 03:48:01PM +0500, Andrey Rahmatullin wrote: > On Tue, Jun 22, 2021 at 11:46:10AM +0100, Jose M Calhariz wrote: > > Does this fix qualify for bullseye? > Please read > https://release.debian.org/bullseye/freeze_policy.html#appropriate and > decide which category this is in, if any. > Probably yes, I will work on it. -- -- As pessoas mudam através do que alcançam --Wystan Hugh Auden signature.asc Description: PGP signature
