Re: RFS: gnus (second try)
]] Tommi Vainikainen | Hi, | | I am still looking for a sponsor for the new version 5.11+v0.10.dfsg-1 | of my package "gnus". While I don't usually sponsor packages any more, I do use gnus and so has an interest in it being good. debian/gnus-init.el has a typo: ;; laod-path, though near the end. Apart from that, it looks good and I've uploaded it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: quanta-doc ?
* Mariusz Przygodzki | [3] PHP Manual You probably know that this is already packaged as php3-doc? The title is a bit misleading - it's actually both php3 and php4-docs in it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Having ssh support non-US?
* Junichi Uekawa | It would be a non-problem if ssh provided rsh. It does, kind of: $ls -l /etc/alternatives/rsh lrwxrwxrwx1 root root 12 nov 17 16:23 \ /etc/alternatives/rsh -> /usr/bin/ssh* how about having mpich depending on rsh | ssh, and then using the link in alternatives? | Now, what about a package in main depending upon non-US/main. it shouldn't. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Having ssh support non-US?
* Junichi Uekawa | > how about having mpich depending on rsh | ssh, and then using the link | > in alternatives? | | No, the right way will be the package providing rsh having a "Provides: rsh" | in its description. | | A bug report is due, I think. perhaps so. | > | > | Now, what about a package in main depending upon non-US/main. | > | > it shouldn't. | | So, I can't just do it. no, afaik. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: creating man pages
* Drew Parsons | I wouldn't necessarily mind using SGML, but which tools exactly do you use. I use emacs with psgml. | For creating man pages I mean. How do you generate them from SGML? docbook-to-man is what I use. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
_i386 changes file for binary-all package?
I am building fortunes-bofh-excuses - just a couple of data files for fortune. It has a Architecture: all in the control file. However, building with dpkg-buildpackage generates a fortunes-bofh-excuses_1.1-1_i386.changes, not fortunes-bofh-excuses_1.1-1_all.changes as I would expect. Is it supposed to be that way? I couldn't find any information on it in the man pages for dpkg-genchanges at least. And also - if somebody could please sponsor the upload for me as soon as it's finished, I'd appreciate. TIA. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: _i386 changes file for binary-all package?
* Adrian Bunk | On 20 Dec 2000, Tollef Fog Heen wrote: | | >... | > It has a Architecture: all in the control file. However, building | > with dpkg-buildpackage generates a | > fortunes-bofh-excuses_1.1-1_i386.changes, not | > fortunes-bofh-excuses_1.1-1_all.changes as I would expect. | > | > Is it supposed to be that way? I couldn't find any information on it | >... | | It is supposed to be that way. Out of curiosity: why? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: _i386 changes file for binary-all package?
* Matt Zimmerman | On Wed, Dec 20, 2000 at 08:50:10PM +0100, Tollef Fog Heen wrote: | | > I am building fortunes-bofh-excuses - just a couple of data files for | > fortune. | | Is there any reason why they shouldn't be included in fortune proper? That they are distributed separately and that I am planning on packaging more of them? fortunes-kernel, fortunes-opensource, fortunes-jargon, maybe fortunes-calvin, fortunes-matrix etc? And that some of them get big - fortunes-jargon is about 1.2MB unpacked. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: getting a python module accepted by python?
* "Sean 'Shaleh' Perry" | I am trying to package soaplib, a python SOAP implementation. I copy the lone | soaplib.py to usr/lib/python1.5/site-packages/soaplib. My postinst runs | compileall.py (I copied python-xml). | | When I try to 'import soaplib' in python, I get an error: | | ImportError: No module named soaplib | | anyone know what I am missing? if you put it in ../site-packages/soaplib, you'll probably need to do 'import soaplib.soaplib'. I guess the fix is obvious. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: getting a python module accepted by python?
* Sean 'Shaleh' Perry | Is there a way to make a site-packages/foo/foo.py without requiring a change | in programs calling foo? Have site-packages/foo.py exist and do 'import foo.foo'. | Also, sorry to get off topic, but should the postinst compile the module? yes, afaik. | Won't this happen the first time the module is imported? No, not if the user doesn't have write access to where the module is located. Which she usually doesn't have. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: testing vs. unstable
* peter karlsson | 2.0 is from November last year, and should be good enough to have | gone into testing, why hasn't it? Dunno, but you can check the status on http://ftp-master.debian.org/~ajt/update_excuses.html , as you probably know. | (2.0.1 fixes the only | bugreport on it and was released yesterday, so it should naturally stay | in unstable for a while). Yep: turqstat 2.0.1 (currently 1.2-1) (low) Maintainer: peter karlsson <[EMAIL PROTECTED]> only 2/10 days old So, unless it's dependant on other buggy packages, or you get any RC bugs, it will go into testing. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Sponsor for mboxgrep
I've ITP'ed and packaged mboxgrep. If somebody could sponsor the upload for me, I'd appreciate. Deb-src line is: deb-src http://samfundet.no/~tfheen/debian woody main TIA. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Mon, Jan 22, 2001 at 09:38:15AM +0100, Christian Hammers wrote: | | > On Mon, Jan 22, 2001 at 08:13:57AM +0100, Martin Schulze wrote: | > > You should always be able to backport a patch. If not, I'm sorry, but that | > > this should be one quality of a Debian maintainer, you lack something... | > Martin? It it the quality of a Debian maintainer to find the right line(s) in | > a 100k C/C++ patch and moreover feeling sure enough about it to say that this | > fixes the security hole in one often used package?!?!?! Programming did not | > fall under the requirements of a maintainer, last time I checked. | | If a maintainer cannot program in the language in which her package is written, | how will she fix bugs, test patches, and generally understand how the packaged | software works on the inside? Such a maintainer is not a very effective one. So, for instance, the maintainer of postgresql must know perl, tcl, C, C++, python and java/jdbc very well? ( since it is written in C, and has interfaces for all the programming languages mentioned.) Of course, having an understanding of the programming languages is helpful, but IMHO not required in order to be a maintainer. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Tue, Jan 23, 2001 at 12:07:02PM +0100, Tollef Fog Heen wrote: | | > So, for instance, the maintainer of postgresql must know perl, tcl, C, | > C++, python and java/jdbc very well? ( since it is written in C, and | > has interfaces for all the programming languages mentioned.) | | Not necessarily. The core of the code is written in C, and the maintainer | should be able to read and write C comfortably in order to effectively maintain | the package. The interfaces for other languages are generally small bits of | glue that don't have very many bugs and don't change very often. 35960 lines of code for the jdbc interface is not what I call 'small bits of glue'. 2000 lines of perl glue (about 650 lines perl, the rest C) isn't necessarily little either - depending on the perl style. However, for python, you are right, about 300 lines of python and 2300 lines of C. (note that all those numbers are from "wc -l"'ing the source files, so it includes blank lines etc. | In the event that a problem arises with the Tcl bits, I imagine I | could post a message here or elsewhere and ask for help. of course. As you could if the problem was not knowing enough C or some other language. | If I needed to do this every time a change was necessary in a C | source file in one of my packages, my progress would be very slow | indeed. I guess that depends a lot on the package. Many packages which use autoconf and automake do only need dh_make and then some minor adjustments. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Tue, Jan 23, 2001 at 10:13:33PM +0100, Tollef Fog Heen wrote: | | > * Matt Zimmerman | > | > | Not necessarily. The core of the code is written in C, and the maintainer | > | should be able to read and write C comfortably in order to effectively maintain | > | the package. The interfaces for other languages are generally small bits of | > | glue that don't have very many bugs and don't change very often. | > | > 35960 lines of code for the jdbc interface is not what I call 'small | > bits of glue'. 2000 lines of perl glue (about 650 lines perl, the | > rest C) isn't necessarily little either - depending on the perl | > style. | | If the Java portion of the code really is that extensive, then I would say yes, | the maintainer should be familiar with Java programming. AFAIK, there is no | standard way to call C code from Java (and indeed this would violate the Java | platform model), so I can imagine that the code is nontrivial. Since this is a database engine, the java calls are jdbc, which works over TCP/IP, so that is not a problem. And you have JNI where you can call standard code. | I'll say that the maintainer should be at least as knowledgeable as | the average user about his/her package. A good maintainer will know | his/her packages very well indeed. I see this as one of Debian's | strengths: since packages are maintained by volunteers who take an | active interest in them, they tend to be well cared for. Yep. I am not saying that a maintainer should not know the language - I am just saying that to maintain something written in C, you don't need to be a C guru. | > | In the event that a problem arises with the Tcl bits, I imagine I | > | could post a message here or elsewhere and ask for help. | > | > of course. As you could if the problem was not knowing enough C or some | > other language. | | The difference is one of scale. If I didn't know enough about the core of a | package that I had to post to debian-devel about most issues with the code, I | wouldn't be maintaining the package anymore; -devel would, with me as a | sponsor. And you'd probably learn your C pretty fast. ;) | > I guess that depends a lot on the package. Many packages which use autoconf | > and automake do only need dh_make and then some minor adjustments. | | In order to be packaged initially, sometimes it's this easy. But to be most | useful to Debian's users? To be best integrated with the rest of Debian? To | be maintained in the long term? Actually - it seems to be about that easy. I am not very into emacs lisp programming, but packaging up the new version of JDE (by using the old maintainer scripts and updating them) and the three support packages it now needs didn't take me more than a couple of hours. I believe I can maintain them quite well, even though I am not a elisp guru. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: chroot and FHS
* Christian Hammers | I like to build my mysql package with chroot support and therfore jail it | somewhere under /var/lib/mysql and link the log files to /var/log. | | I either statically link it so that it can be run from /usr/sbin and then | live in /var/lib because I don't want to have binaries in /var or | hardlink the libs from /usr/lib and /lib to /var/lib/mysql? | Without trying it out I would say that the latter way is preferred, isn't it? No. Hardlinks doesn't work across filesystems and /usr is quite often on it's own partition. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: use and abuse of Debconf, follows-up
* (Jérôme Marant) | I know I'm not doing The Right Thing since I'm modifying conffiles | but I don't understand why this would not be elegant and disgusting. Because you'll get questions from dpkg about a changed conffile. | I would apreciate any suggestion for improving this. Don't mark the file as a conffile? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: mentor request
* Joshua Haberman | Lintian complained at the very end of the latter build: | | W: audacity: unknown-section unknown | | Is that a section in the executable file? dh_strip runs successfully | earlier in the build. In the control file you have something like Section: unknown And since Debian doesn't have a section named unknown, lintian complains. | What am I to do when there is another upstream release? Should I simply | copy the "debian" directory out of the old tree and into the new, update | the changelog, and rebuild? Something like that, yes. If you change anything outside debian/ you might want to use the patch instead. | What about an incremental release, to fix a bug on my (wearing the | package maintainer's hat) part? Am I supposed to make a diff of my | changes? This is not a debian-specific package, right? Just update the changelog, fix your packaging and off you go. | Lastly, what do I need to take into consideration to accomidate for | people who wish to do a source build? How would I note that to build on | potato, you must manually download and compile wxWindows and libvorbis? Put them in the build-depends line. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Wed, Feb 21, 2001 at 02:30:13PM +0100, Richard Atterer wrote: | > Hi, | > | > how do you invoke dpkg-buildpackage for a binary-only NMU? In section | > 8.2 "Guidelines for Porter Uploads", the Developer's Reference says: | > | > In a binary NMU, no real changes are being made to the source. You | > do not need to touch any of the files in the source package. This | > includes debian/changelog. | | debian/changelog is not in source of the package. Is that really written in | the developers reference (too lazy to check that now)? Of course. If you change the source, you need to bump the version number. That is a _source_ NMU, since we need to able to build the packages from the source we have around. A binary NMU should not touch the source. Remember - a buildd building and uploading is, technically, doing an NMU. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Thu, Feb 22, 2001 at 12:44:24PM +0100, Tollef Fog Heen wrote: | > * "Christian T. Steigies" | > | > | debian/changelog is not in source of the package. Is that really written in | > | the developers reference (too lazy to check that now)? | > | > Of course. If you change the source, you need to bump the version | You mean of course, yes? No, it was a remnant from my first sentence. So much for reading through the mail before sending it. | > number. That is a _source_ NMU, since we need to able to build the | > packages from the source we have around. | > | > A binary NMU should not touch the source. Remember - a buildd | > building and uploading is, technically, doing an NMU. | | When I rebuild a package to fix dependency problems (recent example, aview | in potato/m68k depended on a library which was not in potato, so I rebuilt | aview with the potato libraries, changed nothing in the source, only bumped | up the version number, with sbuild, which adds a changelog entry to say just | this: no source changes) that is not ok in your eyes? >From the developers reference: A source NMU is an upload of a package by a developer who is not the official maintainer, for the purposes of fixing a bug in the package. Source NMUs always involves changes to the source (even if it is just a change to debian/changelog). This can be either a change to the upstream source, or a change to the Debian bits of the source. A binary NMU is a recompilation and upload of a binary package for a new architecture. As such, it is usually part of a porting effort. A binary NMU is a non-maintainer uploaded binary version of a package (often for another architecture), with no source changes required. There are many cases where porters must fix problems in the source in order to get them to compile for their target architecture; that would be considered a source NMU rather than a binary NMU. As you can see, we don't distinguish in terminology between porter NMUs and non-porter NMUs. You fall between two chairs - as noted in 7.4.3: What if you are simply recompiling the package? In this case, the process is different for porters than it is for non-porters, as mentioned above. If you are not a porter and are doing an NMU that simply requires a recompile (i.e., a new shared library is available to be linked against, a bug was fixed in debhelper), there must still be a changelog entry; therefore, there will be a patch. If you are a porter, you are probably just doing a binary NMU. (Note: this leaves out in the cold porters who have to do recompiles -- chalk it up as a weakness in how we maintain our archive.) But the situation is clarified in 8.2: Sometimes you need to recompile a package against other packages which have been updated, such as libraries. You do have to bump the version number in this case, so that the upgrade system can function properly. Even so, these are considered binary-only NMUs -- there is no need in this case for all architectures to recompile. You should set the version number as in the case of NMU versioning, but add a ``.0.'' before the the NMU version. For instance, a recompile-only NMU of the source package ``foo_1.3-1'' would be numbered ``foo_1.3-1.0.1''. The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -mporter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependant portions of the package, using the `binary-arch' target in debian/rules. | Technically you may be right, but practically we (well, at least I) do it | like this, just to get things working. Its not necessary that all arches | rebuild hundreds of packages, only because m68k only recently switched to | glibc2.2. And I think thats exactly the reason for the NMU version | numbering. After all, we just recompile the package with a new libc library | installed. Yes, you are right. But there are not problems with hundreds of packages, are there? | Maybe the Developers reference should be clarified, or will I be | expelled from the project now? I guess the Developers reference should be clarified (the 7.4.3 that is, as it seems to be clarified in 8.2). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Thu, Feb 22, 2001 at 02:18:56PM +0100, Tollef Fog Heen wrote: | | > Yes, you are right. But there are not problems with hundreds of | > packages, are there? | | No, only 80 known packages currently | http://people.debian.org/~cts/debian-m68k/quinn/needs-failed | but an unknown number of not-yet-known problems. ouch! | > I guess the Developers reference should be clarified (the 7.4.3 that | > is, as it seems to be clarified in 8.2). | | Well, yes, maybe. I just take it that porters are different and prefer to | spend time on porting over writing the laws. Developers reference is just that - a reference. It's not the law. Policy is 'law'. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Correct way to do binary-only NMU?
* Itai Zukerman (please don't cc me, I'm on the list) | 1. If all you're doing is a compile for a new architecture, then why | is it necessary to bump the package version? If you modify *anything* | in debian/* (for example, the Architecture or Build-Depends fields in | debian/control), then it seems to me this isn't a binary-only NMU. If you just compile for a new version, then you don't bump the version number. It's just if you have to recompile (that you bump the version number). The reason one might need to recompile might be that glibc2.1 had a bug which was fixed in 2.2. You don't want the package to be rebuilt on every other architecture, just because of that. If you are fixing any bugs, then it's a source NMU. And if it's a source NMU, you bump the debian revision by 0.1. | 2. Suppose you bump the package version but nothing in debian/* | changes. Then to re-build the package from source I need to run a | special command; "debian/rules build" won't give me quite the same | thing, right? So I need to know how the binary was built to compile | it properly myself. No, it will work the same in both cases, but the debian revision number will differ by 0.0.1. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
bsh gone?
I took over jde some time ago. jde depends on bsh. bsh exists in testing, but not in unstable, apparently (since I got a bug report saying that I depended on a non-existant package). So - what to do? Package bsh myself? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: bsh gone?
* (Colin Watson) | Tollef Fog Heen <[EMAIL PROTECTED]> wrote: | >I took over jde some time ago. jde depends on bsh. bsh exists in | >testing, but not in unstable, apparently (since I got a bug report | >saying that I depended on a non-existant package). | > | >So - what to do? Package bsh myself? | | It's in unstable, it's just in contrib. If jde depends on it, you'll | need to move that into contrib too. yes, thanks. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: I would like to debianize mod_gzip
* Britton | Yes, you should check the wnpp page http://www.debian.org/devel/wnpp/index | to make sure no one else is already working on it, then announce you | intent to package by filing a wishlist bug against wnpp as per the | instructions in the developers reference (which you should read :). Actually - he should rename the RFP bug to an ITP. | > I would like to debianize mod_gzip requested 5 days ago. Since I'm not an | > official debian maintainer (yet) I'll probably need a sponsor for this package | > (any volunteers ?). Should/can I submit a bug announcing my intention ? I can sponsor you. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Where to place images?
This is sent to both -policy and -mentors, as it's both a proposal and a request for clarification/help. Please Cc me as I'm only subscribed to -mentors. I am in the process of fixing Mailman, which I've just adopted. There is this bug, #61761 (http://bugs.debian.org/61761 ), where the submitter complains that the mailman logo is broken by default (when not accessing from localhost). This is because the images are in http://localhost/doc/mailman/images/, which is only accessible from localhost. The submitter proposes that they should be put in, /var/www/mailman-images or something like that. Policy has something to say about this, 12.5: : Web Document Root : : Web Applications should try to avoid storing files in the Web : Document Root. Instead they should use the /usr/share/doc/ : directory for documents and register the Web Application via the : menu package. If access to the web-root is unavoidable then use : /var/www as the Document Root. This might be just a symbolic link to : the location where the sysadmin has put the real document root. However, I'd like to put images in something like /usr/share/web-images, since I _might_ end up cluttering around and overwriting files which I shouldn't, by placing the images in /var/www/mailman-images. Also, it looks messy, IMHO. So what I propose is that we create a new directory /usr/share/images (or something like that), which is available via the web as http://server/images/. Packages create sub-directories, so that Mailman will have /usr/share/images/mailman/logo.jpg which will be referred to as http://server/images/mailman/logo.jpg . -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Where to place images?
* Jérôme Marant | En réponse à Tollef Fog Heen <[EMAIL PROTECTED]>: | | > | > localhost. The submitter proposes that they should be put in, | > /var/www/mailman-images or something like that. | | I'm the maintainer of the sympa mailing list manager. | I've stored the images used by the web frontend (wwsympa) in | /usr/share/sympa/icons. | | /usr/share/ is used by many (web) applications for | that purpose. How do you serve them then? Add a line to srm.conf, or symlink or a small helper app or something entirely else? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Where to place images?
* Jérôme Marant | With sympa, you just have to give the web alias for accessing | images. So the admin is responsible for setting this up himself? I don't want to mess around with possibly-changing syntaxes in the different httpds' configuration files. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: e-mail address changed
* Stefano Zacchiroli | I've changed my e-mail address, so my last upload of a package seems to | be a NMU, how I fix the problem ? Change the email address in the control file as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Binary-only upload
* peter karlsson | I just noticed that a package I submitted was built on the wrong | machine here at home, and is linked against wrong libraries. Can I, as | the maintainer, do a binary "NMU" where I only recompile the package | against the correct libraries? How do I go about and do that? Increase the version number by 0.01, recompile and upload. See the developers reference 8.2, third paragraph. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Binary-only upload
* peter karlsson | Tollef Fog Heen: | | > Increase the version number by 0.01, recompile and upload. See the | > developers reference 8.2, third paragraph. | | So, how do I change the version number without touching the changelog? You touch the changelog, but you don't include that changelog entry in the next 'normal' upload. IIRC, that is what the consensus on -mentors was last time it was discussed. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
ldd, dpkg-shlibdeps and libsocks.so
I am the maintainer of suck, which links against libsocks. However, it seems like there is something strange going on when it comes to linking: $ldd `which suck` libsocks.so => /usr/lib/libsocks.so (0x4001f000) libnsl.so.1 => /lib/libnsl.so.1 (0x4002d000) libc.so.6 => /lib/libc.so.6 (0x40043000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) $ Here, suck is linked against libsocks.so, without a version number. This makes dpkg-shlibdeps complain about 'format of libsocks.so not recognized'. (Which really is 'format of file name "libsocks.so" not recognized'). Why does this happen, and is this a bug in suck, dpkg-shlibdeps or libsocks4? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: ldd, dpkg-shlibdeps and libsocks.so
* Ben Collins | It is a bug in libsocks4, which should compile the library with -soname | libsocks.so.4. I'm willing to bet that libsocks.so is created by | ldconfig when libsocks4 is installed, else it wouldn't even work without | the -dev package installed. So reassigning the bug against libsocks-dev is the right thing to do? Thanks! -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Undocumented binary
* Sven LUTHER | Maybe all manpage needing binaries could be listed somewhere, and we could | have a manpage writing task ? http://qa.debian.org/man-pages.html :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: directory in .deb
* M G Berberich | I'm not sure if I'm welcome her, because I'm not maintaining a | official debian-package but trying to make .deb's out of my tools. No problem. We are including here. :) | I have a tool that needs a directory /var/log/ppplog. It is contained | in data.tar.gz, but tar does not set the required right on the | directory (right?). So I set the right in the postinst script. It's usually better to set it in the package building script. Less messy, IMHO. | The package also puts a executable in /etc/ppp/ip-down.d. Building the | binary leads to a complain about an executable in unusual place (or | so). Can I prevent this? Are there naming-conventions for script in | /etc/ppp/ip-down.d? I don't know. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: lintian -i file.changes error
* "Sean 'Shaleh' Perry" | However, as I stated in my reply when this came up on lintian -- | hard links are BAD. Symlinks were invented for a reason. I believe you mean something like 'multiple hard links to the same file are bad'. A single hard link is _very_ useful, imho. ;-) And multiple ones for directories. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: gpg keyrings.
* Britton | On 30 Apr 2001, James Troup wrote: | | > Julian Gilbey <[EMAIL PROTECTED]> writes: | > | > > (1) It could be documented on http://keyring.debian.org/ | > | > I'm sure it could...[0] | | Is the procedure for useing anon-rsync documented somewhere else? rsync keyring.debian.org::keyrings/keyrings/debian-keyring.gpg ~/.gnupg/ and add keyring debian-keyring.gpg to ~/.gnupg/options -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: My First Package. Wheee.
* Warren Anthony Stramiello
| a) inclusion in the testing distribution, if still possible
Is handled automagically, if you haven't screwed up anything ;) (that
is, it goes into testing after 10 days of testing in unstable, unless
it has RC bugs, that is). Read more at http://ftp-master.debian.org/testing/
| b) inclusion in the unstable distribution, if still possible
That's were we all upload to.
| c) uploading using dupload and scp
Add something like
package config;
$cfg{'ftp-master'} = {
fqdn => "ftp-master.debian.org",
login => getlogin() || $ENV{USER} || $ENV{LOGNAME},
incoming => "/org/ftp.debian.org/incoming/",
mailto => "[EMAIL PROTECTED]", # stable
mailtx => "[EMAIL PROTECTED]", # unstable, exper.
visibleuser => getlogin() || $ENV{USER} || $ENV{LOGNAME},
visiblename => "",
fullname => "",
# The dinstall on master now sends announcement itself. May 1999.
dinstall_runs => 1,
method => "scpb"
};
$default_host = "ftp-master";
1;
to ~/.dupload.conf
and run
dupload xdrawchem_0.85-1_i386.changes
The changelog decides whether it goes into stable or unstable. Unless
you have _very_ good reasons for it going into stable, it should go
into unstable. Very good reasons include security holes and that the
package as it is in stable is totally unuseable.
Be sure to run lintian on your package before uploading it, though. :)
--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
Re: web app packaging question
* David LaBissoniere | I am packaging the freeside isp billing and account management program. | This package consists largely of many (44) cgi scripts (which reference | each other often) spread into several subdirectories. Some of the | scripts have the same name (for example, view/cust_bill.cgi and | search/cust_bill.cgi). Debian policy states that cgi scripts should be | placed in /usr/lib/cgi. I am guessing that I am not allowed to create | subdirectories in here as apache would no longer view the scripts as | executable? Well, a subdirectory works for mailman, so it should work for you as well. And it is the right way when using many CGIs, imho. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: question on a licence
* Noel Koethe | $ less COPYRIGHT | /* | * Copyright University of Manitoba 1998. | * Written by J. Gary mills | * | * Permission is granted to anyone to use this software for any purpose on | * any computer system, and to alter it and redistribute it freely, | subject | * to the following restrictions: | * | * 1. The author and the University of Manitoba are not responsible | *for the consequences of use of this software, no matter how awful, | *even if they arise from flaws in it. | * | * 2. The origin of this software must not be misrepresented, either by | *explicit claim or by omission. Since few users ever read sources, | *credits must appear in the documentation. | * | * 3. Altered versions must be plainly marked as such, and must not be | *misrepresented as being the original software. Since few users | *ever read sources, credits must appear in the documentation. | * | * 4. This notice may not be removed or altered. | */ I don't see any problems with this license, it says that you have to say that if you modify the sources, you have to say where you got the sources from - similar to the BSD license. Also, they have a no-warranty section, which is just fine. So, I don't see what you might think that would be a problem with the license. | Sorry, if this is the wrong list. Please tell me the right one. debian-legal, but -mentors isn't too bad either. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Fwd: ITP: glib2, gtk2, inti
* Christian Marillat | MAS> Indeed, but for package naming purpose I guess calling | MAS> them libglib2 and libgtk2 would work. | | I disagree. The API may change between 1.3.5 and 2.0 GTK has a very, very broken versioning. There is no connection between the soname of a library and the version of it. Take a library like slang. The package name is slang1, which means that the soname has a major version number which is 1. The version number of the package is 1.4.4-1 (in testing). This is the right way to do it - if you make backwards-incompatible changes, bump the soname's version number. Else, don't. Take another package - xlibs6g. It conforms to version 6 of the Xlib specification, while the package's version number is 4.0.3-3. Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. *sigh* -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: porting problem and how to request help
* Stefano Zacchiroli | How can I solve the problem? May I ask for help on debian-devel or on | debian-m68k ML? That is one of the ways of doing it, yes. m68k would probably be best. | Cause the problem is related to another package, may I close the bug on | ocaml-xstr and fill a new one against ocaml-findlib? No, you'd have to reassign it, not close and open a new one. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: packaging HTML, CGIs, etc.
* Michael Wiedmann | - make the package dependend on "httpd" reasonable | - install the files into "/var/www/openwebschool" reasonable | - should I install the CGI-scripts to "/usr/lib/cgi-bin" or somewhere in | a separate directory (how do I tell in this case the user to edit | "/etc/apache/srm.conf" or is there a generic way to edit the apache | conf files?) I'd install them into /usr/lib/cgi-bin/openwebschool, if there are many of them. Don't edit apache's config files yourself - leave that to the admin. -- Tollef Fog Heen You Can't Win
Re: packaging HTML, CGIs, etc.
* Britton
(don't cc me on lists.)
| > | - install the files into "/var/www/openwebschool"
| >
| > reasonable
|
| What is our policy regarding /var/www? I sort of thought this was a place
| where local sys admins could install their sites without worrying about
| bumping into packages.
from Debian Policy, 12.5. Web servers and applications
3. Web Document Root
Web Applications should try to avoid storing files in the Web
Document Root. Instead they should use the
/usr/share/doc/ directory for documents and register the
Web Application via the menu package. If access to the web
document root is unavoidable then use
/var/www
as the Document Root. This might be just a symbolic link to the
location where the system administrator has put the real document
root.
--
Tollef Fog Heen
You Can't Win
Re: packaging HTML, CGIs, etc.
* Jimmy Kaplowitz | On Mon, Jul 16, 2001 at 12:47:39PM +0200, Tollef Fog Heen wrote: | > * Britton | > | > (don't cc me on lists.) | | Why don't you set Mail-Followup-To: accordingly? Because, in Gnus it's a lot easier to set 'Mail-Copies-To: never' globally than a per-group mail-followup-to. And Debian policy says that you shouldn't Cc unless explicitly stated. | I know the default mutt setup respects that when I invoke the 'reply | all' feature (i.e., it won't reply to you if you have that set | right), whereas it ignores Mail-Copies-To: never. In mutt, it's a | simple matter of adding 'subscribe debian-' to your ~/.muttrc - this | takes care of adding the header for all mails sent to Debian mailing | lists. As you would have seen, if you had read my headers, is that I use gnus. And have no intention of switching. About 1.5GB/173K mails would be a small obstacle if I wanted to switch. -- Tollef Fog Heen You Can't Win
Re: Sponsors?
* Martin Sj|gren | I just entered an application for a sponsor on | http://www.internatif.org/bortzmeyer/debian/sponsor/ | | Is there anything else I should do? Ask here, if there is somebody who are interested in the packages you have packaged, you might get a sponsor quicker. -- Tollef Fog Heen You Can't Win
Re: Sponsors?
* Martin Sj|gren | On Wed, Aug 01, 2001 at 09:21:52PM +0200, Tollef Fog Heen wrote: | | > Ask here, if there is somebody who are interested in the packages you | > have packaged, you might get a sponsor quicker. | | Why that's a terrific idea =) :) | So, there you have it. The reason I picked this package is that I think | it's an extremely cool program, and I'm a math nerd, my minor is in maths, | focusing in algebra, so... Is it available via apt somewhere? (I might be interested in sponsoring you.) -- Tollef Fog Heen You Can't Win
Re: Lintian overrides
* Richard A Nelson | * sendmail source: dh_testversion-is-deprecated Just sendmail: dh_testversion-is-deprecated should work. -- Tollef Fog Heen You Can't Win
Re: Lintian overrides
* Richard A Nelson (Please don't cc me. It says so in the headers) | On 24 Aug 2001, Tollef Fog Heen wrote: | | > * Richard A Nelson | > | > | * sendmail source: dh_testversion-is-deprecated | > | > Just | > | > sendmail: dh_testversion-is-deprecated | > | > should work. | | Thats what I thought ! | $grep 'dh_t' lintian-overrides | sendmail: dh_testversion-is-deprecated Where do you place the lintian-overrides? They have to be installed into the package in /usr/share/lintian/overrides with the name of the package. -- Tollef Fog Heen You Can't Win
Re: Adoption of xcopilot: Who wants to be my sponsor?
* Ludovic Drolez | Also, why Pose is in contrib ? It needs the ROMs from the Palm, afaik. Which aren't free themselves. -- Tollef Fog Heen You Can't Win
Re: Native packages
* peter karlsson | Colin Watson: | | > If you can't build the Debian package as part of the process of | > generating the tarball from CVS, I suppose you could use -b and hack the | > .changes by hand to include the source, although that's rather ugly. | | I tried hacking the changes file by hand, but my upload got rejected three | times so I gave up... :-/ dinstall -n will go through the installation process without actually installing anything in the archive (and is runnable by normal users). That might help. :) -- Tollef Fog Heen You Can't Win
Re: lintian - man pages
* Stephen Stafford [from policy] | It is often a good idea to put text information files (`README's, | changelogs, and so forth) that come with the source package in | `/usr/share/doc/' in the binary package. However, you don't | need to install the instructions for building and installing the | package, of course! If the INSTALL file contains both building and installation instructions, and how to set up the package, what is then the correct way to handle that? Cut and paste the relevant portions into README.Debian or something? -- Tollef Fog Heen Axiom #1: You Can't Win
Re: lintian - man pages
* Robert Bihlmeyer | Tollef Fog Heen <[EMAIL PROTECTED]> writes: | | > If the INSTALL file contains both building and installation | > instructions, and how to set up the package, what is then the correct | > way to handle that? | > | > Cut and paste the relevant portions into README.Debian or something? | | That's obviously the most correct solution; but you should do this | only if you're comfortable with keeping this in sync with the | actual INSTALL file. This was one of my worries. | Personally, I have no problems with /usr/share/doc/foo/INSTALL that | contains set-up (or similar) information and some useless stuff. It | only annoys me if an INSTALL file is wholly useless to users of binary | packages -- e.g. GNU's standard INSTALL instructions. Ack, true, I agree Would this be too much magic to add to lintian -- check whether those are the generic GNU installation instructions or something else? -- Tollef Fog Heen Axiom #1: You Can't Win
Re: lintian - man pages
* "Sean 'Shaleh' Perry" (please don't Cc me, I read the list) | On 19-Oct-2001 Tollef Fog Heen wrote: | > If the INSTALL file contains both building and installation | > instructions, and how to set up the package, what is then the correct | > way to handle that? | > | > Cut and paste the relevant portions into README.Debian or something? | > | | The other choice is to rename the file. Which is just as good a solution as adding a lintian override in order to shut lintian up. That is IMHO not a very good one. -- Tollef Fog Heen Axiom #1: You Can't Win
Re: webserver directory locations when you're not using a webserver
* Hereward Cooper | Now what happens when you either don't have a local webserver, or | are not creating the gallery for it? Should the package put the | images/ directory in a directory some where (/etc/tigger/images/) | then get the user to move it to the apporiate place and telling them | to use "--imagedir=", noting this in the README.debian and man | page. I take it that making a depend on apache, and auto placing the | images/ in /var/www/images/ is out of the question. There isn't any policy on this one, but I have proposed one in bug #89867 against policy. If you think that is a good solution, please second my proposal. -- Tollef Fog Heen Axiom #1: You Can't Win
Re: quanta-doc ?
* Mariusz Przygodzki | [3] PHP Manual You probably know that this is already packaged as php3-doc? The title is a bit misleading - it's actually both php3 and php4-docs in it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Having ssh support non-US?
* Junichi Uekawa | It would be a non-problem if ssh provided rsh. It does, kind of: $ls -l /etc/alternatives/rsh lrwxrwxrwx1 root root 12 nov 17 16:23 \ /etc/alternatives/rsh -> /usr/bin/ssh* how about having mpich depending on rsh | ssh, and then using the link in alternatives? | Now, what about a package in main depending upon non-US/main. it shouldn't. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Having ssh support non-US?
* Junichi Uekawa | > how about having mpich depending on rsh | ssh, and then using the link | > in alternatives? | | No, the right way will be the package providing rsh having a "Provides: rsh" | in its description. | | A bug report is due, I think. perhaps so. | > | > | Now, what about a package in main depending upon non-US/main. | > | > it shouldn't. | | So, I can't just do it. no, afaik. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating man pages
* Drew Parsons | I wouldn't necessarily mind using SGML, but which tools exactly do you use. I use emacs with psgml. | For creating man pages I mean. How do you generate them from SGML? docbook-to-man is what I use. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
_i386 changes file for binary-all package?
I am building fortunes-bofh-excuses - just a couple of data files for fortune. It has a Architecture: all in the control file. However, building with dpkg-buildpackage generates a fortunes-bofh-excuses_1.1-1_i386.changes, not fortunes-bofh-excuses_1.1-1_all.changes as I would expect. Is it supposed to be that way? I couldn't find any information on it in the man pages for dpkg-genchanges at least. And also - if somebody could please sponsor the upload for me as soon as it's finished, I'd appreciate. TIA. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: _i386 changes file for binary-all package?
* Adrian Bunk | On 20 Dec 2000, Tollef Fog Heen wrote: | | >... | > It has a Architecture: all in the control file. However, building | > with dpkg-buildpackage generates a | > fortunes-bofh-excuses_1.1-1_i386.changes, not | > fortunes-bofh-excuses_1.1-1_all.changes as I would expect. | > | > Is it supposed to be that way? I couldn't find any information on it | >... | | It is supposed to be that way. Out of curiosity: why? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: _i386 changes file for binary-all package?
* Matt Zimmerman | On Wed, Dec 20, 2000 at 08:50:10PM +0100, Tollef Fog Heen wrote: | | > I am building fortunes-bofh-excuses - just a couple of data files for | > fortune. | | Is there any reason why they shouldn't be included in fortune proper? That they are distributed separately and that I am planning on packaging more of them? fortunes-kernel, fortunes-opensource, fortunes-jargon, maybe fortunes-calvin, fortunes-matrix etc? And that some of them get big - fortunes-jargon is about 1.2MB unpacked. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting a python module accepted by python?
* "Sean 'Shaleh' Perry" | I am trying to package soaplib, a python SOAP implementation. I copy the lone | soaplib.py to usr/lib/python1.5/site-packages/soaplib. My postinst runs | compileall.py (I copied python-xml). | | When I try to 'import soaplib' in python, I get an error: | | ImportError: No module named soaplib | | anyone know what I am missing? if you put it in ../site-packages/soaplib, you'll probably need to do 'import soaplib.soaplib'. I guess the fix is obvious. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting a python module accepted by python?
* Sean 'Shaleh' Perry | Is there a way to make a site-packages/foo/foo.py without requiring a change | in programs calling foo? Have site-packages/foo.py exist and do 'import foo.foo'. | Also, sorry to get off topic, but should the postinst compile the module? yes, afaik. | Won't this happen the first time the module is imported? No, not if the user doesn't have write access to where the module is located. Which she usually doesn't have. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testing vs. unstable
* peter karlsson | 2.0 is from November last year, and should be good enough to have | gone into testing, why hasn't it? Dunno, but you can check the status on http://ftp-master.debian.org/~ajt/update_excuses.html , as you probably know. | (2.0.1 fixes the only | bugreport on it and was released yesterday, so it should naturally stay | in unstable for a while). Yep: turqstat 2.0.1 (currently 1.2-1) (low) Maintainer: peter karlsson <[EMAIL PROTECTED]> only 2/10 days old So, unless it's dependant on other buggy packages, or you get any RC bugs, it will go into testing. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sponsor for mboxgrep
I've ITP'ed and packaged mboxgrep. If somebody could sponsor the upload for me, I'd appreciate. Deb-src line is: deb-src http://samfundet.no/~tfheen/debian woody main TIA. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Mon, Jan 22, 2001 at 09:38:15AM +0100, Christian Hammers wrote: | | > On Mon, Jan 22, 2001 at 08:13:57AM +0100, Martin Schulze wrote: | > > You should always be able to backport a patch. If not, I'm sorry, but that | > > this should be one quality of a Debian maintainer, you lack something... | > Martin? It it the quality of a Debian maintainer to find the right line(s) in | > a 100k C/C++ patch and moreover feeling sure enough about it to say that this | > fixes the security hole in one often used package?!?!?! Programming did not | > fall under the requirements of a maintainer, last time I checked. | | If a maintainer cannot program in the language in which her package is written, | how will she fix bugs, test patches, and generally understand how the packaged | software works on the inside? Such a maintainer is not a very effective one. So, for instance, the maintainer of postgresql must know perl, tcl, C, C++, python and java/jdbc very well? ( since it is written in C, and has interfaces for all the programming languages mentioned.) Of course, having an understanding of the programming languages is helpful, but IMHO not required in order to be a maintainer. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Tue, Jan 23, 2001 at 12:07:02PM +0100, Tollef Fog Heen wrote: | | > So, for instance, the maintainer of postgresql must know perl, tcl, C, | > C++, python and java/jdbc very well? ( since it is written in C, and | > has interfaces for all the programming languages mentioned.) | | Not necessarily. The core of the code is written in C, and the maintainer | should be able to read and write C comfortably in order to effectively maintain | the package. The interfaces for other languages are generally small bits of | glue that don't have very many bugs and don't change very often. 35960 lines of code for the jdbc interface is not what I call 'small bits of glue'. 2000 lines of perl glue (about 650 lines perl, the rest C) isn't necessarily little either - depending on the perl style. However, for python, you are right, about 300 lines of python and 2300 lines of C. (note that all those numbers are from "wc -l"'ing the source files, so it includes blank lines etc. | In the event that a problem arises with the Tcl bits, I imagine I | could post a message here or elsewhere and ask for help. of course. As you could if the problem was not knowing enough C or some other language. | If I needed to do this every time a change was necessary in a C | source file in one of my packages, my progress would be very slow | indeed. I guess that depends a lot on the package. Many packages which use autoconf and automake do only need dh_make and then some minor adjustments. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security upgrade for potato by new major version and distro change?
* Matt Zimmerman | On Tue, Jan 23, 2001 at 10:13:33PM +0100, Tollef Fog Heen wrote: | | > * Matt Zimmerman | > | > | Not necessarily. The core of the code is written in C, and the maintainer | > | should be able to read and write C comfortably in order to effectively maintain | > | the package. The interfaces for other languages are generally small bits of | > | glue that don't have very many bugs and don't change very often. | > | > 35960 lines of code for the jdbc interface is not what I call 'small | > bits of glue'. 2000 lines of perl glue (about 650 lines perl, the | > rest C) isn't necessarily little either - depending on the perl | > style. | | If the Java portion of the code really is that extensive, then I would say yes, | the maintainer should be familiar with Java programming. AFAIK, there is no | standard way to call C code from Java (and indeed this would violate the Java | platform model), so I can imagine that the code is nontrivial. Since this is a database engine, the java calls are jdbc, which works over TCP/IP, so that is not a problem. And you have JNI where you can call standard code. | I'll say that the maintainer should be at least as knowledgeable as | the average user about his/her package. A good maintainer will know | his/her packages very well indeed. I see this as one of Debian's | strengths: since packages are maintained by volunteers who take an | active interest in them, they tend to be well cared for. Yep. I am not saying that a maintainer should not know the language - I am just saying that to maintain something written in C, you don't need to be a C guru. | > | In the event that a problem arises with the Tcl bits, I imagine I | > | could post a message here or elsewhere and ask for help. | > | > of course. As you could if the problem was not knowing enough C or some | > other language. | | The difference is one of scale. If I didn't know enough about the core of a | package that I had to post to debian-devel about most issues with the code, I | wouldn't be maintaining the package anymore; -devel would, with me as a | sponsor. And you'd probably learn your C pretty fast. ;) | > I guess that depends a lot on the package. Many packages which use autoconf | > and automake do only need dh_make and then some minor adjustments. | | In order to be packaged initially, sometimes it's this easy. But to be most | useful to Debian's users? To be best integrated with the rest of Debian? To | be maintained in the long term? Actually - it seems to be about that easy. I am not very into emacs lisp programming, but packaging up the new version of JDE (by using the old maintainer scripts and updating them) and the three support packages it now needs didn't take me more than a couple of hours. I believe I can maintain them quite well, even though I am not a elisp guru. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chroot and FHS
* Christian Hammers | I like to build my mysql package with chroot support and therfore jail it | somewhere under /var/lib/mysql and link the log files to /var/log. | | I either statically link it so that it can be run from /usr/sbin and then | live in /var/lib because I don't want to have binaries in /var or | hardlink the libs from /usr/lib and /lib to /var/lib/mysql? | Without trying it out I would say that the latter way is preferred, isn't it? No. Hardlinks doesn't work across filesystems and /usr is quite often on it's own partition. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use and abuse of Debconf, follows-up
* (Jérôme Marant) | I know I'm not doing The Right Thing since I'm modifying conffiles | but I don't understand why this would not be elegant and disgusting. Because you'll get questions from dpkg about a changed conffile. | I would apreciate any suggestion for improving this. Don't mark the file as a conffile? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentor request
* Joshua Haberman | Lintian complained at the very end of the latter build: | | W: audacity: unknown-section unknown | | Is that a section in the executable file? dh_strip runs successfully | earlier in the build. In the control file you have something like Section: unknown And since Debian doesn't have a section named unknown, lintian complains. | What am I to do when there is another upstream release? Should I simply | copy the "debian" directory out of the old tree and into the new, update | the changelog, and rebuild? Something like that, yes. If you change anything outside debian/ you might want to use the patch instead. | What about an incremental release, to fix a bug on my (wearing the | package maintainer's hat) part? Am I supposed to make a diff of my | changes? This is not a debian-specific package, right? Just update the changelog, fix your packaging and off you go. | Lastly, what do I need to take into consideration to accomidate for | people who wish to do a source build? How would I note that to build on | potato, you must manually download and compile wxWindows and libvorbis? Put them in the build-depends line. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Wed, Feb 21, 2001 at 02:30:13PM +0100, Richard Atterer wrote: | > Hi, | > | > how do you invoke dpkg-buildpackage for a binary-only NMU? In section | > 8.2 "Guidelines for Porter Uploads", the Developer's Reference says: | > | > In a binary NMU, no real changes are being made to the source. You | > do not need to touch any of the files in the source package. This | > includes debian/changelog. | | debian/changelog is not in source of the package. Is that really written in | the developers reference (too lazy to check that now)? Of course. If you change the source, you need to bump the version number. That is a _source_ NMU, since we need to able to build the packages from the source we have around. A binary NMU should not touch the source. Remember - a buildd building and uploading is, technically, doing an NMU. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Thu, Feb 22, 2001 at 12:44:24PM +0100, Tollef Fog Heen wrote: | > * "Christian T. Steigies" | > | > | debian/changelog is not in source of the package. Is that really written in | > | the developers reference (too lazy to check that now)? | > | > Of course. If you change the source, you need to bump the version | You mean of course, yes? No, it was a remnant from my first sentence. So much for reading through the mail before sending it. | > number. That is a _source_ NMU, since we need to able to build the | > packages from the source we have around. | > | > A binary NMU should not touch the source. Remember - a buildd | > building and uploading is, technically, doing an NMU. | | When I rebuild a package to fix dependency problems (recent example, aview | in potato/m68k depended on a library which was not in potato, so I rebuilt | aview with the potato libraries, changed nothing in the source, only bumped | up the version number, with sbuild, which adds a changelog entry to say just | this: no source changes) that is not ok in your eyes? >From the developers reference: A source NMU is an upload of a package by a developer who is not the official maintainer, for the purposes of fixing a bug in the package. Source NMUs always involves changes to the source (even if it is just a change to debian/changelog). This can be either a change to the upstream source, or a change to the Debian bits of the source. A binary NMU is a recompilation and upload of a binary package for a new architecture. As such, it is usually part of a porting effort. A binary NMU is a non-maintainer uploaded binary version of a package (often for another architecture), with no source changes required. There are many cases where porters must fix problems in the source in order to get them to compile for their target architecture; that would be considered a source NMU rather than a binary NMU. As you can see, we don't distinguish in terminology between porter NMUs and non-porter NMUs. You fall between two chairs - as noted in 7.4.3: What if you are simply recompiling the package? In this case, the process is different for porters than it is for non-porters, as mentioned above. If you are not a porter and are doing an NMU that simply requires a recompile (i.e., a new shared library is available to be linked against, a bug was fixed in debhelper), there must still be a changelog entry; therefore, there will be a patch. If you are a porter, you are probably just doing a binary NMU. (Note: this leaves out in the cold porters who have to do recompiles -- chalk it up as a weakness in how we maintain our archive.) But the situation is clarified in 8.2: Sometimes you need to recompile a package against other packages which have been updated, such as libraries. You do have to bump the version number in this case, so that the upgrade system can function properly. Even so, these are considered binary-only NMUs -- there is no need in this case for all architectures to recompile. You should set the version number as in the case of NMU versioning, but add a ``.0.'' before the the NMU version. For instance, a recompile-only NMU of the source package ``foo_1.3-1'' would be numbered ``foo_1.3-1.0.1''. The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -mporter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependant portions of the package, using the `binary-arch' target in debian/rules. | Technically you may be right, but practically we (well, at least I) do it | like this, just to get things working. Its not necessary that all arches | rebuild hundreds of packages, only because m68k only recently switched to | glibc2.2. And I think thats exactly the reason for the NMU version | numbering. After all, we just recompile the package with a new libc library | installed. Yes, you are right. But there are not problems with hundreds of packages, are there? | Maybe the Developers reference should be clarified, or will I be | expelled from the project now? I guess the Developers reference should be clarified (the 7.4.3 that is, as it seems to be clarified in 8.2). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to do binary-only NMU?
* "Christian T. Steigies" | On Thu, Feb 22, 2001 at 02:18:56PM +0100, Tollef Fog Heen wrote: | | > Yes, you are right. But there are not problems with hundreds of | > packages, are there? | | No, only 80 known packages currently | http://people.debian.org/~cts/debian-m68k/quinn/needs-failed | but an unknown number of not-yet-known problems. ouch! | > I guess the Developers reference should be clarified (the 7.4.3 that | > is, as it seems to be clarified in 8.2). | | Well, yes, maybe. I just take it that porters are different and prefer to | spend time on porting over writing the laws. Developers reference is just that - a reference. It's not the law. Policy is 'law'. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to do binary-only NMU?
* Itai Zukerman (please don't cc me, I'm on the list) | 1. If all you're doing is a compile for a new architecture, then why | is it necessary to bump the package version? If you modify *anything* | in debian/* (for example, the Architecture or Build-Depends fields in | debian/control), then it seems to me this isn't a binary-only NMU. If you just compile for a new version, then you don't bump the version number. It's just if you have to recompile (that you bump the version number). The reason one might need to recompile might be that glibc2.1 had a bug which was fixed in 2.2. You don't want the package to be rebuilt on every other architecture, just because of that. If you are fixing any bugs, then it's a source NMU. And if it's a source NMU, you bump the debian revision by 0.1. | 2. Suppose you bump the package version but nothing in debian/* | changes. Then to re-build the package from source I need to run a | special command; "debian/rules build" won't give me quite the same | thing, right? So I need to know how the binary was built to compile | it properly myself. No, it will work the same in both cases, but the debian revision number will differ by 0.0.1. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bsh gone?
I took over jde some time ago. jde depends on bsh. bsh exists in testing, but not in unstable, apparently (since I got a bug report saying that I depended on a non-existant package). So - what to do? Package bsh myself? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bsh gone?
* (Colin Watson) | Tollef Fog Heen <[EMAIL PROTECTED]> wrote: | >I took over jde some time ago. jde depends on bsh. bsh exists in | >testing, but not in unstable, apparently (since I got a bug report | >saying that I depended on a non-existant package). | > | >So - what to do? Package bsh myself? | | It's in unstable, it's just in contrib. If jde depends on it, you'll | need to move that into contrib too. yes, thanks. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I would like to debianize mod_gzip
* Britton | Yes, you should check the wnpp page http://www.debian.org/devel/wnpp/index | to make sure no one else is already working on it, then announce you | intent to package by filing a wishlist bug against wnpp as per the | instructions in the developers reference (which you should read :). Actually - he should rename the RFP bug to an ITP. | > I would like to debianize mod_gzip requested 5 days ago. Since I'm not an | > official debian maintainer (yet) I'll probably need a sponsor for this package | > (any volunteers ?). Should/can I submit a bug announcing my intention ? I can sponsor you. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Where to place images?
This is sent to both -policy and -mentors, as it's both a proposal and a request for clarification/help. Please Cc me as I'm only subscribed to -mentors. I am in the process of fixing Mailman, which I've just adopted. There is this bug, #61761 (http://bugs.debian.org/61761 ), where the submitter complains that the mailman logo is broken by default (when not accessing from localhost). This is because the images are in http://localhost/doc/mailman/images/, which is only accessible from localhost. The submitter proposes that they should be put in, /var/www/mailman-images or something like that. Policy has something to say about this, 12.5: : Web Document Root : : Web Applications should try to avoid storing files in the Web : Document Root. Instead they should use the /usr/share/doc/ : directory for documents and register the Web Application via the : menu package. If access to the web-root is unavoidable then use : /var/www as the Document Root. This might be just a symbolic link to : the location where the sysadmin has put the real document root. However, I'd like to put images in something like /usr/share/web-images, since I _might_ end up cluttering around and overwriting files which I shouldn't, by placing the images in /var/www/mailman-images. Also, it looks messy, IMHO. So what I propose is that we create a new directory /usr/share/images (or something like that), which is available via the web as http://server/images/. Packages create sub-directories, so that Mailman will have /usr/share/images/mailman/logo.jpg which will be referred to as http://server/images/mailman/logo.jpg . -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to place images?
* Jérôme Marant | En réponse à Tollef Fog Heen <[EMAIL PROTECTED]>: | | > | > localhost. The submitter proposes that they should be put in, | > /var/www/mailman-images or something like that. | | I'm the maintainer of the sympa mailing list manager. | I've stored the images used by the web frontend (wwsympa) in | /usr/share/sympa/icons. | | /usr/share/ is used by many (web) applications for | that purpose. How do you serve them then? Add a line to srm.conf, or symlink or a small helper app or something entirely else? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to place images?
* Jérôme Marant | With sympa, you just have to give the web alias for accessing | images. So the admin is responsible for setting this up himself? I don't want to mess around with possibly-changing syntaxes in the different httpds' configuration files. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: e-mail address changed
* Stefano Zacchiroli | I've changed my e-mail address, so my last upload of a package seems to | be a NMU, how I fix the problem ? Change the email address in the control file as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binary-only upload
* peter karlsson | I just noticed that a package I submitted was built on the wrong | machine here at home, and is linked against wrong libraries. Can I, as | the maintainer, do a binary "NMU" where I only recompile the package | against the correct libraries? How do I go about and do that? Increase the version number by 0.01, recompile and upload. See the developers reference 8.2, third paragraph. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binary-only upload
* peter karlsson | Tollef Fog Heen: | | > Increase the version number by 0.01, recompile and upload. See the | > developers reference 8.2, third paragraph. | | So, how do I change the version number without touching the changelog? You touch the changelog, but you don't include that changelog entry in the next 'normal' upload. IIRC, that is what the consensus on -mentors was last time it was discussed. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ldd, dpkg-shlibdeps and libsocks.so
I am the maintainer of suck, which links against libsocks. However, it seems like there is something strange going on when it comes to linking: $ldd `which suck` libsocks.so => /usr/lib/libsocks.so (0x4001f000) libnsl.so.1 => /lib/libnsl.so.1 (0x4002d000) libc.so.6 => /lib/libc.so.6 (0x40043000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) $ Here, suck is linked against libsocks.so, without a version number. This makes dpkg-shlibdeps complain about 'format of libsocks.so not recognized'. (Which really is 'format of file name "libsocks.so" not recognized'). Why does this happen, and is this a bug in suck, dpkg-shlibdeps or libsocks4? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldd, dpkg-shlibdeps and libsocks.so
* Ben Collins | It is a bug in libsocks4, which should compile the library with -soname | libsocks.so.4. I'm willing to bet that libsocks.so is created by | ldconfig when libsocks4 is installed, else it wouldn't even work without | the -dev package installed. So reassigning the bug against libsocks-dev is the right thing to do? Thanks! -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undocumented binary
* Sven LUTHER | Maybe all manpage needing binaries could be listed somewhere, and we could | have a manpage writing task ? http://qa.debian.org/man-pages.html :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: directory in .deb
* M G Berberich | I'm not sure if I'm welcome her, because I'm not maintaining a | official debian-package but trying to make .deb's out of my tools. No problem. We are including here. :) | I have a tool that needs a directory /var/log/ppplog. It is contained | in data.tar.gz, but tar does not set the required right on the | directory (right?). So I set the right in the postinst script. It's usually better to set it in the package building script. Less messy, IMHO. | The package also puts a executable in /etc/ppp/ip-down.d. Building the | binary leads to a complain about an executable in unusual place (or | so). Can I prevent this? Are there naming-conventions for script in | /etc/ppp/ip-down.d? I don't know. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging of freenx
* "Roberto C. Sanchez" | On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote: | > On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote: | > > I asked a while back (on IRC) about packaging the NX components that are | > > under the GPL. Someone pointed me to Fabian's packages in Skole Linux. | > > Anyhow, those packages are 6 months old and probably not going into | > > Debian. Fabian has also not responded to my email. | > | > See #255850, maybe it could give you some information. | | OK. No activity in more than a year. The website where the packages | were offered early in the thread no longer exists. | | If there are no objections, I will take over the ITP. I talked with Stefan Lippers-Hollmann a few days ago about it and apart from some technical problems with it (namely that the NX build system is an interesting case of «let's see how messed-up we can make this build» and no development package), it's almost ready to go into sid. I've offered to sponsor him if he needs that and would be interested in helping out with packaging. Note that there's a pkg-nx repository on alioth too, even though it hasn't been used for anything yet. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Source Code One Line Change [patch] and Copyright holder
]] "Nanakos V. Chrysostomos" | recently I have contributed a on-line patch [0] that resolves a | significant and major security bug in a PAM module. I added myself to the | Copyright holders of the file and added this change to the changelog file | as you can easily see in [1]. The upstream author and developer of this | software claims that I am not intended to add my name for such a small | change to the Copyright holders of the file and he should ask for legal | advise. What is your opinion? Is this right? I think he's in the right, your contribution does not really consist of any significant creative effort. I'm also unable to reproduce your bug. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkiwqvmx@qurzaw.varnish-software.com
Re: Mentors upload authentication
]] Michael Gilbert > In this case, I think it would be possible to use ssh public keys as > that authentication. The process would be: This seems overly complex, why not just have the user put all those files in a well-known location on alioth (or some other host) and have the mentors code download and DTRT with that bunch of files. As for removing non-distributable files, that's not something we're going to entrust to another team, any such removal requests will go through admin@alioth. [...] > > Just to be clear, alioth is not a regular debian.org machine. It isn't > > admined by the same team, accounts are not handled in the same way, > > and privileged groups on Debian machines have no special privilege on > > alioth machines. > > I understand that, but I don't see how that has to do with the DMUP, > which is a usage policy intended for debian machines of which alioth > is one. Otherwise, it seems like it fine to misuse alioth in ways > that violate the DMUP, but not any other machine. That a machine is not subject to agreement to the DMUP does not mean any other use of said machine is ok. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nukjip2@qurzaw.varnish-software.com
Re: lintian -i file.changes error
* "Sean 'Shaleh' Perry" | However, as I stated in my reply when this came up on lintian -- | hard links are BAD. Symlinks were invented for a reason. I believe you mean something like 'multiple hard links to the same file are bad'. A single hard link is _very_ useful, imho. ;-) And multiple ones for directories. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gpg keyrings.
* Britton | On 30 Apr 2001, James Troup wrote: | | > Julian Gilbey <[EMAIL PROTECTED]> writes: | > | > > (1) It could be documented on http://keyring.debian.org/ | > | > I'm sure it could...[0] | | Is the procedure for useing anon-rsync documented somewhere else? rsync keyring.debian.org::keyrings/keyrings/debian-keyring.gpg ~/.gnupg/ and add keyring debian-keyring.gpg to ~/.gnupg/options -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My First Package. Wheee.
* Warren Anthony Stramiello
| a) inclusion in the testing distribution, if still possible
Is handled automagically, if you haven't screwed up anything ;) (that
is, it goes into testing after 10 days of testing in unstable, unless
it has RC bugs, that is). Read more at http://ftp-master.debian.org/testing/
| b) inclusion in the unstable distribution, if still possible
That's were we all upload to.
| c) uploading using dupload and scp
Add something like
package config;
$cfg{'ftp-master'} = {
fqdn => "ftp-master.debian.org",
login => getlogin() || $ENV{USER} || $ENV{LOGNAME},
incoming => "/org/ftp.debian.org/incoming/",
mailto => "debian-changes\@lists.debian.org", # stable
mailtx => "debian-devel-changes\@lists.debian.org", # unstable, exper.
visibleuser => getlogin() || $ENV{USER} || $ENV{LOGNAME},
visiblename => "",
fullname => "",
# The dinstall on master now sends announcement itself. May 1999.
dinstall_runs => 1,
method => "scpb"
};
$default_host = "ftp-master";
1;
to ~/.dupload.conf
and run
dupload xdrawchem_0.85-1_i386.changes
The changelog decides whether it goes into stable or unstable. Unless
you have _very_ good reasons for it going into stable, it should go
into unstable. Very good reasons include security holes and that the
package as it is in stable is totally unuseable.
Be sure to run lintian on your package before uploading it, though. :)
--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: web app packaging question
* David LaBissoniere | I am packaging the freeside isp billing and account management program. | This package consists largely of many (44) cgi scripts (which reference | each other often) spread into several subdirectories. Some of the | scripts have the same name (for example, view/cust_bill.cgi and | search/cust_bill.cgi). Debian policy states that cgi scripts should be | placed in /usr/lib/cgi. I am guessing that I am not allowed to create | subdirectories in here as apache would no longer view the scripts as | executable? Well, a subdirectory works for mailman, so it should work for you as well. And it is the right way when using many CGIs, imho. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question on a licence
* Noel Koethe | $ less COPYRIGHT | /* | * Copyright University of Manitoba 1998. | * Written by J. Gary mills | * | * Permission is granted to anyone to use this software for any purpose on | * any computer system, and to alter it and redistribute it freely, | subject | * to the following restrictions: | * | * 1. The author and the University of Manitoba are not responsible | *for the consequences of use of this software, no matter how awful, | *even if they arise from flaws in it. | * | * 2. The origin of this software must not be misrepresented, either by | *explicit claim or by omission. Since few users ever read sources, | *credits must appear in the documentation. | * | * 3. Altered versions must be plainly marked as such, and must not be | *misrepresented as being the original software. Since few users | *ever read sources, credits must appear in the documentation. | * | * 4. This notice may not be removed or altered. | */ I don't see any problems with this license, it says that you have to say that if you modify the sources, you have to say where you got the sources from - similar to the BSD license. Also, they have a no-warranty section, which is just fine. So, I don't see what you might think that would be a problem with the license. | Sorry, if this is the wrong list. Please tell me the right one. debian-legal, but -mentors isn't too bad either. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: ITP: glib2, gtk2, inti
* Christian Marillat | MAS> Indeed, but for package naming purpose I guess calling | MAS> them libglib2 and libgtk2 would work. | | I disagree. The API may change between 1.3.5 and 2.0 GTK has a very, very broken versioning. There is no connection between the soname of a library and the version of it. Take a library like slang. The package name is slang1, which means that the soname has a major version number which is 1. The version number of the package is 1.4.4-1 (in testing). This is the right way to do it - if you make backwards-incompatible changes, bump the soname's version number. Else, don't. Take another package - xlibs6g. It conforms to version 6 of the Xlib specification, while the package's version number is 4.0.3-3. Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. *sigh* -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: porting problem and how to request help
* Stefano Zacchiroli | How can I solve the problem? May I ask for help on debian-devel or on | debian-m68k ML? That is one of the ways of doing it, yes. m68k would probably be best. | Cause the problem is related to another package, may I close the bug on | ocaml-xstr and fill a new one against ocaml-findlib? No, you'd have to reassign it, not close and open a new one. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging HTML, CGIs, etc.
* Michael Wiedmann | - make the package dependend on "httpd" reasonable | - install the files into "/var/www/openwebschool" reasonable | - should I install the CGI-scripts to "/usr/lib/cgi-bin" or somewhere in | a separate directory (how do I tell in this case the user to edit | "/etc/apache/srm.conf" or is there a generic way to edit the apache | conf files?) I'd install them into /usr/lib/cgi-bin/openwebschool, if there are many of them. Don't edit apache's config files yourself - leave that to the admin. -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
