Bug#658032: RFS: libgxps/0.2.1-1 [NEW] -- library for handling and rendering XPS documents
Thanks, I'll try and expand the description this weekend. If I don't get an ispiration I'll ask from the good folks of l10n. :)
Fwd: RFS: gnonograms -- create and solve nonogram puzzles
Package: sponsorship-requestsSeverity: wishlistDear mentors,I am looking for a sponsor for my package "gnonograms". * Package name: gnonograms Version : 0.9.5-1 Upstream Author : Jeremy Wootten * URL :http://code.google.com/p/gnonograms/ * License : GPLv2+ Section : games It builds these binary packages: gnonograms - Nonogram puzzle generator and solver (core program) gnonograms-common-data - Nonogram puzzle generator and solver (common data) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gnonograms Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gnonograms/gnonograms_0.9.5-1.dsc I would be glad if someone reviewed this package for me. Regards, Jeremy Wootten GPG Key ID CB585BCD Key Fingerprint 37C0 3C2A A6D4 E45B BA7C 4328 2DF2 1882 CB58 5BCD -- Jeremy Wootten GPG Key ID CB585BCD Key Fingerprint 37C0 3C2A A6D4 E45B BA7C 4328 2DF2 1882 CB58 5BCD
Re: Mentors upload authentication
This one time, at band camp, Michael Gilbert said: > On Thu, Feb 16, 2012 at 1:17 AM, Stephen Gran wrote: > > This one time, at band camp, Michael Gilbert said: > >> Based on discussion about making mentors official, one of the key > >> requirements is contributor DMUP agreement and upload authentication. > > > > I think that there are two main problems with this idea: > > > > First, alioth, while having an infrastructure for ssh keys, doesn't know > > anything about gpg keyrings and signed packages and so on, so all of > > that work still has to be done (and this is the hard bit - distributing > > ssh public keys is easy). > > In terms of gpg public keys, the user could simply upload theirs to a > public_html alioth location, which would allow the mentors scraping > algorithms to pick that up. That process itself would be rather > simple, and could be documented in a set of wiki instructions. Why > are you thinking that's going to be hard? Most people go to a lot more trouble to make sure gpg signatures are valid and trustworthy than just downloading them from a random home directory on a machine where accounts are created on demand. I'm not sure what level of identification you're looking for here, but that seems so trivial to subvert it makes me think you'd be better off without it. I'm assuming that the backstory here is that ftpmaster want signed and identifiable uploads. I think this idea fails that test, myself. > > Second, I think requiring all contributors on alioth to sign the DMUP is > > a very bad idea. > > Alioth is Debian machine, and its listed on > http://db.debian.org/machines.cgi, which is linked from the DMUP > (http://www.debian.org/devel/dmup). I don't really understand why > alioth is so special that it deserves a free pass from the DMUP. It's > a rather non-demanding agreement anyway. > > Just to be a bit more clear, of course DDs and DMs who've already > agreed to the DMUP shouldn't have to do it again. Just to be clear, alioth is not a regular debian.org machine. It isn't admined by the same team, accounts are not handled in the same way, and privileged groups on Debian machines have no special privilege on alioth machines. Yes, the 2 machines that make up the alioth service are in the normal debian ldap, as are several other non-DSA admin'ed machines (exodar, strauss, sumotsu, etc). You don't need to sign the DMUP to use those machines either, as far as I'm aware. Their presence in LDAP is an implementation detail of the system that exports accounts to the machines. > > We host some external project like SANE that have no > > reason to want to sign agreements about their usage of machines they'll > > never log in to. > > I don't think it would be that arduous for external contributors to > sign the DMUP as it's a rather non-demanding and sane document anyway. I do believe it will be arduous to go find all the people who currently use alioth who are not DDs and ask them to sign something in order to retain their access to a service they use. > > Even if we did think it was a good idea, account > > creation is entirely automatic and on demand - we have no way of > > ensuring people have read and agreed to something beyond adding a click > > through web page at creation time or something (ick!). > > You could change your process to do something like launchpad with > their code of conduct (i.e. contributors can/should gpg sign and > upload it). That is optional on launchpad, but I think it should be > required for the DMUP. To recap, I still don't think alioth is a good fit for this. I think you're trying to shoehorn something that works with launchpad onto an entirely different system, and it doesn't fit very well for a variety of reasons. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - 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 , 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 \n"
"Language-Team: German \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 "Cancell
Re: Which git tool should I use?
On Thu, 16 Feb 2012, Paul Elliott wrote: > I am currently packaging several programs for debian. I would like to store > my > VCS stuff publicly. I have been granted access to collab-maint. > > Although previously I used svn I have been persuaded to use git. > > I have spent the last week reading git manuals, but I am a beginner. > > What tool should I use to create my git info? git-dpm? StGit? I am a heavy user of stgit, and IMHO is only good for patch-based workflows where you use git for acceleration. It is really useful for kernel development, for example. And it would be useful for topic branches where you're working on something that needs to be "kernel-style patchset should look perfect at submission time" stuff to send upstream. But it is *crap* for the branches you need to do cooperative development on. I cannot comment on git-dpm, but it is probably best if you start with straight git, with maybe a GUI tool on top (git-gui, etc). Don't do development on your master branch, though. Use a single devel branch and merge that later if you're not yet ready for multiple topic branches. That lets you repair and rebase the devel branch during development work with less fear of making a mess. Just remember that publishing to others a branch that is subject to rebase is not something you should do except in very specific circunstances. Something else you need to think about is the Debian changelog. It *really* is best if you use elaborate commit messages that can be used to construct the changelog later, either manually or automatically. Otherwise, you will get annoying conflicts during development. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218141938.gf20...@khazad-dum.debian.net
Bug#660162: RFS: tack/1.07-2
To be pedantically correct, build-dependency on autotools-dev should be
bumped to >= 20110508.1, as this version introduced the dh addon. (I
said “pedantically”, because a sufficient version is already in stable.)
Could you regenerate autotools stuff at build time? autoconf-dickey is
now in the archive, so this should be feasible. (If you feel
adventurous, you could try also with GNU autoconf.)
As far[0] as I can see, your debian/rules doesn't honour
DEB_BUILD_OPTIONS=noopt. You might want to acquire “correct”
{C,CPP,LD}FLAGS from dpkg-buildflags (enabling hardening as a
side-effect).
[0] Not very far, I didn't try to build the package yet. :P
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120218221752.ga8...@jwilk.net
compressing .debian.tar in xz format automatically
Hello List: I would like to compress my .debian.tar tarballs with xz : is there a way to set up that for debuild and pbuilder ? Thanks in advance, Jerome -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f4073d9.3050...@rezozer.net
Re: compressing .debian.tar in xz format automatically
On Sun, Feb 19, 2012 at 12:00 PM, Jerome BENOIT wrote: > I would like to compress my .debian.tar tarballs with xz : > is there a way to set up that for debuild and pbuilder ? There usually isn't any reason to do that since debian/ is usually very small anyway. If you really want to do that, the dpkg-source manual page documents a --compression=xz option. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6f8-yfs3ou7abf9_i+sy5crtucnjfdxp4ruxfmycbp...@mail.gmail.com
Bug#658204: RFS: bibtool -- tool for BibTeX database manipulation
Hello:
I have just upload a revisited version of my package that addresses
the below points when applicable.
Please find below quick answers to the points.
On 15/02/12 12:05, Benoît Knecht wrote:
Hi Jerome,
Jerome Benoit wrote:
I am looking for a sponsor for my package "bibtool".
* Package name: bibtool
Version : 2.53-1
Upstream Author : Gerd Neugebauer
* URL :
http://www.gerd-neugebauer.de/software/TeX/BibTool/index.en.html
* License : GPL-1+
Section : tex
It builds those binary packages:
bibtool- tool for BibTeX database manipulation
I took a look at your package, here are a few comments:
- debian/preinst has a comment saying it should be removed post-etch;
now seems like it'd be a good time.
It was wiped out.
- lintian gives a few warnings:
P: bibtool source: source-contains-cvs-control-dir regex-0.12/doc/CVS
P: bibtool source: source-contains-cvs-control-dir regex-0.12/CVS
P: bibtool source: unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5
Using the relevant lintian options I could observed those warnings, and I fixed
them
(thanks to the upstream maintainer).
You may want to get in touch with upstream about that. Also, ideally
regex shouldn't be embedded in the source.
I am considering to build a Debian Source to get ride of more useless material
from a Debian perspective.
- I'm not sure why you're closing bugs #291134 and #187255 in the
changelog; they're not fixed by this upload in particular, they're
just not considered bugs. I think you should close these bugs
manually and remove those two entries from the changelog.
Those bugs were closed are non bugs.
The second entry ("Features have been either"...) doesn't seem very
useful; either give a brief summary of the changed features, or
remove the entry entirely. The first entry ("New upstream version")
essentially suggests that there are new or extended features, and
users should know to check the upstream changelog already.
I am agree: I clean up this part.
(Actually, looking into it, there isn't even an entry for 2.53 in
Changes.xml.)
- In debian/copyright, you list yourself as the sole copyright holder
for the files under debian/*, but you didn't do the packaging from
scratch. What about the copyright of the previous maintainers?
fixed !
- In the bibtool(1) man page, the FILES section states "none" and the
DIAGNOSTICS section "many"; I think both sections should simply be
removed.
In the SEE ALSO section, the BibTool Manual is referred to as
bibtool.tex, but this file isn't installed on Debian; instead, it
should refer to bibtool.pdf.gz installed in /usr/share/doc/bibtool.
Also, in the .TH header in bibtool.1, something more useful than
"local" (like a date for instance) should be used.
I took the opportunity to update the bibtool.1 man page and to submit it to
the upstream maintainer who kindly integrated it modulo minor changes.
- Have you forwarded your patches for inclusion upstream?
I got in touch with the upstream maintainer a few week ago to report issues and
to submit patches:
the upstream maintainer kindly cleaned up the source of the coming version and
he integrated all the patches
except a cosmetic one. Since then, I have kept in touch with him to fix more
issues in the coming version.
I hope this helps.
It helped.
Cheers,
Thanks,
Jerome
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f407c79.5010...@rezozer.net
RFS: bibtool [ITA, upstream, second] - tool to manipulate BibTeX files
Dear mentors, dear TeX maintainers: I am looking for a sponsor for my package "bibtool". * Package name: bibtool Version : 2.54+cvs20120219-1 Upstream Author :Gerd Neugebauer * URL :http://www.gerd-neugebauer.de/software/TeX/BibTool/index.en.html * License :GPL-1+ Section : tex It builds those binary packages: bibtool- tool to manipulate BibTeX files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/bibtool Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/bibtool/bibtool_2.54+cvs20120219-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Jerome BENOIT -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f407f64.2050...@rezozer.net
Re: compressing .debian.tar in xz format automatically
Thanks for the prompt reply. On 19/02/12 05:09, Paul Wise wrote: On Sun, Feb 19, 2012 at 12:00 PM, Jerome BENOIT wrote: I would like to compress my .debian.tar tarballs with xz : is there a way to set up that for debuild and pbuilder ? There usually isn't any reason to do that since debian/ is usually very small anyway. If you really want to do that, the dpkg-source manual page documents a --compression=xz option. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f408676.70...@rezozer.net
