Bug#820301: ITP: pytest-benchmark -- py.test fixture for benchmarking code
Package: wnpp Severity: wishlist Owner: Danny Edel <deb...@danny-edel.de> * Package name: pytest-benchmark Version : 3.0.0 Upstream Author : Ionel Cristian Mărieș <cont...@ionelmc.ro> * URL : https://github.com/ionelmc/pytest-benchmark * License : BSD-2-Clause Programming Lang: Python Description : py.test fixture for benchmarking code This plugin provides a benchmark fixture. This fixture is a callable object that will benchmark any function passed to it. . It allows to save and compare timing data to detect speed regressions, and can output results as svg graphs. - I will coordinate with the python-modules-team (in CC) about how to maintain and upload the packaging.
Bug#792096: borg packaging
Hello everyone, I was surprised to see the reaction my comments generated and like Gianfranco, I also want to ask Marc to consider rethinking his decision. I do not think you are spoiling the fun or that insisting on oldfashioned keeping is a bad thing. I apologize that my choice of words made you feel that way - I am not a native english speaker either, so it may have sounded different than I intended. I chose github as a mirror because I have upload rights there, that's the only reason. I would also prefer to work on *.debian.org and I will do so once I have permission. I just thought hosting git repo online somewhere makes looking at it easier than sending stuff by mail, and using github seemed like the easier choice than hosting and maintaining a git browser myself. Since git clones contain the entire history, switching mirrors shouldn't be complicated once upload permission is granted. I chose the "ignore upstream tarball/use git tag" method also just because it was simpler. Had I imported the release tarball, I would have had to maintain the list of files that are auto-generated (a simple *.c won't do, for example _chunker.c is handwritten), and add rules to remove them from the build dir or change their timestamp so that they get refreshed at build-time. Not having them in the first place made that unnecessary. That's the reason why upstream git tag seemed easier to create a working example implementation of the "regenerate files" idea. The git tag is gpg-signed with the same key as the tar.gz release, so I don't really see the difference in authenticity, please elaborate why .tar.gz would be superior for validation of borgbackup. From what I understand, an end-user will trust whatever checksum the Maintainer puts into .changes and signs with maintainer key, so this is just an issue of what the maintainer trusts. Or am I getting this wrong? - Danny
Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)
On Tue, 08 Sep 2015 09:23:51 -0400 Antoine Beaupré wrote: > > How does it differ from the package that Gianfranco and Marc have been > working on? (In cc.) > > A. It doesn't necessarily "differ" in the sense that it would be a different from-scratch packaging. It is 95% their package, plus a few lines in d/rules and one patch in d/patches to accomodate for the differences between upstream git and upstream tarball. My Idea was that instead of just saying "regenerate those files" I wanted to add a stance saying "and it could work somewhat like this", in order to have a discussion on whether my Idea makes sense, and not on the basis of whether it even works. The only differences are: (1) Repository layout "branch off the main repo" I didn't use upstream tarball, but rather depended only on the git tag (which doesn't contain the generated files I spoke of earlier, but it contains the code to re-generate them) Basically I followed this: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL (2) Rebuilding .c and .rst.inc files By using the upstream git directly, we can use the upstream build system (which already calls cython and sphinx) to generate the .c sources and the .rst.inc for the html manual. Some environment-variable-setting in d/rules was necessary to call the upstream docs/Makefile, to make sure it can call "borg help COMMAND --usage-only" during the generation of the .rst.inc files. (3) Patch to remove travis and codecov badges README.rst in git contains images that say "code coverage xyz%" and "travis build [passing/failing]". I didn't think they are of relevance to a Debian user (since they reflect current git status, not the version installed) plus it may be a privacy concern to load external resources when browsing the local copy of the manual. I also think that by using upstream git directly, we get the advantage of directly being able to use git-bisect/git-cherry-pick for identifying and backporting fixes to the stable version, which may come in handy later on. Danny
Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)
On Mon, 31 Aug 2015 14:14:35 +0200 Danny Edel wrote: > I am currently working on a proof-of-concept version of d/rules doing > all of that, I will report back here once I've got a working draft. I have pushed a working packaging to github. It's not of release-quality, but it should serve as a proof-of-concept for building from git tags. git clone git://github.com/dannyedel/pkg-borgbackup.git gbp buildpackage -uc -us [-S/-b] Browse: https://github.com/dannyedel/pkg-borgbackup Things left to do/discuss: * Lintian notices that the binaries are not properly hardened. I've tried including /usr/share/dpkg/buildflags.mk, but enabling pie in the hardening options breaks the build on the cython files. I am not sure what's the right course of action here. * If we symlink borg to borgbackup (like the package name), lintian complains that /usr/bin/borgbackup has no manpage. Do we also symlink the manpage or is there a special syntax to say "load 'man borg' when someone types 'man borgbackup'"? Just to make clear, I don't think this packaging is ready for production use as-is. It's meant as a proof-of-concept of building from the minimal set of source files (i.e. the ones versioned in git), using debian packaged versions of cython and sphinx to re-generate the rest. If you also think that's a good idea, please use as much or as little as seems appropriate. Danny
Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)
Hi,
I have been investigating the differences of "upstream release tarball"
versus "upstream git tag/github tarball" and I noticed that "upstream
release" differs a bit:
(1) Release tarball ships .c files compiled from python sources with
cython (examples: borg/crypto.c, borg/chunker.c)
(2) Release tarball includes generated generates .rst.inc files for
documentation by calling
borg help (see script docs/update_usage.sh)
(3) Release tarball includes a static borg/_version.py, while git tag
includes one embedding the git revision.
I personally think we should regenerate (1) with debian's packaged
cython3 during the build instead of using the upstream ones.
Rationale for this is mainly security: If any serious bug is discovered
in cython3, and we call it during build, all we need is a
no-change-rebuild in order to benefit from the fix. [This will mainly
get relevant when borgbackup reaches "stable" and upstream has moved on]
While (2) and (3) are nowhere near as important as (1), if we recreate
those ourselves during the build process, we could simply depend on
upstream git tag releases (those are gpg-signed with the same key as the
release tarball btw).
I am generally assuming that the (git-)versioned files are the only
actual human-written sources, and everything else is generated by
automation. I would suggest Debian imports only the human-written source
code, and we run all automation following it at build-time.
I am currently working on a proof-of-concept version of d/rules doing
all of that, I will report back here once I've got a working draft.
Of course, in the end, this is just my personal opinion and not
necessarily required policy, however 4.13 ("Convenience copies of code",
although this discusses included *library* code) suggests a similar
direction. I could not find anything on "including generated files vs.
regenerating them" in general.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
- Danny
Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)
On Sat, 11 Jul 2015 12:57:54 +0200 Marc Haber mh+debian-packa...@zugschlus.de wrote: I have stitched together a quick package and pushed it to collab-maint, ssh://git.debian.org/git/collab-maint/borgbackup.git I do not intend to upload until a team of at least two active people maintaining the package has formed. Hello Marc, if I can, I'd like to help on the packaging/maintaining front. The package sounds like a really nice addition to Debian, especially the borg serve infrastructure could be exactly what I need myself : ) Disclaimer: Unlike Gianfranco and anarcat, I'm not a DD, so I don't have upload rights myself. However, if there's other parts of the maintaining , I hope that I can jump in, just let me know where I could lend a hand. - Danny
Bug#794319: ITP: dspdfviewer -- Dual-Screen PDF Viewer for LaTeX-beamer presentations
Package: wnpp Severity: wishlist Owner: Danny Edel deb...@danny-edel.de * Package name: dspdfviewer Version : 1.13 Upstream Author : Danny Edel m...@danny-edel.de * URL : http://dspdfviewer.danny-edel.de/ * License : GPL Programming Lang: C++ Description : Dual-Screen PDF Viewer for LaTeX-beamer This is a specialized PDF Viewing application custom-made for the LaTeX class beamer, specifically the show notes on second screen=right option. . To make use of this program, you will need a document created by latex-beamer, and you will need two monitors connected to your computer. They do not need to have the same resolution, not even the same aspect ratio. . This program will split your PDF page in half, and display the left half (intended for the audience) on one monitor (think: a notebook's VGA output connected to your university's projector) and it will display the right half (intended for you) on the second screen. Also, on the second screen, you get page thumbnails and status information, like the time since you started the presentation and a wall clock. Answering the questions from the template: why is this package useful/relevant? While I could create dual-width presentations with latex' beamer class, there was no viewer to render them to independent screens (workarounds included setting the screens to identical sizes and dragging a viewer window to both screens) is it a dependency for another package? No, but you could think of it as an enhancement for latex-beamer. do you use it? Yes, I do, and judging from the resonance on email, github and stackoverflow, so do other people, both using debian systems and other distributions. Since I want to make life easier for current and future users of my software running debian, I'm asking for an inclusion in the official software list. if there are other packages providing similar functionality, how does it compare? I don't know of any packages providing similar functionality, that was the reason I programmed it in the first place. how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I have been maintaining the software itself on github since winter 2012/2013, and have built deb packages to my third-party repository since then. I plan to maintain the debian package myself, trying to keep it as close to upstream as possible, but compliant to debian guidelines. I will need a sponsor since I'm new to official debian packaging. -- Danny Edel m...@danny-edel.de deb...@danny-edel.de -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55bc91da.20...@danny-edel.de
