Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Thu, 8 Dec 2016 23:12:20 +0100, Christoph Biedl wrote: >Locale generation needs a lot of RAM. You can work around it by >installing locales-all which however takes long time to install on >slow flash drives. Or disable locales entirely. Err. Or build a locale-local package that only contains the locales you want. Does the locales package by any chance offer infrastructure to do that (like a build-locale-deb command, maybe)? And, while we're at it, how is "locale" pronounced? I have a native speaker in my filter bubble who claims that it's short for "local environment" and therefore pronounced "local e", but that sounds wrong for me. Is the example pronouncement given on http://dict.leo.org/dictQuery/m-vocab/ende/de.html?searchLoc=0&lp=ende&lang=de&directN=0&rmWords=off&search=locale&resultOrder=basic&multiwordShowSingle=on correct even in AmE? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#847738: ITP: gap-design -- block designs for GAP
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: gap-design Version : 1r6 Upstream Author : Leonard H. Soicher * URL : http://www.gap-system.org/Packages/design.html * License : GPL-2+ Programming Lang: GAP Description : block designs for GAP GAP is a system for computational discrete algebra with particular emphasis on computational group theory, but which has already proved useful also in other areas. This package provides for GAP routines for constructing, classifying, partitioning and studying block designs.
Bug#847739: ITP: gap-laguna -- LAGUNA GAP package
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: gap-laguna Version : 3.7.0 Upstream Author : Victor Bovdi Alexander Konovalov Richard Rossmanith Csaba Schneider * URL : http://www.gap-system.org/Packages/laguna.html * License : GPL-2+ Programming Lang: GAP Description : LAGUNA GAP package GAP is a system for computational discrete algebra with particular emphasis on computational group theory, but which has already proved useful also in other areas. LAGUNA stands for `Lie AlGebras and UNits of group Algebras'. This package provides GAP with functionality for calculation of the normalized unit group of the modular group algebra of the finite p-group and for investigation of Lie algebra associated with group algebras and other associative algebras.
Re: Release impact of introducing a new archive section?
On Thu, 2016-12-08 at 21:39 -0800, Josh Triplett wrote: > I've now written and submitted all of these patches. Might it be useful to have this list of names and descriptions in some canonical packaged location, such that updating these tools is just a version bump on a build dep, or even a runtime dep? Best case maybe it would be possible to arrange for it to be a simple binNMU. (my first thought was a canonical online location, but these tools may not want that at runtime and can't rely on it at build time, but maybe that should be the source used for the package) Ian.
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Sun, 11 Dec 2016 09:14:09 +0100, Marc Haber wrote: > And, while we're at it, how is "locale" pronounced? I have a native > speaker in my filter bubble who claims that it's short for "local > environment" and therefore pronounced "local e", but that sounds wrong > for me. Is the example pronouncement given on > http://dict.leo.org/dictQuery/m-vocab/ende/de.html?searchLoc=0&lp=ende&lang=de&directN=0&rmWords=off&search=locale&resultOrder=basic&multiwordShowSingle=on > correct even in AmE? Yes, locale isn't a neologism; it refers to a place: https://www.merriam-webster.com/dictionary/locale The pronunciation given on LEO is correct. Regards, Stephen pgpazyIkvLdan.pgp Description: OpenPGP digital signature
Bug#847744: ITP: node-v8flags -- Get available v8 flags
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-v8flags Version : 2.0.11 Upstream Author : Tyler Kellen (http://goingslowly.com/) * URL : https://github.com/tkellen/node-v8flags * License : Expat Programming Lang: JavaScript Description : Get available v8 flags.
Bug#847749: ITP: node-user-home -- Get the path to the user home directory
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-user-home Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/user-home * License : Expat Programming Lang: JavaScript Description : Get the path to the user home directory This is required for v8flags, which is a dependency of gulp. I tried patching v8flags, but 2 out of 6 tests are failing. If anyone could help me patch v8flags correctly, will drop the packaging of user-home.
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On Sun, Dec 11, 2016 at 04:58:08PM +0530, Sruthi Chandran wrote:
> * Package name: node-user-home
[...]
> * URL : https://github.com/sindresorhus/user-home
The only thing this module does is being an alias for os-homedir. This
is the complete contents of index.js:
'use strict';
module.exports = require('os-homedir')();
> This is required for v8flags, which is a dependency of gulp. I tried
> patching v8flags, but 2 out of 6 tests are failing. If anyone could help
> me patch v8flags correctly, will drop the packaging of user-home.
Isn't s/user-home/os-homedir/ not enough? In any case, maybe you should
try to get upstream to switch to os-homedir instead.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Re: Bug#847563: ITP: xtrackcad -- CAD program for designing model railroad layouts
On 09/12/16 15:14, Mike Gabriel wrote: Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: xtrackcad Version : 4.2.4a Upstream Author : Martin Fischer * URL : http://www.xtrkcad.org/Wikka/HomePage * License : GPL-2+, BSD Programming Lang: C Description : CAD program for designing model railroad layouts This package is already in Debian: https://packages.qa.debian.org/x/xtrkcad.html Cheers, Ross
Re: future of Debian amavisd-milter package
Paul Gevers writes ("Re: future of Debian amavisd-milter package"):
> On 08-12-16 23:24, Christoph Biedl wrote:
> > Although I'm not a user of that package, I consider removing it from
> > stretch the wrong thing to do.
>
> Opinions differ. I raised the issue of removing more packages from
> Debian a while ago and got different responses.¹
>
> If nobody is maintaining such a package and the package is not trivial,
> IMHO it may be better to not ship. Until now I am not convinced that
> shipping "not severely broken" packages is a service. I remember in the
> past that I had choice of multiple packages doing approximately the same
> thing and several were in bad shape. I wasted time on figuring out which
> one actually worked reasonably well. At the time (long ago), it didn't
> occur to me yet to file bugs, but the example stuck with me.
I don't think this problem should be solved by completely removing
packages which are essentially "in hibernation". Removing the
packages is quite difficult to work around for users, whereas this
discov erability problem is much more tractable.
For example, as an end user, you can look up the package on
tracker.d.o or bugs.d.o, to get a feel for it.
And if we wanted something more formal, we could invent a way to mark
packages as deprecated.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#847766: ITP: calamares-settings-debian -- Calamares settings for installing a default Debian system
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: calamares-settings-debian Version : 9.0-1 Upstream Author : Jonathan Carter * URL : https://gitlab.com/highvoltage/calamares-settings-debian * License : ISC Programming Lang: Shell / json Description : Calamares settings for installing a default Debian system Calamares is an installer framework that provides a graphical user interface for installing Linux distributions. . This package provides a theme and settings to install a Debian system. . Derivatives of Debian can use this as an example to ship settings for their systems.
Re: Hello: https://manpages.debian.org/man/1/uscan
Le 11/12/2016 à 03:28, Paul Wise a écrit : > You can read about the plans for manpages here: > > https://wiki.debian.org/manpages.debian.org Thank you for the link :) > The debmans software renders manual pages to proper HTML that looked > reasonable to me. According to https://debmans.readthedocs.io/en/latest/design.html#converter, there are several converters so depending which one is used, the generated html will be different. In the source code (debmans/renderer.py), I see classes to call W3M, Mandoc and man2html converters. I saw too that debian-doc is the right list for manpages.d.o so I will go there if I want more details. Stéphane signature.asc Description: OpenPGP digital signature
Bug#847777: ITP: node-package -- Easy package.json exports
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-package Version : 1.0.1 Upstream Author : Veselin Todorov * URL : http://github.com/vesln/package * License : FIX_ME upstream license Programming Lang: JavaScript Description : Easy package.json exports. signature.asc Description: OpenPGP digital signature
Bug#847778: ITP: node-temporary -- Easily create temporary files and directories
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-temporary Version : 0.0.8 Upstream Author : Veselin Todorov * URL : http://github.com/vesln/temporary * License : Expat Programming Lang: JavaScript Description : Easily create temporary files and directories signature.asc Description: OpenPGP digital signature
Bug#847781: ITP: extractpdfmark -- Extract page mode and named destinations as PDFmark from PDF
Package: wnpp Severity: wishlist Owner: "Dr. Tobias Quathamer" * Package name: extractpdfmark Version : 1.0.1 Upstream Author : Masamichi Hosoda * URL : https://github.com/trueroad/extractpdfmark * License : GPL-3+ Programming Lang: C++ Description : Extract page mode and named destinations as PDFmark from PDF When you create a PDF document using a TeX system, you may include many small PDF files in the main PDF file. It is common for each of those files to use the same fonts. . If the small PDF files contain embedded font subsets, the TeX system includes them as-is in the main PDF. As a result, several subsets of the same font are embedded in the main PDF. It is not possible to remove the duplicates since they are different subsets. This vastly increases the size of the main PDF file. . On the other hand, if the small PDF files contain embedded full font sets, the TeX system also includes all of them in the main PDF. This time, the main PDF contains duplicates of the same full sets of fonts. Therefore, Ghostscript can remove the duplicates. This may considerably reduce the main PDF-file's size. . Finally, if the small PDF files contain some fonts that are not embedded, the TeX system outputs the main PDF file with some fonts missing. In this case, Ghostscript can embed the necessary fonts. It can significantly reduce the required disk size. . Either way, when Ghostscript reads the main PDF produced by the TeX system and outputs the final PDF it does not preserve PDF page-mode and named-destinations etc. As a result, when you open the final PDF, it is not displayed correctly. Also, remote PDF links will not work. . This program is able to extract page mode and named destinations as PDFmark from PDF. By using this you can get the small PDF files that have preserved them. signature.asc Description: OpenPGP digital signature
Bug#847782: ITP: kdiagram -- library for creating business charts
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher * Package name: kdiagram Version : 2.6.0 Upstream Author : Klaralvdalens Datakonsult AB * URL : https://cgit.kde.org/kdiagram.git * License : GPL-2+ Programming Lang: C++ Description : library for creating business charts KD Chart and KD Gantt provide an implementation of the ODF Chart specification. They utilize the Qt's model-view programming model for easy integration in Qt based applications. If anyone from the Qt/KDE team wants to maintain this package instead, please feel free to take it. (massif-visualizer 0.6 will require KD Chart.) Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/11/2016 06:18 PM, Guus Sliepen wrote: > Isn't s/user-home/os-homedir/ not enough? In any case, maybe you should > try to get upstream to switch to os-homedir instead. os-homedir is not packaged, we have been patching that with os.homedir. In this case, the patching is partially working, 4 tests are passing and 2 are failing. I have pushed v8flags to alioth [1]. Please have a look. Test is "mocha -R spec test.js". [1] git+ssh://git.debian.org/git/pkg-javascript/node-v8flags.git signature.asc Description: OpenPGP digital signature
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/11/2016 06:29 PM, Sruthi Chandran wrote:
> On 12/11/2016 06:18 PM, Guus Sliepen wrote:
>> Isn't s/user-home/os-homedir/ not enough? In any case, maybe you should
>> try to get upstream to switch to os-homedir instead.
> os-homedir is not packaged, we have been patching that with os.homedir.
> In this case, the patching is partially working, 4 tests are passing and
> 2 are failing.
>
> I have pushed v8flags to alioth [1]. Please have a look. Test is "mocha
> -R spec test.js".
Side-note 1: there appears to be a dependency problem here when running
tests: for mocha to work (at least in this case), you also need the
package chai to be installed (otherwise it will fail with an error).
I think this is because test.js requires chai, but I'm not sure.
(I suspect the dependencies of mocha and node-v8flags themselves are
OK because it's not required for the package directly. OTOH you could
add the test suite to the package's autopkgtests and then add chai and
mocha to the Depends there.)
Problem 1:
- cleanup hook is missing some patching out:
delete require.cache[require.resolve('user-home')];
If that line is not removed, then the cleanup hook will fail with
require.resolve('user-home'), because that module is not installed.
Problem 2:
- after patching that out I get the following test results:
v8flags
✓ should cache and call back with the v8 flags for the running process
✓ should not append the file when multiple calls happen concurrently and
the config file does not yet exist
1) should fall back to writing to a temp dir if user home can't be found
✓ should fall back to writing to a temp dir if user home is unwriteable
2) should return flags even if an error is thrown
✓ should back with an empty array if the runtime is electron
The following errors occur:
1) v8flags should fall back to writing to a temp dir if user home can't be
found:
Uncaught AssertionError: expected false to be true
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/test.js:77:46
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:108:14
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:36:12
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:47:7
at nextTickCallbackWith0Args (node.js:420:9)
at process._tickCallback (node.js:349:13)
2) v8flags should return flags even if an error is thrown:
Uncaught AssertionError: expected null not to be null
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/test.js:98:28
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:108:14
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:36:12
at
/srv/external/Debian/Debugging/node-user-home-replacement/node-v8flags/index.js:47:7
at nextTickCallbackWith0Args (node.js:420:9)
at process._tickCallback (node.js:349:13)
In test.js there is a routine eraseHome() which unsets a lot of environment
variables. This is to trick the user-home module (which we rejected from
Debian, if you remember) to think it can't fetch the user's home directory,
and therefore trigger the fallback.
This is problematic because os.homedir() falls back to reading /etc/passwd
(as it should, that's a feature, not a bug), so it won't fail. That means
that the fallback to a temporary directory won't happen. This means that
in the first case the fallback won't be triggered, and the expectation of
the test is wrong.
The second failure is related: since it tries to trigger the "home dir
doesn't exist" error to see if the module will succeed anyway without
throwing an exception, it does expect the error in the callback passed
to the module to be non-null - since it expects an error to have occurred.
However, in this case there was no error.
This is not a failure in the module itself, this is only a problem with
the test suite.
There's an easy fix though: monkey-patch os.homedir to a function that
just returns null in eraseHome(), and restore it in cleanup().
I've attached an updated use-os-homedir.patch that does this (including
the removal of the require.resolve() line above), and the test suite
now passes for all 6 tests:
v8flags
✓ should cache and call back with the v8 flags for the running process
✓ should not append the file when multiple calls happen concurrently and
the config file does not yet exist
✓ should fall back to writing to a temp dir if user home can't be found
✓ should fall back to writing to a temp dir if user home is unwriteable
✓ should return flags even if an error is thrown
✓ should back with an empty array if the runtime is electron
6 passing (61ms)
Hope that helps.
Regards,
Christian
use os.homedir instead of user-home
--- a/index.js
+++ b/index.js
@@ -26,7 +26,7 @@ function fail (er
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/11/2016 06:52 PM, Christian Seiler wrote:
> I've attached an updated use-os-homedir.patch that does this (including
> the removal of the require.resolve() line above),
And I just noticed that I forgot a semicolon after a line (not
critical, because javascript doesn't require it, but stylistically
it's not nice) and had some trailing whitespace. I've updated the
patch and attached it.
Regards,
Christian
use os.homedir instead of user-home
--- a/index.js
+++ b/index.js
@@ -26,7 +26,7 @@ function fail (err) {
}
function openConfig (cb) {
- var userHome = require('user-home');
+ var userHome = os.homedir();
if (!userHome) {
return tryOpenConfig(path.join(os.tmpdir(), configfile), cb);
}
--- a/test.js
+++ b/test.js
@@ -7,6 +7,8 @@ const expect = require('chai').expect;
const env = process.env;
+const old_os_homedir = os.homedir;
+
function eraseHome() {
delete env.HOME;
delete env.USERPROFILE;
@@ -16,6 +18,8 @@ function eraseHome() {
delete env.USER;
delete env.LNAME;
delete env.USERNAME;
+
+ os.homedir = function() { return null; };
}
function setTemp(dir) {
@@ -24,7 +28,7 @@ function setTemp(dir) {
function cleanup () {
var v8flags = require('./');
- var userHome = require('user-home');
+ var userHome = os.homedir();
if (userHome === null) userHome = __dirname;
var files = [
@@ -37,7 +41,7 @@ function cleanup () {
} catch (e) {}
});
- delete require.cache[require.resolve('user-home')];
+ os.homedir = old_os_homedir;
delete process.versions.electron;
}
@@ -47,7 +51,7 @@ describe('v8flags', function () {
it('should cache and call back with the v8 flags for the running process', function (done) {
var v8flags = require('./');
-var configfile = path.resolve(require('user-home'), v8flags.configfile);
+var configfile = path.resolve(os.homedir(), v8flags.configfile);
v8flags(function (err, flags) {
expect(flags).to.be.a('array');
expect(fs.existsSync(configfile)).to.be.true;
@@ -62,7 +66,7 @@ describe('v8flags', function () {
it('should not append the file when multiple calls happen concurrently and the config file does not yet exist', function (done) {
var v8flags = require('./');
-var configfile = path.resolve(require('user-home'), v8flags.configfile);
+var configfile = path.resolve(os.homedir(), v8flags.configfile);
async.parallel([v8flags, v8flags, v8flags], function (err, result) {
v8flags(function (err2, res) {
done();
Bug#847790: ITP: node-pretty-hrtime -- process.hrtime() to words
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-pretty-hrtime Version : 1.0.3 Upstream Author : Rob Richardson (http://robrich.org/) * URL : https://github.com/robrich/pretty-hrtime * License : Expat Programming Lang: JavaScript Description : process.hrtime() to words signature.asc Description: OpenPGP digital signature
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/11/2016 11:30 PM, Christian Seiler wrote: >> I've attached an updated use-os-homedir.patch that does this (including >> the removal of the require.resolve() line above), Thanks a lot!!! That fixed it. signature.asc Description: OpenPGP digital signature
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/12/2016 12:20 AM, Sruthi Chandran wrote: > On 12/11/2016 11:30 PM, Christian Seiler wrote: >>> I've attached an updated use-os-homedir.patch that does this (including >>> the removal of the require.resolve() line above), > Thanks a lot!!! That fixed it. It was fixed in local build, but fails in sbuild. Can you check? signature.asc Description: OpenPGP digital signature
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 2016, ഡിസംബർ 11 6:18:41 PM IST, Guus Sliepen wrote:
>On Sun, Dec 11, 2016 at 04:58:08PM +0530, Sruthi Chandran wrote:
>
>The only thing this module does is being an alias for os-homedir. This
>is the complete contents of index.js:
>
>'use strict';
>module.exports = require('os-homedir')();
>Isn't s/user-home/os-homedir/ not enough? In any case, maybe you should
>try to get upstream to switch to os-homedir instead.
We rejected os-homedir as buggy and useless as os.homedir() is available in new
versions of nodejs. Upstream won't accept patches because they want to support
older nodejs versions.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug#847749: ITP: node-user-home -- Get the path to the user home directory
On 12/11/2016 07:57 PM, Sruthi Chandran wrote: > On 12/12/2016 12:20 AM, Sruthi Chandran wrote: >> On 12/11/2016 11:30 PM, Christian Seiler wrote: I've attached an updated use-os-homedir.patch that does this (including the removal of the require.resolve() line above), >> Thanks a lot!!! That fixed it. > It was fixed in local build, but fails in sbuild. Can you check? I see you enabled the tests during build; the problem here is that the tests write to the home directory, which is not allowed during package build (see a recent thread on debian-devel about that), and sbuild enforces that by setting the home directory of the sbuild user to something like /non-existent. You can manually set the HOME environment variable during testing to override that with a temporarily created directory. I've attached a git patch against your current packaging (you can use git am to apply it) that does just this. I've tried building it in sbuild -d unstable and it works - and the tests pass. Hope that helps. Regards, Christian From 20e34e4f7ab4ed42574460ce771dc6d76d8395b2 Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Sun, 11 Dec 2016 20:01:59 +0100 Subject: [PATCH] debian/rules: use fake HOME for tests Use a fake home directory for tests to ensure that no data in the real home directory is replaced during package build. --- debian/rules | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/rules b/debian/rules index eaa101b..d6b3496 100755 --- a/debian/rules +++ b/debian/rules @@ -10,6 +10,6 @@ #override_dh_auto_build: override_dh_auto_test: - mocha -R spec test.js - - + mkdir -p test-home + HOME=$(shell pwd)/test-home mocha -R spec test.js + rm -rf $(shell pwd)/test-home -- 2.10.2
Bug#847796: ITP: soapyredpitaya -- RedPitaya device support for SoapySDR
Package: wnpp Severity: wishlist Owner: Andreas Bombe * Package name: soapyredpitaya Version : 0.1.0 Upstream Author : Pavel Demin * URL : https://github.com/pothosware/SoapyRedPitaya/wiki * License : GPL-3+ Programming Lang: C++ Description : RedPitaya device support for SoapySDR The Soapy RedPitaya project provides a SoapySDR module for using the RedPitaya hardware platform as a SDR transceiver. This will be maintained in the hamradio team.
Bug#847795: ITP: soapyosmo -- use gr-osmosdr drivers in SoapySDR
Package: wnpp Severity: wishlist Owner: Andreas Bombe * Package name: soapyosmo Version : 0.2.4 Upstream Author : Josh Blum * URL : https://github.com/pothosware/SoapyOsmo/wiki * License : GPL-3 Programming Lang: C++ Description : OsmoSDR device support for SoapySDR The SoapyOsmo project provides SoapySDR modules to access the OsmoSDR, Mirics SDR, and RFSpace SDR hardware through the drivers in gr-osmosdr. This will be maintained in the hamradio team.
Bug#847797: ITP: soapyairspy -- Airspy device support for SoapySDR
Package: wnpp Severity: wishlist Owner: Andreas Bombe * Package name: soapyairspy Version : 0.1.0 Upstream Author : Charles J. Cliffe * URL : https://github.com/pothosware/SoapyAirspy/wiki * License : MIT Programming Lang: C++ Description : Airspy device support for SoapySDR The Soapy Airspy project provides a SoapySDR module for using the Airspy Software Defined Radio receiver. This will be maintained in the hamradio team.
Bug#847798: ITP: limesuite -- tools and drivers for Lime Microsystems LMS7002M RFIC
Package: wnpp Severity: wishlist Owner: Andreas Bombe * Package name: limesuite Version : git Upstream Author : Lime Microsystems * URL : https://myriadrf.org/projects/lime-suite/ * License : Apache-2.0 Programming Lang: C++ Description : tools and drivers for Lime Microsystems LMS7002M RFIC The Lime Suite is a collection of tools of software supporting several hardware platforms including the LimeSDR, drivers for the LMS7002M transceiver RFIC, and other tools for developing with LMS7-based hardware. It contains a SoapySDR driver module and tools to calibrate, test and update the devices. This will be maintained in the hamradio team.
How to get history into dgit
Hello, I would like to start using dgit for one of my packages, using the dgit-maint-merge workflow. If I understood correctly, following the dgit-maint-merge(7) instructions for the initial setup will give me a repository with only the upstream git history, but no data from previous Debian packages. Is there a good way to import the existing package history as well? Until now, I've used git-dpm, but I don't really need the full git-dpm history, I'd be happy to just preserve the uploaded versions. Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Release impact of introducing a new archive section?
On Sun, Dec 11, 2016 at 09:45:36AM +, Ian Campbell wrote: > On Thu, 2016-12-08 at 21:39 -0800, Josh Triplett wrote: > > I've now written and submitted all of these patches. > > Might it be useful to have this list of names and descriptions in some > canonical packaged location, such that updating these tools is just a > version bump on a build dep, or even a runtime dep? Best case maybe it > would be possible to arrange for it to be a simple binNMU. > > (my first thought was a canonical online location, but these tools may > not want that at runtime and can't rely on it at build time, but maybe > that should be the source used for the package) Packaging this data (section names, short descriptions, and long descriptions) seems like a great idea. Ideally, packages would have a Depends on this and use the data at runtime, rather than using a Build-Depends and compiling it in. With some care, such a package could also serve as the basis for the descriptions on packages.debian.org. - Josh Triplett
Re: Release impact of introducing a new archive section?
On 14518 March 1977, Josh Triplett wrote: >> (my first thought was a canonical online location, but these tools may >> not want that at runtime and can't rely on it at build time, but maybe >> that should be the source used for the package) > Packaging this data (section names, short descriptions, and long > descriptions) seems like a great idea. Ideally, packages would have a > Depends on this and use the data at runtime, rather than using a > Build-Depends and compiling it in. With some care, such a package could > also serve as the basis for the descriptions on packages.debian.org. Does it need a package? Or just a file in the archive somewhere? -- bye, Joerg
Re: Release impact of introducing a new archive section?
On Sun, Dec 11, 2016 at 10:16:51PM +0100, Joerg Jaspert wrote: > On 14518 March 1977, Josh Triplett wrote: > >> (my first thought was a canonical online location, but these tools may > >> not want that at runtime and can't rely on it at build time, but maybe > >> that should be the source used for the package) > > Packaging this data (section names, short descriptions, and long > > descriptions) seems like a great idea. Ideally, packages would have a > > Depends on this and use the data at runtime, rather than using a > > Build-Depends and compiling it in. With some care, such a package could > > also serve as the basis for the descriptions on packages.debian.org. > > Does it need a package? Or just a file in the archive somewhere? If we can get every package to handle this entirely at runtime, then ideally I'd suggest archive metadata downloaded by apt. That would have the advantage of automatically handling new sections, including for third-party archives. Packaging it doesn't have that advantage, though it also seems logistically simpler. - Josh Triplett
Re: How to get history into dgit
Hi, Quoting Nikolaus Rath (2016-12-11 21:17:50) > I would like to start using dgit for one of my packages, using the > dgit-maint-merge workflow. > > If I understood correctly, following the dgit-maint-merge(7) > instructions for the initial setup will give me a repository with only > the upstream git history, but no data from previous Debian packages. > > Is there a good way to import the existing package history as well? > > Until now, I've used git-dpm, but I don't really need the full > git-dpm history, I'd be happy to just preserve the uploaded versions. This thread seems relevant to your query: https://lists.debian.org/1439889317.1468.21.ca...@debian.org cheers, josch signature.asc Description: signature
Re: How to get history into dgit
Hello Nikolaus, On Sun, Dec 11, 2016 at 12:17:50PM -0800, Nikolaus Rath wrote: > I would like to start using dgit for one of my packages, using the > dgit-maint-merge workflow. dgit-maint-merge(7) author here. > If I understood correctly, following the dgit-maint-merge(7) > instructions for the initial setup will give me a repository with only > the upstream git history, but no data from previous Debian packages. > > Is there a good way to import the existing package history as well? > > Until now, I've used git-dpm, but I don't really need the full > git-dpm history, I'd be happy to just preserve the uploaded versions. What I would do in this situation is, starting with your existing packaging history, 1) Ensure HEAD is dgit-compatible. This means patches are applied, debian/source/local-options does not exist, etc. 2) Do the steps under "git configuration" and "source package configuration" in the manpage. 3) rm -r debian/patches. Now you should be able to work as per "building and uploading" and "new upstream releases" in the manpage. If your existing history is disjoint from upstream, the first new upstream release you merge might require --allow-unrelated-histories. -- Sean Whitton signature.asc Description: PGP signature
Re: OpenSSL 1.1.0
Hello, On Wed, Nov 16, 2016 at 04:03:04PM +, Jonathan Wiltshire wrote: > On 2016-11-16 12:26, Ian Jackson wrote: > > In the absence of input from the openssl maintainers, I would like to > > ask the Release Team's opinion. > > > > If we are going to wind back on this change we should do it ASAP. We > > should not allow ourselves to make the decision to press on, simply by > > failing to decide otherwise. > > Indeed it's been under discussion for the past week or so independent of the > thread on -devel. I hope you'll forgive me for not breaking confidences just > yet, but we expect to be able to resolve this very soon. Sorry to resurrect an old thread, but did I miss an e-mail follow-up to this? -- Sean Whitton signature.asc Description: PGP signature
Re: How to get history into dgit
On Dec 11 2016, Sean Whitton wrote: > Hello Nikolaus, > > On Sun, Dec 11, 2016 at 12:17:50PM -0800, Nikolaus Rath wrote: >> I would like to start using dgit for one of my packages, using the >> dgit-maint-merge workflow. > > dgit-maint-merge(7) author here. Thanks for writing it :-). >> If I understood correctly, following the dgit-maint-merge(7) >> instructions for the initial setup will give me a repository with only >> the upstream git history, but no data from previous Debian packages. >> >> Is there a good way to import the existing package history as well? >> >> Until now, I've used git-dpm, but I don't really need the full >> git-dpm history, I'd be happy to just preserve the uploaded versions. > > What I would do in this situation is, starting with your existing > packaging history, > > 1) Ensure HEAD is dgit-compatible. This means patches are applied, > debian/source/local-options does not exist, etc. > > 2) Do the steps under "git configuration" and "source package > configuration" in the manpage. > > 3) rm -r debian/patches. Ah, that makes sense. I guess I'm still mentally adjusting to dgit's flexibility. Thanks! Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Re: How to get history into dgit
On Dec 11 2016, Sean Whitton wrote: > 1) Ensure HEAD is dgit-compatible. This means patches are applied, > debian/source/local-options does not exist, etc. Actually, could you expand on the "etc"? What else do I need to ensure? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#847809: ITP: tcvt -- multicolumn virtual terminal
Package: wnpp Severity: wishlist Owner: "Ferenc Wágner" * Package name: tcvt Version : git snapshot 82c24e2 Upstream Author : Helmut Grohne * URL : http://subdivi.de/~helmut/tcvt/ * License : BSD-2-clause Programming Lang: Python Description : multicolumn virtual terminal Your screen is getting wider. Keeping track of long lines gets harder. Space on the right hand side of the screen is completely blank due to short lines. Are you struggling with these? Then tcvt is for you. . The two column virtual terminal, short tcvt, can be used to vertically split a single terminal in two columns. This is similar to a two column layout in printing, just for regular terminals. . Note that this is not about placing two terminals next to each other. This task is already solved by tiling window managers, screen, tmux and splitvt. What tcvt does is create a single very tall terminal with two columns. I find this utility very useful for some administrative tasks.
Bug#847811: ITP: tendermint-go-crypto -- Go library for cryptography
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tendermint-go-crypto Version : 0.0~git20160724.0.4b11d62-1 Upstream Author : Tendermint * URL : https://github.com/tendermint/go-crypto * License : Apache-2.0 Programming Lang: Go Description : Go library for cryptography This package provides a number of convenience functions and types to handle public key cryptography. . This package is used by Tendermint Core. . Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine, written in any programming language, and replicates it on many machines.
Bug#847815: ITP: golang-github-btcsuite-btcd-btcec -- Go library for Elliptic curve cryptography
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: golang-github-btcsuite-btcd-btcec Version : git snapshot Upstream Author : The btcsuite developers * URL : https://github.com/btcsuite * License : ISC Programming Lang: Go Description : Go library for Elliptic curve cryptography Package btcec implements elliptic curve cryptography needed for working with Bitcoin (secp256k1 only for now). It is designed so that it may be used with the standard crypto/ecdsa packages provided with go. A comprehensive suite of test is provided to ensure proper functionality. . This package contains convenience utilities and shortcuts used across the Tendermint projects.
Re: How to get history into dgit
Hello Nikolaus, On Sun, Dec 11, 2016 at 02:27:15PM -0800, Nikolaus Rath wrote: > On Dec 11 2016, Sean Whitton wrote: > > 1) Ensure HEAD is dgit-compatible. This means patches are applied, > > debian/source/local-options does not exist, etc. > > Actually, could you expand on the "etc"? What else do I need to ensure? You have to ensure that the contents of HEAD is exactly what you would get if you ran `dpkg-buildpackage -i\.git/ -I.git -S` and then unpacked the resultant source package. debian/source/local-options is one way to break that. There are other ways, not all of which I can remember, so I wrote 'etc' :) You can just run `dgit build-source` and it will error out if you missed something. Btw, I've filed #847807 if you have any other suggestions. -- Sean Whitton signature.asc Description: PGP signature
Bug#847816: ITP: golang-github-btcsuite-btcd-chaincfg-chainhash -- generic hash types and functions for Golang
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: golang-github-btcsuite-btcd-chaincfg-chainhash Version : git snapshot Upstream Author : The btcsuite developers * URL : https://github.com/btcsuite/btcd * License : ISC Programming Lang: Go Description : generic hash types and functions for Golang chainhash provides a generic hash type and associated functions that allows the specific hash algorithm to be abstracted. . This package contains convenience utilities and shortcuts used across the Tendermint projects and is a dependency of Tendermint Core.
Re: Bug#843073: dpkg-shlibdeps fix for merged /usr
On Nov 21, Guillem Jover wrote: > First I have to go over a list of queued pending items and then I'll > get to this during this week. I have not yet reviewed the patches (in > part because I didn't do much Debian stuff last week due to lack of > motivation after an unpleasant interaction precisely due to this > issue, and TBH it has become one of those energey drainers), there's > a pending run in rebootstrap by Helmut (which is now waiting for a > gixed gcc), and then I need to write a mail summary of the current > situation and implications. Do you have any updates about reviewing this patch? -- ciao, Marco signature.asc Description: PGP signature
Bug#847824: ITP: golang-github-cloudflare-go-metrics -- Cloudflare's fork of Go port of Coda Hale's Metrics library
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-cloudflare-go-metrics Version : 0.0~git20151117.0.6a9aea3-1 Upstream Author : Cloudflare * URL : https://github.com/cloudflare/go-metrics * License : Expat Programming Lang: Go Description : Cloudflare's fork of Go port of Coda Hale's Metrics library This package is a fork of Richard Crowley's Go port of Coda Hale's Metrics library for Java. It allows one to easily collect metrics from an application written in Go in an unobtrusive way. Metrics can then be exported to syslog, files or to a storage system like Graphite.
Auto-detecting -dev package dependences from pkg-config
[Please CC me on replies.] dpkg-shlibdeps automatically generates Depends on library packages corresponding to any libraries pulled in by the linker for the binaries in a package. However, library -dev packages still have to manually specify Depends on -dev packages that they require. In many cases, we could infer this information from pkg-config dependencies: if a library -dev package ships a pkg-config file, and that file includes Requires pointing to other pkg-config files, we could infer Depends on the packages shipping those other pkg-config files. I'd like to build some tools (possibly including a dh_pkgconfig) to do this automatically; those tools could generate a pkgconfig:Depends substvar for use in debian/control. Before starting on those tools, I'd like to get some feedback on this idea. For me, this problem came up while working on Debian packaging for Rust libraries. I needed a solution to handle Rust libraries that provide FFI wrappers for C libraries, and need Depends on the corresponding -dev packages. I can currently autogenerate all the packaging for Rust packages, and I'd like to handle this case automatically as well. Most Rust libraries use pkg-config to find the C libraries they depend on. I have some work in progress to make those pkg-config dependencies programmatically parseable. In the course of doing so, I realized that the same work could simplify the Depends of C library -dev packages as well. Assume we can parse a list of pkg-config (name, minimum version) pairs from a package. This would ideally come from declarative metadata, though I can also think of multiple ways to obtain it from more programmatic sources. Given such a list, dh_pkgconfig could find all the corresponding pkg-config files, and add a substvar containing the corresponding Depends. For each version requirement, dh_pkgconfig would turn that into a versioned Depends on the corresponding -dev package. (Insert some handwaving here about how to generate a Debian version from a pkg-config version. In 99% of cases ">= version" will work; in the other 1% of cases, -dev packages could provide some kind of mapping expression.) Does this seem like a reasonable approach? - Josh Triplett
Bug#847829: ITP: libcatalyst-view-csv-perl -- CSV view class for the Catalyst web framework
Package: wnpp Owner: Christopher Hoskin Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcatalyst-view-csv-perl Version : 1.5 Upstream Author : Michael Brown * URL : https://metacpan.org/release/Catalyst-View-CSV * License : Artistic or GPL-1+ Programming Lang: Perl Description : CSV view class for the Catalyst web framework Catalyst::View::CSV provides a Catalyst view that generates CSV files. You can use either a Perl array of arrays, an array of hashes, an array of objects, or a database cursor as the source of the CSV data. The CSV file is generated using Text::CSV. The package will be maintained under the umbrella of the Debian Perl Group.
Re: What happened to the idea of using migrations and coordinated uploads when updating packages that has many reverse dependencies?
On ചൊവ്വ 06 ഡിസംബര് 2016 01:26 രാവിലെ, Paul Gevers wrote: > What we need is improved handling of transitions in the JavaScript area > of our archive. Having jquery (and jquery-ui) not updated for stretch, > was IMHO also not an option. But these kind of thing need to trigger > proper transitions, like we do for libraries. After many days of troubleshooting, we have fixed this issue. jquery-ui-rails was not just embedding jquery-ui, but adapting it for sprockets/rails assets pipeline by adding dependency information at the top of the file. We now build ruby-jquery-ui-rails from node-jqueryui. > I believe that jquery was believed to be backwards compatible (at least > that is what I understood from the logs). I felt that I had to fix the > jquery-ui situation before stretch, mostly because the old package > wasn't build from source. I could have filed an RC bug about that but I > believe the maintainer isn't active in Debian these days, so that > wouldn't be a great solution. I decided to fix the package myself and > take the blame So I am taking the blame here and now. I didn't > realize how fragile the JavaScript interface in our archive is. There was a clear breaking of api. all jquery-ui/ changed to jquery-ui/widgets/ and similarly for effects. At least jquery-ui-rails author marked the breakage with clear major version update. > Sorry, and to prevent further damage, I'll not touch existing JavaScript > packages again. That is not a good outcome either. I also broke things in the past and got even stronger responses from affected maintainers (http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20161010/007756.html), after testing the direct reverse dependencies, but did not transitively check all, but I did not stop. What I suggest is the following, 1. When handling fragile languages (javascript, ruby, go and possibly more), we should not assume minor versions will not introduce breaking changes, at the minimum when dealing with development versions (in SemVer language, <= 0). 2. Ask the upstream about their policy of updates. Ask them if they follow SemVer or can consider it. https://wiki.debian.org/Teams/Ruby/UpstreamPledge I have got many positive replies (to my surprise) from many ruby gem authors. 3. Check the changelog for any possible breaking changes, even if it is removing deprecated apis, reverse dependencies need time to update. 4. Don't assume all upstream would have already updated to the new version in 6 months. 5. Use tools like build-and-upload script from pkg-ruby-extras so we know reverse dependencies with defined tests are not broken at least. 6. Increase the test coverage in the repo so library updates can be easily tested using tools like build-an-upload. At the least try to add a few smoke tests (just add require/import/include of the library - so at least file name changes can be caught) 7. Even with all this, we may break things, but then please help the affected maintainers to fix the issue. Having to fix all breakages alone when you are maintaining packages with long list of dependencies (like gitlab, diaspora, prometheus etc) is really demotivating. signature.asc Description: OpenPGP digital signature
Bug#847833: ITP: zram-tools -- Scripts for managing and monitoring zram usage
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: zram-tools Version : 0.1 Upstream Author : Jonathan Carter * URL : https://github.com/highvoltage/zram-tools * License : ISC Programming Lang: Shell Description : Scripts for managing and monitoring zram usage zram is a linux kernel feature that allows you to store compressed files to ram disk. . It's useful in cases where you have little RAM and can't swap to disk, this allows you to set up compressed swap space in RAM. . zram-tools also plans to expand on use cases that might be good for zram, such as setting up a compressed ramdisk for tmp or buildspace.
