xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Hi, I'm forwarding this message to -mentors, is there anybody who can help? thanks (the same post on debian-x didn't have any answer). - Forwarded message from Mattia Dongili <[EMAIL PROTECTED]> - Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 From: Mattia Dongili <[EMAIL PROTECTED]> Date: Mon, 3 May 2004 17:51:56 +0200 To: Debian X Mailing List X-Operating-System: Linux 2.6.5-1 i686 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Disclaimer: Buh! Hi all, the subject[1] says it all, will it ever be an xserver-xfree86 for s390? otherwise I'd better chance my package's Architecture field before sarge Since xfree86 is Architecture: any, I've been suggested to have the same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [1] http://qa.debian.org/developer.php?excuse=xfree86-driver-synaptics thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: [...] > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 [...] > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge > Since xfree86 is Architecture: any, I've been suggested to have the > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [...] Personally I'd immediately change the architecture field and change it back once there is a xserver for s390. - You'll probably have to pester ftp-master to remove the old s390 binary, otherwise xfree86-driver-synaptics will be blocked by "out of date on s390". cu andreas
RFS: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back
Hello! This very useful package (I hope not only for me ;-) was orphaned last month and was unmaintained for 2 years. I have adopted it. I prepared my first (official) debian packages, and I'm looking for sponsor for it. The upload will close 4 bugs. The package is linda and lintian clean. --- Package name: txt2pdbdoc License: GPL Description: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back This utility converts plain text files (or HTML files) to the de facto PalmOS standard DOC format for use in document readers (such as "C Spot Run") and editors (such as "ZDOC"). DOC files are compressed by default, and txt2pdbdoc can also convert DOC files back to plain text. . WARNING: Generated PDB files (for this and previous versions) may cause problems on the Palm if they are installed by some method other than hotsyncing (e.g. via a memory card). See bug #118930 for details. Package Download: http://www.erikschanze.de/debian/ Thanks for taking your time, Erik -- www.ErikSchanze.de * Bitte keine HTML-Mails! No HTML mails, please! Maillimit: 1 MB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linuxinfotag.de *
V.icodin Pre.scriptions
Buy your drug of choice, NO prescription required Today's special: Free overnight Fedex delivery Vicodin.$2.53/dose Hydrocodone$2.10/dose Xanax...$2.50/dose Valium..$2.69/dose Phentermine..$0.84/dose Stock is limited and selling fast, so hurry Buy them here
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > Hi all, > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge There is, today. Notice that xfree86 itself was also stalled by it... Expect your package to go in tomorrow. Do not simply change the architecture field because one or two architectures are behind, rather, try to research *why* your package doesn't go to testing. In this case, Bjorn's page shows wrong information (Cc'ing him). It said: Adding xfree86-driver-synaptics makes 1 non-depending packages uninstallable on s390: xfree86-driver-synaptics But xfree86-driver-synaptics wasn't in testing to begin with (at least, afaics). Exact reason I don't understand (Sarge's X did have s390), but it doesn't matter anymore. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I personally disagree: - it's an ugly workaround - it's hiding problems (s390 failures) - there is no good reason to not support s390, so your removal request might even be rejected (I don't know of course what would really happen, I cannot speak for ftp-master of course). - it adds extra workload to ftp-master, which is unnecessary - it means two extra unnessesary uploads, causing extra load on the buildd's, again, quite unneeded --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Jeroen van Wolffelaar wrote: > In this case, Bjorn's page shows wrong information (Cc'ing him). > It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics This information is grabbed on from update_output.txt, a result file that is produced by the official nightly Debian Testing scripts: trying: xfree86-driver-synaptics skipped: xfree86-driver-synaptics (0 <- 70) got: 26+0: a-2:a-2:h-3:i-0:i-2:m-2:m-5:m-5:p-0:s-5 * s390: xfree86-driver-synaptics (http://ftp-master.debian.org/testing/update_output.txt) I wish there were more details I could show in my script, but there isn't. -- Björn
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... > > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: Oops, I was wrong... I checked out the xfree86 source package, but not the xserver-xfree86 binary package of it. Indeed, it is not available on s390, and never will, since s390 is a mainframe without input controls. Also, s390 doesn't have any possibility to connect a touchpad to. I don't really know what to do about it, maybe ask d-d (this is a quite tricky problem) or debian-release. Some suggestions I heard: - contact ftp-master to add this one to Packages-arch-specific - make your package FTBFS on s390, and have ftp-master remove the s390 binary. It will propagate nicely then, a FTBFS on an unsupported architecture is possible. But this will make s390 attempt to build it, so isn't really nice to do. So the best thing you can do is ask ftp-master for advice I think. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) a light and simplistic resource monitof for X. I am in the process of learning to properly use debian packaging tools, and already managed to make a package that installs, uninstalls and works correctly, but I can't figure out what lintian warns me about: $lintian -i torsmo_0.15-1_i386.changes W: torsmo source: changelog-should-mention-nmu N: N: When you NMU a package, that fact should be mentioned on the first N: line in the changelog entry. N: W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 N: N: A source NMU should have a Debian revision of '-x.x'. This is to N: prevent stealing version numbers from the maintainer (and the -x.x.x N: version numbers are reserved for binary-only NMU's). What configs should I fix, or is this normal in some cases? packages and other related files I made can be downloaded from http://boogeyman.homeunix.org/debian/unstable/torsmo/ Also I need a sponsor when I get the guality of mu packaging work good enough. If someone wants to sponsor me, I suggest that this version of torsmo is not uploaded to archives, because the next version probably gets released soon (and is better and more mature than this version) -- Juuso Tähkäpää
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... ok, thanks. Better than a swiss timer (as we say in Italy) :) > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics I was actually referring to QA pages excuse: xfree86-driver-synaptics/s390 unsatisfiable Depends: xserver-xfree86 (>= 4.3.0) This actually hides a bug in my package (mea culpa), the correct Depends fields should be since this driver works with XFree86-4.2 too: Depends: xserver-xfree86 (>> 4.1.0) Moreover some considerations could be done about the usefulness of a Synaptics Touchpad driver on S390, I strongly doubt we will ever see it :) Anyway thanks a lot for the explanation and help -- mattia :wq!
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
> Uploaded to http://mentors.debian.org/ Failed to fetch http://mentors.debian.net/debian/pool/main/l/lis/lis_2.16.16.orig.tar.gz 404 Not Found Looks like you didn't include the original source with your upload. This is because your package version is neither -0 nor -1, so dpkg-genchanges did not include the original source in the list of files. From the dpkg-buildpackage manpage: "By default, or if -si is specified, the original source will be included if the version number ends in -0 or -1, ie if the Debian revision part of the version number is 0 or 1." Will try to grab the original source and slap on your diff to have a look at your lintian error. Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Hi again Thomas, I just had a look at your control file.. it's HUGE as you define all the kernel-lis-modules-2.4.26-1-(386|586tsc|etc..) packages! I suggest you take a look at how alsa or pcmcia-cs are packaged and create an "lis-source" package in your control file. You should not be building all these different flavours from your main control file. What you want to do is build : lis, lis-dev, lis-doc, lis-source. The "lis-source" package is the one that will be used to build the actual kernel modules. To do so you will provide a template called "lis-source.control" in your main package which will define the various kernel module packages. Once again, I recommend you take a look at how ALSA or the PCMCIA packages are built! Cheers, Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux
NML vs Octave
Okay Ive decided on the name NML (Numerical Methods Library) Where Odes are concerned. I've implemented 10 different solving schemes. The 2 most promising are seen below vs Octave executed 100 times the equation dy/dx = y*tan(x) [y = sec(x)] which is even more unstable than dy/dx = 1 + y^2. [y = tan(x)]: Real : y(1.57) = 1255.7659 Octave: y(1.57) = 1255.7708 (2.88 sec) Predictor-corrector: y(1.57) = 1211.35(0.32 sec) or y(1.57) = 1233.83(0.64 sec) Runge kutta order 4: y(1.57) = 1255.7659 (exact) (0.59 sec) Runge kutta 4 rocks. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
ITA: filler - Simple game in Java
Good evening. My name is James Damour, and I would like to adopt the filler package that the Debian QA team has orphaned. I have made my first modifications to the package, and I have uploading them to http://mentors.debian.net. I would appreciate it if a sponsor could review my packaging, and let me know what I should change in order to get it ready for upload to the Debian archive. I've fixed all lintian or linda errors, and the remaining linda warning may be a bug (as a game, filler needs to be rwxr-sr-x and linda is expecting rwxr-xr-x). I expect that I'll get a FTBFS error because I can not specify a compliant Java Development Kit from within the Debian archive (filler requires Swing technology, and I haven't found a VM that will build it, but I'm still looking). Any assistance in this area would be greatly appreciated. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: NML vs Octave
Hi The Brusselator is a system of odes. I'm implementing the algorithm for a system of odes right now using RK4. All I could find out about the Brusselator equation is that is used a lot in chemistry. You seem to know a lot about odes. Does that extend to all of numerical analysis?. If there is a paper you know about that i can read please let me know. Also I found a GNU project similar to mine the GNU Scientific Library (GSL) www.gnu.org/software/gsl/ Its also a C library for numerical analysis. If anyone knows alot about numerical analysis I'd appreciate if you could compare the GSL with my NML numerical.port5.com As far as I can see, setting up the GSL for comutation looks tougher than for the NML. Regards __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
Re: RFS: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back
Erik Schanze: > --- > Package name: txt2pdbdoc > > License: GPL > > Description: > txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back > This utility converts plain text files (or HTML files) to the de facto > PalmOS standard DOC format for use in document readers (such as "C Spot > Run") and editors (such as "ZDOC"). DOC files are compressed by > default, and txt2pdbdoc can also convert DOC files back to plain text. > . > WARNING: Generated PDB files (for this and previous versions) may cause > problems on the Palm if they are installed by some method other than > hotsyncing (e.g. via a memory card). See bug #118930 for details. > > Package Download: http://www.erikschanze.de/debian/ > I discussed my translation of debconf template with Gerd Fuchs from debian-l10n-german list and have done some improvements. So please look over updated package under http://www.erikschanze.de/debian/ or should I upload package to mentors.debian.net instead? BTW: Is there any need to give dpkg-buildpackage the option -v (-v1.4.2-2 in my case) to say dh_genchanges that a previous version is still in archive? I noticed no differences between calls with this option or not. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-Mails! No HTML mails, please! Maillimit: 1 MB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linux-info-tag.de *
Re: ITA: filler - Simple game in Java
James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > Good evening. My name is James Damour, and I would like to adopt the > filler package that the Debian QA team has orphaned. I have made my > first modifications to the package, and I have uploading them to > http://mentors.debian.net. Hi, I cannot offer you to sponsor your package, as I understand no Java, and any error would probably slip under my nose. Anyway, if you have the package ready, please retitle bug #232868 to 'ITA: filler - Simple game in Java' - You can do this by sending the following line as a mail to [EMAIL PROTECTED]: retitle 232868 ITA: filler - Simple game in Java I noticed you already replied to that bug report, but when people look at the WNPP packages, filler still appears as orphaned - do this just to save other people the effort in opening the report and checking. > I would appreciate it if a sponsor could review my packaging, and let me > know what I should change in order to get it ready for upload to the > Debian archive. I've fixed all lintian or linda errors, and the > remaining linda warning may be a bug (as a game, filler needs to be > rwxr-sr-x and linda is expecting rwxr-xr-x). > > I expect that I'll get a FTBFS error because I can not specify a > compliant Java Development Kit from within the Debian archive (filler > requires Swing technology, and I haven't found a VM that will build it, > but I'm still looking). Any assistance in this area would be greatly > appreciated. If your package requires a non-free JDK, then it will enter contrib (instead of main) and will not be autobuilt, so don't worry, you will not get the dreaded FTBFS ;-) Just please note somewhere visible (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it and where can it be found. Also, double check: Can Filler be used with any of the existing JVMs in Debian? If not, it would not be useful at all, and instead of adopting it, you should file for its removal from the archive. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: NML vs Octave
Halim Boukaram wrote: > I've implemented 10 different solving schemes. The 2 most promising > are seen below vs Octave executed 100 times the equation dy/dx = > y*tan(x) [y = sec(x)] ... This is really off-topic for debian-mentors. Could this discussion (except for any questions about Debian packaging) be moved to a better forum such as sci.math.num-analysis, or maybe a GNU Octave list?
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Thanks for replying Jeremy, comments on your suggestions inlined. For anyone interrested the complete packages (including .orig.tar.gz) are available in http://nthomas.free.fr/LiS But my trouble remains : lintian -i lis_2.16.16-2.dsc E: lis source: package-uses-debhelper-but-lacks-build-depends N: N: If a package uses debhelper, it must declare a Build-Depends on N: debhelper. N: but lis_2.16.16-2.dsc is: -- Format: 1.0 Source: lis Version: 2.16.16-2 Binary: kernel-lis-modules-2.4.26-1-k7-smp, kernel-lis-modules-2.4.26-1-386, kernel-lis-modules-2.4.26-1-686-smp, lis-doc, kernel-lis-modules-2.4.26-1-k7, lis, kernel-lis-modules-2.4.26-1-686, lis-dev, kernel-lis-modules-2.4.26-1-k6, kernel-lis-modules-2.4.26-1-586tsc Maintainer: Nicolas THOMAS <[EMAIL PROTECTED]> Architecture: any Standards-Version: 3.6.1 Build-Depends: debhelper (>> 4.0.0), kernel-build-2.4.26-1, dbs, m4 Files: 082c8612dce46236282b97d8af4c3f01 792684 lis_2.16.16.orig.tar.gz c5c53afc74063dfa91c35939b390f69f 10461 lis_2.16.16-2.diff.gz -- It as a build-depends on debhelper !! what do I miss ?? More inlined : Quoting Jeremy Lainé <[EMAIL PROTECTED]>: > Hi again Thomas, > > I just had a look at your control file.. it's HUGE as you define all the > kernel-lis-modules-2.4.26-1-(386|586tsc|etc..) packages! I suggest you > take a look at how alsa or pcmcia-cs are packaged and create an > "lis-source" package in your control file. > > You should not be building all these different flavours from > your main control file. What you want to do is build : lis, lis-dev, > lis-doc, lis-source. The "lis-source" package is the one that will be > used to build the actual kernel modules. To do so you will provide a > template called "lis-source.control" in your main package which will > define the various kernel module packages. Once again, I recommend you > take a look at how ALSA or the PCMCIA packages are built! What I want is to be able to provide binary packages for debian "official" kernels for now own the automated creation of a big control file and .(pre|post)inst is working. I don't believe it's against policy (correct me if I'm wrong) but fully agree to have a close look at your proposal to easily allow anyone to build modules for it's own kernel. I2C for 2.4 kernels use a similar approach. Anyway I do not see how all this is related to the lintian error .. I first have to work on packaging 2.16.18 version then I'll have a deep look at making a lis-source and make-kpkg template. Thanks > > Cheers, > Jeremy > > -- > http://www.jerryweb.org/ : JerryWeb.org > http://sailcut.sourceforge.net/ : Sailcut CAD > http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > --
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Nicolas THOMAS wrote: Thanks for replying Jeremy, comments on your suggestions inlined. For anyone interrested the complete packages (including .orig.tar.gz) are available in http://nthomas.free.fr/LiS But my trouble remains : lintian -i lis_2.16.16-2.dsc E: lis source: package-uses-debhelper-but-lacks-build-depends N: N: If a package uses debhelper, it must declare a Build-Depends on N: debhelper. N: Remove first (empty) line of the 'control' file. Lintian that source package is described before first empty line. -- Eugeniy Meshcheryakov Kyiv National Taras Shevchenko University Information and Computing Centre http://icc.univ.kiev.ua
Re: testing config/preinst mods
> > For config scripts, in the absence of something pre-existing, one > > approach that looks like it would work pretty easily would be to > > replace apt-extracttemplates (which is called by dpkg-preconfigure) > > with something that would check a magic directory for replacement > > scripts for a package and use those instead of the real ones if they > > exist. > > I have never heard of something like this - but it would be simply > great! Not only that it would make testing easier, but also because if > some strange bug is reported, one could put debugging code at the right > places of the script, send it to the bug submitter and ask him to make > dpkg use it. I had a couple of hours over the weekend to implement and test this. I used it today to create patches for two outstanding bugs including three merged release-critical bugs against console-common. I'll post my solution to debian-devel today with the subject "testing config/preinst mods: one approach". -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: python-utidylib -- Python wrapper for TidyLib
Hello, I'm looking for a sponsor for python-utidylib (http://bugs.debian.org/244110): Package name: python-utidylib Version : 0.2 Upstream Author : Cory Dodt <[EMAIL PROTECTED]> URL : http://utidylib.sourceforge.net/ License : MIT Description : Python wrapper for TidyLib uTidylib provides Python wrapper for TidyLib, HTML syntax checker and reformatter. This allows you to tidy HTML files through a Pythonic interface, with all the options that Tidy command line supports. In short, it turns awful cowboy HTML into sexy standard-compliant HTML. sources.list: deb http://fluid.sparcs.net/debian/ unstable/all/ deb-src http://fluid.sparcs.net/debian/ unstable/source/ I also want to package API documentation of python-utidylib. There is a tool(gendoc.py) to do so in the source distribution, but I'm not sure how to handle it for Debian. Any suggestion is appreciated. Regards,
Init Script for Arbitrary Number of Daemons
The "skeleton" "init.d" file is a great default for starting _one_ daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, however, what this newbie package developer should do to start an arbitrary number of daemons, each with - potentially - different "$DAEMON_OPTS". It's nice to be able to throw "$DAEMON_OPTS" into "/etc/default/package" and get get a bit more control over the daemon; but I can't think how to nicely specify an arbitrary number of "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. I'm still searching for a solution... Input much appreciated! Thanks! Jack
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
Juuso Tähkäpää <[EMAIL PROTECTED]> schrieb: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? You know what an NMU is? If not, read the respective parts of the Developer's Reference. I don't know what's the cause in your particular case (and didn't download the package). But it seems that lintian thinks this will be a non-maintainer-upload - perhaps because names in debian/changelog and debian/control don't match? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, May 11, 2004 at 01:52:55PM +0300, Juuso T?hk?p?? wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? I got from the .changes: Maintainer: Juuso T??hk??p <[EMAIL PROTECTED]> Changed-By: Juuso Thkp <[EMAIL PROTECTED]> which is the cause. You should write your name in debian/control at 'Maintainer:' in UTF-8 too for the Debian archive scripts to recognise this is the same person (and thus recognise it as a maintainer upload, rather than a Non-Maintainer Upload aka NMU). Historically, only plain ASCII (that is excluding the a with ) is allowed in debian/control, but if you're going to violate that (unwritten) rule (which is quite common and an understandable wish) you should use UTF-8. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, 11 May 2004 22:36:04 +0200 Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > Historically, only plain ASCII (that is excluding the a with call that in finnish?>) is allowed in debian/control, but if you're > going to violate that (unwritten) rule (which is quite common and an > understandable wish) you should use UTF-8. So it is better to avoid weird characters and use slightly "wrong" name? Lesson learned! -- Juuso Tähkäpää
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, 11 May 2004 14:37:43 +0200 Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote: > Where did you find so complicated dependencies? As I was (late at night) just trying to get the package working I didn't use too much time thinking about dependencies... I just blindly followed Debian New Maintainers' Guide's "hack you can use to find out which packages your package needs" and moved on. Torsmo actually seems to need help2man (>=1.27), xlibs-dev (>=4.1.0), debhelper (>=4.0.2). (versions are what woody has to offer; torsmo compiles cleanly on woody (and on almost any other distros)) It seems to me that some kind of version requirements are a good thig... -- Juuso Tähkäpää
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
Second round with many lessons learned. -actual (?) build-dependencys in debian/control -no editing of the configure-script -no "illegal" characters in control or changelog If someone still cares to see what else I am doing wrong, new files are on http://boogeyman.homeunix.org/debian/unstable/torsmo/ On Tue, 11 May 2004 13:52:55 +0300 I wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly. > Also I need a sponsor when I get the guality of mu packaging work good > enough. If someone wants to sponsor me, I suggest that this version of > torsmo is not uploaded to archives, because the next version probably > gets released soon (and is better and more mature than this version) -- Juuso Tähkäpää
Re: ITA: filler - Simple game in Java
On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > Good evening. My name is James Damour, and I would like to adopt the > > filler package that the Debian QA team has orphaned. I have made my > > first modifications to the package, and I have uploading them to > > http://mentors.debian.net. > > Hi, > > I cannot offer you to sponsor your package, as I understand no Java, > and any error would probably slip under my nose. Anyway, if you have > the package ready, please retitle bug #232868 to 'ITA: filler - Simple > game in Java' - You can do this by sending the following line as a > mail to [EMAIL PROTECTED]: > > retitle 232868 ITA: filler - Simple game in Java > > I noticed you already replied to that bug report, but when people look > at the WNPP packages, filler still appears as orphaned - do this just > to save other people the effort in opening the report and checking. > Done. > > I would appreciate it if a sponsor could review my packaging, and let me > > know what I should change in order to get it ready for upload to the > > Debian archive. I've fixed all lintian or linda errors, and the > > remaining linda warning may be a bug (as a game, filler needs to be > > rwxr-sr-x and linda is expecting rwxr-xr-x). > > > > I expect that I'll get a FTBFS error because I can not specify a > > compliant Java Development Kit from within the Debian archive (filler > > requires Swing technology, and I haven't found a VM that will build it, > > but I'm still looking). Any assistance in this area would be greatly > > appreciated. > > If your package requires a non-free JDK, then it will enter contrib > (instead of main) and will not be autobuilt, so don't worry, you will > not get the dreaded FTBFS ;-) Just please note somewhere visible > (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it > and where can it be found. Also, double check: Can Filler be used with > any of the existing JVMs in Debian? If not, it would not be useful at > all, and instead of adopting it, you should file for its removal from > the archive. The file, /usr/share/doc/filler/README.Debian mentions both the Blackdown and the Sun VMs. It does not *explicitly* state that these are needed to rebuild the source; do you think that I should update the file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, and neither currently support the Swing APIs used by filler, but I'm very hopeful that they will quite soon. As such, and considering the age of the package (it's been in Debian for over 3 years) I'd prefer to leave the package in Debian, and just have it limp along until FLOSS Java catches up to it. > > Greetings, Thank you for your feedback. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
RE:'RTCProd=005-232-113'Re:hello
Thank you for the information provided. To ensure the most appropriate person answers your question, I forwarded your e-mail message to a group that specializes in this area. You should receive a response from this group within 24 business hours (one business day). If you do not receive a response from them, or have any additional questions, please reply to this e-mail message. You may also contact us by calling the Microsoft Sales and Information number at (800) 426-9400. This phone number is available Monday through Friday, 6:00 A.M. to 5:30 P.M. Pacific time. For your convenience, I have included the following Web sites that you may find helpful: Microsoft Product Support and Knowledge Base http://support.microsoft.com Microsoft Developer Network http://msdn.microsoft.com Microsoft TechNet Online http://technet.microsoft.com Purchase and review Microsoft Products http://shop.microsoft.com -Original Message- From: debian-mentors@lists.debian.org [EMAIL PROTECTED] Sent: Tuesday, May 11 2004 6:48PM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject:Re:hello Re:hello
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said: > The "skeleton" "init.d" file is a great default for starting _one_ > daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, > however, what this newbie package developer should do to start an > arbitrary number of daemons, each with - potentially - different > "$DAEMON_OPTS". > > It's nice to be able to throw "$DAEMON_OPTS" into > "/etc/default/package" and get get a bit more control over the daemon; > but I can't think how to nicely specify an arbitrary number of > "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. > > I'm still searching for a solution... Input much appreciated! I am not exactly sure what you mean by arbitrary - I'm assumin you have a real number in mind, but that it could vary (e.g., some may not be selected to actually run at boot, or all could, depending on the setup). If the daemons are useful independently of each other, package them seperately. If not, try one of the following. You can use multiple init scripts, or you can take a look at the init scripts of packages that start multiple daemons (slapd and samba come to mind) for examples of how others do it. If you just want seperate defaults, seperate lines in /etc/default/package would work well - it's just sourced, so DAEMON_1_OPTS="..." DAEMON_2_OPTS="..." etc. If you really mean arbitrary, in the sense that you have no idea how many, I can't help :) HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0i5wUbt68j.pgp Description: PGP signature
Re: ITA: filler - Simple game in Java
On (11/05/04 21:37), James Damour wrote: > On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > > I would appreciate it if a sponsor could review my packaging, and let me > > > know what I should change in order to get it ready for upload to the > > > Debian archive. I've fixed all lintian or linda errors, and the > > > remaining linda warning may be a bug (as a game, filler needs to be > > > rwxr-sr-x and linda is expecting rwxr-xr-x). As for SGID - if this is java game, so you most probably have a shell wrapper. S[UG]ID bits do NOT work on shell scripts. You can have the bits set but they will be ignored. So I suspect linda may check that your wrapper is a shell script and then - sgid bit makes no effect anyway. What you probably could do is write a small C wrapper, but then your package would have to be autobuild on all architectures, which will not happen for a package in contrib... So getting back to the sources of SGID - the bit is there so that games played independently by difrent users could store the "best score" values in a shared place. If you don't set the bit you can not use this functionality. Well, not a terribly big loss probably. > > If your package requires a non-free JDK, then it will enter contrib > > (instead of main) and will not be autobuilt, so don't worry, you will > > not get the dreaded FTBFS ;-) Just please note somewhere visible [...] > The file, /usr/share/doc/filler/README.Debian mentions both the > Blackdown and the Sun VMs. It does not *explicitly* state that these > are needed to rebuild the source; do you think that I should update the > file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, > and neither currently support the Swing APIs used by filler, but I'm > very hopeful that they will quite soon. As such, and considering the Contrib for now, definitely. As for Swing support - that remains to be seen :) I wouldn't expect truly satisfactory Swing support in Free JVMs before Sarge release (unless Sarge will release in 2005 ;-). This is not due to slowness of the development but because Swing is *huge*. If you don't get any email from me in next days - please don't forget to mail me again in a week if you still want your package to be reviewed and uploaded by me. I am very sorry about it, but I really have a very unpleseant deadline to deal with. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
Juuso Tähkäpää <[EMAIL PROTECTED]> schrieb: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? You know what an NMU is? If not, read the respective parts of the Developer's Reference. I don't know what's the cause in your particular case (and didn't download the package). But it seems that lintian thinks this will be a non-maintainer-upload - perhaps because names in debian/changelog and debian/control don't match? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, May 11, 2004 at 01:52:55PM +0300, Juuso T?hk?p?? wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? I got from the .changes: Maintainer: Juuso Tähkäpää <[EMAIL PROTECTED]> Changed-By: Juuso Tähkäpää <[EMAIL PROTECTED]> which is the cause. You should write your name in debian/control at 'Maintainer:' in UTF-8 too for the Debian archive scripts to recognise this is the same person (and thus recognise it as a maintainer upload, rather than a Non-Maintainer Upload aka NMU). Historically, only plain ASCII (that is excluding the a with ) is allowed in debian/control, but if you're going to violate that (unwritten) rule (which is quite common and an understandable wish) you should use UTF-8. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, 11 May 2004 22:36:04 +0200 Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > Historically, only plain ASCII (that is excluding the a with call that in finnish?>) is allowed in debian/control, but if you're > going to violate that (unwritten) rule (which is quite common and an > understandable wish) you should use UTF-8. So it is better to avoid weird characters and use slightly "wrong" name? Lesson learned! -- Juuso Tähkäpää
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, 11 May 2004 14:37:43 +0200 Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote: > Where did you find so complicated dependencies? As I was (late at night) just trying to get the package working I didn't use too much time thinking about dependencies... I just blindly followed Debian New Maintainers' Guide's "hack you can use to find out which packages your package needs" and moved on. Torsmo actually seems to need help2man (>=1.27), xlibs-dev (>=4.1.0), debhelper (>=4.0.2). (versions are what woody has to offer; torsmo compiles cleanly on woody (and on almost any other distros)) It seems to me that some kind of version requirements are a good thig... -- Juuso Tähkäpää
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
Second round with many lessons learned. -actual (?) build-dependencys in debian/control -no editing of the configure-script -no "illegal" characters in control or changelog If someone still cares to see what else I am doing wrong, new files are on http://boogeyman.homeunix.org/debian/unstable/torsmo/ On Tue, 11 May 2004 13:52:55 +0300 I wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly. > Also I need a sponsor when I get the guality of mu packaging work good > enough. If someone wants to sponsor me, I suggest that this version of > torsmo is not uploaded to archives, because the next version probably > gets released soon (and is better and more mature than this version) -- Juuso Tähkäpää
Re: ITA: filler - Simple game in Java
On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > Good evening. My name is James Damour, and I would like to adopt the > > filler package that the Debian QA team has orphaned. I have made my > > first modifications to the package, and I have uploading them to > > http://mentors.debian.net. > > Hi, > > I cannot offer you to sponsor your package, as I understand no Java, > and any error would probably slip under my nose. Anyway, if you have > the package ready, please retitle bug #232868 to 'ITA: filler - Simple > game in Java' - You can do this by sending the following line as a > mail to [EMAIL PROTECTED]: > > retitle 232868 ITA: filler - Simple game in Java > > I noticed you already replied to that bug report, but when people look > at the WNPP packages, filler still appears as orphaned - do this just > to save other people the effort in opening the report and checking. > Done. > > I would appreciate it if a sponsor could review my packaging, and let me > > know what I should change in order to get it ready for upload to the > > Debian archive. I've fixed all lintian or linda errors, and the > > remaining linda warning may be a bug (as a game, filler needs to be > > rwxr-sr-x and linda is expecting rwxr-xr-x). > > > > I expect that I'll get a FTBFS error because I can not specify a > > compliant Java Development Kit from within the Debian archive (filler > > requires Swing technology, and I haven't found a VM that will build it, > > but I'm still looking). Any assistance in this area would be greatly > > appreciated. > > If your package requires a non-free JDK, then it will enter contrib > (instead of main) and will not be autobuilt, so don't worry, you will > not get the dreaded FTBFS ;-) Just please note somewhere visible > (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it > and where can it be found. Also, double check: Can Filler be used with > any of the existing JVMs in Debian? If not, it would not be useful at > all, and instead of adopting it, you should file for its removal from > the archive. The file, /usr/share/doc/filler/README.Debian mentions both the Blackdown and the Sun VMs. It does not *explicitly* state that these are needed to rebuild the source; do you think that I should update the file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, and neither currently support the Swing APIs used by filler, but I'm very hopeful that they will quite soon. As such, and considering the age of the package (it's been in Debian for over 3 years) I'd prefer to leave the package in Debian, and just have it limp along until FLOSS Java catches up to it. > > Greetings, Thank you for your feedback. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
RE:'RTCProd=005-232-113'Re:hello
Thank you for the information provided. To ensure the most appropriate person answers your question, I forwarded your e-mail message to a group that specializes in this area. You should receive a response from this group within 24 business hours (one business day). If you do not receive a response from them, or have any additional questions, please reply to this e-mail message. You may also contact us by calling the Microsoft Sales and Information number at (800) 426-9400. This phone number is available Monday through Friday, 6:00 A.M. to 5:30 P.M. Pacific time. For your convenience, I have included the following Web sites that you may find helpful: Microsoft Product Support and Knowledge Base http://support.microsoft.com Microsoft Developer Network http://msdn.microsoft.com Microsoft TechNet Online http://technet.microsoft.com Purchase and review Microsoft Products http://shop.microsoft.com -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Tuesday, May 11 2004 6:48PM To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject:Re:hello Re:hello
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said: > The "skeleton" "init.d" file is a great default for starting _one_ > daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, > however, what this newbie package developer should do to start an > arbitrary number of daemons, each with - potentially - different > "$DAEMON_OPTS". > > It's nice to be able to throw "$DAEMON_OPTS" into > "/etc/default/package" and get get a bit more control over the daemon; > but I can't think how to nicely specify an arbitrary number of > "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. > > I'm still searching for a solution... Input much appreciated! I am not exactly sure what you mean by arbitrary - I'm assumin you have a real number in mind, but that it could vary (e.g., some may not be selected to actually run at boot, or all could, depending on the setup). If the daemons are useful independently of each other, package them seperately. If not, try one of the following. You can use multiple init scripts, or you can take a look at the init scripts of packages that start multiple daemons (slapd and samba come to mind) for examples of how others do it. If you just want seperate defaults, seperate lines in /etc/default/package would work well - it's just sourced, so DAEMON_1_OPTS="..." DAEMON_2_OPTS="..." etc. If you really mean arbitrary, in the sense that you have no idea how many, I can't help :) HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: ITA: filler - Simple game in Java
On (11/05/04 21:37), James Damour wrote: > On Tue, 2004-05-11 at 11:40, Gunnar Wolf wrote: > > James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > > > I would appreciate it if a sponsor could review my packaging, and let me > > > know what I should change in order to get it ready for upload to the > > > Debian archive. I've fixed all lintian or linda errors, and the > > > remaining linda warning may be a bug (as a game, filler needs to be > > > rwxr-sr-x and linda is expecting rwxr-xr-x). As for SGID - if this is java game, so you most probably have a shell wrapper. S[UG]ID bits do NOT work on shell scripts. You can have the bits set but they will be ignored. So I suspect linda may check that your wrapper is a shell script and then - sgid bit makes no effect anyway. What you probably could do is write a small C wrapper, but then your package would have to be autobuild on all architectures, which will not happen for a package in contrib... So getting back to the sources of SGID - the bit is there so that games played independently by difrent users could store the "best score" values in a shared place. If you don't set the bit you can not use this functionality. Well, not a terribly big loss probably. > > If your package requires a non-free JDK, then it will enter contrib > > (instead of main) and will not be autobuilt, so don't worry, you will > > not get the dreaded FTBFS ;-) Just please note somewhere visible [...] > The file, /usr/share/doc/filler/README.Debian mentions both the > Blackdown and the Sun VMs. It does not *explicitly* state that these > are needed to rebuild the source; do you think that I should update the > file to say so? I've tried gij-3.3 and both Kaffe and SableVM from Sid, > and neither currently support the Swing APIs used by filler, but I'm > very hopeful that they will quite soon. As such, and considering the Contrib for now, definitely. As for Swing support - that remains to be seen :) I wouldn't expect truly satisfactory Swing support in Free JVMs before Sarge release (unless Sarge will release in 2005 ;-). This is not due to slowness of the development but because Swing is *huge*. If you don't get any email from me in next days - please don't forget to mail me again in a week if you still want your package to be reviewed and uploaded by me. I am very sorry about it, but I really have a very unpleseant deadline to deal with. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Hi, I'm forwarding this message to -mentors, is there anybody who can help? thanks (the same post on debian-x didn't have any answer). - Forwarded message from Mattia Dongili <[EMAIL PROTECTED]> - Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 From: Mattia Dongili <[EMAIL PROTECTED]> Date: Mon, 3 May 2004 17:51:56 +0200 To: Debian X Mailing List <[EMAIL PROTECTED]> X-Operating-System: Linux 2.6.5-1 i686 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Disclaimer: Buh! Hi all, the subject[1] says it all, will it ever be an xserver-xfree86 for s390? otherwise I'd better chance my package's Architecture field before sarge Since xfree86 is Architecture: any, I've been suggested to have the same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [1] http://qa.debian.org/developer.php?excuse=xfree86-driver-synaptics thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: [...] > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 [...] > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge > Since xfree86 is Architecture: any, I've been suggested to have the > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [...] Personally I'd immediately change the architecture field and change it back once there is a xserver for s390. - You'll probably have to pester ftp-master to remove the old s390 binary, otherwise xfree86-driver-synaptics will be blocked by "out of date on s390". cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back
Hello! This very useful package (I hope not only for me ;-) was orphaned last month and was unmaintained for 2 years. I have adopted it. I prepared my first (official) debian packages, and I'm looking for sponsor for it. The upload will close 4 bugs. The package is linda and lintian clean. --- Package name: txt2pdbdoc License: GPL Description: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back This utility converts plain text files (or HTML files) to the de facto PalmOS standard DOC format for use in document readers (such as "C Spot Run") and editors (such as "ZDOC"). DOC files are compressed by default, and txt2pdbdoc can also convert DOC files back to plain text. . WARNING: Generated PDB files (for this and previous versions) may cause problems on the Palm if they are installed by some method other than hotsyncing (e.g. via a memory card). See bug #118930 for details. Package Download: http://www.erikschanze.de/debian/ Thanks for taking your time, Erik -- www.ErikSchanze.de * Bitte keine HTML-Mails! No HTML mails, please! Maillimit: 1 MB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linuxinfotag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
V.icodin Pre.scriptions
Buy your drug of choice, NO prescription required Today's special: Free overnight Fedex delivery Vicodin.$2.53/dose Hydrocodone$2.10/dose Xanax...$2.50/dose Valium..$2.69/dose Phentermine..$0.84/dose Stock is limited and selling fast, so hurry Buy them here -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > Hi all, > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge There is, today. Notice that xfree86 itself was also stalled by it... Expect your package to go in tomorrow. Do not simply change the architecture field because one or two architectures are behind, rather, try to research *why* your package doesn't go to testing. In this case, Bjorn's page shows wrong information (Cc'ing him). It said: Adding xfree86-driver-synaptics makes 1 non-depending packages uninstallable on s390: xfree86-driver-synaptics But xfree86-driver-synaptics wasn't in testing to begin with (at least, afaics). Exact reason I don't understand (Sarge's X did have s390), but it doesn't matter anymore. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I personally disagree: - it's an ugly workaround - it's hiding problems (s390 failures) - there is no good reason to not support s390, so your removal request might even be rejected (I don't know of course what would really happen, I cannot speak for ftp-master of course). - it adds extra workload to ftp-master, which is unnecessary - it means two extra unnessesary uploads, causing extra load on the buildd's, again, quite unneeded --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Jeroen van Wolffelaar wrote: > In this case, Bjorn's page shows wrong information (Cc'ing him). > It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics This information is grabbed on from update_output.txt, a result file that is produced by the official nightly Debian Testing scripts: trying: xfree86-driver-synaptics skipped: xfree86-driver-synaptics (0 <- 70) got: 26+0: a-2:a-2:h-3:i-0:i-2:m-2:m-5:m-5:p-0:s-5 * s390: xfree86-driver-synaptics (http://ftp-master.debian.org/testing/update_output.txt) I wish there were more details I could show in my script, but there isn't. -- Björn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... > > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: Oops, I was wrong... I checked out the xfree86 source package, but not the xserver-xfree86 binary package of it. Indeed, it is not available on s390, and never will, since s390 is a mainframe without input controls. Also, s390 doesn't have any possibility to connect a touchpad to. I don't really know what to do about it, maybe ask d-d (this is a quite tricky problem) or debian-release. Some suggestions I heard: - contact ftp-master to add this one to Packages-arch-specific - make your package FTBFS on s390, and have ftp-master remove the s390 binary. It will propagate nicely then, a FTBFS on an unsupported architecture is possible. But this will make s390 attempt to build it, so isn't really nice to do. So the best thing you can do is ask ftp-master for advice I think. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) a light and simplistic resource monitof for X. I am in the process of learning to properly use debian packaging tools, and already managed to make a package that installs, uninstalls and works correctly, but I can't figure out what lintian warns me about: $lintian -i torsmo_0.15-1_i386.changes W: torsmo source: changelog-should-mention-nmu N: N: When you NMU a package, that fact should be mentioned on the first N: line in the changelog entry. N: W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 N: N: A source NMU should have a Debian revision of '-x.x'. This is to N: prevent stealing version numbers from the maintainer (and the -x.x.x N: version numbers are reserved for binary-only NMU's). What configs should I fix, or is this normal in some cases? packages and other related files I made can be downloaded from http://boogeyman.homeunix.org/debian/unstable/torsmo/ Also I need a sponsor when I get the guality of mu packaging work good enough. If someone wants to sponsor me, I suggest that this version of torsmo is not uploaded to archives, because the next version probably gets released soon (and is better and more mature than this version) -- Juuso Tähkäpää
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... ok, thanks. Better than a swiss timer (as we say in Italy) :) > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics I was actually referring to QA pages excuse: xfree86-driver-synaptics/s390 unsatisfiable Depends: xserver-xfree86 (>= 4.3.0) This actually hides a bug in my package (mea culpa), the correct Depends fields should be since this driver works with XFree86-4.2 too: Depends: xserver-xfree86 (>> 4.1.0) Moreover some considerations could be done about the usefulness of a Synaptics Touchpad driver on S390, I strongly doubt we will ever see it :) Anyway thanks a lot for the explanation and help -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
> Uploaded to http://mentors.debian.org/ Failed to fetch http://mentors.debian.net/debian/pool/main/l/lis/lis_2.16.16.orig.tar.gz 404 Not Found Looks like you didn't include the original source with your upload. This is because your package version is neither -0 nor -1, so dpkg-genchanges did not include the original source in the list of files. From the dpkg-buildpackage manpage: "By default, or if -si is specified, the original source will be included if the version number ends in -0 or -1, ie if the Debian revision part of the version number is 0 or 1." Will try to grab the original source and slap on your diff to have a look at your lintian error. Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Hi again Thomas, I just had a look at your control file.. it's HUGE as you define all the kernel-lis-modules-2.4.26-1-(386|586tsc|etc..) packages! I suggest you take a look at how alsa or pcmcia-cs are packaged and create an "lis-source" package in your control file. You should not be building all these different flavours from your main control file. What you want to do is build : lis, lis-dev, lis-doc, lis-source. The "lis-source" package is the one that will be used to build the actual kernel modules. To do so you will provide a template called "lis-source.control" in your main package which will define the various kernel module packages. Once again, I recommend you take a look at how ALSA or the PCMCIA packages are built! Cheers, Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NML vs Octave
Okay Ive decided on the name NML (Numerical Methods Library) Where Odes are concerned. I've implemented 10 different solving schemes. The 2 most promising are seen below vs Octave executed 100 times the equation dy/dx = y*tan(x) [y = sec(x)] which is even more unstable than dy/dx = 1 + y^2. [y = tan(x)]: Real : y(1.57) = 1255.7659 Octave: y(1.57) = 1255.7708 (2.88 sec) Predictor-corrector: y(1.57) = 1211.35(0.32 sec) or y(1.57) = 1233.83(0.64 sec) Runge kutta order 4: y(1.57) = 1255.7659 (exact) (0.59 sec) Runge kutta 4 rocks. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITA: filler - Simple game in Java
Good evening. My name is James Damour, and I would like to adopt the filler package that the Debian QA team has orphaned. I have made my first modifications to the package, and I have uploading them to http://mentors.debian.net. I would appreciate it if a sponsor could review my packaging, and let me know what I should change in order to get it ready for upload to the Debian archive. I've fixed all lintian or linda errors, and the remaining linda warning may be a bug (as a game, filler needs to be rwxr-sr-x and linda is expecting rwxr-xr-x). I expect that I'll get a FTBFS error because I can not specify a compliant Java Development Kit from within the Debian archive (filler requires Swing technology, and I haven't found a VM that will build it, but I'm still looking). Any assistance in this area would be greatly appreciated. -- James Damour (Suvarov454) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: NML vs Octave
Hi The Brusselator is a system of odes. I'm implementing the algorithm for a system of odes right now using RK4. All I could find out about the Brusselator equation is that is used a lot in chemistry. You seem to know a lot about odes. Does that extend to all of numerical analysis?. If there is a paper you know about that i can read please let me know. Also I found a GNU project similar to mine the GNU Scientific Library (GSL) www.gnu.org/software/gsl/ Its also a C library for numerical analysis. If anyone knows alot about numerical analysis I'd appreciate if you could compare the GSL with my NML numerical.port5.com As far as I can see, setting up the GSL for comutation looks tougher than for the NML. Regards __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back
Erik Schanze: > --- > Package name: txt2pdbdoc > > License: GPL > > Description: > txt2pdbdoc - Convert plain text files to Palm DOC (for PalmOS) and back > This utility converts plain text files (or HTML files) to the de facto > PalmOS standard DOC format for use in document readers (such as "C Spot > Run") and editors (such as "ZDOC"). DOC files are compressed by > default, and txt2pdbdoc can also convert DOC files back to plain text. > . > WARNING: Generated PDB files (for this and previous versions) may cause > problems on the Palm if they are installed by some method other than > hotsyncing (e.g. via a memory card). See bug #118930 for details. > > Package Download: http://www.erikschanze.de/debian/ > I discussed my translation of debconf template with Gerd Fuchs from debian-l10n-german list and have done some improvements. So please look over updated package under http://www.erikschanze.de/debian/ or should I upload package to mentors.debian.net instead? BTW: Is there any need to give dpkg-buildpackage the option -v (-v1.4.2-2 in my case) to say dh_genchanges that a previous version is still in archive? I noticed no differences between calls with this option or not. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-Mails! No HTML mails, please! Maillimit: 1 MB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITA: filler - Simple game in Java
James Damour dijo [Tue, May 11, 2004 at 08:25:52AM -0400]: > Good evening. My name is James Damour, and I would like to adopt the > filler package that the Debian QA team has orphaned. I have made my > first modifications to the package, and I have uploading them to > http://mentors.debian.net. Hi, I cannot offer you to sponsor your package, as I understand no Java, and any error would probably slip under my nose. Anyway, if you have the package ready, please retitle bug #232868 to 'ITA: filler - Simple game in Java' - You can do this by sending the following line as a mail to [EMAIL PROTECTED]: retitle 232868 ITA: filler - Simple game in Java I noticed you already replied to that bug report, but when people look at the WNPP packages, filler still appears as orphaned - do this just to save other people the effort in opening the report and checking. > I would appreciate it if a sponsor could review my packaging, and let me > know what I should change in order to get it ready for upload to the > Debian archive. I've fixed all lintian or linda errors, and the > remaining linda warning may be a bug (as a game, filler needs to be > rwxr-sr-x and linda is expecting rwxr-xr-x). > > I expect that I'll get a FTBFS error because I can not specify a > compliant Java Development Kit from within the Debian archive (filler > requires Swing technology, and I haven't found a VM that will build it, > but I'm still looking). Any assistance in this area would be greatly > appreciated. If your package requires a non-free JDK, then it will enter contrib (instead of main) and will not be autobuilt, so don't worry, you will not get the dreaded FTBFS ;-) Just please note somewhere visible (i.e. in /usr/share/doc/filler/) what JDK did you use to compile it and where can it be found. Also, double check: Can Filler be used with any of the existing JVMs in Debian? If not, it would not be useful at all, and instead of adopting it, you should file for its removal from the archive. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NML vs Octave
Halim Boukaram wrote: > I've implemented 10 different solving schemes. The 2 most promising > are seen below vs Octave executed 100 times the equation dy/dx = > y*tan(x) [y = sec(x)] ... This is really off-topic for debian-mentors. Could this discussion (except for any questions about Debian packaging) be moved to a better forum such as sci.math.num-analysis, or maybe a GNU Octave list? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Thanks for replying Jeremy, comments on your suggestions inlined. For anyone interrested the complete packages (including .orig.tar.gz) are available in http://nthomas.free.fr/LiS But my trouble remains : lintian -i lis_2.16.16-2.dsc E: lis source: package-uses-debhelper-but-lacks-build-depends N: N: If a package uses debhelper, it must declare a Build-Depends on N: debhelper. N: but lis_2.16.16-2.dsc is: -- Format: 1.0 Source: lis Version: 2.16.16-2 Binary: kernel-lis-modules-2.4.26-1-k7-smp, kernel-lis-modules-2.4.26-1-386, kernel-lis-modules-2.4.26-1-686-smp, lis-doc, kernel-lis-modules-2.4.26-1-k7, lis, kernel-lis-modules-2.4.26-1-686, lis-dev, kernel-lis-modules-2.4.26-1-k6, kernel-lis-modules-2.4.26-1-586tsc Maintainer: Nicolas THOMAS <[EMAIL PROTECTED]> Architecture: any Standards-Version: 3.6.1 Build-Depends: debhelper (>> 4.0.0), kernel-build-2.4.26-1, dbs, m4 Files: 082c8612dce46236282b97d8af4c3f01 792684 lis_2.16.16.orig.tar.gz c5c53afc74063dfa91c35939b390f69f 10461 lis_2.16.16-2.diff.gz -- It as a build-depends on debhelper !! what do I miss ?? More inlined : Quoting Jeremy Lainé <[EMAIL PROTECTED]>: > Hi again Thomas, > > I just had a look at your control file.. it's HUGE as you define all the > kernel-lis-modules-2.4.26-1-(386|586tsc|etc..) packages! I suggest you > take a look at how alsa or pcmcia-cs are packaged and create an > "lis-source" package in your control file. > > You should not be building all these different flavours from > your main control file. What you want to do is build : lis, lis-dev, > lis-doc, lis-source. The "lis-source" package is the one that will be > used to build the actual kernel modules. To do so you will provide a > template called "lis-source.control" in your main package which will > define the various kernel module packages. Once again, I recommend you > take a look at how ALSA or the PCMCIA packages are built! What I want is to be able to provide binary packages for debian "official" kernels for now own the automated creation of a big control file and .(pre|post)inst is working. I don't believe it's against policy (correct me if I'm wrong) but fully agree to have a close look at your proposal to easily allow anyone to build modules for it's own kernel. I2C for 2.4 kernels use a similar approach. Anyway I do not see how all this is related to the lintian error .. I first have to work on packaging 2.16.18 version then I'll have a deep look at making a lis-source and make-kpkg template. Thanks > > Cheers, > Jeremy > > -- > http://www.jerryweb.org/ : JerryWeb.org > http://sailcut.sourceforge.net/ : Sailcut CAD > http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lis -- SVR4 compatible STREAMS (+help on lintian)
Nicolas THOMAS wrote: Thanks for replying Jeremy, comments on your suggestions inlined. For anyone interrested the complete packages (including .orig.tar.gz) are available in http://nthomas.free.fr/LiS But my trouble remains : lintian -i lis_2.16.16-2.dsc E: lis source: package-uses-debhelper-but-lacks-build-depends N: N: If a package uses debhelper, it must declare a Build-Depends on N: debhelper. N: Remove first (empty) line of the 'control' file. Lintian that source package is described before first empty line. -- Eugeniy Meshcheryakov Kyiv National Taras Shevchenko University Information and Computing Centre http://icc.univ.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testing config/preinst mods
> > For config scripts, in the absence of something pre-existing, one > > approach that looks like it would work pretty easily would be to > > replace apt-extracttemplates (which is called by dpkg-preconfigure) > > with something that would check a magic directory for replacement > > scripts for a package and use those instead of the real ones if they > > exist. > > I have never heard of something like this - but it would be simply > great! Not only that it would make testing easier, but also because if > some strange bug is reported, one could put debugging code at the right > places of the script, send it to the bug submitter and ask him to make > dpkg use it. I had a couple of hours over the weekend to implement and test this. I used it today to create patches for two outstanding bugs including three merged release-critical bugs against console-common. I'll post my solution to debian-devel today with the subject "testing config/preinst mods: one approach". -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: python-utidylib -- Python wrapper for TidyLib
Hello, I'm looking for a sponsor for python-utidylib (http://bugs.debian.org/244110): Package name: python-utidylib Version : 0.2 Upstream Author : Cory Dodt <[EMAIL PROTECTED]> URL : http://utidylib.sourceforge.net/ License : MIT Description : Python wrapper for TidyLib uTidylib provides Python wrapper for TidyLib, HTML syntax checker and reformatter. This allows you to tidy HTML files through a Pythonic interface, with all the options that Tidy command line supports. In short, it turns awful cowboy HTML into sexy standard-compliant HTML. sources.list: deb http://fluid.sparcs.net/debian/ unstable/all/ deb-src http://fluid.sparcs.net/debian/ unstable/source/ I also want to package API documentation of python-utidylib. There is a tool(gendoc.py) to do so in the source distribution, but I'm not sure how to handle it for Debian. Any suggestion is appreciated. Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Init Script for Arbitrary Number of Daemons
The "skeleton" "init.d" file is a great default for starting _one_ daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, however, what this newbie package developer should do to start an arbitrary number of daemons, each with - potentially - different "$DAEMON_OPTS". It's nice to be able to throw "$DAEMON_OPTS" into "/etc/default/package" and get get a bit more control over the daemon; but I can't think how to nicely specify an arbitrary number of "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. I'm still searching for a solution... Input much appreciated! Thanks! Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
