[¼ºÀα¤°í]1¿ù 2ÀÏ ½Å±Ô ¼ºÀλçÀÌÆ® ¿ÀÇÂÇÕ´Ï´Ù..

[bc°É]

Processing of epan_1.3.1-5_i386.changes

[Archive Administrator]

epan_1.3.1-5_i386.changes uploaded successfully to localhost
along with the files:
  epan_1.3.1-5.dsc
  epan_1.3.1-5.tar.gz
  epan_1.3.1-5_i386.deb

Greetings,

Your Debian queue daemon

Processing of epan_1.3.1-5_i386.changes

[James Troup]

epan_1.3.1-5_i386.changes uploaded successfully to auric.debian.org
along with the files:
  epan_1.3.1-5.dsc
  epan_1.3.1-5.tar.gz
  epan_1.3.1-5_i386.deb

Greetings,

Your Debian queue daemon

Bug#121459: microwindows build status

[Thomas Bushnell, BSG]

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]

On 4 Jan 2002, Thomas Bushnell, BSG wrote:

> 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.

You have no idea what you're talking about here. While this may be the
best solution in an ideal world, it's pretty damn impractical in the
current situation.
I've been filing 450 build logs since Dec. 31 for PowerPC. Today's been
rather slow, but there's been on the order of 100 builds a day, 70
successful (skim log file, sign, a minute work each) and 10 failed builds
(other than build dependencies that won't install, or disk run full, or
other fun stuff) per day. Only a select few are no-brainers like obvious
build dependencies missing these days. The others require careful
examination of the log and looking up stuff in the build tree (config.log
comes to mind) to even compose a meaningful fail log message.
That's been an hour filing success logs, at least another half hour filing
fail logs, plus whatever it takes to figure out why some freaking build
dependency wouldn't install, or what permanently installed part of the
bloated chroot (in order to catch most of the commonly missing build
dependencies) better be upgraded today. That's only powerpc - m68k builds
at a slower rate, but there's more problems with package dependencies
there, and more machines to keep running smoothly.

To cut a long story short - I find I rarely go the extra mile of filing a
meaningful bug report (forwarding only the fail logs didn't go over well
with a lot of developers) when the basics already take a big chunk out of
my day. There may have been the same bug noticed by another autobuild
admin, and been reported already (duplicate bugs from three or four
autobuilders go over real well, too). It may have been a sporadic problem
with the build chroot, gone the next time a package comes up. If there was
just a single failure to report each day I'd perhaps file a bug, but not
with things as hectic as they are now.

With all architectures collecting build logs at buildd.debian.org,
plus each of the autobuilder sporting its own web interface for looking up
status and log, finding out why a package is out of date on a particular
architecture has become painless enough IMHO. The autobuilders already
take a huge load off developers (imagine everyone manually building their
packages on each architecture).

> 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

In my book, that's a problem with the package maintainers (the lack of
awareness, not necessarily build or upload problems :-).

> 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.

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).

Michael

Bug#121459: microwindows build status

[Thomas Bushnell, BSG]

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#127472: marked as done (does not build from source on powerpc and s390)

[Debian Bug Tracking System]

Your message dated Sat, 05 Jan 2002 15:01:46 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#127472: fixed in libsafe 2.0-9-2
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 2 Jan 2002 16:32:59 +
>From [EMAIL PROTECTED] Wed Jan 02 10:32:59 2002
Return-path: <[EMAIL PROTECTED]>
Received: from mgw01.swol.de (mgw00.swol.de) [195.238.142.134] 
by master.debian.org with smtp (Exim 3.12 1 (Debian))
id 16LoK3-ra-00; Wed, 02 Jan 2002 10:32:59 -0600
Received: (qmail 18162 invoked by uid 1001); 2 Jan 2002 17:26:34 -
Received: from stut199.swol.de (HELO tau) (195.238.130.73)
  by mgw01.swol.de with SMTP; 2 Jan 2002 17:26:34 -
From: Gerhard Tonn <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: does not build from source on powerpc and s390
Date: Wed, 2 Jan 2002 17:35:55 +0100
X-Mailer: KMail [version 1.1.99]
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_VRKBSCUJQ98IBZ5D50UM"
MIME-Version: 1.0
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]


--Boundary-00=_VRKBSCUJQ98IBZ5D50UM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Package: libsafe
Version:  2.0-9-1
Severity: serious
Tags: patch


Hi,
libsafe doesn't build from source on s390 and powerpc. va_list assignment is 
not portable. Please use the attached patch. For details of the error see

http://buildd.debian.org/build.php?arch=&pkg=libsafe
--Boundary-00=_VRKBSCUJQ98IBZ5D50UM
Content-Type: text/x-c;
  name="libsafe-s390.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="libsafe-s390.diff"

LS0tIGxpYnNhZmUtMi4wLTkvc3JjL2ludGVyY2VwdC5jCVRodSBOb3YgMjkgMjE6MzQ6MzAgMjAw
MQorKysgbGlic2FmZS0yLjAtOS1zMzkwL3NyYy9pbnRlcmNlcHQuYwlXZWQgSmFuICAyIDE2OjIw
OjEzIDIwMDIKQEAgLTU3Niw3ICs1NzYsOCBAQAogCS8qCiAJICogV2UgaGF2ZSB0byBzYXZlIGEg
Y29weSBvZiBhcCwgc2luY2UgdmFfYXJnKCkgd2lsbCBtb2RpZnkgaXQuCiAJICovCi0JdmFfbGlz
dCBvcmlnX2FwID0gYXA7CisJdmFfbGlzdCBvcmlnX2FwOworCV9fdmFfY29weShvcmlnX2FwLCBh
cCk7CiAKIAlmb3IgKDsgY291bnQ+MDsgY291bnQtLSkgewogCSAgICBwID0gdmFfYXJnKGFwLCBj
aGFyICopOwpAQCAtNTg1LDcgKzU4Niw3IEBACiAJICAgIH0KIAl9CiAKLQlhcCA9IG9yaWdfYXA7
CisJX192YV9jb3B5KGFwLCBvcmlnX2FwKTsKICAgICB9CiAKICAgICByZXMgPSByZWFsX3ZmcHJp
bnRmKGZwLCBmb3JtYXQsIGFwKTsKQEAgLTY0NSw3ICs2NDYsOCBAQAogCS8qCiAJICogV2UgaGF2
ZSB0byBzYXZlIGEgY29weSBvZiBhcCwgc2luY2UgdmFfYXJnKCkgd2lsbCBtb2RpZnkgaXQuCiAJ
ICovCi0JdmFfbGlzdCBvcmlnX2FwID0gYXA7CisJdmFfbGlzdCBvcmlnX2FwOworCV9fdmFfY29w
eShvcmlnX2FwLCBhcCk7CiAKIAlmb3IgKDsgY291bnQ+MDsgY291bnQtLSkgewogCSAgICBwID0g
dmFfYXJnKGFwLCBjaGFyICopOwpAQCAtNjU0LDcgKzY1Niw3IEBACiAJICAgIH0KIAl9CiAKLQlh
cCA9IG9yaWdfYXA7CisJX192YV9jb3B5KGFwLCBvcmlnX2FwKTsKICAgICB9CiAKICAgICByZXMg
PSByZWFsX3ZmcHJpbnRmKGZwLCBmb3JtYXQsIGFwKTsK

--Boundary-00=_VRKBSCUJQ98IBZ5D50UM--

---
Received: (at 127472-close) by bugs.debian.org; 5 Jan 2002 20:13:53 +
>From [EMAIL PROTECTED] Sat Jan 05 14:13:53 2002
Return-path: <[EMAIL PROTECTED]>
Received: from auric.debian.org [206.246.226.45] (mail)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16MxCT-0004G7-00; Sat, 05 Jan 2002 14:13:53 -0600
Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian))
id 16Mx0k-00021M-00; Sat, 05 Jan 2002 15:01:46 -0500
From: David Coe <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.66 $
Subject: Bug#127472: fixed in libsafe 2.0-9-2
Message-Id: <[EMAIL PROTECTED]>
Sender: James Troup <[EMAIL PROTECTED]>
Date: Sat, 05 Jan 2002 15:01:46 -0500
Delivered-To: [EMAIL PROTECTED]

We believe that the bug you reported is fixed in the latest version of
libsafe, which has been installed in the Debian FTP archive:

libsafe_2.0-9-2.diff.gz
  to pool/main/libs/libsafe/libsafe_2.0-9-2.diff.gz
libsafe_2.0-9-2.dsc
  to pool/main/libs/libsafe/libsafe_2.0-9-2.dsc
libsafe_2.0-9-2_i386.deb
  to pool/main/libs/libsafe/libsafe_2.0-9-2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
David Coe <[EMAIL PROTECTED]> (supplier of updated libsafe package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please c

Bug#121459: microwindows build status

[Thomas Bushnell, BSG]

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

[Daniel Jacobowitz]

On Fri, Jan 04, 2002 at 03:47:30PM -0800, Thomas Bushnell, BSG wrote:
> 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.

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).  The port maintainers
already have a significant amount of work to do on this front, and are
generally package maintainers themselves also.

Of course, I expect James to insert a comment here about how it isn't
really that much work... but we all accept that James is superhuman.

-- 
Daniel Jacobowitz   Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer

Bug#121459: microwindows build status

[Michael Schmitz]

> microwindows is not building on powerpc, but I don't know why.  The

make[1]: Entering directory
`/build/buildd/microwindows-0.88pre11/build/fb/microwin/src'
make[2]: Entering directory
`/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/apps'
make[3]: Entering directory
`/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/apps/nanowm'
/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/Makefile.rules:342:
.depend: No such file or directory
[... snip ...]
Compiling wterm.c ...
wterm.c: In function `main':
wterm.c:1060: warning: implicit declaration of function
`term_init'
wterm.c:790: warning: unused variable `ptr'
wterm.c: At top level:
wterm.c:89: warning: `pty' defined but not used
wterm.c:90: warning: `winsz' defined but not used
dependency dropped.
make[3]: Circular
/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/lib/ <-
/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/lib/ dependency
dropped.
make[3]: *** No rule to make target
`/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/lib/libmwdrivers.a',
needed by
`/build/buildd/microwindows-0.88pre11/build/fb/microwin/src/bin/wterm'.
Stop.

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?

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:

dpkg-source: extracting microwindows in microwindows-0.88pre11
dpkg-buildpackage: source package is microwindows
dpkg-buildpackage: source version is 0.88pre11-4
dpkg-buildpackage: host architecture is powerpc
 /usr/bin/fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f *-stamp
rm -f log.bulid.*
rm -rf build
dh_clean
 debian/rules build
dh_testdir
Unpacking tarballs/microwindows-0.88pre11.tar.gz into build/fb
Unpacking tarballs/microwindows-0.88pre11.tar.gz into build/x11
touch unpack-stamp
Applying /build/buildd/microwindows-0.88pre11/patches/common-sourcepatch
patching file src/Makefile.rules
touch patch-fb-stamp
cp debian/config.fb build/fb/microwin/src
echo Logging to log.build.fb
Logging to log.build.fb
(cd build/fb/microwin/src; /usr/bin/make LIBSOMAJOR=0.88 >
/build/buildd/microwindows-0.88pre11/log.build.fb 2>&1)

No configure. Nothing that would indcate the autobuilder screwed up. Give
me a powerpc libmwdrivers.a and I'll retry.

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. I can see that other architectures built this package
fine. I just can't figure out why.

Michael

Bug#121459: microwindows build status

[Michael Schmitz]

> > 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

There should be another log now to show the freetype2 installation no
longer is a problem but there's the old problem with a missing library now
(see my mail to [EMAIL PROTECTED]).

> As yet, I'm still having trouble having anyone tell me that they
> reproduce #121459.

It was easily reproduced - there's no libmwdrivers.a for powerpc and the
microwindows build tries to use that before it's built.

> 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.

Wait for voltaire to come back online (Jan. 12 IIRC) or send me account
info to set up an account (password crypt, or ssh pubkey).

Michael

Bug#121459: microwindows build status

[Thomas Bushnell, BSG]

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.

Processed: Got microwindows to build on ppc

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 121459 patch
Bug#121459: microwindows doesn't build from source on powerpc (at least)
Tags added: patch

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#121459: Got microwindows to build on ppc

[Aaron Schrab]

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.

The problem is that a couple of the drivers #include sys/io.h, which
doesn't exist on ppc.  As far as I can tell, scr_fb.c doesn't actually
need to include it.  I've tested this patch (should work fine in the
patches directory) on both i386 and ppc:

--- microwin/src/drivers/scr_fb.c.dist  Sat Jan  5 15:32:03 2002
+++ microwin/src/drivers/scr_fb.c   Sat Jan  5 15:32:57 2002
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

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.dist  Sat 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
 

Again, I tested this on both x86 and ppc.  It seems to work, at least
on the systems I checked.

-- 
Aaron Schrab [EMAIL PROTECTED]  http://www.execpc.com/~aarons/
 I dunno, I dream in Perl sometimes... --Larry Wall

Bug#127933: microwindows: microwindows source is organized wrong

[Thomas Bushnell BSG]

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

[Adam Olsen]

On Sat, Jan 05, 2002 at 01:33:25PM -0500, Daniel Jacobowitz wrote:
> On Fri, Jan 04, 2002 at 03:47:30PM -0800, Thomas Bushnell, BSG wrote:
> > 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.
> 
> 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).  The port maintainers

Such as the package subscription stuff just mentioned on debian-qa?  I
don't think having a brief email sent each time a package is autobuilt
would be too much.  (I'd prefer a single email sent when a new version
is uploaded, build reports for all architectures, but I don't thik the
buildd's are syncronized that well.)


> already have a significant amount of work to do on this front, and are
> generally package maintainers themselves also.
> 
> Of course, I expect James to insert a comment here about how it isn't
> really that much work... but we all accept that James is superhuman.

-- 
Adam Olsen, aka Rhamphoryncus

Bug#121459: microwindows build status

[Michael Schmitz]

I concur with Dan here - part because it's really his job, part because
I've had it with filing bug reports from m68k buildds myself. But there's
always two sides to that issue, so:

> > 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

Agreed on both counts. The developers corner would be a nice spot to add a
link to the package status interface. Having the latest build logs and
status on each packages' page on packages.debian.org is a nice idea, we
just need to make sure packages.debian.org works right in the first place
(i.e. I can look up arcane stuff like pmud there). Once that's done, a log
button with arch selector should be easy enough to have.

What do we have to file a bug against to make that happen?
www.debian.org??

> 3) Every port should be responsible for making a machine available to
>developers so that they can fix bugs in their packages.

I can only speak for m68k with any authority - we do offer access for
developers on request, using those machines we have (neither of them
owned by Debian or maintained by DSA, all privately owned and hosted).

We do also work on making one rather high end m68k box available to all
developers without request (still waiting for the barebones box to be
shipped), that machine will be integrated into the standard account
management (if the DSA team agrees). That's all we caan do - if you
suggest having each port set up a mandatory developer machine I'd expect
the project to cover the costs for that in some way.

If you look at http://db.debian.org/machines.cgi most architectures
appear to have one or more machines available.

For powerpc there is voltaire (usually), and in a pinch we can fall back
to giving out accounts on request (see my other mail).

> Note that the problem with microwindows is currently stymied for lack
> of #3.

That's a temporary problem only.

Michael

Bug#121459: microwindows build status

[Michael Schmitz]

> > 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).  The port maintainers
> 
> Such as the package subscription stuff just mentioned on debian-qa?  I

I don't think that suggestion covers it. Unless you mean to say one of the
'subscribers' is made responsible for checking the build logs, by
arrangement of the package maintainers. 

> don't think having a brief email sent each time a package is autobuilt
> would be too much.  (I'd prefer a single email sent when a new version
> is uploaded, build reports for all architectures, but I don't thik the
> buildd's are syncronized that well.)

They are not synchronized at all. But a build log could be sent
automatically to the maintainer, or @debian.org (either for all
packages, or none as far as I'm concerned). Subscribing to receive build
logs - that's something you should talk to the build.debian.org admins
about.

> > Of course, I expect James to insert a comment here about how it isn't
> > really that much work... but we all accept that James is superhuman.

Yep. 

Michael

cooledit_3.17.1-3.1_m68k.changes INSTALLED

[Debian Installer]

Installing:
cooledit_3.17.1-3.1.diff.gz
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.diff.gz
cooledit_3.17.1-3.1.dsc
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.dsc
cooledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/cooledit_3.17.1-3.1_m68k.deb
coolicon_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolicon_3.17.1-3.1_m68k.deb
coolman_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolman_3.17.1-3.1_m68k.deb
libcw-dev_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw-dev_3.17.1-3.1_m68k.deb
libcw_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw_3.17.1-3.1_m68k.deb
smalledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/smalledit_3.17.1-3.1_m68k.deb
Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 115830 124515 127132 


Thank you for your contribution to Debian.

epan_1.3.1-5_i386.changes INSTALLED

[Debian Installer]

Installing:
epan_1.3.1-5.dsc
  to pool/non-free/e/epan/epan_1.3.1-5.dsc
epan_1.3.1-5.tar.gz
  to pool/non-free/e/epan/epan_1.3.1-5.tar.gz
epan_1.3.1-5_i386.deb
  to pool/non-free/e/epan/epan_1.3.1-5_i386.deb
Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 


Thank you for your contribution to Debian.

Bug#124515: marked as done (coolicon: Spelling error in description)

[Debian Bug Tracking System]

Your message dated Sun, 06 Jan 2002 14:55:16 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#124515: fixed in cooledit 3.17.1-3.1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at maintonly) by bugs.debian.org; 17 Dec 2001 22:12:08 +
>From [EMAIL PROTECTED] Mon Dec 17 16:12:08 2001
Return-path: <[EMAIL PROTECTED]>
Received: from smtp01.mrf.mail.rcn.net [207.172.4.60] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16G5zU-0003Js-00; Mon, 17 Dec 2001 16:12:08 -0600
Received: from 146-115-121-200.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com 
([146.115.121.200] helo=mizar.alcor.net)
by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.33 #10)
id 16G5zU-00044z-00
for [EMAIL PROTECTED]; Mon, 17 Dec 2001 17:12:08 -0500
Received: from mdz by mizar.alcor.net with local (Exim 3.33 #1 (Debian))
id 16G5zT-G4-00
for <[EMAIL PROTECTED]>; Mon, 17 Dec 2001 17:12:07 -0500
From: Matt Zimmerman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: coolicon: Spelling error in description
Message-Id: <[EMAIL PROTECTED]>
Sender: Matt Zimmerman <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2001 17:12:07 -0500
Delivered-To: [EMAIL PROTECTED]

Package: coolicon
Severity: minor

This is an automated bug report.

I have recently conducted a mass spelling check of Debian package
descriptions.  In the process, some other errors were also detected,
such as capitalization, word wrap, and indentation problems.

Some notable guidelines that I used in the check include:

- Capitalization

  The names of languages (English, French, etc.) are capitalized in
  English.  Acronyms should be in all capital letters.

- Abbreviation

  In general, words should not be abbreviated as part of the
  description.  Exceptions include standard abbreviations like "etc.".
  This is especially important for proper keyword searches.

- Word joining

  For various reasons, technical terms tend to be artificially joined
  to form new words, like "bugreport".  While this may be acceptable
  in an informal context, such words should be written separately in
  package descriptions, for clarity and to aid in searching.

In some cases where there the spelling check uncovered other errors, I
have made other edits in the diff for purposes of grammar and clarity.

There appear to be one or more errors in the description for this
package.  A unified diff follows at the end of this message.  You
should be able to apply it to your source tree by piping this message
directly into a command line like:

patch /home/me/somewhere/mypackage/debian/control

There is a chance that this may not work if your control has been
modified from the version of your source package in the Debian
archive.  If so, you will have to apply the diff by hand.  When doing
so, please take note if there are multiple corrections on the same
line of the diff.

If you believe this correction to be in error, please contact me
before closing this bug so that we can come to an understanding, and
so that provisions can be made for future spelling checks.

If you are not a native English speaker and would like assistance
improving your description, contact
[EMAIL PROTECTED]


--- orig/coolicon   Mon Dec 17 15:52:36 2001
+++ corrected/coolicon  Mon Dec 17 15:59:03 2001
@@ -2,7 +2,7 @@
 Description: Displays pixmap (.XPM) files as icons on the desktop.
  Each icon presents a menu (right-click) from where the user can perform
  various operations.  Each icon has two user configurable scripts which are
- executed on recieving a drop event or on running the icon with a double-click.
+ executed on receiving a drop event or on running the icon with a double-click.
  The icons scripts' as well as other properties can be modified through a
  dialog box accessible through each icon's menu.  The scripts can directly
  manipulate a received drop event making it easy to program Trash Cans,

---
Received: (at 124515-close) by bugs.debian.org; 6 Jan 2002 20:41:51 +
>From [EMAIL PROTECTED] Sun Jan 06 14:41:51 2002
Return-path: <[EMAIL PROTECTED]>
Received: from auric.debian.org [206.246.226.45] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16NK75-Rf-02; Sun, 06 Jan 2002 14:41:51 -0600
Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian))
id 16NJO0-0001Gf-00; Sun, 06 Jan 2002 14:55:16 -0500
From: Matthias Klose <[EMAIL PROTECTED]>
To: [EMAIL PRO

Bug#127132: marked as done (cooledit fails to build from source on m68k)

[Debian Bug Tracking System]

Your message dated Sun, 06 Jan 2002 14:55:16 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#127132: fixed in cooledit 3.17.1-3.1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 31 Dec 2001 00:46:06 +
>From [EMAIL PROTECTED] Sun Dec 30 18:46:06 2001
Return-path: <[EMAIL PROTECTED]>
Received: from mail126.mail.bellsouth.net (imf26bis.bellsouth.net) 
[205.152.58.86] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16Kqac-0002ts-00; Sun, 30 Dec 2001 18:46:06 -0600
Received: from loki ([216.78.168.67]) by imf26bis.bellsouth.net
  (InterMail vM.5.01.04.00 201-253-122-122-20010827) with ESMTP
  id <[EMAIL PROTECTED]>
  for <[EMAIL PROTECTED]>; Sun, 30 Dec 2001 19:46:03 -0500
Received: from marenks by loki with local (Exim 3.32 #1 (Debian))
id 16Kqa7-FP-00
for <[EMAIL PROTECTED]>; Sun, 30 Dec 2001 18:45:35 -0600
Date: Sun, 30 Dec 2001 18:45:35 -0600
From: Stephen R Marenka <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: cooledit fails to build from source on m68k
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
User-Agent: Mutt/1.3.24i
Sender: Stephen R Marenka <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]


--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: cooledit
Version: 3.17.1-3  =20
Severity: serious

cooledit fails to build from source on m68k. Here's an excerpt from the
build log.


Making all in po
make[3]: Entering directory `/build/buildd/cooledit-3.17.1/po'
PATH=3D../src:$PATH : --default-domain=3Dcooledit --directory=3D.. \
  --add-comments --keyword=3D_ --keyword=3DN_ \
  --files-from=3D./POTFILES.in
rm -f ./cooledit.pot
mv cooledit.po ./cooledit.pot
mv: cannot stat `cooledit.po': No such file or directory
make[3]: *** [cooledit.pot] Error 1
make[3]: Leaving directory `/build/buildd/cooledit-3.17.1/po'


A full build log is available from
.

Other build logs are available from
.

--=20
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>

--AqsLC8rIMeq19msA
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8L7UvVKM4J7YoSbMRAj/NAJ9SX/W0swyFjkEnqRxlEIXcDZpLIwCfdXzM
rjqPrxjug4MvWmfKTWgfoH8=
=034k
-END PGP SIGNATURE-

--AqsLC8rIMeq19msA--


---
Received: (at 127132-close) by bugs.debian.org; 6 Jan 2002 21:05:05 +
>From [EMAIL PROTECTED] Sun Jan 06 15:05:05 2002
Return-path: <[EMAIL PROTECTED]>
Received: from auric.debian.org [206.246.226.45] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16NK79-Rf-00; Sun, 06 Jan 2002 14:41:55 -0600
Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian))
id 16NJO0-0001Gh-00; Sun, 06 Jan 2002 14:55:16 -0500
From: Matthias Klose <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.66 $
Subject: Bug#127132: fixed in cooledit 3.17.1-3.1
Message-Id: <[EMAIL PROTECTED]>
Sender: James Troup <[EMAIL PROTECTED]>
Date: Sun, 06 Jan 2002 14:55:16 -0500
Delivered-To: [EMAIL PROTECTED]

We believe that the bug you reported is fixed in the latest version of
cooledit, which has been installed in the Debian FTP archive:

cooledit_3.17.1-3.1.diff.gz
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.diff.gz
cooledit_3.17.1-3.1.dsc
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.dsc
cooledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/cooledit_3.17.1-3.1_m68k.deb
coolicon_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolicon_3.17.1-3.1_m68k.deb
coolman_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolman_3.17.1-3.1_m68k.deb
libcw-dev_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw-dev_3.17.1-3.1_m68k.deb
libcw_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw_3.17.1-3.1_m68k.deb
smalledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/smalledit_3.17.1-3.1_m68k.deb



A summary of the changes between this version and the previous one is
attached.

Thank you

Bug#115830: marked as done (cooledit: Forces an email send to author at start)

[Debian Bug Tracking System]

Your message dated Sun, 06 Jan 2002 14:55:16 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#115830: fixed in cooledit 3.17.1-3.1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 16 Oct 2001 17:48:58 +
>From [EMAIL PROTECTED] Tue Oct 16 12:48:58 2001
Return-path: <[EMAIL PROTECTED]>
Received: from gfanrend.fishpool.fi [212.16.100.69] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15tYKn-0004jp-00; Tue, 16 Oct 2001 12:48:58 -0500
Received: from seven-of-nine.fishpool.fi [212.16.100.78] (mail)
by gfanrend.fishpool.fi with esmtp (Exim 2.05 #1 (Debian))
id 15tYKl-0004Bu-00; Tue, 16 Oct 2001 20:48:55 +0300
Received: from msk by seven-of-nine.fishpool.fi with local (Exim 3.32 #1 
(Debian))
id 15tYJS-0006AW-00; Tue, 16 Oct 2001 20:47:34 +0300
From: Matti Koskimies <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: cooledit: Forces an email send to author at start
X-Reportbug-Version: 1.29
X-Mailer: reportbug 1.29
Date: Tue, 16 Oct 2001 20:47:34 +0300
Message-Id: <[EMAIL PROTECTED]>
Sender: Matti Koskimies <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]

Package: cooledit
Version: 3.17.1-2.1
Severity: normal

When launched, the program presents a dialog informing that "Cooledit will
now mail the following message to count the number of cooledit users". The 
program will only continue execution if the user agrees to this.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux seven-of-nine 2.2.19 #1 Thu Apr 19 22:35:28 EST 2001 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages cooledit depends on:
ii  libc6 2.2.4-1GNU C Library: Shared libraries an
ii  libcw 3.17.1-2.1 The Cool widget library used by co
ii  python-base   1.5.2-16   An interactive object-oriented scr
ii  xlibs 4.1.0-6X Window System client libraries


---
Received: (at 115830-close) by bugs.debian.org; 6 Jan 2002 21:04:24 +
>From [EMAIL PROTECTED] Sun Jan 06 15:04:24 2002
Return-path: <[EMAIL PROTECTED]>
Received: from auric.debian.org [206.246.226.45] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16NK78-Rf-02; Sun, 06 Jan 2002 14:41:54 -0600
Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian))
id 16NJO0-0001Gd-00; Sun, 06 Jan 2002 14:55:16 -0500
From: Matthias Klose <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.66 $
Subject: Bug#115830: fixed in cooledit 3.17.1-3.1
Message-Id: <[EMAIL PROTECTED]>
Sender: James Troup <[EMAIL PROTECTED]>
Date: Sun, 06 Jan 2002 14:55:16 -0500
Delivered-To: [EMAIL PROTECTED]

We believe that the bug you reported is fixed in the latest version of
cooledit, which has been installed in the Debian FTP archive:

cooledit_3.17.1-3.1.diff.gz
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.diff.gz
cooledit_3.17.1-3.1.dsc
  to pool/main/c/cooledit/cooledit_3.17.1-3.1.dsc
cooledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/cooledit_3.17.1-3.1_m68k.deb
coolicon_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolicon_3.17.1-3.1_m68k.deb
coolman_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/coolman_3.17.1-3.1_m68k.deb
libcw-dev_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw-dev_3.17.1-3.1_m68k.deb
libcw_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/libcw_3.17.1-3.1_m68k.deb
smalledit_3.17.1-3.1_m68k.deb
  to pool/main/c/cooledit/smalledit_3.17.1-3.1_m68k.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose <[EMAIL PROTECTED]> (supplier of updated cooledit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-

Format: 1.7
Date: Sun,  6 Jan 2002 03:51:35 +0100
Source: cooledit
Binary: cooledit coolicon libcw smalledit coolman libcw-dev
Architecture: source m68k
Version: 3.17.1-3.1
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group <[EMAIL PROTECTED]>
Changed-By: Matthias Klose <[EM

Bug#121459: Got microwindows to build on ppc

[Thomas Bushnell, BSG]

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#121459: microwindows build status

[Thomas Bushnell, BSG]

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

[Thomas Bushnell, BSG]

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)...