Bug#1012558: ITP: drawterm-9front -- graphical client for plan9front CPU servers
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org * Package name: drawterm-9front Upstream Author : Plan9front project * URL : http://drawterm.9front.org/ * License : MIT Programming Lang: C Description : graphical client for plan9front CPU servers Drawterm is a X11 application that allows one to connect to a remote Plan 9 server, usually a CPU server, but a terminal can also be tweaked to receive drawterm clients. . This is a fork of Russ Cox’s drawterm to incorporate features from Plan9front, most importantly DP9IK authentication support and the TLS based rcpu protocol. -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Re: How to handle packages which build themselves with bazel?
They seem to be mostly interested in packaging bazel *for* Debian, while I'm more interested in building packages *with* bazel. Currently I'm mainly concerned about my own software (where with my other hat I am the developer, as well as the maintainer), but this is going to show up more as bazel use becomes more common... On Thu, 9 Jun 2022 at 00:38, M. Zhou wrote: > 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: needs suggestion on LuaJit's IBM architecture dilemma
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. > signature.asc Description: PGP signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Frédéric, On 09-06-2022 16:19, Frédéric Bonnard wrote: did you see any improvement with luajit2 ? Improvements, yes. All fixed, no. 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. See also https://bugs.debian.org/1012362. Best to have the conversation there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1012584: ITP: blag -- blog-aware, static side generator
Package: wnpp Severity: wishlist Owner: Bastian Venthur X-Debbugs-Cc: debian-devel@lists.debian.org, vent...@debian.org * Package name: blag Version : 1.2 Upstream Author : Bastian Venthur * URL : https://github.com/venthur/blag * License : MIT Programming Lang: Python Description : blog-aware, static side generator Blag is a blog-aware, static site generator, written in Python. It supports the following features: * Write content in Markdown * Theming support using Jinja2 templates * Generation of Atom feeds for blog content * Fenced code blocks and syntax highlighting using Pygments * Integrated devserver * Available on PyPI
Work-needing packages report for Jun 10, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1266 (new: 8) Total number of packages offered up for adoption: 177 (new: 1) Total number of packages requested help for: 60 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: emacs-neotree (#1012472), orphaned 2 days ago Description: directory tree sidebar for Emacs that is like NERDTree for Vim Installations reported by Popcon: 23 Bug Report URL: https://bugs.debian.org/1012472 emacs-pod-mode (#1012473), orphaned 2 days ago Description: Emacs major mode for editing .pod files Reverse Depends: emacs-goodies-el Installations reported by Popcon: 1912 Bug Report URL: https://bugs.debian.org/1012473 jsonnet (#1012294), orphaned 6 days ago Description: data templating language Reverse Depends: libjsonnet-dev Installations reported by Popcon: 32 Bug Report URL: https://bugs.debian.org/1012294 lintian (#1012289), orphaned 6 days ago Description: Debian package checker Reverse Depends: arriero elida jenkins-debian-glue-buildenv libconfig-model-dpkg-perl mini-buildd packaging-dev pkg-perl-tools progress-linux-maintainers xdeb Installations reported by Popcon: 24570 Bug Report URL: https://bugs.debian.org/1012289 monero (#1012557), orphaned today Description: cryptocoin client for Monero network - daemon and tools Reverse Depends: monero-tests Installations reported by Popcon: 74 Bug Report URL: https://bugs.debian.org/1012557 node-mermaid (#1012551), orphaned today Description: Markdownish syntax for generating flowcharts, Reverse Depends: gitlab Installations reported by Popcon: 49 Bug Report URL: https://bugs.debian.org/1012551 node-node-sass (#1012550), orphaned today Description: Wrapper around libsass Reverse Depends: node-grunt-sass node-rollup-plugin-sass Installations reported by Popcon: 22 Bug Report URL: https://bugs.debian.org/1012550 onedrive (#1012429), orphaned 3 days ago Description: folder synchronization with OneDrive Installations reported by Popcon: 365 Bug Report URL: https://bugs.debian.org/1012429 1258 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: oz (#1012397), offered 3 days ago Description: Install virtual machine guest OSs with minimal input from the user Installations reported by Popcon: 19 Bug Report URL: https://bugs.debian.org/1012397 176 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1335 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (134 more omitted) Installations reported by Popcon: 96806 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 94 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core firejail (17 more omitted) Installations reported by Popcon: 185183 Bug Report URL: https://bugs.debian.org/1006872 aufs (#963191), requested 719 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 8194 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 2017 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1211 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3910 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 629 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1885 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 2790 Bug Report URL: https://bugs.debian.org/860116
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. > >
