Bug#4447: manfnt.mf missing in mfbasfnt-1.05
Package: mfbasfnt Version: 1.0-5 I uploaded 1.0-6 a while ago and it should be fixed it that one.
Re: Do we ever retire packages?
Remove them. Move them to project/obsolete or some such. Better would be to restructure the archive somehow and name things correctly. I 'm still think something like this would be better: stable/ /admin /base /comm ... stable-extra/ /contrib /non-free - .../non-free /obsolete /experimental /and other names which don't fit in the above unstable/ /admin /base /comm ... unstable-extra/ /contrib /non-free - .../non-free /obsolete /experimental /and other names which don't fit in the above This will leave us two main entries for all the packages in a distribution. The problem with stable and unstable non-free/contrib packages will disappear (they will be included in the releases approach we are following). non-free and contrib will get the same status as the other sections like base, admin and comm c. This will make the structure far more consistent. Erick -- Christopher J. Fearnley|Linux/Internet Consulting [EMAIL PROTECTED], [EMAIL PROTECTED] |UNIX SIG Leader at PACS http://www.netaxs.com/~cjf |(Philadelphia Area Computer Society) ftp://ftp.netaxs.com/people/cjf|Design Science Revolutionary Dare to be Naive -- Bucky Fuller |Explorer in Universe
Bug#4447: manfnt.mf missing in mfbasfnt-1.05u
Package: mfbasfnt Version: 1.0-5 I uploaded 1.0-6 a while ago and it should be fixed it that one. Sorry I noticed that it was rejected because of a bad checksum. Currently uploading 1.0-7. Erick
Re: devel directory reorg?
I'd prefer a non-hierarchical reorganization personally. While none of the ten thousand scripts that run on master should break, I'm sure they all will. I prefer a non-hierarchical reorganization as well but I suggest that the section directories are listed in one file per Distribution and that all scripts read this file first before doing anything. Adding the name of that one new section will work for all scripts relying on the information about what sections exist. This is kind of similar how the Packages file are right now (in a way). Erick
mfbasfnt 1.0-6 uploaded (Urgency: HIGH)
-BEGIN PGP SIGNED MESSAGE- Date: 23 Aug 96 16:34 UT Format: 1.6 Distribution: unstable Urgency: High Maintainer: Erick Branderhorst [EMAIL PROTECTED] Source: mfbasfnt Version: 1.0-6 Binary: mfbasfnt Architecture: all source Description: mfbasfnt: TeX's default fonts and a few others. Changes: Fri Aug 23 18:12:19 1996 Erick Branderhorst [EMAIL PROTECTED] . * added black, committee, gray, half, logo, manualfonts, mfbook, slant from ftp.tex.ac.uk /pub/tex/archive/fonts/cm/utilityfonts/ * manfnt.mf was missing in previous relaease causing initex going bezurk when generating .fmt files . Files: 4103e616a218b77baa4bfaa07cfbbf99 202020 tex - mfbasfnt-1.0-6.tar.gz 4fbf5dc5a00b2156305d9a3d5483ceb5 168724 tex standard mfbasfnt_1.0-6_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMh3d3aXl16B8emrRAQE9tAP/UdIgEVJw53lSUsETi/TPOS2DDUleqUvW V2crLkLDdaLCXiTusVAJ0+PIASmnPJzJbcZzGNYBQh+tKwe8x6xm5zm3p8roiiyp jBEVDBQmkf9T4p4qChmATeZYo/vP9SuN8kNC+oMADS9SdCRQLkWS4JHoD6xX0q6/ TfsQM+YkM8A= =sLD3 -END PGP SIGNATURE-
Re: Bruce - fiat required to end discussion on lyx/copyright ?
All packages in the Debian distribution proper must be freely useable, modifiable and redistributable in both source and binary form. It must be possible for anyone to distribute and use modified source code and their own own compiled binaries, at least when they do so as part of a Debian distribution. This can't be done with nearly all (la)tex related style files. When one wants to change a (la)tex style an other named copy can be used but the original may not be touched. Do we really want to ditch (la)tex? Erick
Re: Releases other than by the package maintainert
Non-usual-maintainer updates, hello-1.3-8 - hello-1.4-0.1 Usual-maintainer updates, hello-1.3-8 - hello-1.4-1 Usual-maintainer should never use -0 for revisions. And if we agree on this, it should be mandated in the manual. I think this seems reasonable. I propose to mandate it. Any objections, considerations ? Doesn't this open up the file naming question again. I.e. before we could say definitively that xxx_yyy-zzz.aaa STOP STOP, MY MISTAKE (I meant _) SORRY SORRY, let's continue. Erick
Upstream maintainer in control file
Hi all, I got a request from Jim Meyering (gnu maintainer shellutils, textutils, fileutils etc.) whether or not he could get the bug-reports filed against his packages. I asked Ian J. about this but he couldn't come up with something more than adding the mainstream maintainer in the maintainer field. He said that isn't a good suggestion and I think that it isn't as well. Nevertheless I think that we can solve this by Adding an optional field to the Source part of the new control file: Upstream or Upstream-Maintainer with his/her preferred mail adress and optionally the name of the Maintainer. Sometimes it is difficult to point to the upstream maintainer because it is a large group of people. If this Upstream-Maintainer field exists the bug report system should add an small informative message to the bugreport and sent it to the Upstream-Maintainer. Opinions? Suggestions? Anyone? Ian? Erick.
Re: Releases other than by the package maintainert
(b) that the non-usual-maintainer releases should use a particular revision format: eg, hello-1.3-8 would become hello-1.3-8.1. Seems very right to me. But I would like to add the following to it. When mainstream is updated, hello-1.3 - hello-1.4 Non-usual-maintainer updates, hello-1.3-8 - hello-1.4-0.1 Usual-maintainer updates, hello-1.3-8 - hello-1.4-1 Usual-maintainer should never use -0 for revisions. And if we agree on this, it should be mandated in the manual. Erick sorry for cc
Bug#3961: 14 character file name limit in zoo
As zoo comes from DOS I'm not sure if it would be a good idea to support long filenames. If this is a valid argument for you you might restrict to 8.3 . E
Bug#4006: Fileutils has /usr/libexec directory
Package: fileutils Version: 3.13-2 The fileutils package has an empty /usr/libexec directory in the .deb file. I don't think the FSSTND supports libexec yet, so the directory should be removed. This dir is standard by make install in gnu packages and didn't see any harm so will not do an update just for removing this dir if you don't mind. If someone can come up with serious problems having this empty dir in the package I'll remove it. Erick
Re: 1.2 source archive and packaging issues
I also think that's important. The source packages should be very simple, and the source unpacker/packer should be written in a scripting language. tar xzf source-version.tar.gz mv source.version source.version.orig tar xzf source-version.tar.gz cd source.version zcat ../diff-version-revision.diff.gz | patch the above lines aren't very difficult but we need to continue with a few checks IMHO: dpkg --status various packages needed for building this package should be installed ok From what I've gathered, the rpm format for sources is basically lines of text giving control information, followed by a cpio of all the gzipped tars. The control field gives commands to do things like unpack, build, etc. Because we already mandate commands for debian.rules, such complexity is not needed. This program (dsource?) would know that it just needs to run debian.rules build to build, debian.rules dist for a distribution, etc. The only information in the control field is how to unpack. Not only how to unpack, but also a possibility to download the original sources (so an URL to the original sources at the original site should be provided). The copyright field which comes with rpm might be usefull too, in the debian source handling approach. We might construct a automatic /usr/doc/copyright/package file by using this copyright field, the maintainer information, the url to the original sources, the organization where the package comes from, the package name the revision name, the changes made for this revision from debian.Changelog and the contents of debian.README (which would contain other info than it does right now, only the copyright info from the original sources). All this can be translated into some machine created sentences like: ---/usr/doc/copyright/package This is the Debian Linux prepackaged version of the organization package distribution. This package package-version-revision was put together by maintainer, from the organization sources, which were obtained from source-url. The changes for revision revision are listed below: revision changes The debian specific changes are copyrighted by maintainer and put under the gpl (see /usr/doc/copyright/GPL). The original sources from organization/author are put under the copyright license. contents debian.README ---/usr/doc/copyright/package Additionally we need the possibility to use more than one source (tar.gz) file. Example is web2c and kpathsea and those big things. So we need more than one source field and related debian diff field which specify the patches to be applied at the original sources. Unix: 30 definitions of regular expressions living under one roof D.E. Knuth Erick Branderhorst http://www.iaehv.nl/users/branderh/
textutils very big m68k
The textutils package in the Incoming dir on master for the m68k architecture is 1.1 meg big, much bigger than the ?? k under i386. Is this normal or did something went wrong during building, I would like to know because I'm maintaining the thing right now. Can't download it myself, because I'm using a paid line of 14k4, so that would take at least 10 minutes to download the thing. Can someone tell me what happened with this (dpkg --contents text*) Unix: 30 definitions of regular expressions living under one roof D.E. Knuth Erick Branderhorst http://www.iaehv.nl/users/branderh/
Re: 1.2 source archive and packaging issues
[EMAIL PROTECTED] (Erick Branderhorst) writes: I don't think it can be done this way, because a lot of makefiles are organized in a way that they require the installer to be root at the moment of installation, or am I misinformed? Perhaps fooling install might be an option? What do you mean by require the installer. We don't use make install for the final install anyway, and if you're worried about the I use make install in a lot of the packages I maintain because this is the closest to the mainstream installation. And we want to provide users the most close to mainstream installation but then better. [deleted stuff about dummy-installer] Reasonable? Makes a lot of sense to me, can you hack install to do such a thing? Unix: 30 definitions of regular expressions living under one roof D.E. Knuth Erick Branderhorst http://www.iaehv.nl/users/branderh/
