Re: Modifications of the changelog.
Hi,
On Di, 24 Apr 2012, Ben Finney wrote:
To say it more plainly: Modifying previous changelog entries, while not
prohibited, does break an implicit user expectation. I think that
expectation is reasonable to an extent, and breaking it is costly to the
same extent.
But there are good reasons to do it at some point, like a new
upstream actually fixed some bugs, and it was realized only afterwards.
So I close the bug per email with a version header indicating the
version where it is fixed, and later I change the old changelog
entry
* new upstream release (Closes: )
and add a few more bugs there.
I consider this reasonable, but in general, I agree it is better to
refrain from too wild rewritting of changelog entries.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
DUNCRAGGON (n.)
The name of Charles Bronson's retirement cottage.
--- Douglas Adams, The Meaning of Liff
--
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/20120424054932.gi23...@gamma.logic.tuwien.ac.at
Re: Some questions related to signing
Le 24/04/12 04:25, Paul Wise a écrit : On Tue, Apr 24, 2012 at 10:13 AM, Christopher Howard wrote: * I make binary deb packages available for my projects from my Web site, but I also wanted to make the deb source files available, so that people can wrap their own binary debs for other architectures. I know that they need the *.orig.tar.gz file, the *.dsc file, and the *.debian.tar.gz file. However, what are the relevance of the *.changes files? The changes files are only used for making changes to an apt repository and most people running an apt repository aren't using anything that uses .changes to make changes to the repository. It is likely that the .changes file is irrelevant for your case. If you use reprepro to manage a repository, you can use the .changes files to include a new version of a package in your repository (but it's not necessary). Within the Debian infrastructure, the .changes is used to convey information about what a particular _upload_ changes (e.g. closing bugs, also list of source and binary packages uploaded) thus the .changes is related to an upload rather than the source package itself. Regards, Thibaut. -- 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/4f965e95.9090...@free.fr
packaging help
First off, is this the right list to ask basic questions about packaging? I'm trying to package a small daemon that provdies a ZMQ remote execution facility for R. The code is here: https://github.com/armstrtw/deathstar.core I've read the package tutorials several times, but I'm having trouble finding out how to create a new user during the install (I don't want the daemon to run as root). Can someone point me in the right direction? Thanks, Whit -- 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/CAMi=pg4n7UXxm+2Tq8P+8q9dYQ2c=gekv8-ljkacv2_3sem...@mail.gmail.com
Re: RFS: open-axiom/1.4.1+svn~2626-1
Игорь Пашев pashev.i...@gmail.com writes: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package open-axiom I will have a look at this. d -- 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/874ns9xqmg.fsf@zancas.localnet
Re: packaging help
I've read the package tutorials several times, but I'm having trouble finding out how to create a new user during the install (I don't want the daemon to run as root). Can someone point me in the right direction? Two suggestions: a) think about what type of user you want: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2 b) look inside an existing package (e.g. reSIProcate, see debian/control and debian/repro.postinst) -- 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/4f969fb9.7080...@pocock.com.au
Bug#670254: RFS: lcmaps/1.5.5-1 [ITP] -- I'm looking for a sponsor.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package lcmaps * Package name: lcmaps Version : 1.5.5-1 Upstream Author : Nikhef Grid Security Middleware Team grid-mw-secur...@nikhef.nl * URL : https://wiki.nikhef.nl/grid/Site_Access_Control * License : Apache 2 Section : libs It builds those binary packages: lcmaps-basic-interface - LCMAPS header files for basic interfaces lcmaps-globus-interface - LCMAPS header files for Globus interfaces lcmaps-openssl-interface - LCMAPS header files for OpenSSL interfaces liblcmaps-dev - LCMAPS development libraries liblcmaps-without-gsi-dev - LCMAPS development libraries (Without GSI) liblcmaps-without-gsi0 - Grid mapping service without GSI liblcmaps0 - Grid (X.509) and VOMS credentials to local account mapping servic To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lcmaps Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lcmaps/lcmaps_1.5.5-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: New upstream release. Fixes out-of-source build failure with --disable-gsi-mode. It now builds both with and without GSI mode libraries in one package. Regards, Dennis van Dok -- 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/4f96a256.7070...@nikhef.nl
Re: packaging help
Thanks, Daniel. I would be looking for 6-64999, assuming my package eventually made it into debian, I suppose it would need to have a 'globally allocated' uid. The idea is simply not to give users executing an R script on the machine root access. Regarding, reSIProcate, it's cdbs based? Would the postinst script be the same format if I use dh? Based on Lucas Nussbaum's tutorial (http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf) I thought that dh would be the way to go for new packages. -Whit On Tue, Apr 24, 2012 at 8:42 AM, Daniel Pocock dan...@pocock.com.au wrote: I've read the package tutorials several times, but I'm having trouble finding out how to create a new user during the install (I don't want the daemon to run as root). Can someone point me in the right direction? Two suggestions: a) think about what type of user you want: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2 b) look inside an existing package (e.g. reSIProcate, see debian/control and debian/repro.postinst) -- 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/4f969fb9.7080...@pocock.com.au -- 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/CAMi=pg4rj5t4zulc_e0fpcfzoqkwt7xlicrqvbqfxfji_+v...@mail.gmail.com
Re: packaging help
Whit Armstrong armstrong.w...@gmail.com writes: Thanks, Daniel. I would be looking for 6-64999, assuming my package eventually made it into debian, I suppose it would need to have a 'globally allocated' uid. The idea is simply not to give users executing an R script on the machine root access. Why do you think you'd need a statically allocated id? Why wouldn't a dynamic one work? -- |8] -- 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/87sjftuunw.fsf@algernon.balabit
Re: packaging help
On 04/24/2012 03:16 PM, Whit Armstrong wrote: I would be looking for 6-64999, assuming my package eventually made it into debian, I suppose it would need to have a 'globally allocated' uid. The idea is simply not to give users executing an R script on the machine root access. You shouldn't need a statically allocated user id for this; just creating a (system) user with adduser should be fine. (The 100-999 range in policy 9.2.2.) Regarding, reSIProcate, it's cdbs based? Would the postinst script be the same format if I use dh? Based on Lucas Nussbaum's tutorial (http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf) I thought that dh would be the way to go for new packages. Maintainer scripts shouldn't differ (they are more or less just copied into the binary packages[1]). dh should be the most popular for new packages, but in the end it's a matter of preferences. I believe it might also be easier to find a sponsor for packages using dh as more people are familiar with it than with cdbs. Regards, Ansgar [1] With a few modifications: debhelper (and cdbs as it uses debhelper) might add some lines to them by replacing a special marker with shell code (#DEBHELPER#). -- 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/4f96ad1d.2050...@43-1.org
Re: packaging help
On Tue, 24 Apr 2012 15:39:41 +0200, Ansgar Burchardt ans...@43-1.org wrote: On 04/24/2012 03:16 PM, Whit Armstrong wrote: I would be looking for 6-64999, assuming my package eventually made it into debian, I suppose it would need to have a 'globally allocated' uid. The idea is simply not to give users executing an R script on the machine root access. You shouldn't need a statically allocated user id for this; just creating a (system) user with adduser should be fine. (The 100-999 range in policy 9.2.2.) Regarding, reSIProcate, it's cdbs based? Would the postinst script be the same format if I use dh? Based on Lucas Nussbaum's tutorial (http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf) I thought that dh would be the way to go for new packages. Maintainer scripts shouldn't differ (they are more or less just copied into the binary packages[1]). dh should be the most popular for new packages, but in the end it's a matter of preferences. I believe it might also be easier to find a sponsor for packages using dh as more people are familiar with it than with cdbs. Regards, Ansgar [1] With a few modifications: debhelper (and cdbs as it uses debhelper) might add some lines to them by replacing a special marker with shell code (#DEBHELPER#). Agreed, and just to add few more bits to the above: As a good reference of adding and removing system users have a look at the vsftpd package, that is, its portinst and postrm scripts. However, the project's general agreement is that system users, once added, should not be removed [1] by packaging means, so you will only need to worry about the addition part. [1[ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833 -- 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/7c5c04e5e99e1d8aef38840f2d1bb...@spnet.net
Re: packaging help
On Tue, Apr 24, 2012 at 8:16 AM, Whit Armstrong
armstrong.w...@gmail.com wrote:
Thanks, Daniel.
I would be looking for 6-64999, assuming my package eventually
made it into debian, I suppose it would need to have a 'globally
allocated' uid. The idea is simply not to give users executing an R
script on the machine root access.
Regarding, reSIProcate, it's cdbs based? Would the postinst script be
the same format if I use dh? Based on Lucas Nussbaum's tutorial
(http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf)
I thought that dh would be the way to go for new packages.
I've used the postinst script from the puppet package for creating a
user. Here is my version of it:
---{start}---
#!/bin/sh
set -e
if [ $1 = configure ]; then
# Create the mailregx user
if ! getent passwd mailregx /dev/null; then
adduser --quiet --system --group --home /var/run/milter-regex \
--no-create-home \
--gecos milter-regex daemon user \
mailregx
fi
# Create the mailregx group, if it is missing, and set the
# primary group of the mailregx user to this group.
if ! getent group mailregx /dev/null; then
addgroup --quiet --system mailregx
usermod -g mailregx mailregx
fi
fi
#DEBHELPER#
---{end}---
The #DEBHELPER# chunk is a callback or an include. It allows dh to
insert code into the script.
After my package is built, the postinst looks like:
---{start}---
#!/bin/sh
set -e
if [ $1 = configure ]; then
# Create the mailregx user
if ! getent passwd mailregx /dev/null; then
adduser --quiet --system --group --home /var/run/milter-regex \
--no-create-home \
--gecos milter-regex daemon user \
mailregx
fi
# Create the mailregx group, if it is missing, and set the
# primary group of the mailregx user to this group.
if ! getent group mailregx /dev/null; then
addgroup --quiet --system mailregx
usermod -g mailregx mailregx
fi
fi
# Automatically added by dh_installinit
if [ -x /etc/init.d/milter-regex ]; then
update-rc.d milter-regex defaults /dev/null
invoke-rc.d milter-regex start || exit $?
fi
# End automatically added section
---{end}---
You can see the things that dh can put into the various post/pre
scripts in /usr/share/debhelper/autoscripts.
HTH,
-mz
--
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/caolfk3u_atyqp7wztfw3yjv28bx-q4udzwfjk1mo-9htj5o...@mail.gmail.com
Re: packaging help
Matt, Ansgar, and Gergely,
Thanks for the tips.
Can you also help with some advice on the init.d script?
The init.d script for deathstar launches a daemon which listens for
jobs, and one worker per core.
Can I use the same pid file for all of those processes?
-Whit
On Tue, Apr 24, 2012 at 9:46 AM, Matt Zagrabelny mzagr...@d.umn.edu wrote:
On Tue, Apr 24, 2012 at 8:16 AM, Whit Armstrong
armstrong.w...@gmail.com wrote:
Thanks, Daniel.
I would be looking for 6-64999, assuming my package eventually
made it into debian, I suppose it would need to have a 'globally
allocated' uid. The idea is simply not to give users executing an R
script on the machine root access.
Regarding, reSIProcate, it's cdbs based? Would the postinst script be
the same format if I use dh? Based on Lucas Nussbaum's tutorial
(http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf)
I thought that dh would be the way to go for new packages.
I've used the postinst script from the puppet package for creating a
user. Here is my version of it:
---{start}---
#!/bin/sh
set -e
if [ $1 = configure ]; then
# Create the mailregx user
if ! getent passwd mailregx /dev/null; then
adduser --quiet --system --group --home /var/run/milter-regex \
--no-create-home \
--gecos milter-regex daemon user \
mailregx
fi
# Create the mailregx group, if it is missing, and set the
# primary group of the mailregx user to this group.
if ! getent group mailregx /dev/null; then
addgroup --quiet --system mailregx
usermod -g mailregx mailregx
fi
fi
#DEBHELPER#
---{end}---
The #DEBHELPER# chunk is a callback or an include. It allows dh to
insert code into the script.
After my package is built, the postinst looks like:
---{start}---
#!/bin/sh
set -e
if [ $1 = configure ]; then
# Create the mailregx user
if ! getent passwd mailregx /dev/null; then
adduser --quiet --system --group --home /var/run/milter-regex \
--no-create-home \
--gecos milter-regex daemon user \
mailregx
fi
# Create the mailregx group, if it is missing, and set the
# primary group of the mailregx user to this group.
if ! getent group mailregx /dev/null; then
addgroup --quiet --system mailregx
usermod -g mailregx mailregx
fi
fi
# Automatically added by dh_installinit
if [ -x /etc/init.d/milter-regex ]; then
update-rc.d milter-regex defaults /dev/null
invoke-rc.d milter-regex start || exit $?
fi
# End automatically added section
---{end}---
You can see the things that dh can put into the various post/pre
scripts in /usr/share/debhelper/autoscripts.
HTH,
-mz
--
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/CAMi=pg5meoix4rasoyvjpu9g0owht31q1np+tg4ey41tib9...@mail.gmail.com
Re: packaging help
On Tue, Apr 24, 2012 at 9:20 AM, Whit Armstrong armstrong.w...@gmail.com wrote: Matt, Ansgar, and Gergely, Thanks for the tips. Can you also help with some advice on the init.d script? Perhaps. The init.d script for deathstar launches a daemon which listens for jobs, and one worker per core. This sounds a little like an apache that forks worker processes. Perhaps check apache's init script for ideas. Can I use the same pid file for all of those processes? Most Debian init scripts use start-stop-daemon (s-s-d) for controlling the daemon. How s-s-d interacts with the daemon depends greatly on how the daemon is written. Start with /etc/init.d/skeleton and tweak as needed. -mz -- 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/caolfk3xczkn7mypjjxc815rvq1-xmr6m1qae-pdgebhp2t_...@mail.gmail.com
Re: packaging help
Whit Armstrong armstrong.w...@gmail.com writes: Matt, Ansgar, and Gergely, Thanks for the tips. Can you also help with some advice on the init.d script? The init.d script for deathstar launches a daemon which listens for jobs, and one worker per core. Can I use the same pid file for all of those processes? I assume it has a main process, which when stopped, would result in the workers being killed too. If that is so, I do not think you need to store the pids of the workers anywhere. -- |8] -- 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/87k415ur40.fsf@algernon.balabit
Re: packaging help
I assume it has a main process, which when stopped, would result in the workers being killed too. If that is so, I do not think you need to store the pids of the workers anywhere. Perhaps I'm confusing terminology here. The main deamon does not spawn the workers. It and the workers are started by the init.d script. The workers and the main daemon should be started and stopped together. In that case, it seems like I should store the pid's... so I can kill them upon stop. Have I understood correctly? -Whit -- 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/CAMi=pg6WaUT1Fi6YVk2gontQSPp2-5qOTHpwcbaL=b6yebp...@mail.gmail.com
Re: packaging help
Whit Armstrong armstrong.w...@gmail.com writes: I assume it has a main process, which when stopped, would result in the workers being killed too. If that is so, I do not think you need to store the pids of the workers anywhere. Perhaps I'm confusing terminology here. The main deamon does not spawn the workers. It and the workers are started by the init.d script. The workers and the main daemon should be started and stopped together. In that case, it seems like I should store the pid's... so I can kill them upon stop. Have I understood correctly? Correct. As a suggestion, I'd store the pidfiles under /run/your-program-name/, under names like worker:0.pid, and main.pid or somesuch. start-stop-daemon can be of great help here, but unfortunately, I don't recall any package off the top of my head that would serve as a good example, even though I know I've met one or two.. :( -- |8] -- 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/87aa21umvh.fsf@algernon.balabit
Bug#658426: Re-Orphaning
# Re-orphaning. submitter 658426 ! owner 658426 ! close 658426 thanks I wish to re-orphan this package. The changes are minimal, plus the package is pretty old and unpopular. Cheers, Dan -- Daniel Martí - mv...@mvdan.cc - GPG 0x58BF72C3 pgpwpdTVPorfU.pgp Description: PGP signature
Processed: Re-Orphaning
Processing commands for cont...@bugs.debian.org: # Re-orphaning. submitter 658426 ! Bug #658426 [sponsorship-requests] RFS: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X Changed Bug submitter to 'Daniel Martà mv...@mvdan.cc' from 'Daniel Martà danielmarti.deb...@gmail.com' owner 658426 ! Bug #658426 [sponsorship-requests] RFS: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X Owner recorded as Daniel Martà mv...@mvdan.cc. close 658426 Bug #658426 [sponsorship-requests] RFS: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X Marked Bug as done thanks Stopping processing here. Please contact me if you need assistance. -- 658426: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658426 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133529096131112.transcr...@bugs.debian.org
Bug#669903: marked as done (RFS: ttylog/0.1.d-2)
Your message dated Tue, 24 Apr 2012 23:28:52 +0200 with message-id 1335302932.15788.18.camel@LAPJFS and subject line RFS: ttylog/0.1.d-2 uploaded has caused the Debian Bug report #669903, regarding RFS: ttylog/0.1.d-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 669903: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669903 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package ttylog * Package name: ttylog Version : 0.1.d-2 Upstream Author : Robert James Clay j...@rocasa.us, Tibor Koleszar o...@debian.org * URL : http://ttylog.rocasa.us * License : GPL-2+ Section : utils It builds these binary packages: ttylog - serial port logger ttylog-dbg - debugging symbols for ttylog To access further information about this package, please visit the following URL: http://mentors.debian.net/package/ttylog Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/ttylog/ttylog_0.1.d-2.dsc Changes since the last upload: ttylog (0.1.d-2) unstable; urgency=low * Set debhelper compatibility to 8. * Set debhelper Build-Depends to version 8. * Set Standards Version in debian/control to 3.9.3. * Rewrite debian/copyright in accordance with DEP-5. * Explicitly set Debian source format as 3.0 (quilt). * Changed to using dh and a minimal version of debian/rules. * Update the Vcs-Git Vcs-Browser fields in debian/control. * Add creation of a ttylog-dbg package to the package build. Regards, Robert James Clay ---End Message--- ---BeginMessage--- Package uploaded - thanks! Feel free to contact me directly for future ttylog RFS. Best regards, Johann Felix Soden signature.asc Description: This is a digitally signed message part ---End Message---
Bug#670334: RFS: notion/3+2012042300-1 [ITP] -- Notion tiling tabbed window manager
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package notion Package name: notion Version : 3+2012042300-1 Upstream Author : The Notion Team, p/a arnou...@bzzt.net URL : http://notion.sf.net License : Ion license (LGPL with trademark restrictions) Section : x11 It builds those binary packages: notion - tiling tabbed window manager designed for keyboard users notion-dev - Notion development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/notion Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/non-free/n/notion/notion_3+2012042300-1.dsc Notion is an actively maintained fork of the unmaintained 'ion3', and this package is based on previous ion3 packaging work by Ben Hutchings et al. Several users have expressed interest in a Debian package, both on our mailinglists and the notion ITP bug, #647048. Because of extra clauses added to the LGPL for this software (mostly protecting the 'ion' name), we propose this package for the 'non-free' repositories. The ion3 package has been available in the non-free repos under the same license before. Changes since the last (ion3) upload include: * Import new upstream version * Updated standards version to 3.9.3 (no change required) * Move general fields (homepage, section, priority) to source package * Use '3.0 (quilt)' source versions, removes the need to call quilt * Add descriptions for patches * Drop empty lintian/overrides directories * Fix unescaped hyphen in manpages Regards, Arnout Engelen -- 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/20120424215325.gc2...@bzzt.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
(I don't intend to sponsor this package.) * Dmitry Nezhevenko d...@dion.org.ua, 2012-04-22, 14:03: dget -x http://mentors.debian.net/debian/pool/main/p/python-django-djblets/python-django-djblets_0.6.17-1.dsc I'd use debhelper (= 8) instead of debhelper (= 8.0.0), for easier backporting. DEP-5 spec says There are many versions of the MIT license. Please use Expat instead, when it matches. Files: media/js/jquery* - did you mean Files: djblets/media/js/jquery*? More importantly, I don't see source for some of these files. License of feedparser.py is not documented in debian/copyright. AFAICS you don't need --buildsystem=python_distutils, dh will detect it automatically. Upstream provides a test suite. Please run it at build time, against all supported Python versions. -- 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/20120424231708.ga9...@jwilk.net
Bug#669599: RFS: python-django-evolution/0.6.7-1 [ITP] -- Schema evolution for the Django web framework
(I don't intend to sponsor this package.) * Dmitry Nezhevenko d...@dion.org.ua, 2012-04-20, 13:39: http://mentors.debian.net/debian/pool/main/p/python-django-evolution/python-django-evolution_0.6.7-1.dsc Why priority extra? I'd use debhelper (= 8) instead of debhelper (= 8.0.0), for easier backporting. What is python-feedparser dependency for? AFAICS you don't need --buildsystem=python_distutils, dh will detect it automatically. Upstream provides a test suite. Please run it at build time, against all supported Python versions. -- 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/20120424233313.ga6...@jwilk.net
Bug#670195: RFS: lierolibre/0.1-1
On Tue, 2012-04-24 at 10:14 +0800, Paul Wise wrote: On Tue, Apr 24, 2012 at 5:26 AM, Martin Erik Werner wrote: I am looking for a sponsor for my new package lierolibre A review, since you are upstream too, I'm including some advice related to that too. Thanks for the review, ./TODO :) I would suggest using git2cl or 'git log' upstream to create the ChangeLog file. Ok, I've used git log --stat, that seems to be the most readable format. I note many files don't have copyright/license headers: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ I'm aware, I have taken to practice adding copyright headers to all *header* files whose related code I poke in, but since I have not made changes to all bits, many remain unchanged. I would suggest moving the C++ code to a src/ (or similar) subdir. Yeah, that's probably a good idea, I'll look into that. I would suggest deleting sdl.m4 from your VCS and just letting autotools copy in the one from SDL. Via autoreconf you mean? I'll look into that. How about completely dropping the zlib copy from your gvl fork? Yeah, true, ancient anyways, done. gvl is both an embedded code copy and a nest of embedded code copies, some of which are even in Debian (zlib, libpcl1-dev, libtut-dev). My eyes! Well the zlib is unused, (and now deleted). I was not aware of libpcl and libtut, I'll have a look at ripping those out as well. I found this post about dtoa.c: http://patrakov.blogspot.com.au/2009/03/dont-use-old-dtoac.html Hmm, I though I removed that since I found it non-free... Anyways, it's not used in any of the resulting binaries, and now deleted. Hmm, you are using both the jam and autotools build systems, is that on purpose? I am keeping the Jam build updated and working, so that both may be used, it's not being used in the packaging build, if I haven't made some clear mistake... I'd suggest that individual graphics in separate .xpm files would be a better way to develop the graphics than strips of multiple graphics in one .xpm file. Maybe, and mapping the palette somehow would also be handly, it's a TODO, but the current method is at least better than nothing, as noted before. You might want to add the old liero release info to NEWS? True, done so. On my screen the default window size is so small I can't read the writing. How about making it 800x600? I would suggest using one of these algorithms for window scaling: https://en.wikipedia.org/wiki/Image_scaling http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/index.html Yeah, the native game resolution is 320x200 pixels, and anything else is scaled. Both nearest and scale2X are available currently, toggled via the [F1] in-game menu. I think I've got a reasonable hack setting it to 800x500 (x2.5) for now, though the code that handles the resolution is somewhat of a mystery to me at the moment. One can also use: window-managers default maximise method (alt+F10, double-click title, maximise button) F6 to get 640x480, scaled F5 to get fullscreen, scaled Unfortunately all higher resolutions seem to add unneeded bordering... I would suggest changing the default keyboard settings for player 1 to the more standard wasd. I disagree on this, Since control, alt and shift are used wasd becomes very cumbersome. For singleplayer I personally use ijkl and asd for actions, but that's also quite odd, and inappropriate for splitscreen, so I think it makes best sense to keep the LIERO default here. The change weapon button doesn't seem to work. Do you mean the one for Player2? Yeah, that's the default case for me as well, though I suspect that that's due to me having Alt Gr instead of LAlt, and I'm not sure if it's possible to support both, I'll have to look into that.. Why the dpkg predepends? Hmm, since I am (or at least should be) using xz compression for the packages? Please use dh --parallel or mention in debian/rules why build parallelism isn't possible to use. Ah, ok, I'll do that. I would suggest depending on dh-autoreconf and running dh --with autoreconf to ensure that the configure script and Makefiles are always buildable on Debian. This is useful since Debian does rebuild testing for newer versions of autotools. Ah, I haven't looked at autotools from a Debian perspective enough it seems, thanks for the hint. cppcheck warnings: [gvl/gvl_test/_build/deque.cpp:51]: (error) Throwing exception in destructor [gvl/crypt/curve25519.cpp:318]: (error) Memory leak: temp [gvl/containers/tests/deque.cpp:48]: (error) Throwing exception in destructor [gvl/crypt/curve25519.cpp:690]: (error) Memory leak: temp1 [gvl/uthread/uthread.cpp:100]: (error) Throwing exception in destructor [viewport.cpp:132]: (error) Possible null pointer dereference: worm - otherwise it is redundant to check if worm is null at line 111 I'll have to do some digging here :) Thanks! -- Martin Erik Werner
My package sponsoring guidelines
Hi, I'm going to be making some of my time available to review packages. So, I'm primarily interested in looking at work that fixes release-critical bugs, security issues, and just regular bugs as well (i.e. non-maintainer uploads, NMUs). So, if you're the bug fixing type, this is for you. I am however not very interested in new packages per se, and will not be spending much time on that. For release-critical bugs, the best place to get started is here: http://bugs.debian.org/release-critical/other/testing.html For security issues, the best place to start is either the debsecan tool (i.e. the debsecan package), which tells you which issues are currently unfixed on your current system, or the sid security-tracker: http://security-tracker.debian.org/tracker/status/release/unstable Also, helping with plain-old security triage is very useful as well, and may lead you to packages/bugs that need fixing (including possibly stable updates as well): http://security-tracker.debian.org/tracker/data/report So, if you're interested in doing the kind of work that helps improve existing Debian packages and helps make progress toward the next release, then please start with the above and make sure to include [NMU], [RC], or [SEC] as appropriate in the title of your sponsorship-request bugs. I will be specifically scanning only bugs including those terms in the subject. Best wishes, Mike -- 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/CANTw=mnkayzyqyewhm3ingk_vcb0nsesm4h2u0z_jzpmi4l...@mail.gmail.com
Bug#670195: RFS: lierolibre/0.1-1
On Wed, Apr 25, 2012 at 7:50 AM, Martin Erik Werner wrote: Via autoreconf you mean? I'll look into that. Yep Well the zlib is unused, (and now deleted). I was not aware of libpcl and libtut, I'll have a look at ripping those out as well. ... Hmm, I though I removed that since I found it non-free... Anyways, it's not used in any of the resulting binaries, and now deleted. Cool. Yeah, the native game resolution is 320x200 pixels, and anything else is scaled. Both nearest and scale2X are available currently, toggled via the [F1] in-game menu. I think I've got a reasonable hack setting it to 800x500 (x2.5) for now, though the code that handles the resolution is somewhat of a mystery to me at the moment. One can also use: window-managers default maximise method (alt+F10, double-click title, maximise button) F6 to get 640x480, scaled F5 to get fullscreen, scaled Unfortunately all higher resolutions seem to add unneeded bordering... IIRC with X11 there are hints you can send to the WM to prevent users from being able to resize to particular sizes, that might be useful to get rid of the bordering. Also, I encountered a couple of segfaults when resizing, one in scale2x mode when resizing the window less than 320x200. The other was random while scaling in scale2x mode. I disagree on this, Since control, alt and shift are used wasd becomes very cumbersome. For singleplayer I personally use ijkl and asd for actions, but that's also quite odd, and inappropriate for splitscreen, so I think it makes best sense to keep the LIERO default here. Hmm, ok. Do you mean the one for Player2? Yeah, that's the default case for me as well, though I suspect that that's due to me having Alt Gr instead of LAlt, and I'm not sure if it's possible to support both, I'll have to look into that.. Yep, thanks. Why the dpkg predepends? Hmm, since I am (or at least should be) using xz compression for the packages? Ah. Ah, I haven't looked at autotools from a Debian perspective enough it seems, thanks for the hint. I don't think there are many Debian folks who would suggest this. -- 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/CAKTje6FrZsHxDJ3ugncWnWP=pt_a2_sa5flv+bj7jjdzcow...@mail.gmail.com
Bug#670195: RFS: lierolibre/0.1-1
One more thing, the WM close button doesn't close the game (at least in GNOME 3). -- 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/caktje6e-2puphkhakelw2k3yj9i3utdt_svgki0mscd6o8n...@mail.gmail.com
Bug#670195: RFS: lierolibre/0.1-1
On Wed, 2012-04-25 at 01:50:59 +0200, Martin Erik Werner wrote: On Tue, 2012-04-24 at 10:14 +0800, Paul Wise wrote: I note many files don't have copyright/license headers: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ I'm aware, I have taken to practice adding copyright headers to all *header* files whose related code I poke in, but since I have not made changes to all bits, many remain unchanged. Well strictly speaking you don't really need to add a Copyright notice to be able to add the per-file license headers; you could do the latter right away for all project files, and do the former when time permits a proper authorship research, or at least for yours when you modify them. regards, guillem -- 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/20120425054045.ga7...@gaara.hadrons.org
