Re: RFS: haskell-dataenc
On Wed, Oct 31, 2007 at 17:21:42 +1100, Paul Wise wrote: Couple of comments: Scary looking package, perhaps there needs to be a dh_haskell that writes the correct stuff to the postinst/etc like there is for python. How do you mean scary? I followed the steps I found on the Haskell wiki[1] which make it very simple to create Debian packages. So I suspect the scary stuff was added by the automagical scripts. You forgot the ITP number in the changelog. It's about to be fixed. /M [1]: http://haskell.org/haskellwiki/Creating_Debian_packages_from_Cabal_package -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus signature.asc Description: Digital signature
Re: RFS: ustr (updated package)
James Antill wrote:
Hmm, I doubt Vaclav changed the Makefile and I'm pretty sure that
isn't the case in the upstream Makefile.
Note that it builds 4 versions of each file by default that look like:
*-so-dbg.o
*-so-opt.o
*-a-dbg.o
*-a-opt.o
That's good! As I said before - I didn't check it carefully, and most
upstreams don't care about such things.
Also the following warning appears pretty often:
ustr-main.h:859: warning: ‘map_big_pow2’ is static but declared in
inline function ‘ustr_xi__pow2’ which is not static
ustr-main.h:860: warning: ‘map_pow2’ is static but declared in inline
function ‘ustr_xi__pow2’ which is not static
ustr-main.h:863: warning: ‘map_big_pow2’ is static but used in inline
function ‘ustr_xi__pow2’ which is not static
ustr-main.h:865: warning: ‘map_pow2’ is static but used in inline
function ‘ustr_xi__pow2’ which is not static
That sounds fixable.
That code is basically:
extern inline size_t ustr_xi__pow2(int use_big, unsigned char len)
{
static const unsigned char map_big_pow2[4] = {2, 4, 8, 16};
static const unsigned char map_pow2[4] = {0, 1, 2, 4};
...so I'm pretty sure it's correct as is, and the version of GCC
used is giving out false warnings.
I doubt that.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00182.html
Cheers,
Bernd
--
Bernd Zeimetz
[EMAIL PROTECTED] http://bzed.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: throttle
All'incirca Sun, 22 Jul 2007 18:22:59 +0200, Nico Golde [EMAIL PROTECTED] sembrerebbe aver scritto: Hi, * Kartik Mistry [EMAIL PROTECTED] [2007-07-22 18:17]: On 7/22/07, Nico Golde [EMAIL PROTECTED] wrote: throttle - A bandwidth limiting pipe [...] As I said, throttle is too simple with 3 or 4 command line options written in mind with simple use. While, cstream has lots of options available to configure your need. Did you look at trickle? But trickle is different. Trickle is useful to limiting the bandwidth of a socket, throttle is for limiting the bandwidth of a standard stream. They're two different uses. I reply to this old thread because I too began to work on throttle, and asked for RFS some days ago. I didn't remember this thread and the ITP bug didn't report anything about it. Paul Wise then recalled it to me. Now the question is: cstream is more complex and trickle is different. I don't know of any similar programs. Should I continue on packaging and maintaining throttle (and waiting for someone to sponsor it), or should I ask Joey Hess to include it in moreutils (as Paul Wise suggested), or should I give up with throttle (writing in the ITP bug why did I do so)? Thank you, Giovanni. -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) signature.asc Description: PGP signature
Re: RFS: nted (3rd try)
Erik Schanze a écrit : Hi Gilles, Hi Erik, Gilles Filippini [EMAIL PROTECTED]: I am looking for a sponsor for my package nted. * Package name: nted Something to fix: - The author field in some translation files (*.po) is empty. - There are many warnings during compilation, so the build log is hard to read. I've forwarded to upstream. Is it possible to get any sound output without MIDI hardware (kernel module is loaded)? Just to test the program. Yes it is. See this page: http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/doc/timidity_server.html Kindly regards, Erik Thanks for the review, _gilles. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nted (3rd try)
Paul Wise a écrit : Quick review of the diff: Might want to remove the comments and other cruft from the manual page. Same for the watch file (it need only be 2 lines) Same for the rules file, you have lots of commands that are commented out, remove them if they are not needed. Please run sed -i -e s/septembre/September/ debian/nted.1 Don't forget to send the manual page to upstream. Don't forget to send a patch to upstream so that debian/dirs isn't necessary. Hi Paul, Thanks for this review. -- _gilles. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ustr (updated package)
Bernd Zeimetz [EMAIL PROTECTED] writes:
James Antill wrote:
That code is basically:
extern inline size_t ustr_xi__pow2(int use_big, unsigned char len)
{
static const unsigned char map_big_pow2[4] = {2, 4, 8, 16};
static const unsigned char map_pow2[4] = {0, 1, 2, 4};
...so I'm pretty sure it's correct as is, and the version of GCC
used is giving out false warnings.
I doubt that.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00182.html
From the above email:
This patch makes GCC's inline function support more like the C99
support. To be precise, it implements 6.7.4 paragraph 3
ISO 9899:1999, 6.7.4 paragraph 3 says:
An inline definition of a function with external linkage shall not
contain a definition of a modifiable object with static storage
duration, and shall not contain a reference to an identifier with
internal linkage.
...as both of the declarations are static const, 6.7.4#3 doesn't
apply.
--
James Antill -- [EMAIL PROTECTED]
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to just copy files that don't need compiled? and set up a cron job?
Hi, I could use some assistance building a package. I've been using this guide - http://www.debian.org/doc/maint-guide/ - and successfully build some packages for CPAN modules yesterday, which were fairly normal. Now I'm trying to build a somewhat simpler package but running into two main problems: getting a cron job set up and actually getting the perl scripts copied into the right locations. This package is just a few perl scripts and a perl module. It needs to go into a certain folder that doesn't exist normally. I added the custom directory they need to go into (/opt/gsi-tools) to the debian/dirs file and it is getting created when I install the package. (I know that's kind of a weird folder but higher powers have insisted that's where this stuff goes;-))... However the scripts are not getting copied in there. My build directory is /usr/local/src/gsi-tools/gsi-tools-1.7 and I've tried putting the scripts right in there, or in /usr/local/src/gsi-tools/gsi-tools-1.7/opt/gsi-tools but either way they don't get installed when I install the package. So I figure I need to add something into the debian/rules file to copy the files somehow. I've tried several things but the latest thing I tried which didn't work was: install: build dh_testdir dh_testroot dh_clean -k dh_installdirs mkdir -p $(CURDIR)/debian/opt/gsi-tools cp GSITools.pm $(CURDIR)/debian/opt/gsi-tools/ cp GSIManagementService.pl $(CURDIR)/debian/opt/gsi-tools The other part of my question is trying to set up a cron job. I tried adding the job into debian/cron.d.ex and in the debian/rules file I uncommented dh_installcron in the binary-arch: build install section, but the cron job is not being added to /etc/crontab or to root's crontab (it needs to run as root). I've also tried adding a command into the postinst.ex in the configure section to echo/append the job to /etc/crontab, and another command in prerm.ex to remove that line from the crontab but even with that the cron job still never shows up. Thanks!
Re: how to just copy files that don't need compiled? and set up a cron job?
Am Donnerstag, den 01.11.2007, 08:38 -0500 schrieb Jeremy Martin:
[..]
This package is just a few perl scripts and a perl module. It needs to
go into a certain folder that doesn't exist normally. I added the
custom directory they need to go into (/opt/gsi-tools) to the
debian/dirs file and it is getting created when I install the package.
(I know that's kind of a weird folder but higher powers have insisted
that's where this stuff goes;-))...
Why?
However the scripts are not getting copied in there. My build
directory is /usr/local/src/gsi-tools/gsi- tools-1.7 and I've tried
putting the scripts right in there, or
in /usr/local/src/gsi-tools/gsi-tools-1.7/opt/gsi-tools but
^
$(PACKAGE)/
either way they don't get installed when I install the package.
Please read debhelper(1). The default location (for files) to package is
debian/$(PACKAGE) - even since compatibility level 2.
[snip debian/rules code with the same issue]
The other part of my question is trying to set up a cron job. I tried
adding the job into debian/cron.d.ex and in the debian/rules file I
uncommented dh_installcron in the binary-arch: build install
section, but the cron job is not being added to /etc/crontab or to
root's crontab (it needs to run as root).
It's AFAIK never added to /etc/crontab. dh_installcron(1) installs
cron-scripts into /etc/cron.{d,hourly,daily,weekly,monthly}/.
I've also tried adding a command into the postinst.ex in the configure
section to echo/append the job to /etc/crontab, and another command in
prerm.ex to remove that line from the crontab but even with that
the cron job still never shows up.
Independent that this is not necessary, you have to remove the .ex
suffixes. These are example files, that are not considered by debhelper
scripts. For me it sounds, you left the suffixes.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How a package will determine the dependencies
hi i have a library and want to package it But it has a configuration option as --enable-debug=yes/no So i need to make 2 packages as 1) libinput0 2) libinput0-debug So now if an application uses libinput, how the $(shlibs:Depends) variable get substituted, during application package being built. Because dpkg will automatically determine and substitute the variable according to which one of the above two lib packages are installed, at the time of application package being built. The application must work with any of the above packages should i manually write libinput0 | libinput0-debug in Depends field. Or is there a some other way to do it. thanks and regards varun -- View this message in context: http://www.nabble.com/How-a-package-will-determine-the-dependencies-tf4732207.html#a13531374 Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to just copy files that don't need compiled? and set up a cron job?
hi try this mkdir -p $(CURDIR)/debian/package-name/opt/gsi-tools cp GSITools.pm $(CURDIR)/debian/package-name/opt/gsi-tools/ cp GSIManagementService.pl $(CURDIR)/debian/package-name/opt/gsi-tools bye varun -- View this message in context: http://www.nabble.com/how-to-just-copy-files-that-don%27t-need-compiled--and-set-up-a-cron-job--tf4731421.html#a13531728 Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 08:57:19AM -0700, varun_shrivastava wrote: hi i have a library and want to package it But it has a configuration option as --enable-debug=yes/no So i need to make 2 packages as 1) libinput0 2) libinput0-debug I think the recommended way to do this [0] is to build with debugging symbols then move the debugging symbols to a separate file, and associate the dbg files with the normal runtime files. Justin [0] see the developers' references and at least one bug against such. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to just copy files that don't need compiled? and set up a cron job?
On Thu, 01 Nov 2007, Jeremy Martin wrote:
The other part of my question is trying to set up a cron job. I tried adding
the job into debian/cron.d.ex and in the debian/rules file I uncommented
dh_installcron in the binary-arch: build install section, but the cron job
is not being added to /etc/crontab or to root's crontab (it needs to run as
root).
Mucking about with /etc/crontab should not be done by packages, since
there's never any valid reason to do so.[1] If your script needs to be
run daily as root (or a similar interval for which directories exist)
put the script in /etc/cron.{daily,weekly,monthly,hourly}. If it needs
to be run more often, then stick a crontab entry in /etc/cron.d.
man cron; and see /etc/crontab; for details.
Don Armstrong
1: Well, ignoring packages like cron and anacrontab, anyway.
--
It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.
-- Andrew Suffield in [EMAIL PROTECTED]
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: prboom (updated package)
Thanks for the CC Miriam or I may have missed this! Right now I have a prboom package I was about to upload to mentors which Moritz was going to sponsor. It Replaces: lxdoom as we're trying to get that out of the archive. So this is interesting timing. I'd appreciate it if all packages that are requested to be sponsored were based on the package that is currently in SVN, as I'm sure every games team member appreciates! :-) Regarding Marco's improvements to the package: I kept the desktop file that he added to SVN but I reverted the icon for copyvio reasons. I can understand that being a simple mistake. I also had to revert the addition of an install file that actually caused the package to FTBFS. That was mildly irritating as it suggested that the check-in to trunk wasn't tested, but is explained by Marco's relative newness to SVN. Marco: I'm not following the situation with regards your SVN access, but assuming you have it back now (or in the future), would you mind making commits into a branch? I'll happily cherry-pick them across to trunk, and I just ask this whilst you get to grips with SVN. As for the other changes that are not committed, there's no real rush on package uploads at the moment, so I'd like to wait until the next version for those, and get them into SVN first (so someone else can test them too). -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Removing non-Linux files from source tarballs
Hello, mentors. I'm currently working on Processing (#433270). Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? Processing also distributes its own Java and Jikes compilers, and of course those have to be removed. I'll need to patch the build process in order to make sure that it will work with Debian's versions of these packages. Oh, and it looks like it'll have to go into contrib, until Java becomes completely free. :-/ Confirm, deny? Thanks, - Jordi G. H. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: Hello, mentors. I'm currently working on Processing (#433270). Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? I forget if it's policy or devref which prefers *not* removing them unless you're already using a nonpristine sourceball or it would save significant space, (with the justification that people might like to use the debian sources for nondebian things) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to just copy files that don't need compiled? and set up a cron job?
varun_shrivastava wrote: hi try this mkdir -p $(CURDIR)/debian/package-name/opt/gsi-tools cp GSITools.pm $(CURDIR)/debian/package-name/opt/gsi-tools/ cp GSIManagementService.pl $(CURDIR)/debian/package-name/opt/gsi-tools why so complicated? man dh_install Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 08:57:19AM -0700, varun_shrivastava wrote: i have a library and want to package it But it has a configuration option as --enable-debug=yes/no So i need to make 2 packages as 1) libinput0 2) libinput0-debug So now if an application uses libinput, how the $(shlibs:Depends) variable get substituted, during application package being built. Because dpkg will automatically determine and substitute the variable according to which one of the above two lib packages are installed, at the time of application package being built. It won't be a problem, because the -dbg package (the standard suffix isn't -debug) doesn't have full copies of the library, just the debugging symbols. The only place where you could run into trouble would be if --enable-debug for this package doesn't just enable -g -O0 and disable stripping, but instead actually modifies the source to be compiled (such as adding fprintf(stderr, DEBUG: Got here\n) throughout the source, or something else similarly irritating). If that's the case, then you've got a real problem, as I can't think of a really good solution to that. I suspect the best solution there is going to be to have the regular library and the -dbg library *conflict* with each other, and have the -dev package depend on only the non-dbg version, so anyone who's building against the library is guaranteed to only have the non-dbg version installed. That is, however, unbelievably ugly, and largely defeats the purpose of having a -dbg version of the library, because the people who are going to want the debugging-enabled library are the people who are linking against the library... I would suggest working out exactly what --enable-debug does to the library build process, and changing anything that isn't symbol related to be run-time rather than build-time configured (so enabling any fprintf(stderr, DEBUG: ) with an environment variable rather than #ifdef), and then the problem reverts to the standard strip symbols, stick symbols in -dbg package method. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, 1 Nov 2007 13:17:26 -0600, Jordi Gutiérrez Hermoso [EMAIL PROTECTED] said: Hello, mentors. I'm currently working on Processing (#433270). [...] Oh, and it looks like it'll have to go into contrib, until Java becomes completely free. :-/ Confirm, deny? See if it works with, e.g. gij + classpath. Otherwise, yes, it will have to go into contrib. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On 01/11/2007, Justin Pryzby [EMAIL PROTECTED] wrote: On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: Hello, mentors. I'm currently working on Processing (#433270). Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? I forget if it's policy or devref which prefers *not* removing them unless you're already using a nonpristine sourceball or it would save significant space, It would save 20 megs from the source package. Is that considerable enough for their removal? - Jordi G. H.
Re: Removing non-Linux files from source tarballs
On 01/11/2007, Hubert Chathi [EMAIL PROTECTED] wrote: On Thu, 1 Nov 2007 13:17:26 -0600, Jordi Gutiérrez Hermoso [EMAIL PROTECTED] said: Hello, mentors. I'm currently working on Processing (#433270). [...] Oh, and it looks like it'll have to go into contrib, until Java becomes completely free. :-/ Confirm, deny? See if it works with, e.g. gij + classpath. Otherwise, yes, it will have to go into contrib. I haven't been able to make it work with anything but Sun's Java. The upstream authors confirm this. - Jordi G. H.
Re: how to just copy files that don't need compiled? and set up a cron job?
On 11/2/07, Jeremy Martin [EMAIL PROTECTED] wrote: (I know that's kind of a weird folder but higher powers have insisted that's where this stuff goes;-)) mkdir -p $(CURDIR)/debian/opt/gsi-tools cp GSITools.pm $(CURDIR)/debian/opt/gsi-tools/ cp GSIManagementService.pl $(CURDIR)/debian/opt/gsi-tools Why are you trying to install into /opt/gsi-tools/? GSIManagementService.pl should probably be /usr/bin/GSIManagementService or /usr/sbin/GSIManagementService and GSITools.pm in /usr/lib/perl5/ - see the perl policy for more details: http://www.debian.org/doc/packaging-manuals/perl-policy/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On 11/2/07, Jordi Gutiérrez Hermoso [EMAIL PROTECTED] wrote: Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? If there is no source for them in the tarball, yes. If there is source in the tarball, I'd suggest that it is worth the space saving to remove them. Since you are manually creating the orig.tar.gz from SVN anyway, obviously leave them out since they are not source code. And add a get-orig-source target to recreate the tarball automatically. And get upstream a clue :) -- bye, pabs http://wiki.debian.org/PaulWise
Re: How a package will determine the dependencies
hi actually the library uses g_log kind of debugging technique ie some #defines are there, so when log is enabled #defines get replaced by g_log(***), and when its disabled #defines get replaced by (void)0 But i have a bigger problem thats the library has one more option of --enable-sdl=yes/no , I checked the source code and enabling it adds a huge amount of code to standard library. What to do now? thanks for your reply varun -- View this message in context: http://www.nabble.com/How-a-package-will-determine-the-dependencies-tf4732207.html#a13542239 Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
