Re: Editor extensions to help editing debian/* files?
On Sunday, 21 January 2024 08:43:05 CET Otto Kekäläinen wrote: > What editors and extensions are you using to augment your productivity > and minimize mistakes when editing debian/* files? That's not exactly an editor extension, but I use 'cme edit dpkg' to modify debian files. This tool provide a GUI with integrated help to edit most debian/* files. See https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme HTH
Debian: perl6 package is replaced by raku package
Hi Some of you may have wondered by perl6 package vanished from Debian Bookworm (aka testing). Belatedly following the rename of Perl6 language to Raku, I've renamed most Debian packages related to Raku. Among them, perl6 package was renamed raku. You can now install raku package to get rakudo compiler and the raku modules that are available in Debian [1]. All the best Dod PS: this announcement does not apply to Debian 11 (aka stable or bullseye) [1] https://qa.debian.org/developer.php?login=pkg-rakudo-devel%40lists.alioth.debian.org
Rakudo has a transition tracker and then what ?
Hello I'm a bit lost with the transition tracker and ben. Rakudo modules used to be delivered as Rako source and pre-compiled at installation time. This was not very user friendly, and I've modified the package so that Raku modules are pre-compiled at package build time. Unfortunately, this pre-compilation process must be redone at each new rakudo release (every month or so). Hoping to automate this process, I've setup a transition tracker for Rakudo [1]. I was expecting that these tracked packages would be rebuilt automagically, but that did not happen. All package are red and nothing was rebuilt. What did I miss ? Is there some setup required elsewhere ? All the best Dod [1] https://release.debian.org/transitions/html/rakudo.html
Bug#997838: ITP: libdist-zilla-plugin-signature-perl -- sign releases with Module::Signature
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-signature-perl Version : 1.100930 Upstream Author : Graham Barr * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Signature * License : perl Programming Lang: Perl Description : sign releases with Module::Signature Dist::Zilla::Plugin::Signature will sign a distribution using Module::Signature. This plugin should appear after any other AfterBuild plugin in your dist.ini file to ensure that no files are modified after it has been run The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
On Thursday, 1 April 2021 08:52:46 CEST Andrey Rahmatullin wrote: > Can you please list some unsupported chips in addition to these specific > Realtek ones? My daughter's laptop (an HP pavilion) has a RTL8821CE wifi chip which is not supported. All the best
cme now handles lintian-overrides (was: Re: About lintian)
On Wednesday, 27 January 2021 14:26:41 CET Andreas Tille wrote: > > I can add support to lintian-overrides in cme. I can also add a more or > > less automatic update of renamed tags. > > > > Is this something Debian people would like to see ? > > YES. (Since cme rocks - thanks again for working on it.) Done. Once libconfig-model-dpkg-perl/experimental is installed on your system, 'cme check dpkg' checks the contents of all lintian-overrides files and warn about unknown tags. The command 'cme fix dpkg' replaces obsolete tags with new tag names. No other check is done on lintian-overrides files. I could also provide a cme command that would check only overrides files *only* (i.e. 'cme fix lintian-overrides' would not touch all the other package files). This could be useful as a lintian-brush script. Is this something Debian people would be interested in ? All the best
Re: About lintian
On Thursday, 21 January 2021 23:18:07 CET Felix Lechner wrote: > While we often change tag names (or combine tags etc.), the majority > of the renames people talk about seems to stem from two bug reports by > third parties asking that we make tag names more consistent (bug > numbers are available, if needed). I can add support to lintian-overrides in cme. I can also add a more or less automatic update of renamed tags. Is this something Debian people would like to see ? Any volunteer to help ? (I'm still worried about the bus factor of cme) All the best Dod
Bug#966507: ITP: prove6 -- test runner based on TAP harness
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-rakudo-de...@lists.alioth.debian.org * Package name: prove6 Version : 0.0.12-1~1.gbp4f786b Upstream Author : Leon Timmermans * URL : https://github.com/Leont/app-prove6 * License : Artistic-2.0 Programming Lang: Raku Description : test runner based on TAP harness prove6 is an implementation in Raku language of Perl's prove command. This command runs a set of test through a TAP harness
Bug#966506: ITP: raku-getopt-long -- A powerful getopt implementation for Raku
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-rakudo-de...@lists.alioth.debian.org * Package name: raku-getopt-long Version : 0.1.6-1~1.gbp99eaf4 Upstream Author : Leon Timmermans * URL : https://github.com/perl6/getopt-long6 * License : Artistic-2.0 Programming Lang: Raku Description : A powerful getopt implementation for Raku The Getopt::Long module implements extended getopt functions called get- options() and get-options-from, as well as automatic argument parsing for a MAIN sub. This function adheres to the POSIX syntax for command line options, with GNU extensions. In general, this means that options have long names instead of single letters, and are introduced with a double dash "--". Support for bundling of command line options, as was the case with the more traditional single-letter approach, is also provided.
Re: Preferred install file: plain debian/install or debian/pkg.install ?
On Tuesday, 28 July 2020 11:12:05 CEST Andrey Rahmatullin wrote: > No, it's just documented in the common place, debhelper(7): Oh.. ok.. Thanks for the reminder. All the best
Preferred install file: plain debian/install or debian/pkg.install ?
Hi I'm working on improving cme dpkg behavior regarding debian/*install files. When a source package produces only one binary package, I've seen install file provided as "debian/install" or "debian/.install". Knowing that dh_install man page only mentions the second form, should cme assume that plain "debian/install" is deprecated ? In that case, what should cme do ? - always rename "debian/install" in "debian/.install" - warn about "debian/install" and offer to rename it to "debian/ .install" with "cme fix" - still accept both files and let maintainer decide which for to use Feel free to pitch in other ideas... All the best Dod
Bug#955365: ITP: libdist-zilla-plugin-minimumperlfast-perl -- Quickly detects the minimum version of Perl required for your dist
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-minimumperlfast-perl Version : 0.003 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/Dist-Zilla-Plugin-MinimumPerlFast * License : Artistic or GPL-1+ Programming Lang: Perl Description : Quickly detects the minimum version of Perl required for your dist Dist::Zilla::Plugin::MinimumPerlFast is a plugin for Dist::Zilla Perl module. It uses Perl::MinimumVersion::Fast to automatically find the minimum version of Perl required for your dist and adds it to the prerequisites of your Perl distribution (aka prereqs). The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#955306: ITP: libperl-minimumversion-fast-perl -- Find a minimum required version of perl for Perl code
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libperl-minimumversion-fast-perl Version : 0.18 Upstream Author : tokuhirom * URL : https://metacpan.org/release/Perl-MinimumVersion-Fast * License : Artistic or GPL-1+ Programming Lang: Perl Description : Find a minimum required version of perl for Perl code Perl::MinimumVersion::Fast module takes Perl source code and calculates the minimum version of perl required to be able to run it. Because it is based on goccy's Compiler::Lexer, it can do this without having to actually load the code. Perl::MinimumVersion::Fast is an alternative fast & lightweight implementation of Perl::MinimumVersion. The package will be maintained under the umbrella of the Debian Perl Group. This module is a dependency of libdist-zilla-plugin-minimumperlfast-perl -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#954951: ITP: libcompiler-lexer-perl -- Lexical Analyzer for Perl5
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcompiler-lexer-perl Version : 0.23 Upstream Author : Masaaki Goshima (goccy) * URL : https://metacpan.org/release/Compiler-Lexer * License : Artistic or GPL-1+ Programming Lang: Perl Description : Lexical Analyzer for Perl5 Compiler::Lexer provides a lexical analyser for Perl code. Once the Perl code is parsed, the lexer can provide: * a list of tokens * the list of module used by the Perl code. This module is written in XS to be faster than a pure Perl implementation. This module is a dependency of libdist-zilla-plugin-minimumperlfast-perl which I plan to package. The package will be maintained under the umbrella of the Debian Perl Group.
Re: Heads up: persistent journal has been enabled in systemd
On Wednesday, 5 February 2020 22:40:29 CET Dmitry Smirnov wrote: > There are log readers like "lnav" and "multitail" that will become useless > without traditional log files. "lnav" tails multiple logs by default and > IMHO provides a very useful interface. multitail provides -l option to read logs from a command. For instance: SYSTEMD_COLORS=0 multitail -l 'journalctl -f' lnav has a similar feature: SYSTEMD_COLORS=0 journalctl -f | lnav Hope this helps
Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
On Thursday, 9 January 2020 09:21:23 CET Paul Gevers wrote: > It's a wiki though, you can improve the > text if it's unclear to you. :-) I was not sure to have the right answer.. Now that I've understood, I've updated the wiki. All the best
Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
On Wednesday, 8 January 2020 20:42:45 CET Andreas Beckmann wrote: > > I checked the piuparts documentation just then [2] and found out that > > unlike ci.d.o or reproducible-build checks, the piuparts test will *not* > > automatically be retried for the same package of the same version (same > > upload). > > Where is that written? Boyuan Yang gave a link to debian wiki: https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F The answer mentions that package are not automatically retested. Whether this applies to package that passed or failed piupart test is not specified. I assumed the latter. All the best
Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
On Friday, 27 December 2019 02:56:07 CET Mo Zhou wrote: > https://wiki.debian.org/CopyrightReviewTools > > I'm unfamiliar with most of them. I'm only describing the two I'm familiar > with. Both licensecheck (Jonas) and debmake (Osamu) do template/regex > matching. I'd suggest you to look at 'cme' as this tool is closer to what you want to achieve. For details, please see https://github.com/dod38fr/config-model/wiki/ Updating-debian-copyright-file-with-cme > * Tree structure is always missing. after importing a new upstream release > with significant directory layout change, it will be inconvenient to > locate the parts of debian/copyright should be updated. Things will become > more complex when new licenses/copyrights emerged. This use case is handled by 'cme update dpkg-copyright' which merges information from current debian/copyright with the information provided by the new release. > * licensecheck dumps garbage when it encounters a binary file, e.g. PNG > image. This is not a BUG, as ftp-masters indeed checks the possible > metadata in a binary file to make sure whether there is extra > copyright/license info. But this is something needs to be improved... As cme relies of licensecheck, this is also a sore point which can be allieciated by tuning debian/fill.copyright.blanks.yml (see URL above for details) > The core of my idea is a tree-structured intermediate representation (IR) > for the "license reviewing tree". The IR is basically a directory tree with > annotations on the file nodes. The IR can be stored as a, say, JSON file. This IR tree is constructed by 'cme' when processing licensecheck information, but is not saved after debian/copyright is updated. > To build such an tree-shaped IR, we need a couple of "backend" tools for > checking the copyright & license info for a SINGLE file. Such "backend" > includes but not limited to: > > * `licensecheck`. Given a file FILE, `licensecheck FILE` produces the > license name. > * `grep` or `ripgrep`. For example, `rg -i copyright FILE` always works > well. * "neighbor". For example, given a source file "F/I/L/E" without any > copyright & license info, looking for F/I/L/LICENSE, F/I/LICENSE, ..., etc > like git does for the ".git" directory will help. cme also infers "global" license information from README, LICENSE files to use as default values when no specific license information is found in files. > The formated+filtered output of any combination of these backends can be > attached to the corresponding IR. > > In contrast, a "frontend" tool is also needed for dealing with such IR > in a higher level. My imagined "frontend" tool is a `ranger`-like file > browser with specific designs. cme provides a frontend to debian/copyright structure (shown as a tree in this frontend) with 'cme edit dpkg-copyright' See https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#maintaining-debian-copyright-file > * the user can choose what backend(s) to use. If none is chosen, the > frontend tool falls back into a general file browser with a preview panel. cme only uses licensecheck backend. I did not see a need to try another tool to extract license information from files. > How to proceed > -- > > * a group of interested contributors. If needed, I'm willing to tweak cme (*) so you can re-use cme (or parts thereof) for your project. All the best (*) Actually, the code that handles copyright information is in libconfig- model-dpkg-perl, which is a cme plugin to handle dpkg files: https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl
Automatic update of Vcs-Git info (was Re: Git Packaging Round 2: When to Salsa)
On Friday, 13 September 2019 15:00:11 CEST gregor herrmann wrote: > That's obviously an artifact of our poor Vcs-* information handling > (in source packages); in reality, of course all of the 3600+ > perl-team packages are maintained on salsa. For what it's worth, Vcs-Git info can be updated automatically with 'cme run set-vcs-git`. This command shoud be run in each repo. It won't change files if VCS-Git is already up-to-date. Here's the output of 'cme run set-vcs-git --doc' $ cme run set-vcs-git --doc update control Vcs-Browser and Vcs-git from git remote value parameters: remote (default is origin) example: cme run set-vcs-git cme run set-vcs-git -arg remote=debian will commit with message: 'control: update Vcs-Browser and Vcs-Git' Hope this helps Dod
Bug#927748: ITP: libdist-zilla-plugin-checkextratests-perl -- dzil command to check xt tests before release
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-checkextratests-perl Version : 0.029 Upstream Author : David Golden Jesse Luehrs * URL : https://metacpan.org/release/Dist-Zilla-Plugin-CheckExtraTests * License : Apache-2.0 Programming Lang: Perl Description : dzil command to check xt tests before release This package provides a plugin command for Dist::Zilla build sytem for Perl libraries. Once this package is installed, you run run "dzil xtest" to run the tests stored in xt directory. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Doubt on installation
On Thursday, 28 March 2019 12:21:17 CET ravichandhiran Sathish wrote: > I am using Windows 10 in my system. I just want to change it > to Debian os. Can you help me to install it. You can get everything you need to install Debian on your PC there: https://www.debian.org/distrib/ All the best
Re: V8 depends from outdated and unmaintained libv8 with security issues
On Monday, 11 February 2019 09:51:11 CET Jérémy Lal wrote: > that's what i tried to do in the first place. > However, the lack of v8 soname and abi stability across versions gave me so > much additional work that i ended up not doing it at all, leading to v8 > being unmaintained. The solution here is purely practical, it offers a way > to get a maintained v8 in debian, for very low additional time cost, > because nodejs 10 will be maintained up until april 2021 [2] ok... Unfortunately, I cannot offer advice for the solution you've proposed. This goes way over my head. I'll let others chime in. All the best
Re: V8 depends from outdated and unmaintained libv8 with security issues
Hi On Friday, 8 February 2019 12:10:01 CET Jérémy Lal wrote: > > I suppose i need to ask a removal of libv8 from unstable (it's removed > > from testing) to > > be able to "take" libv8-dev. Or maybe declare a libv8-in-nodejs-dev > > package ? > > In any case i don't know if i should make a libv8-xx package (which would > > basically be > > symlinks to libnode). > > Any advice is welcome... I think the following should happen: * update libv8 from new upstream source. [1] * build nodejs for Debian using the updated libv8 packages as required by Debian policy [2] Rakudo packaging team faced a similar issue with moarvm [3] which includes a convenience copy of libtommath and libuv1. We had to: * take over and update libuv1, libtommath packages that were outdated * add a Files-Excluded: line in marvm's debian/copyright to remove the convenience copies of libuv and libtommath * use options provided by moarvm build tools to use system libraries instead of the convenience copy. Hope this helps [1] Either https://chromium.googlesource.com/v8/v8.git or its "official" mirror https://github.com/v8/v8. [2] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-of-code [3] https://salsa.debian.org/perl6-team/moarvm
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
On Wednesday, 9 January 2019 15:22:32 CET Mike Gabriel wrote: > Those jquery.* et al. files are in folder paths that contain blanks. > Ouch. It seems that our tool chain components fail completely on > handling them. Or maybe I am doing entirely wrong. This looks like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198507 :-/
New RC version of libtommath in experimental
Hello I've uploaded a new RC version of libtommath in experimental. Please test at will. Hopefully, the non-RC version will be ready before the freeze. All the best Dod
Bug#916868: ITP: libconfig-model-backend-yaml-perl -- Read and write config as a YAML data structure
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libconfig-model-backend-yaml-perl Version : 2.132 Upstream Author : Dominique Dumont * URL : https://metacpan.org/release/Config-Model-Backend-Yaml * License : LGPL-2.1 Programming Lang: Perl Description : Read and write config as a YAML data structure Config::Model::Backend::Yaml is a Perl module used by Config::Model and cme to read or write YAML files. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Should the weboob package stay in Debian?
On Thursday, 26 July 2018 09:53:08 CEST Sune Vuorela wrote: > The woob command would then lookup the "original" name in the mappings > file and exec the correct one with remaining args. > This is probably fairly low maintenance once created, but it still has > the bad names on the file system, though hidden away out of path. The man page would be out of sync with woob command and sub-commands. Do you have an idea on how to handle them ? All the bets
Bug#900271: ITP: libsoftware-licensemoreutils-perl -- More utilities and a summary for Software::License
Package: wnpp Owner: Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsoftware-licensemoreutils-perl Version : 0.003 Upstream Author : * URL : https://metacpan.org/release/Software-LicenseMoreUtils * License : Artistic or GPL-1+ Programming Lang: Perl Description : More utilities and a summary for Software::License Software::LicenseMoreUtils Perl module provides more utilities for Software::License: * more short keyword to create license object * license summaries that point to /usr/share/common-licenses The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: libuv1 build failure only on Ryzen ???
On mardi 8 mai 2018 22:53:21 CEST Ben Hutchings wrote: > Make sure you have current microcode installed (either in the BIOS or > the amd64-microcode package). I've update the BIOS, amd64-microcode is the latest version. dmesg shows: $ sudo dmesg |grep microcode [0.687667] microcode: CPU0: patch_level=0x08001137 [0.687671] microcode: CPU1: patch_level=0x08001137 [0.687674] microcode: CPU2: patch_level=0x08001137 [0.687677] microcode: CPU3: patch_level=0x08001137 [0.687680] microcode: CPU4: patch_level=0x08001137 [0.687683] microcode: CPU5: patch_level=0x08001137 [0.687686] microcode: CPU6: patch_level=0x08001137 [0.687689] microcode: CPU7: patch_level=0x08001137 [0.687693] microcode: CPU8: patch_level=0x08001137 [0.687697] microcode: CPU9: patch_level=0x08001137 [0.687703] microcode: CPU10: patch_level=0x08001137 [0.687707] microcode: CPU11: patch_level=0x08001137 [0.687711] microcode: CPU12: patch_level=0x08001137 [0.687716] microcode: CPU13: patch_level=0x08001137 [0.687722] microcode: CPU14: patch_level=0x08001137 [0.687727] microcode: CPU15: patch_level=0x08001137 [0.687756] microcode: Microcode Update Driver: v2.2. I've tried: - set AMD64UCODE_INITRAMFS= early in /etc/default/amd64-microcode - update-initramfs -u - reboot This did not change the microcode version. libuv1 build still fail with this IPv6 test. Thanks for the hint. All the best -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org
libuv1 build failure only on Ryzen ???
Hi I'm packaging libuv1 and I'm facing an unusual issue. On my ryzen system the following test fails: not ok 295 - udp_dual_stack # exit code 6 # Output from process `udp_dual_stack`: # Assertion failed in test/test-udp-ipv6.c on line 181: recv_cb_called == 1 This test fail for libuv1 1.11.0 1.18.0 and 1.20.3 ( I did not go further back) On the other hand, this package builds fine on an Intel proc and an older AMD (proc bought around 2010) All these machine are Debian/sid amd64 and were updated today. My Ryzen is AMD Ryzen 7 1700X Eight-Core Processor with hyperthreading. Could someone test this build on their Ryzen system ? (I'd rather have a confirmation from other people before logging upstream this kind of bug). All the best -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org
ANNOUNCE: new cme script to update package VCS-Git field
Hello Since a lot of people are going to migrate their package repo from alioth to salsa, I've created a small script for cme to help update debian/control file for this new package repository. Once you have updated your repo to the new remote (can be on salsa or anywhere else), run cme run set-vcs-git This command will update Vcs-Browser and Vcs-Git in debian/control (from the url of the "origin" remote) and commit the change. The remote name can also be specified. For instance: cme run set-vcs-git -arg remote=debian For help, please run: cme run set-vcs-git --doc or cme run --help This new script is available from libconfig-model-dpkg-perl 2.106 (and requires cme package) All the best
Re: A proposal for improving transparency of the FTP NEW process
On Saturday, 3 March 2018 07:54:00 CET Lars Wirzenius wrote: > We have licencecheck, and if that isn't good enough, we can improve > it. That's my cue to advertise "cme update dpkg-copyright" that uses licencecheck output to provide a debian/copyright file See [1] for details (and limitations) HTH [1] https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
[VAC] French Alps
Hi I'll be on vacation next week In St Sorlain D'Arves for a week of telemark with my family. I won't have much internet access. Feel free to nmu any package that I maintain. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Debian med policy and cme (was Re: cme)
On Monday, 15 January 2018 10:26:58 CET Andreas Tille wrote: > The great tool created by pkg-perl team that I'm using happily > > cme fix dpkg-control > > to get some standard layout also for d/control. It is explicitly mentioned > in Debian Med policy[1] and I'd strongly recommend you try it. Thanks :-) > [1] https://debian-med.alioth.debian.org/docs/policy.html#debian-control BTW, I found there some issues related to cme: - there's no need to install libconfig-model-itself-perl (this module is only needed to update models for cme, e.g. to update Dpkg::Control model when a new parameter is added to control file) - you may want to install libconfig-model-tkui-perl to use cme GUI with 'cme edit dpkg') - you can generate from scratch a debian/copyright file with 'cme update dpkg- copyright' - config-edit is obsolete. You can check copyright data with 'cme check dpkg- copyright) You may also want to use 'cme check|edit|fix dpkg' so that cme works on all supported files (control, copyright, patches, source/format...) HTH -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: SPDX & cme WAS: Why do we list individual copyright holders?
On Friday, 12 January 2018 15:06:10 CET Geert Stappers wrote: > What is 'cme' cme is a program able to refresh the content of debian/copyright using information extracted from source files. For more details, see: https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Why do we list individual copyright holders?
On Friday, 12 January 2018 03:08:59 CET Ben Hutchings wrote: > I have been meaning to look at regenerating debian/copyright based on > the SPDX tags, and possibly sending corrections upstream based on the > current content. But that's all. Feel free to get back to me if: - you intend to use cme for this task - you have questions or issues with cme All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Precarious status of Shutter in Debian
Hello Debian is moving away from Gnome2::VFS [1] . This obsolete module will be removed from next release of Debian. Unfortunately, shutter, a very nice Gtk2 screenshot application, depends on Gnome::VFS, which means that shutter will be removed from Debian unless this dependency is removed from shutter [2]. I guess that the options are: * port shutter from Gnome2::VFS to GVFS or GIO * replace Gnome2::VFS with other Perl modules. Unfortunately, Debian perl team do not have the skills or bandwidth to work on this port, I hope that someone will be able to help. If you're interested in taking over maintenance of shutter, please: - coordinate with upstream shutter team [3] (yes, upstream is on launchpad) - keep debian-perl team and me posted All the best Dod, on behalf of Debian Perl team [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870418 [2] https://bugs.launchpad.net/shutter/+bug/1006290 [3] https://launchpad.net/~shutter -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Announce: cme now supports autopkgtest
Hello cme now supports the autopkgtest [1] parameters defined either in debian/control or in debian/tests/control [2]. autopkgtest parameters are checked with 'cme check dpkg' and can be modified using 'cme edit dpkg' [3] Required packages: - cme - libconfig-model-dpkg-perl 2.104 - libconfig-model-tkui-perl (for 'cme edit' command) In case of problem, you can ask for help on #debian-perl or report a bug on libconfig-model-dpkg-perl All the best [1] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html [2] https://manpages.debian.org/testing/libconfig-model-dpkg-perl/Config::Model::models::Dpkg::Tests::Control.3pm.en.html [3] https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Has Copyright summarizing outlived its usefulness?
On Thursday, 30 November 2017 11:26:31 CET Simon McVittie wrote: > For a large package, gathering the list of copyright holders from > the source into debian/copyright is clearly a lot of work. For what it's worth, the amount of work can be reduced using 'cme update dpkg- copyright' [1] (other tools exist [2]) HTH [1] https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme [2] https://wiki.debian.org/CopyrightReviewTools -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: New: "cme run paste-license script"
On Monday, 23 October 2017 13:27:48 CEST Pirate Praveen wrote: > On ഞായര് 22 ഒക്ടോബര് 2017 11:09 വൈകു, Dominique Dumont wrote: > I tried this today and it worked mostly. Thanks for doing the major part > already (the actual formatting part). You're welcome :-) > I think cme should not require --force here as earlier License: MPL-2.0 > lines have empty license text and cme should not remove those lines in > the final output (I have to add back 'License: MPL-2.0' lines removed by > cme). Agreed -> https://github.com/dod38fr/config-model/issues/15 > Note: I know MPL 2.0 is now part of common licenses but I wanted to try > cme as npm2deb did not create the correct copyright file in this case. have you tried "cme update dpkg-copyright" ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: New: "cme run paste-license script" (was: Re: pasting license text into debian/copyright)
On Sunday, 22 October 2017 21:47:12 CEST Andreas Tille wrote: > Could you please explain what you mean by "main section"? For me > > Files: * > > would qualify as "main section" but you seem to have a different > understanding of this term. ok. Let's use the same terminology as debian/copyright. I meant the section made of one or more "Stand-alone License paragraph" [1] . This one was missing from the file, the CeCILL license was not defined, hence the file was considered as invalid by cme. > > May be I should just display a > > "changed" message when summarising the changes applied to a text > > parameter. > > I think that's a more helpful output. ok. Will do. > I don't say that the GUI is bad - I just prefer a command line tool for > this job. ok. fair enough. > > $ cme modify dpkg-copyright -force 'License:CeCILL text=.file(COPYING) ! > > Files:"*" License short_name=CeCILL ! Files:"debian/*" License > > short_name=CeCILL' > > Ahhh, this helps. :-) > I just would love a way shorter command line since I somehow will never > remember this one. :-P You should be able to use paste-license script in you add first the License text as a standalone paragraph (using paste-license), *then* add the Files:* paragraphs. > Just to let me understand better: I understood this thread that way > that creating the license text in a proper form is a goal of this > specific cme option. In how far is the problem above a corner case. It's a corner case because you started from an copyright file that is considred invalid by cme because it lacks the standalone license paragraph that defines CeCILL license text). This challenges the way error tolerance is done in cme, which is not much tested yet. All the best Dod [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: New: "cme run paste-license script" (was: Re: pasting license text into debian/copyright)
On Sunday, 22 October 2017 12:10:29 CEST Andreas Tille wrote: > > without the matching section in Licenses (the one you trying to add). cme > > emits a warning when reading a copyright file with this error. This value > > is ignored because of this error. > > Sorry, I do not understand. I the string CeCILL (with capital I) is in the > main license section. Could you please be more verbose how d/copyright > needs to look like to make cme add the license text? Uh ? From a fresh git clone of beads, cat debian/copyright shows: + Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: BEADS Upstream-Contact: Olivier Langella Source: http://pappso.inra.fr/bioinfo/beads/index.php Files-Excluded: */CImg.h Files: * Copyright: 2008-2010 Michel Zivy , Olivier Langella License: CeCILL Files: debian/* Copyright: Andreas Tille License: CeCILL There's no main CeCILL section. And cme complains: $ cme check dpkg-copyright cme: using Dpkg::Copyright model loading data Configuration item 'Files:"*" License short_name' has a wrong value: license 'CeCILL' is not declared in main License section. Expected Admitedly, the error message is lackluster when main License section is empty. This will be fixed. > > > Warning: Files:"debian/*" License short_name skipping value CeCILL > > > because > > > of the following errors: license 'CeCILL' is not declared in main > > > License > > > section. Expected > > > > Likewise. > > Likewise I fail to understand. ;-) Duh ;-) > Yes please. I'd be really happy if you could push a d/copyright that is > correctly formed to let cme work. I hope that won't be necessary. See below. > I redirected simply for this mail here ... Fair enough. > > err. it never occurred to me that someone could feed cme output to patch > > > Yes, I had this clue only since the first column '+' is a feature > frequently used in patch. Just a wild guess of mine. It's just that cme uses a diff to show the delta between old and new value. It's not supposed to be used as a patch. May be I should just display a "changed" message when summarising the changes applied to a text parameter. > > cme should write debian/copyright provided no error is left. > > That's what I'd prefer. So we have a common goal :) > I admit I do not really like that GUI. I'm open to idea on how to improve the GUI while keeping it generic for the other models supported by cme (e.g ssh systemd itself ...) > $ cme modify dpkg-copyright -force 'License:CeCILL text=.file(COPYING) ! > Files:"*" License short_name=CeCILL Files:"debian/*" License > short_name=CeCILL' cme: using Dpkg::Copyright model > Warning: Files:"*" License short_name skipping value CeCILL because of the > following errors: license 'CeCILL' is not declared in main License section. [snip] > Hmmm, sorry, no change to d/copyright. Sorry, my bad. I dropped a '!' during cut'n'paste. Here's the right command tested on beads repo: $ cme modify dpkg-copyright -force 'License:CeCILL text=.file(COPYING) ! Files:"*" License short_name=CeCILL ! Files:"debian/*" License short_name=CeCILL' [ snip ] $ git diff --stat debian/copyright | 508 ++ +- 1 file changed, 507 insertions(+), 1 deletion(-) > No, sorry, I seem I totally fail to understand. Why exactly can't cme > simply copy the text that is specified as CeCILL into my copyright? It did so, but refused to write the output due to errors. > Sorry for my probably very naive questions but obviously I do not > understand the philosphy behind. No problem. cme tries to address a very complicated problem and can be confusing when dealing with corner cases. Thanks for your patience and questions. This is invaluable to improve the usability of cme. :-) All the best Dod -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: New: "cme run paste-license script" (was: Re: pasting license text into debian/copyright)
On Sunday, 22 October 2017 08:55:44 CEST Andreas Tille wrote: > $ cme run paste-license --arg license=CeCILL --arg file=COPYING > > copyright.patch Log4perl: Seems like no initialization happened. Forgot to > call init()? That's a bug in cme that will be fixed soon. > Warning: Files:"*" License short_name skipping value CeCILL > because of the following errors: license 'CeCILL' is not declared in main > License section. Expected Looks like you copyright file already has Files: * License: CeCiLL without the matching section in Licenses (the one you trying to add). cme emits a warning when reading a copyright file with this error. This value is ignored because of this error. > Warning: Files:"debian/*" License short_name skipping value CeCILL because > of the following errors: license 'CeCILL' is not declared in main License > section. Expected Likewise. > License CeCILL is not used in Files: section The new added license is seen as unused because the CeCILL values were ignored above. (*) > Configuration item 'Files:"*" License short_name' has a wrong value: > Undefined mandatory value. This is an error shown while writing the file. cme does not accept to write back a copyright file containing errors. The values are missing because, err, they were ignored above because, err, the main license was missing. I guess that error handling in cme can be improved ... > I admit I do not really understand all the output to stderr. I hope I gave some clue above ... > The output > to stdout The fact that stdout is redirect makes the errors above harder to understand. > (in my example redirected to copyright.patch) is err. it never occurred to me that someone could feed cme output to patch > So this does not really help since its neither a valid patch for > d/copyright nor can I add this content there without editing. It just > added a '+' to the original license text which is not really helpful. > May be I'm continuously missing the point but shouldn't it add rather > a ' ' instead of a '+' and replace empty lines by ' .'? cme should write debian/copyright provided no error is left. Following Perl's TIMTOWTDI tradition, I suggest to fix this problem by either: - use -force option with cme and add back the License entries after cme has saved the file - use the GUI (cme edit dpkg-copyright) and cut'n'paste CeCILL license text in the License section (see [1] for details) - tweak your file so that cme check returns no warning before running paste- license - fix everything at once with: cme modify dpkg-copyright -force 'License:CeCILL text=.file(COPYING) ! Files:"*" License short_name=CeCILL Files:"debian/*" License short_name=CeCILL' Hope this helps Dod [1] https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#maintaining-debian-copyright-file (*) I always wondered if an erroneous value found in a file should be ignored or loaded. I've chosen the first option, which leads to the cascading errors you've found. I guess that I should implement the second option at least when -force option is used. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
New: "cme run paste-license script" (was: Re: pasting license text into debian/copyright)
Hi People have complained that adding license text in debian/copyright file is tedious. To avoid this problem, libconfig-model-dpkg-perl 2.102 now ships a new cme script to copy a license text in debian/copyright. This script is run with "cme run" command [1] For instance: $ echo -e "blah\n\nblah\n\nblah" > my-lic.txt $ cme run paste-license --arg license=MyTest --arg file=my-lic.txt cme: using Dpkg::Copyright model License MyTest is not used in Files: section Changes applied to dpkg-copyright configuration: - License:MyTest text: @@ -1 +1,5 @@ - +blah + +blah + +blah $ git diff diff --git a/debian/copyright b/debian/copyright index 60bf1722..6e85dadb 100644 --- a/debian/copyright +++ b/debian/copyright @@ -22,3 +22,10 @@ License: LGPL-2.1+ License, or (at your option) any later version. On Debian GNU/Linux systems, the complete text of version 2.1 of the GNU Lesser General Public License can be found in `/usr/share/common- licenses/LGPL-2.1' + +License: MyTest + blah + . + blah + . + blah The doc specific to this script is shown with -doc option: $ cme run paste-license --doc paste license text in License paragraph paste file: cme run paste-license --arg license=Expat --arg file=MIT.txt paste STDIN: cat MIT.txt | cme run paste-license --arg license=Expat Please ignore a warning message about missing initialisation of Log4Perl. This is harmless and will be fixed soon. I hope this command will be useful to help you in your packaging activities. All the best [1] https://manpages.debian.org/testing/cme/App::Cme::Command::run.3pm.en.html -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
[ Sorry for the late reply on this point. I did miss it when I read you mail ] On Thursday, 21 September 2017 15:53:11 CEST gregor herrmann wrote: > Maybe we could even have "cme run copy-license " which > takes the text from a well-know location? Assuming "well-known" means part of Software::License module, you can already do something like: $ cme modify 'dpkg-copyright License:"Apache-2.0"' -save (the -save option is required due to a bug in Config::Model::AnyId. This will be fixed soon) I hope that Software::License has enough licenses to cover most of the needs. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#877864: ITP: libtest-log-log4perl-perl -- module to test Log::Log4perl
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-log-log4perl-perl Version : 0.32 Upstream Author : Chia-liang Kao * URL : https://metacpan.org/release/Test-Log-Log4perl * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to test Log::Log4perl Test::Log::Log4perl module can be used to test that you're logging the right thing with Log::Log4perl. It checks that your code logs what you expect and only that. This module is a fork and can be used instead of Test::Log4perl The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Thursday, 21 September 2017 16:11:52 CEST Andreas Tille wrote:
> May be if cme would have the same effect as wrap-and-sort there is at
> least no disagreement between the users of both tools any more (leaving
> those who are not happy with either of them :-P ).
Unfortunately, wrap-and-sort has its own way of sorting: special entries (i.e.
that do not begin with letters) are sorted after "normal" entries. So
dependencies like "${misc:Depends}" are sorted after package dependencies.
Usually, sort algorithms do the reverse. May be wrap-and-sort should be called
wrap-and-sort-ish :-p
I don't really mind this weird order except emulating this requires adding yet
another special case (aka wart) to the way dpkg is handled in cme.
All the best
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: ftp master uploads disappearing?
On Monday, 25 September 2017 22:28:35 CEST Norbert Preining wrote: > Umpf, interesting. dput was quite happy with the upload, but somehow > actually it didn't work out. > > Seems to be a serious bug in dput! I had a lot of trouble with dput on a slow connection: a too long upload was aborted. I now use dupload which does not have that kind of issues. HTH -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: ftp master uploads disappearing?
On Monday, 25 September 2017 16:01:18 CEST Norbert Preining wrote: > The same happened today, I uploaded calibre 3.8.0 and didn't get any > response whatsoever from the upload server. > > Are the servers back up running? I don't know the exact status. All I can say is that I uploaded libconfig- model-perl 2.111 [1] yesterday without problem. HTH [1] https://tracker.debian.org/pkg/libconfig-model-perl -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: ftp master uploads disappearing?
On Monday, 25 September 2017 08:51:49 CEST Norbert Preining wrote: > is there anything known about the status of ftp-master? There was an outage on Debian server that happened Friday and Saturday. This isssue was announced on debian-infrastruture-announce. I guess that your packages were either silently processed (check the PTS) or dropped. HTH -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Thursday, 21 September 2017 15:17:06 CEST Andreas Tille wrote: > I* think its fine but I have heard from at least one team member who > asked me not to use cme on the packages he is Uploader for since the > identation does not fit his aesthetics. Note that I wouldn't mind changing the format details of the file generated by cme to follow an agreed upon standard (or recommendation) that would apply to all tools that reformat files (like cme wrap-and-sort dh-make-perl) or create files from scratch (like some dh-make tools) . > > Would such script be useful ? > > Yes, despite some people might not like some details. Great :-) Thanks for the feedback -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Wednesday, 20 September 2017 11:31:39 CEST Dominique Dumont wrote: > I can also whip up a script based on cme that would copy the license text > from a file (or from STDIN), format it and store it in debian/copyright as > a License: paragragh I forgot to mention the main side effect: the copyright file is re-organized, and the dependency list are re-indented. This is not a problem if you already use cme, but may lead to a big diff if you don't. What do you think ? Would such script be useful ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Wednesday, 20 September 2017 11:24:50 CEST gregor herrmann wrote: > gregor, who also hates reformatting license texts or copying them from > random places I can also whip up a script based on cme that would copy the license text from a file (or from STDIN), format it and store it in debian/copyright as a License: paragragh The command could look like: cme run copy-license or wget http://url-to-license-text | cme run copy-license - short-name All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Saturday, 16 September 2017 23:13:04 CEST Andrey Rahmatullin wrote: > Changing a long free-form text file into a deb822 multiline block, when > you want to use the "machine-readable" format. You can do this with cme. Either launch cme GUI with 'cme edit dpkg-copyright'. You can paste the license content in the tree widget on the left side. See [1] for more details Or you can try the fuse interface: $ cd pkg_dir $ mkdir fuse $ cme fusefs dpkg-copyright -fuse-dir fuse/ $ ls fuse Comment Copyright Disclaimer Files Files-Excluded Format Global-License License Source Upstream-Contact Upstream-Name $ ls fuse/License/ LGPL-2.1 $ cat fuse/License/LGPL-2.1/text This program is free software; you can redistribute it and/or modify it [snip] $ mkdir fuse/License/Test $ echo "yada yada" > fuse/License/Test/text $ fusermount -u fuse $ git diff diff --git a/debian/copyright b/debian/copyright index b631507..913af34 100644 --- a/debian/copyright +++ b/debian/copyright @@ -18,3 +18,6 @@ License: LGPL-2.1 . On Debian systems, the complete text of version 2.1 of the GNU Lesser General Public License can be found in `/usr/share/common-licenses/LGPL-2.1'. + +License: Test + yada yada See the diff above. cme takes care of indenting and inserting '.' where needed. HTH [1] https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#maintaining-debian-copyright-file -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: pasting license text into debian/copyright
On Saturday, 16 September 2017 18:10:16 CEST Thorsten Alteholz wrote: > manually working on debian/copyright can be nasty from time to time. What do you mean by "nasty" ? What are the painful points ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: X facts about Debian - some fact checking and looking for ideas.
On Thursday, 24 August 2017 08:01:54 CEST shirish शिरीष wrote: > Are there any such unsung technical/non-technical or social > innovations that Debian has done that is now known/or lesser known > which Debianities should know about and be proud about. Having more > Debian fanboys should also increase both participation and > contribution to Debian. lcdproc package now feature automatic configuration merge when upgrading a package: system admin modifications and package manager modifications are merged automatically in a way that preserve both changes. See [1] for more details. All the best. [1] https://wiki.debian.org/PackageConfigUpgrade -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Future cme dpkg changes about versioned dependencies
Hi Currently, cme dpkg issues warning when a package has a dependency with a version requirement (e.g. "foo (>=1.2)") which can be satisfied by stable or old-stable. Some parameters exists that let user decide whether the "cut-off" should be done for stable or old-stable. The possibility to choose between old-stable and stable has been broken for quite a while and nobody complained. I guess that nobody uses this feature, so I'm going to remove it. (it's one of those "cool" feature that nobody actually cares about, oh well... ) Unless someone has a better idea, I plan to implement a simpler ruler: a warning will be issued only for dependencies requiring a version older than the oldest one known by madison. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#868339: ITP: libtk-fontdialog-perl -- font dialog widget for perl/Tk
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtk-fontdialog-perl Version : 0.18 Upstream Author : sla...@rezic.de * URL : https://metacpan.org/release/Tk-FontDialog * License : Artistic or GPL-1+ Programming Lang: Perl Description : font dialog widget for perl/Tk Tk::FontDialog Perl module implements a font dialog widget. The dialog is displayed by calling the Show method. The returned value is either the selected font (if the dialog was closed with the Ok button) or undef (otherwise). The exact type of the return value is a Tk::Font object which can be used as values in Tk -font options. The package will be maintained under the umbrella of the Debian Perl Group. This package is required by next version of libconfig-model-tkui-perl -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Permanent transition tracker for Perl6 ? (was: Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...))
Hello Sorry for the long delay On Tuesday, 30 May 2017 17:37:44 CEST Ian Jackson wrote: > ~/.perl6 is a particularly annoying place to put this. It defeats > the usual efforts to move this kind of thing to non-backed up storage, > or whatever. Good point. > > Unfortunately, these pre-compiled files are obsolete when a new Perl6 > > (rakudo) compiler is released. > > And does it automatically delete them, ever ? If not then surely that > is a bug. I tend to agree. As far as I understand, this feature also takes care of Perl6 developers: pre-compiled files can co-exist for several versions of Perl6. This may be good for development, but is a pain to manage in Debian > > is letting daemon write its own pre-compiled file a security risk ? > > Possibly, but the cache area should be by uid not by USER. uh, I fail to see the distinction... AFAIK, there's a 1-to-1 relation between user and uid. What did I miss ? > > - pre-compile all module are installation time (like python or emacs). The > > main issues are: all modules must be re-compiled in the correct order when > > rakudo is upgraded and how to clean up obsolete pre-compiled files. This > > requires complex post-install scripts > > Does Perl6 function correctly if these compiled files do not exist, > and cannot be written ? I think so. May be Daniel can confirm. > If so you can do the compilation > opportunistically. Python seems to take this approach. You mean at run time when a python script is run ? If so, how can a script invoked by a user can write a .pyc file owned by root ? > > The latter is probably the best solution from my point of view. > > > > But a permanent tracker has an impact in the buildd: is this solution > > acceptable ? > > It seems rather poor. ok. I'll find another solution. > Can you patch Perl6 to put the precompiled files alongside the > original source files, the way Python does it ? I don't think so. A pre-compiled file name is a hash sum made of the file content, the rakudo version and maybe some other data that I forgot. Relating a perl6 source to the precompiled file is not easy. > Then you can reuse > the techniques used by the Python people, maybe. I'm thinking about pre-compiling at installation time, keep track of the written files and remove them at de-installation time. The trick is to take care of upgrade, both module upgrade and rakudo upgrade... All the best Dominique. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Permanent transition tracker for Perl6 ? (was: Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...))
On Thursday, 18 May 2017 16:37:58 CEST Matthias Klumpp wrote: > Unfortunately though, the D language ABI isn't stable, so any future > compiler update might break the software in weird ways unless all D > software is recompiled when a new compiler is released. Perl6 has a similar issue: currently all modules (aka library) are pre- compiled ar run-time. The pre-compilation result is stored in user's home directory ( ~/.perl6 ) to speed up the start-up time when a program is launched. Unfortunately, these pre-compiled files are obsolete when a new Perl6 (rakudo) compiler is released. All in all, I have three choices: - ship only source in module and let rakudo install pre-compiled files. This may require user to clean-up ~/.perl6 from time to time. This may cause problems for daemon written in Perl6 (we're not there yet): e.g. how to clean up ? is letting daemon write its own pre-compiled file a security risk ? - pre-compile all module are installation time (like python or emacs). The main issues are: all modules must be re-compiled in the correct order when rakudo is upgraded and how to clean up obsolete pre-compiled files. This requires complex post-install scripts - like haskell, setup a permanent transition tracker so that Perl6 modules packages are re-built when needed. pre-compiled files are arch independant to the number of re-builds does not explode. The latter is probably the best solution from my point of view. But a permanent tracker has an impact in the buildd: is this solution acceptable ? All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Bug#856967: ITP: zef -- per6 package manager
On Monday, 6 March 2017 22:46:13 CET Alberto Luaces wrote: > Please > > s/per6/perl6/g Oops... Sure. Thanks for the heads-up. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#856967: ITP: zef -- per6 package manager
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: zef Version : 0.001 Upstream Author : Nick Logan nlo...@gmail.com * URL : https://github.com/ugexe/zef * License : Artistic-2 Programming Lang: Perl6 Description : per6 package manager zef is per6 package (module) manager. It can be used to donwload and install Perl6 modules in your home directory. It will be used to create debian packages for Perl6 modules. ( See https://github.com/ugexe/zef/issues/117 for the whole story ) -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Bug#854183: ITP: node-time-out
On Sunday, 5 February 2017 00:09:07 CET Shirish Togarla wrote: > * URL : https://github.com/mfunkie/time-out#readme This URLs returns a 404. I could not find time-out repo in https://github.com/mfunkie/ Please provide the correct upstream URL and author All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Release impact of introducing a new archive section?
On Thursday, 8 December 2016 18:17:23 CET gregor herrmann wrote: > Ah, I see; that makes sense. So, perl6 X::Y::Z modules will use the > > > naming perl6-x-y-z? > > Yup, that's my understanding. Yes, that's the plan. > > In any case, I don't have any objections to a new section; I just wanted > > to check about the alternative possibility of using "perl" (which in any > > case seems better than using "interpreters"). > > Ack. I just wanted to add my opinion that combining them with "perl" > doesn't seem to be a good idea. Agreed. Perl5 and Perl6 are considered by upstream as 2 different languages (even if of the same familly). That's why I think having 2 separate sections is preferable to match upstream's point of view. > And I'm not sure if we need perl6 _now_, given the amount of > packages. Yes, this can wait until jessie is released. I just hope to find the time to package Perl6 modules before Buster :-/ All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#844223: ITP: libwww-shorten-github-perl -- shorten GitHub URLs using GitHub's URL shortener
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libwww-shorten-github-perl Version : 0.1.7 Upstream Author : James Aitken * URL : https://metacpan.org/release/WWW-Shorten-GitHub * License : Artistic or GPL-1+ Programming Lang: Perl Description : shorten GitHub URLs using GitHub's URL shortener This module provides a perl interface to GitHub's URL shortening service, git.io. It allows you to shorten any GitHub URL, and also retrieve the original URL from a pre-shortened URL The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#844219: ITP: libpod-elemental-transformer-list-perl -- module to transform :list regions into =over/=back
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libpod-elemental-transformer-list-perl Version : 0.102000 Upstream Author : Ricardo SIGNES * URL : https://metacpan.org/release/Pod-Elemental-Transformer-List * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to transform :list regions into =over/=back Pod::Elemental::Transformer::List module provides a way to write lists in Pod in an easier way than usual =over/=item/back section. In your Pod document, you must add a =for declaration and then the list items prefixed with '*' The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#844215: ITP: libpod-weaver-section-support-perl -- Add a SUPPORT section to your POD
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libpod-weaver-section-support-perl Version : 1.007 Upstream Author : Apocalypse * URL : https://metacpan.org/release/Pod-Weaver-Section-Support * License : Artistic or GPL-1+ Programming Lang: Perl Description : Add a SUPPORT section to your POD Pod::Weaver::Section::Support is a Dist::Zilla plugin to that will produce a hunk of pod that lists the various ways to get support for your module. If you have Dist::Zilla::Plugin::Repository enabled in your dist.ini, be sure to check the repository_link attribute! The generated support section is added ONLY to the main module's POD, because it would be a waste of space to add it to all modules in your dist. The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#839534: ITP: libio-async-loop-mojo-perl -- Perl module to use IO::Async with Mojolicious
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libio-async-loop-mojo-perl Version : 0.05 Upstream Author : Paul Evans * URL : https://metacpan.org/release/IO-Async-Loop-Mojo * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module to use IO::Async with Mojolicious IO::Async::Loop::Mojo Perl module is "glue" module to enable usage of asynchronous modules based on IO::Async::Loop in a web server based on Mojolicious. In other words, this module is a subclass of IO::Async::Loop which uses Mojo::Reactor to perform its IO operations. The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#839009: ITP: perl6 -- Perl6 Compiler (pure meta package)
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-rakudo-de...@lists.alioth.debian.org * Package name: perl6 Version : 6c Upstream Author : none (pure meta package) * URL : http://perl6.org/ * License : Artistic-2.0 Description : Perl6 Compiler Perl 6 is a programming language, member of the Perl family. Like Perl 5, her world-famous big sister, Perl 6 intends to carry forward the high ideals of the Perl community and is currently being developed by a team of dedicated and enthusiastic volunteers. perl6 package is a meta package that aims to depend on a Perl6 compiler and Perl6 core modules. Currently this package depends only on a compiler (rakudo). Dependency on the main perl6 modules will be added once they are available on Debian. Perl6 version number represents the version of the language specification. The version of the compiler is another matter. ++ The goal of this package is to let people install a perl6 compiler with "apt install perl6". There's no need for the user to know that he actually needs rakudo package. This package will be handled by pkg-rakudo team. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Standards-Version field should be deprecated
On Friday, September 9, 2016 11:14:09 AM CEST Holger Levsen wrote: > I'd actually prefer if the text would point to > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz - alternativly > maybe it could point to both the local file and the web URL. I want the warning message to have a clikable link under konsole. Turns out that including file:///usr/share/doc/debian-policy/upgrading- checklist.txt.gz in the error message works as well (this launches ark which lists a clickable file. That's 2 clicks instead of one, but still faster than using a http URL). Al the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Standards-Version field should be deprecated
On Thursday, September 8, 2016 8:39:01 AM CEST Russ Allbery wrote: > If Lintian says that the Standards-Version field is out of date, I then > open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down > to the current value of Standards-Version, and then read backwards to the > top, checking each item against my knowledge of the package to see if > there's anything I need to update. Then I update Standards-Version in the > packaging. Good point. I'm going to change 'cme fix dpkg' warning message to mention this. The message will look like: Warning in 'control source Standards-Version' value '3.9.5': Current standards version is 3.9.8. Please read https://www.debian.org/doc/debian-policy/ upgrading-checklist.html to check what changes need to applied to your package to upgrade it from standard version 3.9.5 to 3.9.8 Ideas are welcome to improve this message after the generic part, i.e. after "Warning in 'control source Standards-Version' value '3.9.5':" All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#822800: ITP: libconfig-model-systemd-perl -- Edit and validate Systemd configuration files
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libconfig-model-systemd-perl Version : 0.002 Upstream Author : Dominique Dumont * URL : https://metacpan.org/release/Config-Model-Systemd * License : LGPL-2.1 Programming Lang: Perl Description : Edit and validate Systemd configuration files Config::Model::Systemd provides a configuration editor for the configuration file of Systemd, i.e. all files in ~/.config/systemd/user/ or all files in /etc/systemd/system/ Ok. This was quite simplified. Actually, this module provides the configuration models of Systemd configuration file that cme, Config::Model and Config::Model::TkUI use to provide a configuration editor and checker. The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
New doc: how to update debian copyright file with cme
Hello You may recall that "cme update dpkg-copyright" is a command to help maintain debian/copyright file [1] The result is often far from perfect and some "hints" must be given to cme and licensecheck to improve these results. I've written a wiki page [2] that provides "how-to" instructions to improve the results of "cme update dpkg-copyright" based on my experience with moarvm. As usual, feedback are welcome, PRs even more so :-) All the best [1] https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/ [2 https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#816840: ITP: perl6-panda -- Perl 6 module manager.
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-rakudo-de...@lists.alioth.debian.org * Package name: perl6-panda Version : 2015.12 Upstream Author : Tadeusz Sośnierz * URL : https://github.com/tadzik/panda * License : Expat Programming Lang: Perl6 Description : Perl 6 module manager. Panda is a Perl6 module installer. Use panda to download and install Perl6 modules in your home directory.
Bug#809157: ITP: rakudo-star -- Perl 6 core modules
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-rakudo-de...@lists.alioth.debian.org * Package name: rakudo-star Version : 2015.11 Upstream Author : the Rakudo Star Team * URL : http://rakudo.org/ * License : Artistic-2.0 Programming Lang: Perl6 Description : Perl 6 core modules Rakudo Perl is a compiler that implements the Perl 6 specification and runs on top of several virtual machines. Debian rakudo package runs on top of MoarVM. This package provides Perl6 core modules delivered upstream by rakudo-star releases. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Bug#808767: ITP: apt-transport-gs -- APT transport for repositories privately held on GCS
On Wednesday 23 December 2015 09:54:05 Marcin Kulisz wrote: > Honestly I'm not sure about it (I mean package name not the change). I don't > really mind to change it to gcs. > I called package *-gs to keep it in the 2 letter convention and to emphasise > that links later are starting with gs://, but if people think > it should be gcs instead I'll change it. When I read "apt-transport-gs" package name, I wondered what ghostscript (/usr/bin/gs) got to do with apt... IMHO, "-gcs" suffix is better. Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: copyright files can be generated by cme (was Re: Copyright file granularity)
On Saturday 14 November 2015 16:02:18 Neil Williams wrote: > scan-copyrights must get much better handling of non-text formats. > I tried it with a package containing a lot of png files, the example at > the top of the manpage failed because the output of scan-copyrights was > a binary file. (It's a text-like file which contains binary snippets > pretending to be copyright information.) scan-copyright uses licensecheck which has some trouble recently to handle files with binary. This issue is tracked by #803724. > So no, detailed copyright files for non-trivial packages cannot be > generated and the tools produce nothing close to the required result. > Trivial packages don't need generation. > > It's not that neither tool is perfect, neither tool seems to have been > tried with actual packages that may need the tool. I tried 'cme update dpkg' on moarvm, libtommath, pan and sdl2. Here's a result: http://anonscm.debian.org/cgit/pkg-rakudo/pkg-moarvm.git/tree/debian/copyright Unfortunately, the latest changes in licensecheck indeed broke scan- copyrights. > Even with a trivial package, scan-copyrights produces output which > if used as debian/copyright would get rejected by lintian and ftpmaster. What trivial package ? I can't fix bugs without details. > Much more work needs to be done, You're right. Especially with licensecheck. I've tried to improve licensecheck to better cope with encoding using `file` to detect mime type. But your mail show that this approach fails. Looks like `file` does not cope with with ascii file embeding binary or with several encodings. I need to rework licensecheck. I'll probably revert my changes and let user deal with inconsistent encodings in owners names. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]
Le samedi 14 novembre 2015, 15:50:28 15:50:28 Vincent Danjean a écrit : > And, after the current discussion, I have new thoughts for more complex > things: > - to be able to track external directory (/usr/...) as 'models' for > config files and to present the same kind of resolution conflict > when a file in /etc is present that override a modified default config > file in /usr There's a similar mechanism supported by cme which is named "layered configuration". This was developed for multistrap whose's configuration uses base configuration files and override files. This is also used by ssh model where ~/.ssh/config overrides the values defined in /etc/ssh/config I admit that this feature is somewhat underdocumented [1] :-/ All the best [1] http://search.cpan.org/dist/Config-Model-Itself/lib/Config/Model/models/Itself/ConfigRead.pod#default_layer_-_How_to_find_default_values_in_a_global_config_file and http://search.cpan.org/dist/Config-Model/lib/Config/Model/Value/LayeredInclude.pm -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org
copyright files can be generated by cme (was Re: Copyright file granularity)
Le vendredi 13 novembre 2015, 16:10:14 16:10:14 Wookey a écrit : > However there are numerous copyright holders and files contributed on > various dates so I spent several hours making this copyright file: > https://sources.debian.net/src/ompl/1.0.0%2Bds2-1/debian/copyright/ > with each copyright owner split out into a separate stanza. Detailed copyright files can be generated by cme. You can either run "cme update dpkg-copyright " [1] or "scan-copyrights" [2] . (you need to install cme and lib-config-model-dpkg-perl) The first one tries its best to merge current copyright with existing debian/copyright file. The second one outputs on stdout coalesced copyright information gathered from source files. Neither tools are perfect, but they produce information quite close to the required result. See also: https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/ https://ddumont.wordpress.com/2015/05/31/improving-update-of-existing-debiancopyright-file/ All the best [1] http://manpages.debian.org/cgi-bin/man.cgi?query=cme&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en [2] http://manpages.debian.org/cgi-bin/man.cgi?query=scan-copyrights&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org
Re: Config upgrade with cme (was Re: (newbie) Disruptive LIRC package update.)
On Thursday 12 November 2015 23:14:16 you wrote: > Ok. I was thinking wrong. I was under the impression that cme used > the original LCDd.conf. The wiki page is not clear enough then. I'll modify it. > Yes. I'm always a bit relunctant to not check that the merge of my > modif and upstream modif works well. It is probably because I only > used line-based merge methods (merge3, ...) that does not know > anything about the structure and the semantic of the file. cme is > probably way better here. I really need to try it. Then, feedback and suggestions will be welcome :-) All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Config upgrade with cme (was Re: (newbie) Disruptive LIRC package update.)
Hello Vincent On Wednesday 11 November 2015 17:11:13 Vincent Danjean wrote: > I looked at [2] (cme seems really powerfull to offer automatic > upgrade/merge of config files). I've two questions after reading the wiki: > > 1) I vaguely recall recommendations/requirement that a package > should/must not depends on a file in /usr/share/doc/pkg for its > work (as this directory can be removed to get some place). > The wiki says that "[LCDd.conf] is now delivered in > /usr/share/doc/lcdproc and not in /etc/". Won't /usr/share/lcdproc > be a better place ? cme does not use original LCDd.conf when upgrading user's configuration. Original LCDd.conf is placed in /usr/share/doc so that user wanting to bail out of automatic upgrade has a reference file to help him do manual edition of /etc/LCDd.conf. > 2) "user will be asked *once* by debconf whether to use automatic > configuration upgrades or not. * no further question will be asked > (no ucf style questions)." > Why not preparing (unconditionally) the new version of the configuration > file with cmd [cme] and then use ucf to install it in /etc? That way, > the user would be prompted only when he has done new changes since > the last package upgrade (and the "install maintainer version" prompt > would then install the cme built config file) Err, I don't really understand the problem you're trying to solve here... Are you suggesting to prompt user to approve that his "new changes since the last package upgrade" are propagated to the new version of the configuration file ?? All the best. > Regards, > Vincent > > > [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html > > [2] https://wiki.debian.org/PackageConfigUpgrade#Apply_configuration_upgrade_using_an_existing_model:_lcdproc_example > >[3] http://manpages.org/dh_cme_upgrade > > > > (*) it took me a while to understand the difference :o) -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: (newbie) Disruptive LIRC package update.
Le mardi 10 novembre 2015, 12:42:21 12:42:21 Alec Leamas a écrit : > Also: updating the new config files, systemd or /etc/lirc/*, in > maintainer scripts is not allowed [1] (?) Not exactly. You're confusing "configuration file" and "conffile" (*). Both can exists in /etc/. The latter is handled by dpkg. A file delivered by a package in /etc automatically becomes a conffiles. In this case, restriction mentioned in [1] apply. On the other hand, if your post-inst script creates a configuration file in /etc, this file is not handled by dpkg and is not a conffile. That's what I did for to be able to upgrade automatically lcdproc configuration [2] by cme in a postinstall script with dh_cme_upgrade [3] > Which means that what I could and should do is: > - Make a script which can handle update in most cases. > - Make manual update documentation. > - Have prominent notices in debian/NEWS about required disruptive > configuration update with links to both tool and update docs. This is allowed by [1] provided the migration scripts are run by user and not by post-install scripts. > My newbie skills cannot find anything better. You're doing very well. :-) All the best [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html [2] https://wiki.debian.org/PackageConfigUpgrade#Apply_configuration_upgrade_using_an_existing_model:_lcdproc_example [3] http://manpages.org/dh_cme_upgrade (*) it took me a while to understand the difference :o)
Re: (newbie) Disruptive LIRC package update.
On Sunday 08 November 2015 15:19:30 Alec Leamas wrote: > Some tooling to build the new configuration from the old will indeed be > required. This is actually some work - it includes a complete lircd > command line parser with ~18 options. Bit it's certainly doable. Good to know > The real reason why I think some user intervention is if not necessary > at least desirable is the semantic gap between the old and new > configuration. In particular, the current config enables the 'lirc' > service which then starts up to four different server processes. The new > config is actually up to four different systemd services which need to > be handled separately by the user. If I rephrase, with the current setup, 'service lirc start' starts 4 daemon processes. Which means the user only has to type one command to start and stop all of them. With the new setup. the user will have to deal with 4 systemd services (one per daemon) and will have to run 4 systemctl commands to start or stop lirc. Is that correct ? > Sure, it's possible to enable and start systemd services from the > existing configuration. But won't this be rather confusing for the user? As long as lirc is up and running after package upgrade, I think user won't care. I guess that user may be confused when investigating issues with lirc. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: (newbie) Disruptive LIRC package update.
On Friday 06 November 2015 18:48:29 Alec Leamas wrote: > So, an upgrade will not support hardware.conf. Which basically breaks > each and every installation. While we could (i. e., should) provide docs > and perhaps some tooling to ease the process, Well, you can provide a tools to upgrade from hardware.conf to the new configuration files (systemd based) using https://wiki.debian.org/PackageConfigUpgrade Since hardware.conf is quite small, the creation of the model shouldn't take long. Creating the code to read hardware,conf is easy, creating the code to write files using systemd syntax shouldn't take long. I could help you there if you don't know Perl. > I think some kind of > manual intervention is unavoidable. Why ? because of the format change ? or does the user have to provide more information ? (the latter would more or less break the upgrade described above) All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#802892: ITP: libtk-doubleclick-perl -- Perl/Tk function to handle double and single clicks
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtk-doubleclick-perl Version : 0.02 Upstream Author : John C. Norton * URL : https://metacpan.org/release/Tk-DoubleClick * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl/Tk function to handle double and single clicks Tk::DoubleClick provides a single function to create bindings for single and double click events. The bindings provided can be used instead of the bindings provided by TK widgets (which not always work) This package is required to provide a working double click to cme GUI The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#792488: ITP: libtext-levenshtein-damerau-perl -- Edit distance calculator with Damerau Levenshtein algorithm
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libtext-levenshtein-damerau-perl Version : 0.41 Upstream Author : Nick Logan * URL : https://metacpan.org/release/Text-Levenshtein-Damerau * License : Artistic or GPL-1+ Programming Lang: Perl Description : Edit distance calculator with Damerau Levenshtein algorithm Text::Levenshtein::Damerau module returns the true Damerau Levenshtein edit distance of strings with adjacent transpositions. Useful for fuzzy matching, DNA variation metrics, and fraud detection. Defaults to using Pure Perl Text::Levenshtein::Damerau::PP, but has an XS addon Text::Levenshtein::Damerau::XS for massive speed imrovements. Works correctly with utf8 if backend supports it. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3000763.DKPrHFeM9s@ylum
Re: Copyright format “License” field: grant of license, license text?
On Thursday 21 May 2015 12:49:23 Simon Josefsson wrote: > I believe the license grant is just as important as the license text. > The license text itself does not mean anything related to a package > unless there is a grant relating the project source code to a particular > license. This text can look the same, but for GPL it isn't: the license > grant typically refer to a particular GPL version but also includes text > such as "or (at your option) any later version". That grant text is > critical to determining the actual license of a package. Code under > GPLv2 and GPLv2+ have different properties. Currently, the license short name tries also to convey how the license is granted: * GPL or later grant are codified with something GPL-2+ * alternate choice are codified with "or". e.g. GPL or Artistic * some exception are explicitly allowed (like openssl exception) Using these agreed upon short names enable us to write tools to check license compatibility when aggregating softwares. If the license keywords are badly chosen (e.g.using GPL2 with a grant text allowing "GPL2 or later"), the copyright file will indeed be correct, but unusable by automated tools. Which would defeat the purpose of DEP-5 spec. If a license grant deviates from the most used grants, you may create a new license short name, e.g: File: Foo/* License: bsd-like License: bsd-like License under BSD and you must do whatever also. In this case, assessing the compatibility of this license with others cannot be automated. Hopefully, this will not be too common. > I prefer to clarify that 'License:' is intended to hold the license > grant text together with the license text itself (or a pointer for the > common license texts). I don't mind provided you choose the right license short name. Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1471225.ofyLUHQvDd@ylum
Re: udev vs fuse: Transport endpoint is not connected
On Monday 18 May 2015 15:10:56 Mathieu Malaterre wrote: > 1. What is the actual issue of ``udev`` vs ``fuse`` > 2. What (if possible) is needed to make a *udev* rules mount a FUSE > filesystem (I do not really care for proper umount for now). I can only guess that: - mounting a file system with fuse is based on file /dev/fuse - /dev/fuse is set up by udev - there's a race condition between the setup of /dev/fuse and ntfs-3g mounts. Note that I could be completely wrong. But I would search in that area Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3576267.qNsRDqxccl@ylum
Re: udev vs fuse: Transport endpoint is not connected
On Monday 18 May 2015 14:13:46 Mathieu Malaterre wrote: > Could a udev guru please comment on the (somewhat) famous issue > `Transport endpoint is not connected` happening when a udev rule tries > to mount fuse filesystem ? The only description I found of this issue > appear on archlinux wiki, it does not explain the actual issue: it > only tells you one should not do it. Why is this so fundamentally > wrong ? Can this be fixed ? I often had this error while debugging Config::Model::FuseUI You should be able to fix this issue by running 'fusermount -u broken-mount-point' For more details, see this stackoverflow answer [2] HTH [1] http://search.cpan.org/perldoc?Config%3A%3AModel%3A%3AFuseUI [2] http://stackoverflow.com/questions/16002539/fuse-error-transport-endpoint-is-not-connected -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6151017.JN9b7x2k6y@ylum
Bug#785245: ITP: libapp-pause-perl -- A CLI for PAUSE, the Perl module administration site
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libapp-pause-perl Version : 0.30 Upstream Author : perlancar * URL : https://metacpan.org/release/App-pause * License : Artistic or GPL-1+ Programming Lang: Perl Description : A CLI for PAUSE, the Perl module administration site App::Pause module provides a command line interface (CLI) to administer your Perl Module on PAUSE site. PAUSE stands for the Perl Author Upload Server. The pause command provides subcommands to list, upload or delete modules on PAUSE server. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/22372754.R5JYVL18lj@ylum
Re: Gitorious; check-all-the-things (was: Re: Misc Developer News (#38))
On Tuesday 10 March 2015 11:25:22 Jonas Smedegaard wrote: > license-reconcile began, I believe, as a fork of licensecheck2dep5.. I > have not yet figured out how to actually use license-reconcile - it may > be far superior on all fronts, you'll have to consult its author about > that. I've also worked on a way to improve licensecheck2dep5 (without knowing about license-reconcile). The result [1] is provided with latest version on libconfig-model-dpkg-perl (in experimental). scan-copyright is able to consolidate the copyright information in a way quite close to a reviewable copyright file. See [2] for example I'll write a blog about this tool once I finish to integrate it with cme. All the best [1] https://anonscm.debian.org/cgit/pkg-perl/packages/libconfig-model-dpkg-perl.git/tree/bin/scan-copyrights [2] https://anonscm.debian.org/cgit/pkg-perl/packages/libconfig-model-dpkg-perl.git/tree/bin/scan-copyrights#n37 -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1522091.BhqCdCRqdd@ylum
Bug#779031: ITP: libwww-shorten-simple-perl -- Factory wrapper around WWW::Shorten to avoid imports
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libwww-shorten-simple-perl Version : 0.01 Upstream Author : Tatsuhiko Miyagawa * URL : https://metacpan.org/release/WWW-Shorten-Simple * License : Artistic or GPL-1+ Programming Lang: Perl Description : Factory wrapper around WWW::Shorten to avoid imports WWW::Shorten::Simple is a wrapper (factory) around WWW::Shorten so that you can create an object representing each URL shortening service, instead of importing makeashorterlink function into your namespace. This allows you to call multiple URL shortening services in one package, for instance to call WWW::Shorten::RevCanonical to extract rev="canonical", fallback to bit.ly if username and API key are present, and then finally to TinyURL. This module is required by libdist-zilla-plugin-twitter-perl -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3062778.FZY4UcpuJh@ylum
Bug#779027: ITP: libdist-zilla-plugin-twitter-perl -- Twitter when you release with Dist::Zilla
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-twitter-perl Version : 0.026 Upstream Author : David Golden , Mike Doherty * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Twitter * License : Apache-2.0 Programming Lang: Perl Description : Twitter when you release with Dist::Zilla Dist::Zilla::Plugin::Twitter module will use Net::Twitter to send a release notice to Twitter. By default, it will include a short link to the release page of your module on http://metacpan.org. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1848563.8EdRAvoUdk@ylum
Bug#778538: ITP: libdist-zilla-plugin-emailnotify-perl -- dzil plugin to send an email on dist releas
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-emailnotify-perl Version : 0.003 Upstream Author : Sawyer X * URL : https://metacpan.org/release/Dist-Zilla-Plugin-EmailNotify * License : Artistic or GPL-1+ Programming Lang: Perl Description : dzil plugin to send an email on dist release Dist::Zilla::Plugin::EmailNotify module is a Dist::Zilla plugin that sends an email when releasing a Perl distribution. This email will contain the main release changes, authors and web pages. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5034911.65AsFyO3xk@ylum
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On Friday 06 February 2015 07:55:56 Harald Dunkel wrote: > No problem with me, but technically it would be a "jessie-forwardport". > The version I fixed is in Wheezy. There is no sign of it in Stretch. yes, there is: $ apt-cache policy network-manager-strongswan network-manager-strongswan: Installed: (none) Candidate: 1.3.0-1.1 Version table: 1.3.0-1.1 0 990 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages network-manager-strongswan is still in unstable and will be part of stretch once jessie is out and the RC bugs are fixed. Your work is definitely not a waste of time: it can be used for stretch or for jessie-backport All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1645605.B94Kc2CaVU@ylum
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On Thursday 05 February 2015 15:19:07 Harald Dunkel wrote: > I have pushed a new version 1.3.0-1.3 to mentors, providing a > workaround for #773764 as well. > > http://mentors.debian.net/package/network-manager-strongswan > > It would be nice if n-m-s could make it into Jessie. Sorry that's not possible: this package was removed from Jessie back in September. Freeze policy excludes package removed more than 1 week ago [1] All the best [1] https://lists.debian.org/54d28e3b.3070...@thykier.net -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3091155.yk0pF1Zcuy@ylum
Re: network-manager-strongswan kicked out from Jessie, even though there is a fix?
On Wednesday 04 February 2015 11:00:35 Harald Dunkel wrote: > Currently it seems it has been kicked out due to #773764, > even though the report provides an easy fix to make it work at least > for xfce4 and gnome on Jessie. According to PTS [1], this package was kicked out because of a FTBS [2]. Is this bug fixed ? All the best [1] https://tracker.debian.org/pkg/network-manager-strongswan [2] http://bugs.debian.org/759826 -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5015649.if6nvdUsq6@ylum
Re: GUI Configuration tool for main Debian window managers
On Tuesday 06 January 2015 11:52:15 Paul Wise wrote: > There is no standard mechanism to configure all software in Debian, > the first step would be to pick an existing standard and convince all > upstream developers to switch to it. Elektra project [1] has been trying this for years. > Personally I don't think this is > a feasible project, there are too many opinions on how to configure > software and too much software with more complex configuration (such > as programming languages or domain-specific languages) requirements > for there to be any chance of global agreement amongst Free Software > developers. That's why I've written cme and Config::Model [2]: this works on top of existing configuration files so existings projects are not impacted. I agree that Config::Model cannot address all configurations (like exim's). See https://github.com/dod38fr/config-model/wiki/Available-models-and-backends to see which configurations can be edited with cme. Help is welcome to support more configurations. All the best [1] https://github.com/ElektraInitiative/libelektra [2] https://github.com/dod38fr/config-model/wiki -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2435223.b0WqupyypJ@ylum
Bug#774086: ITP: libarray-intspan-perl -- Handles arrays of scalars or objects using integer ranges as index
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libarray-intspan-perl Version : 2.003 Upstream Author : Dominique Dumont (ddum...@cpan.org) * URL : https://metacpan.org/release/Array-IntSpan * License : Artistic Programming Lang: Perl Description : Handles arrays of scalars or objects using integer ranges as index Array::IntSpan brings the speed advantages of Set::IntSpan to arrays. Uses include manipulating grades, routing tables, or any other situation where you have mutually exclusive ranges of integers that map to given values. Array::IntSpan is also able to consolidate ranges by comparing the adjacent values of the range. If 2 adjacent values are identical, the 2 adjacent ranges are merged. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462457.6Bvi9chD80@ylum
Bug#771565: ITP: cme -- Check or edit configuration data with Config::Model
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: cme Version : 1.001-1 Upstream Author : Dominique Dumont * URL : https://metacpan.org/release/App-Cme * License : LGPL-2.1+ Programming Lang: Perl Description : Check or edit configuration data with Config::Model cme provides a command to check or edit configuration data with Config::Model. cme and Config::Model are quite modular: the configuration data that you can edit depend on installed packages. I.e.: - ssh client or ssh daemon config: libconfig-model-openssh-perl - approx config: libconfig-model-approx-perl - lcdproc config: libconfig-model-lcdproc-perl - popcon config: provided with libconfig-model-perl Some applications can be handled by cme: - debian package files: libconfig-model-dpkg-perl - multistrap files: provided with libconfig-model-perl You can also choose a user interface: - graphical, based on Tk: libconfig-model-tkui-perl - curses based: libconfig-model-cursesui-perl - simple shell: provided with libconfig-model-perl Last but not least, you can also take a stab at maintaining configuration model with libconfig-model-itself-perl. Feel free to get back to me if you have ideas to improve the description. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1577933.6IbGZW3sa5@ylum
