Bug#389163: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
From Paul's comments, it seems to me that there is no need for the current Aleph it's been replaced, and it's three years old. I have no opinion about whether it ought to be dropped from Debian. Paul also explains that AFNIX replaced Aleph, and should not be thought of as just a new version with a name change. I had misunderstood. Given his explanation, we should think of AFNIX and Alpha as two different entities I think. That means that Paul should continue with AFNIX, I think, and continue learning; there isn't any hue and cry I know of asking for AFNIX to be in Debian right away, so I see no reason he shouldn't just continue as he has been. This however does not solve the name clash with Aleph. So I think there are three possibilities (repeating here what Frank already said somewhat): 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. 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? Thomas signature.asc Description: This is a digitally signed message part
Bug#389163: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
On Tue, 2006-12-12 at 21:20 +0100, Frank Küster wrote: > 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). Eek. > > 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). I am happy to adopt the package and do whatever uploads (including packaging the new upstream version) may be necessary. However, if the program is now called afnix, presumably the package name should change too, which will require NEW queue processing too. > > 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. Another possibility is to NMU aleph to change the binary to /usr/bin/afnix, since this is already upstream's approach according to your report. > To me it seems as if the current situation is better than having no > aleph/afnix at all. However, it violates the release policy. I agree with your assessment of the relative merits here. If there is no fix availing, I think we should just let this policy violation go, though it isn't my call. Thomas signature.asc Description: This is a digitally signed message part
Bug#361766: status
Martin Michlmayr <[EMAIL PROTECTED]> writes: > What's the status of this bug? It looks like nobody has checked out your patch. Since it's a QA package, you are probably at the moment the person who is best qualified to check out the patch. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346883: intent to upload sponsored NMU to fix xlibs-dev bug
Justin Pryzby <[EMAIL PROTECTED]> writes: > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. My pbuild result of this patch was clean, and > produced a binary package with expected debdiff output from the most > recent version in sid. Build logs and debdiff output are attached. > > Please note that maintainer uploads are preferred to NMUs! If you are > able to upload, then please do so. Once again, don't NMU QA-maintained packages; just a straightforward normal upload is the correct procedure. Which I'm doing now for this one too. Thanks for the work in finding the correct patches on these, btw. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346975: intent to upload sponsored NMU to fix xlibs-dev bug
Justin Pryzby <[EMAIL PROTECTED]> writes: > package wmtz > tag 346975 patch > thanks > > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. My pbuild result of this patch was clean, and > produced a binary package with expected debdiff output from the most > recent version in sid. Build logs and debdiff output are attached. This package is already maintained by the QA group. No NMU is necessary; it is permitted to simply upload a new version directly. Accordingly, I have just uploaded a fixed package, including Justin's patch. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325035: Intent to NMU
dann frazier <[EMAIL PROTECTED]> writes: > As these bugs have been open for 30 days without a response from the > maintainer, I intend to NMU them in 1 week (or earlier, at the > maintainer's request). gkdial is currently orphaned. So you don't need to NMU; you can simply do an upload yourself. Don't use NMU version numbering; just use a normal increment. Put at the front of the changelog entry "QA Upload." Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#246486: ["Craig P. Steffen" <[EMAIL PROTECTED]>] drop package roleplaying from Debian
--- Begin Message --- Hi Tomas, You contacted me a while back about the roleplaying package, which I have set to ITA. Your last comment on bug 246486 was that fixing it and bringing it up to date would be the be difficult, and perhaps the package should just be removed. I think that's a good assessment. There was an update January of 2004. The last one before that was 2002. I think given that, and the difficulty of fixing it, and the license changing, that it's best to just flush it. Are you a DD? I assume, then, that it's easier for you to get the ball rolling on that one. Sorry I fell out of touch on this. I'm trying again to get back into that game. The first thing I'm doing is cleaning out old cruft that I left lying around. Thanks, Craig Steffen -- [EMAIL PROTECTED] public key available at http://www.craigsteffen.net/GPG/ current goal: use a CueCat scanner to inventory my books career goal: be the first Vorlon Time Lord signature.asc Description: Digital signature --- End Message ---
Re: webmin-samba in testing
"Roedel, Christian" <[EMAIL PROTECTED]> writes: > it seems the package webmin-samba is not available anymore in the testing > branch. Will it be available again? The webmin-optional packages have two release-critical bugs and it was probably dropped from testing for the time being until those bugs get fixed. The package has no official maintainer, so it will depend probably on whether the QA team has time to deal with its bugs. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#241371: marked as done (gbuffy: crashes after adding new mailbox)
Adeodato Simó <[EMAIL PROTECTED]> writes: > that bug was supposed to be closed by katie, but my sponsor forgot to > pass the appropriate -v option to debuild (or whatever). Whoops! Ah well, such mistakes happen. > actually, bugs closed via the changelog get closed when they enter > incoming, not when they are installed (but anyway, gbuffy is also > installed now). Right, but there are many things that can go wrong between "I'll upload this soon" and "I just did a dupload" and "the package is now actually in incoming".
Re: Bug#241371: marked as done (gbuffy: crashes after adding new mailbox)
> this bug is fixed in gbuffy 0.2.6-8, currently in incoming. Do not close bugs this way. It is incorrect to close a bug until the fixed package is actually installed in the archive. Instead, you can tag the bug "pending", and then put "Closes: #" in debian/changelog, which will make sure the bug is closed at just the right time.
Bug#251768: pbuilder duplicates bug
Blars Blarson <[EMAIL PROTECTED]> writes: > My reopens of this bug are based on pbuilder builds on sparc. You can > probably duplicate it with pbuilder on other architectures. Nope. I tried pbuilder on ppc, and it works fine. The problem, again, is the handling of dependencies (as mentioned on debian-devel and reported to [EMAIL PROTECTED] and [EMAIL PROTECTED]). On those archs, dependencies are not being downloaded, and therefore the build fails. On s390, libx11-dev is installed, but not its dependency libx11-6. On sparc, xlibs-dev is installed, but not its dependency libx11-dev. Thomas
Bug#251768: FTBFS: Missing Build-Depends libxt-dev
reopen 251768 thanks So this is a tricky problem; some buildd's are apparently not installing package dependencies properly. I'm tracking the bug; if you wish to work on it too, please coordinate with me. Thomas
Bug#264026: dia2code: FTBFS
Wouter van Heyst <[EMAIL PROTECTED]> writes: > Regenerating the autotools stuff with a modified autogen.sh from the > autotools-dev package resulted in a package that builds with pbuilder. This is much preferable.
Bug#267927: ppxp: FTBFS on i386
Package: ppxp Version: ppxp_0.2001080415-10 Severity: serious ppxp does not build on i386. See attached log. Title: File `log' in ppxp_0.2001080415-10_i386 (Aug 17 14:33) File `log' in ppxp_0.2001080415-10_i386 (Aug 17 14:33)ppxp >> 0.2001080415-10 >> Aug 17 14:33 >> logAutomatic build of ppxp_0.2001080415-10 on cyberhq by sbuild/i386 1.170.5 Build started at 20040817-1116 ** Checking available source versions... Fetching source files... Reading Package Lists... Building Dependency Tree... Need to get 436kB of source archives. Get:1 http://incoming.debian.org unstable/main ppxp 0.2001080415-10 (dsc) [702B] Get:2 http://incoming.debian.org unstable/main ppxp 0.2001080415-10 (tar) [426kB] Get:3 http://incoming.debian.org unstable/main ppxp 0.2001080415-10 (diff) [8579B] Fetched 436kB in 2s (217kB/s) Download complete and in download only mode ** Using build dependencies supplied by package: Build-Depends: debhelper (>> 3.0.0), libncurses5-dev, libreadline4-dev (>= 4.1), zlib1g-dev, tk8.4-dev, xlibs-dev, libxaw7-dev Warning: The following central src deps are (probably) missing: tcl8.3-dev, tk8.3-dev Checking for already installed source dependencies... debhelper: missing libncurses5-dev: missing libreadline4-dev: missing zlib1g-dev: missing tk8.4-dev: missing xlibs-dev: missing libxaw7-dev: missing Checking for source dependency conflicts... /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install debhelper libncurses5-dev libreadline4-dev zlib1g-dev tk8.4-dev xlibs-dev libxaw7-dev Reading Package Lists... Building Dependency Tree... The following extra packages will be installed: debconf-utils file gettext gettext-base html2text intltool-debian libice-dev libice6 libmagic1 libsm-dev libsm6 libx11-6 libx11-dev libxaw7 libxext-dev libxext6 libxi-dev libxi6 libxmu-dev libxmu6 libxmuu-dev libxmuu1 libxp-dev libxp6 libxpm-dev libxpm4 libxrandr-dev libxrandr2 libxrender-dev libxrender1 libxt-dev libxt6 libxtrap-dev libxtrap6 libxtst-dev libxtst6 libxv-dev libxv1 pm-dev po-debconf render-dev tcl8.4 tcl8.4-dev tk8.4 x-dev xfree86-common xlibs-data xlibs-static-dev Suggested packages: dh-make cvs tclreadline tcl8.4-doc tk8.4-doc x-window-system-core x-window-system xspecs Recommended packages: xterm x-terminal-emulator The following NEW packages will be installed: debconf-utils debhelper file gettext gettext-base html2text intltool-debian libice-dev libice6 libmagic1 libncurses5-dev libreadline4-dev libsm-dev libsm6 libx11-6 libx11-dev libxaw7 libxaw7-dev libxext-dev libxext6 libxi-dev libxi6 libxmu-dev libxmu6 libxmuu-dev libxmuu1 libxp-dev libxp6 libxpm-dev libxpm4 libxrandr-dev libxrandr2 libxrender-dev libxrender1 libxt-dev libxt6 libxtrap-dev libxtrap6 libxtst-dev libxtst6 libxv-dev libxv1 pm-dev po-debconf render-dev tcl8.4 tcl8.4-dev tk8.4 tk8.4-dev x-dev xfree86-common xlibs-data xlibs-dev xlibs-static-dev zlib1g-dev 0 upgraded, 55 newly installed, 0 to remove and 0 not upgraded. Need to get 2270kB/18.2MB of archives. After unpacking 57.3MB of additional disk space will be used. Get:1 http://incoming.debian.org unstable/main libreadline4-dev 4.3-11 [196kB] Get:2 http://incoming.debian.org unstable/main libxaw7 4.3.0.dfsg.1-6 [312kB] Get:3 http://incoming.debian.org unstable/main libxmu-dev 4.3.0.dfsg.1-6 [193kB] Get:4 http://incoming.debian.org unstable/main libxpm-dev 4.3.0.dfsg.1-6 [167kB] Get:5 http://incoming.debian.org unstable/main libxaw7-dev 4.3.0.dfsg.1-6 [389kB] Get:6 http://incoming.debian.org unstable/main libxmuu-dev 4.3.0.dfsg.1-6 [138kB] Get:7 http://incoming.debian.org unstable/main libxp-dev 4.3.0.dfsg.1-6 [154kB] Get:8 http://incoming.debian.org unstable/main libxrandr-dev 4.3.0.dfsg.1-6 [146kB] Get:9 http://incoming.debian.org unstable/main libxtrap-dev 4.3.0.dfsg.1-6 [160kB] Get:10 http://incoming.debian.org unstable/main libxtst-dev 4.3.0.dfsg.1-6 [146kB] Get:11 http://incoming.debian.org unstable/main pm-dev 4.3.0.dfsg.1-6 [135kB] Get:12 http://incoming.debian.org unstable/main xlibs-dev 4.3.0.dfsg.1-6 [134kB] Fetched 2270kB in 5s (423kB/s) Selecting previously deselected package libmagic1. (Reading database ... 7897 files and directories currently installed.) Unpacking libmagic1 (from .../libmagic1_4.10-3_i386.deb) ... Selecting previously deselected package file. Unpacking file (from .../archives/file_4.10-3_i386.deb) ... Selecting previously deselected package gettext-base. Unpacking gettext-base (from .../gettext-base_0.14.1-5_i386.deb) ... Selecting previously deselected package debconf-utils. Unpacking debconf-utils (from .../debconf-utils_1.4.31_all.deb) ... Selecting previously deselected package html2text. Unpacking html2text (from .../html2text_1.3.2a-1_i386.deb) ... Selecting previously deselected package gettext. Unpacking gettext (from .../gettext_0.14.1-5_i386.deb) ... Selecting previously deselected package intltool-debian. Unpac
please remove ia64 lush binary package
Package: ftp.debian.org Severity: important Please remove the ia64 lush and lush-library binary packages. The latest upload omits (intentionally) ia64 from the Architecture line. Lush does not work on ia64, and it is only accidental that past builds worked. The old binary packages for ia64 are blocking inclusion of lush into testing. Thomas
Bug#240992: This is a feature request rather than a bug...
severity 240992 normal thanks Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > I might be mistaken, but isn't it so that currently, if you accidently > have libktoblzcheck1-dev installed, the resulted binary is linked > against it, and otherwise, it isn't? > > Then, isn't it true that this package either > 1) needs to build-depends on libktoblzcheck1-dev > 2) needs to build-conflicts on libktoblzcheck1-dev > 3) needs to be ./configured to not link to libktoblzcheck1-dev, whether >it's available or not? Yes, I believe you are correct. Number (2) is a foolish idea; the package should either use the library, and adopt (1), or it should not, and use (3). That means that a maybe-yes-maybe-no is inconsistent and a bug in the package. So since I'm the new maintainer, I'm bumping it back up to normal severity. Thomas
Bug#255955: [EMAIL PROTECTED]: Re: Accepted mmake 2.2.1-4 (all source)]
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED]/tmp/mmake-2.2.1$ cat LICENSE > COPYRIGHT GNUGPL (c) 1998-2001 Jan-Henrik Haukeland <[EMAIL PROTECTED]> > > Redistribution and use with or without modification, are permitted > provided that the above copyright notice can be reproduced. Please see > the enclosed GNU GENERAL PUBLIC LICENSE file for complete details. > [EMAIL PROTECTED]/tmp/mmake-2.2.1$ > > Seems ok to me, though a little bit non-standard. The problem with this is that it does not actually say which files this applies to. > > In the old version, he did so in the file LICENSE, but that is > > technically not enough--you must do so in such a way that identifies > > *which files* are being licensed. The normal way is to put the > > A LICENSE file in the root of package surely implies it applies to the > whole tarball, doesn't it? I've *never* seen a package with a copyright > statement that listed the source files that were going with that > copyright... Thomas, can you name one package that does so? It's like you didn't even read what I wrote. The normal way is to put a reference to the GPL in every file right next to the copyright. For examples, see GNU Emacs, GCC, coreutils, and many others. > Anyway, could you please continue this discussion on -legal? This isn't > really a topic for discussion on -qa. Actually, just see me personally. I'm now the mmake maintainer, so there is no need for -qa discussion. :) Thomas
Bug#255955: [EMAIL PROTECTED]: Re: Accepted mmake 2.2.1-4 (all source)]
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Well well. I assume of non-serious priority right? > I did a random check of tree packages. 2 of them was correct and 1 did > not include such source comments (hsftp). It depends on the particular case. > That he removed GNUGPL.TXT and LICENSE and added COPYING instead > to be clear. No no, I think you still don't understand. Merely distributing a copy of the GPL *means nothing*. What must happen is the author must say "this work is distributed under the terms of the GPL." It is totally irrelevant what any of the files are called. In the old version, he did so in the file LICENSE, but that is technically not enough--you must do so in such a way that identifies *which files* are being licensed. The normal way is to put the license statement in every file; but he could also list the files in LICENSE, or by some other way. He did not, and that's a bug. The latest version, by contrast, contains no such statement at all, anywhere at all. It simply distributes the GPL (which the old version did too). It is totally irrelevant what filename the GPL is put in. What makes this a serious bug, and something that could warrant the package being removed, is that we should have real doubts about the intentions of the upstream maintainer. He *removed* the grant of permission to copy--not just failed to include one--and he has declined to answer repeated queries from Debian about what his licensing intentions are. > Did you actually read what I wrote? The new upstream has a "COPYING" > file with full GPL statement. Is that not enough as copying file > (except for source notes)? No. It is totally irrelevant what the filename is. Distibuting a copy of the GPL is not, in any way, shape, or form, the same thing as licensing a program under the GPL. > Do you really think this is a problem still? It can not be of 'serious' > severity at least. Not at least unless you want to keep the sarge > release away for a big number of months. Hogwash. The consequence is that mmake would not be part of sarge. Mmake is not a very important program. Thomas
Bug#246486: attempts to fix
It turns out that fixing this bug is not trivial; it is merely one of a whole host of problems that are caused because apparently swig has changed its interface in a variety of ways. Adapting to the changes seems easy on the assumption that you understand swig, but I don't. Perhaps version 2.0.1 (see bug 173384) solves the problems. Since version 2.1 is not free at all, perhaps the best thing to do is to drop roleplaying from Debian entirely. Thomas
Bug#255955: Clarification of
Don Armstrong <[EMAIL PROTECTED]> writes: > My original bug was that debian/copyright didn't actually include the > following (I was auditing packages for something wolse when I ran > across this.) > >COPYRIGHT GNUGPL (c) 1998-2001 Jan-Henrik Haukeland <[EMAIL PROTECTED]> > >Redistribution and use with or without modification, are permitted >provided that the above copyright notice can be reproduced. Please see >the enclosed GNU GENERAL PUBLIC LICENSE file for complete details. > > The above should read something like the following: > >Copyright 1998-2001 Jan-Henrik Haukeland <[EMAIL PROTECTED]> > >This file is part of mmake, and is released under the terms of the >GPL version 2, or any later version, at your option. See the file >README and COPYING for more information. > > if this is actually licensed under the GPL. Oh, and what is particularly important: the license needs to be very clear just what files it applies to. The normal way to do that is to put this text at the front of every file, right next to the copyright notice. Or, if it is carried in a different file, then that file needs to name or otherwise identify exactly which files are covered by the license. Thomas
Bug#255955: reopen
reopen 255955 thanks This bug still exists; merely creating a copyright file doesn't do it. The package is not properly licensed under the GPL, and until we get clarification from upstream, we can't budge on release of it; and we must drop it from Debian if we don't hear at all. I'm tracking this bug, and Ola Lundqvist should not have closed the bug. Please don't close it without discussing with me. Thomas
Bug#265426: lush: FTBFS on amd64: Please add 'amd64' to the supported architectures
Andreas Jochens <[EMAIL PROTECTED]> writes: > The latest change from 'any' to an explicit list of supported architectures > broke the amd64 port. Please add 'amd64' to the supported architectures. Sorry about that; I'll do an upload right away. What we *really* need is a way to do: Architecture: !ia64 Thomas
Bug#243501: [Lush-devel] Status of lush ia64 bug
Leon Bottou <[EMAIL PROTECTED]> writes: > On Wednesday 11 August 2004 10:54 am, Leon Bottou wrote: > > I can see two possible causes: > > > > 1- A floating exception (problems we encountered on mipses) > > The fix would then be easy. > > > > 2- A bfd issue in the dynamic loading/unloading code. > > This could result from gp constructs in IA64 ELF. > > Fixing this would require significant work. > > We'd have to temporarilly declare lush unavailable on IA64. > > > > I would need less than one hour of access to an IA64 machine > > to determine the nature of the problem. Fixing problem 1 > > would be immediate. Fixing problem 2 would take weeks. > > After checking the IA64 ABI, I am certain that problem 2 occurs. Ok, then I'll note that it cannot be built on ia64. I will ask the Debian machine people if you can have a temporary account to work on a port if you would like; let me know. Thomas
Bug#243501: [Lush-devel] Status of lush ia64 bug
Leon Bottou <[EMAIL PROTECTED]> writes: > Kevin told me about a failure to build on certain mips machines. > I was not able to fix it for lack of such a machine. > I was not aware of an IA64 failure. It builds fine on mips and mipsel; it fails on ia64. The mips build log is at http://buildd.debian.org/fetch.php?&pkg=lush&ver=1.0%2Bcvs.2004.05.14&arch=mips&stamp=1090969012&file=log&as=raw. The mipsel build log is at http://buildd.debian.org/fetch.php?&pkg=lush&ver=1.0%2Bcvs.2004.05.14&arch=mipsel&stamp=1089905985&file=log&as=raw The failing ia64 build log is at: http://buildd.debian.org/fetch.php?&pkg=lush&ver=1.0%2Bcvs.2004.05.13&arch=ia64&stamp=1084958283&file=log&as=raw You can review the previous discussion at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243501 > Can you give me a pointer to the failure page in the debian build system? > In order to fix it, I could use a temporary access to an IA64 machine. > Is this something you can arrange with the debian people? I believe it is possible. > Kevin found simpler to maintain the debian directory inside the lush cvs. > It would be easy for us to give you write access as well. > It would also be easy for us to simply remove this directory from cvs. > Your choice will be ours. Well, it's entirely up to you, but QA is a disconnected group of people, and so keeping an off-Debian record makes things much harder. So my suggestion is to remove the current directory. A future real maintainer may well find it helpful again; I cannot say. Thomas
Bug#241371: pending upload for gbuffy?
Adeodato Simó <[EMAIL PROTECTED]> writes: > I've adopted the package (#242096). I'm waiting for a DD to do the > upload for me: > > http://lists.debian.org/debian-mentors/2004/07/msg00407.html > http://lists.debian.org/debian-mentors/2004/08/msg00109.html > > I also asked the QA team for an upload some time ago. See: > > http://lists.debian.org/debian-qa/2004/06/msg00111.html Ah, ok, I got it now. Thanks for letting me know. > > I'd be very glad if you uploaded the package for me. ;-) > Alas, I make a very very bad mentor. I wish I knew a way to make the NMU process better, but the people who run it don't listen to me. :) Thomas
Bug#263594: cannot uninstall xlibs due to broken speedbar-beta dependency
> [EMAIL PROTECTED]> apt-get remove --purge xlibs > Reading Package Lists... Done > Building Dependency Tree... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > > Since you only requested a single operation it is extremely likely that > the package is simply not installable and a bug report against > that package should be filed. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > speedbar-beta: Depends: emacs21 or > emacsen > E: Broken packages apt-get is very clever: if you have partially installed packages, it often tries to complete their installation while doing other work. What happens if you run "dpkg --purge xlibs"? Thomas
Bug#255955: copyright for mmail 2.3
I am working on the Debian package for mmail, and I noticed that its copying permissions are very unclear. You distribute a copy of the GPL with the program, but you never actually say that the program may be distributed under its terms. All I can find is this: # # (c) 1998-2004 Jan-Henrik Haukeland, <[EMAIL PROTECTED]> # I would like to keep this package in Debian, but we cannot distribute it without proper permissions. If you look at the GNU GPL, you will see some instructions for the normal way to apply the GPL to a program. Basically, we need some kind of licensing statement attached to the copyright; merely distributing a copy of the GPL along with the program is not sufficient to legally grant permission. Thomas
Bug#171082: speedbar-beta and xemacs21
I'm investigating bug 171082 / 171222 which you reported; in which speedbar-beta didn't install on with xemacs. Using the current versions in Debian unstable, I am unable to reproduce the problem. Can you confirm whether or not you are still seeing the bug? Thomas
Bug#151870: xitalk crashes if you click on 3rd user
> If you have 3 people logged in, and you click on the 3rd person, xitalk > quits. The 4th person, 1st 2nd all work fine - it's always the 3rd > person that causes it to crash. I can't reproduce this bug on my system; can you tell me if the bug still happens for you, and if it does, what version of the xitalk package you are using? Thomas (for the Debian QA team)
Bug#259258: gnucash: Crashes on startup - guile problem
Does this problem still happen for you? I cannot reproduce it on my system, and before I try to investigate further, can you confirm that it is still a problem? > Package: gnucash > Version: 1.8.9-2 > Severity: grave > Justification: renders package unusable > > Hi all, > > I have checked other startup problems and my error report is different > than already reported bugs. So this is my error report: Thomas
Bug#151319: xkbd doesn't work with sawfish
> As an ipaq user, I know that xkbd isn't really intended for normal > window managers, but I actually have a real need for it on a real WM on > x86 architecture so I'm reporting this as a bug. > > xkbd under sawfish-gnome 1.0.1.20020116-4 doesn't do a darn thing. It > puts up its keyboard window but clicks on the keys don't send keypresses > to the focus window. If focus is set to click-to-focus, xkbd's window > actually takes focus when you click on a key. On current xkbd (0.8.5-2) and sawfish (1:1.3+cvs20040617-6), xkdb works fine for me. Can you see if it still fails for you, and let me know so I can either work on the bug further or close it? Many thanks. Thomas (for the Debian QA team)
Bug#128058: guppi-gnumeric crashes
> Package: libguppi15 > Version: 0.40.2-7 > Severity: important > > On debian ppc sid, I find that guppi-gnumeric crashes when > I try to do the following. > > 1) run gnumeric > 2) enter two columns of three rows of numbers (1,2,3 and 2,4,6) > 3) select these six cells > 4) click on the graph icon in the gnumeric toolbar > > On my machine I get an alert that guppi-gnumeric has suffered a > segment fault. Has guppi ever actually worked within gnumeric > in recent history in sid? I am unable to reproduce this problem in the latest gnumeric (1.2.13) using libguppi16. Does the bug still happen for you? If not, please let me know and I can close the bug report. Thomas (for the Debian QA team)
Bug#246486: Debian roleplaying package
Are you still planning to take over maintenance of the Debian "roleplaying" package? On May 25 you said you were planning to start working on it. If you no longer intend to adopt the package, please change its status back to orphaned (I would be happy to do that for you if you like). If you do still intend to adopt it, do you mind if I do a QA upload to clear the existing release-critical bug (#246486)? Please let me know. Thomas (for the Debian QA team)
Bug#249777: semi: prevents gnus-bonus-el package from configuring
I have just done the following with no problems: # apt-get remove gnus-bonus-el gnus # apt-get install semi wl t-gnus # apt-get install gnus-bonus-el with no errors at all. Perhaps this was fixed in a release after the one you have installed (which appears to be 1.14.6+0.20040). Can you try with a more recent version of the package and tell me if you still see the bug? Thomas (for the Debian QA team)
Bug#110331: This bug seems done now
Colin Watson <[EMAIL PROTECTED]> writes: > Current practice is to simply close bugs in packages maintained by the > QA group once they've been dealt with, rather than regarding them as > NMUs. A new maintainer taking over the package will have to start from > the most recent version in the archive anyway. Oh, of course; I forgot this was a QA upload. Yeah, closing the bug is peachy by me.
Bug#128444: This *is* serious
Colin Watson <[EMAIL PROTECTED]> writes: > severity 128444 serious > thanks > > In practice this is serious. I'll put together a fix. "in practice". No. It doesn't violate policy. Maybe it should, but it doesn't. Of course, it's fine to fix it. But there is no rule that packages must not depend on such things.
Bug#128444: zope-zpatterns_0.4.3p2-0.2(unstable/sparc): build-depends on a package with interactive install
James Troup <[EMAIL PROTECTED]> writes: > Please don't build-depend on zope, it's postinst is interactive which > means it can't be installed by build daemons. Gregor suggested a > better solution in #86722 (namely that the needed header files be > copied to zope-zpatterns source), please use that instead. I grant that this is a better solution, but it's not clear to me why it's "serious". Policy doesn't have any such rule at present. (Though, indeed, I would supporting adding such a rule.) Or, another way to put it is: This is a QA package, it would be very helpful if all Debian developers would help by submitting patches for RC bugs in it. Especially if there isn't a really solid case for the bug being RC in the first place. :)
Bug#121459: Got microwindows to build on ppc
Aaron Schrab <[EMAIL PROTECTED]> writes: > I agree. My previous patch was mostly intended to show what needed to > be turned off for powerpc. I'd somehow got it in my head that it was > the maintianer that had asked for help on -powerpc, and so completely > missed that the package was orphaned. Because of that, I thought that > the maintainer would be better suited to fixing it to only affect ppc. Well, I was playing maintainer-for-the-bug, as it were. ;) But your revised patch is superb; thanks for all the work!
Bug#121459: Got microwindows to build on ppc
Aaron Schrab <[EMAIL PROTECTED]> writes: > But vgaplan4.c also includes that file (via vgaplan4.h) and appears to > need it. I got around this by modifying debian/config.fb so that it > won't build that part: > > --- config.fb.distSat Jan 5 15:40:15 2002 > +++ config.fb Sat Jan 5 14:18:30 2002 > @@ -204,7 +204,7 @@ > # framebuffer screen driver (linear and/or vga 4 planes) > # set VTSWITCH to include virtual terminal switch code > FRAMEBUFFER = Y > -FBVGA= Y > +FBVGA= N > VTSWITCH = Y > PORTRAIT_MODE= N This makes me nervous; aren't you turning off a useful feature here for all systems? I'd feel better if you only turned it off on the one system that can't support it (powerpc)...
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > It was easily reproduced - there's no libmwdrivers.a for powerpc and the > microwindows build tries to use that before it's built. No, no, a thousand times no. microwindows does try to build libmwdrivers.before it's used, and without someone giving me a log of the actual failure (which will require dropping that silly redirection from debian/rules), you're just guessing.
Bug#121459: Got microwindows to build on ppc
Aaron Schrab <[EMAIL PROTECTED]> writes: > tags 121459 patch > thanks > > Fixing the source was actually pretty easy, but it took me quite a while > due to needing to fight the horrible build system from upstream. Thank you, you rock! I'll take care of uploading this.
Bug#127933: microwindows: microwindows source is organized wrong
Package: microwindows Version: N/A Severity: normal The microwindows source is organized wrongly. The .orig.tar.gz file contains itself another .tar.gz, and a set of patches. This is so wrong, it doesn't even begin to deserve mention. But whoever adopts this package really *must* reorganize the source to be more sane. -- System Information Debian Release: 3.0 Kernel Version: Linux aquinas.becket.net 2.2.19 #1 Tue Jan 1 20:08:29 PST 2002 i686 unknown
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > That's why (only the last of four identical errors). According to the > package listing page at http://www.debian.org/distrib/packages there's no > libmwdrivers.a in any of the PowerPC packages, any distribution. On ix86 > the file is in libmicrowindows0-x11-dbg which (surprise) has source > microwindows_0.88pre11. Explain. Maybe the missing .depend has something > to do with it? Where should that come from? No, that's not quite right. The build is failing, but not because libmwdrivers.a should be installed. It's supposed to be built as part of building microwindows. > The source build depends on itself (without bothering to declare that in > build-depends) unless there was some error I didn't catch in the log. And > there isn't much of a log before output is redirected to log.build.fb: No, the package does not depend on itself. I built it without having it installed, and I'm sure the other autobuilders are doing so too. > Side note: redirecting the make output to log.xx.build guarantees the > output is lost when the build tree is cleaned after successful build on > other architectures. Yeah, it's pretty lame to redirect it. It should just be spewed to stdout. I'll make that change at the least.
Bug#121459: microwindows build status
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > I think that's a drastically unfair judgement. I would rather ask > every maintainer to do a few extra steps for the quality of their > packages (or better yet, to improve automated systems to notify > (opt-in) maintainers about such problems). Right now, there isn't even any link from www.debian.org to buildd.debian.org. If you want maintainers to be responsible for checking up on each port to make sure that their packages work on that port, then at a minimum, the following things need to happen: 1) The developer's reference should say so 2) There should be easy and convenient links with that information from (say) packages.debian.org 3) Every port should be responsible for making a machine available to developers so that they can fix bugs in their packages. Note that the problem with microwindows is currently stymied for lack of #3. And, of course, this should apply only to released ports, not ports that exist only in sid.
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > That's why (only the last of four identical errors). According to the > package listing page at http://www.debian.org/distrib/packages there's no > libmwdrivers.a in any of the PowerPC packages, any distribution. On ix86 > the file is in libmicrowindows0-x11-dbg which (surprise) has source > microwindows_0.88pre11. Explain. Maybe the missing .depend has something > to do with it? Where should that come from? Circular dependencies in make are not actually bugs (though they do indicate sloppy programming). Alas, the package is really awful. Take a look at the contents of microwindows_0.88pre11.orig.tar.gz if you want to see part of why. AFAICT, microwindows is not in use by any other Debian packages. So it seems to me, that given limited QA time available, I should file a wishlist bug to reorganize the package source, and for now, let #121459 serve to happily keep the package out of woody. If someone wants to fix it, bless them. Thomas
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > Technically these are binary NMUs, but I'd rather think of them as > happening on behalf of the maintainer by some obscure magic, and that > ultimately leaves the maintainer in charge of checking the result (at > least sporadically). That's a reasonable way to want to change things. But as I mentioned on the mailing list, it's a *change* to current practice.
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > (I rarely do these > days, rather rely on the maintainer to check build status and > logs). This is not such a good idea. Maintainers are generally not responsible for checking build status and logs; the port maintainer (whoever is responsible for making the binary NMU) should do that andn file an RC bug. Indeed, there are many packages that miss getting into testing because of some problem uploading or building one port or another, and maintainers in general seem to be totally unaware of these. I think the people who take responsibility for uploading the binary NMUs for various ports need to also take the responsibility for filing bugs when things are failing.
Bug#121459: microwindows build status
Michael Schmitz <[EMAIL PROTECTED]> writes: > I've rescheduled the 0.88pre11-4 build hoping the build dependencies > install now. But that doesn't relate to #121459 at all. As far as I can tell, it doesn't work: http://buildd.debian.org/fetch.php?&pkg=microwindows&ver=0.88pre11-4&arch=powerpc&stamp=1010178840&file=log&as=raw As yet, I'm still having trouble having anyone tell me that they reproduce #121459. Here's the deal... One of the following needs to happen: 1) Someone with access to a powerpc reports that they were able to build microwindows from current package source. Then, regardless of whatever happens with the buildd/freetype2 problem, #121459 could be closed. The buildd problem is for the buildd and powerpc porters to solve. 2) Someone with access to a powerpc says "here's the patch that fixes 121459", and says "when I apply that patch, the source builds". Then I will upload a new microwindows with the patch, and close #121459. 3) Someone says "here's a powerpc machine that you can ssh to now using your Debian account and which has the build dependencies installed". And then I can go there and deal with #121459 myself. Thomas
Bug#121459: microwindows build status
microwindows is not building on powerpc, but I don't know why. The bug report filed seems wrong to me, and the buildd report at http://buildd.debian.org/stats/?arch=powerpc&state=Dep-Wait reports: libs/microwindows_0.88pre11-4: Dep-Wait by schmitz-pb [optional:uncompiled] Dependencies: freetype2-dev (>= 1.3.1-1), freetype2 (= 1.3.1-1) Previous state was Building until 2002 Jan 02 04:05:45 Previous failing reasons: 0.88pre11-2 some error. 0.88pre11-1 0.88pre11-1 circular build dep 0.88pre7-1 make failures, resulting in circular dependencies for a library I don't know everything about buildd, but it seems to me that it's complaining that freetype2 is not available, and that isn't a reason for there to be an RC bug against microwindows. I would like to close bug 121459, and rely on powerpc to attempt a build by the normal process and report a new bug against the current version if necessary. It would be especially nice if the powerpc port people would see if they can fix any problems, since there isn't a developer-accessible powerpc sid machine for anyone else to work on, it seems. Thomas
Re: Processed: done now
Josip Rodin <[EMAIL PROTECTED]> writes: > On Tue, Jan 01, 2002 at 03:33:09PM -0600, Debian Bug Tracking System wrote: > > Processing commands for [EMAIL PROTECTED]: > > > > > tags 110331 + fixed > > Bug#110331: libmicrowindows0-fb-dbg is not installable in unstable > > Tags added: fixed > > Don't tag it fixed, either tag it pending (if it's in incoming) or close it. Ok, I was trying to be conservative. Please clarify then: The normal rules for NMU's are that the bug is merely marked fixed, right? Does that mean that QA uploads should not really be considered NMUs at all? That's fine, but I thought I should err on the side of caution, not really knowing which. Thomas
Bug#110331: here's the fix
Here's the patch for the bug mentioned. NMU in progress. libmicrowindows0-fb-dbg should depend on libmicrowindows0-fb, not libmicrowindows0. libmicrowindows0-x11-dbg should depend on libmicrowindows0-x11, not libmicrowindows0. Thomas
Bug#121459: oops
The previous message is in error; I typoed the bug number.
Bug#121459: Here's the patch
Here's the patch for the bug mentioned. NMU in progress. libmicrowindows0-fb-dbg should depend on libmicrowindows0-fb, not libmicrowindows0. libmicrowindows0-x11-dbg should depend on libmicrowindows0-x11, not libmicrowindows0. Thomas
Re: gtml
Adam Majer <[EMAIL PROTECTED]> writes: > According to the Need Help page, gtml is O. Looking at it's bug > report I noticed that QA is the maintainer and not the maintainer > that originally maintained the package --- I assume that it is still > for adoption since O bug is not closed. Correct? Correct. Normal practice is that if a package remains orphaned for more than a couple weeks, QA becomes the maintainer. But it is still officially orphaned, and you can adopt it the normal way: first send a BTS note to change the wnpp bug title to ITA, and then in your package upload, close the wnpp bug. Thomas
