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