Bug#303082: acknowledged by developer (fluxbox-doc: closing old inactive RFP)
reopen 303082 retitle 303082 fluxbox package is missing official documentation reassign 303082 fluxbox thanks > This is an automatic notification regarding your Bug report > #303082: RFP: fluxbox-doc -- fluxbox documentation, > which was filed against the wnpp package. > > It has been marked as closed by one of the developers, namely > Lucas Nussbaum . Frankly, I haven't checked whether the documentation is still available at the place I named, but it is definitely still missing from the package. Regards, Frank P.S. Thanks anyway, Lucas, for your work -- Frank Küster Sprecher B90/Grüne OV Miltenberg und Umgebung VCD Miltenberg, ADFC Aschaffenburg-Miltenberg Debian Developer (TeXLive) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc0fo23x@alhambra.kuesterei.ch
Bug#514751: ITP: pgfplots -- TeX package to draw normal and/or logarithmic plots directly in TeX
OHURA Makoto wrote: > Package: wnpp > Owner: OHURA Makoto > Severity: wishlist > > * Package name: pgfplots > Version : 1.2 > Upstream Author : Christian Feuersanger > * URL or Web page : http://pgfplots.sourceforge.net/ > * License : GPLv3 > Description : TeX package to draw normal and/or logarithmic plots > directly in TeX This package will be included in TeXLive 2008. There's still some way to go until we'll be able to upload those packages - or rather, it's probably quite easy, but there's no one who works on this regularly. Of course I'd prefer your working on TeXLive 2008, but if you do prepare packages for pgfplots, are you willing to keep on maintaining them when TL 2008 is in the archive? TIA, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481606: Questions about MiKTeX package manager for Debian
Paul Gevers <[EMAIL PROTECTED]> wrote: > Hello, > > I am currently working on packaging the MiKTeX-tools for Debian, which > consists mainly of a LaTeX package manager. (I hope you know the > tools.) Because MiKTeX pulls the packages from CTAN I was wondering if > you can tell me how TeXlive (which if I am correct also works from the > CTAN), works with licensing/copyrights, Manual checking. We're not actually sure that we've already identified every non-free bit and taken it out. > because this is a large issue > with Debian. Someone [1] suggested to ask here. Of course it's an issue to have only DFSG-free software packaged in Debian. But how does that affect a package manager? Well, it would be really cool if the package manager was able to display the license of package I am about to download. But it doesn't affect its freeness which license data it downloads have. > By the way, how do you feel about such a LaTeX package manager for > Debian? Do you think it might be useful? Or does TeXlive include a > manager which does the same thing? I read somewhere that TeXlive is > also (partly) based on MiKTeX. Answering backwards, last question first: No, I don't think TeXliv is based on MikTeX. It's based on teTeX, and teTeX and MikTeX may have some common roots - although I think that rather has MikTeX taken over some ideas from teTeX, and then developped much further. TeXLive Upstream does have a user interface for selecting packages from the installation media, but it doesn't update from CTAN or install additional packages. It only handles the packages included when the particular TeXLive version was released. Therefore, it is not included in the Debian packages - we have our Debian texlive packages (which are not based on individual CTAN packages, but collections) and aptitude etc. for installing them. I do think that a package manager for updating individual packages and for installing add-on packages (new on CTAN, non-free, or not on CTAN at all) would be a nice thing to have. As far as I know, TeXLive upstream maintainers already work on such a feature (maybe even with MikTeX-like automatic package installation), but I'm not sure about it's status. I'd be surprised if it would be already in the soon-to-be-released 2008 version. Therefore, having such a package manager in Debian might be a good idea, too. However, be aware that it is not trivial to integrate the package manager with the TeX installation on Debian. I'm sure you've already studied the Debian TeX Policy; it provides for the TEXMF trees you need, but there's more to do. In particular, I don't think you should call the binary package miktex-tools. I'm not used to all of them, but it seems that what you mainly want to make available for Debian is mpm? I guess we do not want initexmf in Debian. As for the license, I guess you looked at the wrong place, on the Web site. You should have looked in the source tarball. There you'd find files named "COPYING", which unfortunately just contain a copy of the GPL, along with the instructions below it telling the author what he should have done... Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458380: Bug#465088: texlive-latex-recommended: Duplicates package latex-ucs
retitle 465088 texlive-latex-recommended: Duplicates unmaintained package latex-ucs tags 465088 wontfix thanks Gábor Braun <[EMAIL PROTECTED]> wrote: > Package: texlive-latex-recommended > Version: 2007-13 > Severity: minor > > The CTAN package ucs is packaged seperately as latex-ucs. > Therefore, you should remove it from this package. No, see #458380, RFA: latex-ucs which has been discussed in December in http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/348881/focus=26256 and we agreed that latex-ucs can be removed. Martin, should we retitle the RFA bug to RM [RoM] and reassign to ftp.debian.org? Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)
Bug#418778: O: arabtex
Norbert Preining <[EMAIL PROTECTED]> wrote: > But I propose that we take over arabtex in the sense that we create > texlive-lang-arab. The respecive tpm file contains: > arabtex.tpm > arabi.tpm > which would mean that we would get added value, too, namely a new Arabic > system: > > Arabi System > Version 1.1 > (c) Youssef Jabri > > > An author maintained LPPL system to write in Arabic and Farsi. > Fully compatible with BABEL and can use commercial fonts > (as well as free ones :) > -------- > > Comments? ACK. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#403770: ITP: context -- A powerful TeX format
Norbert Preining <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Norbert Preining <[EMAIL PROTECTED]> > > * Package name: context > Version : 2006.12.17 > Upstream Author : Hans Hagen > * URL : http://www.pragme-ade.com > * License : GPLv2 > Programming Lang: TeX > Description : A powerful TeX format Fine :-) > ConTeXt is a typographical engine written in the typographical computer > language TeX. ConTeXt provides you with a convenient way to encode documents > in a structured way and to typeset these documents in various ways on paper, > computer screen or web site. > > Use ConTeXt to create simple documents and complex layouts. To me this long description sounds too much like marketing blurb and has little information content. The most important question that it should answer is "what's the difference to the more known LaTeX?" Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379564: Bug#389163: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Norbert Preining <[EMAIL PROTECTED]> wrote: > On Sam, 16 Dez 2006, Frank Küster wrote: >> > THis name change is currently under discussion in the tex-live >> > (upstream) mailing list with the original authors participating. As soon >> > as we have come to a conclusion there it will be executed in Debian. >> >> Sorry, aren't the texlive people talking about mex? I always thought >> that it was settled that aleph "belongs" to the TeX community, and the >> programming language is "afnix"? > > Damned, you are right, I mixed this. So we have > aleph(texlive-omega,tetex-bin) vs. aleph(aleph) > and > mex(texlive-lang-polish) vs. mex(octave) No, we don't have any problems (for etch): - aleph has been removed and will probably be reintroduced as afnix - octave uses /usr/bin/mex2.1 We should, however, contact the octave people about the possible conflict, perhaps with a wishlist bug "Please don't use /usr/bin/mex". Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379564: Bug#389163: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Norbert Preining <[EMAIL PROTECTED]> wrote: > On Sam, 16 Dez 2006, Steve Langasek wrote: >> > 3) Retain aleph, and change the name of the binary in one package or the >> > other. If we don't do (2), and the release team is not happy with (1), >> > then this is obviously the right course. I don't care at all which >> > program's name is changed or what it's changed to. What are the pros >> > and cons? >> >> Sounds like this is the way to go. > > THis name change is currently under discussion in the tex-live > (upstream) mailing list with the original authors participating. As soon > as we have come to a conclusion there it will be executed in Debian. Sorry, aren't the texlive people talking about mex? I always thought that it was settled that aleph "belongs" to the TeX community, and the programming language is "afnix"? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379564: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > 1) Leave things alone, and ignore the problem. This, it seems to me, > requires some kind of go-ahead from the release team. > > 2) Drop aleph. This would be warranted if it were of no use any longer, > or if it were buggy. But the *only* bug against Aleph is the name clash > with TeX, so there is no independent reason to prefer this solution. > The question remains, however, whether the current version has any use, > and I simply don't know the answer to that. If it does, then, as I > said, I'm happy to maintain it. I don't know an answer, either - but popcon gives some hints: 18170 aleph-emacs 23 0 0 023 (Debian Qa Group) 21858 aleph-doc 12 0 0 012 (Debian Qa Group) 30097 aleph 3 1 2 0 0 (Debian Qa Group) 37868 aleph-dev 1 0 1 0 0 (Debian Qa Group) the 3's are the area of the "not in sid" packages, in other words leftovers that have never been upgraded or removed. That's not a strong argument to keep it... > 3) Retain aleph, and change the name of the binary in one package or the > other. If we don't do (2), and the release team is not happy with (1), > then this is obviously the right course. I don't care at all which > program's name is changed or what it's changed to. What are the pros > and cons? I'm against changing TeX's aleph. It would be against the upstream decision. And knowing the information Paul gave, I suggest not to rename to afnix, but to something like aleph-runtime or similar. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379564: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Andreas Barth <[EMAIL PROTECTED]> wrote: > Why is it better than to drop aleph? If a package is way outdated, and > RC buggy, and also aleph is practically unchanged since Sarge, I think > that is still grounds for a removal. I haven't investigated about aleph. I just thought that, since it doesn't have many bugs, even the current version might be useful, and better than nothing. If Thomas packages afnix (together with Paul or separately), that's probably the best choice. From a technical point of view, the package names could also stay the same, so that we don't need to wait for NEW processing (but you RMs might have a magic wand to speed up that?) Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379564: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
severity 389163 serious thanks Dear release team, I just noticed , Etch RC policy: | | | Packages must not install programs in the default PATH with | different functionality with the same file name, even if they | Conflict:. ` We've got a problem here, since all three packages are in testing, provide /usr/bin/aleph, and conflict with each other (or rather, the *tex* packages conflict with aleph). The right solution to this would be to package the "new upstream version" of aleph, which changes the name to afnix. However, the aleph package has been orphaned (#374120), and the ITP afnix has not yet yielded a package. I wouldn't want to rely on that for etch (although this is the first time I contact Paul about this, so I might be wrong). If there'll be no afnix package in etch, the only other solution to this problem seems to be to remove aleph from testing - any NMUing won't make sense without doing the actual work of packaging afnix. To me it seems as if the current situation is better than having no aleph/afnix at all. However, it violates the release policy. What should we do? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#398890: [Paul Seelig] O: ethiop
> From: Paul Seelig <[EMAIL PROTECTED]> > Subject: O: ethiop > To: Debian Bug Tracking System <[EMAIL PROTECTED]> > Cc: Frank Küster <[EMAIL PROTECTED]> > Date: Thu, 16 Nov 2006 10:38:21 +0100 > Reply-To: Paul Seelig <[EMAIL PROTECTED]> > > Package: wnpp > Severity: normal > > Unfortunately, i have no use anymore for this package and therefore won't > keep maintaining it. A new maintainer is needed, preferably with an > Ethiopian language background, if at all possible. > > Maybe it would even be better to completely remove the package from the > Debian archive. It is already included in the upstream source tar ball for > texlive which is also part of the Debian archive. It's not only included in the tarball, it's also installed (binary package texlive-lang-african). texlive also has additional Type1 fonts (see also #390195). The TeXlive maintainers generally appreciate if someone cares for a particular component of TeXlive and maintains it in a separate package; we exclude the stuff from our packages and Recommend the separate package. However, if no one steps up and maintains ethiop, there's no problem in just removing it now. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#391342: [RFS]: jsMath:TeX equations in HTML documents
[resending to the correct b.d.o address] Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > Packages are lintian/linda clean. Worries might be due to use of > debconf in jsmath to configure web servers. gallery's scripts were used > as a start point. I might in future disable botton in jsMath menu to > look for updates (although it can't hurt so people could buzz me to run > uscan ;-)) > > Thanks everyone in advance for looking at. Some comments: debian/copyright: I think that a binary deb package is a derivative of both the upstream source and the Debian packaging. According to http://www.gnu.org/licenses/license-list.html, upstream's Apache license (v.2.0) and your GPL for the packaging are incompatible. maintainer scripts: - it's inconsistent to name them jsmath.config but postinst and postrm without the package name prepended - What's the purpose of this in config: db_version 2.0 || [ 0 -lt 30 ] This looks just like || true, and debconf-devel(7) suggests you never need this command... - the config script should try to detect which servers are actually installed, to make sure the user does not select exactly the one that's *not* installed. Might be tricky to implement, though. - the second debconf question is asked with higher priority than the first (why?), but the text is written with the assumption that the user has already seen the first question. This should be changed... - the postinst is probably RC buggy, see policy 10.7.4: "The maintainer scripts must not alter a conffile of any package, including the one the scripts belong to." At least /etc/apache2/httpd.conf doesn't seem to be a conffile, but I think this mostly applies to configuration files, too. Moreover, I doubt that this works at all, and I think there are better mechanisms to interact with webserver packages than that. You write you've taken the code from gallery, but that doesn't mean that it is good. If I'm talking rubbish here, this is because I don't have much experience with web servers - but I don't think it's complete rubbish. debian/rules: - why do you call dh_strip and dh_link? So much for this package, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#389598: ITP: xpbiff -- animated mail monitor on X with popup notification
James Vega <[EMAIL PROTECTED]> wrote: > On Tue, Sep 26, 2006 at 07:29:05PM +0200, Gernot Salzer wrote: >> Copyright: >> >> * xpbiff - popup biff for X >> * >> * Author: Kazuhiko Shutoh, 1993 >> * >> * Permission to use, copy, modify and distribute without charge this >> software, > > Doesn't the 'without charge' bit violate DFSG #1? If it is meant as it is written, yes. Often sentences like this can also be read as "Permission, without charge, to use, copy, ...". But in this particular case the "without charge" seems to be quite clearly associated with "distribute". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#389394: O: netenv -- Configure your system for different network environments
Package: wnpp Severity: normal I hereby orphan netenv. I do no longer use it, and my limited time does not allow properly maintaining it. It's unique feature, compared to other packages for managing a laptop in different network enviroments, is that it does not at all try to detect anything automatically: All is in the hands of the person sitting at the keyboard while booting. Because of this unique feature, I think it deserves being maintained. It's completely written in shell (bash, actually). Upstream exists and responds to e-mail (with long delays), but upstream development is very slow - there are simply not many improvements to make. Some Debian-specific improvements I made, however, where rejected upstream, so there are some differences in how the script acts. The new maintainer should be willing to maintain these parts, too. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#365672: RFP: xetex - An extension of TeX with Unicode and OpenType support
Norbert Preining <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> On Fre, 25 Aug 2006, Frank Küster wrote:
>> > suppose. It should be shipped with the data.tar.gz. dh_installtex does
>> > *NOT* create the necessary symlinks. (Should it do it?)
>>
>> If we want to do that, we should modify texlinks to accept a $DESTDIR
>> and call that one from dh_installtex.
>
> On Fre, 25 Aug 2006, Atsuhito Kohda wrote:
>> Only quick look, original postinst contained, among others,
>> "texlinks --silent" so I guessed removing it could be wrong.
>
> Ahhh.
>
> Well I am against calling texlinks in the postinst and creating files
> which are *NOT* removed at remove/purge time.
Yes, this should definitely not be done.
> So: if we provide the functionality in dh_installtex, it should create the
> links by itself (without texlinks) in debian/$(package)/usr/bin
> and should NOT put code like texlinks into the postinst script.
>
> Or better, devs create the symlinks by themselves in the rules file.
>
> What do you think, which of the two options is better?
Since the symlinks and their targets can be deduced from a
"configuration file", namely the fmtutil.cnf snippet, I think it would
be a good idea to include this in dh_installtex. However, I don't think
this is particularly important; there's probably other things to do that
are more pressing.
The reason why I was mentioning texlinks and a DESTDIR option is that
the code for parsing fmtutil.cnf, deciding about and generating symlinks
already exists. And I had now a short look at the code in texlinks: I
think it has already nearly everything we need. A call like
texlinks --cnffile debian/40Foo.cnf debian/foo/usr/bin/
would create the symlinks, just that it checks whether the targets
exist. Here's a patch:
--- /usr/bin/texlinks 2006-08-02 16:27:58.0 +0200
+++ bin/texlinks2006-08-25 13:29:08.0 +0200
@@ -49,6 +49,8 @@
--silent
-ssilently skip over existing scripts / binaries
instead of creating a warning
+ --allow-dangling
+ -dallow dangling symlinks
directories is an optional list of directories in which to operate.
If no directories are specified the list of directories depends on the
@@ -228,6 +230,7 @@
multiplatform=false
verbose=false
silent=false
+ allow_dangling=false
thisdir=`pwd`
: ${KPSE_DOT=$thisdir}; export KPSE_DOT
selfautoloc=`kpsewhich --expand-var='$SELFAUTOLOC'`
@@ -242,6 +245,7 @@
--v*|-v) verbose=true;;
--s*|-s) silent=true;;
--m*|-m) multiplatform=true;;
+ --allow-dangling|-d) allow_dangling=true;;
-*) errmsg "fmtutil: unknown option \`$1' ignored.";;
*) break;;
esac
@@ -290,7 +294,7 @@
main_args_while="$@"
test "x$fmt" = "x$engine" && continue
- if test -f "$d/$engine"; then
+ if test -f "$d/$engine" || test "$allow_dangling" = "true"; then
install_link "$engine" "$d/$fmt"
else
verbose_echo "$d/$engine: engine does not exist. Skipping..."
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Bug#365672: RFP: xetex - An extension of TeX with Unicode and OpenType support
Norbert Preining <[EMAIL PROTECTED]> wrote: > On Fre, 25 Aug 2006, Atsuhito Kohda wrote: >> >From curiosity, I've packaged xetex 0.995 (and xdvipdfmx 0.3) for >> Debian/unstable. (I don't mean to maintain it though. I guess >> it would be best TeXLive includes XeTeX.) > > Next version will include it. I think about making a intermediate > release of texlive packages with 2006~svnYYMMDD so that we can get > xetex. We will see. While that would be good, I think it would be even better if someone maintains a separate xetex package. xetex has a much faster development process currently than texlive. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#365672: RFP: xetex - An extension of TeX with Unicode and OpenType support
Norbert Preining <[EMAIL PROTECTED]> wrote: >> Ah, perhaps I modified postinst in a wrong way. Thanks. > > Hmm why the postinst? The link should be created in the rules files I > suppose. It should be shipped with the data.tar.gz. dh_installtex does > *NOT* create the necessary symlinks. (Should it do it?) If we want to do that, we should modify texlinks to accept a $DESTDIR and call that one from dh_installtex. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#205392: jabref destiny
gregor herrmann <[EMAIL PROTECTED]> wrote: > So yes, I'd be willing to maintain this package. > Frank, is it ok for you if I take over #205392? Yes, of course. Go ahead! Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#199874: acknowledged by developer (WNPP bug closing)
reopen 199874 thanks [EMAIL PROTECTED] (Debian Bug Tracking System) wrote: > #199874: ITP: molmol -- Display and analyze structures of biological > macromolecules [med-bio], > Your ITP wnpp bug is being closed because of the following reasons: > - It is, as of today, older than 365 days. > - It hasn't had any activity recently. I still plan to ask the copyright holders when I find some time. More importantly, I keep getting private mails about the software, and I assume that a RFP bug would be opened quite soon. David, I'd really appreciate if you'd try to contact the bug owner before closign. I don't know how many bugs you closed this way, so it might not be feasible, but still I'd like it... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#335899: Bug#348906: lmodern warnings with bullets and cdots
retitle 335899 RFA: lmodern -- scalable PostScript fonts for european character sets reassign 335899 wnpp,lmodern thanks Elrond <[EMAIL PROTECTED]> wrote: > Exactly my point! > > Thanks for clarifying. > > I really do like it, if Debian packages have a > README.Debian, that gives "quick start" infos, as most > other stuff is already prepared to "work out of the box", > one just needs to know, how to use it "on Debian". Note that this information is by no means Debian-specific. We should submit this change upstream. Apropos "we": As a sidenote in a thread on -devel, it turned out that our current choice of letting lmodern be orphaned and subscribing the list to its bugs is suboptimal, since people are considering some auto-cleanup of testing from orphaned packages with bugs (even with non-RC bugs). So I'm retitling the bug to RFA (request for adoption) and make it visible also in the lmodern package's bug page, and we're going to do a takeover-upload somewhen in the future >> This text assumes that people who need other encodings than T1 (current >> lmodern package supports also QX, current upstream supports at least >> also T5) know what to change. >> >> Of course, it would be better if upstream would provide better >> documentation, so that one could refer users to 'texdoc lmodern'. > > As mentioned above, I like the quickstart info, if upstream > has more docs, the above text could have some "For more > details, see the docs in ...". I object to that - if there *is* an upstream documentation, duplicating this in README.Debian is superfluous (and even harmful, because it distracts people from the cases where README.Debian in fact has important Debian-specific information). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#339513: ITP: feynmf -- LaTeX macros for creating Feynman diagrams
"Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Kevin B. McCarty <[EMAIL PROTECTED]> > > * Package name: feynmf > Version : 1.08 > Upstream Author : Thorsten Ohl <[EMAIL PROTECTED]> > * URL : > http://www.ctan.org/tex-archive/macros/latex/contrib/feynmf/ > * License : GPL > Description : set of LaTeX macros for creating Feynman diagrams > > Feynmf is a combined LaTeX/Metafont package for easy drawing of > professional-quality Feynman diagrams Nice to see an other LaTeX package in Debian. Please have a look at the new Debian TeX Policy Draft in /usr/share/doc/tex-common/. Please either follow it, or bug the debian-tetex-maint list if you find any flaws. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#335899: O: lmodern -- scalable PostScript fonts for european character sets
subscribe lmodern debian-tetex-maint@lists.debian.org thanks Florent Rougon <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: normal > > Hi, > > I cannot work on lmodern anymore and am hereby orphaning it. We are *not* offering to take the package, but we want to know about its bugs and other activity. I hope subscribing the mailing list (which is the maintainer of tetex-*) will work, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#205392: JabRef is being prepared for Debian
Tobias Toedter <[EMAIL PROTECTED]> wrote: > merge 205392 308094 > thanks > > Hi, > > please note that Frank Küster <[EMAIL PROTECTED]> was preparing a package > for Jabref. I don't know how far he got with it. Frank, any news on this? As I wrote just yesterday in #205392, not very far. The packages that I have build with sun's Java, but I don't even remember whether the binary works (since I didn't have time, I just took the compiled version from the upstream site when I set up my working machine three months ago) The packages are at http://www.kuesterei.ch/jabref_1.7.orig.tar.gz http://www.kuesterei.ch/jabref_1.7-1.dsc http://www.kuesterei.ch/jabref_1.7-1.diff.gz Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#205392: some useful tools
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > Hi Jukka (and Frank) > > Nice references! > I think I will give rubber a spin. Not that I am lost in my makefiles > but indeed there might be something better. > > jabref sounds cool too. Indeed Java GUI probably is quite nasty but your > description gives some nice features which I think are not present in > pybliographer which I'm using at the moment and which I really like. > if only someone packaged it for debian > well -- there was ITP > http://lists.debian.org/debian-wnpp/2005/03/msg01069.html > > Frank, how is packaging going or did you abandoned the idea? I didn't completely abandon it, but I had to reduce the amount of work I do for Debian, and I doubt that I will have time for that soon. Especially since I don't know Java really, and it didn't turn out to be trivial to run or compile it with a free Java. I took it as an opportunity to get more familiar with Java, but won't have much energy for that, either. So if somebody else is interested, I'd gladly hand that over. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#280675: ITP: l2tpns
Jonathan McDowell <[EMAIL PROTECTED]> schrieb: > On Fri, Nov 12, 2004 at 03:34:45PM +0100, Frank Küster wrote: >> Jonathan McDowell <[EMAIL PROTECTED]> schrieb: >> > On Fri, Nov 12, 2004 at 12:17:20PM +0100, Frank Küster wrote: >> >> To my taste, this description contains too many abbreviations, and is >> >> only understandable for someone who already knows what they mean. Please >> >> follow the general guidelines for descriptions, >> > "The package description should be written for the average likely user" >> > >> > The average likely user should know what L2TP is and understand the >> > LNSes role in this. >> No, I don't think so. I think that "the average likely user" is meant >> to be an average user of Debian, not the user of the package. This is >> logical, because the purpose of the description is to allow a user to >> decide whether he *is* the target user of the package. > > If the user doesn't understand the package description, is it not > reasonable to assume they'll work out it's probably not for them? No, it is not reasonable. There *are* lots of crappy^Wbad descriptions around, and for a user it is, unfortunately, very reasonable to assume that the solution to her/his problem lies in a package whose descriptions she doesn't understand at all. Your package would add one more that she'd have to check. > If I > went searching for something and found a handful of packages, some of > which had many terms I didn't understand while the others did, I'd > assume that some of the packages weren't appropriate to what I wanted. Or that they had simply bad descriptions. > Must we dumb everything down to the lowest common denominator rather > than assuming our users have some level of intellegence? This is not a question of intelligence. If you don't know anything about chemistry, but you want to buy a chemistry experimentation kit for your 14 year old son or daughter (who is fond of chemistry and has yet read lots of books), shouldn't the box of the kit tell _you_ whether it makes sense to buy this one, or whether it will be much too easy or dangerous for him/her? If you don't understand it - do you have a problem with your intelligence? No. Don't take this as an analogy for your package description - there might be packages an admin installs on user request without knowing them, but yours is not one of these. But take it as a hint that it is not about intelligence. > Would you be satisfied with "This package is not intended for users who > want to setup a local dialup or similar connection; you probably want > the ppp package instead." as the first paragraph of the description? Or > perhaps "This package is aimed at those who need to terminate a large > number of L2TP sessions; if you're a home user you probably want the ppp > package". Yes, that would be appropriate. Andreas suggestion sounds even better to me, because it is not longer, but has the additional information what L2TPNS is. > I'm sorry, I disagree. PPP and ISP are commonly used terms and L2TP/LNS > should be familiar to the users of the package. Yes, PPP and ISP are common (although ISP is much less common for non-english speaking users). But if, by the will of the gods of regexp matching, a package shows up in a totally different context, the abbreviations might have a totally different meaning in that context. If an abbreviation can be avoided, it should be. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#280675: ITP: l2tpns
Jonathan McDowell <[EMAIL PROTECTED]> schrieb: > On Fri, Nov 12, 2004 at 12:17:20PM +0100, Frank Küster wrote: >> Jonathan McDowell <[EMAIL PROTECTED]> schrieb: >> > Package: wnpp >> > Severity: wishlist >> > >> > * Package name: l2tpns >> > Version : 2.0.5 >> > Upstream Author : David Parrish and others <[EMAIL PROTECTED]> >> > * URL : http://l2tpns.sf.net/ >> > * License : GPL >> > Description : L2TP LNS which does not require l2tpd, pppd or any >> > kernel patches. >> > >> >L2TPNS is half of a complete L2TP implementation. It supports only >> >the LNS side of the connection. >> [...] >> >> To my taste, this description contains too many abbreviations, and is >> only understandable for someone who already knows what they mean. Please >> follow the general guidelines for descriptions, >> >> file:///usr/share/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics > > This says: > > "The package description should be written for the average likely user" > > The average likely user should know what L2TP is and understand the > LNSes role in this. No, I don't think so. I think that "the average likely user" is meant to be an average user of Debian, not the user of the package. This is logical, because the purpose of the description is to allow a user to decide whether he *is* the target user of the package. Did you read the complete paragraph? It explains its intention with an example: , | Avoid referring to other applications or frameworks that the user | might not be familiar with ? "GNOME" or "KDE" is fine, since users are | probably familiar with these terms, but "GTK+" is probably not. Try | not to assume any knowledge at all. If you must use technical terms, | introduce them. ` If GTK+ is not acceptable, how can l2tpd, l2tp and lns be? They could, if you _first_ state clearly that the package is only aimed at people experienced in some type of network setup. Any user who wants to do something about her dialup connection and enters "apt-cache search ppp" should immediately know whether the package might be useful (perhaps after some or a lot of reading) or whether it is about something different. > (And the only abbreviations I count in the description are L2TP [which > gets expanded], LNS, PPP and ISP.) That's about 3 to 4 too much. Generally, because of good style, not because they are unfamiliar to me. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#280675: ITP: l2tpns
Jonathan McDowell <[EMAIL PROTECTED]> schrieb: > Package: wnpp > Severity: wishlist > > * Package name: l2tpns > Version : 2.0.5 > Upstream Author : David Parrish and others <[EMAIL PROTECTED]> > * URL : http://l2tpns.sf.net/ > * License : GPL > Description : L2TP LNS which does not require l2tpd, pppd or any kernel > patches. > >L2TPNS is half of a complete L2TP implementation. It supports only >the LNS side of the connection. [...] To my taste, this description contains too many abbreviations, and is only understandable for someone who already knows what they mean. Please follow the general guidelines for descriptions, file:///usr/share/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics Thanks, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#276392: O: bochs -- IA-32 PC emulator
Robert Millan <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: normal > > I intend to orphan the bochs package. Is this just because your workload is too high? Or is there any other reason like "bochs is bad" or "there are better alternatives" or the like? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#268126: O: tex4ht -- LaTeX and TeX for Hypertext (HTML)
Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > Note that Juhapekka Tolvanen <[EMAIL PROTECTED]> is maybe interested (or maybe > not) in taking over this package, he is not a DD though. Juhapekka, just ask on debian-tetex-maint - somebody, probably me, will be a good candidate for a sponsor. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#257914: ITP: libodbcxx -- C++ class library for accessing SQL databases via ODBC
Dan Weber <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > > * Package name: libodbcxx [...] > Libodbc++ is a c++ class library for accessing SQL databases. It is Why didn't you name the package libodbc++, which seems to be the upstream name? (and why isn't the upstream name libodbcc++, one c from ODBC, one from C++?) Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#133649: Status of the package cm-super?
Rogério Brito <[EMAIL PROTECTED]> wrote: > Anyway, is the new version of tetex expected to enter testing before > sarge's release? Nobody knows when sarge will finally be released, but bets are against it. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#133649: Status of the package cm-super?
Hilmar Preusse <[EMAIL PROTECTED]> schrieb: > On 27.06.04 Rogério Brito ([EMAIL PROTECTED]) wrote: > > Hi, > >> Is there any possibility of having the package cm-super being >> included in time for Debian's sarge release? >> > Yes, if there will be a volunteer to take the maintainership. > Preliminary packages exist and also on CTAN exist one from Peter > Szabo, but I guess Claire won't do it. Rogério, It's not a question of "in time for sarge's release". The next upstream teTeX version will contain the lmodern fonts, but not cm-super. Therefore the cm-super fonts will never be part of teTeX, and if you want them in Debian, you'll have to find somebody to package them. The lmodern package (now a separate package) could be a good starting point for adaption to cm-super. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#199874: Outstanding ITP - molmol
Justin Pryzby <[EMAIL PROTECTED]> schrieb: > Do you still intend to package molmol for Debian? If so, please > remember to keep the bugtracking system informed of progress and delays. Yes, I still intend to package it. There are two things that delay it: - There are some minor problems with lesstif. However this isn't really important, since it will probably have to go to non-free anyway, so I can use openmotif. - I am still awaiting a response from the copyright holders; with the current license, we need a permission to distribute modified versions. I hope they'll change it, but in any case I have to wait for a reaction. The interaction with the copyright holders hasn't been copied to the bug, because the main person involved actively refused to use electronic communication... Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#241235: ITP: primer3 -- [Biology] Tool design flanking oligo nucleotides for DNA amplification
Steffen Moeller <[EMAIL PROTECTED]> schrieb: > Package: wnpp > Severity: wishlist > > > * Package name : primer3 > Version : 0.9 > Upstream Authors : Steve Rozen, Helen J. Skaletsky > * URL : http://www.example.org/ > * License : other - distribute freely, keep copyright, mention > patches > Description : [Biology] Tool design flanking oligo nucleotides for DNA > amplification Sollte das nicht verständlicher "A Tool to design ..." heißen? > Comments and a sponsor are welcome. Ich bin sehr interessiert. Hier einige Anmerkungen: - viel unnötiges in debian/rules: Die auskommentierten Zeilen können weg, genauso das configure-target. - Bist du dir sicher, dass binary-indep für arch-any Pakete immer aufgerufen wird (also auch z.B. von buildd's)? Ich würde primer3.1 lieber zum prerequisite von build machen. - es fehlt eine build-dependency: , | fakeroot debian/rules binary | docbook-to-man primer3.sgml > primer3.1 | /bin/sh: docbook-to-man: command not found | make: *** [primer3.1] Error 127 ` Am besten siehst du dir mal das pbuilder-Paket an, damit kann man das recht gut überprüfen. - Hast du mal mit den Autoren gesprochen, was die Lizenz angeht? Mir scheint, dass das, was sie wollen, sehr gut auch mit einer DFSG-freien Lizenz zu erreichen wäre. - Willst du selbst Debian-Developer werden? Gruß, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#188167: ITA: netenv -- Configure your system for different network
Paul Telford <[EMAIL PROTECTED]> schrieb: > You wrote: >> However, I still think we should give the upstream author time until the >> end of the summer holidays. If 0.94 hasn't been released by mid august, >> I suggest, I will ask my sponsor to upload the packages as they are with >> the (publicly unused) version number 0.93. > > > Hi Frank, > > Have you heard any news? With the recently announced sarge release > schedule [1] it would be great to see this new package fix some of the > outstanding bugs soon. Yes, netenv-0.94 is out, and my package is practically ready. Bernhard Link ([EMAIL PROTECTED]) has agreed to sponsor it and is reviewing my work currently. Basically he was satisfied with it, he only questioned wether I should use debconf to configure it (as I did) or wether to simply disable it before the user configured it manually, based on examples I provide. You can get and review the packages at http://www.kuesterei.ch, if you like. The Debian revision 1.1 is because I made the mistake not to start with 0.x for the first try I sent to Bernhard. I had some hits on these files in my weblog, and therefore I wanted to indicate that something has changed. Thank you - I'm glad to hear that people are interested in the package. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#188167: ITA: netenv -- Configure your system for different network environments
Paul Telford <[EMAIL PROTECTED]> schrieb: > Is there any status update on this package? We are waiting for the 0.94 release to come. When Yooseong (Yooseong, are you subscribed to the netenv package package tracking list? To be sure, I put you into Cc:) said he would take it, I stepped in (saying I had new packages nearly ready, and contacted the upstream author), and we generally agreed that I should upload the packages with the help of a sponsor. I had prepared the packages based upon version 0.94 which is not yet released, but bug-free AFAIS. The upstream author said (at the end of April or early May) it would be ready within weeks, this is why I decided to wait. Since more and more people are getting impatient, see #114594 and #97944, action should probably be taken. However, I still think we should give the upstream author time until the end of the summer holidays. If 0.94 hasn't been released by mid august, I suggest, I will ask my sponsor to upload the packages as they are with the (publicly unused) version number 0.93. Yours, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules
Package: wnpp Version: N/A; reported 2003-07-03 Severity: wishlist * Package name: molmol Version : 2k.2.0 Upstream Author : Reto Koradi <[EMAIL PROTECTED]> et al. * URL : http://www.mol.biol.ethz.ch/wuthrich/software/molmol/ * License : non-free (academic type "use me, but cite men in publications") Description : Display and analyze structures of biological macromolecules I'm not a Debian Developer - thus would need a sponsor. In fact the package is quite ready, but the license and distribution permission have to be clarified with the authors. Bye, Frank -- System Information Debian Release: 3.0-bunk-1 Architecture: i386 Kernel: Linux alhambra 2.4.19 #1 Sam Apr 26 21:34:01 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#188167: I would have also taken it, feel free to make use of what I've done so far
Hi all, found out now, fixed it. Please find working files on http://www.kuesterei.ch Please apologize for any inconvenience, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#188167: I would have also taken it, feel free to make use of what I've done so far
Dear all, something weird has gone wrong. As you might have noticed, the files I have uploaded for your inspection are messed up, because somehow a native package has been built. I have been very buisy this week, so I just uploaded what I found in my netenv directory. I have not yet found out how this comes, excuse me. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Bug#188167: I would have also taken it, feel free to make use of what I've done so far
Dear Yooseong, (and dear Mattia) I was also intending to adopt the package (I had in fact contacted Robert van der Meulen some weeks ago). Since I am not yet a Debian developer, I asked a developer I knew (Bernhard Link) wether he would sponsor it. He agreed in principle, only asked me to change its maintainer scripts to use debconf. I've done that in the past weeks, and also contacted the upstream developer, cleared some questions and packaged the new version. The package is near ready, the only thing is that I haven't set up pbuilder yet and only built it on woody. Therefore, I have not contacted Bernhard again (which I do now by Cc-ing him). Also, I have not yet signed keys with anybody. If you like, we can combine our efforts. Anyone could sponsor me taking it over, if you think that is less work for you (or because you want to introduce someone new to Debian), or I could just hand over what I've done so far to Yooseong (or anybody) - you may freely use everything, of course. I have put what I have done so far on my web page, http://www.kuesterei.ch/. There is one peculiarity about this: Upstream numbered the pre-release-Versions of 0.94 just as we number Debian Versions: 0.94-1, 0.94-2. Therefore I decided to use the (publically unused) version 0.93 for the pre-0.94 stuff. The packages for 0.94 that are also on the web page are my very first try, the ones I gave to Bernhard first. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
