mini-debconf 2017 in Toulouse, FRANCE
Hello everyone ! The Debian France Association [1] organizes a mini-debconf in Toulouse (south west France). This event will welcome everyone with an interest in the Debian project for a series of talks and workshops about Debian. This mini-debconf will take place in the same time and place of the « Capitole du Libre » [2] on november 18th and 19th 2017 at the ENSEEIHT school : 26 rue Pierre-Paul Riquet, Toulouse FRANCE. « Capitole du Libre » is one of the biggest french free software event between users, organizations and developers. It homes stands, talks, workshops, technical or not, just like FOSDEM but user-oriented (except technical rooms) We would like to have half conferences in english. So english speakers are welcome ! The conferences and workshops will be scheduled on the same schedule as the conferences of the “Capitole du libre” event. Thus, it will be easy to switch from the mini-debconf to the “Capitole du libre” and conversely of course ;) Talk proposals are open, you can register a talk by E-mail at : minidebconf[at]france[dot]debian[dot]net and on the wiki page [3]. Deadline to submit your talk: 09/30/2017 Denis Briand [1] https://france.debian.net/ [2] https://2017.capitoledulibre.org/ [3] https://wiki.debian.org/DebianEvents/fr/2017/Toulouse signature.asc Description: OpenPGP digital signature
Bug#875666: ITP: erlang-p1-eimp -- Erlang application for manipulating graphic images
Package: wnpp Severity: wishlist Owner: Philipp Huebner * Package name: erlang-p1-eimp Version : 1.0.0 Upstream Author : ProcessOne * URL : https://github.com/processone/eimp * License : Apache 2.0 Programming Lang: C, Erlang Description : Erlang application for manipulating graphic images This library is an Erlang application for manipulating graphic images using external C libraries. Currently it supports convertation between WebP, JPEG and PNG. It is used by ejabberd.
Re: s/python3-sphinx-intl/sphinx-intl
On Tue, 12 Sep 2017 17:49:25 +0100 Ghislain Vaillant wrote: > The python3- prefix is for binary packages only (alongside python- and > pypy-). > > Should you decide to use a prefix for the source package name, it should > be python-, not python3-. Since sphinx-intl is intended to be used as a > utility, not a library, I suggested you to just name the source package > sphinx-intl and the corresponding binary packages sphinx-intl / > sphinx-intl-doc. Then, source package as sphinx-intl and binary package python3-sphinx-intl is fine? -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Re: s/python3-sphinx-intl/sphinx-intl
Hi, 2017-09-13 13:18 GMT+02:00 Hideki Yamane : > Then, source package as sphinx-intl and binary package python3-sphinx-intl > is fine? > if sphinx-intl is primary application (cli tool, etc.), than binary pkg sphinx-intl is better. If it's library/module, than python3-sphinx-intl is better. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: s/python3-sphinx-intl/sphinx-intl
On 13/09/17 12:21, Ondrej Novy wrote: if sphinx-intl is primary application (cli tool, etc.), than binary pkg sphinx-intl is better. If it's library/module, than python3-sphinx-intl is better. Based on the description of the project [1], it looks like it is the former. [1] https://pypi.python.org/pypi/sphinx-intl Ghis
Re: Removal of upstart integration
Alexandre Detiste writes ("Re: Removal of upstart integration"):
> Please also sprinkle these maintainers scripts with some
>
> rmdir /etc/init --ignore-fail-on-non-empty
That should be
rmdir --ignore-fail-on-non-empty /etc/init
in case an environment variable is set requesting traditional
(non-GNU) positional option parsing.
Ian.
Re: s/python3-sphinx-intl/sphinx-intl
On Wed, Sep 13, 2017 at 12:26:34PM +0100, Ghislain Vaillant wrote: > On 13/09/17 12:21, Ondrej Novy wrote: > > if sphinx-intl is primary application (cli tool, etc.), than binary pkg > > sphinx-intl is better. If it's library/module, than python3-sphinx-intl > > is better. > > Based on the description of the project [1], it looks like it is the former. > > [1] https://pypi.python.org/pypi/sphinx-intl however sphinx itself is python*-sphinx, so maybe having those be consistent with each other is a good idea. signature.asc Description: PGP signature
Re: Steps towards a patch to document disabling a daemon upon installation
control: block 601455 by 857452 On Mon, Sep 11 2017, Ian Jackson wrote: > This should also be fixed with a new update-rc.d rune. Thank you, Ian and Felipe, for your feedback. I think the right thing is to wait on #857452. -- Sean Whitton signature.asc Description: PGP signature
Bug#875713: ITP: aether-ant-tasks -- Ant tasks to resolve Maven dependencies and install/deploy artifacts
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: aether-ant-tasks Version : 1.0.1 Upstream Author : The Eclipse Foundation * URL : https://github.com/eclipse/aether-ant * License : EPL-1.0 Programming Lang: Java Description : Ant tasks to resolve Maven dependencies and install/deploy artifacts The Aether Ant Tasks enable build scripts for Apache Ant 1.7+ to use Eclipse Aether combined to Apache Maven Aether Provider to resolve dependencies and install and deploy locally built artifacts. This package will be maintained by the Java Team. It'll replace the maven-ant-tasks package.
Bug#875722: ITP: ert-runner -- Opinionated Ert testing workflow
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Control: block 825980 by -1 * Package name: ert-runner Version : 0.7.0 Upstream Author : Jorgen Schaefer * URL : http://github.com/rejeep/ert-runner.el * License : GPL-3+ Programming Lang: Elisp Description : Opinionated Ert testing workflow Ert-runner is a tool for Emacs projects tested using Ert. It assumes a certain test structure setup and can therefore make running tests easier. I am in the process of packaging ert-runner, because elpy's tests seem to depend on it (100% failure rate at present). My hope is that configuring a directive for ert-runner will remove the necessity to patch 140-something (300-something by ert's count) tests in elpy. Be it resolved that elpy's tests truly depend on ert-runner, I plan to maintain it as part of the pkg-emacsen team. At this time I will need a sponsor for the initial upload. Regards, Nicholas
Bug#875724: ITP: elpa-commander -- Command line parsing for Emacs
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Control: block 875722 by -1 * Package name: elpa-commander Version : 0.7.0 Upstream Author : Johan Andersson * URL : https://github.com/rejeep/commander.el * License : GPL-3+ Programming Lang: Elisp Description : Command line parsing for Emacs (upstream does not yet have a long description). . Commander is an emacs addons that provides an alternative method for specifying functions to run. For example, to run a custom "foo" function with "emacs -- foo arg1 [arg2] [etc]", define the command foo with at least one required argument: . (commander (command "foo <*>" "Foo" fn)) This package is a dependency of ert-runner, which seems to be needed for elpy's self-tests. As with 875722, I plan to maintain it as part of pkg-emacsen, and I will require a sponsor for the initial upload. Regards, Nicholas
Summary of the Arm ports BoF at DC17
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the Arm ports BoF session in Montréal. Apologies for the delay in posting... Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] We spoke about the past/present/future state of Arm ports in Debian. arm64 = Most recent Arm port, first released with Jessie. We're starting to see more devices becoming available that will run Debian arm64 well. We're also starting to get real server hardware turning up. arm64 hardware often follows better standards than some of the older generations of Arm hardware, meaning that most of the machines coming (assuming kernel support!) should work well out of the box using device tree or ACPI. Please use ACPI if you can - the two are mostly equivalent in terms of what they describe, but ACPI is a better choice for the future where possible, with better standards. armhf = Much as in previous BoFs in terms of support and future! Current port, first released with Wheezy. Due to cross-distro effort, this setup (ARMv7 EABI using VFPv3D16) is the default supported 32-bit Arm architecture in all distros now. This means that there's even a fair chance of binaries built for one distro running on others! We've got a couple of multi-platform kernel variants (armmp and armmp-lpae for large-memory systems) that will support just about any new devices shipping, given updated drivers and device tree support. UEFI is now a thing for some ARMv7 platforms. Some people are looking into using UEFI by default, plus there's also the ongoing work by Alexander Graf on the UEFI shim layer in modern U-Boot. This allows for easier, consistent boot support (e.g. booting off USB automatically for installation). armel = armel is the longest-running of the three current Arm ports in Debian, starting in 2007 with Lenny. We've been debating the future of armel for some time in Debian now. It's typically still supported by most upstreams (Linux kernel, gcc, etc.), but we're more frequently finding issues with support for it in newer tools and languages and applications further up the stack. It's difficult (in some cases almost impossible) to run many larger applications like browsers on ARMv4t, as the upstream developers just don't support it any more. Based on this, I described a plan to drop armel from testing and *not* release it with Buster. This is *not* a done deal, and there's still scope for interested developers to step up and make sure that armel is supported in future. We'd been asking for that for the last couple of years and it had not happened. We'd been talking in the past few years about options for armel, including a partial armel port, dropping support for some packages that are difficult to port or not considered useful. While that might sound attractive as a possible way to go, nobody appears to have done any of the work needed to make it possible. In the background, almost in parallel there has been some discussion on the mailing list about this topic and it seems we now *do* have some developers wanting to keep armel alive. See the thread starting at [3] for more information, or if you'd like to help. I still have personal concerns about the viability of armel in the future, but I wish any other volunteers luck in keeping it alive. Whether we continue with armel or not, it's probably worthwhile for users to think about migrating to newer hardware if they care about it in the longer term. Buildds and hardware The existing build machines for armel and armhf are all still ARMv7 based, using donated Marvell Armada XP machines. They're working very well as build machines - they're quite fast and take a reasonable amount of memory. Scaleway [4] use similar hardware for Arm-based hosting. We also still have an older Freescale imx53 porter box for people on armhf who might need to debug NEON issues, as the Armada XP machines don't include it. arm64 gives us more options for sensible build machines: AMD Seattle, APM Mustang, Arm Junos. We're still looking at more and better hardware in the future, including potential offers from arm64 server hardware developers. We're wanting to move on to more and more arm64 hardware in the future for build machines, including for building armhf. Using real server hardware will help us, as the machines will then fit in a rack, with remote management options too. Unfortunately, you can't rely on these for building for armel. There are old deprecated instructions (mainly barriers and atomics) that are no longer supported in the ARMv8 hardware. There is optional kernel support to trap the exceptions here and emulate the i
Re: Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.
Hi Andrey, Thanks for the guidance, I understand that if I accept the package will go to non-free, I will improve the description, I am learning how to package and hope to do the best possible. Thank you! signature.asc Description: OpenPGP digital signature
Re: Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.
Hi Alexandre, With cpdf you can scale, crop, set pdf version, it is one of the advantages I see. For example: Convert an A4 page to A3, for example: cpdf -scale-page "2 2" in.pdf -o out.pdf Include the pages of a file to fit the A4 image: cpdf -scale-to-fit "297mm 210mm" in.pdf -o out.pdf cpdf -scale-to-fit a4portrait in.pdf -o out.pdf Change file to PDF 1.4: cpdf-set-version 4 in.pdf -o out.pdf Can I do this with pdftk? thanks, Francisco signature.asc Description: OpenPGP digital signature
