Re: How to use svn(-buildpackage) with pbuilder?
On Sun, Jul 31, 2005 at 09:59:04AM +, W. Borgert wrote:
> - How do I have to arrange the repository, so that
better use arrangement which svn-buildpackage creates
branches trunk tags upstream build-area and tarballs
> under pkg-greetings/hello/tags/1.0-1/? Or do I have to put
> the upstream under pkg-greetings/hello/branches/upstream/1.0/?
svn-inject and consequently svn-upgrade does it for you
> - How do I call svn-buildpackage, so that pbuilder is used? Is
> --svn-builder=pdebuild enough?
I'm using
svn-buildpackage --svn-lintian --svn-builder="pdebuild --buildresult
`pwd`/../build-area --auto-debsign "
borrowed from a nice minimalistic HOWTO
http://workaround.org/moin/SvnBuildpackage
> - Has somebody a good build script that does all steps
> automatically? 1. checkout from svn, 2. build in pbuilder,
> 3. run linda, 4. run lintian, 5. run piuparts.
I did without 3 and 5 with a given above commands. But it is easy to add
3 and 5 just add them to --svn-postbuild as IT IS SAID IN THE MAN PAGE:
--svn-prebuild, --svn-postbuild, --svn-pretag, --svn-posttag
Commands (hooks) to be executed before/after the build/tag com-
mand invocations. Examples to fetch the orig tarball from a
local pool (trying pool/libX/... to):
svn-buildpackage --svn-prebuild='a="wget -chttp://mymir-
ror/debian/main/pool/";b="/$package/${package}_${upstream_ver-
sion}.orig.tar.gz"; $a$(echo $package|cut -c0-1)$b || $a$(echo
$package | cut -c0-4)$b'
Multiple retries with a bashism:
svn-buildpackage --svn-prebuild='wget-chttp://mymir-
ror/debian/main/pool/{`echo $package | cut -c0-1`,`echo $package
| cut-c0-4`}/$package/${package}_${upstream_ver-
sion}.orig.tar.gz'
Or using a bounty, see below...
svn-b --svn-prebuild="wget http://mymir-
ror/debian/main/pool/$guess_loc"
> Many thanks in advance!
You are welcome :-)
--
.-.
=-- /v\ --------=
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgppnIfg8cN4m.pgp
Description: PGP signature
Re: How to use svn(-buildpackage) with pbuilder?
> If I have the complete upstream source in SVN, but not the > .tar.gz, how do I create the .orig.tar.gz, when I have a new > upstream version? Look down the thread -- your question was answered: Date: Mon, 01 Aug 2005 16:03:03 +0200 From: Arjan Oosting <[EMAIL PROTECTED]> To: debian-mentors@lists.debian.org Subject: Re: How to use svn(-buildpackage) with pbuilder? X-Spam-Level: gpg: Signature made Mon Aug 1 10:03:03 2005 EDT using DSA key ID 962E3890 gpg: Can't check signature: public key not found [-- The following data is signed --] Op ma, 01-08-2005 te 13:44 +0200, schreef Matthijs Mohlmann: > > I don't want to have all revisions of the package that ever existed on > > my filesystem. Is it possible to make svn-buildpackage create the > > tarballs on build-time? > > > AFAIK it isn't possible. It is, the orig.tar.gz is created if you do a FORCEEXPORT=yes svn-buildpackage It is not recommended to use this though because the resulting orig.tar.gz might be different (md5 checksum) from the upstream version which can complicate things substantially. Greetings Arjan Oosting [-- End of signed data --] > Cheers, -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpyvKpYQUAZR.pgp Description: PGP signature
mozilla-imagezoom
Dear Debianizers, I've decided to take my chances and package imagezoom extension for mozilla (firefox and thunderbird) http://imagezoom.yellowgorilla.net which is a very nice addition to mozilla especially if you work with images and need to zoom them from time to time to get better view on some details. So I've made a preliminary version of a mozilla-imagezoom package from the recent development upstream version. mozilla-nukeimage served me as a start point. An ITP for mozilla-imagezoom was filed a day ago. Package (.orig, .diff, .deb) is available from http://www.onerussian.com/debian Before I start bothering my regular sponsor I've decided to seek help to resolve some of the issues with the package (although it is lintian and linda clean) + how to activate a thunderbird extension? I've created most of the necessary symlinks and have ran (manually for now) update-mozilla-thunderbird-chrome to get chrome updated, but I think the missing part is extension.part.imagezoom I don't see it in the original upstream package, and this one is the first package of mozilla extensions. Is there a tool to extract relevant information from install.rdf or I need to create RDF:Description manually somehow? I would appreciate any good references about mozilla extensions system and especially about their debian packaging styles. + would be the versioning I've used appropriate or I should go directly to 0.2.20050126 because it is an alpha for 0.2 release? Thank you in advance -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpK3R3usskDZ.pgp Description: PGP signature
"combined" prerm script problem [Bug#337223: fail2ban: leaves garbage around after purge]
Dear All,
I'm maintaining fail2ban package and got a bug report about garbage left
after purge on the package. The problem lies in prerm script which first
tries to stop fail2ban and then if stop was successfull removes .py[co]
files (added by dh_python) which were compiled/installed on first
start of fail2ban:
#!/bin/sh
set -e
# Automatically added by dh_installinit
if [ -x "/etc/init.d/fail2ban" ]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d fail2ban stop || exit 0
else
/etc/init.d/fail2ban stop || exit 0
fi
fi
# End automatically added section
# Automatically added by dh_python
dpkg -L fail2ban |
awk '$0~/\.py$/ {print $0"c\n" $0"o"}' |
xargs rm -f >&2
# End automatically added section
The simplest solution is to override error-handler for dh_installinit
but that will impact postinst script as well and I don't want to have
such side effect. What would be a proper solution or do I have to
contact debhelper team (or -dev list) to resolve this case.
I would like to avoid hacking my own prerm since it will not be a proper
solution
Thank you in advance for the hints
- Forwarded message from Jochen Voss <[EMAIL PROTECTED]> -
Date: Thu, 03 Nov 2005 11:29:15 +
From: Jochen Voss <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Bug#337223: fail2ban: leaves garbage around after purge
X-Spam-Level:
Package: fail2ban
Version: 0.5.4-7
Severity: normal
Hi,
when I install and then purge fail2ban, some files are left lying around in
/usr/share/fail2ban:
[EMAIL PROTECTED] [~] sudo aptitude purge fail2ban
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages will be REMOVED:
fail2ban
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 246kB will be freed.
Do you want to continue? [Y/n/?] y
Writing extended state information... Done
(Reading database ... 132413 files and directories currently installed.)
Removing fail2ban ...
Stopping fail2ban: Status of fail2ban: fail2ban is not running.
Not stopping fail2ban
invoke-rc.d: initscript fail2ban, action "stop" failed.
Purging configuration files for fail2ban ...
dpkg - warning: while removing fail2ban, directory
`/usr/share/fail2ban/utils' not empty so not removed.
dpkg - warning: while removing fail2ban, directory
`/usr/share/fail2ban/confreader' not empty so not removed.
dpkg - warning: while removing fail2ban, directory
`/usr/share/fail2ban/logreader' not empty so not removed.
dpkg - warning: while removing fail2ban, directory
`/usr/share/fail2ban/firewall' not empty so not removed.
dpkg - warning: while removing fail2ban, directory `/usr/share/fail2ban'
not empty so not removed.
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
[EMAIL PROTECTED] [~] ll /usr/share/fail2ban/
total 56
drwxr-xr-x 2 root root 4096 2005-11-03 11:23 confreader/
-rw-r--r-- 1 root root 15916 2005-11-03 11:14 fail2ban.pyc
-rw-r--r-- 1 root root 15916 2005-11-03 11:14 fail2ban.pyo
drwxr-xr-x 2 root root 4096 2005-11-03 11:23 firewall/
drwxr-xr-x 2 root root 4096 2005-11-03 11:23 logreader/
drwxr-xr-x 2 root root 4096 2005-11-03 11:23 utils/
-rw-r--r-- 1 root root 469 2005-11-03 11:14 version.pyc
-rw-r--r-- 1 root root 469 2005-11-03 11:14 version.pyo
These files should be deleted when the package is purged.
I hope this helps,
Jochen
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages fail2ban depends on:
ii iptables 1.3.3-2Linux kernel 2.4+ iptables adminis
ii python2.3.5-3An interactive high-level object-o
fail2ban recommends no packages.
-- no debconf information
- End forwarded message -
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgp9Xgrnr5Cl5.pgp
Description: PGP signature
Re: "combined" prerm script problem [Bug#337223: fail2ban: leaves garbage around after purge]
Thank you Justin, I was about to send my "thank you" to your first email when my mail server with lovely mutt hanged on me :-/ hardware doesn't like me these days. I will have fail2ban init script fixed accordingly. Thank you once again! On Thu, Nov 03, 2005 at 03:20:25PM -0500, Justin Pryzby wrote: > On Thu, Nov 03, 2005 at 02:46:26PM -0500, Joe Smith wrote: > > The bug is in the initscript. > > LSB mandates that 'stop' not fail if the service is not running. > Oh, yes, you are right. The problem was that I was reading > fail2ban/testing version. The bug was reported against unstable, > though. -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpAlmKDvtpbx.pgp Description: PGP signature
mozilla extension installation - is not seen on some boxes
Dear Gurus, I am a sponsored maintainer of mozilla-imagezoom package. I just upgraded it to the most recent upstream version so I could have it working with the recent firefox. I believe I had similar problem before but now I have it again: on some boxes (where I believe I used to have it installed in my local account) it doesn't appear in the list of extensions no matter what I do (including moving ~/.mozilla away to start with fresh local settings). But it works nicely on some other boxes... So what did I miss in my package? In the debian/rules I do dtmp = $(CURDIR)/debian/mozilla-imagezoom extdir = $(dtmp)/usr/share/mozilla-extensions/imagezoom uuid = 1A2D0EC4-75F5-4c91-89C4-3656F6E44B68 . install: . cp -rp chrome defaults $(extdir) install -m 644 debian/chrome.d debian/extensions.d install.rdf \ $(extdir) install -m 644 debian/Uninstall $(extdir)/uninstall and in debian/postinst I do if [ "$1" = configure ]; then for update in update-mozilla-chrome \ update-mozilla-snapshot-chrome \ update-mozilla-firefox-chrome \ update-mozilla-thunderbird-chrome; do if searchpath "$update"; then "$update" fi done fi Fresh version of the package will be duploaded by the sponsor as soon as he gets my email, but for now I have it available from my local repository if you are willing to have a look at it http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-all/web/mozilla-imagezoom_0.2.2-1_all.deb Thank you in advance for the hints -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpGkicnaoLUx.pgp Description: PGP signature
Re: RFC: denyhosts
On Mon, Jan 16, 2006 at 07:59:58PM +0100, Marco Bertorello wrote: > denyhosts can run on systems that haven't support for packet filtering, > fail2ban can ? :) actually it can do that since fail2ban can be configured to run ANY command to "ban" an ip you can add something like fwban = "echo ssh >> /etc/deny.hosts" fwunban = "perl -pi -e 's/^ssh $//g' /etc/deny.hosts" or with recently changed general rule fwban = "echo %(__name__) >> /etc/deny.hosts" fwunban = "perl -pi -e 's/^%(__name__) $//g' /etc/deny.hosts" just choose names of the sections appropriately :-) or add another "interpolation" name into config file. feel free to mod the lines up to your needs to make it truly functional That is the advantage of fail2ban that it is not really doomed to use iptables but prefers them since it is the best way (as author(s) think) You are to choose an alternative way to ban if you want to do so > BTW, why "keep it away from the archive" ? > Users that can choose are happy users :) I agree! also it forces authors and maintainers to add more features which might be present in the other package. Also within time it will be interesting which package will be of prereference among the users :-)) -- .-. =------ /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpqmRKGvs3FE.pgp Description: PGP signature
Re: mozilla extension installation - is not seen on some boxes
Since it might be of interest to someone else, the main problem was in the omitted from install chrome.manifest to confirm the latest requirements of the extension manager N.B. Inspired by that finding I've packaged another nice extension for you guys: mozilla-bookmarksftp (in ITP as mozilla-bookmarksync), it is out to become available within a few hours (if not yet) A Mozilla Firefox extension that let you to connect to an FTP/WebDAV(HTTP,HTTPS) server and synchronize your bookmarks that are stored in an XML file. Setup is very easy: just enter your FTP/WebDAV server address, username, password and a name for the XML file (by default called xbel.xml). . Features include - automatic download/upload on startup/exit - merge of fresh bookmarks from the server into local bookmarks - synchronization of favicons, livemarks, keywords, and webpanel - undo/redo . More details on the project available from https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=14 On Tue, Jan 10, 2006 at 02:02:46PM -0500, Yaroslav Halchenko wrote: > Dear Gurus, > I am a sponsored maintainer of mozilla-imagezoom package. I just > upgraded it to the most recent upstream version so I could have it > working with the recent firefox. I believe I had similar problem before -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpH8SubHLM2Q.pgp Description: PGP signature
Re: RFC: denyhosts
from a live discussion on gentoo forum:
http://forums.gentoo.org/viewtopic-p-3032020.html#3032020
[SSH]
enabled = true
logfile = /var/log/sshd/current
fwstart =
fwend =
fwcheck =
fwban = IP= && echo "ALL: $IP" >> /etc/hosts.deny
fwunban = IP= && sed -i.old s/ALL:\ $IP// /etc/hosts.deny
timeregex = \S{3}\s{1,2}\d{1,2} \d{2}:\d{2}:\d{2}
timepattern = %%b %%d %%H:%%M:%%S
failregex = Authentication failure|Failed password|Invalid user
makes it work with hosts.deny (haven't tried myself though)
On Mon, Jan 16, 2006 at 10:37:30PM -0500, Yaroslav Halchenko wrote:
> On Mon, Jan 16, 2006 at 07:59:58PM +0100, Marco Bertorello wrote:
> > denyhosts can run on systems that haven't support for packet filtering,
> > fail2ban can ? :)
> actually it can do that
> since fail2ban can be configured to run ANY command to "ban" an ip you
> can add something like
> fwban = "echo ssh >> /etc/deny.hosts"
> fwunban = "perl -pi -e 's/^ssh $//g' /etc/deny.hosts"
> or with recently changed general rule
> fwban = "echo %(__name__) >> /etc/deny.hosts"
> fwunban = "perl -pi -e 's/^%(__name__) $//g' /etc/deny.hosts"
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpFWKq8pEiXq.pgp
Description: PGP signature
Re: Linking file types and apps
Hi Miriam, I am not a specialist to answer your question concisely and complete but I just want to suggest the logic I would follow... I recall that dia package introduces such new kind of files, and it is very popular, thus must have such an association setup correctly. Here is the step of action I do > apt-get source dia > cd dia-0.94.0/ > find -iname \*desktop\* ./shapes/network/pc_desktop.png ./shapes/network/pc_desktop.shape ./dia.desktop.in > less dia.desktop.in [Desktop Entry] Encoding=UTF-8 _Name=Dia _Comment=Diagram editor Type=Application Exec=dia-gnome Icon=dia_gnome_icon.png Terminal=false Categories=GNOME;Application;Graphics; StartupNotify=true MimeType=application/x-dia-diagram; > ls debian/*mime* 4 debian/dia-gnome.mime 4 debian/dia.mime > grep desktop debian/* debian/changelog: * Added dh_desktop call to debian/rules (Closes: #278723) debian/changelog: * Set GNOME desktop category (closes: #148816, #194598) debian/rules: dh_desktop -i debian/rules: dh_desktop -a > grep mime debian/* debian/changelog: * debian/: Added MIME handler with dh_installmime for dia and dia-gnome debian/rules: dh_installmime -i debian/rules: dh_installmime -a May be it is not complete - as I said I never have done it - but at least it gives some hints about how to figure out on how to deal with .desktop and .mime for your application :-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpILrDjC7saa.pgp Description: PGP signature
Re: RFC/RFS: griffith -- A film collection manager
Hi Vasco, My 1 cent: > It is lintian clean but linda returns warnings about having > files in /usr/lib directory. Since they're python files, > I see no problem with having them in there, am I right? From http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html " A program using /usr/bin/python as interpreter can come up with private python modules. These modules should be installed in /usr/lib/site-python/module, /usr/lib/pythonX.Y/site-packages/module (where pythonX.Y is the current python version). If the private modules would pollute the name space in sys.path, the modules should be installed in /usr/lib/package (for architecture any) or /usr/share/package (for architecture all). In this case, the directory should be added to sys.path at the program startup. " Since python-compiled modules supposed to be architecture independent... and indeed .pyc files are platform independent http://lists.debian.org/debian-python/2003/11/msg00037.html that is why I believe the most of python driven packages actually install under /usr/share/package. Please correct me if I am wrong - since then I would need to fix my packages as well ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpqgvh8HkwLS.pgp Description: PGP signature
Re: RFS: personalbackup
Dear Kim Kuylen, I am quite sorry to ask such a rhetoric question but is there any advantage over backuppc which seems to be much superior (ie implementing everything what personalbackup does and even more) and quite similar in how it implements the features and has been in the Debian for quite a while. On Wed, 15 Mar 2006, Kim Kuylen wrote: > Dear listmembers, > As pointed out by Ben Finney I forgot to add the links to the dsc and changes > files. > I also forgot to add a link to the original sources, and I forgot to supply > the author name... > I therefor repost my original RFS and added the missing info. My apologies > for the inconvenience. > Best Regards, > Kim Kuylen -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpTMBgEZxtPh.pgp Description: PGP signature
package-uses-debhelper-but-lacks-build-depends ????
Dear All, I am in the process of packaging a new package toward closing ITP ;-) and although I defined Build-Depends to depend on debhelper, lintian is not happy anyways What is my problem??? binaries are from http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-i386/science/ sources (and diff) http://itanix.rutgers.edu/rumba/dists/unstable/perspect/source/science/ package pyepl lintian reports: W: pyepl source: dh-make-template-in-source debian/python-pyepl.doc-base.EX that is ok - I will work on documentation in the next step E: pyepl source: package-uses-debhelper-but-lacks-build-depends > grep debhelper debian/control Build-Depends: debhelper (>= 4.0.0), . W: pyepl source: maintainer-upload-has-incorrect-version-number 1.0.9-0.2 that is ok -- it is my versioning toward -1 ;-) E: python2.4-pyepl: shlib-with-non-pic-code usr/lib/python2.4/site-packages/pyepl/hardware/sound/_eplSound.so E: python2.3-pyepl: shlib-with-non-pic-code usr/lib/python2.3/site-packages/pyepl/hardware/sound/_eplSound.so and that is a mistery as well... description of shlib-with-non-pic-code doesn't really seem to provide an answer to what is happening -- I don't see those switches in Makefiles... anyways probably it is time to go to bad ;-))) Thank you for any hints -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpRYEA4yIEQO.pgp Description: PGP signature
Re: howto pack python programs
for more information you might refer to http://www.debian.org/doc/packaging-manuals/python-policy/ which is Debian Python Policy Abstract This document describes the packaging of Python within the Debian GNU/Linux distribution and the policy requirements for packaged Python programs and modules. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hard-to-reach upstream. looking for advice
Dear DDs and DPMs (Debian Package Maintainers who might not be a DD) I've packaged mozilla-bookmarksftp which is "Mozilla Firefox extension to synchronize bookmarks" since I think it is a very very useful extension -- I have been using it for a while to sync bookmarks between 4 boxes.. Current version in unstable/testing is 1.0.2, but it is not compatible with recent firefox. Thus I need to upgrade it. The problem is really is that original upstream author is hard (if possible at all to reach) -- there is no official webpage since mozilla.org rejected some recent version of it and upstream author didn't bother to proceed or smth like that, thus https://addons.mozilla.org/firefox/14/ has only 1.0.1. I've tried to reach upstream via email but got no reply. There are few derivatives available 1. floating around "original" release from upstream 1.1.2 which is compatible with fresh firefox. (available from the website of 3 -- look below) 2. Bookmarks Synchronizer 3 (https://addons.mozilla.org/firefox/1989/) which is merely a fix of 1.0.2 to make it work with FF 1.5 3. Bookmarks Synchronizer SE http://www.trasduzione.com/bmsync/ -- fork from 1.0.2, which now reached its own 1.1.8 version. It has multiple bug fixes and improvements. But also seems to be without any changes since 28 Jan 2006. I left multiple inquiries and sent emails to those authors, but got no reply (besides comments to my first question among the comments on http://www.trasduzione.com/bmsync/). Also they switched to another prefix in mozilla configuration parameters, thus anyone who will upgrade to bmsync SE will have to reenter their configuration -- should not be a big deal, since new prefix seems to be used by 1.1.2 from the original upstream anyways. Also probably a package name has to change to mozilla-bmsyncse which would be more appropriate I am not sure which way I should proceed -- I really want to see that extension upgraded but absence of contact with upstream holds me away from simply choosing 1 or 3. 2 is just a hack on top of 1. so I would prefer to stay away from it. How usually people deal with such problems with upstream? Thank you in advance for advice -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp5DrWfYdu5V.pgp Description: PGP signature
proper way to package mozilla extensions
Hi All, I am upgrading to the recent upstream one of the extensions I am maintaining. Finally I made a proper debian/watch file but now I need to decide which way to go on how to keep .orig.tar.gz. I've investigated a few packaged extensions and didn't find an answer to my question: how to perform automatic upgrade (via uscan). The reason is that 1. There are two possible packaging schemes a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it at build time. b. Keep unzipped .xpi in .orig.tar.gz. I was going the b. way but now I think that keeping original .xpi would be better 2. All packages I've checked were missing debian/watch, so I could not see how people perform upgrades. Now I need to either write my own wrapper around svn-merge, which would be called by uscan, and it will tar.gz the freshiest .xpi into .tar.gz and call svn-upgrade But before I do that I thought to ask people on what they think about a. vs b. and debian/watch config to (semi)automatically upgrade to the most recent upstream -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpbdrY0iDH34.pgp Description: PGP signature
Re: proper way to package mozilla extensions
> >1. There are two possible packaging schemes > > a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it > >at build time. > > b. Keep unzipped .xpi in .orig.tar.gz. > > I was going the b. way but now I think that keeping original .xpi > > would be better > I'm no DD, but I would say (a) is nicer because then a checksum can be > verified more easily. :-) Actually this is the only way the checksum can be verified ;-) as soon as you extract it, there is no way (besides downloading xpi, extracting and md5suming all the files) to verify the authenticity of upstream release. This is what I think and that is why I would like to move over keeping original .xpi. And the question is did anyone done it proper way to automate it with uscan + svn-upgrade... :-) -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpbWoC9fMAzi.pgp Description: PGP signature
Re: proper way to package mozilla extensions
On Mon, 24 Apr 2006, Don Armstrong wrote: > On Mon, 24 Apr 2006, Yaroslav Halchenko wrote: > > >...< > > 1. There are two possible packaging schemes > > a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it > > at build time. > > b. Keep unzipped .xpi in .orig.tar.gz. > c. Distribute the actual source code in the orig.tar.gz. > >...< doh... how could I forget about this one? ;-) > Otherwise it's a PITA to actually patch the .xpi, as you have to > unpack it, unpack the jar, patch the jar, pack the jar, pack the xpi. totally true... > See Michael Spang's work on greasemonkey for an example on how to do > this. thank you - I will check it out! > 1: Note that I personally won't sponsor mozilla modules that don't > distribute the actual source in the orig.tar.gz... xpi and jar is the source -- it is just packaged with the other than tar/gzip archiver and nested in each other to make our life fun ;-) That is why there is no alternative tarball with the "true source" is often provided (even if the license is GPL) -- at least I didn't mention any on https://addons.mozilla.org. I will check with the upstream if they will not mind provide .tar.gz as well... -- .-. =-- /v\ --------= Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpuwqV2s5Iz8.pgp Description: PGP signature
Re: proper way to package mozilla extensions
indeed -- proper full building from source is simply necessary in such cases for my case -- upstream provided me with SVN information, I wrote a nasty but nice ( :) ) wrapper script which is called by uscan if there is a fresh .xpi available. That wrapper exports upstream SVN, wrapps exported release into .tar.gz and feeds it to svn-upgrade which takes care about the rest. The only difference now in the rules - I am zipping (greesemonkey leaves everything open which I would consider somewhat an overkill) chrome into .jar during "install". This way I have fully automatic upgrade procedure, proper watch file so I could monitor my package easily, all sources are extracted in the .orig.tar.gz -- so it is close to be the best solution If anyone interested: http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5.orig.tar.gz http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.diff.gz http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.dsc http://itanix.rutgers.edu/rumba/dists/sid/perspect/binary-all/web/mozilla-imagezoom_0.2.5-1_all.deb On Tue, 25 Apr 2006, Matthias Julius wrote: > Sometimes Mozilla extensions contain other binaries. One example that > I know is the Html Validator extension. And I know that because my > AMD64 Firefox loads the i386 version of this extension. And when I > try to use it Firefox says it is not compatible. > Matthias -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpAqoxQREAqu.pgp Description: PGP signature
Re: How to include information about a source package ?
Hi Frank, Isn't debian/README.Debian the one you would like to edit? On Fri, 28 Apr 2006, Frank Gevaerts wrote: > Hi, > I'm currently updating the foobillard package. I'd like to include a > file explaining how I work with the package. Is there a consensus about > how such a file should be named ? > Frank -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpPH2IlgJpXN.pgp Description: PGP signature
PDF files and dh_compress
I'm sorry if this question was discussed before but I couldn't google it up and think that it is too early to raise on -dev. I've got finally annoyed enough by compressed pdf.gz in -doc packages that I decided to check if that is required (deb pol, or dev ref?) and/org common practice. Let me first reveal some numbers characterizing current situation: Total number of pdf files present in sid: > apt-file search .pdf | grep '\.pdf\(\.gz\)*$' >| pdf.files > wc -l pdf.files 2485 pdf.files How many pdfs lie outside of doc (just out of curiosity): > grep -v 'usr/share/doc' pdf.files | wc -l 476 And whatever is within share/doc, gzipped: > grep 'usr/share/doc/.*\.pdf\.gz$' pdf.files | wc -l 1095 raw pdf: > grep 'usr/share/doc/.*\.pdf$' pdf.files | wc -l 914 So approx 50/50, so half people do adjust debian/make to exclude .pdfs. I'm lazy to spot some dependency here -- may be cdbs takes care about keeping them not compressed automatically? And if we look only at -doc packages which are intended to provide a documentation (ie ready to be readable information, not another gzipped single file ball needed to be decompressed before viewing) > grep 'usr/share/doc/[^/]*-doc/.*\.pdf\.gz$' pdf.files | wc -l 253 > grep 'usr/share/doc/[^/]*-doc/.*\.pdf$' pdf.files | wc -l 573 the situation is slightly better: > 2/3 are keeping PDFs uncompressed in -doc packages. This simple algebra shows though that there is no agreement/clear policy (or at least it is not followed) on how PDFs should be handled. Of cause pdfs are not as highly compressed as with gzip -9 but they are zipped internally and usually are less than 10% larger than their .pdf.gz versions. And at least I would expect all -doc packages to have uncompressed .pdfs since neither of the pdf viewers to me experience handle transparent decompression of pdf.gz Few questions now: So is there a recommendation anywhere in dev ref or deb policy regarding the PDF files? Shouldn't it be recommended (withing dev ref or deb policy) to keep PDFs not compressed with gzip on top (at least in -doc packages)? Obviousely dh_compress doesn't bother checking if there is a good reason to compress the file (like some threshold gain, after which file has to be compressed). I doubt that it is worth implementing, but I think it should at least take care about not compressing pdf's in -doc packages. What do you think? As always, depending on the answers to previous questions, may be it is worth to provide linda/lintian warnings about twice compressed files or at least compressed pdfs in -doc packages. Thank you in advance -- .-. =------ /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpe4RsO0wuAt.pgp Description: PGP signature
Re: PDF files and dh_compress
Thank you Florent, The thing which I always knew (somewhere deep) but kept avoid using for some reason ;-) Probably due to the reason that my choice of viewer for pdf or for images varies for any given purpose: quick view or thorough reading, or in case of images - reorganization of files (I am using gqview for that) The problem remains though whenever firing up links from mozilla to pdf.gz's... ;-) Thank you for the hint anyways On Sun, 07 May 2006, Florent Rougon wrote: > I know it doesn't really answer your question, but a simple way for > viewing .pdf.gz files is: > see file.pdf.gz > [ cf. see(1) ] -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpVywSUbH1kc.pgp Description: PGP signature
Re: PDF files and dh_compress
On Mon, 08 May 2006, Craig Small wrote: > > Obviousely dh_compress doesn't bother checking if there is a good reason > > to compress the file (like some threshold gain, after which file has to > > be compressed). I doubt that it is worth implementing, but I think it > > should at least take care about not compressing pdf's in -doc packages. > > What do you think? > Fix the policy not the tool. > If there is a good reason not to compress pdf files, then it should be > put into the policy as an exception. Currently if dh_compress did not > compress pdf files, it breaks 12.3 of policy. Well... the policy states in 12.3 Additional documentation: *Text documentation* should be installed in the directory /usr/share/doc/package, where package is the name of the package, and compressed with gzip -9 unless it is small. Of cause we can call PDFs as "text documentation", but often with the same success as png's with text in them. I bet policy intended to address regular textual (ASCII) files with documentation. Probably due to that "text documentation" limitation, dh_compress doesn't compress many other things already: find usr/share/doc -type f \\( -size +4k -or -name "changelog*" -or -name "NEWS*" \\) \ \ \\( -name changelog.html -or ! -iname "*.htm*" \\) \\ ! -iname "*.gif" ! -iname "*.png" ! -iname "*.jpg" \\ ! -iname "*.jpeg" ! -iname "*.gz" ! -iname "*.taz" \\ ! -iname "*.tgz" ! -iname "*.z" ! -iname "*.bz2" \\ ! -iname "*-gz" ! -iname "*-z" ! -iname "*_z" \\ ! -iname "*.jar" ! -iname "*.zip" ! -iname "*.css" \\ Ironically .zip is among them (I believe PDF internally uses zip compression, doesn't it?) > > is worth to provide linda/lintian warnings about twice compressed > > files or at least compressed pdfs in -doc packages. > Once policy is changed, yes. But not before. So as to me, there is no real need in fixing the policy, but rather this question has to be addressed in dev ref, or in packaging practices. ? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpoL3aZwWTGc.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
Sorry to intrude but I wanted to clarify a bit (although there had been a lengthy thread on native packages not that long ago) > You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in > order to produce non Debian native package! Could you please point me where it is *required* (to address "need to") that upstream sourced do not include debian/? I fully understand, that having no debian in upstream source is handy for any dpatch-oriented DD, since with dpatch you wouldn't be able to patch most debian/ files Otherwise, there is no harm at all for upstream to provide any debian/ infrastructure -- any change can be easily absorbed into .diff. Inconvenience arises also in a conflict within debian/changelog entries, so manual interaction might be necessary on each uupdate NMU can happen for native packaging as well and versioning scheme is there, so I don't see much of a problem there. And if we go through the policy we can find next excerpts which do not rule out possibility for upstream to have debian/ directory and for upstream author to be a debian maintainer as well. so talking about native packaging: Policy C.3: > | ... or the Debian maintainer is the same as the upstream maintainer > | - the format is slightly different:... and further from C as well: "This is a unified context diff (diff -u) giving the changes which are required to turn the original source into the Debian source." So if original source already includes everything to be a Debian source, and requires only minor tuning, (or not at all), then only those minor changes (at least Debian/changelog entry with proper maintainer information) need to be in .diff.gz. So I don't see anything which requires debian/ directory to be absent from the orig.tar.gz especially if a package maintainer is the upstream. And also I don't see any strict requirement (although I understand that it is desired) to don't use native versioning schema for not-only-for-debian packages. I think that policy/dev-ref is not clear on that at the moment, that is why relevant questions come up from time to time. -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpz19KkZJsSo.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
> > developer's signature on the package to be accepted in the official > > repositories - just a security measure. > cool, So I'll need to register my signature as a Debian Developer. > I'll figure out how to do this thanks. (Un)fortunately becoming a debian developer is a long term step, for now you should seek for a sponsor for your packages Please have a look at http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#sponsored_packages for how to do that and register your request at http://sponsors.debian.net/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpdkAuEaHmcP.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
> > > You need to remove debian/ directory form fslint_2.15.orig.tar.gz file in > > > order to produce non Debian native package! > > Could you please point me where it is *required* (to address "need > > to") that upstream sourced do not include debian/? > > I fully understand, that > from http://www.debian.org/doc/maint-guide/footnotes.en.html#f5 > | Some people argue that, even for Debian specific packages, it is still > | better practice to package the contents of the debian/ directory > | residing in the diff.gz file, rather than in the orig.tar.gz file. Nice addendum to the pieces I've collected ;-) Thanks That implies also to use debian revisions for "native" debian specific packages. -- .-. =-- /v\ ----= Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp0324ILNOp8.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
> > especially if a package maintainer is the upstream.
> This isn't an argument for inclusion of the debian directory (will you
> release a new upstream version just because you need to change a
> build-depends and trigger a rebuild on the Debian buildds?).
yikes... pardon my ignorance if it is not so... quick look at dev-ref
didn't allow me to find a statement that boost in debian revision
doesn't cause triggering of buildd.
you are saying that increment in debian revision doesn't trigger buildd?
So if I fix a security bug and increment debian revision, that doesn't
penetrate to other architectures?
if buildd is triggered by deb revision increment as well -- there is no
difference between boosting of the upstream version or only deb
revision...
> > And also I don't see any strict requirement
> > (although I understand that it is desired) to don't use native
> > versioning schema for not-only-for-debian packages.
> I don't see this written out specifically, either, but I think this is
> implied. For example, 3.2.1 talks about native packages:
> ,
> | Native Debian packages (i.e., packages which have been written
> | especially for Debian) whose version numbers include dates should
> | always use the "MMDD" format.
> `
well -- that is only for the "Version numbers based on dates" and from
the same section "In general, Debian packages should use the same
version numbers as the upstream sources". If you cited it to
characterize what native package is, then we can debate on the meaning
of "packages which have been written especially for Debian".
First of all *any debian package is written especially for Debian*,
so there is a bit of tautology. Package itself is not a software or
documentation, it is a packaging material (ie debian/) accompanying the
content.
Cleaner statement may be something like "i.e. if the packaged material
(e.g. software, images, documentation) is intended to be used primarily
on a Debian-based system and useless on the other systems". That seems
to be cleaner.
> > I think that policy/dev-ref is not clear on that at the moment, that
> > is why relevant questions come up from time to time.
> Yes, but the answers given are always the same: Try to avoid a
> debian/ directory in the upstream sources. It's in the archives.
yeap - I saw most of those. And I saw the arguments. And I agree that
having split debian/ helps in few cases. But the same question arises
over and over. May be it is the time to fix the policy to make it
explicit to avoid the debates.
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpffhsmpWBX7.pgp
Description: PGP signature
Re: [OT?] debmirror does not add index files
Hi Eddy, Indeed mentors is not the best place to ask such general question -- please follow up on debian-users. Before you email them package your question properly, ie include NB. make sure you don't run --dry-run Simulate a mirror run. This will still download the meta files to .temp but won't replace the old meta files, won't download debs and source files and only simulates cleanup. 1. version of debmirror and more information about the system 2. command line you call debmirror 3. call debmirror with --debug and make that log available somewhere online and point to it in your email that would allow to spot the possible issue. Otherwise it is merely possible to give a better answer I think. I am running debmirror myself with next params: debmirror /share/debmirror/debian -e rsync --passive -h debian.csail.mit.edu -r :debian -d etch,etch-proposed-updates,sid,sarge,sarge-proposed-updates,woody,woody-proposed-updates -d experimental -s main,contrib,non-free,main/debian-installer --getcontents -a i386,sparc,ia64,powerpc --passive --exclude='disks-*' --ignore=rumba --ignore-missing-release --ignore-small-errors and it seems to work nicely ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpvp4mc72Hhh.pgp Description: PGP signature
Re: RFS: FSlint - File System lint
> >> > especially if a package maintainer is the upstream. > >> This isn't an argument for inclusion of the debian directory (will you > >> release a new upstream version just because you need to change a > >> build-depends and trigger a rebuild on the Debian buildds?). > > yikes... pardon my ignorance if it is not so... quick look at dev-ref > > didn't allow me to find a statement that boost in debian revision > > doesn't cause triggering of buildd. > > you are saying that increment in debian revision doesn't trigger buildd? > > >...< > Of course a change in the debian revision will also trigger the > buildds. that is good that we agree... so what was about your statement:? > >> release a new upstream version just because you need to change a > >> build-depends and trigger a rebuild on the Debian buildds?). > In the -1 debian revision, you'd have a non-native package with an empty > diff.gz file (don't even know whether dpkg-source will accept that). that is ok to my knowledge > In the -1 version, -1 version? may be you meant debian revision? may be -2? > you would have a diff.gz file that contains only a diff against > debian/control and debian/changelog. Now this would be very > confusing. Especially if there is a bug in the packaging and you are > currently not available: A possible NMUer would be very confused. can you describe what is confusing in that? I don't really see it... you don't operate on diff.gz directly anyways -- you are operating on extracted (and may be even patched) source, so you have all the files. Usually you are inspecting .diff to catch what was done wrong, or if there was garbage sucked in, or to extract relevant patch. If .diff.gz was missing debian/ it is obvious (to me) that debian is within orig.tar.gz due to the definition of diff.gz > > First of all *any debian package is written especially for Debian*, > > so there is a bit of tautology. Package itself is not a software or > > documentation, it is a packaging material (ie debian/) accompanying > > the content. > "package" in this context is also the name for software here. And for > sure a package is *not* just the packaging material; a Debian source > package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, > and a binary package is a deb file. ok - let me make an analogy to describe what I meant: "this book containing fairy tales from around the world was written especially for our kindergarden"... > > Cleaner statement may be something like "i.e. if the packaged > > material (e.g. software, images, documentation) is intended to be > > used primarily on a Debian-based system and useless on the other > > systems". That seems to be cleaner. > Submit this as a wishlist bug to the policy. indeed, I think that at least mentioning the confusion which comes once so often, it might be useful to at least trigger the change (I bet others can come up with better statement than mine) > >> > I think that policy/dev-ref is not clear on that at the moment, that > >> > is why relevant questions come up from time to time. > >> Yes, but the answers given are always the same: Try to avoid a > >> debian/ directory in the upstream sources. It's in the archives. > > yeap - I saw most of those. And I saw the arguments. And I agree that > > having split debian/ helps in few cases. But the same question arises > > over and over. May be it is the time to fix the policy to make it > > explicit to avoid the debates. > How can the Debian policy "forbid" something that upstream is doing? :-) Good questions with simple answer: it can't. That is why over and over again everyone advices upstreams to place /debian directory aside of orig.tar.gz. And lest don't get into the loop describing why it is bad... ooo - actually it might be worth to compose a wiki page where people can add to pros/cons... -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: python-py{ode,epl}
Dear DDs, Not so long ago me and Michael Hanke created an alioth project http://alioth.debian.org/projects/pkg-exppsy/ aimed provide Debian-aware psychologists with the means of carrying out their experiments, such as stimuli delivery and response registration tools. Also I took over RFP(#329013) for PyODE since it is required for PyEPL to run. I am going through NM process, and Michael is also just an addicted-to-Debian packager without DD title, thus we are seeking for sponsor to get our packages uploaded. Debian packaging is kept under SVN pkg-exppsy http://svn.debian.org/wsvn/pkg-exppsy svn://svn.debian.org/pkg-exppsy/ Built packages and full sources are available from the repository deb http://pkg-exppsy.alioth.debian.org/debian/ sid main dgettable dsc files are http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyode_1.1.0-1.dsc http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14-1.dsc Active issues and notes: * Maintainer address set to [EMAIL PROTECTED] and since none of us is DD yet we saw no point to include us in Uploaders. This fact makes lintian unhappy and complaining about changelog-should-mention-nmu, source-nmu-has-incorrect-version-number * PyODE is among Depends for PyEPL, thus may be I should've RFS just for for it first without PyEPL? * We had preliminary packages available for a while and of cause they used python2.?-PACKAGE scheme, that is why I had to provide conflicts and replaces for the packages so anyone who installed preliminary versions would be ok with new packages if they get accepted to official Debian * Upstream tarball for pyepl includes non-free font. I patched pyepl to don't rely on it, thus binary packages must be ok. Do I have to rip off that font from .orig.tar.gz and provide modified .orig.tar.gz? I would like to thank in advance anyone willing to look at the packages. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpIPWxSBueYe.pgp Description: PGP signature
Re: Who should be listed in Uploaders ?
Great! Thank you Russ and Charles for the Uploaders discussion and pointers. I have added the Uploaders field, now the packages are lintian quiet (only linda is unhappy about non-free font in the upstream tarball) ;-) The same dgettable urls -- I didn't boost the revision. On Mon, 19 Jun 2006, Russ Allbery wrote: > Technically, Uploaders is basically anyone who is listed in changelog > entries. If you list yourself as the author of a version in > debian/changelog, you should be in Uploaders. > In practice, I agree with... > > In the end, I think that it is safe to think the Uploaders field as a > > "Co-maintainers" field. This is also how it is presented in > > packages.qa.debian.org... > ...this. -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpqGK7SNqAA5.pgp Description: PGP signature
Re: Who should be listed in Uploaders ?
> On Tue, 2006-06-20 at 13:25 +0900, Charles Plessy wrote: > > I am in the same situation with some debian-med packages, and I ended up > > adding myself in Uploaders. I think that it is important that the users > > have a clue that there are real persons which take care of the packages. > Yes, and I would personally advise to have a real person to bear the > final responsibility for any package, rather than just a mailinglist. > This might aswell be the person listed in Uploaders in your case. I've added both of us to Uploaders, but responsible person for a specific changeset can be tracked down from changelog. We have also visionegg package (which I will RFS very soon) and most of changelog entries are Michael's, but some times (like now) I will take over to provide necessary changes and there will be corresponding changelog entry with my name (to blame ;-)) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgphThnBMDSLm.pgp Description: PGP signature
Re: Who should be listed in Uploaders ?
> > only linda is unhappy about non-free font in the upstream tarball > If linda is correct about there being a non-free font in the upstream > tarball, then you will need to repack the upstream tarball and > document that you have done so. See the devref for how. you've triggered the action ;-) I wrote a tiny script (debian/repackage.sh) to be called by uscan if a new release is available, it would tar --delete nonDFSG font and feed new tarball to svn-upgrade. That got documented in debian/README.Debian-source and referenced from debian/copyright. debian/watch file adjusted to call that script instead of direct svn-upgrade I kept the same version. Updated files are available from the same url: http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14-1.dsc Linda is happy now ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpofyPVKfFvJ.pgp Description: PGP signature
Re: Who should be listed in Uploaders ?
Thank you Paul for this notice. Indeed, I should've adjusted the version to make my mangling more obvious. For now that font is the only nonDFSG piece I've found Adjusted packages are at http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14.dfsg.1-1.dsc > Also, did you ask upstream to remove the non-free font from their > source? They may be illegally distributing it if the licence does not > allow that. I did... few times... I will remind them about this issue again. Thank you for your help -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpA2TL35lQFx.pgp Description: PGP signature
[RFS]: python-py{ode,epl}
Dear DDs anyone to sponsor my beautiful packages? ;-) they are very clean (linda and lintian are happy with them), satisfy recent python extensions packaging policy, work fine, and might be of interest for quite a few Debian people. Thank you in advance On Wed, 21 Jun 2006, Yaroslav Halchenko wrote: > Thank you Paul for this notice. > Indeed, I should've adjusted the version > to make my mangling more obvious. > For now that font is the only nonDFSG piece I've found > Adjusted packages are at > http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14.dfsg.1-1.dsc > > Also, did you ask upstream to remove the non-free font from their > > source? They may be illegally distributing it if the licence does not > > allow that. > I did... few times... I will remind them about this issue again. > Thank you for your help -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp4VxR9Lji4A.pgp Description: PGP signature
Re: [RFS]: python-py{ode,epl}
> I'm not a DD, but thats my 2 cents after looking at diff file: You > can't use "all (>=2.3)" in XS-Python-Version header, it has to be: > "all, >=2.3" if you want to support all python versions >= 2.3 yikes! Thank you for warning me. Although I think it is quite in dissonance with the rest of control file syntax, since I've just used the syntax used in regular Depends/Build-Depends. I don't see why any other field in control file (such as ??-Python-Version should be anyway different) -- was there some reason for such syntax or it is just a "feature" to overcome some problems with commonly accepted format? I am CCing python mailing list for clarification. > try to run: > $ pyversions -r "all (>=2.3)" > and > $ pyversions -r "all, >=2.3" > to see why -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpUmM3GWSgvl.pgp Description: PGP signature
Re: [RFS]: python-py{ode,epl}
> "all" is not a package, it's a (pseudo) version, you can't use
ouh... indeed... pseudo-version... That helps ;-)
> "version (>= version)" syntax.
> For arch indep packages use just "all" or ">= 2.3"
> For arch dep packages, you need to add "any" part
> ("any", "any, >=2.3", "any, >=2.3, <<2.5", ...)
Thank you for the info - I will try to read docs more carefully next
time ;-)
--
.-.
=------ /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpqXGXYjBvHG.pgp
Description: PGP signature
Re: [RFS]: python-py{ode,epl}
Thank you Piotr once again Updated packages with syntacticly correct XS-Python-Version are available from the same URLs: http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyode_1.1.0-1.dsc http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14.dfsg.1-1.dsc On Sat, 24 Jun 2006, Piotr Ozarowski wrote: > >...< > For arch indep packages use just "all" or ">= 2.3" -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp7o88W5d5cu.pgp Description: PGP signature
Re: [RFS]: python-py{ode,epl}
Dear Mentors, I am sorry that I had to fix few things up and thank everyone who helped me to make those packages 99.9% Debian ready (I leave .1% possibility that I am still missing something...) Could any one sponsor our kiddies? > http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyode_1.1.0-1.dsc > http://pkg-exppsy.alioth.debian.org/debian/dists/unstable/main/source/science/pyepl_1.0.14.dfsg.1-1.dsc -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpTUAMTGZKCL.pgp Description: PGP signature
Re: Dependancies within multi-binary packages
> postgresql-client-8.0-hw depends on libpq4 (>= 8.0.4); however: shouldn't it be libpq8 really? or am I missing something? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17]
[RFS]: jsMath:TeX equations in HTML documents
Dear All, For the sake of reference I am replying to my ITP bugreport. Please consider next packages for sponsoring or for commenting on. (I am 1 person away from DAM approval in NM queue... 1,2 months more and I might become a DD myself ;-) For now I need sponsoring) Sources: dget http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath_3.3g-1.dsc dget http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath-fonts_1.3-1.dsc dget http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath-fonts-sprite_1.0-1.dsc Binaries available from my repository: deb http://itanix.rutgers.edu/rumba/ sid perspect This is the 1st packaging, thus it would close an ITP. Packages are lintian/linda clean. Worries might be due to use of debconf in jsmath to configure web servers. gallery's scripts were used as a start point. I might in future disable botton in jsMath menu to look for updates (although it can't hurt so people could buzz me to run uscan ;-)) Thanks everyone in advance for looking at. On Fri, 06 Oct 2006, Yaroslav Halchenko wrote: > Package: wnpp > Owner: Yaroslav Halchenko <[EMAIL PROTECTED]> > Severity: wishlist > * Package name: jsmath > Version : 3.3e > Upstream Author : Davide P. Cervone > * URL or Web page : http://www.math.union.edu/~dpvc/jsMath > * License : Apache License 2.0 > Description : TeX equations in HTML documents > The jsMath package provides a method of including mathematics in HTML > pages that works across multiple browsers under Windows, Macintosh OS > X, Linux and other flavors of Unix. It overcomes a number of the > shortcomings of the traditional method of using images to represent > mathematics: jsMath uses native fonts, so they resize when you change > the size of the text in your browser, they print at the full > resolution of your printer, and you don't have to wait for dozens of > images to be downloaded in order to see the mathematics in a web > page. > . > There are also advantages for web-page authors, as there is no > need to preprocess your web pages to generate any images, and the > mathematics is entered in TeX form, so it is easy to create and > maintain your web pages. -- .-. =-- /v\ ----= Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpd8tr9V78gx.pgp Description: PGP signature
Re: [RFS]: jsMath:TeX equations in HTML documents
webserver packages than that. You write any pointer would be great -- may be some exemplar package > you've taken the code from gallery, but that doesn't mean that it is > good. it might be not the best but it is working one ;-) > debian/rules: > - why do you call dh_strip and dh_link? Indeed... leftovers -- thanks for spotting! removing them from all jsmath* packages > So much for this package, Frank Thank you for the comments. P.S. Since modifications were quite minor I didn't boost up a revision, so the files are available from the same URLs -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp3auaFpB31e.pgp Description: PGP signature
Re: [RFS]: jsMath:TeX equations in HTML documents
On Mon, 23 Oct 2006, Frank KЭster wrote:
> Sorry to be unclear - I meant that db_version is rarely used.
indeed. thanks -- among 124 postinst scripts using debconf I found on my
box only 29 used db_version. so I must be fine wo it ;-) removed...
> >> Moreover, I doubt that this works at all, and I think there are
> >> better
> > hm... seems to be working to me ;-) I've tested it on a box and
> > previousely I had gallery installed on a few, that is why I recalled
> > that it copes with registering itself within apache
> >> mechanisms to interact with webserver packages than that. You
> >> write
> > any pointer would be great -- may be some exemplar package
> /etc/apache2/README explains shortly how it's supposed to work. It
> also says that httpd.conf is an empty file, and the file itself says
> it's mostly for backwards compatibility. You should try whether it
> works with files in /etc/apache2/mods-{available,enabled} or
> /etc/apache2/sites-{available,enabled}, then you could have real
> conffiles with everything dpkg offers for them.
I think that we don't need to deal with modules/sites, since jsmath is
neither of them, but...
I see now where the confusion is. Please have a kook at current
jsmath.postinst -- it does it in apache2 compliant manner: it doesn't
touch httpd.conf -- just places jsmath.conf under conf.d. It modifies
httpd.conf only for apache, apache-ssl, apache-perl, and in those I
believe httpd.conf is not to be empty.
Having closer look at uptodate httpd.conf from apache -- it now has a
line to include conf.d/ files. Also it seems that the lines I borrowed
from gallery's postinst and which modify httpd.conf are not
necessary since they are there to
1. remove explicit inclusion of gallery.conf in favor of conf.d way.
2. only iff conf.d is not included (may be older config files were
preserved during upgrades or explicitely removed by sysadmin), then it
adds that explicit rule.
so - I see that I just need to link jsmath.conf to webserver's conf.d/
if such exists ;) thus I can completely remove first case statement from
postinst.
Thank you for helping me to make it right ;-)
> Regards, Frank
P.S. updated version (under the same revision) is available from the
same source ;-) current modifications touched just jsmath package
(I tested it on an apache2 server once again... seems to be doing fine)
dget
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath_3.3g-1.dsc
dget
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath-fonts_1.3-1.dsc
dget
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/jsmath-fonts-sprite_1.0-1.dsc
--
.-.
=------ /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpZ6oq748pDz.pgp
Description: PGP signature
Re: [RFS]: jsMath:TeX equations in HTML documents
Hi Richard On Tue, 24 Oct 2006, Richard Laager wrote: > On Tue, 2006-10-24 at 14:08 -0400, Yaroslav Halchenko wrote: > > 2. only iff conf.d is not included (may be older config files were > > preserved during upgrades or explicitely removed by sysadmin), then it > > adds that explicit rule. > I haven't really been following this, so I'm not sure if you're > targeting Apache 1 or Apache 2, but if you're targetting Apache 2, is it > possible that this code has always been there? If that's the case, the > only reason it wouldn't be there is if the sysadmin removed it, in which > case it seems wrong for you to blindly assume that you can add code to > their conffile. you are correct in your understanding of 2. and that is why I removed all those httpd.conf touching lines from jsmath.postinst ;-) 1 and 2 are still in gallery's postinst script though which I took as a starting point for my .postinst > In any case, I thought it violated Debian Policy to modify a conffile > from another package, so you shouldn't do this either way, right? yes, but httpd.conf seems to be a configuration file which is not a conffile (since it is generated/maintained by postinst script), so it seems that it doesn't violate the policy to modify it or at least this is how I understood it... i can be wrong > I'm not a DD. I'm a new packager, so please don't rely on what I've just > said. However, I'd love to have clarification on this, to improve my own > understanding. me too ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harminv
> >-I, --display-info
> > Display informational ("I:") tags as well. They are
> > normally suppressed.
> I mean, lintian -i nor lintian -I doesn't report me anything.
Upgrade lintian may be?
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
pgpGbOCYz7hlV.pgp
Description: PGP signature
init script output
Dear Mentors, Discussing a bug 398740 [1] I could not reach a settlement with the bug reported due to the fact that I could not find a clear statement in debian policy (although I think that I saw it somewhere and that is why init script now performs this way) or LSB about init script that " if daemon found running - don't report that to the screen but simply " report LSB compliant message saying "Ok" So I consider that it is a normal/desired behavior (under various vague policy statements [2,3]) to have smth like lapse:~# /etc/init.d/fail2ban start || echo failure Starting authentication failure monitor: fail2ban. lapse:~# /etc/init.d/fail2ban start || echo failure Starting authentication failure monitor: fail2ban. lapse:~# /etc/init.d/fail2ban stop || echo failure Stopping authentication failure monitor: fail2ban. lapse:~# /etc/init.d/fail2ban stop || echo failure Stopping authentication failure monitor: fail2ban. Martin wants it to look similar to apache2 piper:~# /etc/init.d/apache2 start || echo failure #[345] Starting web server (apache2)... . piper:~# /etc/init.d/apache2 start || echo failure #[346] Starting web server (apache2)... httpd (pid 4175) already running. piper:~# /etc/init.d/apache2 stop || echo failure#[346] Stopping web server (apache2)... . piper:~# /etc/init.d/apache2 stop || echo failure#[347] Stopping web server (apache2)... httpd (no pid file) not running. which I actually consider a bad practice at least since it just spits out stderr output from apache2ctl without wrapping it with lsb_*_msg functions So what should we do? * keep it the way and close the bug with wontfix * keep it the way I want to leave this bug a wishlist?? * fix it asap since it is in violation of policy (please reference) References [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398740 [2] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html [3] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.4 - Forwarded message from martin f krafft <[EMAIL PROTECTED]> - Date: Wed, 15 Nov 2006 17:02:08 +0100 From: martin f krafft <[EMAIL PROTECTED]> To: Yaroslav Halchenko <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Re: Bug#398740: Re: Bug#398740: init.d script does not appear idempotent severity 398740 wishlist retitle 398740 please make init.d script state if it didn't do anything thanks. also sprach Yaroslav Halchenko <[EMAIL PROTECTED]> [2006.11.15.1647 +0100]: > Please argue not by an example on possibly broken scripts but > references to policy/dev-ref -- that would make it easier to > properly resolve the issue I accept your reasoning wrt apache2. However, I don't want to argue using policy. I would like to know whether start started the daemon (and set up the jails), or whether it didn't do anything because fail2ban was already running. And the same goes for stops. This is purely visual or haptic feedback. It's minor. In fact, it's wishlist. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems - End forwarded message - -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp9DS5hGT36M.pgp Description: PGP signature
Re: init script output
> I would, of course, prefer a solution with the lsb functions. What > I want is to know when fail2ban started and when I accidentally > tried to start it while the daemon was already running. BTW - it seems that /etc/init.d/skeleton does not provide any additional status (which you requested), that is why I did it the way it is now (I believe) case "$1" in start) [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME" do_start case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac ;; stop) [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME" do_stop case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac so if providing additional information is what everybody agrees upon, 1) cases should have additional log_daemon_msg I assume to report "(is already running)" or "(was not running)" accordingly... As for LSB compliance: shouldn't usage message be printed using log_success_msg as well (as quite a few init scripts doing that already (eg portmap))? if so - initscripts should get a fresh (yet 1 more heh heh) bugreport filed... -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpFqyfBuCqtg.pgp Description: PGP signature
Re: init script output
well - status has being there for quite a while > invoke-rc.d fail2ban status Status of authentication failure monitor: fail2ban is running but the question is actually an attempt to disambiguate behavior/output of start/stop actions in cases when it was already started/stopped since there is no clear statement in policy, neither in dev-ref about this. On Sun, 19 Nov 2006, Jц╤rg Sommer wrote: > Is it possible to provide a status target? If so Martin can use > % fail2ban status; fail2ban start > Bye, Jц╤rg. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17]
Re: RFS: Need help packaging MMS (My Media System) and get it into Debian
On Tue, 16 Jan 2007, Luis Rodrigo Gallardo Cruz wrote: > > I started packaging (with the help of the web and some maintainers of VDR) > > but > > am new to packaging at all ;) > >...< > Please send the URL to your source package's .dsc file so I can have a > look at it. seems to be online http://www.prodeia.de/mms/mms_1.0.8.1+patch60-1.dsc (or may be just already online ;-)) It looks like a cool project! Congrats! If you have difficulty finding a sponsor - drop me a not - I will have a closer look at packaging and at the software as a whole Thanks! -- .-. =-- /v\ = Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Need help packaging MMS (My Media System) and get it into Debian
few notes on what I spot since first thing of all was to check copyright file -- there seems to be a copyright holder missing for the software itself. there is no sense to keep config.log in .diff -- employ proper clean procedure in debian/rules (may be the other .log files as well can be cleaned...?) there are sources for other libraries included (eg tinyxml, etc) -- those better appear as independent packages (file ITP bugs for them first), if they are not already (like there are unofficial packages for libavcodec). if they are old and abandoned (thus will not be used elsewhere) -- include copyright/licensing information into copyright file for mms. if they are packaged (eg commoncpp2, libavcodec) -- better use provided by Debian libraries instead of rebuilding and relying on upstream ones, unless they were tuned in some way, or there are compatibility issues -- I just worry about possible overlap with names of the shared libraries you might get at the end. So there are lots of work to make it clean in this sense... I hope this blurb is of some value Good luck guys and keep on good work! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch file and berlios
I am sorry if I am trying to wake up a dead issue, but
On Thu, 23 Nov 2006, Julian Gilbey wrote:
> On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote:
> > I think there are 2 problems:
> > - Berlios apparently rejects based on User-Agent.
> Fixed in 2.9.24, I believe.
Indeed there is a changelog entry:
* uscan: set HTTP user agent name (Closes: #397354)
and current 2.9.27 version of uscan has:
$user_agent->agent('Debian uscan 2.9.27');
and my uscan fails with:
,---
| -- In debian/watch, processing watchfile line:
|opts=downloadurlmangle=s/prdownload/download/
http://developer.berlios.de/project/showfiles.php?group_id=7729
http://prdownload.berlios.de/keyjnotegui/keyjnotegui-(.*).tar.bz2
| uscan warning: In watchfile debian/watch, reading webpage
| http://developer.berlios.de/project/showfiles.php?group_id=7729 failed: 403
Forbidden
`---
so imho issue persists since berlios seems to don't allow uscan as the
agent effectively bringing #397354 back alive:
,---
| *$> lynx -dump
'http://developer.berlios.de/project/showfiles.php?group_id=7729' | head -3
|
| [1]BerliOS :[2]DevCounter [3]WebCalendar [4]Developer
| [5]SourceAgency [6]SourceLines[7]Partners [8]Contact Us
|
| $> lynx -useragent='Debian uscan 2.9.27' -dump
'http://developer.berlios.de/project/showfiles.php?group_id=7729'
| Warning: User-Agent string does not contain "Lynx" or "L_y_n_x"!
|
|Forbidden
|
|You don't have permission to access /project/showfiles.php on this
|server.
| _
|
|
| Apache/1.3.34 Server at developer.berlios.de Port 80
`---
P.S. Sorry for an extensive list of Addressees -- just wanted to
follow-up on existing thread/issue.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch file and berlios
ok - so it is not a dead issue. Thanks for the link. I think it is time to ask berlios people to add uscan to the list of valid agents. I will email Lutz Henckel in a follow-up... On Tue, 20 Mar 2007, Michal Čihař wrote: > Hi > On Mon, 19 Mar 2007 23:41:56 -0400 > Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > > I am sorry if I am trying to wake up a dead issue, but > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409137 -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch file and berlios
Dear Lutz,
I am a Debian developer who packages a FOSS software hosted at
berlios.de. As a part of packaging, we use a convenience tool named
uscan which checks the upstream page for available new versions.
Since some time ago, berlios's website is not allowing the tool to use
its native Agent string ("Debian uscan 2.9.27") and forbids the access.
Is there a chance to adjust web server configuration to allow uscan to
access the pages? If it is not of your responsibility, could you
please forward this request to appropriate person?
For the reference and examples of invocation please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397354
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409137
Thank you in advance for your help
Cheers
Yarik
On Mon, 19 Mar 2007, Yaroslav Halchenko wrote:
> I am sorry if I am trying to wake up a dead issue, but
> On Thu, 23 Nov 2006, Julian Gilbey wrote:
> > On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote:
> > > I think there are 2 problems:
> > > - Berlios apparently rejects based on User-Agent.
> > Fixed in 2.9.24, I believe.
> Indeed there is a changelog entry:
> * uscan: set HTTP user agent name (Closes: #397354)
> and current 2.9.27 version of uscan has:
> $user_agent->agent('Debian uscan 2.9.27');
> and my uscan fails with:
> ,---
> | -- In debian/watch, processing watchfile line:
> |opts=downloadurlmangle=s/prdownload/download/
> http://developer.berlios.de/project/showfiles.php?group_id=7729
> http://prdownload.berlios.de/keyjnotegui/keyjnotegui-(.*).tar.bz2
> | uscan warning: In watchfile debian/watch, reading webpage
> | http://developer.berlios.de/project/showfiles.php?group_id=7729 failed:
> 403 Forbidden
> `---
> so imho issue persists since berlios seems to don't allow uscan as the
> agent effectively bringing #397354 back alive:
> ,---
> | *$> lynx -dump
> 'http://developer.berlios.de/project/showfiles.php?group_id=7729' | head -3
> | [1]BerliOS :[2]DevCounter [3]WebCalendar [4]Developer
> | [5]SourceAgency [6]SourceLines[7]Partners [8]Contact Us
> | $> lynx -useragent='Debian uscan 2.9.27' -dump
> 'http://developer.berlios.de/project/showfiles.php?group_id=7729'
> | Warning: User-Agent string does not contain "Lynx" or "L_y_n_x"!
> |Forbidden
> |You don't have permission to access /project/showfiles.php on this
> |server.
> | _____
> | Apache/1.3.34 Server at developer.berlios.de Port 80
> `---
> P.S. Sorry for an extensive list of Addressees -- just wanted to
> follow-up on existing thread/issue.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
pgpeQDnOKgp4c.pgp
Description: PGP signature
Re: debian/watch file and berlios
Thank you Lutz!
Just checked -- it worked!
On Thu, 22 Mar 2007, Lutz Henckel wrote:
> Hi Yarik,
> is should work again. A wrong configuration has forbidded
> access of User Agents beginning with "D".
> Ciao
> Lutz
> Yaroslav Halchenko schrieb:
> >Dear Lutz,
> >I am a Debian developer who packages a FOSS software hosted at
> >berlios.de. As a part of packaging, we use a convenience tool named
> >uscan which checks the upstream page for available new versions.
> >Since some time ago, berlios's website is not allowing the tool to use
> >its native Agent string ("Debian uscan 2.9.27") and forbids the access.
> >Is there a chance to adjust web server configuration to allow uscan to
> >access the pages? If it is not of your responsibility, could you
> >please forward this request to appropriate person?
> >For the reference and examples of invocation please see
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397354
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409137
> >Thank you in advance for your help
> >Cheers
> >Yarik
> >On Mon, 19 Mar 2007, Yaroslav Halchenko wrote:
> >>I am sorry if I am trying to wake up a dead issue, but
> >>On Thu, 23 Nov 2006, Julian Gilbey wrote:
> >>>On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote:
> >>>>I think there are 2 problems:
> >>>>- Berlios apparently rejects based on User-Agent.
> >>>Fixed in 2.9.24, I believe.
> >>Indeed there is a changelog entry:
> >> * uscan: set HTTP user agent name (Closes: #397354)
> >>and current 2.9.27 version of uscan has:
> >>$user_agent->agent('Debian uscan 2.9.27');
> >>and my uscan fails with:
> >>,---
> >>| -- In debian/watch, processing watchfile line:
> >>|opts=downloadurlmangle=s/prdownload/download/
> >>http://developer.berlios.de/project/showfiles.php?group_id=7729
> >>http://prdownload.berlios.de/keyjnotegui/keyjnotegui-(.*).tar.bz2
> >>| uscan warning: In watchfile debian/watch, reading webpage
> >>| http://developer.berlios.de/project/showfiles.php?group_id=7729 failed:
> >>403 Forbidden
> >>`---
> >>so imho issue persists since berlios seems to don't allow uscan as the
> >>agent effectively bringing #397354 back alive:
> >>,---
> >>| *$> lynx -dump
> >>'http://developer.berlios.de/project/showfiles.php?group_id=7729' | head -3
> >>| [1]BerliOS :[2]DevCounter [3]WebCalendar [4]Developer
> >>| [5]SourceAgency [6]SourceLines[7]Partners [8]Contact Us
> >>| $> lynx -useragent='Debian uscan 2.9.27' -dump
> >>'http://developer.berlios.de/project/showfiles.php?group_id=7729'
> >>| Warning: User-Agent string does not contain "Lynx" or "L_y_n_x"!
> >>|Forbidden
> >>|You don't have permission to access /project/showfiles.php on this
> >>|server.
> >>| _
> >>| Apache/1.3.34 Server at developer.berlios.de Port 80
> >>`---
> >>P.S. Sorry for an extensive list of Addressees -- just wanted to
> >>follow-up on existing thread/issue.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_wraporig [was: Creating a source tarball for repackaged source...]
I hacked up a small script dh_wraporig
http://svn.debian.org/wsvn/pkg-exppsy/tools/dh_wraporig
for the cases when
* repackaging is required to remove some non-dfsg content
* wrapping original source-ball is desired (.xpi for ice*
extension, or even if .zip/.rar is shipped) to preserve the original
sources for easy confirmation of their authenticity
Customization of the parameters is done via their definition in
debian/dh_wraporig.local.
Now, whenever a new upstream version comes out, dh_wraporig is called by uscan
and my new fresh .orig.tar.gz is created for me automatically with
undesired content removed, or original source wrapped in the tarball and then
optional command ran (like svn-upgrade) on the generated tarball. Also I get an
updated debian/README.Debian-source file which looks like
,
| README on source packaging of remake:
| --
|
| The source tarball of the package was generated by
| dh_wraporig v.0.1.236 script which
| can be obtained from alioth's exppsy project repository:
| http://svn.debian.org/wsvn/pkg-exppsy/tools/dh_wraporig
|
| For this package dh_wraporig performed following actions:
| * Extracted files from
| md5:23428d1d5e85774b2a4149ef01fddaac ../remake_3.80+dbg0.62.orig.tar.gz
| * Removed following files/directories:
| doc/make.{texi,info*,html} doc/{make-stds,fdl}.*
|
| Additional information:
| * Following patches were present to be applied to the original source
| at build time
| 00-dfsg-no-makedoc
| 00-correct-info-title
`---
debian/dh_wraporig.local for this case looks like
,---
| # later on should be changed to svn-upgrade
| # but now that would just annoy
| post_command=
|
| #
| # files/directories to delete. bash patterns
| delete_files='doc/make.{texi,info*,html} doc/{make-stds,fdl}.*'
|
| #
| # suffix to attach
| suffix_out=~dfsg
|
| #
| # for now we better simply create a symlink
| do_orig_symlink=" pleasedo ;-) "
|
| #
| # do we need original tarball? I guess so for now,
| # if not - uncomment
| #do_delete_originals=" kill the beast "
|
| #
| # Create README.Debian-source
| do_create_readme=" of course "
`---
Then in collaboration with uscan's
,---
| opts="versionmangle=s/-//,dversionmangle=s/~dfsg\.\d+$//"
`---
at the end I am effortlessly getting
,---
| remake-3.80+dbg0.62~dfsg.1.tar.gz
`---
This way anyone who gets this source can confirm the authenticity of upstream
tarball, and can replicate all the steps which were done to ship debian version
of the upstream source. Otherwise, I found it difficult some times to
figure out what was actually done to the upstream source and what tarball was
actually used to generate .orig.tar.gz.
May be an improved version of such script can become a part of debhelper utils
- that would unify things a bit.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#665658: RFS: org-mode/7.8.06-1.0 [put in ITP, ITA, RC, NMU if applicable]
Well, I would better start off asking Sebastien: Sebastien, What do you think about this NMU and getting an more recent org-mode release into Debian?taking into account that freeze is approaching it would be great to be able to give it some "unstable" testing ;) may be there are some showstoppers? would you accept Yury's help/co-maintainership? Thanks in advance for the reply! On Sun, 25 Mar 2012, Paul Wise wrote: > > * Non-maintainer upload. > > * New upstream release > > * Fix lack of odt export styles (Closes: #655652) > These are not appropriate changes for an NMU: > http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325144617.gr22...@onerussian.com
Bug#665658: RFS: org-mode/7.8.06-1.0 [put in ITP, ITA, RC, NMU if applicable]
Thank you Sébastien, Some users might not be fully familiar with standard flow of things -- that might explain the sincere attempt to help by requesting sponsorship for the NMU instead of 'low-effort' wishlist bug report ;-) On Sun, 25 Mar 2012, Sébastien Delafond wrote: > Oops, didn't notice there was a new upstream release. Not sure why > that somehow ended in an NMU attempt instead of a wishlist bug against > org-mode, but oh well, thanks for the nudge: I just uploaded 7.8.06 to > unstable. > Cheers, > --Seb -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325152256.gs22...@onerussian.com
Bug#667511: RFS: updeb/1.0.3 [NEW] -- Non-interactive upgrade Debian system
On Wed, 04 Apr 2012, Vladimir Stavrinov wrote: > > idea... Also there is already unattended-upgrades in the archive if you > > want to automatically install security updates. > I know this package for a long time, but is not make the work the updeb > does. Look at report it produce. would you mind making one of such exemplar reports publicly available for the demonstration purposes? ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823151338.gr2...@onerussian.com
Re: Python: Including Nosetest
well -- if you discover some other way -- please let me know. Otherwise -- I have been doing exactly that -- cd build and run tests from there and where permits against the installed version under debian/tmp or debian/python-MODULE, e.g.: http://anonscm.debian.org/gitweb/?p=pkg-exppsy/brian.git;a=blob;f=debian/rules;hb=HEAD#l44 On Tue, 18 Oct 2011, Ole Streicher wrote: > This error comes from the fact, that the nosetest uses the current > directory as the first entry in the path and so tries to read the source > directory (pywcs/...) and not the build-and-not-installed-yet version in > build/lib.linux-x86_64-2.6/ (and ...2.7). Since I assume that it is not > very clean just to include that path (or chdir there before running the > test), I guess there is another solution on how to run nosetest during > package build? -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111018131054.gb32...@novo.onerussian.com
Re: Python: Including Nosetest
well, yeah -- but I would advise to run tests against "installed" version of the software -- who knows what was missing from their MANIFEST.in or setup.py files... although might require few more custom lines, testing against installed version IMHO provides better QA. Moreover some modules/projects even forbid (or discourage) in-source testing (e.g. IIRC numpy) also, depending on the setup, it might be wasting CPU while building extensions multiple times -- first in-place, then for installation Just my 0.1 cents On Tue, 18 Oct 2011, Ole Streicher wrote: > python setup.py build_ext -i > which builds the extension in-place. So my debian/rules looks like > override_dh_auto_test: > python setup.py build_ext -i && nosetests tests/test.py > This works fine for me, and I hope it will survive the review :-) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111018144710.gg10...@onerussian.com
Re: Debian/Ubuntu Package Developing with Docker
On Mon, 11 Nov 2013, Paul Tagliamonte wrote: > Hey gustavo and Tong, > On Mon, Nov 11, 2013 at 06:20:14PM +0800, gustavo panizzo wrote: > > On 11/11/2013 08:36 AM, Paul Tagliamonte wrote: > > > In fact, I have. I've got a few tools brewing for Debian that use > > > Docker. I've got it packaged and it'll be in Debian soon. > > do you have a package, even preview quality, to use it? > > i would check git.d.o but is down :( > No, not yet. This is all pre-published work. I've been following docker > upstream since they announced it (they announced it in a lightning talk > after my lightning talk announcing Hy :) ), and have been working a few > issues out (slowly) why then there is now two ITPs: (ITP - #730569) http://bugs.debian.org/730569 docker.io -- yours (ITP - #706060) http://bugs.debian.org/706060 lxc-docker -- upstream's ? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131127045033.ga26...@onerussian.com
build package for sarge and for sid from the same debian/control
I'm a new to the deb maintainers world so I have a question which bothers me: I have a project which I want to package for different distributions of debian, so from distro to distro there is change in "Build-Depends" options for package and also I need to use different compiler from default one which is used now in testing (it seems that I need to use g++-2.95 instead of default 3.2.3, cause libqt3 test compilation fails with newer g++, it seems that libqt with sarge compiled with g++-2.95, when default g++ is 3.2 already), so probably I need to provide "distribution-specific" CXX enviroenment variable in debian/rules. How to do all this? Thank you in advance for any hint and link .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17]
Bug#784898: I would be interested
to see this package in Debian so I can provide review/sponsorship when time allows (hopefully in the next day or so). meanwhile: - make package really ready -- vcs fields should point to existing repository. Do you want to keep it under collab-maint? Then please join the team at https://alioth.debian.org/projects/collab-maint and initiate that repository Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150610231526.gr28...@onerussian.com
Bug#775532: citeproc/data/schema/csl.rng license Re: Bug#775532: RFS: citeproc-py/0.3.0-1 [ITP] -- Python library for CSL based bibliography processing
On Tue, 12 May 2015, Andrey Rahmatullin wrote: > I'm afraid the license for citeproc/data/schema/ is not DFSG-free: > "Permission to freely use, copy and distribute." Dear Brecht, I am not sure if you were contacted already about this issue. The rights field of citeproc/data/schema/csl.rng is a bit too restrictive (e.g. not allowing modifications). I wondered if you have contact with original authors to seek clarification and possibly release under some DFSG compliant license? Thanks in advance -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614045803.ga5...@onerussian.com
Bug#775532: RFS: citeproc-py/0.3.0-1 [ITP] -- Python library for CSL based bibliography processing
On Fri, 19 Jun 2015, Daniel Stender wrote: > The state of the package is: I'm not sure if it's o.k. for it to get accepted > into the archive when a DFSG compliant change of the license is declared for > the project but the actual file headers state something different. > For that I've added a patch which disables the style check over by default for > the +dfsg package w/o the RELAX NG schemes which would do it until the files > get updated. With that the citeproc just does not warn for faulty custom > styles, > which is great to have but could be dispensed for a while [1]. > I would like to discuss this option with the sponsor, maybe it's possible to > push it non +dfsg already which a Comment link to the declaration of the > new licensing. > Anyway, I've uploaded the latest package to mentors [2]. sorry -- this issue fell of my radar :-/ I would like to sponsor this upload. I would be ok to sponsor upload without +dfsg and with a comment on relicensing (and pointer to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775532#57). or if you like I could review/upload as it is now. Just let me know Cheers -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150712145940.ga31...@hopa.kiewit.dartmouth.edu
Re: [Caffe] uploaded to mentors but NOT RFS
On Wed, 02 Sep 2015, lumin wrote: > Hi all, > (CC'ing people interested in package Caffe) > It takes so long time for Caffe to be packaged for Debian, > now the package is nearly prepared to be uploaded, and > there are still some small issues to be addressed. > http://anonscm.debian.org/cgit/debian-science/packages/caffe.git > My local build result (2 amd64 machines: chroot testing, and testing): > [debuild] [OK] > [d/rules:: custom-cpu] [OK] > [d/ruels:: custom-cuda] [OK] note that nvidia-cuda-toolkit is from non-free. And packages from main can't build-depend on non-free components :-/ It means that it might be necessary either to 1. move caffe into contrib (again, away from main :-( ) 2. or provide two source packages, of which main would build only CPU implementation while in non-free would build both/only GPU (depending how organized). Or is there a better solution which I am missing somehow? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#784898: I would be interested
Great to see activity going and please pardon me staying silent on this issue ;) Cheers everyone! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
