bug reports (was: Re: md5sum passwords)
On Wed, 15 Nov 1995, Daniel Quinlan wrote: > Open input is good, in general. If you want to guarantee haggling, do > it on a mailing list. If you don't want haggling, have input sent to > a responsible party. Good point. I agree. General distribution of bug reports is a useful option, but shouldn't be the default. > [...] If you want to speed things up, I suggest these initial steps: > > - Send bug reports only to the maintainer, mirror them on a WWW-site. >(A good example -- http://www.cogs.susx.ac.uk/cgi-bin/ltxbugs2html) >Maybe also send them to packages that are related. Mirroring >the bugs to debian-devel was a stupid idea from the beginning, IMHO. Mirroring bug reports to debian devel was done because it was convenient, I think. Bug reports weren't, and still are not, sent to package maintainers because that is inconvenient to implement. I've said, and I still think, think that it'd be a good idea to deal with that implementation inconvenience in the intrests of effectiveness. > - Try to send comments to the maintainer, unless it's something that >really concerns everyone. Bug reports should go directly to the maintainer, I think. The very long list of un-actioned bug reports indicates to me that either bugs aren't being dealt with very well or that many maintainers are very delenquent in closing completed bug reports. I think we have both of those cases represented. I'd like to see this list still appear on debian-devel, but be sorted by maintainer with a subsort by package. I think that'd be much more useful, if a bit less convenient to implement.
Bug#1865: cmr10 at 10.0pt not loadable: Metric (TFM) file not found.
Package: kpathsea
Version: 2.6-1
LaTeX did not work after I purged the old TeX packages and installed the
new ones. This is what happened:
$ latex 951115.tex
This is TeX, Version 3.1415 (C version 6.1)
(951115.tex
LaTeX2e <1995/06/01> patch level 1
(/usr/lib/texmf/tex/latex/latex209.def
Entering LaTeX 2.09 compatibility mode.
(/usr/lib/texmf/tex/latex/tracefnt.sty)
(/usr/lib/texmf/tex/latex/latexsym.sty)
kpathsea: Appending font creation commands to missfont.log.
! Font OT1/cmr/m/n/10=cmr10 at 10.0pt not loadable: Metric (TFM) file not
found
.
relax
l.355 \selectfont
?
I set KPATHSEA_DEBUG=63 and tried again. It looks like kpathsea is looking
for cmr10.tfm in the path=.:/var/spool/texmf/fonts/tfm//
:/usr/local/lib/texmf/fonts/tfm//:/usr/lib/texmf/fonts/tfm//.
Unfortunately, the textfm package puts the font metric files in
/usr/lib/texmf/fonts/metafont/tfm/, not /usr/lib/texmf/fonts/tfm/.
I was able to get latex and dvips working by symlinking
/usr/lib/texmf/fonts/metafont/tfm/ to /usr/lib/texmf/fonts/tfm/.
I'll append the compressed debugging log.
Matt Birkholz <[EMAIL PROTECTED]>
PGP 2.6.2 Public Key ID = 74305425
Key Fingerprint = B3 34 FB 3E 3C FE E8 57 AA B4 B2 95 A7 C0 1E AF
Finger [EMAIL PROTECTED] for key. (Note missing "z"; thank you, Primenet.)
begin 660 kpathsea.log.gz
M'XL("`.6J3```VMP871HOX(`^)$"J#Z?)DJ#I
MT&U--ZQIBB4;[EMAIL PROTECTED]&7*)D*1*D4GSG[]2,FV1$IR13+]>[EMAIL
PROTECTED]>\[AU;V7
ME[+D9P"M"L8%^./#ZYO?KM^\OOWUS<]_O3T_/@R>`0(%6H'3HR1)CD+Y:W`W
M0]/E_.P:09XN0`'%`F2,@S"E&<@P0278RSC+0<@"+
[EMAIL PROTECTED]"IZ1S$S;#J8`J%`DT9S?"\4EY/YASL44912VI%5
M=B91\^XI-YQO$0Y`OBS%+5KA4IPG!]))='8+"5&_JVF>]T]R/[EMAIL PROTECTED](
M7I<0G+\"[EMAIL PROTECTED]&#>\['AF:MW+WI<7ZU`*6BUO"V-VRV+MY\_'RXMW56W5:
MSGI)R'[0B]OQ7,8*1/=VCST`O`*.5X?9BSC>7J4L):Q$>[EMAIL PROTECTED](#
M8R^N_KQ\?7-=&81GSRKK"%/L`MW)[EMAIL PROTECTED]"WZ@;3MZOQJR=I//BIE
M-8LF8:67GC)AS1F,R%;C(O_^_L-?ZY!X5M7K";[EMAIL PROTECTED]=J"
M6C!&1L2893W]AM5T;"T=5TF5>[ZG4GIQ>7'UOEE<*^TB+R+EW#(26:[JW#;N
MM:.U7UJ'[EMAIL PROTECTED]&[EMAIL PROTECTED](9BS0.]5;([H._4YYJ'
M)[D.7[/A>"[EMAIL PROTECTED]/JS.]=5D[/)B*B65=OK@VK/(VM3L6'I;?E(^
M_[/I\[>ALFL'(T%[]B_RJ+E[V0I7Z#W#M^=W*M1&:EL2>!+W^:O9T(]VV%,T
M0(VCUV(:'4IR&'5O--3S;9_1YG?:S*\>N1Y'V/P`/#3C4KDU:[$%[Z",M`D"
M+Y/3TZ,H/H[BY)6:[EMAIL PROTECTED]:0*]$V:3^#2'=\9=U7$_4]1'(B?>M#8.T
M=?00L6IOD]<`,\QO":9WY5CSYXD=MZ@<[\%N`%CR%QP1!F?N_":`)3_D`J<$
MA2DIW?A-`$O^J3SO3JY9VUYY)`3B[MR&O77<4?10>K#K]M;[EMAIL PROTECTED]>WOV
M^5+V05[\.H)UUOG,7K.V9.9(W>YVYS;L+=E+(IWF$76&O6VNWR6QM&6.N=ZV
MMF=.O)@3#^:)%_/$E3DCZ!-UI];-K6OK)\KQ/`DA]G8H&H.[UA;UOCU=_E8^[.
MWT%PZ^#=^75[2_8'1S2^XYA\6B@([EMAIL PROTECTED]'A5,Q\=CR&?:V=?_RG5_=
MU^VMV:\]V:\]V-6S`2B''OP=!%L%98JQ![UF;LF=%B\.?W3GULVMN4^.8A_N
MMKG]>H]IXK7:M^U=V">>[!-GOV?S^E,>@[EMAIL PROTECTED]"K0)2^BHP$>SO[96"X\)=
[EMAIL PROTECTED],''02WCL.9W["W77/E)[EMAIL PROTECTED]:L/>99\A1_OP&PA.
MGY#'B8<"$\%-P<1;P<13P:&[EMAIL PROTECTED]:M#3#/FH\!`L%>0+E!ZYZ5`1["]T\MF
[EMAIL PROTECTED]9QX^*"[EMAIL
PROTECTED]&@"T_6_+4SP,F
[EMAIL PROTECTED]'00+!7(XYZ9T$%H%.QZIK4!4$\7#I_=8+6?<&W=ZQIU4VR#
MT?NT:[^)]ECH2?]CK_KX;[EMAIL PROTECTED]&,Z!]6#LF`2QJ?5\^AR,S'%
M!(M'(.LI,F=5OS_:NK'\;9ULWN(>=2]\I)/U6;:<_&/<&WK_>V5'Z&F2AO)V
M_2GU=Y"WK<_+=V?3>J!-WFYG^?F0^M\K`1CY9$.?^]*<)[%Z[V6,[[[0JT^-
M)[6U?YA-B9XHT;N7_K$``[W'3O,33_H3+_9C3_;C'G:]Z]EQJ:N^9_C\CBYJ
M.#I`\Z;&KNZKWV(=S]M0WN^>VWRG0_V17PZ+,5_K\,7#O?GRAJVNMO9V/&B3
M,ZYZ9US/F+J^Y'B]^:K>#()-&3E5Q;[EMAIL PROTECTED]([EMAIL
PROTECTED]>J<:G>ETPY6CS)F">
[EMAIL PROTECTED]"@#14&[EMAIL PROTECTED]@V]NDE4?$5Y1*,[EMAIL
PROTECTED])([7$A`&4"J)=$X)2@,W")
M!,O%ZKS&5O261`&+R7)%`')/0-P#C%]!0+0_<,[EMAIL PROTECTED]/#PZ`C\
M4\K`2872U1T;_`0^!N\94/N.$K`,L*4HEB(,;CBD9
Announce: libgdbm-1.7.3-2
Note: this version is made to cooperate with David's new ELF packages and the new directory structure (ELF libs in /usr/lib; a.out libs in /usr/i486-linuxaout). Changes since elf-libgdbm 1.7.3-1 * Renamed to libgdbm. Added 'Provides: elf-libgdbm' to control file. * Use /usr/ instead of /usr/i486-linuxelf; part of Debian's move to ELF. * Added 'Depends: libc5'. This also fixes Bug#1761. * Changed symlinks for shared libs. GNU dbm is a set of database routines that use extendible hashing and that work similar to the standard UNIX dbm routines. This package contains both the static and the dynamic libgdbm. It should go into project/experimental/elf. adb20616838bd48fbcb41b76ae6937b4 libgdbm-1.7.3-2.deb 52131aceb354c448a0aa2e784e070418 libgdbm-1.7.3-2.diff.gz 60c628468f341de322236743b7c822d1 libgdbm-1.7.3-2.tar.gz -rw-r--r-- 1 root root39499 Nov 15 07:58 libgdbm-1.7.3-2.deb -rw-r--r-- 1 root root10700 Nov 15 08:00 libgdbm-1.7.3-2.diff.gz -rw-r--r-- 1 root root81381 Nov 13 18:21 libgdbm-1.7.3-2.tar.gz Ray -- J.H.M. Dassen | RUMOUR Believe all you hear. Your world may [EMAIL PROTECTED] | not be a better one than the one the blocks [EMAIL PROTECTED] | live in but it'll be a sight more vivid. | - The Hipcrime Vocab by Chad C. Mulligan
Bug reports by maintainer and package
Below is a listing generated by a new version of the bug summaries script. What do people think of it ? I currently have the following crontab entries for generating bug summaries to debian-devel: 23 16 * * 5 /home/iwj10/things/debian-bugs/scripts/mailsummary undone 23 16 * * 2 /home/iwj10/things/debian-bugs/scripts/mailsummary veryold I'm inclined to replace the Wednesday posting of only the very old bug reports with this new listing by maintainer and package, and to leave the full reports sorted by age on Friday. The reports sorted by age now list the package maintainer where the originator used to be. It's interesting to note that the people who are most involved with the critical parts of the project are also those with the most outstanding bug reports against their packages. I think I shall be following Ian M.'s lead and asking for some volunteers ... Ian. Package Ref Subject Nils Rennebarth <[EMAIL PROTECTED]> (1 bugs): gpm 1669 shutdown hangs on gpm -k until mouse is moved [EMAIL PROTECTED] (Guy R. Thomas) (1 bugs): dld 1488 dld control file dsccription problem Erick Branderhorst <[EMAIL PROTECTED]> (1 bugs): hyperlatex 1719 hyperlatex recommends ghostscript - nonexistent package Robert Read <[EMAIL PROTECTED]> (1 bugs): ftape1615 ftape package contains only source Giuseppe Vacanti <[EMAIL PROTECTED]> (2 bugs): diald1611 Diald 0.10 man pages diald1613 diald: minor typo in config-script Robert Sanders <[EMAIL PROTECTED]> (2 bugs): strace 1205 strace doesn't compile with newer kernel sources strace 1539 strace source package does not compile [EMAIL PROTECTED] (David H. Silber) (2 bugs): fortune 1118 fortune is setuid games ?! uucp 1265 Misc. uucp bugs Christian Linhart <[EMAIL PROTECTED]> (2 bugs): tgif 1821 tgif should read /etc/papersize xarchie 1857 xarchie doesn't honour default archie server setting Kenny Wickstrom <[EMAIL PROTECTED]> (2 bugs): tin 1619 tin depends on inn | inewsinn | inews tin 1753 trn recommends, instead of depends Helmut Geyer, [EMAIL PROTECTED] (2 bugs): ghostview1225 ghostviewR6 bad name, depends on xbaseR6, ghostviewR5 exist xxgdb1231 xxgdbR6 bad name, depends on xbaseR6, xxgdbR5 exists Dirk Eddelbuettel <[EMAIL PROTECTED]> (2 bugs): acct 1737 missing man pages for accouting commands acct 1738 `errors' in /usr/info/accounting [EMAIL PROTECTED] (D.J. Gregor) (2 bugs): cdtool 1322 cdtool: wrong permissions for manpages workbone 1381 workbone postinst fails Matt Porter <[EMAIL PROTECTED]> (3 bugs): lrzsz1635 revision should be package_revision lrzsz1727 Man-pages lrzsz1729 Naming of commands [EMAIL PROTECTED] (Robinson, Jim) (3 bugs): ifrench 1233 Bad french.hash file in ifrench.deb igerman, w 1793 german.hash has wron magic number wenglish 416 perl doesn't flush output automatically Kenneth MacDonald <[EMAIL PROTECTED]> (3 bugs): ispell 1627 ispell copyright file ispell 1715 ispell recommends word-list - nonexistent package linuxdoc-s 1830 version of doc behind linuxdoc package [EMAIL PROTECTED] (D.J. Gregor) (4 bugs): gnuplot 1662 gnuplot won't run xfig 1224 xfig depends on xpmR6, xbaseR6 xfig 1408 xfig always asks about colour/mono xfig 1453 `xfig' should depend on `X11R6' Alvar Bray <[EMAIL PROTECTED]> (4 bugs): man 1735 apropos(1) segfaults man 1751 corrupt man page for dc man 1805 man package problem man 1841 man_db problems David Engel <[EMAIL PROTECTED]> (4 bugs): expect 1836 expect core dumps ldso 1646 ldso (or dpkg) "bug" snmp 1820 snmp postinst backgrounds start-stop-daemon ? snmp 1824 snmpd not killed by pre/post-rm, ignored SIGTERM Michael Alan Dorman <[EMAIL PROTECTED]> (4 bugs): minicom 1636 minicom cant file /etc/minicom.users minicom 1661 minicom should use /etc for config files minicom 1679 Minicom has default lockfile in /var/spool/uucp minicom 1728 Depencies&Conflicts [EMAIL PROTECTED] (D.J. Gregor) (4 bugs): unclutter1779 unclutter - I need -noevents vim 1133 vim asks unnecessary and unclear question vim 1187 Various `vi' versions trample on each other. vim 1405 vim doesn't use update-alternatives Martin Schulze <[EMAIL PROTECTED]> (5 bugs): syslogd 786 syslogd gone awol syslogd 1474 syslogd uses default settings for update-rc.d syslogd 1531 syslogd continues to write to old file after savelog syslogd 1813 /var/log/news should exist syslogd 1833 [EMAIL PROTECTED]: patch for Debian sysklogd package] Anders Chrigstrom <[EMAIL PROTECTED]> (5 bugs): bison1553 Bison: #include problem bison1554 Bison: confusing documentation bison
Bug#1866: xwpe should depend on xcompat
Package: xwpe Version: 1.4.1-1 xwpe requires old X library (libX11.so.3) which is in the xcompat package. But xwpe does not "depend" on xcompat. Marek
Re: Bug reports by maintainer and package
Ian Jackson writes: Ian> Below is a listing generated by a new version of the bug summaries Ian> script. Ian> Ian> What do people think of it ? I like it and prefer it over the old format. Two small glitches: - Nils Rennebarth has two entries (the very first and a bigger one further down - An acct bug (#1738) is assigned to me even though I marked it done. It's not in last Friday's list. -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
OK, OK :-)
I accidentally deleted the test for whether the bug had been marked as done. Don't bother reporting this, ahm, interesting feature any more. I'll fix it and produce another list. Any other comments that people haven't made yet ? Ian.
Bug#1867: [hag@gnu.ai.mit.edu: a little bit of flamage about single user mode]
Package: sysvinit Version: 2.57b-1 --- Start of forwarded message --- Date: Wed, 15 Nov 1995 01:03:29 -0500 To: Ian Murdock <[EMAIL PROTECTED]> Subject: a little bit of flamage about single user mode From: Daniel Hagerty <[EMAIL PROTECTED]> I know I saw some mail about this on debian-users a few weeks ago, but I must let you know this: The current debian system's concept of "single user" is seriously hosed, and tries to do way too many things that are inappropriate for a single user machine. Basically, a single user shell should finish booting the kernel, and give you a shell at that point. Root shouldn't even be remounted read-write. It certainly shouldn't try to ifconfig network interfaces, or mount remote nfs filesystems. The network interface one is particularly bad, you can seriously trash a network for 10-15 minutes while arp caches clear out and so forth. --- End of forwarded message ---
Re: md5sum passwords
Andrew Howell <[EMAIL PROTECTED]> writes: > Though it would be nice if the whole community switched I don't think > it's that great a deal whether they do or not, us using MD5 and others > using DES shouldn't lead to any incompatibilties or problems as far > as I can see. I asked Garrett A. Wollman (FreeBSD) about their experience using MD5 outside of the US, why they didn't switch to MD5 wholesale, etc. Garrett noted: > Because it's incompatible with every other UNIX system out there. > Lots of people need access to YP password databases, etc., and > therefore have to have the DES hash. > > Some people find the existence of two different password mechanisms > confusing. Some people find the fact that the `crypt' function and > library doesn't actually do encryption really confusing. > > Some programs use small fixed-length buffers to hold hashed > passwords, causing them to crash when used with the longer output > from the MD5 scheme. Before Debian actually switches to MD5, issues such as these must be resolved. Any use of fixed-length buffers to hold hashed passwords should probably be considered a bug, regardless. A mixed solution may be possible, supplying DES (from both a US and a non-US site) to those who require YP support. I'm still not in favor of Debian doing this alone in the Linux community, though. Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
Re: dselect CD-ROM / hard disk / NFS method
Bill Mitchell writes ("Re: dselect CD-ROM / hard disk / NFS method"):
> On Wed, 15 Nov 1995, Ian Jackson wrote:
> > If it sees what looks like a Debian mirror of some kind (possibly in a
> > `debian' subdirectory) and has `stable' and `development'
> > subdirectories it will offer the user the choice between the stable
> > tree and the development one, rather than requiring them to specify
> > the pathname themselves. (The user will still be able to specify a
> > different pathname if they want to.)
> > [...]
> > So, in summary, the script will look for trees named
> > stable
> > development
> > contrib
> > non-free
> > and in each tree will it look for
> > binary
> > and
> > binary/Packages
> > or
> > binary/Packages.gz
> >
> > It will look for these trees in the root of the installation
> > filesystem, or in a subdirectory `debian' of that filesystem.
>
> "it" is dselect, right? Unless I misunderstand, that's what it
> looks like to the user.
Yes. It's the dselect disk access method script, which is invoked by
dpkg when the user selects hard disk partition, mounted filesystem or
CD-ROM from the dselect access method list.
> Could we have a dselect(1) or dsleect(8) man page which explains
> such things as this, or points the user to another man page which
> explains them?
Well volunteered.
This ought really to go in the installation manual, in the form `to
get dselect to work well, download the following files into a
directory tree like this'. Perhaps you'd like to write an appropriate
chapter or section and send it to Ian M. ?
Ian.
Re: md5sum passwords
Andrew Howell writes ("Re: md5sum passwords"):
> Daniel Quinlan writes:
> > I think switching would probably be a decent idea, although it is not
> > of earth-shattering importance to me. I'm also concerned about doing
> > Debian doing it alone, instead of with the cooperation of the rest of
> > the Linux community.
>
> Though it would be nice if the whole community switched I don't think
> it's that great a deal whether they do or not, us using MD5 and others
> using DES shouldn't lead to any incompatibilties or problems as far
> as I can see.
Don't many programs have built in limits like 8 on the length of a
password, and 13 or whatever it is on the length of an encrypted
password ? I don't see the point in switching.
> > I am more interested in longer user names and longer password. I'm
> > disgusted with being limited to eight characters.
>
> Yes, MD5 obviously makes the system that much more secure from attempts
> at using crack on a passwd file. MD5 being much slower than DES and also
> just the fact that you can't count on the password being 8 characters long
> anymore would make it a quite a more difficult process.
It's very hard to get people to remember a decently-long secret. For
this reason longer passwords aren't in general going to make for
better security.
What we should do instead, IMO, is to keep a secret cookie in a
read-protected file and use that as part of the data when hashing the
password (we can use MD5 or DES or SHA or whatever, though if we use
MD5 we'll have to truncate the result).
Programs that can read the file would just use it; programs that can't
would consult a system daemon to do the crypt() for them.
The effect of this would be that the cracker would have to use your
daemon to do all the crypts - which makes cracking infeasible - and
that *no programs would even need to be recompiled*.
We have 13 characters available, and 2 of these are known to be the
salt. Each character yields 6 bits with a sensible encoding, so we
have 12 bits of salt and 66 bits available for the encrypted
passwords.
The salt is less important if we constrain the potential cracker to
use our daemon, so we can keep some of it (4 bits perhaps?) as an
index number into a smallish table of secrets, so that we can change
the secret without having to have all the users change their passwords
at once.
Daniel Quinlan writes ("Re: md5sum passwords"):
> I am more interested in longer user names and longer password. I'm
> disgusted with being limited to eight characters.
Longer user names is pretty much a lost cause at this late stage, I
think. Feel free to try, but expect a lot of problems. Longer
passwords are difficult too, and even 8 lowercase alphanumerics are a
bit over 40 bits of entropy: this is fine to prevent guessing if the
attacker can't run an off-line search. If you use case and
punctuation too you can get around 50 bits, which is pretty good for a
login application.
Getting people to remember even 40 bits worth of password is the real
problem; we should be concentrating on ways to get good use out of
even 20 or 10 or less bits of randomness - and the way to do this is
to ensure that attempts at password searching have to go through
something you control.
> A little reading on using MD5 instead of DES turned up a FreeBSD web
> page on the topic.
>
> http://www.freebsd.org/handbook/handbook68.html
The FreeBSD web page seems to say to me that they made the decision to
use MD5 instead of crypt because of the export control issues. It
seems that the Linux community in general has taken the view that
since it is no more practical to use crypt than MD5 for
confidentiality it is silly to replace one with the other (the US
government view is - broadly speaking - that integrity and
authentication is OK whereas confidentiality isn't, which is very
silly when you try to apply it to algorithms: there's a standard way
to turn a hash function into a block cipher).
I think we should continue to provide a crypt()-like interface, and I
think my plan above is a way to significantly improve our security -
bringing it up to the level of systems with shadow passwords - without
the pain of recompiling every binary.
(The scheme also allows users to check their own and each others'
passwords, so that screenlocker programs &c don't need to be trusted
by the sysadmins. This feature could be disabled simply by not
running the crypting daemon.)
If people think this is a sufficiently good idea I might even be
persuaded to implement it, just so I can write a paper about it :-).
Re: md5sum passwords
Daniel Quinlan writes ("Re: md5sum passwords"):
> Bill Mitchell <[EMAIL PROTECTED]> writes:
> > This might be a bit harsh WRT the distribution itself. Too much
> > open input can lead to a lot of haggling over diverse viewpoints on
> > this or that alternative (not that we haven't had a bit of that
> > anyhow).
>
> Open input is good, in general. If you want to guarantee haggling, do
> it on a mailing list. If you don't want haggling, have input sent to
> a responsible party.
>
> Most Debian contributors seem to think every issue concerns everyone,
> everyone debates on everything, everything goes very slowly. If you
> want to speed things up, I suggest these initial steps:
I don't think we have a problem wrt slow response to bug reports
because of the comments people make about them.
On the other hand, I think there have been a number of times where the
only reason we made the best decision about how to fix a particular
problem was that another not-obviously-related developer saw the
report and perhaps the reply and was able to give good input.
It also allows any developer to pick off non-bugs, so that the busy
maintainer with half the distribution on their plate doesn't have to
deal with it.
I think the problems we've had with slowness have been due to lack of
manpower in some cases, and in many cases a lack of willingness to
part with things until they're perfect. One of Linux's selling points
is that the latest hottest thing - buggy as hell or not - is always
available if you want it. I think this really improves people's
motivation to help contribute.
Bill Mitchell writes ("bug reports (was: Re: md5sum passwords)"):
> On Wed, 15 Nov 1995, Daniel Quinlan wrote:
> > Open input is good, in general. If you want to guarantee haggling, do
> > it on a mailing list. If you don't want haggling, have input sent to
> > a responsible party.
>
> Good point. I agree. General distribution of bug reports is a useful
> option, but shouldn't be the default.
At one point I agreed with you, but I've come to disagree.
I don't think the general distribution of bug reports has been
unhelpful.
One thing we could do is to set up a seperate list that gets copies of
all bug reports, and have the developers decide individually whether
to see all of the reports rather than having the submitter decide
whether to distribute it generally.
Speaking as the dpkg maintainer I find that many bug reports touch on
my area in some way, and I reply to a significant number of them. I
wouldn't want to lose the ability to do that.
> Mirroring bug reports to debian devel was done because it was
> convenient, I think. Bug reports weren't, and still are not, sent
> to package maintainers because that is inconvenient to implement.
It's not so inconvenient now as it was, and it could be done.
Ian.
Re: md5sum passwords
Daniel Quinlan writes ("Re: md5sum passwords"):
> 1. Release a new copy. Make it very public.
>
> It has been my experience that contributors are more apt to continue
> contributing if things aren't kept so private and are updated often.
I agree entirely.
> - People like to see the results of their work
> - People like to contribute to projects that are moving forward
>at a significant pace or are updated often.
> - People don't like to repeat work. Knowing the status of things
>means that you won't repeat work.
> - The urge to work is often the result of seeing something new that
>you have strong feelings about (positive or negative).
>
> 2. Stop calling it a draft, call it a work in progress.
I agree here too.
It's critically important to get things out of the door quickly. We
can revise them later - especially with manuals, for example.
Ian.
Re: New a.out/ELF development packages
On Sat, 11 Nov 1995, David Engel wrote: >[...] > 3. Start converting other packages to ELF. What's the protocol for package uploads from here on out? Upload a.out packages? Announce where? Upload elf packages? Announce where? If both a.out and elf packages are to be uploaded, how are uploaders to differentiate one from the other?
ELF packages
I've moved the new ELF packages that David and Ray are working on to /debian/private/project/elf. As soon as they give the word, I'll move them into the distribution. For now, I urge everyone to upgrade their copies of gcc, libc, etc., as we're going to start wanting to building ELF packages fairly soon.
Re: New a.out/ELF development packages
Bill Mitchell writes ("Re: New a.out/ELF development packages"):
> On Sat, 11 Nov 1995, David Engel wrote:
> >[...]
> > 3. Start converting other packages to ELF.
>
> What's the protocol for package uploads from here on out?
>
> Upload a.out packages? Announce where?
>
> Upload elf packages? Announce where?
>
> If both a.out and elf packages are to be uploaded, how are
> uploaders to differentiate one from the other?
If you only want them to go into the 1.0 development tree (the usual
case) then you may upload one or the other, though ELF would be
preferred now.
If you want them to go into the 0.93 stable tree because they fix a
serious problem or for some similar reason you should say so and must
upload an a.out. If you have both a.out and ELF versions of the same
package I suggest you call them revision 3.1 and 3.2 or whatever - Eg,
hello-1.3-4.1 for the a.out and hello-1.3-4.2 for the ELF. This will
ensure that upgrades happen in the right direction.
Ian.
Re: ELF packages
> I've moved the new ELF packages that David and Ray are working on to > /debian/private/project/elf. As soon as they give the word, I'll move > them into the distribution. For now, I urge everyone to upgrade their > copies of gcc, libc, etc., as we're going to start wanting to building > ELF packages fairly soon. As far as I'm concerned, the aout-* packages are ready to go into the distribution. I'll be uploading new ELF libc5, binutils and gcc packages later tonight or tomorrow morning. The only change is that they explicitly "conflict" with and "provide" the elf-* equivalents. These should also be moved into the distribution. I'll also be uploading an ELF gcc 2.7.1 package. I don't expect any problems, but this one should probably receive a little more testing before being moved. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Revised resorted bugs list
Right, I think I've fixed the bug that caused it to list bugs that had been marked as done. There is a file (well, three files actually) on ftp.debian.org that can override the Maintainer field from the packages in the archive; I've edited this a little, but there are probably still remaining problems. If you upload a revised package this file will automatically catch up; otherwise you can mail Ian M. or myself and we can edit the file. Ian. Package Ref Subject Nils Rennebarth <[EMAIL PROTECTED]> (1 bugs): gpm 1669 shutdown hangs on gpm -k until mouse is moved Dirk Eddelbuettel <[EMAIL PROTECTED]> (1 bugs): acct 1737 missing man pages for accouting commands Robert Read <[EMAIL PROTECTED]> (1 bugs): ftape1615 ftape package contains only source Matt Porter <[EMAIL PROTECTED]> (1 bugs): lrzsz1635 revision should be package_revision [EMAIL PROTECTED] (Guy R. Thomas) (1 bugs): dld 1488 dld control file dsccription problem [EMAIL PROTECTED] (D.J. Gregor) (1 bugs): unclutter1779 unclutter - I need -noevents Kenneth MacDonald <[EMAIL PROTECTED]> (1 bugs): linuxdoc-s 1830 version of doc behind linuxdoc package Robert Sanders <[EMAIL PROTECTED]> (2 bugs): strace 1205 strace doesn't compile with newer kernel sources strace 1539 strace source package does not compile Giuseppe Vacanti <[EMAIL PROTECTED]> (2 bugs): diald1611 Diald 0.10 man pages diald1613 diald: minor typo in config-script [EMAIL PROTECTED] (David H. Silber) (2 bugs): fortune 1118 fortune is setuid games ?! uucp 1265 Misc. uucp bugs Helmut Geyer, [EMAIL PROTECTED] (2 bugs): ghostview1225 ghostviewR6 bad name, depends on xbaseR6, ghostviewR5 exist xxgdb1231 xxgdbR6 bad name, depends on xbaseR6, xxgdbR5 exists Kenny Wickstrom <[EMAIL PROTECTED]> (2 bugs): tin 1619 tin depends on inn | inewsinn | inews tin 1753 trn recommends, instead of depends Alvar Bray <[EMAIL PROTECTED]> (2 bugs): man 1805 man package problem man 1841 man_db problems Martin Schulze <[EMAIL PROTECTED]> (2 bugs): syslogd 786 syslogd gone awol syslogd 1813 /var/log/news should exist [EMAIL PROTECTED] (D.J. Gregor) (2 bugs): cdtool 1322 cdtool: wrong permissions for manpages workbone 1381 workbone postinst fails Christian Linhart <[EMAIL PROTECTED]> (2 bugs): tgif 1821 tgif should read /etc/papersize xarchie 1857 xarchie doesn't honour default archie server setting (orphan) (2 bugs): inewsinn 1441 `inewsinn' should provide virtual package inewsinn 1752 inewsinn recommends trn Michael Alan Dorman <[EMAIL PROTECTED]> (2 bugs): minicom 1661 minicom should use /etc for config files minicom 1679 Minicom has default lockfile in /var/spool/uucp David Engel <[EMAIL PROTECTED]> (3 bugs): expect 1836 expect core dumps snmp 1820 snmp postinst backgrounds start-stop-daemon ? snmp 1824 snmpd not killed by pre/post-rm, ignored SIGTERM [EMAIL PROTECTED] (D.J. Gregor) (3 bugs): xfig 1224 xfig depends on xpmR6, xbaseR6 xfig 1408 xfig always asks about colour/mono xfig 1453 `xfig' should depend on `X11R6' [EMAIL PROTECTED] (Robinson, Jim) (3 bugs): ifrench 1233 Bad french.hash file in ifrench.deb igerman, w 1793 german.hash has wron magic number wenglish 416 perl doesn't flush output automatically [EMAIL PROTECTED] (Bill Mitchell) (4 bugs): ae 1724 unexpected keypress translations git 1848 git gets SIGV indent850 [indent] option mentioned in documentation not supported mtools 1355 mformat does not work Anders Chrigstrom <[EMAIL PROTECTED]> (5 bugs): bison1553 Bison: #include problem bison1554 Bison: confusing documentation bison1769 bison files in /usr/share sendmail 1437 Debian sendmail sendmail 1657 Sendmail uses flock instead of fcntl and is setgid root Sven Rudolph <[EMAIL PROTECTED]> (5 bugs): adduser 1534 adduser problems with home directories adduser 1711 adduser replaces NIS entries in /etc/passwd adduser? m 1708 `passwd' not interruptible when invoked by `adduser' bigloo 1354 bigloo: several problems (ELF, packaging, manpage) xonix1377 xonix can't write its score file. Andrew Howell <[EMAIL PROTECTED]> (6 bugs): rxvt 1161 rxvt manual page differs from implementation samba1825 samba not completely killed by pre/post-rm tcsh 820 tcsh builtin `echo' doesn't check write errors xntp 1656 /etc/ntp.drift should be somewhere in /var (FSSTND) xntp 1770 xntp dumps core with kernel 1.3.35 xtron1703 xtron documentation Peter Tobias <[EMAIL PROTECTED]> (6 bugs): lpr 902 lpr can't print a PostScript file ?! lpr 1061 /etc/printcap vs. /usr/man/man5/printcap.5
Re: Revised resorted bugs list
You did not fix the other bug. Nils, for example has two entries : Nils Rennebarth <[EMAIL PROTECTED]> (1 bugs): gpm 1669 shutdown hangs on gpm -k until mouse is moved Nils Rennebarth <[EMAIL PROTECTED]> (19 bugs): bibtex, kp 1429 several TeX packages Provide themselves dvipsk 1716 dvipsk recommends psfonts - nonexistent package <...> -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
[tange@mi.aau.dk: More info on packages]
--- Start of forwarded message --- Date: Mon, 13 Nov 1995 19:28:10 +0100 From: [EMAIL PROTECTED] Subject: More info on packages To: Ian Murdock <[EMAIL PROTECTED]> Hi Ian. I love being on the debian-announce-list. But I must admit, that the packagedescriptions generally lack. I am sure that there are packages - which I might find handy - but have not installed simply because I do not know what this package does. I am sure this goes for a fair share of the debian-announce-readers, too. Therefore it would be nice if maintainers included a description of the package in the announcement. This could just be the LSM-entry that follows the non-package version. Since you (as far as I know) are the headorganizer of Debian I hereby give you this idea. If you find it acceptable please suggest it to all packagemaintainers. /Ole --- End of forwarded message ---
Re: ELF packages
On Wed, 15 Nov 1995, Ian Murdock wrote: > [...] For now, I urge everyone to upgrade their > copies of gcc, libc, etc., as we're going to start wanting to building > ELF packages fairly soon. I've started working on mine. The second package build failed because it uses curses. The plan, AFAK, is to junk curses in favor of ncurses. However, I recall that Bruce put the ncurses package up for grabs. Would it be possible to get an elf libncurses? Is the stuff in /usr/include/ncurses to be repositioned to /usr/include or to remain in /usr/include/ncurses? Also, I see that we no longer have /usr/include/curses.h, but do have /usr/include/bsd/curses.h.
