Bug#1070312: O: zdbsp -- node builder library for OpenGL-based Doom-style games

[Jonathan Dowland]

retitle 1070312 ITA: zdbsp -- node builder library for OpenGL-based Doom-style 
games
owner 1070312 j...@debian.org
thanks

On Fri May 3, 2024 at 4:18 PM BST, Bastian Germann wrote:
> Jonathan Dowland has essentially orphaned zdbsp with
> https://salsa.debian.org/debian/zdbsp/-/commit/b37655b0ffeab5ba2d8519ecec141f0f0a1d6061

I did plan to do that, yes, but I changed my mind, and haven't
had occasion to update the package since.

I'll repurpose this bug so I can close it with a package upload
rather than close it now (although it might seem odd for the current
maintainer to be ITA'ing their own package.)

-- 
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1057087: RFA: ikiwiki -- wiki compiler

[Jonathan Dowland]

retitle 1057087 ITA: ikiwiki -- wiki compiler
owner 1057087 j...@debian.org
thanks

I'm still actively using IkiWiki and want it to continue to be
well-maintained in Debian. I am happy to co-maintain the package,
and I'm adjusting the bug metadata accordingly (I think that's the
convention).

Anyone else who wants to help; please get in touch. The package
lives in the Debian project on Salsa already, so is defacto
collab-maint; I wouldn't want to change that, and I'm pro-lowNMU
threshold.

Thank you Simon for doing an amazing job, upstream and in Debian,
keeping IkiWiki going.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1055584: ITP: cekit -- Container image creation tool

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: cekit
  Version : 4.9.1
  Upstream Contact: Jonathan Dowland 
* URL : https://cekit.io/
* License : MIT
  Programming Lang: Python
  Description : Container image creation tool


  CEKit is a container-source pre-processor with a strong focus on
  modularity and code re-use. Features include
  . 
  • Container images declaratively described in YAML documents and
Jinja templates
  • Container description decomposed into separate modules which may
live in external repositories, with inter-module dependency
resolution
  • Multiple build back-ends including Docker, Podman, Buildah
  • Integration/unit testing of container images (Behave/Cucumber)

CEKit has been organically built over a period of about ten years to
enable the production of containers for much of Red Hat's Middleware
product portfolio. CEKit is nowadays an independent community project
with users and contributors beyond Red Hat.

I intend to maintain CEKit (and necessary transitive dependencies)
within Debian, in the Debian Salsa project (formerly collab-maint)
and I am a supporter of low-threshold NMUs. Contributions welcome!

-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1050348: ITP: melonds -- nintendo DS emulator

[Jonathan Dowland]

On Wed, Aug 23, 2023 at 03:07:15PM +, Mae Miller wrote:

I'm going to be packaging this as my first package partially because
it's a program I use and care about and partially in order to learn how
the system works and to make my first contribution to debian.


Those are great reasons!

Can melonDS be usefully used without a BIOS/firmware dump from a DS?

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#981176: RFP: doas -- minimal replacement for sudo

[Jonathan Dowland]

On Wed, Jan 27, 2021 at 10:59:58AM +0100, Bernd Zeimetz wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: doas


I'd like this too!


 Version : 6.8
 Upstream Author : Duncan Overbruck znc others
* URL : https://github.com/Duncaen/OpenDoas


There's also <https://github.com/slicer69/doas>

I have not compared the forks.

Note that for slice69's fork,


  persist  After the user successfully authenticates,
  do not ask for a password again for some time.
  Works on OpenBSD only, persist is not available on
  Linux or FreeBSD.


It looks like Duncaen's fork has (new, disabled-by-default, potentially
dangerous?) persist support. I think this feature will be almost
essential for this to be a viable replacement for sudo.


--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#922628: ITP: dt -- DNS tool - display information about your domain

[Jonathan Dowland]

On Mon, Feb 18, 2019 at 12:46:16PM -0500, Antoine Beaupré wrote:

On 2019-02-18 17:39:51, Scott Kitterman wrote:

This is an incredibly generic package name.  Please pick something
more descriptive.


This was already reported by Paride Legovini, an hour ago. Please
follow the conversation there.

I would welcome help convincing upstream to rename the package, for
example.


Paride was talking about the *binary name*, Scott is talking about the
*package name*. (Consequently he has probably been following the
conversation just fine). Quite aside from the binary name clash
problems, "dt" is a very short package name, and a more descriptive
package name would serve as a form of self-documentation. "dnstool"
would seem perfectly consistent with the way upstream refer to the
project (GitHub title: DNS tool - display information about your domain)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#847613: ITP: nextcloud-client -- desktop client for nextcloud

[Jonathan Dowland]

noowner 847613
thanks

On Sat, Dec 29, 2018 at 01:48:39AM +0100, Sandro Knauß wrote:

sorry I havn't seen, that you already took the task of packaging nextcloud-
desktop for Debian. I started already to copy the work done at owncloud-client
to nextcloud-desktop and also got something, that is quite ready for usage.
I published my work at salsa:
https://salsa.debian.org/owncloud-team/nextcloud-desktop

maybe we can join our forces to get a working package ready soon.


It's been over 6 months since the last positive message from Lev that he
intended to work on this. The repository is still empty, and the freeze
for our next stable release is getting uncomfortably close.

IMHO, 6 months is long enough that it would be reasonable for you to
take over this ITP, if you are still interested in packaging the
nextcloud client yourself/yourselves (as part of the owncloud-team). In
fact, I will do the first next thing now, and remove the owner
annotation for this bug, requesting forgiveness if Lev still intends to
work on this, rather than permission.

I think this is the only course of action likely to result in
nextcloud-client making it into the next stable Debian release.

I will attempt to test your existing packaging if that would be helpful.


Thanks,

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#847613: ITP: nextcloud-client -- desktop client for nextcloud

[Jonathan Dowland]

On Mon, Dec 31, 2018 at 03:28:42PM +0100, Sandro Knauß wrote:

With todays upload of owncloud-client, I got a big fat warning that
connecting to nextcloud is no longer supported


Argh they now really start fighting against each other - WTF?  If nextcloud-
dektop won't make it to Debian, I'll patch this out.


I'm not sure that's a good idea, if it is more than just a warning, what
if there is a genuine incompatibility or the likelyhood of one growing
after we release the next Stable: there could be a dataloss issue if
someone uses the Debian-packaged owncloud client with a
not-Debian-controlled nextcloud server.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Jonathan Dowland]

Clément Hermann wrote:

Actually, yes, it's a bit outdated. I'm currently working on the
dependancies needed for 3.0.1, see this edited output of dh-make-golang
estimate (some entries were false positive, due to different import path
that'll need to be patched, or an apparently useless for in the case of
go4):


I updated https://wiki.debian.org/LXD with the list from your email, and
then


People interested, please check the up-to-date list in the Gobby doc at
gobby.debian.org/Teams/Go/lxd-dep-packaging (or the export at
https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging). It
contains comments, #ITPs, etc.


I'd never heard of Gobby before. I've linked to it from the wiki page,
but it doesn't seem to make sense to try and track this in two places.
It's kind-of unfortunate to have introduced yet-another-collaborative
editor. I'd delete the list from the wiki page and point at the Gobby
doc except I don't know how accessible that is yet, and I don't know
if the list there is current to now, either.

https://salsa.debian.org/lxc-team/lxd doesn't exist still but I guess
it wouldn't until the dependencies were done.


--

Jonathan Dowland

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

[Jonathan Dowland]

Hi Michael,

On Thu, Oct 04, 2018 at 03:06:38PM +0200, Michael Biebl wrote:

Jonathan, did you find some time to review Lev's work?


Sorry no, I hadn't checked back to see if the repository¹ was
populated yet - but it isn't.

(thanks for the other info too)


¹ https://salsa.debian.org/debian/nextcloud-client

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

[Jonathan Dowland]

Hi Lev,

Thanks for working on this. I'm glad to see the Salsa repo is now
live[1] and I look forward to having something to look at!

For my own purposes I am looking at possibly replacing an Owncloud and I
may be able to help evaluate the nextcloud packaging for this purpose.


[1] https://salsa.debian.org/debian/nextcloud-client

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Jonathan Dowland]

Hey folks,

I was pleased to see the last LXD dependency that we were tracking has
finally made it into Debian, so the path is likely clear for LXD itself
now (unless we need to catch up on some newer dependencies since the
analysis was done: https://wiki.debian.org/LXD)

What's the status of the LXD package itself? In the middle of this whole 
process Alioth went away and was replaced by Salsa. I found the

following Salsa project but no packaging sources:

   https://salsa.debian.org/lxc-team/lxd




Thanks & best wishes

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#768073: ITP: lxd - The Linux Container Daemon

[Jonathan Dowland]

On Sun, May 27, 2018 at 04:01:28PM +0300, Alexander Gerasiov wrote:

Nope, they said that _feature_ releases will be available as snap
packages, but LTS (3.0 for now, and may be other in the future) will
be supported as deb packages.


It's moot, anyway: Debian will be packaging the source and building our
own binaries, not redistrubuting theirs.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#889145: ITP: zdbsp -- node builder tool for Doom-style games

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland <j...@debian.org>

* Package name: zdbsp
 Version : 1.19
 Upstream Author : Marisa Heit
* URL : https://github.com/rheit/zdbsp
* License : GPL-2+
 Programming Lang: C++
 Description : node builder tool for Doom-style games

ZDBSP is a node building-tool for Doom-style games, such as
Doom, Doom 2, Heretic, Hexen and Strife. Doom-style games
require "Nodes" (binary space partition trees) to be built for
custom maps. Compared to similar tools, ZDBSP is very fast.
ZDBSP generates the additional lumps required by GL engines.

---

I'd like there to be at least one BSP tool in the archive. At
the moment we have glbsp (which was orphaned and I have just
adopted) but I think we should switch to ZDBSP. I did some
performance comparisons, and on a particularly evil map ("choz"
from the WadC examples) and build time on my laptop dropped
from 4-ish minutes (glbsp) to sub-second.

I'll either maintain via collab-maint (Salsa Debian project)
or pkg-games.


--
Jonathan Dowland

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#880972: ITP: crispy-doom -- Limit-raising medium-resolution Doom source port based on Chocolate Doom

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland <j...@debian.org>

* Package name: crispy-doom
 Version : 5.0
 Upstream Author : Fabian Greffrath <fab...@greffrath.com>
* URL : https://www.chocolate-doom.org/wiki/index.php/Crispy_Doom
* License : GPL-2
 Programming Lang: C
 Description : Limit-raising medium-resolution Doom source port based on 
Chocolate Doom

Crispy Doom is a friendly fork of Chocolate Doom that provides a higher display
resolution, removes the static limits of the Doom engine and offers further
optional visual, tactical and physical enhancements while remaining entirely
config file, savegame, netplay and demo compatibile with the original.



Crispy Doom strikes a unique balance between being a traditional Doom engine
(with demo compatibility, and vanilla-engine bug compatibility, etc.) and
offering modern conveniences such as mouse look, nicer resolutions, and small
tweaks and tricks to make the game more interesting and varied (blood colour
for monsters matches their sprites, some static sprites are randomly mirrored
on the vertical axis for more visual variation, etc.)

I will maintain this either via collab-maint or pkg-games, apparently skitt
has expressed an interest in the past and Fabian himself might involve himself
if he wishes to (both would be welcome)

One (other) big difference between crispy and chocolate doom, at least at the
moment, is crispy has been ported to SDL2, which makes it better suited for
platforms or environments where SDL2 has been ported and SDL1 has not.


--
Jonathan Dowland

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#768073: [pkg-go] Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

Hi folks,

We didn't manage to get LXD into the archive in time for the freeze.

We packaged the following specifically as LXD dependencies which did go in:

 * https://tracker.debian.org/pkg/golang-gopkg-flosch-pongo2.v3
 * https://tracker.debian.org/pkg/golang-petname
 (possibly others, hit-list was at https://wiki.debian.org/LXD)

IMHO, and at least for the ones I did, I think we should file RC bugs to
prevent these packages from going into stretch. They should stay in the
archive/sid, for continued work on LXD, but I don't think that they are
valuable on their own in the next release: it's just stuff that people
might try to use that isn't being looked after properly (since the reason
for them being there does not exist), taking up archive space and apt
metadata space, etc.

Thoughts?

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#768073: [pkg-go] Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

Hi all,

I was pinged about this today which reminded me to post an update to the bug.

I'm unlikely to have enough time to finish packaging the rest of the 
dependencies
before the freeze deadline.

But the good news is we're very close anyway!

Zhenech has  golang-…-lxc.v2  imported to pkg-lxc but the tests are failing.

Clément identified that some of the other deps might already be packaged:

On Fri, Oct 14, 2016 at 01:33:53PM +0200, Clément Hermann wrote:
> >   Depends: golang-gopkg-inconshreveable-log15.v2-dev but it 
> > is not installable
> 
> From what I looked, this is a fork of
> golang-github-tendermint-log15-dev, which is the archive. There seem to
> be very few changes, so it might just work:
> https://github.com/inconshreveable/log15/compare/master...tendermint:master

So I'd encourage anyone else interested to jump in *now* to get the last 10% or
so done if possible!


signature.asc
Description: Digital signature

Bug#768073: [pkg-go] Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

On Thu, Oct 13, 2016 at 02:11:13PM +0200, Martín Ferrari wrote:
> A few of these dependencies are already in the archive, not all have the
> standard naming yet, but I think about half of those are already packaged.

Thanks! I've just gone through to re-check them, renamed a few to the canonical
names for the relevant dev packages, leaving just three missing:

 lxd-build-deps : Depends: golang-gopkg-flosch-pongo2.v3-dev but it is not 
installable
  Depends: golang-gopkg-inconshreveable-log15.v2-dev but it is 
not installable
  Depends: golang-gopkg-lxc-go-lxc.v2-dev but it is not 
installable

(I've pushed changes to debian/control just now)

I have a flosch package somewhere that I started last week, I'll try to dig
it out.

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

Hi Team,

Just a quick mail to say hello, I recently joined because I am interested
in packaging (at least) build dependencies for LXD, which is Canonical's
container hypervisor platform.

The specific go dependencies that we need to package are:

* golang-gopkg-flosch-pongo2.v3-dev
* golang-gopkg-inconshreveable-log15.v2-dev
* golang-gopkg-lxc-go-lxc.v2-dev
* golang-any-shared-dev
* golang-go.crypto-dev
* golang-context-dev
* golang-github-gorilla-mux-dev
* golang-github-gosexy-gettext-dev
* golang-github-mattn-go-colorable-dev
* golang-github-mattn-go-sqlite3-dev
* golang-github-olekukonko-tablewriter-dev
* golang-github-pborman-uuid-dev
* golang-gocapability-dev
* golang-gopkg-tomb.v2-dev
* golang-yaml.v2-dev
* golang-websocket-dev

I'm looking at flosch-pongo2 right now, but I thought I'd post the list to this
mailing list just in case anyone else was interested in getting involved!

I've set up this wiki.d.o page to track progress on the above:
https://wiki.debian.org/LXD


Thanks,

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

On Sun, Oct 09, 2016 at 08:17:09PM +0200, Adnan Hodzic wrote:
> Jonathan and everybody else,
> 
> Since I couldn't find my original LXD package source, I started from
> scratch.
> 
> I created new Git repo (pkg-lxc/lxd.git) and pushed initial Debian package
> of LXD 2.4.1 (Yakkety release). Git repo is available on Alioth:
> https://anonscm.debian.org/git/pkg-lxc/lxd.git

Great, thanks!

> Building the package will fail due to missing golang-* deps which ATM are
> missing in Debian. I can't remember if the original list of missing
> dependencies was this long, but this is what we we're currently dealing
> with:

I've updated the list at https://wiki.debian.org/LXD accordingly.
 
> Has pkg-go team been notified of this problem? And are they willing to
> package these for Debian?

I have joined pkg-go and tackled one of the dependencies (with a second
incoming) but I hadn't thought to msg the team with this list, I will do
that too.

Thanks!


signature.asc
Description: Digital signature

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland <j...@debian.org>

* Package name: golang-gopkg-flosch-pongo2.v3
  Version : 3.0
  Upstream Author : Florian Schlachter
* URL : https://github.com/flosch/pongo2
* License : Expat
  Programming Lang: Go
  Description : Django-syntax like template-engine for Go

This offers a template renderer compatible with the Django syntax but
for the Go language.
.
pongo2 is the successor of pongo.

This is a dependency for LXD and is being packaged via the pkg-go team.

Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals

[Jonathan Dowland]

On Fri, Sep 30, 2016 at 08:53:05AM +0200, Pascal Grange wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pascal Grange <pas...@grange.nom.fr>
> 
> * Package name: bash-unit
>   Version : 1.0.2
>   Upstream Author : Pascal Grange <pas...@grange.nom.fr>
> * URL : https://github.com/pgrange/bash-unit
> * License : GPL
>   Programming Lang: Bash
>   Description : bash unit testing enterprise edition framework for 
> professionals
> 
> bash-unit is a unit testing software for bash.

My immediate thought was "how does this differ to shunit2", which is
already packaged. You mention this later:
 
> I am aware of one alternative Debian package providing similar
> functionaltities: shunit2. bash_unit and shunit2 propose
> different testing methods and workflow.

It would be nice to expand on this a little, to help make the case that
we need another shell unit testing framework (especially since shunit2
works for other shells too!)

> It has been reported that people using bash_unit won't use shunit2 to write
> their tests but I may not be objective about that ;) bash_unit officially
> supports only bash where shunit2 tries to support more shells.  This package
> would improve bash unit testing support for Debian.
>
> I am the main developer of bash-unit.

Objectivity is very important here IMHO. What are your motivations for packaging
it in Debian? Is it a build-dependency for something else, or are you looking 
for
a "signal boost" to raise the profile of bash-unit?


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

On Mon, Sep 26, 2016 at 12:35:24AM +0200, Adnan Hodzic wrote:
> Awhile back I started packaging process. I basically re-packaged the LXD
> Ubuntu package. As Evgeni mentioned it "is what we did with the other LXC
> components and that worked out pretty well so far."

Do you have that lying around, and if so is it worth us pushing it to a git
repo for pkg-lxc?

> At this point, I think we just need to align the efforts between pkg-go and
> pkg-lxc teams, and we'll see LXD in Debian in no time.

I've just joined both teams and opened an ITP for golang-petname. I've got a
package prepared pending a few questions on the pkg-go list, I should get it
into NEW Tomorrow. Then perhaps I can start on the others next week.


Thanks,

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#839077: ITP: golang-petname -- generate pronouncable, perhaps even memorable, pet names

[Jonathan Dowland]

Package: wnpp
Severity: wishlist
Owner: Jonathan Dowland <j...@debian.org>

* Package name: golang-petname
  Version : 2.5~git20160928-1
  Upstream Author : Dustin Kirkland <dustin.kirkl...@gmail.com>
* URL : https://github.com/dustinkirkland/golang-petname
* License : Apache-2
  Programming Lang: Go
  Description : generate pronouncable, perhaps even memorable, pet names

 This utility will generate "pet names", consisting of a random
 combination of an adverb, adjective, and proper name.  These are
 useful for unique hostnames, for instance.
 The default packaging contains about 2000 names, 1300 adjectives,
 and 4000 adverbs, yielding nearly 10 billion unique combinations,
 covering over 32 bits of unique namespace.
 As such, PetName tries to follow the tenets of Zooko's triangle:
 names are human meaningful, decentralized, and secure.

This package is a dependency of LXD, which we are hoping to get into
Debian soon, via the pkg-lxc team. I intend to package this as part
of the pkg-go team.

Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

Hi folks, thanks for the useful replies!

I've sent requests to join pkg-lxc and pkg-go, and set up a scratch/todo page
on wiki.d.o at https://wiki.debian.org/LXD that we could use to coordinate work
needed.

Now to take a look at those Go packages...


signature.asc
Description: Digital signature

Bug#768073: LXC team take over ITP?

[Jonathan Dowland]

Hi,

I think that an ITP that has been inactive this long could be taken over by
another interested party without it being a hijack, all things considered.
(I think some QA script might move it to RFP soon anyway).

Adnan, how's it going?

There's a pkg-lxc team already. Since this package is/will be very 
inter-related to
LXC, perhaps it should be developed in that team? Team CCed. Are they 
interested?
Are you in pkg-lxc already?

What's the state of the Ubuntu package? Could that make a good starting point? 
How
much hacking before that would be suitable for an experimental upload at least?

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#768073: ITP: lxd - The Linux Container Daemon

[Jonathan Dowland]

Hi,

This ITP is now over a year old. Is this package still being worked on?
Is there a public WIP repository or packages that people can see yet
please?


Thanks,

-- 
Jonathan Dowland

Bug#805925: ITP: shatteredpixeldungeon -- A mod of Pixel Dungeon with many improvements

[Jonathan Dowland]

Sorry for the delay in replying to this,

On Tue, Nov 24, 2015 at 10:25:15AM +0800, Paul Wise wrote:
> On Tue, Nov 24, 2015 at 10:15 AM, Noam Preil wrote:
> 
> >   Description : A mod of Pixel Dungeon with many improvements
> 
> Does that mean it is a fork of pixeldungeon?
> Or is it a plugin that doesn't change the code?

Noam Preil wrote:
> Shattered is a fork.

Paul's point, I think, is that the Description is not clear enough. I'd suggest
that for Debian, it's more important to describe what Shattered Pixel is (i.e.,
a game, a roguelike, etc.) than where it comes from (Pixel Dungeon). The latter
can be included in the long description of course.

How is the ITP going?


Thanks,

-- 
Jonathan Dowland

Bug#807241: ITP: archlinux-xdg-menu -- Convert freedesktop files to a format used by various WMs

[Jonathan Dowland]

On Sun, Dec 06, 2015 at 04:20:28PM +, Nicholas Bamber wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nicholas Bamber 
> 
> * Package name: archlinux-xdg-menu

^ don't put archlinux in the package name. It might warrant a mention in the
long description, however.

>   Description : Convert freedesktop files to a format used by various WMs
^^^
> xdg-menu generates menus for WMs using the Free Desktop menu standard.
   ^^^
probably worth expanding WMs to "window managers" to reduce ambiguity.

> You can install archlinux-xdg-menu from the official repositories.

^ I wouldn't include this sentence in the package description.

> The following WMs are supported:

^ I wouldn't enumerate a list of WMs one-per-line in the long description.
Instead do something like

  twm; ion3; WindowMaker; fvwm2; icewm; blackbox; fluxbox; openbox; awesome.

> KDE, Gnome, Xfce, Enlightenment are already XDG compatible.

What does this mean? Does it mean you do not need this package if you use
on of these environments?

Bug#804315: [Vmdebootstrap-devel] Namespace issues

[Jonathan Dowland]

Hi,

On Tue, Nov 10, 2015 at 12:13:54AM +0100, Julian Andres Klode wrote:
> May I suggest debian-cd-live or debian-live-cd as a name? That would
> be close in name to debian-cd, highlighting its use case.

I would advise against these suggestions, because using debian in the name of a
loosely-coupled sub-project (and due to the nature of Debian, all sub-projects
are loosely-coupled) is it implies a sense of "officialness" above and beyond
other software that might co-exist, either now or in the future. (Consider
if/when we decide that debhelper, d-i and various other things need to be
replaced in the future, we will face a similar problem). For that reason, I
think it would be good to avoid using the project name in software names. As
such:

> Or vmdebootstrap-live if you want to focus on vmdebootstrap name-wise (you
> being maintainer here).

Would be fine. (although vmdebootstrap is an accretion on top of debootstrap
in the first place and I'd rather that wasn't the case either, mutter mutter
cognitive burden of Debian tooling proliferation mutter mutter)

On Tue, Nov 10, 2015 at 12:13:54AM +0100, Julian Andres Klode wrote:
> Well, people seem to be happy to "invade" other namespaces, just look
> at how much packages start with "apt-" ;) [which confuses users, because
> they think the APT team is the right team to talk to].

Yes, the *apt* "namespace" is a good example of why *not* to do this. (See
also git-buildpackage, which managed to invade two namespaces at the same
time - although since fixed it seems)

> But we don't have the replacement problem, there is no apt-ng package
> or similar.

...yet :)

It seems Iain has opted for live-wrapper now, which IMHO does not have the
problems of live-build-ng. Clashing with "live-build" is considered rude,
but OTOH "live*" is too-wide a namespace for live-build to claim to itself.


-- 
Jonathan Dowland

Bug#440111: Processed: RFP: rockboxutility -- Utility for installing Rockbox on portable audio players

[Jonathan Dowland]

 Bart Martens wrote:
  noowner 440111
 Bug #440111 [wnpp] RFP: rockboxutility -- Utility for installing Rockbox on
 portable audio players Removed annotation that Bug was owned by Jonathan
 Dowland j...@debian.org.

It would be lovely if you could explain why.



Thanks

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150528082633.ga7...@chew.redmars.org

Bug#729203: Intent to package FFmpeg

[Jonathan Dowland]

Hi Andreas,

On Sun, Mar 16, 2014 at 02:36:35PM +0100, Andreas Cadhalpun wrote:
 unfortunately you haven't forwarded my and Alexander's request to
 join collab-maint to n...@debian.org. Thus we still don't have access
 to the repository you created.

No, so far I haven't, sorry - I haven't had time to send the signed
message. I'm near my GPG key tonight so I can do so now.

 Are you still interested in packaging FFmpeg for Debian?

Yes.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140317201711.ga10...@bryant.redmars.org

Bug#729203: Intent to package FFmpeg

[Jonathan Dowland]

On Wed, Feb 26, 2014 at 10:17:03PM +0100, Andreas Cadhalpun wrote:
 I would be fine with collab-maint and Alexander as well. If you
 create a repository, we could ask to be added and I could put my
 current packaging (imported via git-dsc-import) in there.

OK, I've created an empty repository at
git://anonscm.debian.org/collab-maint/ffmpeg.git

Thanks


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140227080906.gb22...@bryant.redmars.org

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav

[Jonathan Dowland]

On Wed, Feb 26, 2014 at 01:39:23AM +, Clint Adams wrote:
 Ideally someone should upload ffmpeg to unstable instead of
 endlessly discussing it.  I don't see anyone preventing this
 yet.

Seconded. I felt that Moritz's last message (when it was the last
message) was fine - let's get it into unstable, and /prove/ that
security issues can be managed, by managing them. That will go a long
way towards building trust in the ffmpeg-packaging-team (whoever that
might be. Still to be resolved I guess) can handle it. It will also
address the issue for a large chunk of Debian users, who use sid anyway.

And before someone actually uploads the thing - can we please get it
into a git repo; clarify the team arrangements (collab-maint or set up a
new one?); and can we reach an agreement on whether the first upload
offers a binary ffmpeg package only (my preference), before we attempt
to tackle the library co-installation (which might take a lot longer,
require ftp master convincing etc.)


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140226201706.ga9...@bryant.redmars.org

Bug#729203: Intent to package FFmpeg

[Jonathan Dowland]

Hi Andreas

On Tue, Feb 25, 2014 at 05:43:25PM +0100, Andreas Cadhalpun wrote:
 I intend to package and maintain FFmpeg for Debian. Co-maintainers
 are welcome.

I am interested in co maintaining and can sponsor uploaders, as long
as the package is maintained in git and we aim to get an ffmpeg binary
into unstable before we try to tackle the library issues (i.e., as a
distinct, first phase, with an accepted upload).

Thanks


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140226203418.ga9...@bryant.redmars.org

Bug#729203: ~ Re: Bug#729203: CTTE and reasonable solutions

[Jonathan Dowland]

On Sun, Feb 16, 2014 at 02:25:18PM +0200, Adrian Bunk wrote:
 How do you plan to address the DSA veto against having both sources in 
 the archive?
 
   https://lists.debian.org/debian-devel/2014/02/msg00668.html

I did not intepret that message as a DSA veto. But, with regards making
sure the DSA are happy with whatever we do, we'll do that by talking to
DSA - which, last I checked - was not you.

You clearly have nothing constructive to offer with regards getting
ffmpeg back into Debian and satisfying the users who are craving it.
Can I suggest you therefore focus your efforts on something else,
preferably something constructive, and leave this bug alone?


-- 
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/20140216123026.ga4...@bryant.redmars.org

Bug#729203: CTTE and reasonable solutions

[Jonathan Dowland]

Hi Rogério, thanks for looking into resolving this situation.

I haven't read every last mail in the history of this issue and recently
have confined myself to just this bug. There's obviously a detailed
history and a lot of animosity.

I'd say first and foremost, I miss ffmpeg most as a command-line tool.
The tools that link to libav (VLC etc.) seem to continue to work fine
from a user's perspective. I appreciate that there might be a lot of
pain for maintainers below the water line (more on that later). Reading
some of the comments on this bug, I think many users are similarly
missing ffmpeg as a command line tool and are not as concerned about the
library side of things.

So, I fully support packaging ffmpeg as a binary package for the command
line client at the very least, and perhaps as a necessary first step.

If the debian multimedia team are not interested in doing that, fine,
they don't have to. But it would be wrong for them IMHO to prevent some
other interested party from doing so.

Back to maintainers linking against libav. You have said yourself that
the effort involved to get e.g. handbrake to work with Debian's libav
was herculean (not your exact words I know). I believe that, if ffmpeg
libraries and libav libraries can co-exist in the archive, it should be
a maintainer's choice which they link against. So, if it were possible
for ffmpeg's libraries to be packaged without interfering with existing
clients of libav's libraries, a maintainer such as yourself for
handbrake[1] could choose to use ffmpeg, that would be the maintainer's
right.

I suspect that the animosity I've read in this thread from people
towards ffmpeg in the archive as libraries is due to concerns about how
practical it would be for them to co-exist. These are probably valid
concerns that should be looked at. However, they can be, by exploring
real packaging attempts outside the archive (or using experimental)
rather than arguing about theoretics.

So as a first step and addressing many of the requests here I think we
should push on to get the binary packaged on it's own, for now.  A good
starting place would be a git repository for the packaging.  Should we
base this on the pre-libav ffmpeg package, or start afresh?

[1] perhaps a bad example since it's yourself with the debian multimedia
team...


--
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/20140213131534.ga15...@bryant.redmars.org

Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

[Jonathan Dowland]

On 13/02/2014 12:11, Holger Levsen wrote:
 so how is this related to Spotify? Not at all, it's just streaming music?
 (And what has it to do with poverty? And with poor men especially?)

You're right that the description needs updating, but Poor Man's
Spotify is the upstream name of the software.

(it was renamed from pms to mps to avoid aclash with something else;
however internally it still uses pms a lot and creates e.g. .pms-config,
pms-playlist, pms-debug...)

It does look a bit dodgy though. It appears to use http://pleer.com/ as
a source which looks like a copyright-violation website at first glance.


-- 
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/52fce132.5030...@debian.org

Bug#726698: ITP: puppet-module-puppetlabs-xinetd -- The xinetd module let you manage xinetd with Puppet

[Jonathan Dowland]

It's good to see puppet modules being packaged for Debian.

Is there a team under which such efforts are coordinated? Are they being 
managed in a vcs?

I'd suggest flipping the order of the two paragraphs in the long description: 
put the text which describes the module first, and the text which explains 
puppet second. I'd also suggest a shorter and more impartial puppet description 
such as 

Puppet is a declarative configuration management tool for handling 
heterogeneous collections of hosts

--
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/542e2ba7-7b30-40e4-861b-abff0e491...@debian.org

Bug#620272: Status report

[Jonathan Dowland]

Might it be possible to call the package name dwarf-therapist? I won't
go as far as to suggest renaming any binaries or other references to the
package. However, there's one other possible parsing of dwarftherapist
which can take you back, somewhat, until you figure out where you went
wrong. For those who will not install or use the package, but will see
the conjoined name in package lists from time to time, it might be nice
to spell out the conjunction with a dash.


-- 
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/20130924164943.ga27...@ubik.ncl.ac.uk

Bug#703762: ITP: jdownloader -- download manager for one-click hosting sites

[Jonathan Dowland]

On Sat, Mar 23, 2013 at 01:29:13PM +0100, Benjamin Drung wrote:
 Am Samstag, den 23.03.2013, 13:13 +0100 schrieb Michael Stapelberg:
  Could you instead package jdownloader itself?
 
 I tried, but failed miserable. Some libraries needs to be packaged and
 the upstream build system needs to be bent to build on Debian. I would
 love to ditch the launcher and replace it with a proper package. This is
 a lot of work. Until this work is done, I like to have this launcher in
 the contrib archive. This is suboptimal, but better than nothing.

I'm not sure it *is* better than nothing, it could actually be worse. If you
don't personally have the time to do it properly, why not try and put 
together a team to do it? If you do a downloader instead, what you do is
partially and sub-optimally meet the demand for a jdownloader package, which
will dilute the motivation for people to work on a proper solution. Then we
end up stuck with the sub-optimal solution.

I think downloader packages where required for licensing reasons are an uneasy
necessary evil, but for when the maintainer doesn't have time to package
something? This seems like a really slippery slope to me.

-- 
Jonathan Dowland


-- 
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/20130325115943.ga3...@ubik.ncl.ac.uk

Bug#699163: O: bup -- highly efficient file backup system based on git

[Jonathan Dowland]

Package: wnpp
Severity: normal


signature.asc
Description: Digital signature

Bug#681576: non-daw: please package non-daw

[Jonathan Dowland]

This could be an interesting one. I've just been taking a look at
it. I might package, it - no promises, I haven't actually ran it
yet - but I've managed to build it.

We will also need to package NTK (a fork of FLTK) and handle the
./waf evil.


-- 
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/20121211214337.ga7...@ubik.ncl.ac.uk

Bug#690905: freedoom: Prboom Plus should be used instead of Prboom

[Jonathan Dowland]

On Thu, Nov 29, 2012 at 11:15:16AM +0100, Fabian Greffrath wrote:
 I have currently started improving the packaging a bit and found the
 package name really confusing and distracting. Could we please
 rename the package to prboom-plus just as upstream calls the
 project itself? We could, of course, keep the symlinks to prboom+
 binary and manpage, but as a Debian package name I find it really
 unsuitable.

That's disappointing. The idea of the package being prboom-plus
really rankles with me, e.g. imagine if bonnie++ was bonnie-plus-plus,
libstdc++6 libstdc-plus-plus-6 etc. However packaging practicalities
are important. Let me look over your commits today and then I'll
get back to you whether I'm happy to rename it or not.


-- 
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/20121130103806.GD5807@debian