Bug#879697: RFS: opencsg/1.4.2-1 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "opencsg" * Package name: opencsg Version : 1.4.2-1 Upstream Author : Florian Kirsch (mail at opencsg dot org) * URL : http://opencsg.org/ * License : GPL-2 with CGAL exception, and some ZLIB & similar Section : libs The package provides the graphics library for the OpenSCAD programmatic 3D modelling tool. The library flips around the Z buffer so that CSG (constructive solid geometry) compositions can be shown without explicitly calculating their meshes. It builds those binary packages: libopencsg1 libopencsg-example - a small GLUT demo program whose practical importance in Debian is to answers the question of "is it a library or an OpenSCAD bug?" libopencsg-dev libopencsg1-dbg To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opencsg Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opencsg/opencsg_1.4.2-1.dsc For Sponsors who prefer to sponsor from git-buildpackage sources: git clone ssh://git.debian.org/git/collab-maint/opencsg.git The package was built from 266c730b5c4b192be18d78bacc176961edfbe8f5. Changes since the last upload: * New upstream version 1.4.2 (Closes: #861244) * Update copyright file * Drop old dependency names from squeeze or earlier * Modernize VCS-* and DEP URIs * Drop obsolete lintian override * Bump Standards-Version (no changes) (up to here it has been sitting around for a while), and the RC bugfix:) * Make build dependency on rename explicit (Closes: #876676) I'm aware that the Standards-Version is not the latest, but that would better be fixed with other pending updates (eg. dbgsym migration), while right now I'd like to get this through to resolve the FTBFS situation with imminent testing removal. Thanks for your consideration, chrysn -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature
Bug#718323: another hyperrogue suggestion from debian reviewers
hello damyan, On Sat, Nov 23, 2013 at 05:22:29PM +0200, Damyan Ivanov wrote: I've found only a couple of small glitches: * there is a new upstream release, featuring freely-licensed music. How about upgrading the package? i'm aware there is a new version, but haven't had time to look at it so far. * the repackaging is documented, but not automated. this is mainly because last time i looked at repackaging, automation required pulling in some perl scripts, and i was hoping that later versions would be available as tarball or git repo anyway. zeno, i think i have forgotten to mention this in my mails: if you published the source directly as your version control system, and/or produce a .tar.bz2 file with your original source code (and third party additons like the music), things would be a little easier for us, and for other distributions too. (eg, f-droid likes to pull its sources from git or hg repositories). I intent to work on all the points and eventually upload the package, if that's alright with you. (I am already member of pkg-games, cc-ed). if you find the time before i do, i'd of course appreciate contributions to the package source in the team repo and it being uploaded! happy hacking / playing chrysn -- There's always a bigger fish. -- Qui-Gon Jinn signature.asc Description: Digital signature
Bug#716852: package review
hello package reviewers, (this is a copy of the mail i originally sent to the itp instead of the rfs, as i originally overlooked the rfs. this also explains why some of the points i mention are the same as mentioned by paul earlier). i'm having a look at your libpam-ssh-agent-auth package, as i'd like to use it too. here are some things you should have a look at before the package can be uploaded: * changelog: dots inside the debian part of the version number are reserved for non-maintainer uploads (NMUs); when you're changing the package yourself, just increment the debian part. even better: use the dch utility, which will usually do the right thing. it will also prevent formating errors like missing lines as in the older versions by jamie. also, the changelog should probably be condensed into a single log entry for the first upload (ie. the version should be 0.9.5-1), and it should definitely contain a (Closes: #595817) text, so that the ITP bug gets closed when it hits the archive. * control: where did you take the build-depends from? i was curious about groff-base, had my doubts about mime-support, but libgl1-mesa-glx very definitely does not belong here. * control: if you want to have a paragraph break in the description, leave an empty line (as it is common with many plain-text systems). empty line in the context of a debian/control field means that the line contains a single indented dot (otherwise, it could be mistaken for the beginning of a new section): keyring in a forwarded ssh-agent. . This module can be used to provide authentication for anything run locally that * copyright: as you are now modifying the debian packaging, your name should be listed in the The Debian packaging is copyright section of the copyright file. please also check whether the license described there really applies to the source code -- i only checked punctually, but the license text in pam_ssh_agent_auth.c is different from debian/copyright. * dirs / libpam-ssh-agent-auth.dirs: you only need one of those; see the man page of dh_installdirs. what debian/dirs does can be read from the debhelper man page (section debhelper config files), but in short, debian/dirs is a shorthand for debian/$PACKAGE.dirs if there is only one binary package in your source package. * README: the situation with README is a little confusing -- it's inside debian/, and its heading states it is about debian, but its content is not specific to debian. actually, this file should be in the upstream tarball outside the debian/ dir (which should not be in the upstream tarball anyway). in my opinion, this is nothing you can directly change well -- just ship the README file by adding a line debian/README to debian/docs (to be picked up by dh_installdocs) for the time being, and talk to upstream about dropping his debian directory and shipping this README as a generic readme file. * README.Debian: * this should definitely not be executable. * README.Debian files are usually wrapped to around 80 characters, and uses empty lines for paragraph separation. as far as i know, there is no definite non-markup language used there, just common sense, so your heading indications with leading '=' and the '+' around commands are not technically wrong, but a more widespread formatting would be: The problem === `sudo` is a mechanism for unprivileged user to gain privileged accesses. don't bother too much with this, just be aware and have a look at other README.Debian files around. * for others who want to base their decisions on my review: i have not actually read the whole text. * rules: do you understand what all the lines there are doing? given the standards version, chances are that this file has been generated some time ago, and procedures have changed. a rules file like this has the same effect: #!/usr/bin/make -f # -*- makefile -*- # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@ override_dh_auto_configure: dh_auto_configure -- --libexecdir=/lib/security --with-mantype=man (debian/libpam-ssh-agent-auth.install is not needed any more then.) * please have a look at the warnings lintian throws when running over the package. the biggest problems are also listed on the mentors page[1], but you can always check the results of a build process using `lintian ../libpam-ssh-agent-auth_0.9.5-2.2_amd64.changes -IE --color`. you should aim for fixing them (though some of them don't need to be fixed right now; for example, spelling-error-in-manpage is better forwarded upstream and fixed with the next upstream release). best regards chrysn [1] http://mentors.debian.net/package/libpam-ssh-agent-auth -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Bug#718323: another hyperrogue suggestion from debian reviewers
On Sun, Aug 04, 2013 at 10:37:54AM +0200, Zeno Rogue wrote: I have read Adam's post in the thread. (How to subscribe and post to this thread?) you can send a mail to 718323-subscr...@bugs.debian.org; it will ask you back to confirm. if you want to participate in the discussion, just send a mail to 718...@bugs.debian.org. Indeed, killing 5000 slimes makes the Alchemist's Lab degenerate, this is a bug. Probably overharvesting one land should also make all other lands more dangerous (say, monster generation should be based on max(N, (M-10)/10), where N is gold in given land, and M is max gold among all lands). Probably I need to invent some cool way to prevent the sandworm farming too... maybe simply the worm's explosion should destroy walls around its head. adam, i think your ideas were taken well with upstream, but i regard them all as upstream decisions, including the choice to leave cocytus in there as an easter egg. (i'm under the impression though that our interest in the game is beneficial to its development :-) ) i therefore still think that the package is suitable for debian from my point of view. best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
On Fri, Aug 02, 2013 at 08:55:26AM +0200, Paul Wise wrote: fontconfig is just a font discovery system, I don't think it will help doing font fallback. I may be wrong, please test the code with a random font name that doesn't exist on your system. i've tried running without vera, and it safely falls back to DejaVuSans-Bold.ttf. In that case it would be best to generate the icon from the game at build timeby running it under xvfb-run and taking a screenshot. the game does not have a mechanism for saving or loading games, adding such a mechanism would be a big effort, and would mean adding a big blob of data to the package just as well. besides, that would still not give the original icon, but a way to recreate a similar one at best. Personally I think the #include mechanism they use to achieve their current one-gcc-command build is a bit ugly. it is; but then again, it's a game of 10 source files, and the only effect it has is an increased build time when only one cpp file was modified. best reards chrysn -- There's always a bigger fish. -- Qui-Gon Jinn signature.asc Description: Digital signature
Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
hello, sorry i missed this mail before. On Wed, Jul 31, 2013 at 12:39:13AM +0200, Adam Borowski wrote: Why do you use ttf-bitstream-vera? fonts-dejavu-core is a superset, and is installed on about every X-capable Debian system thanks to existing dependencies. i've patched the game to fontconfig on pabs' suggestion. it now falls back from bitstream vera to dejavu, and depends on either of the packages. The window's title is Untitled window. You want to call SDL_WM_SetCaption(). good idea, patched and submitted. If the player grinds long enough, he will gain access to an unfinished land that doesn't work yet. In game.cpp, you'd want to comment out the following lines: if(tkills() = 2000 gold() = 2000) tab[cnt++] = laCocytus; that's far beyond the game's high score, and cocytus may be visually and balancing-wise unfinished, but it's not like it makes the game crash. (it's inaccessible even without orbs of teleport). The desc of Dead Orb (classes.cpp) is actively misleading: it claims these orbs have no use, while they can be used to flip slime colours. No matter what is one's stance on spoilers, documentation shouldn't outright lie. i think it's ok for an in-game help (which the text in classes.cpp is; it gets displayed when pressing F1 on the orb item) in a role playing game to lie, even more to omit particular uses. (i presume its primary use is to serve as breadcrumbs to mark the way back to an orb of yendor from its key). best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
On Tue, Jul 30, 2013 at 10:21:08PM +0200, Paul Wise wrote: On Tue, Jul 30, 2013 at 8:17 PM, chrysn wrote: given that the game only displays its own static strings and usually ships the font file, i'd assume upstream will stay with sdl ttf, but i asked anyway. The main advantage of fontconfig is not having to hard-code font pathnames at build time nor in git. If you add pango/QuesoGLC then you get fallback on secondary fonts, which is mainly useful for l10n. zeno (the hyperrogue author) has shown interest in pango sdl, but won't convert on short term. (currently, there's no i18n either). as a quick fix, i've added a fontconfig patch following the example of chromium-bsu as you suggested. i don't understand everything it's doing with its patterns, but checked with the fontconfig to avoid the worst pitfalls. as i assume that fontconfig will do just that kind of fallbacks, i've changed the depends from ttf-bitstream-vera to ttf-bitstream-vera | fonts-dejavu-core. my impression was that it's a mixture of copy/pasted and one-shot import from somewhere else, possibly an ad-hoc process -- but i've asked for clarification here too. much better -- as a hidden feature, the game can be used as a hyperbolic vector editor, which spits out c++ code. this, along with the other hidden features, has been documented in the man page, with an additional note in README.source concerning preferred forms of modification. speaking of preferred forms of modification: i've obtained a more original file the icon was created from; it used to be a screenshot, but modifications were whose sources are lost (as it is common with this kind of files). i added the most original version to the debian package (with a include-binaries override), which is now shipped as .png, and the xpm is generated from it. the build process is a single gcc invocation. --parallel wouldn't do anything, would it? Right now no, point taken and added, but i'll have to check carefully anyways if the upstream build system changes much. i've already spotted another zero pointer dereference (03-worm-segfault.patch), which might be indicative of a general [...] Sounds reasonable. upstream has been very responsive and supportive; all the non-debian specific patches so far have been included in a 3.8 version that is just being released (and is already merged into the package). from my point of view, the package is in a releaseable state again (and uploaded to mentors, see urls below). please review again and upload if you don't find remaining issues. thanks chrysn urls: mentors overview: http://mentors.debian.net/package/hyperrogue dsc: dget -x http://mentors.debian.net/debian/pool/main/h/hyperrogue/hyperrogue_3.8+dfsg-1.dsc git: git://anonscm.debian.org/pkg-games/hyperrogue.git -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
Package: sponsorship-requests Severity: normal hello mentors, and hello debian games team, i've written a package for the hyperrogue game, and would like to ask for sponsorship for this new package. * Package name: hyperrogue Version : 3.7 Upstream Author : Zeno Rogue z...@attnam.com * URL : http://www.roguetemple.com/z/hyper.php * License : GPL-2+ Programming Lang: C++ Description : non-euclidean graphical rogue-like game Section : games it builds a single binary package of the same name. content-wise, it's a rogue-like game (walk around, collect treasures, fight monsters) with the unique feature of being played on a hyperbolic geometry (on regularly arranged hexagons and heptagons). its graphics options range from ascii (still on sdl graphics output, for hyperbolic geometry is hard to reflect in a terminal) to escher style interwoven tiles. the package's source git (git-buildpackage style, only the dfsg part without the windows dlls checked in) already resides in the pkg-games section on alioth. the master branch was *not* tagged debian/3.7+dfsg-1, because i'm not sure whether this is supposed to be done by me or by whoever sponsors it (wiki.d.o/Games/VCS/git seems to indicate the former, from pkg-ruby-extras i know it's the latter way). the relevant urls are: Vcs-Web: http://anonscm.debian.org/gitweb/?p=pkg-games/hyperrogue.git;a=summary Vcs-Git: git://anonscm.debian.org/pkg-games/hyperrogue.git Mentors page: https://mentors.debian.net/package/hyperrogue dget line / dsc: dget -x http://mentors.debian.net/debian/pool/main/h/hyperrogue/hyperrogue_3.7+dfsg-1.dsc this is the first version of hyperrogue to be uploaded to debian. please consider sponsoring this package. best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game
thank you for your feedback!
i'll classify my responses by solution status:
will talk with upstream
---
On Tue, Jul 30, 2013 at 04:51:28PM +0200, Paul Wise wrote:
About the fonts stuff; The best would be if the program used SDL Pango
instead or as an alternative to SDL TTF. Other font rendering systems
that automatically discover system fonts and cope with multi-script
strings by falling back on other fonts are also OK. If upstream isn't
OK with switching to SDL Pango, please send them a patch to use
fontconfig to detect where the font files are located, falling back on
runtime or compile-time configured fonts. An example of how to do this
stuff is in chromium-bsu, which uses different rendering libs but the
principles are the same. The GLC backend is an example of the SDL
Pango style and the FTGL backend is an example of the SDL TTF style.
given that the game only displays its own static strings and usually
ships the font file, i'd assume upstream will stay with sdl ttf, but i
asked anyway.
Could you ask upstream; What is the origin of the numbers in
polygons.cpp? Were they created by hand? Were they converted from some
other format and hard-coded into the file? Are they maintained in some
other format? Are they not maintained at all?
my impression was that it's a mixture of copy/pasted and one-shot import
from somewhere else, possibly an ad-hoc process -- but i've asked for
clarification here too.
i don't think it's a problem
Why is -O3 in CXXFLAGS? I would suggest sticking to the Debian default
which is set by dpkg-buildflags (-O2) and not setting CXXFLAGS in the
Makefile.
that's the default value upstream ships in the make file. as it is
packaged, i patched the make file to only -O3 if the flags are not given
from outside, so it shouldn't affect debian. (the original makefile
didn't respect any environment variables.)
Please add --parallel to the dh arguments.
the build process is a single gcc invocation. --parallel wouldn't do
anything, would it?
P: hyperrogue: no-upstream-changelog
given how rare upstream changelogs are outside of top-of-class
upstreams, i sometimes wonder why this is even a check.
ok / done
-
Please use imagemagick or similar at build time to create PNG and XPM
icons (for the Freedesktop and Debian menus) from the upstream MS
Windows icon. The XPM should be 32x32 and the PNG one should be the
maximum size available in the MS Windows icon.
done. should the .ico file remain in /usr/share/pixmaps? (i assume no.)
Please forward the remaining patches, manual page and desktop file
upstream if you haven't already.
the patches were already forwarded, man page and desktop file are now.
You may want to run wrap-and-sort -sa.
i wasn't aware of that tool, good to know, thanks and done.
The copyright years in debian/copyright are slightly wrong.
oups. (only looked at the file all the other files referred to). fixed.
CXXFLAGS missing (-fPIE)
i enabled hardening, blhc doesn't complain any more.
desktop-file-validate:
debian/hyperrogue.desktop: error: value
hyperbolic;escher;noneuclidean for locale string list key Keywords
in group Desktop Entry does not have a semicolon (';') as trailing
character
i blame the poor resolution to #277441.
just kidding, now i know of the tool, fixed and done.
bfbtester:
Lots and lots and lots of core dumps due to SIGABRT.
on my box, i got segfault crashes for single argument tests.
i'm not sure exactly why, but they are related to hyper segfaulting when
no DISPLAY variable is set (failure to check for SDL_Init return code).
now runs flawlessly; probably the x server was under too heavy load, sdl
didn't get proper windows back, and behaved as if the x server was gone.
i'm under the impression that this kind of thing might happen again --
i've already spotted another zero pointer dereference
(03-worm-segfault.patch), which might be indicative of a general
sloppyness with respect to zero pointers and exit codes, but my stance
on this is that it's sufficient quality for a game which neither has
elevated privileges nor reads untrusted data.
-
i hope to get the package in release-able shape when i receive zeno's
responses to my inqueries concerning the typesetting system and further
sources; i'll report back then.
chrysn
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
Re: Fwd: RFS: gnonograms -- create and solve nonogram puzzles
hi jeremy, i can't sponsor your package, but i've had a look at it and it looks very good to me; the package is lintian clean. two thinks i'd like to mention because they struck me as odd: * debian/copyright: this almost looks like a DEP5 debian/copyright file, but isn't yet. it is not policy to use DEP5, but if you want to, you can read more on [1]. * why does the orig.tar.gz differ from the your release tarball? (which, as a note to you with your upstream hat on, contains editor backup files (*~) in the html directory) nice game. have a translation. (see attached.) regards chrysn [1] http://dep.debian.net/deps/dep5/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom # German translations for gnonograms package. # Copyright (C) 2012 THE gnonograms'S COPYRIGHT HOLDER # This file is distributed under the same license as the gnonograms package. # Christian M. Amsüss chr...@fsfe.org, 2012. # msgid msgstr Project-Id-Version: gnonograms 0.9.5\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2012-01-27 19:38+\n PO-Revision-Date: 2012-02-18 10:38+0100\n Last-Translator: chrysn chr...@fsfe.org\n Language-Team: German translation-team...@lists.sourceforge.net\n Language: de\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n #: ../src/Gnonogram_controller.vala:474 #, c-format msgid Total time penalty now %4.0f seconds msgstr Zeistrafe gesamt: %4.0f Sekunden #: ../src/Gnonogram_controller.vala:554 msgid Congratulations - you have solved the puzzle.\n \n msgstr Gratulation – Sie haben das Puzzle gelöst.\n \n #: ../src/Gnonogram_controller.vala:558 msgid Congratulations - you have found an alternative solution.\n \n msgstr Gratulation – Sie haben eine alternative Lösung für das Puzzle gefunden.\n #. stdout.printf(New game\n); #: ../src/Gnonogram_controller.vala:596 msgid New puzzle? msgstr Neues Spiel? #: ../src/Gnonogram_controller.vala:601 ../src/Gnonogram_viewer.vala:395 msgid New puzzle msgstr Neues Spiel #: ../src/Gnonogram_controller.vala:613 msgid Restart solving the puzzle? msgstr Puzzle neu starten? #: ../src/Gnonogram_controller.vala:626 msgid Timer paused msgstr Zeitnehmung unterbrochen #: ../src/Gnonogram_controller.vala:636 msgid Name and save this puzzle msgstr Speichern unter… #: ../src/Gnonogram_controller.vala:637 ../src/Gnonogram_filereader.vala:74 msgid Gnonogram puzzles msgstr Gnonogram-Puzzles #: ../src/Gnonogram_controller.vala:650 ../src/Gnonogram_controller.vala:677 #, c-format msgid Could not write to '%s' msgstr Schreiben auf '%s' fehlgeschlagen #: ../src/Gnonogram_controller.vala:654 ../src/Gnonogram_controller.vala:681 #, c-format msgid Saved as '%s' msgstr Gespeichert als '%s' #: ../src/Gnonogram_controller.vala:663 msgid Name and save as picto puzzle msgstr Speichern unter (als Picto-Puzzle)… #: ../src/Gnonogram_controller.vala:664 ../src/Gnonogram_filereader.vala:74 msgid Picto puzzles msgstr Picto-Puzzles #: ../src/Gnonogram_controller.vala:765 msgid Failed to load puzzle msgstr Laden des Puzzles fehlgeschlagen #: ../src/Gnonogram_controller.vala:786 msgid Could not open puzzle file msgstr Konnte Puzzle-Datei nicht öffnen #: ../src/Gnonogram_controller.vala:791 msgid File format incorrect msgstr Fehler im Dateiformat #: ../src/Gnonogram_controller.vala:797 msgid Dimensions too large msgstr Puzzle zu groß #: ../src/Gnonogram_controller.vala:801 msgid Dimensions too small msgstr Puzzle zu klein #: ../src/Gnonogram_controller.vala:809 msgid Dimensions data missing msgstr Puzzlegröße fehlt #: ../src/Gnonogram_controller.vala:828 msgid Clues contradictory msgstr Hinweise sind widersprüchlich #: ../src/Gnonogram_controller.vala:833 msgid Puzzle not easily soluble by computer msgstr Puzzle kann nicht einfach durch den Computer gelöst werden #: ../src/Gnonogram_controller.vala:837 msgid Clues and solution both missing msgstr Sowohl Hinweise als auch Lösungen fehlen #: ../src/Gnonogram_controller.vala:906 msgid No errors\n \n msgstr Keine Fehler\n \n #. show incorrect cells #: ../src/Gnonogram_controller.vala:910 #, c-format msgid Incorrect cells: %d\n \n msgstr Falsche Zellen: %d\n \n #: ../src/Gnonogram_controller.vala:916 msgid No solution available\n \n msgstr Keine Lösung verfügbar\n \n #: ../src/Gnonogram_controller.vala:936 #, c-format msgid Time taken: %d hours, %d minutes, %8.3f seconds msgstr Zeit benötigt: %d Stunden, %d Minuten, %8.3f Sekunden #: ../src/Gnonogram_controller.vala:937 #, c-format msgid Including %4.0f seconds time penalty msgstr Einschlißlich %4.0f Sekunden Zeitstrafe #: ../src/Gnonogram_controller.vala:961 msgid Failed to solve or no unique solution msgstr Lösen fehlgeschlagen oder keine eindeutige Lösung #: ../src/Gnonogram_controller.vala:964 msgid Cancelled by user msgstr Vom Anwender abgebrochen #: ../src/Gnonogram_controller.vala:968 #, c-format msgid Solved
RFS: openscad
hello michael, hello mentors, after almost exactly two years of packaging, efforts by numerous people from both debian (especially -legal) and openscad, and a license change from the openscad dependency CGAL which could have saved us much trouble, i now consider my openscad package ready for inclusion in debian, and would like to ask for a final review and sponsoring. * Package name: openscad Version : 2011.12-1 Upstream Author : Clifford Wolf cliff...@clifford.at, Marius Kintel mar...@kintel.net * URL : http://opencsg.org/ * License : GPL-2+ with CGAL exception, among others Section : graphics the copyright file is still rather complex as it doesn't assume it's building against the GPL'd new version of CGAL yet. when that gets packaged, openscad can move to main. It builds those binary packages: openscad - script file based graphical CAD environment openscad-dbg - script file based graphical CAD environment (debugging symbols) openscad-testing - script file based graphical CAD environment (test suite) openscad-testing-data - script file based graphical CAD environment (test suite data) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/openscad Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/contrib/o/openscad/openscad_2011.12-1.dsc I would be glad if someone uploaded this package for me. Kind regards chrysn -- You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) signature.asc Description: Digital signature
Re: RFS: themole
On Tue, Feb 14, 2012 at 12:31:44AM +0100, Jakub Wilk wrote:
* installing by just copying python files to /usr/share/themole is
far from elegant.
Uh? This is the idiomatic way to install Python applications.
are you sure?
i've made a short survey by looking at files in
/{{usr,}/{s,}bin,usr/games}/ and looking for symlinks to /usr/share to
as python scripts (found five distinct packages doing that: gdebi, gtg,
python-xlrd, and upnp-inspector), looking for things that modify
PYTHONPATH (only paraview and non-python stuff), and looking for scripts
that do sys.path.append to use usr/share (no matches, but i've just
written two bug reports after going through occurrences of path.append,
one of them security critical)
so all in all, of those 76 packages that install python scripts to the
PATH (not counting the ^python packages), only half a dozen try to load
code directly from /usr/share. the others either have very small
executables (which reside solely in the bin folder and don't have any
auxiliary code) or use pyshared or dist-packages.
a simple --with python3 after dh $@ won't do by itself either.
Yes, it would. dh_python3 does care of bytecompiling stuff in
/usr/share/$packagename/ (even though it's not documented, sigh).
sorry, i didn't know about that feature. pulling in the python3
debhelper (and adding a build dependency on python3) would solve the
biggest issue of this package i see, then.
regards
chrysn
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
how to install python applications (was: RFS: themole)
On Tue, Feb 14, 2012 at 04:01:54PM +0200, Stefano Rivera wrote:
We encourage an application's modules to be installed privately when
they won't be of any use to other modules / applications.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
so what is the preferred way to make the programs find their modules,
then?
* put the main python file in /usr/share/my_package/ and symlink it from
/usr/bin (as it is done in themole), relying on python to resolve the
symlink and find the required modules next to the invoked file
* have a import sys; sys.path.append('/usr/share/my_program'); import
my_main; my_main.run() main wrapper in /usr/bin/
* some distutils/distribute/distutils2 magic i'm not aware of
and, unless it's the third option: is there an elegant way to integrate
that with packages that are already proper (in a python sense) packages
and have a setup.py?
thanks
chrysn
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
Re: RFS: libqsi - second attempt
hello jasem, i'm not a debian developer myself, so i can't help you with uploading, nor should you rely solely on my opinion here, but i hope these comments are helpful both to you and the developer reviewing your package for upload: * you already require debhelper 6, is there any reason you don't let it operate to its full potential by setting debian/compat to 6? * by adding a (Closes: #656203), you could make the upload automatically close your itp bug * the Support: paragraph in the COPYING file contains a line that is typically included in the copyright file (comes without warranty of fitness). i'd include that in debian/copyright too just to be on the safe side, but don't know if that's a matter of personal preference or if people more familiar with what needs to be in a copyright file have a stronger opinion on that. * the NEWS file is empty. you can tell dh_installdocs, which afaict installs it automatically, to not install it by passing -X NEWS to it, but i can't tell exactly where that goes in a cdbs based build process. * if, for any other reasons more important than this little item, you have to increase your debhelper level to 7, you can strip the debian/tmp off the debian/*.install files, making them more readable in my opinion. * there's a number of things lintian still complains about. please run lintian on your .changes file and see what it says (use -i for additional information). some things are formal issues that are easy to fix (copyright-should-refer-to-common-license-file-for-lgpl, wrong-section-according-to-package-name, extended-description-line-too-long), i don't know exactly about package-name-doesnt-match-sonames (never happened to me before), and for binary-without-manpage, i'm afraid you'll have to write at least very short explanations of what the binaries do and how to use them (as there are no man pages in the source, but debian requires them). regards chrysn -- There's always a bigger fish. -- Qui-Gon Jinn signature.asc Description: Digital signature
Re: RFS: themole
hello raúl, i'm not a debian developer myself, so i can't help you with uploading, nor should you rely solely on my opinion here, but i hope these comments are helpful both to you and the developer reviewing your package for upload: * as your upstream tarball contains the whole python-chardet module, that should be acknowledged in the copyright file; you can quote from python-chardet's. (whether or not to remove the duplicate data from the tarball is a question i've yet to get answered for my opencsg package too; preferably, upstreams would just not do that, but that's their decision). * installing by just copying python files to /usr/share/themole is far from elegant. there is no byte-compilation of files, unless themole gets invoked by root (which in term is a bad thing itself as /usr/share gets written to at run time, and it is not cleaned up on uninstall). a simple --with python3 after dh $@ won't do by itself either. you could add a rather simple setup.py file to make a bunch of automatisms kick in (or rather not ... until bug #597105 is solved, it needs some kickstarting, but then it works), but the upstream package is not really prepared for that, and the installation would behave badly in some namespaces. (import exceptions, from any python module, would import thmeole's exceptions. the main script would still be called mole.py, and debian doesn't like that.) see the attached minimal-setuppy.patch, which shows how it's done. (the setup.py is not a particularly good example of how to write one, just a very simple one). the cleaner solution would be to re-organize the source files into a more pythonic structure as described in [1] together with upstream. it's basically moving files around, making sure the import statements still go where they should (as it's python3, you can use relative imports without worrying about compatibility), and slimming down mole.py to the bare essentials (imo, it should be no more than from mole.commandline import run; if __name == __main__: run() -- more or less). .. [1]: http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html * there seems to be a -p option that is not documented in the man page. * your package is lintian clean. the only complaint on pedantic (!) level is unversioned-copyright-format-uri for your dep5 format, and afict there is no consensus yet on how this should be done exactly. regards chrysn -- Beware paths which narrow future possibilities. Such paths divert you from infinity into lethal traps. -- Leto Atreides II diff --git a/debian/control b/debian/control index 6046ead..17fe0a3 100644 --- a/debian/control +++ b/debian/control @@ -2,9 +2,10 @@ Source: themole Section: web Priority: extra Maintainer: Raúl Benencia rbenen...@linti.unlp.edu.ar -Build-Depends: debhelper (= 9.0.0) +Build-Depends: debhelper (= 9.0.0), python3 Standards-Version: 3.9.2 Homepage: http://themole.nasel.com.ar +X-Python-Version: = 3.0 Package: themole Architecture: all diff --git a/debian/rules b/debian/rules index ed933e6..65dfb5c 100755 --- a/debian/rules +++ b/debian/rules @@ -2,4 +2,12 @@ #export DH_VERBOSE=1 %: - dh $@ + dh $@ --with python3 + +# everything below this line is only required because of 597105 + +override_dh_auto_clean: + python3 setup.py clean -a + +override_dh_auto_install: + python3 setup.py install --force --root=debian/themole --no-compile -O0 --install-layout=deb diff --git a/debian/themole.install b/debian/themole.install deleted file mode 100644 index a4371ef..000 --- a/debian/themole.install +++ /dev/null @@ -1,6 +0,0 @@ -*py usr/share/themole/ -dbmsmoles/* usr/share/themole/dbmsmoles/ -htmlfilters/* usr/share/themole/htmlfilters/ -queryfilters/* usr/share/themole/queryfilters - - diff --git a/debian/themole.links b/debian/themole.links deleted file mode 100644 index dd8d35b..000 --- a/debian/themole.links +++ /dev/null @@ -1 +0,0 @@ -usr/share/themole/mole.py /usr/bin/themole diff --git a/setup.py b/setup.py new file mode 100644 index 000..fb4efc6 --- /dev/null +++ b/setup.py @@ -0,0 +1,33 @@ +#!/usr/bin/env python3 + +from distutils.core import setup + +setup( +name='themole', +version='0.2.6', +py_modules=[ +'commands', +'completion', +'connection', +'datadumper', +'dbdump', +'domanalyser', +'exceptions', +'filters', +'injectioninspector', +'output', +'themole', +'threader', +'xmlexporter', +'dbmsmoles.dbmsmole', +'dbmsmoles.mysql', +'dbmsmoles.oracle', +'dbmsmoles.postgres', +'dbmsmoles.sqlserver', +'htmlfilters.base', +'htmlfilters.genericfilters', +'queryfilters.base', +'queryfilters.genericfilters
RFS: opencsg and openscad
Dear mentors, I am looking for a sponsor for my package openscad and its dependency opencsg. * Package name: openscad Version : 2011.04-1 Upstream Author : Clifford Wolf and Marius Kintel * URL : http://openscad.org/ * License : GPL-2+ with exception for CGAL (libcgal) Section : contrib/graphics It builds these binary packages: openscad - script file based graphical CAD environment The contrib section stems from the dependency on CGAL, which is published under the QPL, making it non-free. For opencsg, the Mentors EMail Template looks like this: * Package name: opencsg Version : 1.3.0 Upstream Author : Florian Kirsch m...@opencsg.org * URL : http://opencsg.org/ * License : GPL-2+ Section : libs It builds these binary packages: libopencsg-dev - image-based CSG library using OpenGL (development files) libopencsg-example - image-based CSG library using OpenGL (example program) libopencsg1 - image-based CSG (Constructive Solid Geometry) library using OpenG libopencsg1-dbg - debugging symbols for libopencsg For opencsg, lintian reports on the -I level * `no-symbols-control-file` (I've had a look at the wiki page referenced in the description, and it says one shouldn't do the symbol control file thing withot knowing what one is doing, and I lack depth of understanding in that area), * `binary-control-field-duplicates-source` (which I prefer for clarity) and * `copyright-refers-to-symlink-license` (which stems from including the whole GLEW copyright file, as upstream ships GLEW in his tarballs, and I left them there without building from them -- if generating a clean upstream tarball is the preferred way, I can modify the package). For openscad, on the same level, it reports * `spelling-error-in-binary` and * `no-upstream-changelog` -- well, lintian is a bit pedantic here. My motivation for maintaining this package is that I am using OpenSCAD on a fairly regular basis, and am in irregular personal contact with the upstream authors at the Metalab in Vienna. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/o/openscad / http://mentors.debian.net/debian/pool/main/o/opencsg - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/o/openscad/openscad_2011.04-1.dsc - dget http://mentors.debian.net/debian/pool/contrib/o/openscad/openscad_2011.04-1.dsc / http://mentors.debian.net/debian/pool/main/o/opencsg/opencsg_1.3.1-4.dsc Further information, partially outdated, can be obtained via the packages' ITPs #583705 and #583476. I would be glad if someone uploaded this packages for me. Kind regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
RFS: pcb2gcode
Dear mentors, I am looking for a sponsor for my package pcb2gcode. * Package name: pcb2gcode Version : 1.1.0+git20110221-1 Upstream Author : Patrick Birnzain pbirnz...@users.sourceforge.net * URL : http://sourceforge.net/apps/mediawiki/pcb2gcode/ * License : GPL-3+ Section : misc It builds these binary packages: pcb2gcode - command-line tool for engraving PCBs using CNCs pcb2gcode-dbg - debugging symbols for pcb2gcode The package appears to be lintian clean and even build on Ubuntu (PPA at https://launchpad.net/~chrysn/+archive/pcb2gcode/). The upload would fix these bugs: 616626 (ITP) My motivation for maintaining this package is that I am actively using it and that I am contributing to the upstream project. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pcb2gcode - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pcb2gcode/pcb2gcode_1.1.0+git20110221-1.dsc I would be glad if someone uploaded this package for me. Kind regards chrysn signature.asc Description: Digital signature
RFS: arandr (new version)
hello rhonda, hello mentors, i've just released version 0.1.4 of the xrandr frontend ARandR (written in python), and would like to ask you to sponsor the upload of the resulting 0.1.4-1 version of the arandr package (single binary package). the new version fixes a major bug with some graphics adapters (not reported to bts) and adds a bunch of new translations. packaging-wise, the changes are minimal (entries in debian/copyright for the new translation files, updated standards w/o changes). the package is lintian clean up to --pedantic, and can be found at http://mentors.debian.net/debian/pool/main/a/arandr (dget http://mentors.debian.net/debian/pool/main/a/arandr/arandr_0.1.4-1.dsc). kind regards chrysn -- You don't use science to show that you're right, you use science to become right. -- Randall Munroe signature.asc Description: Digital signature
Re: RFS: sslh (updated package)
On Mon, Dec 13, 2010 at 11:00:02PM +0100, Guillaume Delacour wrote: The upload would fix these bugs: 598591, 600181, 603608 and piuparts uninstallation issues. I would be glad if someone uploaded this package for me, thanks in advance. i can't upload it for you, but i've had a look at it. the changes are minimal, match the description, it builds and the translation works -- everything seems to be ok. regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: RFS: sima (autoqueue MPD client, find similar artists to queue)
On Fri, Nov 12, 2010 at 10:03:46PM +0700, Paul Wise wrote:
On Fri, Nov 12, 2010 at 6:12 PM, chrysn chr...@fsfe.org wrote:
PYTHONPATH=/usr/share/sima/:$PYTHONPATH
PYTHONPATH=/usr/share/sima/${PYTHONPATH:+:$PYTHONPATH}
i stand corrected -- thanks for pointing it out, and sorry for spreading
dangerous code.
chrysn
(who is just grepping for PYTHONPATH in his home directory)
signature.asc
Description: Digital signature
Re: RFS: sima (autoqueue MPD client, find similar artists to queue)
On Fri, Nov 12, 2010 at 10:30:51AM +0100, Geoffroy Youri Berret wrote: I would be glad if someone uploaded^Wreview this package for me. you don't need to override dh_install, you can just rely on debian/sima.install if you * rename debian/sima.sh to debian/wrappers/sima (can't rename it to debian/sima because that's going to be a directory in the build process) * change the sima /usr/bin line to debian/wrappers/sima /usr/bin in debian/sima.install * and likewise for simadb_cli still concerning the wrappers: using a shell script is not what i'd do in own packages, but i'm not sure about the pros and cons so i won't recommend against it, but you might want to * exec the python script instead of calling it, so that the sh process doesn't stay until the program quits * put the $@ in quotes so the arguments are not shell-unescaped again * (optionally) avoid changing the working directory, and finally use PYTHONPATH=/usr/share/sima/:$PYTHONPATH exec /usr/share/sima/mpd_sima.py $@ regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: RFS: hotot
hello julián, On Mon, Nov 01, 2010 at 08:06:49PM -0500, Julián Moreno Patiño wrote: I would be glad if someone uploaded this package for me. while not being able to sponsor it myself, i've had a look at your packaging. here are some things that i think could be improved, in descending priority: * the copyright file fails to mention The Dojo Foundation for data/ui/js/jquery.js * the package does not build twice in a row as the clean target does not remove the .mo files (and possibly others) * instead of overriding dh_installman, you could just as well have a line debian/hotot.1 in the debian/manpages file (it wouldn't work that easily with the Changelog, as you'd have to move it eg. to debian/upstream_changelog/changelog so it can be added to debian/docs without renaming. i'd say it's a matter of taste which solution one prefers.) * package description: i'd suggest to write Lighweight Identi.ca / Twitter client based on GTK and WebKit -- GTK is usually written with three capital letters, WebKit with uppercase K, and splitting a list of items (identi.ca, twitter) with just a comma in the style of an asyndeton could be viewed as a means of style but i'd recommend against it here (rather / or and) apart from that, the package looks good to me; the lintian override looks plausible. the package installs and uninstalls without warnings, it seems to work as far as i could check it without having a twitter/identi.ca account. the global key binding thing didn't work for me, but i'd rather blame that on my exotic configuration. regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: RFS: fritzing
hello enrique, i've just built fritzing from your package (fritzing_0.4.3b-4), but ran into problems as described in [#571640] (qmake build system can't be set to use qmake-qt3 or qmake-qt4). this typically happens on systems that have qt3-dev-tools installed; in that case, debhelper uses /usr/bin/qmake as it is currently configured in alternatives, which is qmake-qt3 by default. until that bug is closed, i suggest to add qt3-dev-tools to Build-Conflicts; this seems to be the best solution until #571640 is fixed. after removing qt-dev-tools, building and installing worked, and a quick functionality check didn't show noticable shortcomings. thanks for packaging fritzing chrysn [#571640] http://bugs.debian.org/571640 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: Request for voluntary package reviews
On Sat, Oct 30, 2010 at 09:49:41PM +0200, Michael Tautschnig wrote: I have recently sponsored your packages downloadstatusbar and visolate. thanks; i've received the messages, just waited for the package to pass through NEW for confirmation. As many others are still looking for sponsors for their packages, and in a follow-up to [1], I would like to ask you to give back to the community, if you feel happy about your package having been uploaded to Debian archives. i wasn't aware that mentors is used like this -- it might be useful to have this stated on mentors.debian.net, the start page text mainly emphasizes on the different roles of developers as sponsors and non-developers as sponsees. as a result, i just subscribed to mentors. concerning the midish package: i've had a look at the midish package mentioned in [1]. it seems to be packaged in a reasonable way. the only potential issue i've spottet is that Willem van Engen, co-author of mdep_alsa.c, is mentioned in the file's copyright section, but not in debian/copyright; also, Samuel Mimram did the earlier packaging, he might deserve being mentioned in debian/copyright as well, unless 0.3.0-1 was a complete re-packaging, in which case that should be stated in the changelog. (on the minor end of the severity scale, one might suggest to upstream to keep source code, man pages and examples in appropriate sub-directories, but that's probably just a matter of style.) i couldn't test the functionality itself for lack of midi hardware, but at least that's reflected by appropriate warnings by midish. hth chrysn [1] http://lists.debian.org/debian-mentors/2010/10/msg00464.html 20101030121441.ga15...@moule.localdomain -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
RFS: visolate
Dear mentors, I am looking for a sponsor for my package visolate. * Package name: visolate Version : 2.1.6~svn8-1 Upstream Author : Marcus Wolschon * URL : https://sourceforge.net/projects/visolate/ * License : GPL Section : x11 It builds one binary package: visolate - tool for engraving PCBs using CNCs The package appears to be lintian clean except for wishlist and pedantic. I am motivated to maintain the package as I use it myself. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/visolate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/visolate/visolate_2.1.6~svn8-1.dsc I would be glad if someone reviewed the java packaging (it's my first java package) and, if appropriate, uploaded this package for me. Please keep me in CC when replying as I'm not subscribed to mentors. Kind regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
