Bug#1065042: O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library
On 2024-02-29, Sandro Tosi wrote: > I intend to orphan the mpl-sphinx-theme package. > > The package description is: > This is the official Sphinx theme for Matplotlib documentation. It extends > the > pydata-sphinx-theme project, but adds custom styling and a navigation bar. > . > This package provides documentation for mpl-sphinx-theme It looks like you attempted to orphan it, but switched the Maintainer to the python team rather than the Debian QA team ... Was your intention to orphan it, or just leave it up to the python team? I only noticed because I am subscribed due to the previous NMU for reproducible builds, and those changes do not appear to be included... live well, vagrant signature.asc Description: PGP signature
Bug#1040973: RFP: haunt -- static site generator written in Guile Scheme
On 2023-07-13, David Bremner wrote: > * Package name: haunt ... > Looks like dependencies guile-reader and guile-commonmark would also > need packaging. Looks like guile-reader, guile-commonmark and haunt look likely to be fairly trivial to package... see the recently packaged guile-avahi for a simple example. I am not sure I am up for being haunted with three more guile packages! ... that said, haunt is available in guix, which is available in Debian, and is the main reason I maintain any guile packages at all! :) live well, vagrant signature.asc Description: PGP signature
Bug#1038980: ITP: guile-avahi -- guile bindings for avahi
Package: wnpp Owner: Vagrant Cascadian X-Debbugs-Cc: debian-de...@lists.debian.org, vagr...@debian.org, l...@gnu.org Severity: wishlist * Package name: guile-avahi Version : 0.4.1 Upstream Contact: l...@gnu.org, guile-avahi-b...@nongnu.org * URL : https://www.nongnu.org/guile-avahi/ * License : LGPL, GPL, permissive Programming Lang: guile, C Description : guile bindings for avahi This package provides bindings for Avahi. It allows programmers to use functionalities of the Avahi client library from Guile Scheme programs. Avahi itself is an implementation of multicast DNS (mDNS) and DNS Service Discovery (DNS-SD). guile-avahi is a build-dependency for guix, although it can technically be built without it and does not use avahi by default, if enabled at runtime, it errors out in non-obvious ways: https://lists.gnu.org/archive/html/help-guix/2023-06/msg00083.html https://bugs.debian.org/1038916 Draft packaging available: https://salsa.debian.org/vagrant/guile-avahi Currently, guix and related guile packages are primarily maintained by me alone, but would welcome help! live well, vagrant
Bug#1025776: O: amavisd-milter -- amavisd-new interface for milter-capable MTAs
Package: wnpp Severity: normal Description: amavisd-new interface for milter-capable MTAs This package provides a milter for amavisd-new that works with Sendmail or Postfix, using the AM.PDP protocol. . Replacing the older amavisd-new-milter program, amavisd-milter makes use of the full functionality of amavisd-new. It supports using spam and virus information header fields, rewriting message subjects, adding address extensions, and selectively removing recipients. signature.asc Description: PGP signature
Bug#1015208: O: gcc-riscv64-unknown-elf -- GCC compiler for embedded RISC-V chips
Package: wnpp Severity: normal X-Debbugs-CC: debian-ri...@lists.debian.org, vagr...@reproducible-builds.org, kei...@keithp.com The maintainer of gcc-riscv64-unknown-elf no longer wishes to maintain the package, marking as orphaned. It might be possible to switch this package to building from the gcc-X-source packages, instead of a forked upstream. I will probably do a QA upload soon to resolve some outstanding reproducible builds and other issues, but do not intend to adopt the package myself for the long-term. live well, vagrant signature.asc Description: PGP signature
Bug#1015206: O: binutils-riscv64-unknown-elf -- GNU assembler, linker and binary utilities for RISC-V processors
Package: wnpp Severity: normal X-Debbugs-CC: debian-ri...@lists.debian.org, vagr...@reproducible-builds.org, kei...@keithp.com The maintainer of binutils-riscv64-unknown-elf no longer wishes to maintain the package, marking as orphaned. It might be possible to switch this package to building from the binutils-source package, instead of a forked upstream. I will probably do a QA upload soon to resolve some outstanding reproducible builds and other issues, but do not intend to adopt the package myself for the long-term. live well, vagrant signature.asc Description: PGP signature
Bug#1011559: ITP: lcsync -- librecast file and data syncing tool
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: lcsync Version : 0.0 Upstream Author : Brett Sheffield * URL or Web page : https://librecast.net/lcsync.html * License : GPL-2, GPL-3 Description : librecast file and data syncing tool Kind of like an ipv6 multicast rsync tool. Initial packaging available at https://salsa.debian.org/vagrant/lcsync signature.asc Description: PGP signature
Bug#988904: ITP: usbsdmux -- control software for USB-SD-Mux devices
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: usbsdmux Version : 0.2.0 Upstream Author : Pengutronix, Chris Fiege * URL or Web page : https://github.com/pengutronix/usbsdmux * License : LGPL-2+, BSD-3 Description : usbsdmux: control software for USB-SD-Mux devices The USB-SD-Mux hardware allows switching a microSD card between the host computer via USB or a device-under-test, allowing programmatic testing of low-level parts of the boot process such as boot loader and early operating system. This package provides a commandline interface to control switching between host computer and device-under-test, as well as a command to configure the USB-SD-Mux device itself. Initial packaging soon to be at: https://salsa.debian.org/vagrant/usbsdmux live well, vagrant signature.asc Description: PGP signature
Bug#988691: RFP: python-comment-parser -- extract comments from source code (Python)
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org, vagr...@debian.org * Package name: python-comment-parser Version : 1.2.3 Upstream Author : Jean-Ralph Aviles * URL or Web page : https://github.com/jeanralphaviles/comment_parser * License : Expat Description : extract comments from source code (Python) This Python module can be used to extract comments from source code in various languages. Supported languages include: C, C++/C#, Go, HTML, Java, Javascript, Python, Ruby, Shell, and XML. I've made a quick packaging attempt that will soon be available at: https://salsa.debian.org/vagrant/python-comment-parser I do not have a lot of experience packaging python modules, so if someone with more experience and enthusiam for python packaging would like to take this on, that would be great, as I don't forsee uploading this to Debian myself; I'm packaging this for my own use at the moment, but if I need to use it more maybe I'll take a more active interest... live well, vagrant signature.asc Description: PGP signature
Bug#986363: ITA: guile-lib -- Library of useful Guile modules
Control: retitle 986363 ITA: guile-lib -- Library of useful Guile modules
Control: owner 986363 vagr...@debian.org
On 2021-04-04, Göran Weinholt wrote:
> I intend to orphan the guile-lib package.
>
> The package description is:
> A set of various-purpose library modules for Guile. Covered areas include:
> .
> * Unit testing framework ala JUnit
> * Logging system
> * String routines (wrapping, completion, soundex algorithm)
> * OS process chains (think "shell pipes in scheme")
> * ANSI escape sequence text coloring
> * A thread-safe message queue
> * Routines to perform topological sorts
> * Neil Van Dyke's permissive ("pragmatic") HTML parser
> * Nifty and concise regular expression routines
> * Classic search functions
This is a build dependency of newer versions of guix (and the upcoming
guix version requires a newer version of guile-lib), so looks like I
should adopt it!
I did some quick testing of the updated guile-lib version, and the
packaging was nicely up-to-date and didn't require much more than
merging the new version, so hope to upload to experimental in the next
few days...
live well,
vagrant
signature.asc
Description: PGP signature
Bug#982893: ITP: gcc-or1k-elf -- GNU C compiler for the Open RISC 1000 processors
On 2021-03-19, Vagrant Cascadian wrote: > On 2021-02-15, Nicolas Boulenguez wrote: >> * Package name: gcc-or1k-elf >> * URL : https://salsa.debian.org/debian/gcc-or1k-elf > > I tried building this with sbuild, but it unfortunately doesn't get very > far, failing in the clean target: > > dpkg-buildpackage: info: host architecture amd64 >debian/rules clean > dh clean -Dsrc -Bbld > dh_auto_clean -O-Dsrc -O-Bbld > dh_auto_clean: error: invalid or non-existing path to the source directory: > src > make: *** [debian/rules:24: clean] Error 25 > dpkg-buildpackage: error: debian/rules clean subprocess returned exit > status 2 This fixed it for me: diff --git a/debian/rules b/debian/rules index 018d959..9fecc6d 100755 --- a/debian/rules +++ b/debian/rules @@ -21,7 +21,7 @@ static_archives := $(addprefix $(gcc_libdir)/,libgcc.a libgcov.a) # https://gcc.gnu.org/install/configure.html recommends out-of-tree builds. %: - dh $@ -Dsrc -Bbld + dh $@ -Bbld execute_before_dh_autoreconf: src src: signature.asc Description: PGP signature
Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors
On 2021-02-15, Nicolas Boulenguez wrote: > * Package name: binutils-or1k-elf > * URL : https://salsa.debian.org/debian/binutils-or1k-elf > * License : GPL-3+ > Description : GNU binary utilities for the Open RISC 1000 processors > > This package provides GNU assembler, linker and binary utilities for > a specific hardware and operating system combination. You don’t need > it unless you plan to cross-compile programs for it from another > operating system. > . > This package targets the Open RISC 1000 processors. Any blockers to uploading this? It seems to build fine. Looking forward to getting crust into Debian to be able to integrate into u-boot packages in Debian! live well, vagrant signature.asc Description: PGP signature
Bug#982893: ITP: gcc-or1k-elf -- GNU C compiler for the Open RISC 1000 processors
On 2021-02-15, Nicolas Boulenguez wrote: > * Package name: gcc-or1k-elf > * URL : https://salsa.debian.org/debian/gcc-or1k-elf I tried building this with sbuild, but it unfortunately doesn't get very far, failing in the clean target: dpkg-buildpackage: info: host architecture amd64 debian/rules clean dh clean -Dsrc -Bbld dh_auto_clean -O-Dsrc -O-Bbld dh_auto_clean: error: invalid or non-existing path to the source directory: src make: *** [debian/rules:24: clean] Error 25 dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 I presume this is because it hasn't yet unpacked the source tarball from /usr/src/gcc*.tar.xz Full build log attached. live well, vagrant gcc-or1k-elf_1~20210319~4_amd64-2021-03-19T16:40:09Z.build Description: Binary data signature.asc Description: PGP signature
Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs
On 2021-01-07, Jonas Smedegaard wrote: > Quoting Arnaud Ferraris (2021-01-07 00:17:49) >> Le 05/01/2021 à 12:35, Jonas Smedegaard a écrit : >> > * Package name: crust > [...] >> > Personally I own an Olimex TERES-I DIY laptop >> > and several Olimex arm64 boards, >> > but would prefer to maintain this package as a team-effort >> > with owners of other Allwinner boards involved as well. >> >> As I own (and develop for) a PinePhone and PineTab, I'll gladly >> co-maintain this package with you. > > Great! Also very interested; thanks for intiating the ITP process! I have a pinebook (14), two pinebook 1080p, a few pine64+, and it would be nice to add support for them. > I propose that we use the Tinker team as platform for this - if fine > with you then please subscribe to the mailinglist and join the irc > channel as listed at https://wiki.debian.org/Teams/Tinker :-) Would you be amenable to maintaining it in the Debian group, along with u-boot and arm-trusted-firmware? The Tinker team sounds interesting, though. :) live well, vagrant signature.asc Description: PGP signature
Bug#896910: O: libdigidoc -- DigiDoc digital signature library
On 2020-12-30, Andrej Shadura wrote: > On Wed, 30 Dec 2020, at 09:14, Andrej Shadura wrote: >> On Wed, 30 Dec 2020, at 08:31, Vagrant Cascadian wrote: >> > I'd like to do a QA upload to fix a reproducible builds issue (#978064) >> > and other basic package maintenance as I'm able without disturbing the >> > package too much, but the above makes it a little unclear how to >> > proceed... I'd rather just use dgit than subscribe to another salsa >> > team. >> >> Sure, please go ahead with dgit (--gbp iirc), I'll push to Salsa myself. > > Actually, I also went ahead and added the debian group to the ACL of this > repository only so you should be able to push too. Oh, the permissions do not seem quite right: remote: GitLab: You are not allowed to push code to protected branches on this project. To salsa.debian.org:eidas-team/libdigidoc.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'g...@salsa.debian.org:eidas-team/libdigidoc.git' Will upload with dgit anyways, and maybe you can sort out how to merge it into salsa for the moment. live well, vagrant signature.asc Description: PGP signature
Bug#896910: O: libdigidoc -- DigiDoc digital signature library
On 2020-12-30, Andrej Shadura wrote: > And yet another mail from me. > > On Wed, 30 Dec 2020, at 09:14, Andrej Shadura wrote: >> On Wed, 30 Dec 2020, at 08:31, Vagrant Cascadian wrote: >> > I'd like to do a QA upload to fix a reproducible builds issue (#978064) >> > and other basic package maintenance as I'm able without disturbing the >> > package too much, but the above makes it a little unclear how to >> > proceed... I'd rather just use dgit than subscribe to another salsa >> > team. >> >> Sure, please go ahead with dgit (--gbp iirc), I'll push to Salsa myself. > > Actually, I also went ahead and added the debian group to the ACL of > this repository only so you should be able to push too. Ok, I'll add a lintian override for that, since you've added the debian group to the ACL, the QA team is able to upload using that. I'll also upload with the uploaders field removed; it makes the orphaned status ambiguous, which kind of defeats the purpose of orphaning. Easy enough to add it back once it is adopted again. :) live well, vagrant signature.asc Description: PGP signature
Bug#896910: O: libdigidoc -- DigiDoc digital signature library
On 2018-04-25, Andrej Shadura wrote: > I intend to orphan libdigidoc. This library is a part of a bigger software > suite for Estonian eID. My current eID is expiring this month, and since I > never used it for anything serious and probably don’t intend to, I won’t be > renewing it. Not being a user, maintaining it in Debian doesn’t seem right > or fair. The status of libdigidoc seems half-way a QA package, and half-way maintained by Andrej Shadura. Notably, a few lintian issues make the current status a bit unclear: https://lintian.debian.org/sources/libdigidoc/3.10.5-1.html E uploaders-in-orphan W no-qa-in-changelog W orphaned-package-maintained-in-private-space Vcs-Git https://salsa.debian.org/eidas-team/libdigidoc.git Since it was orphaned, several uploads have been done, including a switch to using the eidas-team salsa repository. Previously dgit URLs were in Vcs-*. I'd like to do a QA upload to fix a reproducible builds issue (#978064) and other basic package maintenance as I'm able without disturbing the package too much, but the above makes it a little unclear how to proceed... I'd rather just use dgit than subscribe to another salsa team. live well, vagrant signature.asc Description: PGP signature
Bug#850644: ITP: guix -- A functional package manager based on Scheme
On 2020-09-21, Lucas Nussbaum wrote: > On 17/04/20 at 17:25 -0700, Vagrant Cascadian wrote: >> All the build-depends are packaged and may as well call this an ITP now. >> Would still very much welcome help maintaining this, though! >> >> Packaging branch updated to 1.1.0: >> >> https://salsa.debian.org/vagrant/guix > > Any progress on this? We are considering deploying GUIX at $DAY_JOB and > I was wondering if this package could serve as a basis. Been struggling with the test suites, which make some guix specific assumptions and various other failures. Last I tried the packaging branch above it did actually work (with the test suite results ignored), but that was a while ago. I'd like to transition to guile-3.0, but a blocker for that is guile-gnutls test suite issues with recent versions of guile 3.x. The upcoming release of guix (whenever that might be) will actually include proper authentication of updates, which I think would be needed for uploading to anything other than experimental. I've been tempted to upload to experimental to try and get the NEW queue processing going while those issues get sorted out, but haven't had a lot of time or other excuse to work on it. Would love to see progress on it, though, if anyone could lend a hand! live well, vagrant signature.asc Description: PGP signature
Bug#850644: ITP: guix -- A functional package manager based on Scheme
Control: retitle 850644 ITP: guix -- A functional package manager based on Scheme All the build-depends are packaged and may as well call this an ITP now. Would still very much welcome help maintaining this, though! Packaging branch updated to 1.1.0: https://salsa.debian.org/vagrant/guix live well, vagrant signature.asc Description: PGP signature
Bug#950315: ITP: m4api -- access Mini-Box M4-ATX power supplies
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: m4api Version : 0.3~ Upstream Author : Ken Tossell * URL or Web page : https://github.com/ktossell/m4api * License : LGPL-2.1 Description : access Mini-Box M4-ATX power supplies Utility and library to access monitoring and configuration functions of mini-box power supplies produced by http://www.mini-box.com/site/index.html Initial packaging work: https://salsa.debian.org/vagrant/m4api/ live well, vagrant signature.asc Description: PGP signature
Bug#944565: O: ldm -- LTSP display manager
On 2019-11-12, Jonathan Carter wrote: > On 2019/11/12 00:29, Vagrant Cascadian wrote: >> Newer versions of LTSP no longer make use of LDM; it is no longer >> maintained upstream. > > In my opinion, ltspfs, ldm-themes and ldm won't be of particular use of > anyone. Any objections if I file for them to be removed from the archive > instead? Now that it has been several weeks and nobody has stepped up to take over, sure, go ahead and file removal requests! I'd also add ltsp-manager/experimental to the list, while you're at it. live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2019-11-13, Jan Nieuwenhuizen wrote: > Vagrant Cascadian writes: >> Still one test suite failure on amd64, i386 works fine. The failing test >> on amd64 is: >> >> lib/tests/dirent/90-readdir.c >> >> Is there any way to mark the failing test as XFAIL conditionally by >> architecture? > > As a developer: yes; not really as a user/packager atm. IOW, you will > need a patch. > > The strange thing is that I tried to reproduce on a bullseye/sid VM of > about 2months ago; and for me all tests pass? Well, they've consistently failed for me ... hrm. > Anyway, I have updated the wip-0.20 branch to include three patches > > --8<---cut here---start->8--- > build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-gcc. > build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-mescc. > build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64. > --8<---cut here---end--->8--- > > you can cherry-pick the one that works for you. I did a quick build with all three, and it worked. Will triage exactly which of the three are needed another time. >> A bigger blocker at this point is that mes installs numerous files in >> /usr/include/, such as /usr/include/alloca.h, that conflict with other >> packages such as libc6-dev. In a Debian environment, we typically can't >> have multiple packages shipping the same files in the same PATHS. Other >> libc implementations seem to put them in /usr/include/IMPLEMENTATION/ >> subdirs, e.g. /usr/include/mes/. > > On wip-0.20, I have fixed install to honor configure's > --includedir=, so you may use > > ./configure --includedir=/usr/include/mes > > that should work now. That worked pefectly! >> With the /usr/include issue solved and ideally the test suite failure >> too, it would in my opinion be feasible to upload to Debian! > > Hope this fixes it, > a big thank you again! And thanks likewise for quickly responding with patches! Pushed updates to my packaging branch. live well, vagrant signature.asc Description: PGP signature
Bug#850644: #850644: RFP: Guix in Debian
On 2019-05-28, Vagrant Cascadian wrote: > On 2019-05-16, Vagrant Cascadian wrote: >> So in a bit of a focused run of packaging, I've been chasing the >> dependency chain necessary to get guix building on Debian: Summary: all the dependencies are in Debian! >> * guile-gnutls needs to be (re)enabled in libgnutls*: >> >> https://salsa.debian.org/vagrant/gnutls > > Proposed a patch to re-enable: > > https://bugs.debian.org/905272#29 Which has since been fixed and guile-gnutls is again available in Debian! >> * guile-json needs to be updated to version 1.2.0 (3.x is incompatible), >> and I've pushed wip branches updating packaging for new upstream >> versions: >> >> https://salsa.debian.org/debian/guile-json > > Updated to 1.2.0 in Debian experimental. A little awkward not updating > to the newest upstream version, but hopefully that won't last forever... Guix has since switched to guile-json 3.x, which is now in Debian. >> * I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and >> guile-sqlite3 which need some more polish and then uploading to >> Debian: >> >> https://salsa.debian.org/vagrant/guile-gcrypt >> https://salsa.debian.org/vagrant/guile-sqlite3 ... >> https://salsa.debian.org/vagrant/guile-ssh All Debian for a few months now! >> * guile-git required scheme-bytestructures, which I've packaged, and >> needs to be uploaded before guile-git can be: >> >> https://salsa.debian.org/vagrant/scheme-bytestructures > > Uploaded and waiting in NEW for review: > > https://ftp-master.debian.org/new/scheme-bytestructures_1.0.5-1.html scheme-bytestructures went through NEW a while back and... The guile-git package just landed in Debian a few days ago, which was the last missing build-dependency! > It still needs a way to get the bootstrap binaries (bash, mkdir, tar and > xz) from Guix; right now they're binaries shipped in the source! > Ludovic Courtès worked on a patch that would in theory download those at > run-time, but that is not yet working... Since been solved in guix master branch, yay! > Bootstrapping the system with MES is also WIP in Guix, and it might be > possible to build identical bootstrap binaries using MES in Debian at > some point: > > https://bugs.debian.org/902174 I've made some progress on packaging MES as well, but I'm not sure we want to wait till that's done to upload to Debian... > The guix packaging for Debian also has a small number of test failures, > at least one of which simply needs to be disabled because it accesses > the network (which violates Debian policy). The test failures seem a bit larger on this most recent pass. > Also needs some updates to the packaging to get the guix-daemon running > out of the box, for which there's a provided systemd service, and adding > some guixbuild users, which shouldn't be too hard. Working on that now... live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2019-06-10, Vagrant Cascadian wrote: > On 2019-06-10, Vagrant Cascadian wrote: > I updated to b3fa6273210200cf2694491b07ed5a328e9a4e62 from upstream, > added a few packaging updates, and... The current branch builds a > package! > > https://salsa.debian.org/vagrant/mes Updated to 0.20 a while back and have iterated through a few test builds on i386, and it appears to be working: https://salsa.debian.org/vagrant/mes > A few test failures on amd64, but i386 tests run fine. Still one test suite failure on amd64, i386 works fine. The failing test on amd64 is: lib/tests/dirent/90-readdir.c Is there any way to mark the failing test as XFAIL conditionally by architecture? A bigger blocker at this point is that mes installs numerous files in /usr/include/, such as /usr/include/alloca.h, that conflict with other packages such as libc6-dev. In a Debian environment, we typically can't have multiple packages shipping the same files in the same PATHS. Other libc implementations seem to put them in /usr/include/IMPLEMENTATION/ subdirs, e.g. /usr/include/mes/. With the /usr/include issue solved and ideally the test suite failure too, it would in my opinion be feasible to upload to Debian! live well, vagrant signature.asc Description: PGP signature
Bug#944567: O: ltspfs -- Fuse based remote filesystem for LTSP thin clients
Package: wnpp Severity: normal I intend to orphan the ltspfs package. Newer versions of LTSP no longer make use of LTSPFS; it is no longer maintained upstream. Marking it as orphaned for now just in case someone wants to maintain the legacy LTSP 5.x and they could adopt this component. If nobody wants to adopt it, it should probably be removed from the archive instead of landing in the next stable release. Description: Fuse based remote filesystem for LTSP thin clients LtspFS is a remote filesystem consisting of two parts: 1) A network server daemon that runs on the LTSP terminal. 2) A FUSE module that runs in userspace on the server, that connects with the daemon on the client. . This package contains the userspace parts for the LTSP server. live well, vagrant signature.asc Description: PGP signature
Bug#944566: O: ldm-themes -- Collection of themes for the LTSP login manager
Package: wnpp Severity: normal I intend to orphan the ldm-themes package. Newer versions of LTSP no longer make use of LDM; it is no longer maintained upstream. Marking it as orphaned for now just in case someone wants to maintain the legacy LTSP 5.x and they could adopt this component. If nobody wants to adopt it, it should probably be removed from the archive instead of landing in the next stable release. The package description is: LDM is the LTSP Display Manager. It manages logins to sessions hosted on remote machines. . This package currently provides the following themes: - softWaves - Lines - Joy - futureprototype live well, vagrant signature.asc Description: PGP signature
Bug#944565: O: ldm -- LTSP display manager
Package: wnpp Severity: normal I intend to orphan the ldm package. Newer versions of LTSP no longer make use of LDM; it is no longer maintained upstream. Marking it as orphaned for now just in case someone wants to maintain the legacy LTSP 5.x and they could adopt this component. If nobody wants to adopt it, it should probably be removed from the archive instead of landing in the next stable release. The package description is: ldm is an X11 display manager similar to xdm, gdm and kdm, but unlike those it wraps the X11 traffic within an SSH tunnel to provide a secure login mechanism for remote X sessions. . LTSP stands for 'Linux Terminal Server Project'. live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2019-06-10, Vagrant Cascadian wrote: > On 2019-06-10, Jan Nieuwenhuizen wrote: >> Vagrant Cascadian writes: >>> Mes itself still fails to build I updated to b3fa6273210200cf2694491b07ed5a328e9a4e62 from upstream, added a few packaging updates, and... The current branch builds a package! https://salsa.debian.org/vagrant/mes A few test failures on amd64, but i386 tests run fine. Plenty of policy and lintian issues to sort out yet... but getting there. live well, vagrant
Bug#902174: #902174: RFP: mes
On 2019-06-10, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Mes itself still fails to build
...
>> configure fails to detect nyacc. It may be an issue
>> with multi-arch paths (e.g. /usr/lib/guile/2.2
>> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).
>
> Oops, that looks like a bug, thanks. I hope it's harmless...
The configure script still fails to detect nyacc (with version 0.86.0,
0.86.9, 0.92.0, 0.93.0 or 0.94.0):
checking for nyacc [0.86.0]... command[11]: ("/usr/bin/guile-2.2 -c
'(use-modules (nyacc lalr)) (display *nyacc-version*)'" "--version") => []
no
When I run the command from the commandline:
$ /usr/bin/guile-2.2 -c '(use-modules (nyacc lalr)) (display
*nyacc-version*)'
0.94.0
Same with any of the other versions of nyacc...
So not sure why ./configure is getting an empty result... how is
configure passing the "--version" argument?
>> Will need to do some better troubleshooting later... but this appears to
>> be the last build failure i tried based on the wip branch:
>>
>> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
>> ../include -I ../include/linux/x86_64 -static -o crt1.o
>> ../lib/linux/x86_64-mes-mescc/crt1.c
>> unhandled exception:unbound-variable:(move-specl-attr)
>> Backtrace:
>> /<>/scripts/mescc: line 56: 24904 Segmentation fault
>> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
>> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
>> make[1]: *** [GNUmakefile:95: build] Error 139
>
> This could be a problem with Nyacc 0.93.0, find a patch attached for
> that.
Patch seems to have fixed that issue.
After some aggressive patching for /bin/sh -> /bin/bash and using bash
-x, it manages to get further, but it still fails building libmes:
+ trace 'CC lib/libmes.c' /usr/bin/gcc -c -Wdate-time
-D_FORTIFY_SOURCE=2 -D POSIX=1 -D WITH_GLIBC=1 -D POSIX=1 -D
WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c
+ echo ' CC lib/libmes.c'
CC lib/libmes.c
+ shift
+ eval /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c '>>build.log'
'2>&1'
++ /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c
make[1]: *** [GNUmakefile:83: build] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:9: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned
exit status 2
I also tried without the hardening build flags, but no real difference.
live well,
vagrant
Bug#902174: #902174: RFP: mes
On 2019-05-19, Vagrant Cascadian wrote: > I made another pass at the Debian packaging needed for Mes. > > mescc-tools 0.6.1 builds fine for me: > > https://salsa.debian.org/vagrant/mescc-tools And uploaded, waiting in NEW: https://ftp-master.debian.org/new/mescc-tools_0.6.1-1.html live well, vagrant signature.asc Description: PGP signature
Bug#850644: #850644: RFP: Guix in Debian
Control: block 850644 by 902174 Status update: technically working package! Needs more work within Debian to actually include it... On 2019-05-16, Vagrant Cascadian wrote: > On 2018-05-16, Vagrant Cascadian wrote: >> The main build/runtime dependencies missing from Debian appear to be >> guile-git, and possibly a recommends on guile-ssh: >> >> https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html >> https://www.gnu.org/software/guix/manual/html_node/Requirements.html > > Apparently, guix has grown a few additional dependencies since then... > > So in a bit of a focused run of packaging, I've been chasing the > dependency chain necessary to get guix building on Debian: > > * guile-gnutls needs to be (re)enabled in libgnutls*: > > https://salsa.debian.org/vagrant/gnutls Proposed a patch to re-enable: https://bugs.debian.org/905272#29 > * guile-json needs to be updated to version 1.2.0 (3.x is incompatible), > and I've pushed wip branches updating packaging for new upstream > versions: > > https://salsa.debian.org/debian/guile-json Updated to 1.2.0 in Debian experimental. A little awkward not updating to the newest upstream version, but hopefully that won't last forever... > * I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and > guile-sqlite3 which need some more polish and then uploading to > Debian: > > https://salsa.debian.org/vagrant/guile-gcrypt > https://salsa.debian.org/vagrant/guile-sqlite3 Uploaded and waiting in NEW for review: https://ftp-master.debian.org/new/guile-gcrypt_0.1.0-1.html https://ftp-master.debian.org/new/guile-sqlite3_0.1.0-1.html > https://salsa.debian.org/vagrant/guile-git Waiting for guile-bytestructures to get through NEW. > https://salsa.debian.org/vagrant/guile-ssh This is WIP, packaging needs some policy compliance issues addressed. > * guile-git required scheme-bytestructures, which I've packaged, and > needs to be uploaded before guile-git can be: > > https://salsa.debian.org/vagrant/scheme-bytestructures Uploaded and waiting in NEW for review: https://ftp-master.debian.org/new/scheme-bytestructures_1.0.5-1.html > After all that, I did get to the point where I could at least try to > compile guix: > > https://salsa.debian.org/vagrant/guix With local builds of the above packages, I've got a working guix package! It still needs a way to get the bootstrap binaries (bash, mkdir, tar and xz) from Guix; right now they're binaries shipped in the source! Ludovic Courtès worked on a patch that would in theory download those at run-time, but that is not yet working... I tried with using symlinks to the host's bash, mkdir tar and xz, but that resulted in the symlink getting copied into the store, which meant that the package build environment only ended up included a dead symlink and failed to build. Additionally, not using the exact same bootstrap binaries means that Guix's substitute servers would produce different results for all packages, and so substitutes wouldn't be able to be very useful. Bootstrapping the system with MES is also WIP in Guix, and it might be possible to build identical bootstrap binaries using MES in Debian at some point: https://bugs.debian.org/902174 The guix packaging for Debian also has a small number of test failures, at least one of which simply needs to be disabled because it accesses the network (which violates Debian policy). Also needs some updates to the packaging to get the guix-daemon running out of the box, for which there's a provided systemd service, and adding some guixbuild users, which shouldn't be too hard. So, still a lot to be done, but considerable progress! live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2019-02-13, Jan Nieuwenhuizen wrote:
> I have resurrected the debian package descriptions for Nyacc,
> MesCC-tools and Mes, and updated them to the latest versions.
I made another pass at the Debian packaging needed for Mes.
mescc-tools 0.6.1 builds fine for me:
https://salsa.debian.org/vagrant/mescc-tools
Upstream nyacc 0.86.0, 0.86.9 and 0.92.0 all build fine for me:
https://salsa.debian.org/vagrant/nyacc
There are two branches wip/debian/master-0.86.x and
wip/debian/master-0.92.x.
Mes itself still fails to build, but I updated to 0.19, and made a
branch based off of janneke's wip branch as well
(debian/master-wip). configure fails to detect nyacc. It may be an issue
with multi-arch paths (e.g. /usr/lib/guile/2.2
vs. /usr/lib/x86_64-linux-gnu/guile/2.2).
Many of the '#! /bin/sh' scripts contain bashisms which may not be
compatible with Debian's (usual) /bin/sh, dash after a quick check with
"checkbashisms". I could patch all the #! headers and audit all the
calls to "sh" directly, but that seems a bit unmaintainable in the
long-run.
Will need to do some better troubleshooting later... but this appears to
be the last build failure i tried based on the wip branch:
../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
../include -I ../include/linux/x86_64 -static -o crt1.o
../lib/linux/x86_64-mes-mescc/crt1.c
unhandled exception:unbound-variable:(move-specl-attr)
Backtrace:
/<>/scripts/mescc: line 56: 24904 Segmentation fault
${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
/usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
make[1]: *** [GNUmakefile:95: build] Error 139
live well,
vagrant
signature.asc
Description: PGP signature
Bug#929095: ITP: scheme-bytestructures -- Structured access to bytevector contents
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: scheme-bytestructures or guile-bytestructures Version : 1.0.5 Upstream Author : Taylan Ulrich Bayırlı/Kammer * URL or Web page : https://github.com/TaylanUB/scheme-bytestructures/ * License : GPL-3+, LGPL-3+ Description : Structured access to bytevector contents This library offers a system imitating the type system of the C programming language, to be used on bytevectors. C's type system works on raw memory, and ours works on bytevectors which are an abstraction over raw memory in Scheme. The system is in fact more powerful than the C type system, elevating types to first-class status. First draft of packaging: https://salsa.debian.org/vagrant/scheme-bytestructures This is a dependency to package guile-git: https://bugs.debian.org/929094 live well, vagrant signature.asc Description: PGP signature
Bug#929094: ITP: guile-git -- guile bindings for git
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-git Version : 0.2.0 Upstream Author : Amirouche Boubekki * URL or Web page : https://gitlab.com/guile-git/guile-git/ * License : GPL-3+, LGPL-3+, GFDL-1.3+ (with exceptions), others Description : guile bindings for git Guile-Git is a GNU Guile library providing bindings to libgit2. First draft of packaging: https://salsa.debian.org/vagrant/guile-git This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929093: ITP: guile-ssh -- guile bindings to ssh
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-ssh Version : 0.11.3 Upstream Author : Artyom V. Poptsov * URL or Web page : https://github.com/artyom-poptsov/guile-ssh/ * License : GPL-3+, Expat, LGPL-3+, and more! Description : guile bindings to ssh Guile-SSH is a library that provides access to the SSH protocol for programs written in GNU Guile interpreter. It is built upon the libssh library. First draft of packaging: https://salsa.debian.org/vagrant/guile-ssh This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929092: ITP: guile-sqlite3 -- guile bindings for sqlite3
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-sqlite3 Version : 0.1.0 Upstream Author : Andy Wingo * URL or Web page : https://notabug.org/guile-sqlite3/guile-sqlite3 * License : LGPL-3+, GPL-3+ Description : guile bindings for sqlite3 Guile bindings for the SQLite3 database engine. First draft of packaging: https://salsa.debian.org/vagrant/guile-sqlite3 This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#929091: ITP: guile-gcrypt -- gcrypt bindings for guile
Package: wnpp Owner: Vagrant Cascadian Severity: wishlist * Package name: guile-gcrypt Version : 0.1.0 Upstream Author : Christopher Allan Webber and others * URL or Web page : https://notabug.org/cwebber/guile-gcrypt * License : GPL-3+, Expat, GFDL-1.3+ (with exceptions) Description : gcrypt bindings for guile Guile-Gcrypt provides a Guile 2.x interface to a subset of the GNU Libgcrypt crytographic library, which is itself used by the GNU Privacy Guard (GPG). Guile-Gcrypt provides modules for cryptographic hash functions, message authentication codes (MAC), public-key crytography, strong randomness, and more. It is implemented using the foreign function interface (FFI) of Guile. First draft of packaging: https://salsa.debian.org/vagrant/guile-gcrypt This is a dependency to package GNU Guix: https://bugs.debian.org/850644 live well, vagrant signature.asc Description: PGP signature
Bug#850644: #850644: RFP: guix -- A functional package manager based on Scheme
Control: block 850644 by 863147 On 2019-05-16, Vagrant Cascadian wrote: > * guile-gnutls needs to be (re)enabled in libgnutls*: > > https://salsa.debian.org/vagrant/gnutls This is apparently marked as wontfix back in 2016 due to intermittant test failues: https://bugs.debian.org/863147 Though at the time it was using guile-2.0; maybe guile-2.2 passes the tests more reliably? Ask nicely to enable in experimental? Hrm. live well, vagrant signature.asc Description: PGP signature
Bug#850644: #850644: RFP: guix -- A functional package manager based on Scheme
On 2018-05-16, Vagrant Cascadian wrote: > The main build/runtime dependencies missing from Debian appear to be > guile-git, and possibly a recommends on guile-ssh: > > https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html > https://www.gnu.org/software/guix/manual/html_node/Requirements.html Apparently, guix has grown a few additional dependencies since then... So in a bit of a focused run of packaging, I've been chasing the dependency chain necessary to get guix building on Debian: * guile-gnutls needs to be (re)enabled in libgnutls*: https://salsa.debian.org/vagrant/gnutls * guile-json needs to be updated to version 1.2.0 (3.x is incompatible), and I've pushed wip branches updating packaging for new upstream versions: https://salsa.debian.org/debian/guile-json * I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and guile-sqlite3 which need some more polish and then uploading to Debian: https://salsa.debian.org/vagrant/guile-git https://salsa.debian.org/vagrant/guile-gcrypt https://salsa.debian.org/vagrant/guile-ssh https://salsa.debian.org/vagrant/guile-sqlite3 * guile-git required scheme-bytestructures, which I've packaged, and needs to be uploaded before guile-git can be: https://salsa.debian.org/vagrant/scheme-bytestructures After all that, I did get to the point where I could at least try to compile guix: https://salsa.debian.org/vagrant/guix But no successful build just yet. Whew! live well, vagrant signature.asc Description: PGP signature
Bug#928724: ITP: opensbi -- RISC-V Open Source Supervisor Binary Interface
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian X-Debbugs-Cc: debian-de...@lists.debian.org, mer...@debian.org, debian-ri...@lists.debian.org * Package name: opensbi Version : 0.3+ Upstream Author : Anup Patel/Western Digital, other contributors * URL : https://github.com/riscv/opensbi * License : BSD-2, Apache 2.0, GPL-2+ Programming Lang: C Description : RISC-V Open Source Supervisor Binary Interface The **RISC-V Supervisor Binary Interface (SBI)** is the recommended interface between: 1. A platform-specific firmware running in M-mode and a bootloader, a hypervisor or a general-purpose OS executing in S-mode or HS-mode. 2. A hypervisor running in HS-mode and a bootloader or a general-purpose OS executing in VS-mode. The *RISC-V SBI specification* is maintained as an independent project by the RISC-V Foundation on [Github] (https://github.com/riscv/riscv-sbi-doc). The goal of the OpenSBI project is to provide an open-source reference implementation of the RISC-V SBI specifications for platform-specific firmwares executing in M-mode (case 1 mentioned above). An OpenSBI implementation can be easily extended by RISC-V platform and system-on-chip vendors to fit a particular hardware configuration. ... An SBI implementation is needed in order to boot RISC-V systems. This package initially will at least enable loading u-boot in qemu sufficient to boot a linux kernel and initramfs. A similar project is the RISC-V Proxy Kernel and Boot Loader (a.k.a. BBL): https://github.com/riscv/riscv-pk But BBL requires a compilation step to embed the bootloader and/or kernel into a payload every time you upgrade the kernel and/or bootloader. It is possible with OpenSBI to load an arbitrary payload without requiring a compilation step in some cases (e.g. qemu). Karsten Merker has offered to co-maintain (who has also been contributing upstream); not sure if we'll need a team just yet. Initial rough cut of packaging: https://salsa.debian.org/vagrant/opensbi It cross-compiles an arch:all firmware image usable with qemu+u-boot. Help with improving the package description and a few remaining lintian issues would be great! live well, vagrant signature.asc Description: PGP signature
Bug#881620: ITP: arm-trusted-firmware -- reference implementation of secure world software for ARMv8-A
I've got this packaged from an upstream git commit sufficient to replace atf-allwinner; it even reliably powers off on the pinebook! https://salsa.debian.org/debian/arm-trusted-firmware It's currently only building the sun50i_a64 target, since that's the one I've tested on pinebook and pine64+, but there are a few more upstream supports that might be possible to enable, if someone could test them. Hoping to upload soon... live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2018-07-08, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Packaging branch for nyacc:
>>
>> https://salsa.debian.org/vagrant/nyacc
>>
>> Fails to build as it installs info pages to /share/info. Doesn't appear
>> to respect DESTDIR= ... but setting --infodir doesn't work as I would
>> expect either, suddently appending --prefix to it.
>
> I have looked into this; please see `debian' branch at
>
> http://gitlab.com/janneke/nyacc
Built!
>> And also a packaging branch for mes itself, but of course can't test it
>> until nyacc is working:
>>
>> https://salsa.debian.org/vagrant/mes
>
> I will have a look at this later. You will probably want to rebase on
> my `wip-gnu' branch: it has (experimental) DESTDIR and other Debian
> build support (e.g.: do not assume /bin/sh is bash, resurrect guile-2.0).
Tried building with this, and had a couple issues.
The clean target assumes a git checkout:
clean:
git clean -dfx
But Debian builds against tarballs of the source, and running 'git clean
-dfx' from a directory with the source unpackaged but no .git directory
fails.
The configure target doesn't take some common options, and fails when
unknown options are passed, such as --includedir. The default build
passed these:
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking
From the ./configure help output, it suggests that only --prefix and
--sysconfdir are supported, but maybe not all the supported options are
documented.
Working around that by only passing:
./configure --prefix=/usr --sysconfdir=/etc
And a no-op clean target...
Still fails to build:
build-aux/build-cc.sh
...
;;; WARNING: compilation of
/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm failed:
;;; ERROR: failed to create path for auto-compiled file
"/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm"
mes-snarf[guile]...
lib/libmes.c:21:10: fatal error: libmes.h: No such file or directory
#include
^~
compilation terminated.
make[2]: *** [GNUmakefile:39: cc] Error 1
make[2]: Leaving directory '/<>/mes-0.16+0.3da4d01'
make[1]: *** [GNUmakefile:123: src/mes.gcc-out] Error 2
make[1]: *** Waiting for unfinished jobs
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm
;;; WARNING: compilation of
/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm failed:
;;; ERROR: failed to create path for auto-compiled file
"/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm"
mes-snarf[guile]...
lib/libmes.c:21:10: fatal error: libmes.h: No such file or directory
#include
^~
compilation terminated.
make[1]: *** [GNUmakefile:36: build] Error 1
make[1]: Leaving directory '/<>/mes-0.16+0.3da4d01'
dh_auto_build: make -j4 returned exit code 2
So, some progress, but still some work left to do! :)
live well,
vagrant
signature.asc
Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2018-07-08, Jan Nieuwenhuizen wrote: > Vagrant Cascadian writes: > > @Matt: some Nyacc patches attached. > >>> I took a quick stab at this, and it first requires packaging: ... >> Packaging branch for nyacc: >> >> https://salsa.debian.org/vagrant/nyacc >> >> Fails to build as it installs info pages to /share/info. Doesn't appear >> to respect DESTDIR= ... but setting --infodir doesn't work as I would >> expect either, suddently appending --prefix to it. > > I have looked into this; please see `debian' branch at > > http://gitlab.com/janneke/nyacc Thanks! > I have created patches for Nyacc to aid Debian packaging; see attached. > They are on my debian branch, as well as on my master. I also made some > WIP changes to the debian packaging: most notably: I could not find > guile-2.2. guile-2.2 is in Debian testing and unstable, though guile-2.0 is in stable, testing and unstable. For upload to Debian, it would probably be best to use the newest guile version available, unless there's a compelling reason to use guile-2.0, or possibly work the package to support both guile-2.2 and guile-2.0. >> And also a packaging branch for mes itself, but of course can't test it >> until nyacc is working: >> >> https://salsa.debian.org/vagrant/mes > > I will have a look at this later. You will probably want to rebase on > my `wip-gnu' branch: it has (experimental) DESTDIR and other Debian > build support (e.g.: do not assume /bin/sh is bash, resurrect guile-2.0). Will take a look, thanks! live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2018-07-06, Vagrant Cascadian wrote: > On 2018-06-22, Geert Stappers wrote: >> Package name : mes >> Version : 0.15 >> Upstream Author : Jan Nieuwenhuizen >> URL : https://gitlab.com/janneke/mes >> License : GNU GPLv3 >> Programming Lang : C >> Description : Maxwell Equations of Software >> >> Mes aims to help create full source bootstrapping for GuixSD as part >> of the bootstrappable builds effort. > > I took a quick stab at this, and it first requires packaging: > > https://github.com/oriansj/mescc-tools Packaging branch for mescc-tools: https://salsa.debian.org/vagrant/mescc-tools Compiles, maybe it even works! > https://gitlab.com/janneke/nyacc Packaging branch for nyacc: https://salsa.debian.org/vagrant/nyacc Fails to build as it installs info pages to /share/info. Doesn't appear to respect DESTDIR= ... but setting --infodir doesn't work as I would expect either, suddently appending --prefix to it. And also a packaging branch for mes itself, but of course can't test it until nyacc is working: https://salsa.debian.org/vagrant/mes live well, vagrant signature.asc Description: PGP signature
Bug#902174: #902174: RFP: mes
On 2018-06-22, Geert Stappers wrote: > Package name : mes > Version : 0.15 > Upstream Author : Jan Nieuwenhuizen > URL : https://gitlab.com/janneke/mes > License : GNU GPLv3 > Programming Lang : C > Description : Maxwell Equations of Software > > Mes aims to help create full source bootstrapping for GuixSD as part > of the bootstrappable builds effort. I took a quick stab at this, and it first requires packaging: https://github.com/oriansj/mescc-tools https://gitlab.com/janneke/nyacc live well, vagrant signature.asc Description: PGP signature
Bug#850644: RFP: guix -- A functional package manager based on Scheme
There does appear to be a more recent effort at packaging guix for Debian: https://github.com/detrout/debian-guix Though it's already over a year old... The main build/runtime dependencies missing from Debian appear to be guile-git, and possibly a recommends on guile-ssh: https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html https://www.gnu.org/software/guix/manual/html_node/Requirements.html I have some interest in helping with packaging this... but not enough to tackle it alone. :) live well, vagrant signature.asc Description: PGP signature
Bug#895057: RFH: ltsp -- network booted thin and fat clients
Package: wnpp Severity: normal It has been several years since I've actually maintained a real-world deployment of LTSP, and there are very few other active developers of the project upstream. I have continued to maintain it in Debian as best I can, and would love to see it continue to be supported in Debian, but would really need some active co-maintainers to keep it viable long-term. Right now there is an RC bug regarding support for the transition to FreeRDP2 (which I've never used): https://bugs.debian.org/892626 Of course there are a few other bugs in Debian and upstream. The main source packages affected are ltsp, ldm, ltspfs and the much-neglected ltsp-docs. There's also ltsp-manager, currently only in experimental, which is an attempt to simplify installation and management of LTSP environments. Another source package is libpam-sshauth, which is a major piece of an attempt to replace the deficiencies of LDM with a regular display manager using PAM... this has long been on the plans for a next generation LTSP, but hasn't gotten beyond the proof of concept phase. I've CCed debian-edu in the bug report, as that project has some of the largest active users of ltsp in Debian that I'm aware of. live well, vagrant signature.asc Description: PGP signature
Bug#881620: ITP: arm-trusted-firmware -- reference implementation of secure world software for ARMv8-A
On 2018-04-02, Domenico Andreoli wrote: > I've a NanoPI NEO2 (Allwinner H5) and I'd like to seamlessly install > Debian on it. I'm just working at the build of u-boot-sunxi and at > u-boot-install-sunxi64 but I see that the proper solution goes throught > packaging ATF and here we are. You probably want to follow-up with the atf-allwinner package already in Debian: https://tracker.debian.org/pkg/atf-allwinner It's a vendor fork of the upstream arm-trusted-firmware, and I've confirmed it works for the Allwinner A64 on pine64 and pinebook; not sure what the status of H5 support is like, though it is a similar SoC. Once H5 support is in atf-allwinner, u-boot-sunxi and u-boot-install-sunxi64 may need updates to support your board: https://wiki.debian.org/U-boot Regarding upstream arm-trusted-firmware that this ITP is about, while I can get it to build for a few targets, I have yet to suceed in getting anything using it to actually boot, so I haven't uploaded it to Debian yet... Good luck! live well, vagrant signature.asc Description: PGP signature
Bug#881620: ITP: arm-trusted-firmware -- reference implementation of secure world software for ARMv8-A
Package: wnpp Owner: Vagrant Cascadian <vagr...@debian.org> Severity: wishlist * Package name: arm-trusted-firmware Version : 1.4 Upstream Author : ARM Limited and Contributors * URL or Web page : https://github.com/ARM-software/arm-trusted-firmware/ * License : BSD-2-Clause, BSD-3-Clause, Expat, ISC Description : reference implementation of secure world software for ARMv8-A ARM Trusted Firmware provides a reference implementation of secure world software for `ARMv8-A`_, including a `Secure Monitor`_ executing at Exception Level 3 (EL3). It implements various ARM interface standards, such as: - The `Power State Coordination Interface (PSCI)`_ - Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1) - `SMC Calling Convention`_ - `System Control and Management Interface`_ As far as possible the code is designed for reuse or porting to other ARMv8-A model and hardware platforms. ARM will continue development in collaboration with interested parties to provide a full reference implementation of Secure Monitor code and ARM standards to the benefit of all developers working with ARMv8-A TrustZone technology. -- This is needed to boot various arm64 boards (pine64, firefly-rk3399) that may not have built-in firmware shipped with them, possibly in conjunction with an EFI implementation or u-boot. Some considerations when packaging this: - Not all vendors are merged upstream; there are several vendor-specific forks that are needed in order to support specific hardware, such as support for allwinner A64: https://github.com/apritzel/arm-trusted-firmware I would definitely need some help with initial and long-term maintenance to make this a reality... live well, vagrant signature.asc Description: PGP signature
Bug#641768: lightdm-webkit-engine
There's a webkit2 greeter for lightdm with recent activity: https://github.com/Antergos/lightdm-webkit2-greeter We might consider using it for LTSP6, and then would need to get it packaged in Debian. live well, vagrant signature.asc Description: PGP signature
Bug#760314: #760314: RFH: zoneminder maintenance in Debian
On 2014-11-25, Vagrant Cascadian wrote: On 2014-11-25, Peter Howard wrote: we should start using a git repo for the debian-specific work. Vagrant - can you set up a git repo for ZM and clone from ZM upstream? We can then bring over the debian directory, apply the recent NMU patches, and make that the basis for further work. Yeah, I can migrate it over to git, and at least preserve some of the history. I've actually been using git-remote-hg lately, but the histories of the repositories are different... but I can probably get them both into one repository, even if I have to use a hammer. Ok, hammered them together using git merge -X theirs v1.28.0 followed up with removing files not present upstream (other than the debian dir, obviously), and uploaded the repository to collab-maint git. There were a few upstream tags that conflicted with the tags generated from mercurial, I kept the upstream ones. Isaac, you'll want to get an alioth account and get yourself added to the collab-maint group: https://alioth.debian.org/account/register.php https://wiki.debian.org/Alioth/PackagingProject When you've got an account, I can send the mail to NM. Information about accessing alioth git repositories: https://wiki.debian.org/Alioth/Git The repository should be available here, once it's done syncing: git clone git://git.debian.org/git/collab-maint/zoneminder.git Web frontend: https://anonscm.debian.org/cgit/collab-maint/zoneminder.git/ I'd say we branch from the 1.28 release and then make a _quick_ upload of that, then work on a nice version. Vagrant, if you're around to do the actual upload, I'll coordinate with Isaac to get him going with the debian-specific builds. I'm also happy to help with packaging and sponsoring the occasional upload. I didn't update the packaging to 1.28.0, but the master branch on alioth has 1.28.0 upstream merged in. Not sure how much work it will be to update the packaging, but happy to help. Also, might want to consider some of the proposed naming conventions laid out in: http://dep.debian.net/deps/dep14/ Thanks for helping out with zoneminder! live well, vagrant signature.asc Description: PGP signature
Bug#760314: #760314: RFH: zoneminder maintenance in Debian
On 2014-11-25, Peter Howard wrote: we should start using a git repo for the debian-specific work. Vagrant - can you set up a git repo for ZM and clone from ZM upstream? We can then bring over the debian directory, apply the recent NMU patches, and make that the basis for further work. Yeah, I can migrate it over to git, and at least preserve some of the history. I've actually been using git-remote-hg lately, but the histories of the repositories are different... but I can probably get them both into one repository, even if I have to use a hammer. I'd say we branch from the 1.28 release and then make a _quick_ upload of that, then work on a nice version. Vagrant, if you're around to do the actual upload, I'll coordinate with Isaac to get him going with the debian-specific builds. I'm also happy to help with packaging and sponsoring the occasional upload. I'm also wondering if it would be feasible to get upstream's make/cmake files to a state where the debian/rules file can just be the simple two-liner. live well, vagrant signature.asc Description: PGP signature
Bug#760314: #760314: RFH: zoneminder maintenance in Debian
On 2014-11-06, Isaac Connor wrote: Our intention as upstream maintainers is to work with all distros to not only make zm as good as it can be, but to also minimize the effort on the part of distros to package it. Yes, that's the one thing that made me consider continued maintenance... I tend to do my part for debian based distros and have reached out to Howard to help ease his burden. I do not feel qualified to take up maintainership however. It doesn't seem like anyone does at this point... *sigh* Not sure what channels tend to get the most activity in the zoneminder community, but it might be good to try and actively reach out. Without an active maintainer, it's just lingering on in Debian unstable. I've thought about doing one last upload, but then realised it's probably more honest to leave it in the current unusable state... In any event, I will monitor and address issues in the debian bug system and do my best to make packaging zm as easy as possible. Thanks! live well, vagrant signature.asc Description: PGP signature
Bug#760314: RFH: zoneminder
Package: wnpp Severity: normal Zoneminder maintenance has fallen behind; neither myself nor Peter Howard seem to have enough time to maintain it properly. I no longer use zoneminder at work. Another maintainer, ideally one who actively uses zoneminder, is probably long overdue... Homepage: http://www.zoneminder.com/ Description: Linux video camera security and surveillance solution ZoneMinder is intended for use in single or multi-camera video security applications, including commercial or home CCTV, theft prevention and child or family member or home monitoring and other care scenarios. It supports capture, analysis, recording, and monitoring of video data coming from one or more video or network cameras attached to a Linux system. ZoneMinder also support web and semi-automatic control of Pan/Tilt/Zoom cameras using a variety of protocols. It is suitable for use as a home video security system and for commercial or professional video security and surveillance. It can also be integrated into a home automation system via X.10 or other protocols. It's written in Perl, C (maybe C++?), PHP and javascript. It's got a web frontend, and stores events in a database backend. There are at least two RC bugs fixed in VCS/experimental; haven't had the time to do an upload or a good setup to test with, and another that might be fixable with a newer upstream version, or at least downgraded with some testing to verify it only applies to specific cameras. VCS is in collab-maint: http://hg.debian.org/hg/collab-maint/zoneminder Upstream has recently (well, the last year or so) gotten new developers, and has been commenting on several of the bugs in Debian's bug tracking system. Upstream VCS: https://github.com/zoneminder/zoneminder live well, vagrant pgplRMw3qaiHv.pgp Description: PGP signature
Bug#760025: RFP: xserver-xorg-video-fbturbo -- X.Org X server -- fbturbo display driver
Package: wnpp Severity: wishlist * Package name: xserver-xorg-video-fbturbo Version : 0.5.1 Upstream Author : Siarhei Siamashka siarhei.siamas...@gmail.com and others * URL : https://github.com/ssvb/xf86-video-fbturbo * License : GPL2+, MIT/X Programming Lang: C Description : X.Org X server -- fbturbo display driver Essentially, xf86-video-fbturbo can be just used as a drop-in replacement and run on practically any Linux system. There will be no real difference on x86, but any ARM based system should see better performance thanks to some additional optimizations (the elimination of ShadowFB layer, ARM NEON/VFP code for dealing with uncached framebuffer reads, automatic backing store management for faster window moves). I'm not really in a position to maintain this, but it provides significant performance boost on arm systems over the fbdev driver. live well, vagrant pgpf6GMwe9g95.pgp Description: PGP signature
Bug#702697: ITP: git-remote-bzr -- bidirectional bridge between Git and Bazaar
Control: tags 702697 pending Uploaded, waiting in NEW... live well, vagrant signature.asc Description: Digital signature
Bug#702697: ITP: git-remote-bzr -- bidirectional bridge between Git and Bazaar
On Thu, Jul 03, 2014 at 12:16:49PM +0800, Paul Wise wrote: On Wed, 2014-07-02 at 20:54 -0700, Vagrant Cascadian wrote: It's basically an updated version of Sven's packaging with a git-bzr transitional package and the real git-remote-bzr package, against the current git-remote-bzr git. As I said at the URL below I don't know when I'll get to this so please feel free to take over the packaging of git-remote-bzr / git-remote-hg. Ok, well, I'll upload git-remote-bzr then (no real interest in git-remote-hg). Set up a git repository in collab-maint: https://anonscm.debian.org/gitweb/?p=collab-maint/git-remote-bzr.git;a=summary I've added the both of you to Uploaders, as you'd expressed interest in co-maintaining. If I should remove either before upload, let me know. live well, vagrant signature.asc Description: Digital signature
Bug#702697: RFP: git-remote-bzr -- bidirectional bridge between Git and Bazaar
On Thu, May 29, 2014 at 11:52:29AM +0800, Paul Wise wrote: On Wed, 2014-05-28 at 10:21 -0700, Jonathan Nieder wrote: Thanks. I also wouldn't mind co-maintaining since bugs may sometimes point to issues in git's remote helper code. Excellent, thanks. I'd also be interested in helping with this package. What Sven said makes sense to me: a single source package with a transitional git-bzr package that depends on the main git-remote-bzr package. Then only the git-bzr package would need an epoch. git-bzr was never part of a stable release so it would just be needed for a little while for people using sid, testing, or stable-backports. It's not necessarily needed in the jessie release. Agreed but I think it would be best to have the transitional package built from the git source package. Having different versions for different binary packages created from the same source package is possible but it is very confusing. Wheezy never shipped git-bzr, although it is present in wheezy-backports. A transitional package for something never provided in a stable release maybe seems like more trouble than it's worth, if that's the main thing blocking upload. If a transitional package is definitely needed, I'm of the opinion that it's better to ship the transitional package in the new source package, as then you don't need to coordinate uploads between two source packages when it comes time to drop the transitional package. I'd be willing to actually work on the differing versions, if needed. It seems to be a fairly straightforward package, really. Sven's packaging seemed to work fine for me. There aren't many files for copyright review. How can I help? live well, vagrant signature.asc Description: Digital signature
Bug#702697: ITP: git-remote-bzr -- bidirectional bridge between Git and Bazaar
On Wed, Jul 02, 2014 at 05:01:15PM -0700, Vagrant Cascadian wrote:
On Thu, May 29, 2014 at 11:52:29AM +0800, Paul Wise wrote:
On Wed, 2014-05-28 at 10:21 -0700, Jonathan Nieder wrote:
...
If a transitional package is definitely needed, I'm of the opinion that it's
better to ship the transitional package in the new source package, as then you
don't need to coordinate uploads between two source packages when it comes
time
to drop the transitional package. I'd be willing to actually work on the
differing versions, if needed.
It seems to be a fairly straightforward package, really. Sven's packaging
seemed to work fine for me. There aren't many files for copyright review. How
can I help?
Once I got the idea in my head, I couldn't help myself:
https://anonscm.debian.org/gitweb/?p=users/vagrant/git-remote-bzr.git
It's basically an updated version of Sven's packaging with a git-bzr
transitional package and the real git-remote-bzr package, against the current
git-remote-bzr git.
live well,
vagrant
commit 20e92aeeea7ccec21a9556bdd3b65fcd5d5d491b
Author: Vagrant Cascadian vagr...@debian.org
Date: Wed Jul 2 20:31:26 2014 -0700
Add debian dir, based on work from Sven Joachim from:
https://bugs.debian.org/702697
diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 000..2fa5064
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,12 @@
+git-remote-bzr (0.2+20140702~1-1) UNRELEASED; urgency=low
+
+ [ Sven Joachim ]
+ * Initial release (Closes: #702697).
+
+ [ Vagrant Cascadian ]
+ * Upstream version from git snapshot.
+ * Refreshed locale patch.
+ * Add git-bzr transitional package.
+ * Updated debian/copyright.
+
+ -- Vagrant Cascadian vagr...@debian.org Wed, 02 Jul 2014 19:54:42 -0700
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 000..ec63514
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/debian/control b/debian/control
new file mode 100644
index 000..f3242ff
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,33 @@
+Source: git-remote-bzr
+Section: vcs
+Priority: extra
+Maintainer: Debian QA Group packa...@qa.debian.org
+Build-Depends: debhelper (= 9)
+Build-Depends-Indep: asciidoc, xmlto,
+# Needed for the testsuite
+ bzr, git, python, python-bzrlib
+Standards-Version: 3.9.5
+Homepage: https://github.com/felipec/git-remote-bzr
+#Vcs-Git: git://git.debian.org/collab-maint/git-remote-bzr.git
+#Vcs-Browser: http://git.debian.org/?p=collab-maint/git-remote-bzr.git;a=summary
+
+Package: git-remote-bzr
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}, git, python, python-bzrlib
+Suggests: git-doc, bzr
+Conflicts: bzr-git
+Breaks: git-bzr ( 2:${source:Version})
+Replaces: git-bzr
+Description: bidirectional bridge between Git and Bazaar
+ This package provides the bzr remote helper, which allows Git to
+ read from and write to Bazaar repositories as though they were remote
+ Git repositories.
+
+Package: git-bzr
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}, git-remote-bzr,
+Description: transitional package
+ Transitional package to install git-remote-bzr.
+
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 000..a8f1d52
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,35 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: git-remote-bzr
+Source: https://github.com/felipec/git-remote-bzr
+
+Files: *
+Copyright: 2012-2014 Felipe Contreras
+License: GPL-2.0+
+
+Files: test/sharness.sh
+Copyright: 2005-2012 Junio C Hamano
+ 2011-2012 Mathias Lafeldt
+ 2005-2012 Git project
+License: GPL-2.0+
+
+Files: debian/*
+Copyright: 2014 Sven Joachim svenj...@gmx.de
+ 2014 Vagrant Cascadian vagr...@debian.org
+License: GPL-2.0+
+
+License: GPL-2.0+
+ This package is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ .
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+ .
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License version 2 can be found in /usr/share/common-licenses/GPL-2.
diff --git a/debian/git-remote-bzr.docs b/debian/git-remote-bzr.docs
new file mode 100644
index 000..2ed350c
--- /dev/null
+++ b/debian/git-remote-bzr.docs
@@ -0,0 +1 @@
+README.asciidoc
diff --git a/debian/patches/debian-locale.diff b/debian/patches/debian-locale.diff
new file mode 100644
index 000..285f157
--- /dev/null
+++ b/debian/patches/debian-locale.diff
@@ -0,0 +1,38 @@
+Description: Use C.UTF-8 locale
Bug#738446: RFA: u-boot -- A boot loader for embedded systems
On Sun, Feb 09, 2014 at 06:11:52PM +, Clint Adams wrote: I request an adopter for the u-boot package. I can continue to put some time into it, and have handled the last several uploads, although I can only test and maintain a small number of available targets. Would formally making it team-maintained be a good idea? live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140221235929.gn32...@cascadia.debian.net
Bug#646971: ITP: epoptes -- Computer lab management tool
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian vagr...@debian.org * Package name: epoptes Version : 0.3.0 Upstream Author : Alkis Georgopoulos alk...@gmail.com, Fotis Tsamis ftsa...@gmail.com * URL : http://www.epoptes.org/ * License : GPL Programming Lang: Python, bash Description : Computer lab management tool It allows for screen broadcasting and monitoring, remote command execution, message sending, imposing restrictions like screen locking or sound muting the clients and much more! live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111028192208.GH26987@talon.fglan
Bug#640786: replacing Perspectives extension with Convergence?
On Wed, Sep 14, 2011 at 10:41:52AM +0200, berta...@ptitcanardnoir.org wrote: On Mon, Sep 12, 2011 at 02:42:48PM -0700, Vagrant Cascadian wrote: it appears someone has already filed an ITP for convergence: #640786 i've got a git branch too, but haven't pushed it anywhere just yet (what am i waiting for?). pushed my branch here: http://anonscm.debian.org/gitweb/?p=users/vagrant/convergence.git i made a single source package of both the extension and the notary server, since upstream is maintaining them in a single git tree. although really it seems like it might make more sense to maintain them as two separate source packages. I've refrained myself to send this ITP for days, thinking someone would probably do it at some point. But so far no one did so I finally decided to send it. It's nice to see that this bug attract people that have been working on the packaging. indeed. If we are several people interested to work on this, maybe we can setup a team and a git on alioth, or maybe join the pkg-mozext-maintainers team and use their infrastructure. What do you think? definitely should have some sort of team infrastructure, although the notary server code might be outside of what the pkg-mozext-maintainers team normally handles. not sure what would be best. i should also mention that upstream is not so sure we should package for debian until development slows a bit, expecting multiple new versions a week. if we did upload to debian, experimental might be most appropriate. that said, it seems like perspectives shouldn't necessarily be removed the moment convergence hits debian; it's a little more field tested. live well, vagrant p.s. i've subscribed to the bug report myself, so no need to CC me if you're CCing the bug report. i left most folks out of the CC list; hope that's ok. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110919211315.GL12453@talon.fglan
Bug#640786: replacing Perspectives extension with Convergence?
it appears someone has already filed an ITP for convergence: #640786 i've got a git branch too, but haven't pushed it anywhere just yet (what am i waiting for?). live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110912214248.GG12453@talon.fglan
Bug#540362: O: xfs -- X font server
On Mon, Jul 18, 2011 at 10:22:05PM +0200, Moritz Muehlenhoff wrote: On Fri, Aug 07, 2009 at 03:58:50PM +0200, Julien Cristau wrote: The X Strike Force would like to get rid of xfs; it's not needed in most (all?) use cases, since most X clients now use Xft and/or pango to render text, not core X fonts (even emacs, these days! :)) So xfs wants to either get removed or get a new maintainer. Maybe LTSP people, if they still use this? Adding LTSP maintainers to CC; is xfs (the font server, not the filesystem) still in use in LTSP? LTSP works fine without XFS. I think debian-edu may still be using it, as it's recommended in education-thin-client-server. no idea if it's actually used. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719100657.GG22260@talon.fglan
Bug#626837: RFP: libsys-mmap-perl
Package: wnpp Severity: wishlist * Package name: libsys-mmap-perl Version : 0.15 Upstream Author : Todd Rinaldo to...@cpan.org * URL : http://search.cpan.org/~toddr/Sys-Mmap/ * License : GPL Artistic Programming Lang: Perl Description : Sys::Mmap - uses mmap to map in a file as a Perl variable The Mmap module uses the POSIX mmap call to map in a file as a Perl variable. Memory access by mmap may be shared between threads or forked processes, and may be a disc file that has been mapped into memory. Sys::Mmap depends on your operating system supporting UNIX or POSIX.1b mmap, of course. not sure i'd be able to tackle packaging and maintaining this myself, but may be necessary for future versions of zoneminder, which i've been co-maintaining. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110515192416.GE9959@talon.fglan
Bug#616466: ITP: xul-ext-perspectives -- verify HTTPS sites through notary servers
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian vagr...@debian.org * Package name: xul-ext-perspectives Version : 4.1 Upstream Author : Dan Wendlandt and others * URL : http://www.cs.cmu.edu/~perspectives * License : GPL VCS : git://github.com/danwent/Perspectives.git Description : verify HTTPS sites through notary servers Perspectives is an approach to help clients securely identify Internet servers in order to avoid man-in-the-middle attacks, by querying network notaries located in multiple vantage points across the Internet. . This extension enables bypassing HTTPS security warnings when appropriate. perspectives uses multiple network notary servers to track sites over time and from different networks to establish additional information about the consistancy of certificates presented to the browser, and can be used to override security exceptions in some cases. projects such as monkeysphere allow somewhat similar functionality, although monkeysphere requires the user to be well connected in the GPG web of trust in order to be useful, whereas perspectives uses trusted notaries which require little to no configuration to the end user. i'd like to package the firefox extension which seems to be straightforward, and eventually the notary servers as well. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304174653.GQ10855@talon.fglan
Bug#581054: merging RFP and ITP for perspectives
merge 581054 616466 thanks somehow i missed the RFP for perspectives, merging. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304182016.GT10855@talon.fglan
Bug#612341: RFP: libjpeg-turbo -- an accelerated libjpeg library
Package: wnpp Severity: wishlist * Package name: libjpeg-turbo Version : 1.0.90 Upstream Author : Name someb...@example.org * URL : http://libjpeg-turbo.virtualgl.org/ * License : wxWindows Library License 3.1/LGPL/BSD Programming Lang: C Description : an accelerated alternate libjpeg library libjpeg-turbo is a derivative of libjpeg for x86 and x86-64 processors which uses SIMD instructions (MMX, SSE2, etc.) to accelerate baseline JPEG compression and decompression. libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg v6b, all else being equal. it claims API/ABI compatibility with libjpeg, so may very well be able to be a drop-in libjpeg replacement. libjpeg-turbo seems to be actively developed (svn commits within the last 24 hours and a pre-release within the last month). Fedora 14 has also included libjpeg-turbo, so it's in use by another major distribution: http://fedoraproject.org/wiki/Features/libjpeg-turbo i might be able to help with the initial packaging, but am not really able to commit to long-term package maintenance, hence the RFP. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110207211918.GB10855@talon.fglan
Bug#474034: gPXE fork called iPXE
seems like iPXE (ipxe.org) forked from gPXE and gPXE seems to have since stalled development. perhaps the iPXE developers will be more amenable to getting license clarifications? live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101203175934.gk17...@talon.fglan
Bug#474034: license clarifications for inclusion in Debian
greetings! i've been trying to get some license clarifications about gPXE, but haven't recieved much response: http://etherboot.org/pipermail/gpxe/2009-October/02.html http://etherboot.org/pipermail/gpxe/2010-April/000884.html i understand that iPXE is essentially a fork of the gPXE codebase, and iPXE could likely be a viable alternative for Debian to consider. i know this isn't exactly the most fun or exciting part of developing an excellent free software project... even though i can get licensing information for various generated roms individually (using make bin/foo.rom), in order to include it in Debian, we'll need to get licensing information from the source itself. given that there are various FILE_LICENCE markers in most of the files, if i could get clarification from upstream about what license text actually applies to files marked with FILE_LICENCE, it would make great strides towards being able to include it as part of Debian. for example, a potential clarification could be: files containing the text FILE_LICENCE ( GPL2_ONLY ); are licensed under the following terms: This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation. as well as licensing text for each of: GPL_ANY, GPL_2_OR_LATER, and BSD2. including such information in the COPYRIGHTS file would be ideal (though technically copyrights and licensing are two different things). additionally, is there a plan to make a release of iPXE? thanks for your time! live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101203224038.gn17...@talon.fglan
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
daniel and i talked about trying to upload a stripped down upload that at least supports the NICs used by qemu/qemu-kvm, in order to simplify the licensing issues. this is getting more important, as newer versions of qemu don't seem to work well with etherboot. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100806152551.gd14...@claws.fglan
Bug#474034: gPXE license clarifications
filed a ticket in gPXE's issue tracker: http://support.etherboot.org/index.php?do=detailstask_id=97 live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100703001335.gh9...@claws.fglan
Bug#474034: gPXE license clarifications
i have been working on documenting the copyright notices in gPXE in preparation for an upload to Debian. oh, the fun! it may feel rather pedantic, so thanks in advance for bearing with me... there are numerous files which contain a FILE_LICENCE flag, but no other licensing notices (or copyright notices, for that matter): FILE_LICENCE ( BSD2 ); FILE_LICENCE ( GPL_ANY ); FILE_LICENCE ( GPL2_ONLY ); FILE_LICENCE ( GPL2_OR_LATER ); while this implies that they are released under a particular license, getting a clarification from upstream about what exact licensing terms are meant by each of these is needed for uploading to Debian. for example, licensing text for a file licensed under GPL version 2 only might look like: This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation. if i could get clarification about licensing text for each of the above FILE_LICENCE categories, that would be most helpful. additionally, there are some files distributed without any license text or FILE_LICENCE flags at all; what license are these distributed under? once that is resolved, i think it's ready for uploading to debian. the largest categories appear to be GPL2_OR_LATER or files without any licensing at all. following are lists of files under each of these categories: Files: src/drivers/bus/mca.c, src/drivers/net/3c509.c, src/drivers/net/3c529.c, src/drivers/net/ns8390.h, src/include/gpxe/ib_cmrc.h, src/include/gpxe/ib_srp.h, src/include/gpxe/srp.h Copyright: unknown License: FILE_LICENCE ( BSD2 ); Files: src/include/mii.h, src/include/stddef.h, src/drivers/net/davicom.c, src/drivers/net/depca.c, src/drivers/net/natsemi.h, src/drivers/net/rtl8139.c, src/drivers/net/sis190.c, src/drivers/net/sis190.h, src/drivers/net/sis900.h Copyright: unknown License: FILE_LICENCE ( GPL_ANY ); Files: src/drivers/net/phantom/nxhal_nic_interface.h, src/drivers/net/skge.h, src/drivers/net/sky2.h, src/include/gpxe/list.h, src/include/gpxe/pci_ids.h Copyright: unknown License: FILE_LICENCE ( GPL2_ONLY ); Files: src/arch/i386/core/relocate.c, src/arch/i386/firmware/pcbios/gateA20.c, src/arch/i386/hci/commands/pxe_cmd.c, src/arch/i386/include/basemem.h, src/arch/i386/include/basemem_packet.h, src/arch/i386/include/bios.h, src/arch/i386/include/biosint.h, src/arch/i386/include/bits/byteswap.h, src/arch/i386/include/bits/compiler.h, src/arch/i386/include/bits/endian.h, src/arch/i386/include/bits/errfile.h, src/arch/i386/include/bits/io.h, src/arch/i386/include/bits/nap.h, src/arch/i386/include/bits/smbios.h, src/arch/i386/include/bits/stdint.h, src/arch/i386/include/bits/timer.h, src/arch/i386/include/bits/uaccess.h, src/arch/i386/include/bits/umalloc.h, src/arch/i386/include/bootsector.h, src/arch/i386/include/bzimage.h, src/arch/i386/include/comboot.h, src/arch/i386/include/fakee820.h, src/arch/i386/include/gpxe/abft.h, src/arch/i386/include/gpxe/bios_nap.h, src/arch/i386/include/gpxe/bios_smbios.h, src/arch/i386/include/gpxe/bios_timer.h, src/arch/i386/include/gpxe/memtop_umalloc.h, src/arch/i386/include/gpxe/rdtsc_timer.h, src/arch/i386/include/gpxe/timer2.h, src/arch/i386/include/gpxe/x86_io.h, src/arch/i386/include/int13.h, src/arch/i386/include/librm.h, src/arch/i386/include/limits.h, src/arch/i386/include/memsizes.h, src/arch/i386/include/multiboot.h, src/arch/i386/include/pic8259.h, src/arch/i386/include/pnpbios.h, src/arch/i386/include/pxe.h, src/arch/i386/include/pxe_call.h, src/arch/i386/include/pxe_types.h, src/arch/i386/include/pxeparent.h, src/arch/i386/include/realmode.h, src/arch/i386/include/registers.h, src/arch/i386/include/setjmp.h, src/arch/i386/include/undi.h, src/arch/i386/include/undiload.h, src/arch/i386/include/undinet.h, src/arch/i386/include/undipreload.h, src/arch/i386/include/undirom.h, src/arch/i386/interface/pcbios/aoeboot.c, src/arch/i386/interface/pcbios/bios_nap.c, src/arch/i386/interface/pcbios/biosint.c, src/arch/i386/interface/pcbios/ib_srpboot.c, src/arch/i386/interface/pcbios/iscsiboot.c, src/arch/i386/interface/syslinux/comboot_resolv.c, src/arch/i386/transitions/librm_mgmt.c, src/arch/x86/include/bits/pci_io.h, src/arch/x86/include/gpxe/efi/efix86_nap.h, src/arch/x86/include/gpxe/pcibios.h, src/arch/x86/include/gpxe/pcidirect.h, src/config/console.h, src/config/defaults.h, src/config/defaults/pcbios.h, src/config/general.h, src/config/ioapi.h, src/config/nap.h, src/config/serial.h, src/config/timer.h, src/config/umalloc.h, src/core/asprintf.c, src/core/bitops.c, src/core/console.c, src/core/main.c, src/core/misc.c, src/core/random.c, src/core/serial.c, src/drivers/bus/eisa.c, src/drivers/bus/isa.c, src/drivers/bus/pciextra.c, src/drivers/infiniband/arbel.h, src/drivers/infiniband/hermon.h, src/drivers/net/eepro100.h, src/drivers/net/epic100.c, src/drivers/net/epic100.h, src/drivers/net/legacy.c,
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
well, i've updated debian/copyright as best i can, but the last few entries are a bit dubious. there are numerous files with no licensing claims other than upstreams headers: FILE_LICENCE( GPL2_OR_LATER ); there are some with no copyright holder. there also numerous files with no licensing declarations whatsoever... so i added: Files: ... Copyright: unknown License: FILE_LICENCE( GPL_ANY ); ... Files: ... Copyright: unknown License: unknown to at least document which need more work and clarification from upstream. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401024839.go27...@claws.fglan
Bug#565963: ITP: tritium -- a tabbed/tiling window manager
tags 565963 pending thanks git repository located here: http://git.debian.org/?p=collab-maint/tritium.git uploaded... should hit NEW queue when ftp-master is back up and running. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100330051224.gi27...@claws.fglan
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
i've been working on my own local copy of the git repository daniel posted, and am currently updating the debian/copyright file as best i can and some other minor fixes. i don't have write access to the repositories at debian-maintainers.org, so i can't push changes there, but i could publish changes somewhere else in the meantime. i think i can get this ready to upload in the first week of april. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100328200151.gd27...@claws.fglan
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
On Mon, Dec 07, 2009 at 01:57:02PM +0100, Daniel Baumann wrote: i've prepared an updated package based on the ones from vagrant, git is available here: git clone git://git.debian-maintainers.org/git/syslinux/gpxe.git this repository seems to cause me troubles. i do a git clone on it, and then a couple days later, run git pull and it generates merge conflicts. i delete the entire directory, git clone again, and after a couple days git pull generates merge conflicts. the freshly cloned repository only ever seems to have a single commit, so i don't understand where the merge conflicts are coming from. i'm not real savvy with git, but i don't have this problem with other git repositories i've been tracking and committing to. and .deb packages here: deb http://syslinux.debian-maintainers.org/ sid/snapshots main there don't appear to be packages there. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543423: ITP: ltsp-docs -- LTSP Documentation
preliminary packages available: deb http://llama.freegeek.org/~vagrant/debian UNRELEASED/ live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543423: ITP: ltsp-docs -- LTSP Documentation
Package: wnpp Severity: wishlist Owner: Vagrant Cascadian vagr...@freegeek.org * Package name: ltsp-docs Version : 0.99+bzr87 Upstream Author : Scott Balneaves sbaln...@ltsp.org * URL : http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspDocumentationUpstream * License : GPL2 Description : LTSP Documentation VCS (bzr) : https://code.launchpad.net/~ltsp-docwriters/ltsp/ltsp-docs-trunk i would like to package Linux Terminal Server Project Administrator's Reference as a supplement to the ltsp, ltspfs and ldm packages in Debian. it is the most comprehensive documentation for LTSP, and currently generates a PDF and HTML version, as well as a manpage for lts.conf, a commonly used LTSP configuration file. it seems important to have as a package, so the version of the documentation that ships with a given Debian release will be able to document the versions of LTSP shipped in that same release, as online documentation may diverge, which can be confusing for users. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
On Fri, Aug 14, 2009 at 03:01:46PM +0200, Daniel Baumann wrote: what is the current status, and who is waiting on what to be happening/doing/$whatever? i've been tracking upstream, and been pondering taking over the ITP, though the license review on it is still rather intimidatingly large in scope. there's definitely interest from upstream to try and work out whatever licensing issues may arise, but it's just a lot to review. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474034: any progress?
On Fri, Jun 12, 2009 at 03:15:48PM +0200, Guido Günther wrote: any progress in getting this uploaded? It seems somebody built prelimenary packages already. The pxe-virtio would do great in kvm. just the other day, i updated my packages built from current git, but for an upload to Debian, they still need a real review to update debian/copyright, which is actually the bulk of the work. gpxe contains code for network drivers taken from kernel sources, some firmware blobs, and around 1600 files to review for missing or unclear copyright/license notices. i've been a bit overwhelmed to really tackle that single-handed. they've recently added some code to display licenses, which should help, so there's at least interest upstream in tracking down and clarifying licensing issues. live well, vagrant -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474034: ITP: gpxe -- PXE network bootloader for x86 PCs
i'd be very interested in getting gpxe uploaded to debian and co-maintenaning it, if help is desired. i've built some packages of gpxe with only the iso, usb, dsk, lkrn and pdsk images(some of the rom images failed to build): http://llama.freegeek.org/~vagrant/debian/UNRELEASED/ though those packages still need a proper debian/copyright. live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
