Bug#663151: RFS: rhinote/0.7.4-2
On Mon, Jun 18, 2012 at 09:12:40AM +0200, Jakub Wilk wrote: > Have you forwarded these patches upstream? I planned to forward them as soon as the package was accepted into Debian, but as it’s apparently going to take very long I have done it yesterday. > You changed priority from extra to option, but this is not > documented in the changelog. I have updated the changelog to briefly explain the rationale behind the priority bump. The updated package is available from mentors.d.n, if anyone is interested. Thank you for taking a look at it! -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Hi everybody, this is just to remind you that Rhinote is still looking for a sponsor. As the changes for this revision are mostly patches to the software itself, which is written in Python, I'm CCing the python-apps Team hoping that someone will consider picking it up. Cheers. On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "rhinote" > > * Package name: rhinote > Version : 0.7.4-2 > Upstream Author : Marv Boyes > * URL : http://rhinote.tuxfamily.org/ > * License : GPL-2+ > Section : x11 > > It builds those binary packages: > > rhinote- virtual sticky-notes for your desktop > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/rhinote > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc > > More information about rhinote can be obtained from > http://rhinote.tuxfamily.org/ . > > Changes since the last upload: > > * 001-simplify-imports.diff: > - improve the way modules are imported. > * 002-use-secure-printfile.diff: > - avoid potential symlink attacks and cluttering the user's home. > * 003-test-for-external-commands.diff: > - ensure external commands are available before calling them. > * 004-use-popen.diff: > - replace os.system() with the more secure subprocess.Popen(). > * 005-support-lp.diff: > - add support for the lp command in addition to lpr. > * 006-set-print-job-name.diff: > - provide a descriptive name for the print job. > * 007-set-class-name.diff: > - set application name for use by window managers. > * Simplify Depends: to cups-client | lpr. > * Bump Standards-Version to 3.9.3 (no changes needed). > > The software has been heavily patched after Paul Wise has reviewed it[1] > and found a bunch of issues with upstream’s code. He later took a look > at the patches[2] and found them to be okay. > > > [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html > [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1
Nobody? Beef is currently the only Brainfuck interpreter available in Debian, and the package that's going to be included in Wheezy, if nobody steps up for an upload, is FIVE years old – as opposed to this one, which is only a year old ;) Please consider taking a look at Beef, and also at Cattle (ITP #673550), which is a dependency for Beef. Thank you. On Sat, May 19, 2012 at 05:14:22PM +0200, Andrea Bolognani wrote: > I am looking for a sponsor for my package "beef" > > * Package name: beef > Version : 1.0.0-1 > Upstream Author : Andrea Bolognani > * URL : http://kiyuko.org/software/beef > * License : GPL-2+ > Section : devel > > It builds these binary packages: > > beef - flexible Brainfuck interpreter > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/beef > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc > > Changes in this release: > > * New upstream release. (Closes: #639247) > * Fix watch file. (Closes: #529748) > * U01-fix-whatis-entry.diff: > - use the conventional format for the NAME section of the man > page, so that programs such as whatis and apropos can parse it. > * D01-skip-documentation-files.diff: > - don't install duplicated documentation files. > * D02-leave-changelog-alone.diff: > - don't overwrite upstream changelog. > * Switch to 3.0 (quilt) source format. > * Switch to compat level 9. > * Update Debian copyright file to DEP5 candidate version. > * Add Vcs-* control fields. > * Bump Standards-Version to 3.9.3 (no changes needed). -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673550: RFS: cattle-1.0/1.0.1-1 [ITP] -- Brainfuck language toolkit
Any takers? On Sat, May 19, 2012 at 05:23:10PM +0200, Andrea Bolognani wrote: > Dear mentors, > > I am looking for a sponsor for my package "cattle-1.0" > > * Package name: cattle-1.0 > Version : 1.0.1-1 > Upstream Author : Andrea Bolognani > * URL : http://kiyuko.org/software/cattle > * License : GPL-2+ > Section : libs > > It builds these binary packages: > > libcattle-1.0-0 - Brainfuck language toolkit > gir1.2-cattle-1.0 - Brainfuck language toolkit (introspection files) > libcattle-1.0-dev - Brainfuck language toolkit (development files) > libcattle-1.0-doc - Brainfuck language toolkit (API reference) > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/cattle-1.0 > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/c/cattle-1.0/cattle-1.0_1.0.1-1.dsc > > Changes in this release: > > * Initial release. (Closes: #617304) > * D01-tweak-build-system.diff: > - avoid building example programs to speed up compilation. > > > Cattle is a dependency for the latest release of Beef, which is already in > Debian and for which I've filed a separate RFS as #673549. > > I would be glad if someone could upload this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1 -- flexible Brainfuck interpreter
Any takers? On Sat, May 19, 2012 at 05:14:22PM +0200, Andrea Bolognani wrote: > Dear mentors, > > I am looking for a sponsor for my package "beef" > > * Package name: beef > Version : 1.0.0-1 > Upstream Author : Andrea Bolognani > * URL : http://kiyuko.org/software/beef > * License : GPL-2+ > Section : devel > > It builds these binary packages: > > beef - flexible Brainfuck interpreter > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/beef > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc > > Changes in this release: > > * New upstream release. (Closes: #639247) > * Fix watch file. (Closes: #529748) > * U01-fix-whatis-entry.diff: > - use the conventional format for the NAME section of the man > page, so that programs such as whatis and apropos can parse it. > * D01-skip-documentation-files.diff: > - don't install duplicated documentation files. > * D02-leave-changelog-alone.diff: > - don't overwrite upstream changelog. > * Switch to 3.0 (quilt) source format. > * Switch to compat level 9. > * Update Debian copyright file to DEP5 candidate version. > * Add Vcs-* control fields. > * Bump Standards-Version to 3.9.3 (no changes needed). > > > I would be glad if someone could upload this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Dear mentors, Rhinote is still looking for a sponsor, and it’s been a while so I think it’s a good time to bump the thread. As you can see from the full bug report for this RFS (#663151) this updated packages contains code tweaks that make Rhinote much better overall, and that Rhinote users would certainly appreciate having in a stable release. Please consider taking a look at the package and sponsoring it. Thank you. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673550: RFS: cattle-1.0/1.0.1-1 [ITP] -- Brainfuck language toolkit
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cattle-1.0" * Package name: cattle-1.0 Version : 1.0.1-1 Upstream Author : Andrea Bolognani * URL : http://kiyuko.org/software/cattle * License : GPL-2+ Section : libs It builds these binary packages: libcattle-1.0-0 - Brainfuck language toolkit gir1.2-cattle-1.0 - Brainfuck language toolkit (introspection files) libcattle-1.0-dev - Brainfuck language toolkit (development files) libcattle-1.0-doc - Brainfuck language toolkit (API reference) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cattle-1.0 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cattle-1.0/cattle-1.0_1.0.1-1.dsc Changes in this release: * Initial release. (Closes: #617304) * D01-tweak-build-system.diff: - avoid building example programs to speed up compilation. Cattle is a dependency for the latest release of Beef, which is already in Debian and for which I've filed a separate RFS as #673549. I would be glad if someone could upload this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "beef" * Package name: beef Version : 1.0.0-1 Upstream Author : Andrea Bolognani * URL : http://kiyuko.org/software/beef * License : GPL-2+ Section : devel It builds these binary packages: beef - flexible Brainfuck interpreter To access further information about this package, please visit the following URL: http://mentors.debian.net/package/beef Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc Changes in this release: * New upstream release. (Closes: #639247) * Fix watch file. (Closes: #529748) * U01-fix-whatis-entry.diff: - use the conventional format for the NAME section of the man page, so that programs such as whatis and apropos can parse it. * D01-skip-documentation-files.diff: - don't install duplicated documentation files. * D02-leave-changelog-alone.diff: - don't overwrite upstream changelog. * Switch to 3.0 (quilt) source format. * Switch to compat level 9. * Update Debian copyright file to DEP5 candidate version. * Add Vcs-* control fields. * Bump Standards-Version to 3.9.3 (no changes needed). I would be glad if someone could upload this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Dear mentors, please consider reviewing and sponsoring this new Rhinote upload. As you can see from the changelog entry reported below, the updated package contains several improvements that would make using Rhinote much better; moreover, a Debian member has already reviewed the patches and found them to be okay. Thank you for your time. On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "rhinote" > > * Package name: rhinote > Version : 0.7.4-2 > Upstream Author : Marv Boyes > * URL : http://rhinote.tuxfamily.org/ > * License : GPL-2+ > Section : x11 > > It builds those binary packages: > > rhinote- virtual sticky-notes for your desktop > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/rhinote > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc > > More information about rhinote can be obtained from > http://rhinote.tuxfamily.org/ . > > Changes since the last upload: > > * 001-simplify-imports.diff: > - improve the way modules are imported. > * 002-use-secure-printfile.diff: > - avoid potential symlink attacks and cluttering the user's home. > * 003-test-for-external-commands.diff: > - ensure external commands are available before calling them. > * 004-use-popen.diff: > - replace os.system() with the more secure subprocess.Popen(). > * 005-support-lp.diff: > - add support for the lp command in addition to lpr. > * 006-set-print-job-name.diff: > - provide a descriptive name for the print job. > * 007-set-class-name.diff: > - set application name for use by window managers. > * Simplify Depends: to cups-client | lpr. > * Bump Standards-Version to 3.9.3 (no changes needed). > > The software has been heavily patched after Paul Wise has reviewed it[1] > and found a bunch of issues with upstream’s code. He later took a look > at the patches[2] and found them to be okay. > > > [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html > [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Hi mentors, just a friendly bump so that you don’t forget the new and greatly improved version of Rhinote is still waiting for a sponsor. Please take a look at the package and consider uploading it. Cheers! On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "rhinote" > > * Package name: rhinote > Version : 0.7.4-2 > Upstream Author : Marv Boyes > * URL : http://rhinote.tuxfamily.org/ > * License : GPL-2+ > Section : x11 > > It builds those binary packages: > > rhinote- virtual sticky-notes for your desktop > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/rhinote > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc > > More information about rhinote can be obtained from > http://rhinote.tuxfamily.org/ . > > Changes since the last upload: > > * 001-simplify-imports.diff: > - improve the way modules are imported. > * 002-use-secure-printfile.diff: > - avoid potential symlink attacks and cluttering the user's home. > * 003-test-for-external-commands.diff: > - ensure external commands are available before calling them. > * 004-use-popen.diff: > - replace os.system() with the more secure subprocess.Popen(). > * 005-support-lp.diff: > - add support for the lp command in addition to lpr. > * 006-set-print-job-name.diff: > - provide a descriptive name for the print job. > * 007-set-class-name.diff: > - set application name for use by window managers. > * Simplify Depends: to cups-client | lpr. > * Bump Standards-Version to 3.9.3 (no changes needed). > > The software has been heavily patched after Paul Wise has reviewed it[1] > and found a bunch of issues with upstream’s code. He later took a look > at the patches[2] and found them to be okay. > > > [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html > [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rhinote" * Package name: rhinote Version : 0.7.4-2 Upstream Author : Marv Boyes * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc More information about rhinote can be obtained from http://rhinote.tuxfamily.org/ . Changes since the last upload: * 001-simplify-imports.diff: - improve the way modules are imported. * 002-use-secure-printfile.diff: - avoid potential symlink attacks and cluttering the user's home. * 003-test-for-external-commands.diff: - ensure external commands are available before calling them. * 004-use-popen.diff: - replace os.system() with the more secure subprocess.Popen(). * 005-support-lp.diff: - add support for the lp command in addition to lpr. * 006-set-print-job-name.diff: - provide a descriptive name for the print job. * 007-set-class-name.diff: - set application name for use by window managers. * Simplify Depends: to cups-client | lpr. * Bump Standards-Version to 3.9.3 (no changes needed). The software has been heavily patched after Paul Wise has reviewed it[1] and found a bunch of issues with upstream’s code. He later took a look at the patches[2] and found them to be okay. [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: notify command
On Wed, Feb 15, 2012 at 03:16:14AM +0330, Mohsen Pahlevanzadeh wrote: > On Tue, 2012-02-14 at 21:07 +, Javi Merino wrote: > > libnotify-bin > Oh no, I'm looking for notify classic command, it used by a set of old > unix and distro such as nice, renice and so on. > You can the following link: > http://www.manpagez.com/man/1/notify/osx-10.7.php According to the very page you linked, that command is a shell built–in that is only available in csh. Try installing csh or tcsh. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: rhinote (new upstream version)
On Sat, Feb 04, 2012 at 11:49:05AM +0100, Andrea Bolognani wrote: > On Sat, Feb 04, 2012 at 12:42:57PM +0800, Paul Wise wrote: > > > Patches look good to me, please forward them. > > > > rhinote is not in my areas of interest, so I won't be uploading it, sorry. > > No need to apologize, you already did so much by finding all those > issues and reviewing my patches. Thank you once again for that. > > Any takers? David again, maybe? ;) It’s been a week now, with no response so far, so I’ll take the liberty of gently bumping the thread. The package is fairly straightforward, and the new patches have already been reviewed by a Debian Member. Please consider sponsoring it. Thank you. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Should I split off arch independant part?
On Thu, Feb 09, 2012 at 05:21:55PM -0600, Paul Elliott wrote: > Unfortunately the .doc file is the source, so everything must be rebuilt from > source i.e. the .doc file as part of the build process. What kind of documentation are we talking about? If it’s just a reference manual of some sort, chances are catdoc(1) will do a reasonable job at converting it to plain text. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
gobject-introspection’s .typelib files and Multi-Arch
Good morning mentors, I’m in the process of packaging a GObject–based library[1] which provides gobject-introspection support. While preparing the gir1.2- package I stumbled upon the gobject-introspection mini–policy[2] and found out that .typelib files are supposed to be installed in the /usr/lib/girepository-1.0 directory, which doesn’t take multiarch into account. Seeing as the .typelib files are binary blobs, that sounded odd. I checked gir1.2-gtk-3.0 for amd64, mipsel and armhf, obtaining this: $ md5sum Gtk-3.0.* de536efa2a280bd6e41bdc31c6141106 Gtk-3.0.amd64.typelib 4d35a70e54348924ddfeabf25528089d Gtk-3.0.armhf.typelib 4d35a70e54348924ddfeabf25528089d Gtk-3.0.mipsel.typelib The question is: why aren’t these files installed in a multiarch–aware path? In a very old thread about gobject-introspection on -devel, Josselin Mouette argues that adjusting paths for multiarch is not needed, but given that we’re going through all the trouble of isolating arch–specific bits I don’s see why not go the extra mile. Does somebody have any suggestion, or perhaps a good rationale for the current state of affairs? Cheers. [1] http://anonscm.debian.org/gitweb/?p=collab-maint/cattle-1.0.git;a=summary [2] /usr/share/gobject-introspection/policy.txt [3] http://lists.debian.org/debian-devel/2009/09/msg00958.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: rhinote (new upstream version)
On Sat, Feb 04, 2012 at 12:42:57PM +0800, Paul Wise wrote: > Patches look good to me, please forward them. > > rhinote is not in my areas of interest, so I won't be uploading it, sorry. No need to apologize, you already did so much by finding all those issues and reviewing my patches. Thank you once again for that. Any takers? David again, maybe? ;) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: creating an orig.tar.gz from a CVS
On Thu, Feb 02, 2012 at 10:43:34PM +0100, Jerome BENOIT wrote: > In short, I have to do it by hand. Tarballs are usually created by upstream when making a release. There are a variety of build system (autotools, CMake, etc) that provide a standard way to prepare a release tarball: if your upstream uses one of those, you can usually follow the same steps to create a CVS snapshot, taking care to choose a sensible version number. If upstream uses no such standardized build system, they probably have rolled their own script to prepare a release. Again, use the same steps to build your snapshot. So, in short: since it depends a lot on what upstream’s habits are, your best bet is simply asking them. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: rhinote (new upstream version)
On Tue, Jan 24, 2012 at 07:29:03PM +0800, Paul Wise wrote: > > I will try to conjure a patch addressing all the concerns you raised > > during the course of the next few days, and I hope you’ll be willing to > > review it when it’s done to make sure it is suitable for inclusion > > upstream. As I’ve mentioned earlier, I don’t have deep knowledge of > > Python, but you sure seem to know your way around it. > > Sure, no probs. I’ve patched the source quite a bit, and I believe I’ve addressed all of your concerns. I’ve also improved integration with window managers by setting the WM_CLASS, so that pagers and the like show “Rhinote” instead of “Tk” now. All of the patches are available in the git repository[1], and I’ve also uploaded an updated package to m.d.n[2]. I’ll be glad if you could review the patches to confirm they are indeed suitable for inclusion upstream, in which case I’ll forward them. And if you feel like taking a look also to the rest of the package and upload it, I certainly won’t be mad at you ;) Cheers. [1] http://anonscm.debian.org/gitweb/?p=collab-maint/rhinote.git;a=summary [2] http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: rhinote (new upstream version)
On Tue, Jan 24, 2012 at 08:47:21AM +0800, Paul Wise wrote:
> I always get curious when people upload with no comments, so here is a review:
First of all, thank you for the review. I’m always looking forward to
improve my packages, and an in–depth review gives me the chance to do
just that.
> You forgot to mention collab-maint in the changelog.
Yeah, I should probably have mentioned it, but mostly due to the fact
that I’ve added Vcs-* fields — or is collab-maint considered special
in this regard?
Do you suggest mentioning the addition in the changelog entry for the
next upload, or editing the current entry? The latter seems hacky, but
the former is a plain lie.
> You didn't mention the reason for changing the priority to extra.
rhinote depends on cups-bsd, which has Priority: extra, and according
to Policy packages can’t depend on packages with lower priority.
Since I’m going to have to patch the source anyway due to the suggestions
you made below, I might try to make it use lp where available (with
fallback to lpr), and depend on cups-client | lpr (both of which are
Priority: optional) instead.
I believe I could then drop the dependency on cups-bsd | lprng, since
both packages provide lpr, and raise the priority to optional again. Is
that correct?
> Please forward the desktop file and manual page upstream.
I’ve already forwarded them; upstream will probably include them in the
next upstream release, whenever that might be. Any suggestions on how to
document this fact? If we were talking about a patch, I would just use
DEP3, but this is a different scenario…
> One warning from pyflakes to forward upstream:
>
> rhinote.py:24: 'from Tkinter import *' used; unable to detect undefined names
I will notify upstream about this, maybe after doing some research to
understand what it means ;)
> rhinote.py should use os.path.expanduser and instead of
> os.environ['HOME'] since that works when the HOME environment variable
> is not set. Please send upstream a patch for this.
Unfortunately I’m not aware of the various Python best practices due to
the fact that I only did little Python programming; thank you for pointing
this out, I’ll patch it and notify upstream.
> rhinote.py should use the python subprocess module instead of the
> system() function. In any case this thing will not work since it will
> write to a file named lpr instead of running the lpr program. With
> subprocess you can easily pipe the results of one program to another
> which is what rhinote appears to want to do here. Also for upstream
> (but not on Debian due to the Depends), lpr/enscript are not
> guaranteed to be installed so this will fail silently instead of
> informing the user that printing is not available. In addition it
> doesn't remove the ~/.Rhinoteprintfile file when it is complete,
> leaving files around in ~/ is rude. I would also suggest that rhinote
> should be using a temporary file in the temp dir instead of a file in
> ~/ for this purpose, please ensure that it is secure and also supports
> $TMPDIR by using the python tempfile module.
>
> system('enscript -B --word-wrap $HOME/.Rhinoteprintfile > lpr &')
>
> Please send upstream a patch for this to use the subprocess module,
> detect when enscript/lpr are available and notify the user if not, use
> the tempfile module (for security and to support $TMPDIR etc) and also
> clean up afterwards.
I have to admit I’m guilty of never having attempted to print using
Rhinote, mostly due to the fact that I rarely have a printer handy.
Lesson learned.
I will try to conjure a patch addressing all the concerns you raised
during the course of the next few days, and I hope you’ll be willing to
review it when it’s done to make sure it is suitable for inclusion
upstream. As I’ve mentioned earlier, I don’t have deep knowledge of
Python, but you sure seem to know your way around it.
Once again, thank you for your review.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: Digital signature
Re: RFS: rhinote (new upstream version)
On Mon, Jan 23, 2012 at 08:54:57PM +0100, David Paleino wrote: > Uploaded, thanks for your contribution to Debian! Whoa, looks like I was right: it really was a quick job for a Debian Member ;) Thank you for the upload! -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: rhinote (new upstream version)
Dear mentors, two weeks have passed without any reply, so I won’t feel bad for giving this RFS a little more visibility. The package is pretty straightforward and lintian clean, so I reckon an experienced Debian contributor could review it reasonably quickly. Please give it a go. Thank you. On Tue, Jan 10, 2012 at 10:36:12PM +0100, Andrea Bolognani wrote: > Dear mentors, > > I am looking for a sponsor for my package "rhinote". > > * Package name: rhinote >Version : 0.7.4-1 >Upstream Author : Marv Boyes > * URL : http://rhinote.tuxfamily.org/ > * License : GPL-2+ >Section : x11 > > It builds those binary packages: > > rhinote- virtual sticky-notes for your desktop > > The package is already present in the archive; this new upload would > bring Debian up to speed with upstream development, along a bunch of > packaging improvements. > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/rhinote > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-1.dsc > > I would be glad if someone uploaded this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
RFS: rhinote (new upstream version)
Dear mentors, I am looking for a sponsor for my package "rhinote". * Package name: rhinote Version : 0.7.4-1 Upstream Author : Marv Boyes * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop The package is already present in the archive; this new upload would bring Debian up to speed with upstream development, along a bunch of packaging improvements. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-1.dsc I would be glad if someone uploaded this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Correct value for DEP5’s Format: field?
On Sun, Jan 08, 2012 at 09:58:25AM -0800, Russ Allbery wrote: > Andrea Bolognani writes: > > > I’m updating a debian/copyright file in DEP5 format, but I’m finding > > myself unable to pick an acceptable value for the Format: field. > > This is a temporary transitional annoyance that exists for a long and > complex set of reasons that isn't really worth getting into, but will > hopefully be resolved soon. > > In the meantime, you have your choice of using a URL that Lintian likes > but which doesn't actually exist, using the unversioned URL to DEP-5, > which Lintian complains about but which is otherwise a fairly reasonable > choice for right now, or using the ViewVC URI, which I didn't realize > would work but which does seem to be versioned (even though Lintian > doesn't know about it). The ViewVC seems the most reasonable choice, seeing it’s the only one having versioning; however, from the DEP5 Web page I get the impression it is developed using Bazaar, and ViewVC shows the contents of an SVN repository which doesn’t quite seem to be a mirror of the Bazaar one. Given the situation, I guess I’ll just use the unversioned URI and hope DEP5 will become official soon. Thank you for your input on the matter. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Correct value for DEP5’s Format: field?
Hi, I’m updating a debian/copyright file in DEP5 format, but I’m finding myself unable to pick an acceptable value for the Format: field. The previous value, from an earlier version of the package, is http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 lintian correctly warns me (out-of-date-copyright-format-uri tag) that a new version of the specification is available, and points me to http://dep.debian.net/deps/dep5/ for details. Trying to use that unversioned URI results in another lintian warning (unversioned-copyright-format-uri tag), suggesting that the correct format for the field is something along the lines of http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision= but that URI is broken, since the file has been moved. Fiddling a bit with the Web interface I came up with the following URI: http://anonscm.debian.org/viewvc/dep/web/deps/dep5/copyright-format.xml?revision=240&view=markup which seems to do the trick as far as fetching the full source of DEP5 at the intended revision, but is not recognized by lintian (unknown-copyright-format-uri tag). As a last source of confusion, the document located at http://dep.debian.net/deps/dep5/ seems to suggest that the canonical source is http://anonscm.debian.org/loggerhead/dep/dep5/trunk/annotate/head:/dep5/copyright-format.xml That URI does indeed work, but it contains no explicit revision number, and as far as I can tell it’s not possible to convince Loggerhead to both consider a specific revision *and* display the whole file. I think the ViewWC URI above is the most sensible choice. Any ideas? -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: anox
On Mon, Dec 12, 2011 at 08:36:18AM +0100, Sébastien Bertrand wrote: > > From the UNIX point of view, they are not. > > It seems that xinit behave this way, the following commands do not > give the same result : > xinit tremulous -- :1 > xinit tremulous --quiet -- :1 > xinit "tremulous --quiet" -- :1 > > The first just works, the second give an error "xterm: bad command > line option "tremulous"", and the third give an error "No absolute > path found for shell: tremulous --quiet". > > Is the "--" separator part of the UNIX convention ? In the GNU world, -- is used to force the end of options and the start of the list of files to act on. This is not used often, but comes in handy if you have a file called ‘-foo’ somewhere. xinit uses a different convention: the part before -- is the client part, while the part following it is the server part. The client part defaults to launching xterm, and if the first argument is not an absolute path all arguments in the client part are passed directly to xterm. With this knowledge, we can understand what’s happening in each case: 1. xinit tremulous -- :1 ‘xterm tremulous’ is called. The last argument passed to xterm is the name of the shell to execute, so xterm spawns tremulous; 2. xinit tremulous --quiet -- :1 ‘xterm tremulous --quiet’ is called. xterm can’t recognize ‘tremulous’ as a command line option, so it reports an error; 3. xinit "tremulous --quiet" -- :1 xterm is called with a single argument, ‘tremulous --quiet’. Since it’s the last argument, it is taken to be the name of the shell to execute, but no program with that name is found on the system, so xterm exits reporting an error. The last example very clearly shows why quoting makes a difference in the UNIX world, and why you can’t just put everything inside double quotes and call it a day. What you probably want to do is to call something like xinit /usr/games/tremulous --quiet -- :1 so that the game is called directly instead of going through xterm. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: anox
On Fri, Dec 09, 2011 at 11:30:38AM +0100, Sébastien Bertrand wrote: > > calling > > > > foo "bar x" > > > > is not the same as calling > > > > foo bar x. > > >From the point of view of anoX, these two commands are the same. From the UNIX point of view, they are not. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITS: scrotwm (already in Debian)
On Sat, Nov 12, 2011 at 12:19:16AM +0100, Niels Thykier wrote: > > I’ve also noticed that the makefile snippet exporting the hardening build > > flags takes care of enabling optimization and handling > > DEB_BUILD_OPTIONS=noopt itself, which is nice. > > Indeed, unfortunately it comes at the price of a version Build-Depends > on dpkg-dev (>= 1.16.1~). You may be able to ditch it by using > "-include" in d/rules, but then you have to handle noopt manually in > case dpkg-dev (>= 1.16.1~) is not available How did I miss that? Great catch! A fixed package is available, as usual, from mentors.debian.net. Cheers. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITS: scrotwm (already in Debian)
On Thu, Nov 10, 2011 at 10:13:04PM +0100, Niels Thykier wrote: > >> [1] Strictly speaking the CFLAGS/LDFLAGS from should "overrule" the > >> upstream ones if there are conflicts. Fixing that is left as an > >> exercise to the reader. ;) > > > > Can’t think of a way of doing that without patching the Makefile. But > > then again, patching the Makefile is no big deal. > > If you are going to send a patch upstream anyway, you might as well make > it possible to insert user *FLAGS after the "upstream flags". ;) I ended up doing just that: I’ve introduced a MAINT_* version of all the variables, and changed the build rules so that the MAINT_* version is used just before the user–settable version. I’ve also noticed that the makefile snippet exporting the hardening build flags takes care of enabling optimization and handling DEB_BUILD_OPTIONS=noopt itself, which is nice. I will talk to upstream about enabling optimization by default. The updated package is up on mentors.debian.net, let me know what you think of it. Cheers. PS: No need to CC me, I’m subscribed to the list. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITS: scrotwm (already in Debian)
On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote:
> Hi,
>
> As the subject suggests I am willing to sponsor the package. :)
I’m glad to hear that!
> But
> before I do; have you considered enabling hardning flags in your
> package? A basic example of how to do it can be seen the attached patch[1].
Thanks for pointing that out.
I’m looking at the documentation and at your patch, and I’m unsure
about this bit
%.so: %.c
- $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@
+ $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@
Are you positive $(LDFLAGS) is supposed to be passed to the compiler
here? It is just creating an object file, so the linker should not
be called by $(CC).
In fact, I did a quick test using make’s implicit rules, and it seems
to confirm that $(LDFLAGS) is not supposed to be there:
$ echo 'void test (void) {}' >test.c
$ CFLAGS=-Wall make test.o
cc -Wall -c -o test.o test.c
$ rm test.o
$ LDFLAGS=-Wall make test.o
cc-c -o test.o test.c
The latter call to $(CC), instead, needs it. And now that I look at it,
it’s clear that $(LDADD) should really be $(LIBS), and that $(CPPFLAGS)
should be there as well, for -DSWM_LIB.
I will patch the Makefile and send the patch upstream for inclusion in
a future release.
> Is there a reason that the binaries are compiled without
> optimization[2]? As far as I can tell it is an oversight, because the
> "osx" Makefile includes an "-O2" flag. However, if it is known to have
> issues with optimization on Linux platforms, a comment about that would
> be appreciated (bonus points for valid references to bugs against gcc :P).
It’s almost certainly an oversight.
> [1] Strictly speaking the CFLAGS/LDFLAGS from should "overrule" the
> upstream ones if there are conflicts. Fixing that is left as an
> exercise to the reader. ;)
Can’t think of a way of doing that without patching the Makefile. But
then again, patching the Makefile is no big deal.
Thanks for your input, I’ll let you know when I have an updated package
ready for review.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: Digital signature
RFS: scrotwm (already in Debian)
Dear mentors, I’m looking for a sponsor for my package “scrotwm”. * Package name : scrotwm Version : 0.9.34-1 Upstream Authors : Marco Peereboom , Ryan McBride , Darrin Chandler * URL : http://opensource.conformal.com/wiki/Scrotwm * License : ISC and Expat and BSD-3-clause and BSD-4-clause Section : x11 It builds the following binary packages: scrotwm - dynamic tiling window manager The package, along with more information about it, can be found at http://mentors.debian.net/package/scrotwm This new version of the package fixes the following bugs: #531844 - scrotwm: please allow one workspace to span multiple monitors #552647 - suggest or recommend acpi and iostat The package is already in Debian; however, the packaged version is really old (almost two years) and my usual sponsor is no longer able to review and upload it further due to time constraints. I would be glad if someone would review and upload this package for me, and I would prefer it if the sponsor was interested in acting as a recurring sponsor for this and other packages I maintain in Debian. Have a nice day. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: berlios closing; where should my projects escape to?
On Thu, Oct 20, 2011 at 07:34:31AM +0100, Roger Light wrote: > I think it's more like "100% of people prefer the DVCS they use first > because anything after that is different". False. I started off with Bazaar, used it happily for a couple years, then moved everything to Git because I liked it better. This doesn’t completely disprove your point, though. Truth is, most DVCS are no more different from one another than different imperative programming languages are, and programmers constantly move from a project using a certain language to another using a different language without too much pain. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: heimdall android flasher
On Fri, Sep 30, 2011 at 11:06:07AM +0800, Paul Wise wrote: > > Heimdall is a cross-platform open-source tool suite used to flash > > firmware (aka ROMs) onto Samsung Galaxy S > > devices.(http://www.glassechidna.com.au/products/heimdall/) > > I personally wouldn't consider sponsoring something that only does the > non-standard protocol used by Samsung. Why? We already have several tools in the archive to deal with the proprietary iPod protocol, I fail to see how this would be any different. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Question about menu files
On Fri, Sep 23, 2011 at 12:09:55AM +0200, Rodolfo kix Garcia wrote: > Hi, > > I have this in the menu file: > > package(wmaker):needs="wmaker" \ > section="/" title="Exit" sort="ZZ" \ > command="EXIT" > > And I got this lintian error: > > W: wmaker: menu-command-not-in-package usr/share/menu/wmaker:6 EXIT > W: wmaker: menu-item-needs-tag-has-unknown-value wmaker > usr/share/menu/wmaker:6 > N: > N:The menu item has a line that has a needs= field with a > strange value. > N:This may be intentional, but it's probably a typo that will > make menu > N:ignore the line. > N: > N:Severity: minor, Certainty: certain > N: > N:Check: menu-format, Type: binary > > Yes, is not a command. What should I do? I cannot find more info > about how to add the EXIT, SHUTDOWN,... commands. lintian complains about the needs= field. Read menufile(5) to find out what are the acceptable values: "wmaker" is not one of them. I see no mention of the sort= field in that man page, and "/" doesn’t seem to to be an acceptable value for the section= field, at least according to the Debian Menu sub–policy (“Packages must be placed in leaf sections”). As for the command to quit wmaker… I really have no idea. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Tue, Jul 26, 2011 at 11:08:40PM +0200, Kilian Krause wrote: > Thus neither document too > publically how we do it nor what the exact internal versions are. I don’t think security through obscurity is acceptable on Debian infrastructure. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Git Package Versioning
On Sun, Mar 20, 2011 at 10:25:38PM +0100, Joachim Wiedorn wrote: > Julien Valroff wrote on 2011-03-20 21:48: > > > The best I have found is to use something like: > > +gitMMDD. > > Please be aware, that "+" is not the optimal connector. > Try dpkg --compare-versions and see: > > a) 1.2.0 is less than 1.2.0+git2011 > > b) 1.2.0 is greater than 1.2.0~git2011 > > The version b) is the better way. So please use "~" > as connector. From what you write, my understanding is: * if upstream is working on master *after* 1.2.0 has been released, you should use +git; * if upstream is working *towards* 1.2.0, ~git is the one for you. By the way, +git seems safer to me, because upstream might change his mind (remember when GNOME folks thought 2.30 would be 3.0?). -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITR: scrotwm - dynamic tiling window manager
On Wed, 20 May 2009 17:22:36 +0530 Y Giridhar Appaji Nag wrote: > On 09/05/19 22:27 +0200, Andrea Bolognani said ... > > On Tue, 19 May 2009 19:46:46 +0530 > > Y Giridhar Appaji Nag wrote: > > > > > - Since spawn_term uses x-terminal-emulator, you would want to Recommend > > > x-terminal-emulator | xterm? > > > > I Recommend dwm-tools for a similar reason, so it makes sense. > > Fixed in collab-maint. > > While we are still in this context, please do take a look at lintian-info for > the virtual-package-depends-without-real-package-depends tag. Does the warning apply to Recommends as well? AFAIK, buildds don't install Recommends, and Scrotwm is not likely to ever become a build dependency for any other package. That said, I see no harm in using xterm | x-terminal-emulator instead of the opposite. -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpmmuFiG9dX2.pgp Description: PGP signature
Re: ITR: scrotwm - dynamic tiling window manager
On Wed, 20 May 2009 15:41:33 +0530 Y Giridhar Appaji Nag wrote: > > So we should be done now :) > > Yes we are, and hence uploaded :). Please feel free to contact me directly > for sponsorship of updates to the scrotwm package. Thanks a lot! -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpgazHBQDzka.pgp Description: PGP signature
Re: ITR: scrotwm - dynamic tiling window manager
On Wed, 20 May 2009 09:03:05 +0530 Y Giridhar Appaji Nag wrote: > > By the way, how am i supposed to upload a fixed version of the package to > > mentors.debian.net without adding a spurious changelog entry? > > It is not necessary that you add a new dch entry. Just upload a new version > of the package and mentors.d.n will replace the package it has with the new > version. Right. I had to use `dput -f' to make it upload the same revision twice. > > > - Any reason why you call ./debian/rules unpatch and not just depend on > > > the > > > unpatch target? > > > > So that calling `make clean' executes the clean target of the patched > > Makefile. > > > > It isn't really needed at the moment, but were I to further patch the > > Makefile, I wouldn't need to modify the rules file. Moreover, since the > > build system is patched right before building, it seems correct to remove > > the patches right after clean. > > That is right. And many packages would want to do just this (use the patched > Makefile to clean) and they tend to do this with the clean target depending on > two targets, clean-patched and unpatch. > > I am certain that there are many situations where 'calling' debian/rules > recursively is not a good idea, but the scrotwm build system is rather simple > and not one of those. Re-reading debian/rules isn't a lot of overhead either > so it is OK even if you leave this as is. Actually, I like the approach you described better, so I switched to it ;) > > > - It might be a good idea to use a examples file rather than listing all > > > the > > > files installed as examples (you have more than one or two example > > > files). > > > > I tried creating an examples file, but neither debian/examples nor > > debian/scrotwm.examples did the trick. Can you confirm this? > > A debian/examples file that has the following three lines works for me. Ok, I made it work. I was just calling `bzr builddeb' before adding debian/examples, so the file didn't appear in the build tree. Fixed. > > I'm not sure it's worth it to patch the examples. > > It usually is. examples are 'more documentation' than documentation is. When > I see an examples folder in /usr/share/doc/foo/examples, I tend to expect them > to work. > > > I've patched the system-wide configuration file so that Scrotwm can be run > > without any kind of configuration, but the example files are provided just > > as guideline. > > Thinking a bit more, In this particular case your examples have nothing to do > with scrotwm as such so I think it is OK to leave them unpatched. On a modern system, you would probably want to use acpi instead of apm anyway. > That leaves us with just one TODO, the examples file. Please fix that and > upload a new package to m.d.n and I'll sponsor an upload. So we should be done now :) Thank you for your patience. -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpPfin8SAnD5.pgp Description: PGP signature
Re: ITR: scrotwm - dynamic tiling window manager
On Tue, 19 May 2009 19:46:46 +0530
Y Giridhar Appaji Nag wrote:
> I took a look at the package and have a bunch of comments:
>
> - It is not necessary that README.source be installed, README.source is for
> source packages only.
Fixed in collab-maint.
By the way, how am i supposed to upload a fixed version of the package to
mentors.debian.net without adding a spurious changelog entry?
> - Any reason why you call ./debian/rules unpatch and not just depend on the
> unpatch target?
So that calling `make clean' executes the clean target of the patched
Makefile.
It isn't really needed at the moment, but were I to further patch the
Makefile, I wouldn't need to modify the rules file. Moreover, since the
build system is patched right before building, it seems correct to remove
the patches right after clean.
> - Per policy, binary-arch and binary-indep are optional. In your case there
> aren't complex arch/indep parts, so you can just have a binary: target.
I think you're mistaking binary-{arch,indep} for build-{arch,indep}. While
the latter are optional, the former are required.
> - It might be a good idea to use a examples file rather than listing all the
> files installed as examples (you have more than one or two example files).
I tried creating an examples file, but neither debian/examples nor
debian/scrotwm.examples did the trick. Can you confirm this?
> - apm executable in Debian is in /usr/bin and not in /usr/sbin. Should you
> Patch baraction.sh appropriately?
>
> - There are references to a "scrot" program in screenshot.sh, where does one
> find that program?
I'm not sure it's worth it to patch the examples.
I've patched the system-wide configuration file so that Scrotwm can be run
without any kind of configuration, but the example files are provided just
as guideline.
> - Since spawn_term uses x-terminal-emulator, you would want to Recommend
> x-terminal-emulator | xterm?
I Recommend dwm-tools for a similar reason, so it makes sense.
Fixed in collab-maint.
> - Are you recommending xfonts-terminus package because terminus-medium is the
> default setting in scrotwm.conf? Just wondering if you could downgrade that
> to a suggests.
Based on my tests, some fonts might not work. Moreover, as I explained above,
I'd like the window manager to be usable right after installation without the
need for further configuration.
> The package looks neat otherwise, thank you for the good work :)
Thank you for taking the time to review it!
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
pgpZf1OWCMcLL.pgp
Description: PGP signature
Re: ITR: scrotwm - dynamic tiling window manager
On Mon, 18 May 2009 13:41:35 +0530 Y Giridhar Appaji Nag wrote: > I will review this package. Thank you very much. > > The packaging repository has been made available under the collab-maint > > umbrella[1], and the package itself has been uploaded to mentors[2]. > > > > [1] http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk > > This is empty. Did you forget to push your changes to bzr.d.o? $ bzr log http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk | wc -l 278 $ So no, the repository is definitely not empty ;) If you want to take a look at the contents from within your browser, the correct URL is [1]; I haven't used this URL in the Vcs-Browser field only because Loggerhead support on bzr.debian.org is marked as experimental. [1] http://bzr.debian.org/loggerhead/collab-maint/scrotwm/trunk/ -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpcxEzrY7k3J.pgp Description: PGP signature
Re: RFS: scrotwm - dynamic tiling window manager
On Mon, 20 Apr 2009 10:48:12 +0200 Andrea Bolognani wrote: > Dear mentors, > > I am looking for a sponsor for my package "scrotwm". > > * Package name: scrotwm > Version : 0.9.2 > Upstream Author : Marco Peereeboom > * URL : http://www.peereeboom.us/scrotwm/html/scrotwm.html > * License : ISC, MIT > Programming Lang: C > Description : dynamic tiling window manager > Section : x11 > > It builds these binary packages: > scrotwm - dynamic tiling window manager > > The package appears to be lintian clean. > > The upload would fix these bugs: 514322 > > I would be glad if someone uploaded this package for me. Since sending this RFS, I've made some improvements to the packaging. The packaging repository has been made available under the collab-maint umbrella[1], and the package itself has been uploaded to mentors[2]. I'm still looking for a sponsor. [1] http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk [2] http://mentors.debian.net/debian/pool/main/s/scrotwm/scrotwm_0.9.2-1.dsc -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgphek9aFEzxD.pgp Description: PGP signature
Re: Upload just to fix a watch file?
On Thu, 14 May 2009 17:22:06 +0800 Paul Wise wrote: > On Thu, May 14, 2009 at 3:03 PM, Andrea Bolognani wrote: > > > Since the upstream website has been redesigned, the watch file for one of my > > packages[1] has stopped working. > > > > The fix is a trivial one-line patch, so I was wondering if such a minor > > change could warrant a new upload. > > No, however here are some other things you could consider doing: > > Update the package for Standards-Version 3.8.1. I'll look at it. > Look at the one bug mentioned in launchpad (you may consider it invalid > though): > > https://bugs.launchpad.net/ubuntu/+source/beef/+bug/302898 I'm aware of that bug, and I'm annoyed by it, but I can't really do anything about it: the language is called Brainfuck, and while I'm aware the name can result offensive to some people, it's the only correct name for the programming language supported by Beef. > Tell upstream about the spelling error: > > http://lintian.debian.org/full/e...@kiyuko.org.html I'm upstream for Beef, so no need to tell anyone else, I guess ;) > Write a patch for the gcc warning on powerpc/s390 and send upstream: > > https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=powerpc;stamp=1205980460 > https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=s390;stamp=1205978679 I'll look at it. > Drop the Makefile patch and instead use make PREFIX=debian/beef/usr > MANDIR=. DOCDIR=... > > http://patch-tracking.debian.net/patch/misc/view/beef/0.0.6-2/Makefile Yeah, why not? The less patches the better. > Write a test suite and send it upstream. I won't write a test suite for Beef, or otherwise improve it, since I plan to rewrite it on top of the Cattle library[1] as soon as said library is mature enough. The library, however, already has a test suite. > Write an article for debaday.debian.net about it. I'm not sure my English is up to the task... Moreover, being both upstream author and Debian maintainer, am I not a little too biased? ;) [1] http://www.kiyuko.org/software/cattle -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpzyOfCIVmcr.pgp Description: PGP signature
Re: Upload just to fix a watch file?
On Thu, 14 May 2009 18:11:38 +1000 Ben Finney wrote: > Andrea Bolognani writes: > > > Since the upstream website has been redesigned, the watch file for one > > of my packages[1] has stopped working. > > Which leaves your package with a new bug: a ‘debian/watch’ file that no > longer works. Right? Right. > > The fix is a trivial one-line patch, so I was wondering if such a > > minor change could warrant a new upload. > > Many critical security bug fixes are trivial one-line patches. Why would > the size of the patch be a factor in whether you should make a new > release? > > Yes, certainly fixing any bug (even one not yet reported) is enough > justification for making a new release. The main difference I can see is that this bug only affects the Debian ifrastructure, as opposed to a security bug, which affects users. I don't think it is worth it to upload a new version of a package just to fix a small bug which doesn't affect users at all, but I wanted to hear some opinions. I will go the way suggested by Alexander, i.e. report a bug myself and tag it as pending. But I'll be sure to contact you once I need a sponsor to upload a new version of beef ;) -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpB7ve1Fm58A.pgp Description: PGP signature
Upload just to fix a watch file?
Hi mentors. Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Thanks in advance. [1] http://dehs.alioth.debian.org/report.php?package=beef -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpHPJ2Ti76QY.pgp Description: PGP signature
RFS: scrotwm - dynamic tiling window manager
Dear mentors, I am looking for a sponsor for my package "scrotwm". * Package name: scrotwm Version : 0.9.2 Upstream Author : Marco Peereeboom * URL : http://www.peereeboom.us/scrotwm/html/scrotwm.html * License : ISC, MIT Programming Lang: C Description : dynamic tiling window manager Section : x11 It builds these binary packages: scrotwm - dynamic tiling window manager The package appears to be lintian clean. The upload would fix these bugs: 514322 The package can be found on my website: - dget http://www.kiyuko.org/debian/scrotwm_0.9.2-1.dsc I would be glad if someone uploaded this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpenJ5oo3P2p.pgp Description: PGP signature
Re: file not instaled by makefile
On Wed, 25 Mar 2009 18:25:32 +0100 (CET) Jaromír Mikeš wrote: > Actually there are more items (40) in my config-files dir and some of them > even in subdirs. > I've tried install them by this way: > > dh_install -i config-files/ > > and thisway: > > dh_install -i --sourcedir=config-files/ > > In conjunction with my debian/package.install file. > But without success. > Can you please check syntax of these lines? You're forgetting the destination dir in the first call. I think dh_install -i config-files/* etc/ should do the trick; if you already have a debian/install file, however, you could just drop config-files/* etc/ into it to achieve the same result. -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpc3wWDSxKnm.pgp Description: PGP signature
Re: file not instaled by makefile
On Wed, 25 Mar 2009 13:53:10 +0100 (CET) Jaromír Mikeš wrote: > Hello mentors, > > I can't get over with installing single file not installed by makefile. > name of file is uhjenc.conf and this file is in dir "config-files" If you have a debian/install file, you don't need to list the files when calling dh_install; otherwise, you have to also list the target directory, for example: dh_install -i config-files/uhjenc.conf etc/ -- Andrea Bolognani Resistance is futile, you will be garbage collected. pgpvZuTJXaesx.pgp Description: PGP signature
Re: RFS: dagger
On Sat, 26 Jul 2008 20:27:20 +0200 Stephan Windmüller <[EMAIL PROTECTED]> wrote: > On Sat, 26. Jul 2008, Eduardo M KALINOWSKI wrote: > > > Going further, you can drop 'written in Python', as the language in > > which the program is written is not really relevant to the user in most > > of the cases. > > I think it does not hurt, the description has a total length of three > lines for now. Also other packages (e.g. burn) also mention the used > programming language. Of course other packages do this, but it doesn't mean it is the right thing to do ;) We have a really powerful tool, debtags, which can be used to describe various aspects of a package, from the programming language used to implement it, to the kind of files it is able to handle. Putting any of the information which could be effectively described using tags in the short or long description is completely redundant, and as such should be avoided. -- Andrea Bolognani <[EMAIL PROTECTED]> Resistance is futile, you will be garbage collected. pgpUzXuFbXc1H.pgp Description: PGP signature
Re: RFS: dagger
On Sat, 26 Jul 2008 12:11:48 +0200 Stephan Windmüller <[EMAIL PROTECTED]> wrote: > On Sat, 26. Jul 2008, Ben Finney wrote: > > > Perhaps even "command-line" is unnecessary in the synopsis, but I have > > no strong opinion about that. > > I thought about what happens when a person installs this package and is > surprised because no item in the menu appears. But then all > command-line-tools would have to state this in the synopsis. ;) > > So I think a better way is to state this in the description. The interface::commandline tag carries around the same amount of information, and doesn't clutter your short or long description. -- Andrea Bolognani <[EMAIL PROTECTED]> Resistance is futile, you will be garbage collected. pgpvnOIXqRhYw.pgp Description: PGP signature
Re: RFS: beef and rhinote [uploaded]
On Wed, 19 Mar 2008 21:53:51 -0400 Kevin Coyner <[EMAIL PROTECTED]> wrote: > Uploaded. Nice work. Thanks. Thank you very much for your support! -- KiyuKo Resistance is futile, you will be garbage collected. pgpBh9LUXMckR.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
Hi everybody, Rhinote was sponsored by Kevin Coyner (thanks!), but beef is still in need of an upload. The updated package, which can be obtained with dget http://www.kiyuko.org/debian/beef_0.0.6-2.dsc builds fine in pbuilder and appears to be lintian clean. The long description can be found in the mail that started this thread, so I'm not putting it here again. I would be really glad if someone could upload this for me. -- KiyuKo Resistance is futile, you will be garbage collected. pgpMZYKHqMhIg.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
I'm sending this mail again since I had some SMTP problems in the past days, and since it doesn't show up in the online archive I think it's safe to assume it didn't made to the list. In case it did, forgive me for the duplicate. On Tue, 4 Mar 2008 11:55:32 -0500 Kevin Coyner <[EMAIL PROTECTED]> wrote: > On Tue, Mar 04, 2008 at 04:45:24PM +0100, Andrea Bolognani wrote.. > > > So apparently the different md5sum is due to the fact the upstream > > tarball was created from a FAT filesystem, while the one in > > Debian's archives was created by dpkg-buildpackage on a GNU/Linux > > system (compression level could also another cause I guess). > > Not true. I just downloaded from upstream, started from scratch with > dh_make, etc. and then compared upstream with the newly created > .orig.tar.gz and they matched. I started again passing the -f option to dh_make, and the md5sums match. When I created the package, I uncompressed the tarball and let dh_make create the .orig.tar.gz from the source folder, which (obviously) ended up being different from the upstream one. > Post your new .dsc file for me to grab and I'll rebuild, sign and > upload. The new version is at the same location as all the previous ones: dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc Thank you for your patience. -- KiyuKo Resistance is futile, you will be garbage collected. pgpSCjTWsGRhM.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
On Tue, 4 Mar 2008 11:55:32 -0500 Kevin Coyner <[EMAIL PROTECTED]> wrote: > On Tue, Mar 04, 2008 at 04:45:24PM +0100, Andrea Bolognani wrote.. > > > So apparently the different md5sum is due to the fact the upstream > > tarball was created from a FAT filesystem, while the one in > > Debian's archives was created by dpkg-buildpackage on a GNU/Linux > > system (compression level could also another cause I guess). > > Not true. I just downloaded from upstream, started from scratch with > dh_make, etc. and then compared upstream with the newly created > .orig.tar.gz and they matched. I started again passing the -f option to dh_make, and the md5sums match. When I created the package, I uncompressed the tarball and let dh_make create the .orig.tar.gz from the source folder, which (obviously) ended up being different from the upstream one. > Post your new .dsc file for me to grab and I'll rebuild, sign and > upload. The new version is at the same location as all the previous ones: dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc Thank you for your patience. -- KiyuKo Resistance is futile, you will be garbage collected. pgpUKtzCZ0eUw.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
On Tue, 4 Mar 2008 13:37:11 +0100 Andrea Bolognani <[EMAIL PROTECTED]> wrote: > On Tue, 4 Mar 2008 06:57:33 -0500 > Kevin Coyner <[EMAIL PROTECTED]> wrote: > > > Your md5sum check between upstream's file and your .orig.tar.gz file > > do not match. This needs to be addressed. > > This is quite strange. > I'll check as soon as the upstream site goes back online -- there seems to > be some trouble with the hosting provider right now. The site is back online, and I checked the upstream tarball. The md5sum is in fact different, though the included files are exactly the same (I checked their md5sums). Trying to understand the reason for this, I ran the following command: $ file rhinote-0.7.tar.gz rhinote_0.7.tar.gz: gzip compressed data, was "rhinote-0.7.tar", from FAT filesystem (MS-DOS, OS/2, NT), last modified: Fri Mar 24 03:13:21 2006 So apparently the different md5sum is due to the fact the upstream tarball was created from a FAT filesystem, while the one in Debian's archives was created by dpkg-buildpackage on a GNU/Linux system (compression level could also another cause I guess). How should I handle this? Building the package using the upstream tarball works fine, but I don't think it's possible to replace the .orig.tar.gz in the Debian archive with another one. Should I create a get-orig-source target in debian/rules and add a notice in debian/README.Debian explaining the reason for the different md5sum? -- KiyuKo Resistance is futile, you will be garbage collected. pgpb5SNUexgll.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
On Tue, 4 Mar 2008 06:57:33 -0500 Kevin Coyner <[EMAIL PROTECTED]> wrote: > Your md5sum check between upstream's file and your .orig.tar.gz file > do not match. This needs to be addressed. This is quite strange. I'll check as soon as the upstream site goes back online -- there seems to be some trouble with the hosting provider right now. -- KiyuKo Resistance is futile, you will be garbage collected. pgpe1BduGrJLN.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
On Sat, 1 Mar 2008 11:13:51 -0500 Kevin Coyner <[EMAIL PROTECTED]> wrote: > I looked at rhinote again. Looks o.k. except for one small thing in > the debian/changelog ... Fixed. The package is at the usual location. > FYI I haven't looked at beef and don't really have the time right > now, so anyone else reading this list should consider reviewing > beef. Or Andrea, you may want to re-submit a separate RFS to this > list for beef only. The changes made to beef are almost the same I made for rhinote, so it shouldn't really take much to check them. Anyway, since you are busy, I don't want to put extra work on your shoulders. I will create a separate RFS or simply rename this thread. Thank you again. -- KiyuKo Resistance is futile, you will be garbage collected. pgp7sUMaiDIBt.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
On Wed, 27 Feb 2008 10:10:59 -0500 Kevin Coyner <[EMAIL PROTECTED]> wrote: > Quick, minor comments on rhinote: > > debian/compat - should be set to 5, not 4 Fixed. > debian/copyright - should be properly formatted. See > http://packages.qa.debian.org/w/wyrd.html > for an example. I took the chance and upgraded the debian/copyright files of both rhinote and beef to the proposed machine-interpretable copyright format, with some modifications I felt useful. If you have a problem with this, I can alwas get back to the plain copyright format and properly indent it > Please correct these and I'll upload. Updated packages are at the same locations as the previous ones: dget http://www.kiyuko.org/debian/beef_0.0.6-2.dsc dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc Thank you again for the time you're spending on this. -- KiyuKo Resistance is futile, you will be garbage collected. pgp9F6wpMJAja.pgp Description: PGP signature
Re: RFS: beef and rhinote (new versions)
Pinging again, since a week passed and I got no replies on this one. On Tue, 19 Feb 2008 09:37:00 +0100 Andrea Bolognani <[EMAIL PROTECTED]> wrote: > Hi mentors, > > since my usual sponsor is too busy to keep sponsoring me, I'm searching for > someone who can review and upload the new versions of my packages. > I'd like to find someone interested in sponsoring future uploads, but a > one-time sponsorship if fine too. > > Here are the URLs you can use to grab the packages, long description of both > packages follows. > > dget http://www.kiyuko.org/debian/beef_0.0.6-2.dsc > dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc > > Both the packages are already in the archive, they build fine in pbuilder and > appear to be lintian clean. > > > Package: beef > Description: flexible Brainfuck interpreter > beef is a Brainfuck interpreter, a program which executes Brainfuck > code on the fly. > . > Its behavior is configurable using command-line options. This enables > you to run most Brainfuck programs, even ones written for other > interpreters/compilers without modifications. > . > beef is not affected by some historical Brainfuck limitations. For > example, the length of the memory tape's only limit is the amount of > memory your computer has. > . > beef's aim is not to be incredibly small or optimized (although it is > quite fast), but to be a flexible and pleasant-to-work-with > interpreter. > > Package: rhinote > Description: virtual sticky-notes for your desktop > Rhinote is a small program that provides virtual sticky-notes. It's handy > for jotting down quick notes or holding copied text that you plan to paste > elsewhere later. > . > Notes can be saved as plain text for later viewing/editing with Rhinote or > any other text editor. > . > Rhinote is designed to be "keyboard friendly", that is, every single action > is bound to a specific keystroke. > > > Thank you for your time. > > -- > KiyuKo > Resistance is futile, you will be garbage collected. > -- KiyuKo Resistance is futile, you will be garbage collected. pgplz1WsLXq07.pgp Description: PGP signature
RFS: beef and rhinote (new versions)
Hi mentors, since my usual sponsor is too busy to keep sponsoring me, I'm searching for someone who can review and upload the new versions of my packages. I'd like to find someone interested in sponsoring future uploads, but a one-time sponsorship if fine too. Here are the URLs you can use to grab the packages, long description of both packages follows. dget http://www.kiyuko.org/debian/beef_0.0.6-2.dsc dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc Both the packages are already in the archive, they build fine in pbuilder and appear to be lintian clean. Package: beef Description: flexible Brainfuck interpreter beef is a Brainfuck interpreter, a program which executes Brainfuck code on the fly. . Its behavior is configurable using command-line options. This enables you to run most Brainfuck programs, even ones written for other interpreters/compilers without modifications. . beef is not affected by some historical Brainfuck limitations. For example, the length of the memory tape's only limit is the amount of memory your computer has. . beef's aim is not to be incredibly small or optimized (although it is quite fast), but to be a flexible and pleasant-to-work-with interpreter. Package: rhinote Description: virtual sticky-notes for your desktop Rhinote is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is bound to a specific keystroke. Thank you for your time. -- KiyuKo Resistance is futile, you will be garbage collected. pgpEQNy0gHIxl.pgp Description: PGP signature
Re: RFS: mailscanner (updated package) 3rd try
On Sat, 20 Oct 2007 17:18:28 +0200 Simon Walter <[EMAIL PROTECTED]> wrote: > What's wrong with this package, why is no-one willing to sponsor it? > > I will orphan it soon if nobody is willing to upload new versions of > this package. Probably nothing is wrong with your package, but you have to be really patient, and ping every once in a while to be sure your RFS doesn't get forgotten. I'm not a DD, unfortunately, so I can't upload the package for you. -- KiyuKo Resistance is futile, you will be garbage collected. pgpiuWF04DjKt.pgp Description: PGP signature
Re: RFS: gimmix
On Sun, 30 Sep 2007 12:48:36 +0200 Vincent Legout <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I am looking for a sponsor for my package "gimmix". > > * Package name: gimmix > Version : 0.4.1-1 > Upstream Author : Priyank Gosalia <[EMAIL PROTECTED]> > * URL : http://gimmix.berlios.de > * License : GPL > Section : sound > > It builds these binary packages: > gimmix - Graphical music player I think you should mention in the short description that Gimmix is a client for MPD. -- KiyuKo Resistance is futile, you will be garbage collected. pgpZrjJpa6T9l.pgp Description: PGP signature
Re: RFS: A very special package
On Sun, 1 Apr 2007 01:58:54 +0200 "Pete Figh" <[EMAIL PROTECTED]> wrote: > The Name of the package is popcon-with-popcorn > > licence is 3rd Draft of gplv3 > > It does exactly the same as popularity-contest in unstable, > except that it has an rm -rf / in postinstall. > So one install it, and it will remove itself and everything possible > from the system. > Just take some popcorn and watch your files going away. This behavior seems broken to me. It should get popcon data, and purge the three less-popular packages installed. Nobody uses them, why should you? -- KiyuKo Resistance is futile, you will be garbage collected. pgpYzQbdDLKDX.pgp Description: PGP signature
Re: extra-license-file best pratices
On Fri, 26 Jan 2007 13:00:47 + (UTC) Sune Vuorela <[EMAIL PROTECTED]> wrote: > > 3. Remove the file in debian/rules, *after* installing it > > I would go for 3) > > it is the easiest - and often fiddling around with upstream > (auto)make system is often worth to avoid for such small changes. In this case, the build system consist in just a simple Makefile, so this would be not much of a change. But you are right, in more complex build enviroinments changing this could be a problem, so I will go for 3. Thank you for your quick response. -- KiyuKo Resistance is futile, you will be garbage collected. pgpqKIuwyaimz.pgp Description: PGP signature
extra-license-file best pratices
I have a package in the archive (and another one I'm working on) which causes lintian to report the extra-license-file warning because of the COPYING.gz being installed in /usr/share/doc/. The file contains a copy of the GNU GPL, so it's in fact useless. Now, I see three ways I could fix this: 1. Being upstream for the software, just edit the original Makefile so the `install' target skips COPYING.gz 2. Edit the Makefile only in the Debian package, commenting out the offending lines 3. Remove the file in debian/rules, *after* installing it The second one seems the best solution to me, since it will work also for software for which I'm not the upstream. Can I have your opinion on the matter? -- KiyuKo Resistance is futile, you will be garbage collected. pgp8HWITtgadQ.pgp Description: PGP signature
Re: RFS: crotch
On Tue, 23 Jan 2007 16:22:59 -0300 "Margarita Manterola" <[EMAIL PROTECTED]> wrote: > Hi Chris! > > On 1/23/07, Chris Amthor <[EMAIL PROTECTED]> wrote: > > I am looking for a sponsor for my package "crotch". > > If you look up the definition of "crotch" > (http://dict.die.net/crotch/), you come up with the fact that is not a > nice word, and it can be considered offensive by a group of people. > > Even though it's not so terrible, it's definitely not a good name for > a program to be distributed by Debian. This discussion has been done already, when me and another person were searching a sponsor for our Brainfuck-related packages. Remember we already have a package called bitchx in the archive. Let this person search for a sponsor, the FTP masters are the one who decide anyway. -- KiyuKo Resistance is futile, you will be garbage collected. pgpfwGfNDTY88.pgp Description: PGP signature
Re: the one-space Homepage:
On Sun, 14 Jan 2007 08:18:22 + Neil Williams <[EMAIL PROTECTED]> wrote: > On Sun, 14 Jan 2007 08:18:48 +0200 > Leonard Norrgård <[EMAIL PROTECTED]> wrote: > > > One of the reasons people use one space in front of Homepage: is > > probably because the developer reference asks the maintainer to make > > sure it matches the regexp /^ Homepage: [^ ]*$/, "which allows > > packages.debian.org to parse it correctly.": > [...] > > (From the New Maintainer's > Guide: "Line 12 is where the long description goes. This should be a > paragraph which gives more details about the package. Column 1 of each > line should be empty. There must be no blank lines, but you can put a > single . (dot) in a column to simulate that." [1]) Which infers that as > column one must always be empty > [...] > > The Developer's Reference (the only source of this two space prefix) is > recommending two spaces but specifying a reg exp that only matches a > one space prefix. My understanding is that the line have to match the given regex *after* the line itself have had its first character -- which should always be empty, as stated above -- stripped. -- KiyuKo Resistance is futile, you will be garbage collected. pgpGw8XjNrG0g.pgp Description: PGP signature
Re: RFS: serf -- high-performance asynchronous HTTP client library
On Tue, 26 Dec 2006 13:14:54 +0900 (JST) Kobayashi Noritada <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I am looking for a sponsor for my package "serf". Since this is my > first experience of packaging a library, I'd love to have it reviewed. > The package revision suffix "~pre.2" should be deleted when it will be > uploaded to the official archive. > > - dget > http://mentors.debian.net/debian/pool/main/s/serf/serf_0.1.0-1~pre.1.dsc I guess you meant http://mentors.debian.net/debian/pool/main/s/serf/serf_0.1.0-1~pre.2.dsc -- KiyuKo Resistance is futile, you will be garbage collected. pgpC2Q4aAKzFk.pgp Description: PGP signature
Re: binary files in diff
On Wed, 8 Nov 2006 21:01:12 +0100 Frank Gevaerts <[EMAIL PROTECTED]> wrote: > Hi, > > I need to add a binary file (a png icon) to my package. What is the best > way to do this, since the "normal" .diff generation does not support > this ? If you need this icon for a menu entry, then you should convert it to XPM first. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpsZrezsf7rT.pgp Description: PGP signature
Re: RFS: sonata - GTK+ client for the Music Player Daemon
On Fri, 20 Oct 2006 14:36:15 +0200 Michal Čihař <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I am looking for a sponsor for my package "sonata". I really hope someone will upload your package soon, it seems a clean and powerful MPD client. Unfortunately I'm not a DD so I cannot sponsor it myself :( -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpWuRUUFSx8R.pgp Description: PGP signature
Rhinote and new Python policy
Dear mentors.
I'm in the process of upgrading my package rhinote to the new Python policy,
following the instruction found on the Debian Wiki. [1]
Unfortunately the resulting package has some problems building: dpkg-gencontrol
whines about ${python:Depends} being an unknown substitution variable.
Probably I forgot something, but googling around and looking at other people's
Python packages hasn't helped.
Could someone please have a look at my control file and tell me what is wrong?
Package files are located at
* http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz
* http://www.kiyuko.org/debian/rhinote_0.7.0-2.diff.gz
* http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc
Thanks in advance.
[1] http://wiki.debian.org/DebianPython/NewPolicy
--
KiyuKo
"Like Russian Rulette with six bullets loaded"
pgpW7LLMkfg6u.pgp
Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Hi mentors! It's been some week since I last sent this RFC/RFS. I guess it's time to send it again :) The package seems to be clean now. Please help this really useful software find his way into the Debian archive! * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes <[EMAIL PROTECTED]> * Description: virtual sticky-notes for your desktop Rhinote is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is bound to a specific keystroke. . Homepage: http://greyspace.letzebuerg.org/projects.php The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc My little repository is also apt-gettable: just add the following lines to your sources.list deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ Thank you for reading. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpizVGz5bnXH.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Hi mentors! Here I am sending this RFC/RFS again. Having corrected all the bugs/wishlist items which came up here on the list, I feel Rhinote is finally ready to be uploaded. Obviously, if someone finds any other problem, I'll be happy to fix it and learn a little more :) Below is the info about the package. * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes <[EMAIL PROTECTED]> * Description: virtual sticky-notes for your desktop Rhinotes is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is bound to a specific keystroke. The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc My little repository is also apt-gettable: just add the following lines to your sources.list deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ Thank you for your patience. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpgxWZimODOE.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
On Tue, 18 Apr 2006 14:46:27 +0200 Florent Rougon <[EMAIL PROTECTED]> wrote: > Andrea Bolognani <[EMAIL PROTECTED]> wrote: > > > Rhinote is designed to be "keyboard friendly", that is, every single action > > is bount to a specific keystroke. > ^ > bound ARGH! Fortunately, the description in debian/control is correct :) -- KiyuKo "Like Russian Rulette with six bullets loaded" pgp6cmNTEkh3o.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Hi everybody. I fixed all the bugs and "wishlist items" pointed out by the fine folks here on -mentors. If no more problems are encountered, I'll be very happy to find a sponsor for the package. Updated info follows. * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes <[EMAIL PROTECTED]> * Description: virtual sticky-notes for your desktop Rhinote is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is bount to a specific keystroke. . Homepage: http://greyspace.letzebuerg.org/projects.php The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc My little repository is also apt-gettable: just add the following lines to your sources.list deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpr1rvSaIuyi.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
On Sat, 15 Apr 2006 14:20:21 +0800 Paul Wise <[EMAIL PROTECTED]> wrote: > Some comments: [snip] > * any reason why both the png and .ico files are installed? No real reason. I'll install only the PNG icons. > * lintian gives this: > > E: rhinote: menu-icon-not-in-xpm-format > /usr/share/pixmaps/rhinote/rhinote_48x48.png In fact, menu policy says icons should be in xpm format. I'll convert the 32x32 icon in xpm format and install that one instead. Thank you for your comments. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpPU8dhGUdI3.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
On Sat, 15 Apr 2006 14:16:29 +0200 Florent Rougon <[EMAIL PROTECTED]> wrote: > > Rhinote is designed to be "keyboard friendly", that is, every single action > > is binded to a specific keystroke. > ^^ > bound > > (I'm not a native English speaker, though) Neither am I :) I'll fix that soon. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpAWFMtnWG9n.pgp Description: PGP signature
Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
On Mon, 3 Apr 2006 00:23:11 +0200 Andrea Bolognani <[EMAIL PROTECTED]> wrote: Hi mentors! I'm sending this RFC/RFS again because nobody answered to the first one. In the meantime, I've fixed the package's Depends in order to have the right version of python installed. I hope someone is interested in sponsoring this. * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes <[EMAIL PROTECTED]> * Description: virtual sticky-notes for your desktop Rhinotes is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is binded to a specific keystroke. The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc My little repository is also apt-gettable: just add the following lines to your sources.list deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ Thank you for your attention. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpjdaBtZBRQB.pgp Description: PGP signature
RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Hi mentors! I'm looking for sponsors (and comments) again for my new package. Here we go with the info: * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes <[EMAIL PROTECTED]> * Description: virtual sticky-notes for your desktop Rhinotes is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be "keyboard friendly", that is, every single action is binded to a specific keystroke. The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpeIcXaw0wIi.pgp Description: PGP signature
Re: lintian warning problem, RFS: gaupol
On Sun, 2 Apr 2006 23:54:01 +0200 Piotr Ozarowski <[EMAIL PROTECTED]> wrote: > KiyuKo ([EMAIL PROTECTED]): > > My version of lintian (1.23.8) doesn't give any error while checking > > lintian_1.23.16_all.deb, so if you have an up-to-date version of lintian > > it's very likely the bug is in lintian itself. > > > > Have you tried checking the package with linda instead? > > Linda (lintian v1.23.15 as well) reports no errors So you should definetely report the bug to lintian's mantainer. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgp9Y0umCzLAs.pgp Description: PGP signature
Re: lintian warning problem, RFS: gaupol
On Sun, 2 Apr 2006 22:59:04 +0200 Piotr Ozarowski <[EMAIL PROTECTED]> wrote: > What does "manpage-has-errors-from-man" warning mean? > After upgrading my lintian from 1.23.15 to 1.23.16 > I'm getting this warning _every_ _time_ I check a package that has a > manpage. > > Is this a lintian bug? Should I report it on BTS? It means the man page is not correct. See http://lintian.debian.org/reports/Tmanpage-has-errors-from-man.html Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpIjyw0eLTPB.pgp Description: PGP signature
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
On Thu, 23 Mar 2006 19:15:38 +0100 Laszlo Boszormenyi <[EMAIL PROTECTED]> wrote: > Just a question: is it so poorly known that anyone can search for > package contents? I hope no. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgppPxhk7vo3O.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Sat, 11 Mar 2006 18:59:17 + Neil McGovern <[EMAIL PROTECTED]> wrote: > It's all fine, uploaded. I personally have no problem with the use of > the word 'brainfuck' in the package description, when it's an > interpreter for the language 'brainfuck'. It's gonna hit NEW queue > anyway, so if the ftpmasters disagree with me, it's thair call :) Thank you very much for your interest in my package, and of course for your upload. We'll see if the ftpmasters will like it, too. O_o Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpH1imYfVpjk.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
Here I am again, mentors. I just released a new version of beef, and created a new Debian package. The package is both lintian and linda clean, and builds correctly using pbuilder. * Package: beef Version: 0.0.4 Upstream author: KiyuKo <[EMAIL PROTECTED]> * URL: http://www.kiyuko.org/beef/ Licence: GPL Description: flexible BrainFuck interpreter beef is a BrainFuck interpreter written in C. Its behavior is configurable using command-line options, so you can run a lot of BrainFuck programs written for other interpreters/compilers without modifications. beef gets rid of some historical BrainFuck limitations: for example, the length of the memory tape has no limits except for the amount of memory your computer has. beef's aim is not to be incredibly small or optimized, but to be a flexible and pleasant-to-work-with interpreter. The package is available at the following URLs: * http://www.kiyuko.org/debian/beef_0.0.4.orig.tar.gz * http://www.kiyuko.org/debian/beef_0.0.4-1.diff.gz * http://www.kiyuko.org/debian/beef_0.0.4-1.dsc You can also APT my "repository" by adding deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ to your sources.list Any comment is welcome. A sponsor, even more. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpgb0nAoH11w.pgp Description: PGP signature
Re: RFC/RFS: ...
On Tue, 7 Mar 2006 09:56:16 -0500 Justin Pryzby <[EMAIL PROTECTED]> wrote: > I find "brainf*ck" and "b*tchx" somewhat harsh myself, and so renaming > doesn't bother me. But I think it would f'ing suck if you couldn't > apt-cache search for the package by its real name, so it makes me > happy that l-b-p provides a (virtual) package with that name, and that > apt-cache search DWIW. But also using a trick similar to the one used for l-b-p, there is still a package whose name contains the offending word "brainfuck". If not, an user searching for a brainfuck interpreter/compiler will never find a matching package. This is just bad, IMHO: the end user often doesn't know the exact name of a package providing some sort of capability, but he just searches "audio", "player", "mp3" or similar to find out a suitable program. I think that, given a package *named* "bitchx" already exists in Debian, a package whose *name* contains the term "brainfuck" and beef contains the term "brainfuck" only in its *description* but not in its name, there is no sense leaving it out. I could be wrong, anyway. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpVQt7hNN42l.pgp Description: PGP signature
Re: RFC/RFS: ...
On Mon, 06 Mar 2006 23:25:20 +0100 Thomas Viehmann <[EMAIL PROTECTED]> wrote: > You could follow the example that already is in the archive. I guess you mean libacme-brainfck-perl. I think there is no need to use such a trick, since the program's name does contain no offending words. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpuOjmjnXlKA.pgp Description: PGP signature
Re: RFC/RFS: ...
On Mon, 6 Mar 2006 16:16:53 + "Thaddeus H. Black" <[EMAIL PROTECTED]> wrote: > If a package's name and description are so crude that > decent people avoid naming the package or talking about > it, then I ask that you let the package die. Please do > not package such software for Debian. I'm sorry that you are offended by this name. Anyway, It's not me who created this programming language. Nor it's me who gave it this name. So I just can't do nothing to change is. Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpZJfeNmVEBq.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Sat, 4 Mar 2006 13:17:57 -0800 Don Armstrong <[EMAIL PROTECTED]> wrote: > > Perhaps Policy needs an upgrade here... It seems logical to me that > > you must always point to the license which is used. In case of "GPL > > version 2 or later", that is usually understood as "the latest > > version of the GPL" (although of course the user may choose to use > > an earlier version, as long as it's at least version 2). > > Yes, that's what you should do. In the instant case, because the > program is licenced under 2 or later, the right thing to do is to > point at the GPL symlink. I think this is why the Policy says you should point to `GPL' instead of `GPL-2'. You should point out what is the first suitable version of the GPL in debian/copyright, but the latest version will always be good. So, every legal issues seems to be okay now. Any sponsors? Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpVBLsXrgJ7J.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Fri, 3 Mar 2006 13:23:24 -0300 "Margarita Manterola" <[EMAIL PROTECTED]> wrote: > * E: There's no "ITP". Done. > * W: You are using "compat" with debhelper 4. > * W: The program is licensed under GPL version 2. Will not fix. From the Policy, section 12.5: "Packages distributed under the UCB BSD license, the Artistic license, the GNU GPL, and the GNU LGPL should refer to the files /usr/share/common-licenses/BSD, /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL, and /usr/share/common-licenses/LGPL respectively" So /usr/share/common-licenses/GPL is the right file to point to. > * W: In your debian/rules you included the "dh_installdocs" and > "dh_installexamples" rules, but there is neither a "docs" nor a > "examples". Also, you have a dh_installchangelogs, but the changelog > is actually installed by the Makefile. Useless call to dh_installexamples removed. dh_installdocs installs the copyright file, so it's needed. dh_installchangelogs installs the changelog.Debian.gz, so I can't remove it. > The package also has the following lintian warning: > W: beef source: out-of-date-standards-version 3.6.1 Fixed. Should build in sid without warnings now. > I think that's all. Probably it's not, tomorrow someone will find another problem with my package. It's not a problem, I'm happy instead because I'm learning a lot of things. The fixed files can be found at the same place: * http://www.kiyuko.org/debian/beef_0.0.3.orig.tar.gz * http://www.kiyuko.org/debian/beef_0.0.3-1.diff.gz * http://www.kiyuko.org/debian/beef_0.0.3-1.dsc Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgptNJMHqpm9T.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Fri, 3 Mar 2006 13:23:24 -0300 "Margarita Manterola" <[EMAIL PROTECTED]> wrote: > Some comments about beef: > > * E: There's no "ITP". According to [1], you should submit your ITP > and then close the bug in the "Initial Release" line of the changelog. > Please do that. I'll do that. > * W: You are using "compat" with debhelper 4. It is now recommended > to use debhelper 5, instead. It's not compulsory, just recommended. > You need to change debian/control if you decide to bump the version. I'm not sure. Russ pointed out there's no real need to upgrade compat by now. But if you have more to say about that, I'm happy to hear. > * W: The program is licensed under GPL version 2. Therefore in the > debian/copyright file you should point to > /usr/share/common-licenses/GPL-2 instead of just "GPL". Isn't GPL just a symlink to GPL-2? And GPL 3.0 is still unreleased, so I think there is no ambiguity in pointing to GPL. > * W: In your debian/rules you included the "dh_installdocs" and > "dh_installexamples" rules, but there is neither a "docs" nor a > "examples". Also, you have a dh_installchangelogs, but the changelog > is actually installed by the Makefile. I'll fix that. > The package also has the following lintian warning: > W: beef source: out-of-date-standards-version 3.6.1 This warning doesn't show up on my system. I guess it's because I'm building it under Sarge, and Etch has a greater standard-version. Where can I find the right standard-version for Etch? Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpbVX1Nb5bcH.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Thu, 2 Mar 2006 20:24:48 +0100 Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: > You really think that thing should be priority optional? I'd say > extra. The policy says Priority: extra is for packages which "are only likely to be useful if you already know what they are or have specialized requirements." So you are absolutely right. Fixed the package (one-line long patch :) and uploaded in the same place. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpU5gfllO5rw.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
Hi again, mentors! I'm sending this to renew my RFC/RFS, and also to notice I moved all the files needed for beef in a new location. The new URLs are: * http://www.kiyuko.org/debian/beef_0.0.3.orig.tar.gz * http://www.kiyuko.org/debian/beef_0.0.3-1.diff.gz * http://www.kiyuko.org/debian/beef_0.0.3-1.dsc I'd also like to thank all who made comments and pointed me in the good direction. This is the package description, once again: > Package: beef > Licence: GPL > Version: 0.0.3 > URL: http://www.kiyuko.org/beef/ > Upstream author: KiyuKo <[EMAIL PROTECTED]> > Description: flexible BrainFuck interpreter > beef is a BrainFuck interpreter written in C. Its behavior is configurable > using command-line options, so you can run a lot of BrainFuck programs > written for other interpreters/compilers without modifications. > . > beef gets rid of some historical BrainFuck limitations: for example, the > length of the memory tape has no limits except for the amount of memory your > computer has. > . > beef's aim is not to be incredibly small or optimized, but to be a flexible > and pleasant-to-work-with interpreter. Thank you for reading. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgptoknao9wcU.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Thu, 2 Mar 2006 00:11:28 +0100 Bas Wijnen <[EMAIL PROTECTED]> wrote: > If you would upload it while the previous version was in Debian, you would > need a new version. Debian doesn't support uploading a version of a package > which isn't higher than the one currently in the archive. You are right. I forgot that. > If you mean you > wouldn't want it uploaded at all for such a change (but let the change come > in with the next version), then I agree with you. :-) I hope, by the time my packages get into Debian (if at all), I will learn enought to avoid stupid mistakes like this one. O_o Cheers. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpY4kFmUzWL3.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Wed, 1 Mar 2006 22:04:47 +0100 Bas Wijnen <[EMAIL PROTECTED]> wrote: > > I suggest bumping the package version and making a note of > > your changes in debian/changelog when you make a change: the > > tool 'dch -i' from the package source dir will help you do > > this. > > Personally, as long as the previous version wasn't released with Debian, and > not made public on a large scale either (and advertising to this list isn't a > large scale), I don't bump the debian version, but just keep it at -1. As far > as I've understood many e-mails here, that seems to be common practice. I made a similar reasoning when I decided not to bump the version number. The package has never been in Debian, and even if it had, no one would want to update it just because of a change in the mantainer scripts: the content of the package is exactly the same. Please tell me if my thoughts were wrong. Thanks. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgp39hk43C0Zw.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Mon, 27 Feb 2006 21:03:06 -0500 Mike O'Connor <[EMAIL PROTECTED]> wrote: > You included preinst/postinst/prerm/postrm scripts that do nothing. If > they aren't doing anything you should omit them. Removed the useless scripts. Files are at the same place: http://www.kiyuko.org/pool/beef_0.0.3.orig.tar.gz http://www.kiyuko.org/pool/beef_0.0.3-1.diff.gz http://www.kiyuko.org/pool/beef_0.0.3-1.dsc http://www.kiyuko.org/pool/beef_0.0.3-1_i386.changes http://www.kiyuko.org/pool/beef_0.0.3-1_i386.deb Hope everything is ok now. If not, please let me know. PS: thanks for the suggestions. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpq8ZnwO4QnZ.pgp Description: PGP signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Mon, 27 Feb 2006 18:49:04 -0500 Mike O'Connor <[EMAIL PROTECTED]> wrote: > I am not able to use the above url: > > $ HEAD http://www.kiyuko.org/pool/ > 403 Forbidden > Connection: close > Date: Mon, 27 Feb 2006 23:46:34 GMT > Server: Apache/2.0.55 > Content-Type: text/html; charset=iso-8859-1 > Client-Date: Mon, 27 Feb 2006 23:46:48 GMT > Client-Peer: 62.149.140.16:80 > Client-Response-Num: 1 Sorry. These are the URLs to the single files: http://www.kiyuko.org/pool/beef_0.0.3.orig.tar.gz http://www.kiyuko.org/pool/beef_0.0.3-1.diff.gz http://www.kiyuko.org/pool/beef_0.0.3-1.dsc http://www.kiyuko.org/pool/beef_0.0.3-1_i386.changes http://www.kiyuko.org/pool/beef_0.0.3-1_i386.deb Hope everything is correct this time. Sorry again. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgp1tGHanEWew.pgp Description: PGP signature
RFC/RFS: beef - a flexible BrainFuck interpreter
Cheers mentors! I'd like to hear comments about this package, since it's my very first attempt and I probably missed something. I think it would be a shame if etch will be shipped without a BraiFuck interpreter. We must get one in. The package is both lintian and linda clean. You can download the sources from http://www.kiyuko.org/pool/ So here's the info about my package: Package: beef Licence: GPL Version: 0.0.3 URL: http://www.kiyuko.org/beef/ Upstream author: KiyuKo <[EMAIL PROTECTED]> Description: flexible BrainFuck interpreter beef is a BrainFuck interpreter written in C. Its behavior is configurable using command-line options, so you can run a lot of BrainFuck programs written for other interpreters/compilers without modifications. . beef gets rid of some historical BrainFuck limitations: for example, the length of the memory tape has no limits except for the amount of memory your computer has. . beef's aim is not to be incredibly small or optimized, but to be a flexible and pleasant-to-work-with interpreter. Thank you for your comments and your patience. -- KiyuKo "Like Russian Rulette with six bullets loaded" pgpyk2zoBJlDI.pgp Description: PGP signature
