Re: MIME support in Debian.
Daniel Leidert gmx.net> writes: > > Am Samstag, den 22.12.2007, 23:34 +0900 schrieb Charles Plessy: > > > Also, if there are two such > > programs installed, is there something that can be done through MIME so > > that the user has a chance to chose the program ? > > Not directly through MIME (the MIME RFCs just describe the so called > Internet Content type, e.g. "text/plain" - association with programs is > AFAIK not part of the MIME standard). This has been described in the > fd.o standard: > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Isn't the mailcap.order file (or similar, I'm currently condemned to use a Windows box) used for that, probably together with update-mime? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: latexdiff (take 2)
"Sandro Tosi" <[EMAIL PROTECTED]> wrote: >> So let's give them a chance to see this email (I add in CC) :) > > Ok, chance given, no reply, I'm checking :) Seen, but no time to look at other people's packages at the moment (and in the foreseeable future). > - why are you using both cdbs and debhelper 7? they almost aim to do > the same thing, and I encourage to use dh7 By the way, I won't check or even sponsor any package that uses cdbs. I want to understand the packaging, and I never grokked cdbs enough to upload a package using it. Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problems authenticating to svn.debian.org
Hi, I have a problem authenticating to svn.debian.org. I can checkout the pkt-tetex project without problems when I do it without authentification, i.e. read-only, but it says it cannot find the repository when I try with ssh: $ svn checkout svn://svn.debian.org/pkg-tetex/ A pkg-tetex/tex-common Checked out revision 34. $ rm -rf pkg-tetex/ $ svn checkout svn+ssh://[EMAIL PROTECTED]/pkg-tetex/ Enter passphrase for key '/home/frank/.ssh/id_rsa': svn: No repository found in 'svn+ssh://[EMAIL PROTECTED]/pkg-tetex' $ When I'm logged in (using ssh with rsa authentication) on svn.debian.org, I do have write access to the repository. How can I find out what I'm doing wrong? I've tried both with the default files in ~/.subversion, and with ~$ egrep -v '^$|^#' .subversion/config [auth] store-passwords = no store-auth-creds = no [helpers] [tunnels] deb = fsh -l frank [miscellany] [auto-props] ~$ egrep -v '^$|^#' .subversion/servers [groups] debian = svn.debian.org [debian] svn-tunnel = ssh [EMAIL PROTECTED] [global] ~$ TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: problems authenticating to svn.debian.org
Paul Wise <[EMAIL PROTECTED]> wrote: > Try this: > > svn checkout svn+ssh://[EMAIL PROTECTED]/svn/pkg-tetex/ Oh, thanks - the additional /svn/ in the path did the trick. This should be documented on alioth... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Program source including another program source
martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Robert Lemmen <[EMAIL PROTECTED]> [2005.07.21.0958 +0200]: >> personally i would leave it there to preserve the pristine upstream >> tarball, but only if: >> - the program isn't used, especially if it is a license >> - the included program is also dfsg-free > - it doesn't take up too much space. > > I don't think that the "pristine upstream" idea is all that > necessary. Don't make changes, but removing stuff should be ok. In any case, follow the suggestions about repackaging that are now in the Developers' reference. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Unknown default encoding?
"Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > Hi guys, > > I get the following warning when building cernlib on sid: > > dh_installdebconf -a > Warning: Unknown default encoding for vi, get it from debian/po/vi.po: UTF-8 > [...] > Can someone tell me what I'm doing wrong, if anything? You didn't file a wishlist bug against po-debconf to add a default encoding for vietnamese in /usr/share/po-debconf/encodings ;-) > A Google search > for this error turned up little besides package build logs Use the source, Luke. No occurence of "Unkown default" in dh_installdebconf, but it calls po2debconf which contains this string, leading to the correct file even if you don't know perl. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Sponsor request for aspell-uz
Brian Nelson <[EMAIL PROTECTED]> wrote: > * You probably shouldn't repack the .tar file so that the md5sum will > match the upstream version. Usually for an upstream that distributes > a .tar.bz2, you just want to do "bunzip2 foo.tar.bz2; gzip -9 > foo.tar" and then use the resulting .tar.gz. See also http://www.de.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz >> It passed lintian -i test, but linda -i complained about l-uz.cmap file >> being installed into /usr/lib. > > Safe to ignore. It's an aspell upstream issue if anything. If it is a bug, it's still a bug; whether it should be fixed in a Debian-specific patch or by pestering upstream about it is at the descretion of the maintainer. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Can I simulate a weak conflict?
Nicolas Boullis <[EMAIL PROTECTED]> wrote: > Oh, and I just thought there could be a workaround. I could make a new > no-udev empty package that conflicts with udev, and then write > "Recommends: no-udev | udev (>= 0.060-1)". An elegant solution ;-) > I guess this would behave as expected, but I think that having one more > package only for this would be quite insane! Especially because others would pick up the idea... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: what if the upstream version contains hyphens?
kamaraju kusumanchi <[EMAIL PROTECTED]> wrote: > I intend to package gnuplotfortran whose upstream is available at > http://sourceforge.net/projects/gnuplotfortran .The upstream released > sources whose version is 0.2.2-1 . > > My questions are > > 1) What would be the corresponding Debian version? Should it be > 0.2.2-1-1 or should i pretend the upstream's version is 0.2.2.1 and > name the debian version to be 0.2.2.1-1? As far as I remember, 0.2.2-1-1 is a perfectly valid Debian version, the Debian revision will be the part after the last hyphen. > 3) Are there any other packages which have/had this problem > previously? How is/was it solved? My netenv package has this problem, and while back I solved it indeed by changing the upstream version. Meanwhile I was convinced that this wasn't necessary, but unfortunately I forgot when and where this was discussed. > The maint-guide currently is silent about this problem. But if there > is some other documentation available which helps in this regard, I > will be happy to read it. The question is whether it matters at all. I don't know whether any tool¹ actually discriminates between upstream version and Debian revision; dak does not when checking for NMUs. Regards, Frank ¹except editing things like the Debian changelog mode of Emacs... -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: predepends/depends order
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Tue, Aug 16, 2005 at 01:33:37PM +0200, Sandro Dentella wrote: >> hi, >> >> I'm preparing a package that is meant to setup a PDC with ldap and samba >> mainly for schools. The target that will use it is fairly anaware of most >> of the quantity of things that should be configured in such a setup and I >> don't mean to explain more than necessary. >> >> My package (isi-ldap3) depends on a veriety of other packages (pkg1, >> pkg2...) that place questions via debconf, so I thought to fill debconf >> variable (of pkgN) via a package isi-ldap3-pre) that should place very >> simple questions and take decision that I consider "difficoult" for my >> target (super?)user. >> [...] > Depends is sufficient for you; Policy 7.2: > > | `Depends' > | This declares an absolute dependency. A package will not be > | configured unless all of the packages listed in its > | `Depends' field have been correctly configured. I don't think this is sufficient for the purpose. What he wants is to create a package A-pre that is configured earlier than all packages B,C,D, where B,C,D are the packages A depends on. I don't have an idea how this could be done. The only alternative I see is to tell the people "install A-pre first, then install A which will pull in B,C,D"; or to create a script in A-pre that will ask the debconf questions and then ask "You must install A,B,C and D for this to have an effect. Proceed" and run apt-get install A B C D. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: autotools during build
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Fri, Aug 12, 2005 at 10:23:54PM -0400, Joey Hess wrote: >> Steve Langasek wrote: >> > Hmm, I'm not really sure whether that fits with policy's intent regarding >> > the effects of the debian/clean target. >> >> This must undo any effects that the `build' and `binary' targets >> may have had, except that it should leave alone any output files >> created in the parent directory by a run of a `binary' target. >> >> I don't see the conflict. There is an unstated intent that the clean target >> should not leave the package in an unbuildable state, but it doesn't if >> your rules file runs the autotools. > Agree. Is it reasonable to request a policy update with new wording? > Including: > > It should be possible to build the package multiple times. s/should/must/ Maybe explicitly mentioning autotools is worth the effort, since this seems to be the only case where it is an issue, and might help to prevent people from inventing "false" uses. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: predepends/depends order
Bas Wijnen <[EMAIL PROTECTED]> wrote: > On Tue, Aug 16, 2005 at 10:46:34PM +0200, Sandro Dentella wrote: >> > I may be missing the problem, but as far as I understand it you want B, C, >> > and D to have Depends: A. If they don't have it and cannot be used >> > without A, file a bug report. If they can also be used without A then you >> >> no! salpd as an example con live w/o my package, that depends on that. > > In that case it is not your business to demand that your package is configured > before them. Theirs can have been installed years ago. It seems you just > want to allow people to not need to answer questions for packages which are > not yours. No, he's preparing a package that will ask simpler questions, assume a certain environment and preseed the questions for the other packages. I guess Goswin's suggestion to look at CDD is the best so far. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: wdm - WINGs Display Manager - an xdm replacement with a WindowMaker look
Vladimir Shakhov <[EMAIL PROTECTED]> wrote: > Description: WINGs Display Manager - an xdm replacement with a WindowMaker > look [...] > I suppose to revive this package from poor current state. Great to hear that. Sorry that I don't have time to sponsor you, but I've got enough time to tell everybody that I think this package really deserves some care! Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: predepends/depends order
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 03:31:42PM +0200, Goswin von Brederlow wrote:
>> Impossible. What you need is for the packages you want to preconfigure
>> to Depend on isi-ldap-pre. Which means rebuilding all of them.
> OH. I see.
>
>> Sandro Dentella <[EMAIL PROTECTED]> writes:
>>
>> > hi,
>> >
>> > I'm preparing a package that is meant to setup a PDC with ldap and samba
>> > mainly for schools. The target that will use it is fairly anaware of most
>> > of the quantity of things that should be configured in such a setup and I
>> > don't mean to explain more than necessary.
>> >
>> > My package (isi-ldap3) depends on a veriety of other packages (pkg1,
>> > pkg2...) that place questions via debconf, so I thought to fill debconf
>> > variable (of pkgN) via a package isi-ldap3-pre) that should place very
>> > simple questions and take decision that I consider "difficoult" for my
>> > target (super?)user.
> You mean you want THOSE packages to depend on YOUR package, not your
> package depending on them?
>
> That doesn't happen. Low-level things must not depend on high-level
> things; it doesn't make any sense. Otherwise, someone who wanted to
> use samba without using your package wouldn't be able to.
The point is that this "someone" decided that they want Sandro's scripts
to get an easier way to setup THOSE packages, taylored for their
specific usage case.
And the solution, as already pointed out a couple of times, is CDD.
> Note that the admin _must_ run the tool manually; it must not run
> automatically in postinst or some such. Doing so would violate policy
> by fudging with other packages conffiles (it is allowed to modify
> other packages conffiles, if it is a specialized editor which is used
> manually only).
You're thinking too standard-Debian-specific :-)
> Note also that modifying configuration files which are not conffiles
> must be done through a well-defined interface, which would probably be
> provided by the other packages. Such an interface is usually
> /usr/{s,}bin/update-foo. Modifying such a file any other way is a
> policy violation.
You forgot that he wants to simply preseed debconf answers.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Re: RFS: auctiongallery -- Generates picture galleries and HTML templates for auction descriptions
Stan Vasilyev <[EMAIL PROTECTED]> wrote: > I can make a new version and add features that allow users to have their > own settings, like ~/auctiongallery/auctiongallery.conf, > ~/auctiongallery/templates and ~/auctiongallery/auctions. This should be ~/.auctiongallery, of course. > However that > kind of defeats the purpose of my software because it is aimed at eBay > powersellers who have many employees. The way I have auctiongallery set > up at my work is the following. All auction descriptions and pictures go > to a common directory /home/auctiongallery. All users have the same > config and the same templates unless they run auctiongallery with -c and > -t overrides. That way all employees are part of one team and everything > works nicely. So what's the difference then to having the configuration in /etc/auctiongallery? >>PS: Please try to follow the common quoting style: Quote only what you >>directly refer to, only as much as needed and quote each part you are >>replying to directly above your respective answer/comment. That makes >>reading your postings a lot easier. You should read and follow that advice, not just quote it. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: install-info problems with DOS encoded files
"W. Borgert" <[EMAIL PROTECTED]> wrote: > Quoting Norbert Preining <[EMAIL PROTECTED]>: >> Is this a bug in the install-info program, or should I convert all the >> info files to unix lineendings? > > The latter. Please do it either during build in the package directories, or in the texlive repository. Having all these changes in diff.gz would make them unreadable (imagine you want to patch an info file to add Debian-specific information...) Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: gips - an isotopic pattern calculator
Christoph Haas <[EMAIL PROTECTED]> wrote: > Are there multiple 0.7 versions? :) > > Further annotations: > - your debian/changelog looks strange :( > - please tidy up the debian/rules file :( > - building the package works well :) > - when I tried to use the "Help" menu item I had a segfault :( > > Could you please fix these minor issues? Some further comments: - you are also the upstream developer of this package. Do you use Debian, or would you just like to see it included in one more distribution? I'm asking because if you're going to maintain it, you should be using it on Debian. - There's a manpage for gips in the debian directory, why not in the upstream tarball? - Since the package will depend on X, it would be nice to have a hint in the description that there's also a command line tool. And that it produces gnuplot output, anyway. - Upstream issue: The tarball happens to contain a copy of the GPL, but nowhere does it say that this license applies to the other contents. It should, please read the "How to apply" section in COPYING. It also is practice to include the paragraphs cited here in debian/copyright, not only "It's GPL, text is at...". I don't know whether this is mandatory, though. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: gips - an isotopic pattern calculator
Krugaan <[EMAIL PROTECTED]> wrote: >>>- please tidy up the debian/rules file :( > I'm sorry, but I have no clue what you want you want me to do. Remove the unused, commented lines that dh_make wrote. >> - you are also the upstream developer of this package. Do you use >> Debian, or would you just like to see it included in one more >> distribution? I'm asking because if you're going to maintain it, you >> should be using it on Debian. > > The program is developed and used with debian. Good :-) >> - Since the package will depend on X, it would be nice to have a hint in >> the description that there's also a command line tool. And that it >> produces gnuplot output, anyway. > > The command line tool is not part of this package and is therefore not > mentioned. It's not included in order to start things simple. On a > longer time scale it is planned to split the program into a library, a > command line tool and a GUI as supposed previously: > http://lists.debian.org/debian-science/2005/08/msg00125.html Oh, I thought that the GUI was just a frontend to the commandline tool, sorry. I'd be more interested in the commandline tool... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: pbuilder -- chroot and build-dependencies.
"Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote: > Hello. > > I have to build a lot of packages for personal use by myself and I > expirienced a very strange problem with pbuilder: > > Some packages requires some unusual things to build, for example, dpatch > or ocaml. Those tools are included in build-dep in control file, but > actually pbuilder does some stuff _before_ chrooting, so building fails > before installing those dependencies into chroot. I think this is a bug - either in the package, or (more likely) in pbuilder. Or your pbuilder setup is incorrect, but then it would probably happen with every package. What problems exactly do you have with which packages? > How can this problem be solved? AFAIR, pbuilder is official build tool No, the official build tool is sbuilder (and not exactly the version that is released somewhere, IIRC). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: pbuilder -- chroot and build-dependencies.
"Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote: > В Чтв, 01/09/2005 в 16:50 +0200, Frank Küster пишет: >> "Alexander A. Vlasov" <[EMAIL PROTECTED]> wrote: >> >> > Hello. >> > >> > I have to build a lot of packages for personal use by myself and I >> > expirienced a very strange problem with pbuilder: >> > >> > Some packages requires some unusual things to build, for example, dpatch >> > or ocaml. Those tools are included in build-dep in control file, but >> > actually pbuilder does some stuff _before_ chrooting, so building fails >> > before installing those dependencies into chroot. >> >> I think this is a bug - either in the package, or (more likely) in >> pbuilder. Or your pbuilder setup is incorrect, but then it would >> probably happen with every package. >> >> What problems exactly do you have with which packages? > > Ok, quick example: > building mldonkey-2.5.28 > > > /usr/bin/make -f Makefile.options clean [...] > As you can see, make clean requires ocaml. But pbuilder invokes `make > clean' before doing chroot (even before unpacking chroot) The question is how you call pbuilder. I always call it on dsc files, and then it just unpacks the chroot and builds the package. You probably use debuild - well, then you're on your own. If you unpack a source package on your system and want to execute targets from debian, you should have the build-deps installed (Build-Dep-Indep actually for clean). Why don't you just use the dsc file? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Change version number only for a different build.
Bas Wijnen <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, Sep 05, 2005 at 03:06:11PM +0200, Antonio Ospite wrote: >> Since my packages are "unofficial" I want them to be built for sarge and >> sid (i use pbuilder for that), but in the same upstream version; is that >> allowed by the policy. What i have to do? > > Policy is only about the official Debian archive, not about things you build > for yourself. But it is usually a good idea to follow Debian policy if you create packages for your site. For example here, with respect to version numbers, it will make sure that updated packages from the Debian archive are treated as newer as your versions. Furthermore, if you use a consistent version numbering, it's easy to stick to that scheme when you continously prepare custom-built packages from the current source packages in unstable or testing. >> I tought i can use a different package version for binary packages >> targeted to different distribution, does something like package_x.x-1 >> for sid and package_x.x-1sarge for sarge sound reasonable to you? > > It doesn't sound good to me. If you have the same source package, and the > only difference is that it must be compiled with the libs from stable instead > of the ones from unstable, I don't think it should be a different version. > However, maybe someone else has something sensible to say about it. Of course > the pool doesn't allow two binary packages of the same name, because they must > be in the same directory. There are more reasons for a different version number: It makes clear that some change has happened (compared to the binary package from unstable/testing), and possibly which. And it makes it easy to migrate back to the Debian version if you want. For example, if you provide backports, you should make sure that the version number is lower than the version number of the next Debian revision. This ensures that if the user decides to switch to testing/unstable, they'll get the newer version. Whether the version number should actually be *lower* than the version in Debian is a different question. For custom-built packages I would clearly say no - if it is higher, you can keep the Debian lines in your sources list, and will still keep the local packages. For backports, it should usually be lower to make upgrading easy. Regards, Frank >> And how do i have to report the different builds in the changelog? >> Is it an acceptable practise to add a changelog entry only for a build >> on a different distribution? > > In the official archive, this doesn't happen. But binary-only-NMUs do happen, and that is a very similar situation. I've never done one, so I don't know how you change the version - but probably you do it in the changelog. Then why not add a "recompiled for sarge" entry? I've seen that often for woody backports. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
Justin Pryzby <[EMAIL PROTECTED]> wrote: > Could someone else also comment on how applications should deal with > shared libraries which are not intended to be used by other programs? If they aren't used by other programs, there's no need to produce a library. Perhaps it's convienient to create static libraries during compilation and link against these, but shared libraries are of no use. Note that I wrote "if they aren't used by other programs". I didn't write "if they are not intended to be used", this is a different thing. If you have code in your project that fits other people's needs, they are going to use it. If there is no shared library, they'll just copy the code. Don't let that happen. xpdf has let this happen, and it makes up a medium-sized security nightmare: Everytime a security bug pops up in xpdf (and it does frequently), a couple of packages which come with their own particular version of that code have to be - checked whether that version is vulnerable - checked whether in that version the patch for current xpdf is sufficient to fix the issue - recompiled So it doesn't hurt to prepare your software for being a shared libray, and telling people that they should request that instead of copying your code. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote: >> Justin Pryzby <[EMAIL PROTECTED]> wrote: >> >> > Could someone else also comment on how applications should deal with >> > shared libraries which are not intended to be used by other programs? >> >> If they aren't used by other programs, there's no need to produce a >> library. Perhaps it's convienient to create static libraries during >> compilation and link against these, but shared libraries are of no use. > What if there are many binaries (10s of them) in your package, and you > want to use shared libs purely for resource efficiency (disk and > memory)? You're right, that's an other reason for a shared library. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: curious deb installation
"Roland Pontes" <[EMAIL PROTECTED]> wrote: > hi at all > i have a problem with creating my own debian packages. > i like to pack own files (dokus, manpages, own skripts) in a debian package. > building is ok, with dpkg --build ordnername ordnername.deb. > my folder structure > DEBIAN > control > /usr/bin/file But it should look like this: ordnername/DEBIAN ordnername/DEBIAN/control ordnername/usr/bin/file dpkg checks that all files in the DEBIAN directory are ordinary files, not directories. It does this in a rather strange way, by calling rmdir on them and throwing the error when this doesn't fail with "not a directory". BTW, the german translation of the error message sounds even worse than the english original. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Request for "beta testers" for latex-cjk
Danai SAE-HAN <[EMAIL PROTECTED]> wrote: > 1. I have several subpackages, so each has its own directory in >/usr/share/doc/. I wish to centralize all docs, example files the >changelog and the copyright file all in one single directory, id >est /usr/share/doc/latex-cjk/. (Those package from the latex-cjk >source of course, not the extra Japanese and Korean font packages, >since they use a different source each.) > >Do I just have to install them manually (put them in a .install >instead of in a .docs file)? And what about the changelog and >copyright files? They use the same source anyway. I would simply create symlinks /usr/share/doc/otherpackage -> latex-cjk and call dh_installdocs (etc.) only for the "main" package. Just make sure that all of them indeed depend on latex-cjk... > 4. This package uses CJK version 4.5.1, along with extra CVS patches >up to 2003-03-18 (I accidentally put 0.20030319 in the >versioning). The current upstream version has been upped to 4.6.0, >but since a lot of changes have happened, especially concerning the >creation of TeX fonts and vertical writing, and because of the >dependency on fontinst 1.918 (only available in teTeX3), I will >need some more time to get 4.6.0 working. You probably know that teTeX 3 is in experimental? I hope to bring it into unstable soon. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Request for "beta testers" for latex-cjk
Norbert Preining <[EMAIL PROTECTED]> wrote: >> the unstable branch? Because if it's within a month or so, then >> there's no need for me to ask my sponsor to upload the teTeX2 >> dependant package now. > > I guess (but I am not Frank) that within a month it should happen, quite > sure. I guess so, too. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Problems with Debconf
Hi, it seems I'm being stupid here, so please help me. A package wants to use debconf to make some changes to the configuration (e.g. change a setting in a configuration file from "false" to "true" or vice versa, or change the permissions of a file). But since it knows that "debconf is not a registry", it must look at the system (parse the configuration file, get the permissions of that file) in its config script, set the debconf template to give the answer that won't change anything, and then ask the questions. As far as I understood it, this is the only way to ensure that a local configuration change will not be overwritten on a system with DEBIAN_FRONTEND=noninteractive. So far so good. But what happens if the local admin uses an interactive frontend, and wants to change something - e.g. by calling dpkg-reconfigure? This is what is going on, at least if apt-utils are installed: 1. config script is run, finds setting "false" in config file, "db_set question false". Then it asks the question, and the admin answers "true", so now the debconf database has "true". 2. The postinst script is run and loads debconf. debconf first executes the config script, then rexecutes the postinst script, so we have: 2.a config script is run, finds setting "false" in config file, "db_set question false". This time, the question is not asked again, so now the debconf database has "false". 2.b the postinst script queries the debconf database and finds that it doesn't need to change the setting. Either there is an error in the description above, or I'm missing a fundamental idea of making the config script idempotent without reasking questions. Can you help me out? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: essential vs. required vs. base
Russ Allbery <[EMAIL PROTECTED]> wrote: > Justin Pryzby <[EMAIL PROTECTED]> writes: > >> I'm including the context diff between essential packages and required >> ones. Since essential implies required, why isn't there simply another >> priority class, instead of a separate "Essential" field?? > [...] > mawk isn't essential because awk has alternatives and mawk is just the > default choice. Someone may want to install gawk and remove mawk, which > should continue to work. sysv-rc and initscripts similarly, as I recall, > have possible alternatives or at least might. You don't need an init system in a chroot, > dselect probably shouldn't be required any more. > > debconf implements a protocol, and another implementation of the same > protocol should be allowed. cdebconf is in progress, in fact. and you also don't need debconf in a chroot (unless you install a package that uses it, of course). > That leaves the following as the only differences that I don't know the > story behind off-hand: > >> +gcc-4.0-base >> +lsb-base >> +makedev >> +passwd >> +procps The last three aren't needed in a chroot (although I usually add users in static chroots, and thus want passwd). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: A question about debconf
Feifei Jia <[EMAIL PROTECTED]> wrote: > Hi there, > > I wanted to delete the date which stored in debconf database when > purge a package. So I added "db_purge" both in prerm and postrm > scripts, but it seemed not work. > > Did I miss something? Any hints appreciated. Did you load confmodule? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: repack upstream sources or overrides ?
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Tue, Nov 15, 2005 at 02:08:59AM +, Sune Vuorela wrote: >> Hi! >> >> I am working on #338554 - and I am almost there. I have one big problem, >> though. >> >> Upstream did not run make distclean before releasing the tarball. Of >> course, linda and lintian complains about this. >> >> Should I add overrides for lintian warnings and linda _errors_ to >> address this problems - or is the right thing to unpack sources; >> make distclean; pack sources and call that .orig.tar.gz ? Obviously you didn't read file:///usr/share/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz otherwise you wouldn't have forgotten "rename the directory to packagename>-.orig". > What errors? I think the 3 typically justified cases for needing a > nonpristine tarball are: > > - non dfsg clean > - requires multiple source tarballs, or sourcetarball not tar.gz > format > - source tarball includes generated binaries > (is this your situation?) I don't think that generated binaries in the tarball justify repackaging - I think it is always possible to remove them in the clean target, which will always be called when dpkg-buildpackage is used. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: repack upstream sources or overrides ?
Sune Vuorela <[EMAIL PROTECTED]> wrote: > It is easy to remove it, yes. > The package is just not linda/lintian clean. > > Making lintian overrides is quite easy, but I can't make linda override > work. Any advice ? Its an upstream bug, and it should be fixed upstream. Since they already promised to fix it at the next release, I would only ensure that the files are really deleted before dpkg-buildpackage does anything; maybe even in the configure target, so that also people running "fakeroot debian/rules binary" directly won't get bitten. Other than that, I would do nothing - it is a bug, therefore a lintian override is inappropriate, but it is not serious enough to justify messing with the tarball. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: repack upstream sources or overrides ?
Sune Vuorela <[EMAIL PROTECTED]> wrote: > On 2005-11-15, Frank Küster <[EMAIL PROTECTED]> wrote: >> "fakeroot debian/rules binary" directly won't get bitten. Other than >> that, I would do nothing - it is a bug, therefore a lintian override is >> inappropriate, but it is not serious enough to justify messing with the >> tarball. > > So you suggest that I do not repack source and do not add overrides ? > > http://ftp-master.debian.org/REJECT-FAQ.html > about lintian in the serious violations-part > "Sometimes there are valid reasons, but then you should either file a > bug against lintian if it's generally wrong or include an override in > your package, giving a reason in the changelog for it" I wasn't aware that it is a new package. Anyway, I assume the rationale for the lintian error is that this *might* screw up builds badly. But on the other hand, there are ways to prevent that, and I don't think that if a maintainer chooses to do so, he should instead be forced to repackage the source. I don't know how communication with the ftp-masters works these days; ideally they would read through files in the debian dir (what about README.ftp-masters :-)...) and find your note about the reasoning. I would not just add a lintian overrides without having the package double-checked by a person who really understands the issues and verifies that the files will really be out of effect. Just my 2c, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: repack upstream sources or overrides ?
Bas Wijnen <[EMAIL PROTECTED]> wrote: > On Tue, Nov 15, 2005 at 12:59:49PM +0100, Frank K?ster wrote: >> >> I don't know how communication with the ftp-masters works these days; >> ideally they would read through files in the debian dir (what about >> README.ftp-masters :-)...) and find your note about the reasoning. I >> would not just add a lintian overrides without having the package >> double-checked by a person who really understands the issues and >> verifies that the files will really be out of effect. > > I am confused about the purpose of lintian overrides. Can someone explain it > to me, please? > > I thought an override would be in order when lintian complains, but there > isn't really a bug. In other words, in case of a false positive. A lintian > bug report may be in order as well, as the reject-faq says. I agree with that. > In this case, the warning is not wrong at all. It is a bug, and it needs to > be fixed. ACK. > In this case, it can only be fixed upstream (I'm assuming here that > this is not enough reason to repackage the tarball). Upstream has also agreed > to fix it in the next release. > > So I thought that a lintian warning/error should be seen as a bug in the > package. An override would be a WONTFIX tag on it, effectively closing the > bug. In this case, I'd rather say that it's a "severity normal" tag, as opposed to the RC (Reject Critical ;-)) severity the lintian error normally has. The better choice is to communicate with ftp-master; but if it has to be assumed they won't even look at the package if there's this lintian error, an override might be justified. But you are right - if it was my package, I'd just upload it with the bug and the lintian error, and an explanation in the changelog and README.Debian file. If it's rejected due to the lintian error, and there's no reaction on subsequent complaints, you can still reupload it with a lintian override, and still get the package into unstable faster than it was usual a year ago... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: No official upstream sources archive, only tagged SVN directory
"W. Borgert" <[EMAIL PROTECTED]> wrote: > Quoting Ivan Dubrov <[EMAIL PROTECTED]>: >> Other solution is to remove unnecessary files from directory before >> packaging it as "upstream source package". The disadvantage is that >> upstream source generated this way is not very "natural", such >> archives do not correspond one-to-one to the Subversion repository >> content. > > I see no problem in that solution. Yes, it's not as > nice as a one-to-one picture, but let's stay pragmatic. You (Ivan) could also look for a "make dist" target - if it exists, you can simply create a tar.gz file from an SVN export. If it doesn't exist yet, you can earn yourself some honor and contribute it... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: including images for documentation
Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote: > This documentation is not part of upstream and includes some images. > Source for this documentation+images is also part of what I have > added to the upstream source. > > Is there some way to include the images in the debian package? uuencode/uudecode Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: upstream changed the source tarball name...
Matthew Palmer <[EMAIL PROTECTED]> wrote: >>-- But, how do I properly inform the ftp masters that the old >> 'acovea' source has been replaced by the new 'libacovea' source, >> even though both produce a binary package called 'acovea' (and >> should do so)? ITP the new stuff and file the bug to remove the >> old? > > Upload. They're clever people, they'll sort it out. If in doubt, make the > changelog nice and verbose. They'll probably not even see it: If a new source package produces a binary package that already exists, the new source package does not go through NEW. At least it has been that way this summer. I have been told there are plans to change that, but I assume that it has not yet been done. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: ppower4, java, and texive packages
Michael Koch <[EMAIL PROTECTED]> wrote: > On Fri, Dec 02, 2005 at 11:36:38AM +0100, Norbert Preining wrote: >> Hi all! >> >> I have a question concerning packaging stuff for texlive: we want to >> include the ppower4 bundle, which consists of TeX input files, and of >> some jar archive/java program for postprocessing of the pdf file. >> >> Now the question is: How do I package this: Can I include all the stuff >> and only Recommend: a java run time system? And if non is installed, >> give a warning message? Or should I leave out the postprocessor and only >> include the sty files (which would of course make it more or less >> useless)? > > Why not Depends on java1-runtime | java2-runtime | kaffe ? Because ppower4 would be part of texlive-pdfetex, and provide only one small aspect of its functionality. Clearly a Depends is too restrictive. If i would use texlive (as teTeX maintainer, I'll obviously stick to teTeX), I would for sure install texlive-pdfetex, but not use ppower4 at all (I use beamer instead which doesn't require any program for post-processing). Therefore, from my POV it should be Suggests. A wrapper script that gives a nice warning would be great; but be careful to actually deliver the warning to the user if the ppower4 postprocessor has a menu entry. > For kaffe you can depend on another free runtime like sablevm or > java-gcj-compat too. Does ppower4 run with any of the free runtimes? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: sysinfo -- simple GNU/Linux program that displays computer/system information
Mario Iseli <[EMAIL PROTECTED]> wrote: > On Wed, 2005-12-07 at 14:13 +0100, Adriaan Peeters wrote: >> Hello, >> >> I am looking for a sponsor for sysinfo [1], detailed info below. I >> already have two packages in Debian: dnstop and sipcalc. > > Hi, i'm not yet a DD. Because i'm sick i have time to review your > package and i found some mistakes. > > in your diff: > --- sysinfo-0.6.1.orig/src/Makefile.in > +++ sysinfo-0.6.1/src/Makefile.in > > This is wrong!! No. > you may not change anything at the orig! If you have to > apply some changes you should use dpatch and apply the patches by > debian/rules. While it is common practice to use dpatch or other patch systems, it is by no means required. Just look at the policy, it doesn't even talk about this. > debian/changelog: > * Initial Debian Release (Closes: 333680) > This makes no sense, it is a debian package so the "debian" can be > ommited, the rest is ok. If Adriaan previously published deb packages in his local repository, it might well make sense to speak of an initial Debian release. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: sysinfo -- simple GNU/Linux program that displays computer/system information
Carlo Segre <[EMAIL PROTECTED]> wrote: > On Wed, 7 Dec 2005, Frank Küster wrote: > >> Mario Iseli <[EMAIL PROTECTED]> wrote: >> >>> debian/changelog: >>> * Initial Debian Release (Closes: 333680) >>> This makes no sense, it is a debian package so the "debian" can be >>> ommited, the rest is ok. >> >> If Adriaan previously published deb packages in his local repository, it >> might well make sense to speak of an initial Debian release. >> > > This raises a question. If I have been packaging some software for > some time and finally decide to get it into Debian, should I wipe out > the entire changelog, remove any epochs that might have been used, etc? IMO, if you think that you had many users of your private repository that will continue to use it in Debian, I would prefer to keep a consistent versioning scheme. On the other hand, if you only used it locally, or otherwise have a means to contact all users, it's of course nicer to start without an epoch and with a -1 Debian revision. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFS: tex4ht
Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > On Fri, Dec 09, 2005 at 10:52:30PM +0100, Filippo Rusconi wrote: >>On Fri, Dec 09, 2005 at 08:48:14AM +0530, Kapil Hari Paranjape wrote: >>>Dear Sponsors, >>> >>>I am the non-DD maintainer of tex4ht and have been looking for >>>a sponsor for the package at > > Why don't you ask your previous sponsor? He did, the previous sponsor (me) said that he won't have time this year or longer. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: pbuilder and scons
Paul Wise <[EMAIL PROTECTED]> wrote: > Claudio Moratti wrote: > >> I'm working on a package that uses scons... >> >> everything goes fine but I find one problem: in order to clean the sources, >> debian/rules calls >> /usr/bin/scons -c >> but pbuilder don't try to install the Unmet build dependencies before the >> "clean"... > > As other people noted new and in old threads, this is because pbuilder > runs debian/rules clean outside the chroot. I don't understand what the problem is here, really. First of all, as Ming has pointed out, it's probably not pbuilder that runs clean, but pdebuild or whatever tool. Second, if you have the *need* to run debian/rules clean, this means you tried to configure the package on your working host, or something like that, and this means you should install the build-deps anyway. Alternatively, if you just unpacked the sources, edited some files in debian, and now want to create a binary package, why not simply cd ..; dpkg-source -b pbuilder build Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Rationale behind script-not-executable lintian warning
Hi, I'm sure this has been discussed before, but it's really hard to find relevant hits when googling after lintian warnings... It's of course clear that any script in the path should be executable. But if a script is in /usr/share/somewhere, and meant to be used as a "library", it could be that upstream wants to allow both to source and to execute it. So to make lintian happy, I would have to make it executable although I know it will never be executed by Debian programs. Or I would have to patch the file to remove the shebang line. Therefore I'd rather keep things as they are, but there must be a reason for the lintian warning. In the Policy section on permissions I couldn't find anything specific. TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Rationale behind script-not-executable lintian warning
Bas Wijnen <[EMAIL PROTECTED]> wrote: > On Wed, Dec 21, 2005 at 05:45:43PM +0100, Frank K?ster wrote: >> It's of course clear that any script in the path should be executable. >> But if a script is in /usr/share/somewhere, and meant to be used as a >> "library", it could be that upstream wants to allow both to source and >> to execute it. >> >> So to make lintian happy, I would have to make it executable although I >> know it will never be executed by Debian programs. Or I would have to >> patch the file to remove the shebang line. > > If it is meant to be executed, it should be executable. If it is not, it > should not have the shebang line. I don't see the problem. The problem is that it isn't meant to be executed on a Debian system, but by upstream. > Indeed, if upstream wants to allow both to source and to execute it, then it > is meant to be executed and thus should be executable IMO, even if the script > is never executed from the Debian package (but only sourced). If I make it executable, I would get the "executable-not-in-path" lintian warning (or however it is called exactly). >> Therefore I'd rather keep things as they are, but there must be a reason >> for the lintian warning. In the Policy section on permissions I >> couldn't find anything specific. > > I haven't seen anything in policy either, but I can't see any use for having a > shebang line without execute permissions. Can you give an example? The rationale is not to have hunks for removing the shebang line cluttering the Debian-specific patches, just for the sake of making lintian silent. If there's a reason for the warning, I can judge whether it applies in my case, and fix it or add a lintian override. But if I don't know any rationale (except "why not?"), I can't. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Rationale behind script-not-executable lintian warning
Hi lintian maintainers, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > On Thu, 2005-12-22 at 12:25 +0100, Bas Wijnen wrote: >> Then it seems logical to me that an override would be in order. However, I >> don't understand what the check is for, if not for cases like these. So my >> logic may very well be incorrect. > > Many tests document a short rationale in their description; it would be > good to add this for tests where it doesn't exist. For example by > sending patches to the BTS. Good idea, but first we should know the rationale. The warning we are talking about is W: tetex-base: script-not-executable ./usr/share/texmf-tetex/scripts/context/ruby/texmfstart.rb N: N: This file starts with the #! sequence that marks interpreted scripts, N: but it is not executable. N: In this particular case, upstream decided that the script should contain a shebang line (and a couple of possible reasons for this have been given on -mentors), and I'm wondering why lintian doesn't like it like this. The script is not meant to be executed on a Debian system, just called internally, so there's no need for the shebang line; but I also don't see the need for removing it, thus cluttering the diff.gz with useless hunks. Or not so useless as I'd like to learn from you. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Rationale behind script-not-executable lintian warning
Ben Finney <[EMAIL PROTECTED]> wrote: > On 22-Dec-2005, cobaco (aka Bart Cornelis) wrote: >> On Wednesday 21 December 2005 18:41, Bas Wijnen wrote: >> > If it is meant to be executed, it should be executable. >> > If it is not, it should not have the shebang line. >> >> I disagree, there's nothing wrong with clearly documenting what >> shell variant a script is written in, on the contrary IMHO > > A shebang line is more than documentation: it is a strong indication > that the script will be executable from the command line. To have that > expectation not be matched by the file's permission mode is a recipe > for confusion. The fact that the script is not in the path isn't enough for you here? And don't you think that anyone who knows that a shebang lines indicates executability from the command line would easily solve the problem of a "permission denied"? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Rationale behind script-not-executable lintian warning
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote: > On Friday 23 December 2005 10:24, Frank Küster wrote: > >> The fact that the script is not in the path isn't enough for you here? >> And don't you think that anyone who knows that a shebang lines indicates >> executability from the command line > > shebang line does _not_ indicate executability, it's the magic number that > indicates it's a script instead of machine code (see e.g > http://foldoc.org/?shebang) > > if it's meant to be executable it should have the executable bit set, this > is unrelated from the shebang line (if not what do you do with a script > that's executable for the owner but not for anyone else? automatically > remove the shebang depending on who opens it?) You are right, but this makes me doubt even more whether having a non-executable file with a shebang line is a bug, because this information is also interesting for human beings. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Rationale behind script-not-executable lintian warning
Ben Finney <[EMAIL PROTECTED]> wrote: > On 23-Dec-2005, Frank Küster wrote: >> Ben Finney <[EMAIL PROTECTED]> wrote: >> > A shebang line is more than documentation: it is a strong >> > indication that the script will be executable from the command >> > line. To have that expectation not be matched by the file's >> > permission mode is a recipe for confusion. >> >> The fact that the script is not in the path isn't enough for you >> here? > > There are many executables, that I can invoke from the command line by > typing their explicit location, that are not in the default executable > path on a Debian system. That's correct. >> And don't you think that anyone who knows that a shebang lines >> indicates executability from the command line would easily solve the >> problem of a "permission denied"? > > The confusion I refer to is not "how do I fix this?" but rather "why > is there a mismatch, and what is the intended behaviour?" That there > is a mismatch at all is the confusion. Okay, so the rationale for the lintian warning would be: "If a script starts with `#!/path/to/interpreter', this indicates that it is intended to be directly executed, therefore it should have have the executable bits set." However, for me, this sounds like a reason not to make the script executable in *my*case*. Most of the scripts in question in the tetex-base package are from ConTeXt, a software also distributed on its own, but for Debian integrated into teTeX by the teTeX upstream maintainer. It might well be that teTeX's upstream has deliberately decided not to make these scripts executable - for example because he wants his software to work with "./configure; make; make install", whereas calling the scripts directly would require to set some environment variables (which on teTeX are passed to the scripts by the programs that indirectly call them). An other possible rationale for upstream's decision is that the scripts are originally meant to be in the path by the ConTeXt authors, but for the integration into teTeX it was necessary to create a wrapper script (in fact such a script does exist). In this case the scripts are no longer meant to be executable in teTeX. I think Debian should stick to (teTeX's) upstream's decision, which will simply work. On the other hand, I see no reason to remove the shebang lines (of a couple of scripts). Does this sound sensible, would it warrant a lintian override? Or what do you think I should do? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Policy documentation on debconf
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Dec 2005 14:27:04 +0100, Lionel Elie Mamane <[EMAIL PROTECTED]>
> said:
>
>> On Sun, Dec 25, 2005 at 09:23:23PM -0600, Manoj Srivastava wrote:
>>> On Sun, 25 Dec 2005 19:59:07 -0200, Rogério Brito
>>> <[EMAIL PROTECTED]> said:
>>>> On Dec 25 2005, Lionel Elie Mamane wrote:
>
>>>>> Ah yeah, this seems to contain the information. Thanks a lot. Is
>>>>> there a good reason it is not in the policy?
>
>>> Policy is not the place to put documentation that belongs to
>>> packages?
>
>> How can specifying when and with what arguments a maintainer script
>> gets run belong to a package? If it does, why isn't
>> {pre,post}{rm,inst} documentation in dpkg's documentation rather
>> than in the policy?
>
[...]
> The idea is for policy not to be an obstacle in development of
> the debconf/packaging system, while specifying enough of an interface
> that developers can rely on some things being constant from upload to
> upload.
And I thought I could rely upon dpkg from the next upload to call the
configure script with the same arguments as it did before, just as I can
rely on the same for preinst, postinst etc.
We're not talking about the debconf interface at all here, AFAIS. We're
talking about the interface that dpkg provides to packages for there
debconf questions, i.e. the way the configure script is called, and
when.
Do you think it would be an obstacle for development if that were
documented in the Policy, just as the same is documented for the
"classical" maintainer scripts? Why isn't it an obstacle for those
other scripts?
Do you imply we should not rely on the time point when dpkg calls the
configure script, or on the arguments it passes to it? Why?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Re: Policy documentation on debconf
Manoj Srivastava <[EMAIL PROTECTED]> wrote: > On Tue, 27 Dec 2005 17:41:00 +0100, Frank Küster <[EMAIL PROTECTED]> said: > >> And I thought I could rely upon dpkg from the next upload to call >> the configure script with the same arguments as it did before, just >> as I can rely on the same for preinst, postinst etc. > > Not more than what policy already guarantees. All you really > need to do in config scripts is follow the protocol defined; how you > do it is up to you. The information which arguments are passed to the configure script is missing AFAICT. I've got the impression that this is quite stable, too. >> We're not talking about the debconf interface at all here, AFAIS. >> We're talking about the interface that dpkg provides to packages for >> there debconf questions, i.e. the way the configure script is >> called, and when. > > And you think this is not adequately covered in policy? > , > | Packages which use the Debian Configuration management specification > | may contain an additional `config' script and a `templates' file in > | their control archive[2]. The `config' script might be run before the > | `preinst' script, and before the package is unpacked or any of its > | dependencies or pre-dependencies are satisfied. Therefore it must > | work using only the tools present in _essential_ packages.[3] > ` Additionally to the missing arguments, I think there should be some references to the config script in chapter 6, "Package maintainer scripts and installation procedure". >> Do you imply we should not rely on the time point when dpkg calls >> the configure script, or on the arguments it passes to it? Why? > > I think you really need to go read policy again. You got me here - in fact I missed or forgot that it was mentioned in 3.9.1, because 6 is the usual place where my questions related to maintainer scripts are answered. Reading again, it seems to me that 3.9.1, together with the first 3 paragraphs of 3.9, could well be moved to 6, maybe close to 6.3. After that, the rest of 3.9 could be renamed to something like "peaceful coexistence of packages"... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Proposal for collaborative maintenance of packages
skaller <[EMAIL PROTECTED]> wrote: > Right now, however, when I release an upstream tarball, > there is a whole bunch of work for the maintainer/DD to > do .. the set of files in the package may have changed, > the dependencies may have changed, the documentation > set may have changed. This is true for any package > of course .. but this is 150KLOC of source which is > not built in 'conventional' ways -- it uses a literate > programming tool and Python scripts, and the bulk > of the code is in an advanced programming language > (including some in itself :) If your upstream software has a good installation procedure - something like the autotools type with the possibility to change directory locations at configure time (--with-confdir=/etc/foo and such), adding or removing files or documentation needs hardly any work of the package maintainer. Changed dependencies need just one line in control to be edited. So maybe you can use the interaction with Debian to improve your program? > Would you not trust my DD to check *my* skills at maintaining > a few lines of Debian packaging script which wraps > the package of which I'm the upstream author? Well, yes. But how's that different to the current procedure - you create a package, commit yourself to caring for it, and find a sponsor? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFC: denyhosts
Nico Golde <[EMAIL PROTECTED]> wrote: > Yes and I think its alot better than adding a bunch of ips > to /etc/hosts.deny. > And iptables is only a dependency like any other... I have no understanding of what a packetfilter firewall actually does, and therefore I won't install one. On the other hand, it's easy (for me) to understand how hosts.deny works. Furthermore, AFAIK iptables isn't a dependency, but rather a configuration option when compiling the kernel - then it is *not* a dependency like any other. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFC: denyhosts
Nico Golde <[EMAIL PROTECTED]> wrote: > Hi, > * Frank Küster <[EMAIL PROTECTED]> [2006-01-16 22:50]: >> >> I have no understanding of what a packetfilter firewall actually does, >> and therefore I won't install one. On the other hand, it's easy (for >> me) to understand how hosts.deny works. >> >> Furthermore, AFAIK iptables isn't a dependency, but rather a >> configuration option when compiling the kernel - then it is *not* a >> dependency like any other. > > Oh thats right. Thanks for pointing this out! Then maybe > hosts.deny is a good idea. Please make sure to add this fact > to the discription of the package. Important fact. You mean that I am completely ignorant wrt packet filtering? ;-) Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: fixing a bug via NMU
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Tue, Jan 17, 2006 at 01:03:32PM +0100, Bjoern Boschman wrote: > >> I'd like to close on of the xlibs-dev bugs, but I've never done an NMU >> before. > > This is because "NMU" stands for "non-maintainer upload", and you don't > appear to be a DD, therefore it's not possible for you to upload -- > non-maintainer or otherwise. A DD will have to upload the fix in question. But see especially http://lists.debian.org/debian-mentors/2006/01/msg00168.html Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: fixing a bug via NMU
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Tue, Jan 17, 2006 at 01:55:27PM +0100, Frank Küster wrote: >> Steve Langasek <[EMAIL PROTECTED]> wrote: > >> > On Tue, Jan 17, 2006 at 01:03:32PM +0100, Bjoern Boschman wrote: > >> >> I'd like to close on of the xlibs-dev bugs, but I've never done an NMU >> >> before. > >> > This is because "NMU" stands for "non-maintainer upload", and you don't >> > appear to be a DD, therefore it's not possible for you to upload -- >> > non-maintainer or otherwise. A DD will have to upload the fix in question. > >> But see especially >> http://lists.debian.org/debian-mentors/2006/01/msg00168.html > > Which is unnecessarily confusing use of the terminology. Granted, but still the offer might help Bjoern to contribute to Debian. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: How to close Bugs in experimental
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > No, as close commands ARE clearly deprecated as well, and not at all > equivalent to adding a tag. We are taliking about uploads to experimental, > after all. > > AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already is, I > think), and notfound commands to [EMAIL PROTECTED] should be used instead of > fixed-in-experimental tags. Why not use bug#-done with an appropriate Version pseudoheader, also for uploads to experimental? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: create password in postinst
Daniel Knabl <[EMAIL PROTECTED]> wrote: >> file:///usr/share/doc/debian-policy/ >> policy.html/ch-maintainerscripts.html#s-mscriptsinstact > > Hm, I do understand that this is a very important and critical part of > the policy. But, due to my non-perfect English, it's hard to get the > meaning of some terms into my head. At least for me. If there was just > a German version of this file ... but let's have a guess/try: > > postinst: > 1) It gets processed on initial/normal installation, which is ok. > > 2) I do not know what to do about "upgrade" right now? abort-upgrade, abort-remove, abort-deconfigure > Are there German native speakers around, that could help me to > understand this relationships among the control-files? If so, it would > be really a huge help for me. Ne, Entschuldigung. Aber wer Debian-Pakete machen will, der muss genug Englisch verstehen, um auf Bugreports reagieren zu können. Dann sollte auch die Policy kein Problem sein. Gruß, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: ITP vexim
Daniel Knabl <[EMAIL PROTECTED]> wrote: > The main target in postinst, when someone initially installs the > software, is "configure", No, not only upon initially installing it. On every upgrade. > and in postrm, when someone purges it, it is > "purge". No, if the package is purged, postrm is called twice, with different arguments. And it's also called when the package is upgraded or removed. > Now it seems, that I should also perform actions on some targets that As I understood Marc, you did some actions unconditionally, no matter what the first argument is (that seems to be fixed now), and some in configure unconditionally on the second argument that should not be performed upon upgrade. This you still do. Err, and you keep configuration files in /usr/share. > do not get used in real installation process: who should upgrade the > package, when there has never been a version of it before? The package could be in state rc. > Who should downgrade the package (to a non-existent version before)? I > did some tests (installing, removing,purging ...) and there was no > unexpected behavior. > > So now I don't understand, really NOT understand, what you are > complaining about? Is it because I want to release a piece of software > that you don't like? It's a software whose quality I cannot judge, but the quality of the packaging is not fit for Debian. > Is it because of me as person? > If there's any other place where I could ask, not just "if there has > something to be done", but "what in special case has to be done", then > please pint me over there. No problem for me to getting told that this > is the wrong list too, but anyone should even tell me then ... It's the right list for asking questions after you've tried to understand the Debian policy, and consulted the Developer's reference where Policy is unclear to you. But it seems you haven't read the policy, or > I followed your suggestions not to ask on debian-devel, and i have read > the policy more often now, especially the chapters 6.5 to 6.7 about > control files and their behavior, but there are still questions that > affect the actual state of the package. you didn't understand it. Sections 6.5 to 6.7 deal with the installation procedure and maintainer scripts. Control files only exist in the source package. And what you wrote above about postinst and postrm can also easily be shown to be false (or at least incomplete) by looking at these sections. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: proxycheck -- link
Christoph Haas <[EMAIL PROTECTED]> wrote: >> > - Consider using "dpatch" for changing the upstream sources. >> > You may find it easier to keep or remove patches when the next >> > upstream version is released. >> >> It's good to know the option, but for minor changes that are likely to >> either be kept or accepted upstream, I've found it easier to use the >> original patch. I don't think you (Christoph) wanted to require it - >> otherwise you wouldn't have uploaded the package - but for the casual >> reader, it could be even clearer that this is a matter of preference and >> consideration on a case by case basis. > > In case I accidentally sounded like I wanted to enforce anything: that was > just a hint for Al since many (new) maintainers don't know dpatch and > happily patch around the upstream's source and sometimes start to get lost > in it. In such a (rather simple) package it doesn't make much of a > difference. There are also other alternatives to dpatch; one is Debian-specific and i keep forgetting its name, and there's quilt. The main advantage of quilt IMHO is that it doesn't duplicate the whole tree when editing and updating the patch, which can be time- and disk-consuming in large projects. Instead it keeps a list of files for the patch one is editing and only keeps copies of these. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: dpatch vs. quilt
[EMAIL PROTECTED] wrote: > On Sun, Jan 29, 2006 at 11:39:17AM -0500, Kevin B. McCarty wrote: >> Frank K?ster wrote: >> >> > There are also other alternatives to dpatch; one is Debian-specific and >> > i keep forgetting its name, > Are you thinking of dbs? Without looking at its description, I think yes. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: dpatch vs. quilt
"Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > Frank Küster wrote: > >> The main advantage of >> quilt IMHO is that it doesn't duplicate the whole tree when editing and >> updating the patch, which can be time- and disk-consuming in large >> projects. Instead it keeps a list of files for the patch one is editing >> and only keeps copies of these. > > Out of curiosity, does quilt have a mechanism similar to dpatch that > allows you to treat shell scripts as "patches"? My inability to find > such a feature was the main reason I opted for dpatch over quilt in the > Cernlib package -- I needed to move a bunch of files around within the > source, and doing so with a pure patch system will result in huge and > fragile diff files (two copies of each file to be moved, which breaks if > upstream changes any of them!). But now it sounds like I'm missing out > on some features by not using quilt. I don't think that quilt offers this, at least not in a straightforward way. Why can't you separate the moving around of files from the patching? patch-stamp: quilt push -a debian/movefilearound But looking at its implementation, maybe this could easily be changed, just add an additional check whether the "patch" has a shebang line at the start, and execute it instead of calling patch. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: dblatex - Produces DVI, PostScript, PDF documents from DocBook sources
Andreas Hoenen <[EMAIL PROTECTED]> wrote:
> - /etc/dblatex/{specs|contrib}/
> - ~/.dblatex/{specs|contrib}/
>
> dblatex would have to scan these directories in addition to the original
> ones where its own specifications/styles stay located.
The first pair could just be symlinked from the established place, and
then adding support to parse an additional per-user directory is just a
goody.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: RFS: dblatex - Produces DVI, PostScript, PDF documents from DocBook sources
Andreas Hoenen <[EMAIL PROTECTED]> wrote: > Thus, at the risk of repeating myself: anyone interested in sponsoring > this package? Not me - I only answered because I fixed a RC bug in db2latex-xsl a couple of weeks ago and knew that it's hardly maintained and that dblatex existed. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Bas Wijnen <[EMAIL PROTECTED]> wrote: > The question is, how do I solve this? Should I forcefully remove the conffile > before calling update-rc.d? It feels really bad to remove files from /etc in > maintainer scripts, but perhaps it's the right thing to do... I've come across this several times, and what I did was - check the md5sum of the installed file * against the md5sum known to dpkg (not possible if the package was in "rc" state) * against known md5sums hardcoded into the maintainer script - if the file is unchanged, remove it - if it is changed, either keep it and insert a comment at its beginning that it is unused, or move/rename it. In all cases where the file's presence could have a bad effect, I renamed or moved it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote: >> Bas Wijnen <[EMAIL PROTECTED]> wrote: >> >> > The question is, how do I solve this? Should I forcefully remove >> > the conffile before calling update-rc.d? It feels really bad to >> > remove files from /etc in maintainer scripts, but perhaps it's the >> > right thing to do... > >> - if the file is unchanged, remove it > Even changed files are removed on purge. Yes, of course - I should have been more clear. What I wrote is done in preinst. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Mon, 06 Feb 2006, Frank Küster wrote: >> - if it is changed, either keep it and insert a comment at its >> beginning that it is unused, or move/rename it. In all cases where >> the file's presence could have a bad effect, I renamed or moved >> it. > > Just a word of caution here: If the administrator has modified the > file, you should not rename or move it, as they may know better than > you what they're doing. A proper course of action would be warning > them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. If it's just a "the file is no longer needed", then of course I need not do anything, but a warning, debconf question, or just an entry in NEWS.Debian would be good. There's yet an other case: If the postinst script finds that a conf(iguration) file has a setting that will break later postinst action, and result in an unconfigured package, then it should fail right away and give an explanation (and not try to proceed and fail later with a much less understandable error message). > Additionally, you should check to make sure whether you're upgrading > from a version after this transition; if that's the case, you > shouldn't rename/delete either. Yes, that should always be done. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > Right. The problem is that it's not always easy to know if the file > will no longer be read at all; you can't assume that the administrator > has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now the file is generated from files in /etc/bla/conf.d, sits in /var/lib/bla, and the symlink points there, it's safe to assume that /etc/bla/bla.conf is unused. > [Likewise for > failure modes on the presence of an obsolete configuration file; > unless you know for certain that it will fail, you should give the > administrator some way to override your guess.] In some cases, yes. We have cases in teTeX where there are only two alternatives: Either accept the change, or not install the debianized package at all and go for /usr/local/ instead. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFC: PyKaraoke
Miriam Ruiz <[EMAIL PROTECTED]> wrote: > PyKaraoke is a free karaoke player written in Python. If that's meant to be the start of the long description, please drop the "written in Python", because it's not interesting, and for those who want to know that nevertheless, the information is in the dependency fields. HTH, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> > Right. The problem is that it's not always easy to know if the file
>> > will no longer be read at all; you can't assume that the administrator
>> > has left in place your default configuration system.
>>
>> Of course the maintainer should know their package. If the binary reads
>> a configuration file in /usr/share/bla, and in the old version there was
>
> This would be a problem.
Why? What problem?
>> a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now
>> the file is generated from files in /etc/bla/conf.d, sits in
>> /var/lib/bla, and the symlink points there, it's safe to assume that
>> /etc/bla/bla.conf is unused.
>
> The issue here is that you've suddenly changed the way the system
> works, so perhaps the proper method is to move /etc/blah/bla.conf into
> /etc/bla/conf.d/ instead; at the very least you should move the users
> configuration away into a backup position or something rather than
> deleting it if they have made changes.
I never talked about deleting it. In some cases we indeed managed to
transfer it. There might be others where it isn't possible.
It might also be that the binary simply stops looking for that
particular conffile because the configuration options are obsolete.
>> In some cases, yes. We have cases in teTeX where there are only two
>> alternatives: Either accept the change, or not install the
>> debianized package at all and go for /usr/local/ instead.
>
> That seems like a bug to me; it may not be easy to fix in tetex, but
> it's definetly not the ideal situtation for a package.
Go ahead and submit bugs, and we'll discuss whether there's a better
solution. One example:
TeX input files are found in any path ("TEXMF tree") defined in the
TEXMF variable. We had to move teTeX's files from /usr/share/texmf
(which continues to be a TEXMF tree for other packages) into
/usr/share/texmf-tetex, and consequently we need to add this new tree
into the list in the variable TEXMF.
If the user refuses this change upon upgrade, what other choice do we
have? We check for it in postinst and bail out before trying to do any
configure work which will fail for sure.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Tue, 07 Feb 2006, Frank Küster wrote: >> Don Armstrong <[EMAIL PROTECTED]> wrote: >> > On Tue, 07 Feb 2006, Frank Küster wrote: >> >> Don Armstrong <[EMAIL PROTECTED]> wrote: >> >> >> >> > Right. The problem is that it's not always easy to know if the file >> >> > will no longer be read at all; you can't assume that the administrator >> >> > has left in place your default configuration system. >> >> >> >> Of course the maintainer should know their package. If the binary reads >> >> a configuration file in /usr/share/bla, and in the old version there was >> > >> > This would be a problem. >> >> Why? What problem? > > You've now got a conffile in a location which is not /etc, namely > /var/lib/bla, which cannot be overridden by the administrator. No, I don't. The program reads its configuration from a file in /var/lib/bla, but the conffiles (or configuration files) reside in /etc/bla/bla.d. > Instead, I'd suggest having the symlink in /usr/share/bla pointing to > /etc/bla.cnf which then in the default install is a symlink to > /var/lib/bla or whatever is appropriate; if the user has modified the > configuration file, you don't stick in the symlink. That's a possible approach; however teTeX is different. There's an other method to override the Debian integration. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Wed, 08 Feb 2006, Frank Küster wrote: >> Don Armstrong <[EMAIL PROTECTED]> wrote: >> > You've now got a conffile in a location which is not /etc, namely >> > /var/lib/bla, which cannot be overridden by the administrator. >> >> No, I don't. The program reads its configuration from a file in >> /var/lib/bla, but the conffiles (or configuration files) reside in >> /etc/bla/bla.d. > > The configuration file is the file from which the configuration is > read, that is, the file in /var/lib/blah which isn't in /etc. Why? > This > setup forces the administrator to use a your special conffile setup > which they can't override.[1] [...] > 1: In the sense that they can't decide that using the conf.d is silly > and ship a single configuration file. Okay, I see your point. Generally I agree with you, although in the particular example, teTeX, your're wrong: They still can override the scheme. > In addition, you get compliance with policy, Our setup is also policy-compliant. > and an implementation > which is more obvious to the administrator. And clutters /etc/texmf unnecessarily. And has one more severe drawback: People who forgot (or never noticed) that the file is generated from files in conf.d will open /etc/texmf/bla.conf in their favorite editor, change the generated file without noticing, and will be surprised if the change is lost after the next package upgrade. > A third option would be to build the conffile in /var/lib/blah, and > use ucf or similar to prompt for the difference betwen /var/lib/blah > and /etc/blah. Been there, done something similar. ucf is a nice workaround for a missing feature in dpkg, but it confuses users. I avoid it if I can. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: >> People who forgot (or never noticed) that the file is generated from >> files in conf.d will open /etc/texmf/bla.conf in their favorite >> editor, change the generated file without noticing, and will be >> surprised if the change is lost after the next package upgrade. > > This should be an indication that you're not preserving administrator > changes to configuration files if this occurs... Err, no. If the conffiles are in /etc/bla.d/, the generated file bla.conf is in /var/lib/bla/, and there's a symlink chain from /usr/share/bla/bla.conf to /etc/bla.conf and on to /var/lib/bla/bla.conf, then there are two things I need to preserve: One is the state of /etc/bla.conf (is it a symlink or a real file?) and the other is the conffiles in /etc/bla.d/. Of course there would be a remark at the top of /var/lib/bla/bla.conf as to not edit it, but we all know that users don't necessarily read that. This is why I think the symlink from /etc to /var idea isn't good. Either the program is able to read from conf.d, or there is a generated file that is accessed by the program without an additional indirection via /etc. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: xshisen_1.51-2 --- Shisen-sho game for X11
"Zak B. Elep" <[EMAIL PROTECTED]> wrote: > Unfortunately, I'm hitting a snag at #291279 (strange source package) > which is most likely a misversioned NMU :/ Any hints at fixing this? > :) Why not just do your upload with a proper orig.tar.gz? > At any rate, I've to celebrate; I got my first REJECTED mail from the > archive installer thanks to trying to fix this package :P Why was it rejected? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: xshisen_1.51-2 --- Shisen-sho game for X11
"Zak B. Elep" <[EMAIL PROTECTED]> wrote: >> Why was it rejected? > > Quoting the REJECTED mail: > > | Rejected: xshisen_1.51-1-2.dsc refers to xshisen_1.51-1.orig.tar.gz, > | but I can't find it in the queue or in the pool. > > Hmmm, doesn't the maintainer to upload this to main needs to do a > `debuild -sa` so that everything (.orig.tar.gz, .diff.gz, and .dsc) > gets to be signed off in the .changes file? Yes, that should have helped. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: xshisen_1.51-2 --- Shisen-sho game for X11
"Zak B. Elep" <[EMAIL PROTECTED]> wrote: > Hi again! :d > > On 2/21/06, Justin Pryzby <[EMAIL PROTECTED]> wrote: >> Really? Your response here: >> http://lists.debian.org/debian-mentors/2006/02/msg00275.html >> seems to indicate that you fixed the package not to crash by >> distributing the file. Of course the file should be distributed. But >> even if it isn't, the program should be written to not crash, >> hopefully in a graceful way (eg using errorx() rather than assert()). > > Heh, I didn't get my point clearly across. Sorry for the malaprop. ;) > > What I meant was that, during the building of the updated xshisen, I > found that xshisen won't start because it can't find its pixmaps, > since it looks for these in /usr/share/xshisen , when in fact I > installed those in /usr/share/games/xshisen . Naturally I had to fix > the debian/rules to correct this. No files were removed or not > distributed in the resulting deb. It's still unclear to me whether "won't start" means "Tells the user it won't start without these files" or rather "Crashes". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: first package pcftisio
Cedric BRINER <[EMAIL PROTECTED]> wrote:
> * {i} this will create
> o python-cfitsio_0.99.2-1_i386.deb : the package to install
> o python-cfitsio_0.99.2-1_i386.changes : the files changes of the packages
> o python-cfitsio_0.99.2-1_i386.changes.asc : ???
>
[...]
> I've got also:
> gpg: skipped "cedric briner
> is that mandatory to make it work ?
Technically, you can just use "dpkg-buildpackage -b -uc" (or "-us -uc",
without -b to create everything in one run). But for being a
maintainer, you should create a gpg key and have it signed by some DD.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: dpkg-buildpackage, dpatch and wrong permissions...
Claudio Moratti <[EMAIL PROTECTED]> wrote: > On Wednesday 22 February 2006 16:27, Matthijs Mohlmann wrote: >> Claudio Moratti wrote: >> > Hi *! > [cut] >> > I'm not able to find how fix this problem... >> > >> > suggestions? >> > >> > Thx a lot ;-) >> > >> > Claudio >> >> This is not really a problem. The point is that diff can't see in a diff >> file if a file is executable yes or no, before diff didn't shout this >> warning. Anyway my build here goes ok and have also some warnings about >> "0755 cannot be represented in diff" warnings. But they shouldn't harm >> the build. > thanks for this explanation! > the build process ends correctly, of course, but I'm not able to understand > why debian/patches files have not the rw-r--r-- perm... > > during the unpack of sources, probably, only debian/* files are chmod-ed.. > could be the reason? IIRC, dpatch doesn't call "patch -p -i debian/patches/", but instead it executes the file, and if it's just a normal unified diff, there's some magic in the header that causes patch to be called properly. Therefore dpatch probably requires that patches be executable and just sets the permissions as needed. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: NEW queue
Peter Samuelson <[EMAIL PROTECTED]> wrote: > [Kai Hendry] >> My package webpy has been in the NEW queue for a couple of weeks > ... >> Is that for a particular reason, or does it usually take that long? > > You're spoiled - it used to be common for packages to sit in NEW for a > month or more. These days the ftpmasters are quite a bit faster. > > Still, they do NEW processing when they happen to have time. Two weeks > isn't unusual. It'd be nice if they cleared the queue out every day, > but that's not a realistic expectation. They process NEW binary packages quite fast, within one to three days to my impression. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Handling of GnuWin32 source packages
Volker Grabsch <[EMAIL PROTECTED]> wrote: > Which of these ways is the current, modern, best practise way of > handling such exotic source archives? I don't think that there's a general consensus about that. > The "Debian New Maintainers' Guide" explicitly says that it doesn't > cover this topic. The "Debian Developer's Reference" has one interesting > chapter "Best practices for orig.tar.gz files" > > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz > > This covers "Repackaged upstream source", but it's very vague. It > doesn't say much about my three ways. It's vague with respect to your questions because I didn't see the need to address them - the real question was "when is repacking accepted at all". > Personally, I like the way 3) at most, because it directly uses the > upstream zip files. If I do so, may I then leave the required > "README.Debian-source"? Yes, I think so - you'll tell where to get the ZIP file in debian/copyright, anyway. > Although they use a "repacked source", they didn't provide a > README.Debian-source. Are there exceptions from that rule? Nobody is enforcing that, and it's actually a rather new addition to the Developers' Reference. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: texmaker
"Thijs Kinkhorst" <[EMAIL PROTECTED]> wrote: > This is all from the first look, so that's already quite ok! Hope you can > find someone to sponsor it for you. One more: Recommends: gs-gpl | gs-esp | gs-afpl, netpbm, psutils, tetex-bin, tetex-extra tetex-bin is not necessary if you depend on tetex-extra (because -extra depends on -bin). On the other hand, people can use TeXLive just as well. The package splitting scheme is different, but I think Recommends: gs-gpl | gs-esp | gs-afpl, netpbm, psutils, tetex-extra | texlive-latex-extra will do. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: checkinstall
Felipe Sateler <[EMAIL PROTECTED]> wrote: > Thijs Kinkhorst wrote: >> The package looks fine, builds fine, good work. The only think I'd >> change is to remove the README.Debian file. That contains information >> that's already known: all Debian packages put their config under /etc. > Done. I had put it in there because the original package installed it > in /usr/lib/checkinstall/, so I considered it worth noting. If the place for configuration is mentioned anywhere in the upstream documentation, this is the place to indicate the Debian-specific placement. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Doing RFS on -mentors
Panu Kalliokoski <[EMAIL PROTECTED]> wrote: > On Sun, Apr 09, 2006 at 03:16:50PM -0400, Justin Pryzby wrote: >> And do whatever needs to be done so a .diff.gz shows up in my browser, >> rather than making me download it :) >> More seriously, this brings me to a practical reason to use non native >> packages (and of course pristine, where possible). These are not just >> theoretical things, but actively make things more difficult for me. > > That's a good point. Actually, the only thing that still troubles me > with these rationales is that they apply equally well to Debian specific > packages. IOW, to ease peer review and NMU'ing, _every_ package should > be non-native, with no exception. I don't agree. If every new upload would be a new upstream version, it doesn't help you much to see that the diff.gz didn't change except for the changelog. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question about debian/copyright
Miriam Ruiz <[EMAIL PROTECTED]> wrote: > More concisely, is debian/copyright supposed to include the copyright and > license of the contents of the binary package in which it is contained, or the > source package from which it is generated? Take into account that the source > package already contains the copyright notices related to the source > distribution, right as upstream have included them. But the upstream information is not always easy to find. It's easy for a simple package with one single license, but in that case you don't need to distinguish between the source package's and the binary packages' copyright files. In my opinion, if the copyright/licensing situation is complicated enough that you consider putting only relevant parts into binary packages' copyright files, there should also be a debian/copyright file (or some of them, with easy to find names) in the source package that describes what you, the Debian maintainer, know about upstream's licensing and copyright information. If this is the case, I think it's a matter of judgement what to do with the binary packages. Note that it's also a lot of work to keep split copyright files up to date - you might want to rearrange the packaging some day. If a software comes with some data included that might be useful for others (like fonts) and is installed as a separate binary package (like foo-xfonts), then it might really make sense to include in /usr/share/doc/foo-xfonts/copyright only the information about these data. And I don't see how this is against policy. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I have adopted the orphaned thailatex package in the bug: > http://bugs.debian.org/357871 > > And now the brand new package has been dressed up, > waiting for sponsoring. I'm willing to look into it and finally sponsor it (especially since my recent NMU might have caused this or that bug). There are still some minor things to do: - debian/changelog: * You shouldn't close bugs with "new upstream release" as an explanation, unless it's a request to package the new version. Instead, write something like * New upstream release - now has a orig.tar.gz again (closes: #344554) - ... babel.sty ... (closes: #351501) - updated fonts - new Loma font * the "bumped standards version to..." section usually also gets an explanation (like "no changes needed" or "lots of packaging changes, details below", or whatever). - debian/copyright: Should mention where babel.sty comes from. I assume it's a newer upstream version than teTeX's. Anyway, be sure to follow the instructions in 3.4 of the Debian TeX Policy Draft, especially the second paragraph under number 2. (hint: the maintainer address for the Basic TeX packages is [EMAIL PROTECTED], you can also reach texlive's maintainer there). - debian/README.Debian: Please check that the information is still correct and needed (and if yes, fix the bad wording, it misses a "problems" or similar). - debian/rules: You could switch to using dh_installtex for the fonts, this would also make the maintainer scripts simpler, and you'd even no longer need 10thailatex.cfg in your debian directory. But this is optional (and I'm not the dh_installtex guy among the Debian TeX Task Force, so don't ask me for details). - installation: * thai.map should not be in TEXMFSYSCONFIG, see file:///usr/share/doc/tex-common/Debian-TeX-Policy.html/ch4.html#s-configurationfiles * it would be nice if the documentation, at least the upstream README. would be available to texdoc. A symlink /usr/share/doc/texmf/thailatex/thailatex.txt -> ../../thailatex/README would do. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote: > Thank you for your comments. I've tried to cover all of them. > Please check the updated package at the old place: > http://linux.thai.net/~thep/debian/source/thailatex/ I'll not be able to do this today (I think), please remind me if I don't speak up by tomorrow evening. > I've logged the closing of #344554 separately, but decided > not to close #351501, because the closing in previous change > was simply from the fact that it's gone when I tried installing. > So, being unable to reproduce the bug, even by stepwise > upgrades, I can't find a good explanation, and should leave it > open, until it can be reproduced somehow. I'll follow up the bug > soon. I suggest to contact the submitter and ask him whether he ever could, and now still can reproduce it. >> * the "bumped standards version to..." section usually also gets an >> explanation (like "no changes needed" or "lots of packaging changes, >> details below", or whatever). > > Done. However, as a new comer who haven't read old > standards, I can't gather what changes are needed between > old and new version. I hope saying "after the repackaging" > is sufficient. Have a look at /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: [RFS] ophaned package glosstex
"roucaries bastien" <[EMAIL PROTECTED]> wrote: > Hi, > > glosstex was orphaned two month ago. However I use it everyday and I > furthermore I correct a few bugs and I improve it (hyperref). Have you contacted upstream about the hyperref extensions? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Wormux 0.7.1-1
artefact <[EMAIL PROTECTED]> wrote: >>- debian/compat should be 5 if you are using debhelper >4 >> >> > I would like to keep the compatibility with version 4 in order to > provide unofficial packages for the stable dist. Of course, I could have > 2 branches, but does it worth ? If you don't use compat 5 features, you can stick to 4, no problem. On the other hand, how is your package going to get to sarge users? I guess through backports, and then you can build it in a sarge-backports environment, and debhelper 5 is available there. >>- debian/control >> - if your package is in the pkg-games svn repo, and sponsored by an >>member of that team, shouldn't the mainter set to them and you just >>an uploader? >> >> > For the moment, it is not sponsored by anyone. So, you say I am the > Uploader, aren't you the Maintainer ? IMO Alexander was wrong here. There's no field for sponsors. Either the package is team-maintained by the debian-games list (however it is called), then the list address should be in the maintainer field, with the people who mostly care about it (DDs or non-DDs) in the Uploaders: Field. Or it is maintained only by you, or you and a couple of people without connection to such a list. Then you should be in the Maintainer field, and the possible others (or nobody) in the Uploaders field. See the Debian Policy on that. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Wormux 0.7.1-1
Alexander Schmehl <[EMAIL PROTECTED]> wrote: > Therefore I think it's in fact a team maintained package, I think it > would be usefull to have [EMAIL PROTECTED] as the > Maintainer: (so we'll get bug reports and other usefull stuff send to > that list) and you as Uploader: (since you prepared that upload). > However, that it's a question I ask, not a request you must fulfill. This way, I agree, with one exception: The Uploaders field is not meant to be changed on every upload (that's Changed-by in the changes file), and therefore does not reflect who prepared a particular upload, but instead the "List of the names and email addresses of co-maintainers of the package, if any.". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote: > On 4/25/06, Frank Küster <[EMAIL PROTECTED]> wrote: > >> I'll not be able to do this today (I think), please remind me if I don't >> speak up by tomorrow evening. > > I guess all necessary issues are covered, including texlive. > If it still needs some more changes, just let me know. Sorry, I found two more things while testing the upgrade. First, you should bump your versioned depends on tex-common to 0.19, since you need a working dh_installtex. Second, after the upgrade thai.map is still in /etc/texmf/dvips/ even if the user never touched it, and will be left after purging. At least the second thing is actually a dpkg bug, but we still should work around it. I suggest to put the following code into your preinst: old_md5sum=78e5add055dd03616e5bbfbe54db6947 current_md5sum=`grep thai.map /var/lib/dpkg/status | cut -f 3 -d ' ' 2>/dev/null || true` if [ $old_md5sum = "$current_md5sum" ]; then rm /etc/texmf/dvips/thai.map fi Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote:
> On 4/28/06, Frank Küster <[EMAIL PROTECTED]> wrote:
>>
>> Sorry, I found two more things while testing the upgrade.
>>
>> First, you should bump your versioned depends on tex-common to 0.19,
>> since you need a working dh_installtex.
>
> That means replacing ${misc:Depends} with explicit info.
No, sorry,...
> Hmm.. OK. I've done it, as well as adding it to
> Build-Depends-Indep.
My mistake. I meant build-depends, or rather I would have meant had I
thought before writing. I do think, however, that it's correct to
explicitly Build-Depend on tex-common, because you explicitly use
commands from it.
>> Second, after the upgrade thai.map is still in /etc/texmf/dvips/ even if
>> the user never touched it, and will be left after purging. At least the
>> second thing is actually a dpkg bug, but we still should work around it.
>>
>> I suggest to put the following code into your preinst:
>>
>> old_md5sum=78e5add055dd03616e5bbfbe54db6947
>> current_md5sum=`grep thai.map /var/lib/dpkg/status | cut -f 3 -d ' '
>> 2>/dev/null || true`
>> if [ $old_md5sum = "$current_md5sum" ]; then
>>rm /etc/texmf/dvips/thai.map
>> fi
>
> This is nice. I've added it.
And it's buggy, sorry. If the user has deleted thai.map, it's still
registered as a conffile, and thus the test will succeed. After that,
however, rm will fail: No such file or directory. Either put in an
additional test for file exisitence, or do rm -f 2>/dev/null.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: help with texmaker
"Joseph Smidt" <[EMAIL PROTECTED]> wrote: > I've been trying for a while to get texmaker to work. There an issue I have > been working on for a month and don't know how to fix it. The latex help > manuels can't be found but they are in > /debian/texmaker/usr/share/doc/texmaker . If somebody could show me what to > do to get the package to "see" this it would help. "can't be found" by what? Does texmaker maybe call "texdoc" to look for them? Then you need to follow file:///usr/share/doc/tex-common/Debian-TeX-Policy.html/ch3.html#s-sec-documentation Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote: >> My mistake. I meant build-depends, or rather I would have meant had I >> thought before writing. I do think, however, that it's correct to >> explicitly Build-Depend on tex-common, because you explicitly use >> commands from it. > > Not explicitly, I think. They are now replaced with dh_installtex > auto-generated commands. I meant: You already Build-Depend on tetex-bin, and thereby indirectly on tex-common. But since your build explicitly uses tex-common, it should also explicitly *Build-Depend* on it (with proper version). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote: > I guess all necessary issues are covered, including texlive. > If it still needs some more changes, just let me know. I've now uploaded it. Once texlive is in unstable, you should try to build with it, and also add it as an alternative build-dependency (or file a bug against texlive if that doesn't work). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: PDF files and dh_compress
Jon Dowland <[EMAIL PROTECTED]> wrote: > At 1147099677 past the epoch, Craig Small wrote: >> Whatever the compression is, it is not too good. >> I'm getting about 10-30% compression on pdfs. > > Which raises the question, what is acceptable? I don't think > a 10% gain in itself is worth gzipping PDFs for. If 10% was > the "threshold", bzip2 should be used instead of gzip for > other things in /usr/share/doc. > > I think PDFs use ZIP internally. ZIP has compression ratios, > perhaps PDFs can be re-packed to use a higher ratio? If the PDF was generated by pdfTex on a Debian machine, the highest compression level (9) is already used. I don't know what happens when it's created via dvi->ps->pdf, and gs' documentation isn't clear about that, but ps2pdf14's pdf files are even slightly smaller (well, in a sample of two files...) Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
autoconf problems (was: How to deal with .sty files correctly?)
Sven Hoexter <[EMAIL PROTECTED]> wrote: > Hello, > I'm in the process of packaging dvipost ATM and I'm a little bit puzzled > with the 'dvipost.sty' file coming along with dvipost. > The makefile installs the dvipost.sty file into > /usr/share/texmf-tetex/tex/latex/misc/ > and runs texhash afterwards. > > So I read http://people.debian.org/~frank/Debian-TeX-Policy/ > but could not find something that realy fits so I stayed with the > installation path and put the "texhash" run into postinst and postrm. > > Is this the right way to deal with such stuff? No, not completely. I'll first tell you what's correct and why, and then we come to the interesting part: How to fix the package's autoconf scripts. Or, no, there's one more interesting part: How to fix the wording of the Debian TeX Policy. You know, we thought that it should be quite clear that this is not correct, and that section 3 should "fit" quite well, especially 3.2. Please read it again, and tell me whether you just didn't read it carefully enough, or how we should change it. So now the what and why: dvipost/sty should be put into /usr/share/texmf/tex/latex/misc/ or /usr/share/texmf/tex/latex/dvipost/, as you like it. The reason is that /usr/share/texmf-tetex/ is reserved for the teTeX packages (as is /usr/share/texmf-texlive for TeXlive), and it may not even be in the search path if a user has both TeXLive and teTeX installed (or parts of), but wants to use only TeXlive. The most interesting part is how to fix it. The path finds its way into the upstream Makefile via this autoconf macro: AC_MSG_CHECKING(latex environment) if texpath=`kpsewhich latex.ltx 2>/dev/null` thenkpseflag="" eliftexpath=`kpsewhich tex latex.ltx 2>/dev/null` thenkpseflag="-DKPSEWHICH_NEED_TYPE" elsetexpath="."; kpseflag="" fi It is clearly wrong to search for latex.ltx; the correct thing to do would be to use something like kpsewhich --var-value='TEXMFMAIN' However, things are more complicated, because the correct variable depends on the configure prefix. If configure is run with --prefix=/usr, then, on a Debian system, TEXMFMAIN is the correct path to look for (on other UNIX system, I don't know whether there's a sane option). If configured with --prefix=/usr/local (or without any specification), it should look for TEXMFLOCAL, and if configured to install into a user's home directory, TEXMFHOME. To make things more complicated, --var-value is quite new, in sarge one has to use kpsewhich --expand-braces='$TEXMFMAIN' (which works in etch, too, but it's kind of ugly and not what it's meant for). I think the clean solution would be to change the autoconf script to output the right thing; and autoconf wizards might be able to do this (perl and emacs lisp might have similar problems). However, for the time being, I'd suggest to just move the file after "make install". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: autoconf problems
Vincent Danjean <[EMAIL PROTECTED]> wrote: > Sven Hoexter wrote: >> On Tue, May 16, 2006 at 12:21:37PM +0200, Frank K?ster wrote: >>> Or, no, there's one more interesting part: How to fix the wording of the >>> Debian TeX Policy. You know, we thought that it should be quite clear >>> that this is not correct, and that section 3 should "fit" quite well, >>> especially 3.2. Please read it again, and tell me whether you just >>> didn't read it carefully enough, or how we should change it. >> My missunderstanding was that I somehow got the impression that this was >> all about fonts for latex. My problem is that I still lag some knowledge >> about how all those latex stuff works. > > I think that the good document for you will be the TDS (referenced in > the section 2 of the Debian TeX Policy. > It explains where to put all the TeX files inside a TeX tree (which TeX > tree to use is explained in the Debian TeX Policy). Yes, but it doesn't tell you which TEXMF tree to choose, and that was the problem here. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > So I don't see anything which requires debian/ directory to be absent > from the orig.tar.gz You are right, there is no such "law". But still it's a bad idea. > especially if a package maintainer is the upstream. This isn't an argument for inclusion of the debian directory (will you release a new upstream version just because you need to change a build-depends and trigger a rebuild on the Debian buildds?). > And also I don't see any strict requirement > (although I understand that it is desired) to don't use native > versioning schema for not-only-for-debian packages. I don't see this written out specifically, either, but I think this is implied. For example, 3.2.1 talks about native packages: , | Native Debian packages (i.e., packages which have been written | especially for Debian) whose version numbers include dates should | always use the "MMDD" format. ` > I think that policy/dev-ref is not clear on that at the moment, that is > why relevant questions come up from time to time. Yes, but the answers given are always the same: Try to avoid a debian/ directory in the upstream sources. It's in the archives. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: >> > especially if a package maintainer is the upstream. >> This isn't an argument for inclusion of the debian directory (will you >> release a new upstream version just because you need to change a >> build-depends and trigger a rebuild on the Debian buildds?). > yikes... pardon my ignorance if it is not so... quick look at dev-ref > didn't allow me to find a statement that boost in debian revision > doesn't cause triggering of buildd. > > you are saying that increment in debian revision doesn't trigger buildd? > So if I fix a security bug and increment debian revision, that doesn't > penetrate to other architectures? > > if buildd is triggered by deb revision increment as well -- there is no > difference between boosting of the upstream version or only deb > revision... Of course a change in the debian revision will also trigger the buildds. But this situation is exactly the problem I was referring to: In the -1 debian revision, you'd have a non-native package with an empty diff.gz file (don't even know whether dpkg-source will accept that). In the -1 version, you would have a diff.gz file that contains only a diff against debian/control and debian/changelog. Now this would be very confusing. Especially if there is a bug in the packaging and you are currently not available: A possible NMUer would be very confused. >> , >> | Native Debian packages (i.e., packages which have been written >> | especially for Debian) whose version numbers include dates should >> | always use the "MMDD" format. >> ` [...] > If you cited it to > characterize what native package is, then we can debate on the meaning > of "packages which have been written especially for Debian". Yes, I cited it because of this. > First of all *any debian package is written especially for Debian*, > so there is a bit of tautology. Package itself is not a software or > documentation, it is a packaging material (ie debian/) accompanying the > content. "package" in this context is also the name for software here. And for sure a package is *not* just the packaging material; a Debian source package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, and a binary package is a deb file. > Cleaner statement may be something like "i.e. if the packaged material > (e.g. software, images, documentation) is intended to be used primarily > on a Debian-based system and useless on the other systems". That seems > to be cleaner. Submit this as a wishlist bug to the policy. >> > I think that policy/dev-ref is not clear on that at the moment, that >> > is why relevant questions come up from time to time. >> Yes, but the answers given are always the same: Try to avoid a >> debian/ directory in the upstream sources. It's in the archives. > yeap - I saw most of those. And I saw the arguments. And I agree that > having split debian/ helps in few cases. But the same question arises > over and over. May be it is the time to fix the policy to make it > explicit to avoid the debates. How can the Debian policy "forbid" something that upstream is doing? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: RFS: FSlint - File System lint
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: Can you please invest in some empty lines between your text and the text you quote? This is hardly readable. Thanks. >> >> > especially if a package maintainer is the upstream. >> >> This isn't an argument for inclusion of the debian directory (will you >> >> release a new upstream version just because you need to change a >> >> build-depends and trigger a rebuild on the Debian buildds?). >> > yikes... pardon my ignorance if it is not so... quick look at dev-ref >> > didn't allow me to find a statement that boost in debian revision >> > doesn't cause triggering of buildd. >> > you are saying that increment in debian revision doesn't trigger buildd? >> > >...< >> Of course a change in the debian revision will also trigger the >> buildds. > that is good that we agree... so what was about your statement:? Well, if the package you uploaded as debian-native has a packaging error, or just needs to be adapted to newer Debian requirements, you have two choices: Either release a new upstream version, which has has no changes relevant for anybody except the Debian buildds. This will confuse your non-Debian users. Or switch from Debian native to non-native packaging - better do that in the first place. If you've packaged it as non-native from the start, we end up in the situation described below: >> >> release a new upstream version just because you need to change a >> >> build-depends and trigger a rebuild on the Debian buildds?). > >> In the -1 debian revision, you'd have a non-native package with an empty >> diff.gz file (don't even know whether dpkg-source will accept that). > that is ok to my knowledge It is okay, but it's confusing by itself. >> In the -1 version, > -1 version? may be you meant debian revision? may be -2? Sorry, yes, I meant debian revision -2. >> you would have a diff.gz file that contains only a diff against >> debian/control and debian/changelog. Now this would be very >> confusing. Especially if there is a bug in the packaging and you are >> currently not available: A possible NMUer would be very confused. > can you describe what is confusing in that? I don't really see it... you > don't operate on diff.gz directly anyways -- you are operating on > extracted (and may be even patched) source, so you have all the files. I often operate on diff.gz files. It's easy to look into them, just "less ...diff.gz", and you can check whether the copyright file is okay, whether it uses dpatch, cdbs, whatever, whether a particular patch has been applied, and so on. > Usually you are inspecting .diff to catch what was done wrong, or if > there was garbage sucked in, or to extract relevant patch. If .diff.gz > was missing debian/ it is obvious (to me) that debian is within > orig.tar.gz due to the definition of diff.gz If the diff.gz is missing a Debian directory, the first thing I'd suspect would be that something went badly wrong. After finding out that the directory is in the orig.tar.gz, I'd go on checking in the copyright file whether any repackaging is described. If I find no information about that, I'd think about two possibilities: Either the debian directory is in the orig.tar.gz file, or the packages didn't document their repackaging. For both cases, the best approach would be to file a bug... >> > First of all *any debian package is written especially for Debian*, >> > so there is a bit of tautology. Package itself is not a software or >> > documentation, it is a packaging material (ie debian/) accompanying >> > the content. >> "package" in this context is also the name for software here. And for >> sure a package is *not* just the packaging material; a Debian source >> package consists of tar.gz and dsc or orig.tar.gz, diff.gz and dsc, >> and a binary package is a deb file. > ok - let me make an analogy to describe what I meant: "this book > containing fairy tales from around the world was written especially for > our kindergarden"... And you expect that the kindergarden in the neighborhood will not be interested, never? And you also expect that the people working there will never get a different opinion how a fairy tale book should look like? If the people working with the newest group of younger children try out something new (i.e., Debian policy is changed for the next release), shouldn't the book be still the same for the ones working with the older groups? >> How can the Debian policy "forbid" something that upstream is doing? > :-) Good questions with simple answer: it can't. That is why over a
Re: Question about linux-wlan-ng-firmware in main
Stephen Gran <[EMAIL PROTECTED]> wrote: >> In fact, I go even further: I wish that the package use a low-priority >> debconf question (defaulting to "do not download") to let the user execute >> the wrapper at installation time. Of course, the question should warn the >> user that he's about to download non-free stuff. > > Can't you just ship those ten lines in contrib, and the rest in main? > This may be archive bloat, but surely it's arch:all, so that minimizes > the bloat at least. I am not over fond of the freer-than-free holy > wars, but it does seem like this script is exactly the sort of thing > that contrib was designed for. No, it wasn't. As long as I can remember, packages which contained a small part of contrib material, which was not crucial for the function of the package as a whole, can go to main. Look at the policy: , 2.2.1 The main category | Every package in main must comply with the DFSG (Debian Free Software | Guidelines). | | In addition, the packages in main | | * must not require a package outside of main for compilation or | execution (thus, the package must not declare a "Depends", | "Recommends", or "Build-Depends" relationship on a non-main | package), ` This explicitly does *not* mention "Suggests". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question about linux-wlan-ng-firmware in main
Bas Wijnen <[EMAIL PROTECTED]> wrote: > On Tue, May 30, 2006 at 03:26:56PM +0200, Frank K?ster wrote: >> No, it wasn't. As long as I can remember, packages which contained a >> small part of contrib material, which was not crucial for the function >> of the package as a whole, can go to main. Look at the policy: >> >> , 2.2.1 The main category >> | Every package in main must comply with the DFSG (Debian Free Software >> | Guidelines). >> | >> | In addition, the packages in main >> | >> | * must not require a package outside of main for compilation or >> | execution (thus, the package must not declare a "Depends", >> | "Recommends", or "Build-Depends" relationship on a non-main >> | package), >> ` >> >> This explicitly does *not* mention "Suggests". > > Packages containing some contrib material, without which the package functions > well, can indeed go in main AFAIK. However, if I understand the situation > correctly, this package is completely useless without the non-free firmware if > you happen to have a device which needs it. It seems we are confusing source packages and binary packages here. The source package is linux-wlan-ng, and this clearly has a use independently of any non-free files. The binary package is linux-wlan-ng-firmware, and this is only a downloader. > Then again, this sounds pretty much like a thing for debian-legal. :-) I rather think it's a technical question: Can a source package in main produce one binary package that is installed in contrib, or is the separation done only on the level of source packages? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
