Bug#905174: ITP: ufonormalizer -- Normalize XML and other data inside Unified Font Object files
Package: wnpp Severity: wishlist Owner: Yao Wei (魏銘廷) * Package name: ufonormalizer Version : 0.3.5 Upstream Author : Tal Leming * URL : https://github.com/unified-font-object/ufoNormalizer * License : BSD-3-Clause Programming Lang: Python Description : Normalize XML and other data inside UFO This utility normalizes XML and other files inside United Fonts Object, to avoid differences due to spacing, reordering of keys, etc. This package is the new dependency of glyphslib since 3.0.0. This package should be maintained under Debian Fonts Task Force, and I would need someone for sponsor upload. Yao Wei signature.asc Description: PGP signature
Re: Re: usr/share/doc and mo
Te Sent from my iPhonewdj
Re: Bug#892612: ITP: conbuilder -- container-basade package builder for Debian packages
Am Sonntag, den 11.03.2018, 11:31 + schrieb Federico Ceratto: > Package: wnpp > Severity: wishlist > Owner: Federico Ceratto > > * Package name: conbuilder > Version : 0.0.1 > Upstream Author : Federico Ceratto > * URL : https://salsa.debian.org/federico/conbuilder > * License : GPLv3 > Programming Lang: Python > Description : container-basade package builder for Debian > packages > > Build Debian packages using OverlayFS and systemd namespace > containers. > > conbuilder creates a base filesystem using debootstrap, then > overlays it with a filesystem to install the required dependencies > and finally runs the build on another overlay. > > Layers are created, reused and purged automatically to achieve > fast package builds while minimizing disk usage. > > It takes less than 2 seconds to start a new build on an already > existing > overlay. What's the difference to sbuild which is configured to use overlays? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Re: Bug#892612: ITP: conbuilder -- container-basade package builder for Debian packages
Hi, Quoting Benjamin Drung (2018-08-01 16:28:54) > > Build Debian packages using OverlayFS and systemd namespace > > containers. > > > > conbuilder creates a base filesystem using debootstrap, then > > overlays it with a filesystem to install the required dependencies > > and finally runs the build on another overlay. > > > > Layers are created, reused and purged automatically to achieve > > fast package builds while minimizing disk usage. > > > > It takes less than 2 seconds to start a new build on an already > > existing > > overlay. > > What's the difference to sbuild which is configured to use overlays? There certainly are a few things like disabling network access during build or seccomp filters which schroot in Debian cannot yet do (see also #802849). But before re-implementing all the package building logic that already exists in pbuilder and sbuild, could we maybe evaluate whether it is feasible to extend the existing tools with a new backend? Especially when added as an autopkgtest-virt server, such work would benefit a much bigger crowd than yet another [1,2] package building software. I would certainly appreciate a bug against sbuild that adds functionality that sbuild does not yet have. Thanks! cheers, josch [1] https://lists.debian.org/4340a82e-15fc-1518-122a-c49273da1...@metux.net [2] https://lists.debian.org/87lhiduele@desiato.home.uhoreg.ca signature.asc Description: signature
Bug#905234: ITP: urbackup-server -- easy to setup backup system (server)
Package: wnpp Severity: wishlist Owner: Roberto Lumbreras * Package name: urbackup-server Version : 2.2.11 Upstream Author : Martin Raiber * URL : https://www.urbackup.org * License : AGPL-3+ Programming Lang: C++ Description : easy to setup backup system (server) UrBackup is an easy to setup Open Source client/server backup system, that through a combination of full and incremental backups accomplishes both data safety and a fast restoration time. . Clients are provided for Linux, macOS and Windows. Backups are very fast using incremental backups that only copies changed files. Windows client also makes full drive backups, allowing to restore the whole disk with a bootable CD or USB-Stick (bare metal restore). . Features: - Fast: incremental backups, continuously watches file changes. - Easy to setup: web interface, client try icon. - Space efficient: deduplication and compression, using btrfs or ZFS. - Consistent file and image backups while in use. - Automatic discovery in local area networks. - Security: server public key authentication. - Backups via Internet, with strong authentication and encryption. - Multi-platform: Windows, Linux, FreeBSD, macOS. Regards, Roberto
Bug#905240: ITP: golang-github-rivo-tview -- Rich interactive widgets for terminal-based UIs
Package: wnpp Severity: wishlist Owner: Jongmin Kim X-Debbugs-CC: debian-devel@lists.debian.org, team+pkg...@tracker.debian.org * Package name: golang-github-rivo-tview Version : 0.0~git20180728.6614b16-1 Upstream Author : rivo * URL : https://github.com/rivo/tview * License : Expat Programming Lang: Go Description : Rich interactive widgets for terminal-based UIs This Go package provides commonly needed components for terminal based user interfaces. . Among these components are: * Input forms (include input/password fields, drop-down selections, checkboxes, and buttons) * Navigable multi-color text views * Sophisticated navigable table views * Flexible tree views * Selectable lists * Grid, Flexbox and page layouts * Modal message windows * An application wrapper This package is a dependency for git-lab (#898246).
Re: Let's start salvaging packages!
On Sun, 29 Jul 2018 17:40:49 +0800, Tobias Frost wrote: > tl;dr: Let's bring the package salvage process discussed some years earlier to > life! Indeed! Thanks for picking up this topic. > There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan > [a] > for dicussion and fine tuning. (We will likely have video coverage.) I won't be there, so just some quick thoughts in advance: > Reasons to salvage a package > > > A package is eligible for salvaging if it is in clear need of some love > and care, i.e. there are open bugs, missing upstream releases, or there > is work needed from a quality-assurance perspective; AND there is the > need to upload the package to deal with these issues; AND at least one > of these criteria applies: > > * There is no visible activity regarding the package [c] for /six > months/, OR > > * A previous NMU was not acknowledged, and a bug justifying another NMU > is pending for /one month/ [c,d], OR > > * The last upload was an NMU and there was no maintainer upload within > /one year/, OR > > * Bugs exist for more than one major missing upstream version and the > first bug is older than /one year/, OR > > * The package blocks a sourceful transition for /six months/ after a > transition bug was filed against the package in question. I think that's maybe a bit too complicated. It all makese sense somehow in itself (and I guess I was involved in coming up with these conditions some years ago) but reading it I have the impression that I'll never remember it and will have to very carefully and concentrated re-read it in every case where I might want to salvage a package and hope that I get the result of several ANDs and ORs right. > Procedure to salvage a package > -- > > If the criteria described above are fulfilled, anyone interested can > start the following salvage procedure. This looks good in general. > 3) The upload replacing the former maintainers of the package can be > made can be prepared already after 21 days, but needs to go to > DELAYED/7. The salvage bug should be closed by the upload and an > nmudiff sent to the bug. The nmudiff should also explictly CC the > maintainer, the packaging team and all uploaders. Totally minor point: Why the nmudiff? Another thing that came to my mind is: The proposal talks (also in the last quoted paragraph) about "replacing the former maintainers"; what I in practice would like to do usually is to move a package which is under-maintained and has a single individuum in Maintainer to a team, with or without keeping this person in Uploaders. (I've also seen cases where the person is already a member of the team but maintains (or neglects) packages outside.) Maybe this is not relevant as it's covered by "changing the Maintainer field"; or maybe it is because it allows the future ex-maintainer to still work on the package, together with others in a team? Or maybe I'm just making things more complicated when I was asking for simpler guidelines before :) Thanks again for working on this, and a successful BoF in some hours! Cheers, gregor PS: Some nightly thoughts, not relevant for the BoF per se: Semi-radical proposal - "Salvaging a Package, the simple version" If a package is apparently un(der)-maintained (e.g. RC bugs without reply, several NMUs in a row, etc.) it can be salvaged, i.e. the maintainership transfered to another person or team. An ITS (Intent to Salvage) bug is raised against the package stating the intent. If the bug is closed by the maintainer or an uploader, the process is finished. Otherwise, after 1 month, the package can be taken over by a new maintainer person or team. = Less radical variant = If a package, which falls into the area of competence of a packaging team, is apparently un(der)-maintained (e.g. RC bugs without reply, several NMUs in a row, etc.) it can be salvaged, i.e. the maintainership transfered to the respective team. An ITS (Intent to Salvage) bug is raised against the package stating the intent. If the bug is closed by the maintainer or an uploader, the process is finished. Otherwise, after 1 month, the package can be taken over by the team; the previous maintainer is kept in Uploaders and invited to join the team and help in the maintenance of the package. Radical proposal Q: What is the worst that could happen if there was no package ownership in Debian? -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Trio Infernal: bottle of wine signature.asc Description: Digital Signature
