Re: New supply-chain security tool: backseat-signed

[G. Branden Robinson]

At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > Or, because some upstream maintainers have learned through, long,
> > bitter experience that newer versions of autoconf tools may result
> > in the generated configure script to be busted (sometimmes subtly),
> > and so distrust relying on blind autoreconf always working.
> 
> When was the last time this actually happened to you?  I certainly
> remember it being a problem in the early 2.5x days, but it's been well
> over a decade since this actually bit me.

A darkly amusing story of this frustration can be found under "Why
patch?" at .

For my part, I have come to associate the name "Akim Demaille" with the
advisability of extreme caution when adopting a release of new software.

Possibly I should be making that association with someone else, though.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[G. Branden Robinson]

At 2024-03-31T22:32:49+, Stefano Rivera wrote:
> Upstreams would probably prefer that we used git repositories
> *directly* as source artifacts, but that comes with a whole other can
> of worms...

Speaking from my upstream groff perspective, I wouldn't _prefer_ that.

The distribution archives get build-testing on a much wider variety of
systems, thanks to people on the groff@ and platform-testers@gnu mailing
lists that help out when a release candidate is announced.  They have
access to platforms more exotic that I and a few other bleeding-edge
HEAD mavens do.  This practice tangibly improved the quality of the
groff 1.23.0 release, especially on surviving proprietary Unix systems.

Building from the repo, or using the bootstrap script--which Colin
Watson just today ensured will be in future distribution archives--is
fine.[1]  I'm glad some people build the project that way.  But I think
that procedure serves an audience that is distinguishable in some ways.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=822fef56e9ab7cbe69337b045f6f20e32e25f566


signature.asc
Description: PGP signature

Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

[G. Branden Robinson]

Hi Otto,

At 2024-03-30T14:09:46-0700, Otto Kekäläinen wrote:
> While reviewing xz-utils commits I noticed that a bunch of old
> copyright holder names were removed in
> https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78.
> 
> Is this OK to do so?

My opinion is that, _apart from copyright concerns_, an author's
attribution should be removed only if that author's contribution has
been completely removed from the file/work in question.  This is largely
a matter of professional integrity and of avoiding plagiarism.

https://invisible-island.net/personal/copywrongs.html

If someone has rewritten an author's contribution such that none of the
author's "original expression" (a manifestation of human creativity)
remains in the file/work, then it is okay to remove their attribution
and/or copyright notice, and is arguably misleading if you _don't_
remove it.

The untruthful placement or removal of a copyright notices can be a
criminal act in the U.S.[1], but I've never heard of a situation where
someone got into trouble for lazily retaining a notice that was once
applicable to a work, but no longer.  This statute _does_ require
"fraudulent intent", as an element of the crime, a prosecutor is
required to prove it beyond a reasonable doubt to the trier of
fact.[2][3]

Still, candor is a virtue, and, in principle, a false (or no longer
true) claim of copyright could cause problems for an author incorrectly
credited, in the event of some sort of criminal or civil liability
attaching to the work.  The xz backdoor and the mysterious identity of
its perpetrator(s) should underscore this concern.

> Having source code in the public domain means that there is no
> copyright, so no attribution required either?

That's true, but world governments have had great trouble saying "no" to
copyright rentiers for the past century or more, so it can be wise to
retain a public domain dedication notice with the author's name and the
year.

> But if copyright attribution is done, each name should have a year
> next to it at least, right?

Yes, because in theory, software will one day _age_ into the public
domain.  Perhaps infants born today will live to see it happen.

> Is it so that the debian/copyright file is reviewed by ftp-masters
> only for packages in NEW queue, and there is probably no automation in
> place to flag subsequent copyright changes for re-review?

That was my understanding 20 years ago; I can't competently speak to the
status quo.

Regards,
Branden

[1] 
https://www.justice.gov/archives/jm/criminal-resource-manual-1855-protection-copyright-notices-17-usc-506c-and-506d

[2] In practice, over-assertion of copyright would seem to be little
policed; it is common practice for book publishers in the U.S. to
assert flatly impossible copyright notices, asserting a date that
hasn't happened yet.  My anecdotal impression is that over the past
20 years, the month in which one can observe copyright notices dated
in the next calendar year has crept steadily backward.

[3] Of course, most criminal prosecutions in the United States never
proceed to the trial stage,[4] so if you're ever sitting across a
table from a U.S. Attorney, the gap between what is asserted and
what can be proved can be huge.

[4] 
https://www.pewresearch.org/short-reads/2023/06/14/fewer-than-1-of-defendants-in-federal-criminal-cases-were-acquitted-in-2022/


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[G. Branden Robinson]

At 2024-03-30T14:38:03+0200, Jonathan Carter wrote:
> On 2024/03/30 11:05, Simon Josefsson wrote:
> > > 1. Move towards allowing, and then favoring, git-tags over source tarballs
> >
> > Some people have suggested this before -- and I have considered
> > adopting that approach myself, but one thing that is often
> > overlooked is that building from git usually increase the
> > Build-Depends quite a lot compared to building from tarball
> 
> How in the world do you jump to that conclusion?

I don't know about "usually", but "often" seems fair enough; it's true
of groff.

https://git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.REPO?h=1.23.0#n15

Regards,
Branden


signature.asc
Description: PGP signature

Re: Proper handling of Lintian warnings due to other packages

[G. Branden Robinson]

package libghc-pandoc-dev
tag 1053777 + fixed-upstream
thanks

Hi Jonas!

At 2024-01-31T08:43:18+0100, Jonas Smedegaard wrote:
> Quoting G. Branden Robinson (2024-01-31 05:49:00)
> > Well, the version of pandoc that resolved the issue was 3.1.7,
> > released in August 2023.[1]  But the version in Debian unstable is
> > still 3.1.3, and the package is team-maintained.[2]
> 
> This particular bug is tracked in Debian as well:
> https://bugs.debian.org/1053777

Ah!  Thanks for pointing that out.  I might as well tell the BTS that
it's fixed upstream.

> > Unless it's release-critical to have these Lintian warnings, I would
> > disregard them in hope that the pandoc package in unstable will
> > catch up at some point soon.
> 
> Unfortunately it is not likely that the package will be catch up soon,
> because the Haskell team upgrade most Haskell libraries only as a
> whole.
> 
> That issue is not tracked in debbugs, because those vocal in the
> Haskell team actively discourages the use of debbugs:
> https://lists.debian.org/debian-haskell/2024/01/msg00012.html

Ah.  That's a shame.  I have a lot of respect for the Haskell language.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Proper handling of Lintian warnings due to other packages

[G. Branden Robinson]

Hi Loren,

At 2024-01-30T19:55:07-0800, Loren M. Lang wrote:
> While building a package preparing for a possible upload, I am getting
> a large number of warnings from groff-message due to invalid fonts for
> C and CB in the manpages that are generated from Markdown with pandoc.
> From what I understand, this is a known issue with how pandoc
> generates nroff man pages and more recent versions of groff have
> started complaining about the issue. Here is an example warning I am
> getting:
> 
> groff-message troff::89: warning: cannot select font 'C'
> 
> And it seems to match the issue documented here:
> 
> https://github.com/jgm/pandoc/issues/9020

Yes.  I work on groff upstream (and at rare intervals make minor
contributions to the Debian package), and you've accurately summarized
the situation.

> My question is how to handle this. Should I just ignore it for now and
> upload anyways since it's only a warning or should I add an override
> to suppress it as it doesn't seem to be causing any breaking issues at
> the moment? Have other developers dealt with this warning before?

Well, the version of pandoc that resolved the issue was 3.1.7, released
in August 2023.[1]  But the version in Debian unstable is still 3.1.3,
and the package is team-maintained.[2]

Unless it's release-critical to have these Lintian warnings, I would
disregard them in hope that the pandoc package in unstable will catch
up at some point soon.  Those warnings from groff can arise under other
circumstances, and they do mean that a font change requested by the
document has not been honored,[3] so I do not recommend masking them in
general.

Regards,
Branden

[1] https://pandoc.org/releases.html
[2] https://tracker.debian.org/pkg/pandoc

[3] From technical writing and accessibility perspectives, it is not
wise to stake important semantic differences to changes in font
style, but a lot of documentation gets written with that coupling
nevertheless.


signature.asc
Description: PGP signature

static linking, modularity, and community (was: Proposal for how to deal with Go/Rust/etc security bugs)

[G. Branden Robinson]

[follow-ups should probably go to -project, but I'm not setting my
headers to try to force that]

At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order to support them.  Those changes are what I'm trying to explore
> here.

Exploration is one thing; advocacy is another.  Please be clear which
role you're taking in any given discussion.  (If you switch hats
midstream, be explicit about it).

[rearranging]
> Speaking as a C person (I know little about Go/Rust), getting stable
> ABIs, dynamic linking [...] right is not simple, and we've been
> working on that for 20+ years consuming plenty of human resources on
> the way.

That's true, but think about the goal that stable ABIs and dynamic
shared objects achieve: software modularity in the field at runtime.  I
trust that I don't have to argue the benefits of modular design to any
even slightly experienced software developer; its benefits have been
understood for about fifty years.

(Just to get this on the record, and for obligatory technical content:
I've studied Go a little and Rust a bit more.  I think that, _as
languages_, they're likely both superior to C in most respects.  [If you
want to visualize PDP-11 assembler output and stack layout as you code,
both are likely ill-suited to the purpose, as standard C itself
increasingly is.]  In any case they are well worth a software
professional's time to look at, in my opinion.  That doesn't mean you
have to endorse their adoption.)

> and security upgrades

And there's the payoff of dynamic modularity, if you will.

If the origin of a statically linked object, whatever its language of
implementation, is not on the ball _for any reason_, the exposure of a
security vulnerability in it or anything upon which it depends expands a
temporal window of attack on affected systems.  We _know_ that certain
actors in the global IT sector hoard undisclosed vulnerabilities for
deployment later, at opportune times for extortion or data exfiltration
against targets of interest.

Next, consider some of the reasons why the origin of a statically linked
object might come "off the ball".  Maybe they got fired or laid off.
Maybe they burned out.  Maybe they died.  Maybe they've been told the
project is supposed to become part of their "20% time"[sic].  Maybe it's
just "not a priority" to their employer.  Maybe they had a baby or
finally went on that long-planned vacation to a tropical island.

If you've worked in Big IT you know that you can predict that when your
business unit gets a new director, _you_ get a new direction.  Directors
and other senior managers justify their huge salaries and benefit
packages by being "impactful", and one reliable way to be "impactful" is
by handing down dramatic decrees.  (All of the top capitalists are
gamblers; one can easily perceive this in their personalities and
rhetoric.)  At one place I worked such a thing happened twice in less
than a year, I think.  We were going to "drop all Linux" and rebase
everything on FreeBSD.  Then that director departed the company and
FreeBSD was out the window--back to Linux.[1]

Worse, when any of these disruptions happens to the origin of a module
that employs static linking, it can take an indefinite amount of time to
_find out_ that such has even taken place.  So its user community may
lose time while it politely waits for their upstream to check in from
vacation or whatever, because they don't want to be rude, or seen as
hijacking the project, or similar.  And even that assumes that the right
people in the community have sufficient expertise to reasonably
approximate the usual construction and release procedures, which can
vary not just in the technology of the implementation system, but in the
hosting/development site.

Consider the motivations and pressures that professionalized, corporate
software is developed under.  Any cost of development that can be
externalized experiences an unrelenting force in that direction.

  An economic profit is the difference between the revenue received from
  sales and the explicit costs of producing its goods and services, as
  well as any opportunity costs.[2]

Opportunity costs are an interesting subject.[3]  They are often
difficult or even impossible to measure.  In business culture, they are
often therefore utterly neglected, even when they are known to exist.
This is why firms pollute, know they pollute, deny to the public that
they pollute, argue with everyone who challenges them about the
consequences of their pollution, and ultimately attempt to escape
liability for their subjection of others--ultimately, human beings and
the environment generally--to their negative externalities.  The
emphasis on profit and a desire by the wealthiest in society to preserve
the prevailing economic system is also why very concept of negative
externalities is under-emphasized or 

Debian package signing and integrity (was: RFC: advise against using Proton Mail for Debian work?)

[G. Branden Robinson]

At 2023-11-15T14:58:15+, Jeremy Stanley wrote:
> I replied to you there too, but you still never seemed to be able to
> explain... why do you need to put an OpenPGP key on the service
> you're using to upload Python packages (not Debian packages) to
> PyPI, given that PyPI doesn't support uploading OpenPGP signatures
> anyway?

Yeah, this seems really scary to me.  The private key of a
public/private key pair associated with an identifiable individual
should absolutely be under the _exclusive_ control of that individual.
Including read access.

I thought this idea was, like, practical crypto 101.

Am I missing something?

> Yes I'm also annoyed that they saw no value in software authors
> uploading signatures for their release artifacts, I argued
> repeatedly in favor of keeping it, but the PyPI maintainers (rightly
> or wrongly) saw it as a mostly-unused attractive nuisance, and
> assert that their more recent addition of HTTPS and strong checksums
> mostly serves the purpose of users being able to double-check that
> what they downloaded is what PyPI meant to serve them (even if they
> can't as easily double-check that what they downloaded is what the
> author believes was originally uploaded).

It's funny how the same arguments recur over time.  Back in 2001, Ben
Collins, John Goerzen, and Wichert Akkerman tried to get this same sort
of thing into practice into Debian, and faced a wall of indifference
from the archive administration team[1].  One may recognize this
approach to package signing as a Merkle tree, an old concept even at the
time that was popularized as a thoroughly innovative lightning stroke of
genius called "blockchain" several years later.

(I seem to remember that John and I worked on a brief USENIX-style white
paper describing this, but I've long since lost track of it.  I also
don't remember if we tried to submit it for DebConf 1 or 2.[8])

I was excited by this development at the time, because it provided a
user-verifiable chain of custody for source bits.  You could have nested
signatures by the (source) package uploader, the party who built the
binary package, and one by each/any archive host.

I recall from IRC that some of the resistance was due to a vague notion
that package signing was suspect because John and I were drawing
salaries from Ian Murdock's company, Progeny Linux Systems; that some
hidden agenda was therefore at work[2], producing an undisclosed
conflict of interest.  Some of these same people suddenly perceived
massive _synergies_ of interest when they themselves started drawing
salaries from Mark Shuttleworth's Canonical Software.  All of a sudden,
they couldn't endorse external agendas enough.  Go figure.

It's noteworthy to me that, despite much more widespread understanding
of Merkle trees nowadays[3], one's opinion of the value of nested,
signed checksums seems to have a strong negative correlation with one's
status as an administrator of a centralized repository, such that only
the last link in the chain of custody is considered important.  With
that threat model, there's no need to compromise any packager's or
uploader's key; you conduct an injection attack on the archive directly.

And _that's_ something that's never happened to anyone, right?[7]

Regards,
Branden

[1] a.k.a. "ftpmasters", a term I have always refused to use because it
is too depressingly Nietzchean--if there's anything that team wasn't
lacking back them, it as a Will to Power...

https://lists.debian.org/debian-dpkg/2001/03/msg00024.html

[2] Such a fear isn't crazy.  Plenty of startups predicate their
promises of future profitability on some sort of "secret sauce" or
process of market capture.  But there would not have been any way to
convince anyone of that at the time.  As the saying goes, "you can't
reason someone out of a belief they weren't reasoned into".  As it
happened, (A) John and I would have been opposed to any such
unethical leveraging effort had one been on offer;[4] (B) Ben and
Wichert weren't affiliated with or compensated by Progeny in any
way;[5] (C) the design and implementation of the initiative were
completely transparent, and their applicability to the problem of an
indeterminate chain of (bit-modifying) custody obvious; and (D)
while it was pursuing a business plan of "get acquired for an absurd
amount of money", the company's strategic direction whipped to and
fro like an unmoored fire hose, depending on whatever Ian was
reading (or who he was talking to) at the time...I suspect that
these were frequently investors who knew far less about the industry
than he did.  Culturally, it doesn't seem that we've gotten any
better distinguish wealth (or the illusion thereof[6]) from domain
knowledge, competence, or virtuous character.

[3] Well, maybe not.  For one rollicking, schadenfreude-inducing tale of
vapidity, cupidity, and stupidity after another, see

Re: Hyphens in man pages

[G. Branden Robinson]

Hi Jon,

At 2023-10-23T17:24:30-0600, Jonathan Corbet wrote:
> When I wrote the article (last week) it was a lot closer :)
> 
> As for why: Debian may have resolved this, for now at least, but this
> is an issue that is sure to crop up in distributions that are not as
> quick to pick up new groff releases.  In that sense, the topic is very
> much timely.

Interestingly (perhaps), this wasn't the first thing that caught fire
after the groff 1.23.0 release.  What was, was a hack that Debian took
out of its man.local file to force SGR escape sequences off in
grotty(1).  But other distributions, like Arch and its many derivatives,
still had it and noticed when it quit working, because they also use the
less(1) termcap_XXX environment variable hack (until relatively
recently, undocumented) to convert overstriking character sequences
into...SGR escape sequences for selecting colors.

That was
.

It took nearly four months for a hyphen-minus debacle to flare up.
Another two and I would have decided I'd managed to duck controversy.

> And as for the groff release ... I sure wish we could find another
> writer to hire to help us restore some of our wider community coverage.
> If you know any likely candidates, do send them our way.

Could you update a URL in the article to be more robust?

https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS#n64

But this points to the master branch, so the text at that line number
will not be stable over time, and in fact it's not correct for the
"PROBLEMS" file in the groff 1.23.0 release.  (We managed to fix some
problems afterward.)

This URL would be better:

https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS?h=1.23.0#n82

I also shifted the line address a little to make it more obvious how old
this issue really is.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-23T11:17:07-0500, G. Branden Robinson wrote:
> Would someone be willing to send me a subscriber-sponsored link to it?

Thanks to the three fleet-fingered folks who supplied me with one.  I am
amply equipped to resume my crusade against ignorance and
misinformation...except...

Now that I have undertaken to attempt to shed light on a comment to the
article, of course LWN itself goes down.[1]

Because of course it did.

Regards,
Branden

[1] https://downforeveryoneorjustme.com/lwn.net

"It's not just you! lwn.net is down.

Last updated: Oct 23, 2023, 11:36 AM (1 second ago)"


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-14T20:51:27-0600, Antonio Russo wrote:
> I discovered a new pet peeve today:

I must report with some dismay that this thread made LWN.

https://lwn.net/Articles/947941/

Would someone be willing to send me a subscriber-sponsored link to it?

I intend to attempt to address what I expect to be inevitable incorrect
statements about groff and/or man pages in the attached discussion
thread.

I am disappointed that LWN did not cover the groff 1.23.0 release, its
first in four years and featuring over 400 bug fixes,[1] even as a tiny
blurb on the back page, but seizes upon this issue, which quietly died
down a week ago, and should therefore have aged out of the current
window of "weekly" news.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/info-gnu/2023-07/msg1.html


signature.asc
Description: PGP signature

Re: AltGr+ not working anymore on most Desktop apps in Gnome

[G. Branden Robinson]

Hi Andrew,

At 2023-10-23T10:41:10+1300, Andrew Ruthven wrote:
> On Sun, 2023-10-22 at 13:18 +0200, Bastian Venthur wrote:
> > fixed the problem. It is strange this option seems to be affected by
> > the keyboard settings in gnome settings, however i changed all
> > options back and forth in the GUI so they should work, but it
> > somehow didn't.  Resetting the option above fixed it. Since I've
> > never used dconf before, I guess there is a bug somewhere that lead
> > to this situation.
> 
> Possibly not related, but a friend noted that after a recent Gentoo
> update his compose key stopped working. Turned out to be a conflict
> between the XkbOptions compose:ralt and grp:switch which were both
> enabled. Turns out something has changed and if they're both set it
> won't work.

I had been surprised to learn earlier this year that quite a bit of
cleanup work has been going on in XKB upstream.

In fact, prior to some CVEs that cropped up last month, such cleanup,
undertaken by at least 3 different people, has dominated recent libx11
development.

https://gitlab.freedesktop.org/xorg/lib/libx11/-/commits/master

Way back when I was maintaining Debian's XFree86 packages, I had
despaired of such an effort ever being understaken.

It's a good thing to see.  But I would not be surprised if some formerly
invalid-but-quietly-accepted configuration combinations, which so often
in XKB seem to arise from cargo-cult practices, start behaving
differently, or stop behaving at all.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-15T13:11:47-0700, Russ Allbery wrote:
> Sorry for my original message, which was very poorly worded and
> probably incredibly confusing.  Let me try to make less of a hash of
> it.  I think what I'm proposing is something like:

My reply to this didn't make it to the -devel list even after several
hours; I suppose it was blocked due to my inclusion of a PDF attachment.

Those who are curious about the issue can read it at
.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

Hi Russ,

At 2023-10-15T12:06:14-0700, Russ Allbery wrote:
> Minor point, but since you posted it

No worries!

> "G. Branden Robinson"  writes:
> 
> > ...
> 
> >  \- Minus sign or basic Latin hyphen‐minus.  \- produces the
> > Unix command‐line option dash in the output.  “-” is a
> > hyphen in the roff language; some output devices replace it
> > with U+2010 (hyphen) or similar.
> 
> The official name of "the Unix command-line option dash" is the
> hyphen-minus character (U+002D).  Given how much confusion there is
> about this, and particularly given how ambiguous the word "dash" is in
> typography (the hyphen-minus is one of 25 dashes in Unicode), you may
> want to say that explicitly in addition to saying that it's the
> character used in UNIX command-line options (and, arguably as
> importantly, in UNIX command names).

How about this?

 \- Minus sign.  \- produces the basic Latin hyphen‐minus
specifying Unix command‐line options and frequently used in
file names.  “-” is a hyphen in roff; some output devices
replace it with U+2010 (hyphen) or similar.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-15T10:01:20-0700, Russ Allbery wrote:
> I think my position at this point as pod2man maintainer (not yet
> implemented in podlators) is that every occurrence of - in POD source
> will be translated into \-, rather than using the current heuristics,
> and people who meant to use ‐ should type it directly in the POD
> source.  pod2man now supports Unicode fairly well and will pass that
> along to *roff, which presumably will do the right thing with it after
> character set translation.

It will, as long as something (like preconv(1)) translates the UTF-8
into something GNU troff can understand.  One of the most painful
decisions James Clark made was to follow AT's example and use "char"
as the fundamental character type, instead of throwing his elbows with
an "int" (or better yet, an int-sized C++ type, since C++ had real type
checking in 1989, while K C was still in vogue and scoffed at such
gratuities).[1]  I took a stab at changing this about 3 years ago but
it was too big a bite.  I didn't know enough yet about how the formatter
worked.  If I have n months to set aside I suspect I can get it done on
a second attempt.

Anyway, to illustrate.  (UTF-8 follows.)

$ for n in $(seq 8); do printf 'abc\\[u2010]defgh '; done | nroff | cat -s
abc‐defgh  abc‐defgh abc‐defgh abc‐defgh abc‐defgh abc‐defgh abc‐
defgh abc‐defgh


> Currently, pod2man uses an extensive set of heuristics, but I think
> this is a lost cause.  I cannot think of any heuristic that will
> understand that the - in apt-get should be U+002D (so that one can
> search for the command as it is typed), but the - in apt-like should
> be apt­like, since this is an English hyphenated expression talking
> about programs that are similar to apt.  This is simply not
> information that POD has available to it unless the user writing the
> document uses Unicode hyphens.

Yes.  This is the same point I was trying to make with my mg(1) man
page example.

> I believe the primary formatting degredation will be for very long
> hyphenated phrases like super-long-adjectival-phrase-intended-as-a-
> joke, because *roff will now not break on those hyphens that have been
> turned into \-.  People will have to rewrite them using proper Unicode
> hyphens to get proper formatting.

Even that can be overcome.  You can tell groff that a line can be broken
after a minus sign.  But I'm going to stone-facedly require people to
RTFM for that.  The character remapping in the PROBLEMS file is the
prescribed band-aid for those who can't or don't care to fix bad
typography in man pages, and I'd prefer not to see additional cargo cult
techniques piled on top of it.

https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS?h=1.23.0#n82

Regards,
Branden

[1] Just like the omission of bounds checks on array types.  What a
brilliant efficiency that was.  Jean Ichbiah saw Dennis Ritchie
coming a mile away in the 1970s, and Ada 83 did the right thing--in
countless respects.  Compiler authors squealed like pigs in hot oil
at the idea of doing any amount of static analysis of input--this is
back when compilers would not _automatically_ pass anything in
registers at all (_everything_ hit the stack) and common
subexpression elimination was regarded as a state-of-the-art
optimization--and spent over a decade slandering Ada's name in every
forum available to them.  Nowadays, static analysis is cool and
compiler engineers make big, big bucks developing its techniques
professionally.  And I'll bet you those who have even heard of Ada
still turn their noses up at it.

Stick around, and I'll share the secret legacy of the hated IA-64...


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

Hi Wookey,

At 2023-10-15T16:08:32+0100, Wookey wrote:
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.
> 
> However despite reading it all, and especially this bit:
> > Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH this has seemed like a lost battle,
> 
> I was left not actually know what - and \- represent, nor which one I
> _should_ be using in my man pages. And that seems to be the one thing
> we should be telling the 'average maintainer'.
> 
> I think you can consider me representative of the typical maintainer
> who's intereaction with *roff languages almost entirely takes the
> form: 'Oh bloody hell I really ought to write a man page for this
> because upstream is too youthful to have done so - now how the hell
> does roff/nroff/groff work again' (no I'm not sure which it is I'm
> actually using, nor how any of this machinery really works, nor where
> to look for good practice, so I mostly copy existing stuff and DDG for
> answers, which is less than ideal when it comes to details like this).
> 
> So this message is mostly a reminder that most people have not been
> following along at all, so just referring people to bugs like this,
> which discuss the issue in some detail, is not sufficient for
> maintainers to stop doign unhelpful things.
> 
> (Yes I realise I could look it up, but I get the impression that
> everyone involved in this discusssion assumes people know what '-' and
> '\-' are so if they are just told to 'use the right one' will do so,
> and I thought it worth pointing out that that's not correct). Info for
> your average maintainer needs to go one step back and say "use stringA
> in this circumstance and stringB in this circumstance.  what they represent>. The reason why it matters is: stuff about hyphen
> and minus being different and minus being used in commands and
> cut+pasting being important"

Yes, I appreciate your popping of the context stack.

Andreas and Russ provided good, quick answers.  One can reasonably
wonder where to find the same answer in groff's documentation.

Subsection "Fundamental character set" of the groff_char(7) man page
covers the matter, but like the bug report we've Cced, it goes into
great detail.

Subsection "Portability" of groff_man_style(7) (or groff_man(7) in groff
1.22.4) covers the subject in a more practical, how-to manner.

[UTF-8 follows.]

groff_man_style(7):
 ... Some escape sequences
 are however required for correct typesetting even in man pages and
 usually do not cause portability problems.

 Several of these render glyphs corresponding to punctuation code
 points in the Unicode basic Latin range (U+–U+007F) that are
 handled specially in roff input; the escape sequences below must be
 used to render them correctly and portably when documenting
 material that uses them syntactically—namely, any of the set ' - \
 ^ ` ~ (apostrophe, dash or minus, backslash, caret, grave accent,
 tilde).

...

 \- Minus sign or basic Latin hyphen‐minus.  \- produces the
Unix command‐line option dash in the output.  “-” is a
hyphen in the roff language; some output devices replace it
with U+2010 (hyphen) or similar.

 \(aq   Basic Latin neutral apostrophe.  Some output devices format
“'” as a right single quotation mark.

...

 \(ga   Basic Latin grave accent.  Some output devices format “`” as
a left single quotation mark.

 \(ha   Basic Latin circumflex accent (“hat”).  Some output devices
format “^” as U+02C6 (modifier letter circumflex accent) or
similar.

 \(rs   Reverse solidus (backslash).  The backslash is the default
escape character in the roff language, so it does not
represent itself in output.  Also see \e above.

 \(ti   Basic Latin tilde.  Some output devices format “~” as U+02DC
(small tilde) or similar.

> Hope that's helpful.

I hope this message goes some way toward relieving your frustration.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-14T20:51:27-0600, Antonio Russo wrote:
> I discovered a new pet peeve today: if you search for a command in a
> manual page, say -e in man 1 zgrep, it's a crapshot whether just
> searching for '-e' will find the command or not.  The reason is that
> "-" may been accidentally encoded as ‐ instead of -.

You can blame me for this.

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206

...me, and man page authors who don't think about whether they intend
a hyphen or a minus sign when they strike the '-' key...

Quick background: in the context of Unix usage as documented by
nroff/troff, the dash used at the shell prompt, in text editors, and in
programming language source code is a "minus sign".  troff has an em
dash special character as well since the mid-1970s; groff adds an en
dash as well, and furthermore supports user definition of characters
providing access to any other sort of dash that comes down the Unicode
pike.  (Not that doing so is a good idea in a man page; see below
regarding a "restricted dialect" of man(7).)

> Now, depending on your email client and settings, the above will
> appear to be the ravings of an unhinged lunatic who wrote the same
> thing twice, or an unhinged lunatic who slammed their fists onto the
> keyboard.

This issue does indeed have a history of provoking unhinged lunacy.

Before we proceed, you might wish to be aware of
 and its
proposed remedy.

> The reason is that man(1) convert bare dashes (0x2D) to hyphens
> (U+2010).  These are not the same symbol: searching for one does not
> find the other without some kind of normalization, pasting commands
> with one vs. the other does different things.  New users who do not
> understand this will be discouraged trying to read manual pages.
> Chances are, they will fill forums with mundane questions that could
> and should have been addressed by a simple search of a manual page.

I run into this problem, too, since I dogfood my own changes.  When
irritated by this, I try the search again, replacing '-' with '.', which
has yet to fail me (and produces false positives surprisingly rarely).

For example, I've recently been playing with the mg(1) editor, and
observed extremely poor discipline in this area.  So I forked it on
GitHub and have been preparing a bunch of revisions.  I wrote a sed
script to fix its numerous hyphen/dash problems.[1]

> I recently fixed a ton of these in another upstream package with this
> vim "one-liner":
> 
> :%s/--\([a-z]\+\)\(-[a-z]\+\)*/\=substitute(submatch(0), '-', '\\-', 'g')/g

My Vimscript is not very sophisticated, but it looks like you're
replacing only hyphens that appear in long option names here.  That's
good, as you're unlikely to clobber any hyphens that should _not_ become
minus signs.

Such discernment is important.  Many people who want to "solve" this
issue forget (or ignore) that not every '-' is a minus sign.  Some are
actual hyphens, as in "long-term effects" and "word-aligned struct
members".  Trying to infer a distinction from white space adjacency also
won't work.  Consider the phrases "word- or byte-sized caching" and
"object-based vs. -oriented programming".  While sophistication with
compound hyphenated affixes is seldom seen in man pages, we most often
find it where a man page author has taken considerable care with their
technical writing.  Such pages are less likely than most to require
revision with blunt instruments like regular expression-based global
search and replace operations.

> However, this requires manual review

Surprisingly often, the composition of high-quality technical
documentation requires the engagement of a human brain.

> and does not fix the '-e' example from zgrep.

Mapping all hyphens and minus signs to a single character, as people
whose blood pressure spikes over this issue tend to promote as a first
resort, is an ineluctably information-discarding operation.  In my
opinion, man page source documents are not the correct place to discard
that information.

(I acknowledge that you didn't propose such a crude remedy; I write to
anticipate the inevitable follow-ups from people who will.)

Doing so at rendering time is much more defensible, and happens anyway
on devices that do not distinguish these characters in the first place.

> There are also a whole host of this kind of problem, e.g., dashes in
> URLs that get naievely pasted into man pages (another live example I
> just addressed).

Yes, people commonly type URLs and email addresses into man page sources
as they would into an MUA or browser navigation bar.  Since U+2010 is
difficult to encode in such things, the man(7) package could help by
performing an automatic character translation in this area.  However,
(1) no one's actually asked for this and (2) it would address only a
tiny part of the problem.  The means of "help" I have in mind is
employment of the groff man(7) extension macros `UR`/`UE` and 

Re: debian/copyright format and SPDX

[G. Branden Robinson]

At 2023-09-22T02:11:15-0700, Steve Langasek wrote:
> SPDX defines an xml format only.  They lost before they'd even
> started.
> 
> debian/copyright is supposed to be human-readable first and foremost.
> XML need not apply.

Very much +1 on everything quoted.

That said, SPDX's license list and the (plain text) tagging convention
that has grown up around it is of great value, and not at all
incompatible with Debian's documentary conventions.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

[G. Branden Robinson]

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Bill Allombert (2023-09-10 18:29:36)
> > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > > Jonas Smedegaard  writes:
> > > >>  Hmm, how about providing license-common package and that
> > > >>  depends on "license-common-list", and ISO image provides both,
> > > >>  then? It would be no regressions.
> > > 
> > > I do wonder why we've never done this.  Does anyone know?
> > > common-licenses is in an essential package so it doesn't require a
> > > dependency and is always present, and we've leaned on that in the
> > > past in justifying not including those licenses in the binary
> > > packages themselves, but I'm not sure why a package dependency
> > > wouldn't be legally equivalent.  We allow symlinking the
> > > /usr/share/doc directory in some cases where there is a
> > > dependency, so we don't strictly require every binary package have
> > > a copyright file.
> > 
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage
> > the copying themselves.
[...]
> I have zero legal training so the only potential problem with this approach
> that I was able to come up with is, that then the source package itself would
> not anymore contain the license text

...why wouldn't it?  Remember how a source package is defined:

A DSC file, an upstream source archive (maybe more than one in exciting
new source formats I haven't learned), and a compressed diff of Debian
changes.

Debian _source_ packages generally don't chop copyright notices and
license texts out the upstream distributions, and should not do so
unless those notices/texts are invalid or the material they cover has
been removed.  (Both of these do sometimes happen.)

Even if one worries about theoretical liability due to the existence of
separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that
(1) the DSC is minimal, containing metadata that may not rise to the
threshold or originality required by copyright [in the U.S., anyway];
(2) the upstream archive has the notices and texts that the _original
distributor_ put in it, and as a rule, if permission to distribute the
work exists, it is not incumbent on redistributors to add notices/texts
where the rightsholder themselves neglected to do so; and (3) the
.diff.gz will not be in the business of removing notices/texts except as
contemplated in the previous paragraph (correcting erroneous
notices).[1]

> and thus we would be shipping code covered by a license that states
> that the code may only be distributed with the license text alongside
> it without that text.

I don't think that is a risk as long as people continue to follow
packaging practices that Debian has applied with little objection from
our upstreams for 25+ years.[2]

> So while auto-generating this would probably create compliant binary
> packages, it would leave the source package without the license text.

I am unable to imagine the mechanism by which that would happen, given
what Russ and Bill proposed.

Regards,
Branden

[1] When repackaging, e.g., to remove non-free material, affected
content is removed altogether even from the source.  Nothing in
copyright law can compel you to distribute copyright notices and
texts that don't apply to work you're not distributing.[3]

[2] I don't know of Debian _ever_ having had a problem, as in receiving
a cease-and-desist letter or other threat of legal action with what
one might term an "institutional" copyright holder.  We've certainly
had our share of nasty emails from cantankerous individual copyright
holders, often who had their own perverse misreadings of licenses
drafted by others (hello to the memory of Jörg Schilling).  There
also was once an upstream who stuck a Trojan horse into the source
code to try to get Debian's users to stop using versions we
distributed, but to go directly upstream instead.  Nowadays, that
seems quaint; you can today Trojan your machine much more
conveniently with npm(1).

[3] At the same time a few non-free FSF manuals under the GNU FDL
declaim the GNU _GPL_ text to be an Invariant Section.  Like most of
the defects of the FDL, I think this is a pointless encumbrance; if
you distribute GPL'ed software, a copy of its text must come along
anyway.  The only rationale I can imagine is to mandate, for printed
copies of the manuals, the inclusion of the GPL's preachy preamble.
But I digress.


signature.asc
Description: PGP signature

Re: Questionable Package Present in Debian: fortune-mod

[G. Branden Robinson]

At 2023-08-23T15:40:06+0100, Adam Sampson wrote:
> "Andrew M.A. Cater"  writes:
> > where are we going to get our fortunes from - where's the canonical
> > source now that FreeBSD has gone?
> 
> There is Shlomi Fish's version:
>   https://github.com/shlomif/fortune-mod/

I've been mulling over whether to take the Debian package native, but
re-orienting our upstream may be a better idea.  The debian/patches
directory of our package is depressingly motley.

https://sources.debian.org/src/fortune-mod/1%3A1.99.1-7.3/debian/

> This includes the patches from Debian and other distributors,
> along with various other updates to the data files, including removing
> some (but certainly not all) of the more obnoxious fortunes.

Good, on both counts.  I had forgotten that the obnoxious cookie files
are already ROT13 encrypted in the source, so the complaint about the
source package containing them sounds to me like a case of taking a
letter opener to the sealed part of the "adult magazine" warning of
offensive content, greedily slicing one's way to access, and then
complaining to the 7-11 proprietor that your sensibilities are shocked.

(Translation: I'm so old I remember magazines doing this; AARP beckons.)

I find Amy Lewis's remarks on the matter, from 1995, noteworthy.

https://sources.debian.org/src/fortune-mod/1%3A1.99.1-7.3/Offensive/

> I am a bit dubious about the licensing of some of the original
> collection, though, even under the most liberal interpretation of fair
> use -- for example, songs-poems contains complete lyrics for several
> songs that are certainly still under copyright.

But they have also been there for a long, long time--not only, in many
cases I am sure, since before commercial access to the Internet was a
thing, but before many of the lawyers who might attempt to litigate such
claims were born.  For situations like this, there are theories of
estoppel and the principle of laches.  In a nutshell, if you sleep on
your rights, you risk giving them up--with respect to particular
infringements.  This is a U.S.-centric observation, but so is the music
publishing rights industry--never diverse, but a tall oligopoly today.

> (Although I guess we could now add a complete set of Tom Lehrer!)

Thank you for bringing this unalloyed happy news to the thread.  :)

Regards,
Branden


signature.asc
Description: PGP signature

Re: Questionable Package Present in Debian: fortune-mod

[G. Branden Robinson]

at come at
some risk to yourself.  Shelter Jews from Nazis.  March with Black Lives
Matter advocates, particularly in areas where white supremacists have
vowed to show up in counter-protest and/or where the police are known to
be cranky and vocally dedicated to an ethos of "busting heads" to
control crime.  The less your advocacy costs you, the less it matters.

It's okay if you're not up to exposing yourself to such danger.  We
rightly celebrate (and, often, commemorate after the violent deaths of)
people who do.  Martin Luther King, Jr.'s writings and speeches are
deservedly well-remembered.[2]  But we must remember that he got out and
marched at risk to himself, frequently.  He was imprisoned for this; I
urge you to read his "Letter from a Birmingham Jail" from start to
finish.  It connects speech with action more eloquently than I can.  Let
us also not forget that when the forces of evil finally took him out, it
was while he was in Memphis in solidarity with striking garbage workers.

At 2023-08-18T21:09:11+, Andrew M.A. Cater wrote:
> As the person who raised this on debian-project in November 2022 - see
> the archives for debian-project for November/December 2022
[...]
> There was unfortunately no consensus on removal on debian-project and
> G. Branden Robinson filed an ITA - intent to adopt - for this package
> at the time.

Thank you for the reminder, though I have not forgotten.  I postponed
this activity until groff 1.23.0 was released and packaged for unstable;
thanks to Bertrand Garrigues and Colin Watson, that's happened.

I admit to some procrastination on my follow-through.  I expect to
receive abuse from people who struggle to distinguish anarchists from
racists and Nazis, for instance, and such derogation would appear to be
in the offing--see below.  That such personal attacks would, it seems,
be carried out in the name of championing the Debian Code of Conduct is
an irony that I do not find pleasant in its familiarity.

> In the absence of any apparent package, this should possibly be 
> added to files considered for removal: in some sense, it would still 
> have been easier to do this prior to Bookworm release, but, hey, you 
> can't do everything :)

For the moment, I reiterate my ITA (adding the bug's -quiet in CC for
this purpose only).  As often happens in software development, I think
changes by small increments make larger adaptations tractable.

I therefore propose the following course of action for myself.

1.  Adopt the package as-is and upload to experimental.

2.  Rename fortunes-off to fortunes-nsfw and upload to unstable, with
the fortunes-nsfw package description rewritten to suggest its
purpose: the avoidance of encounters with the Human Resources
departments of businesses, NGOs, and other institutions where the
Debian distribution might be deployed.

3.  Add explanatory material insular to Debian (history, content) to the
source package, specifically including references to our mailing
list discussions of it.  Last year's thread is an obvious choice,
but whatever records survive of former DPL Bruce Perens's decision
to segregate the "fortunes-off" package and contemporary responses
to it from other Debian Developers would also be valuable for
edification of the younger generation of Debian contributors.[3]

4.  Begin to audit the package for objectionable content according to my
personal taste as suggested in last year's thread.  I venture this
metric not out of egomania, but because I am skeptical that I can
fairly represent anyone's taste but my own.  To summarize last
year's lengthy discussion, I expect I would take out material that I
think has become stale, or where I find a rebuttal to bigotry
insufficiently witty or forceful.

5.  Add stuff that I think is interesting.  Again recapitulating last
year's discussion, I believe that the acquisition of competence in
so-called "higher" mathematics is an ennobling practice and a much
needed remedy for the minds of those who embroil themselves in what
is popularly termed the Culture Wars.  (To my simple mind, much of
this warfare reduces to the age-old struggle between authoritarians
and their putative subjects, but played out at the periphery rather
than the core of official political operations.)

6.  Address _particularized_ and _specific_ bug reports about the
package's content as and when they arise.  What was said?  Who is
harmed, and how?  I pessimistically assume that I'd get appealed to
the CoC committee in nearly every case I rejected the report, but at
the very least I'd try to get a concrete record before the committee
regarding what, _exactly_, someone wanted removed.  I predict that
this would make their job easier.  See above regarding judicial
processes.

It does occur to me that the above plan is, arguably, violative of

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

At 2023-08-17T01:37:52+0100, Colin Watson wrote:
> On Wed, Aug 16, 2023 at 07:08:18PM -0500, G. Branden Robinson wrote:
> > [6] https://man.cx/grog
> > 
> > I was going to link to
> > https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
> > the man page is missing!  groff definitely ships it.  Any advice?
> 
> Aside from the typo in the last URL segment, the penultimate segment
> identifies the binary package, and grog(1) is in the groff-base package
> rather than groff.

Thanks, Colin.  That explains why I also couldn't find it under
<https://manpages.debian.org/unstable/groff/>.

Upstream mentality plus a senior moment--not a good combination!

>   https://manpages.debian.org/unstable/groff-base/grog.1.en.html

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

Hi Hugh,

At 2023-08-17T07:54:03+1000, Hugh McMaster wrote:
> On Thu, 17 Aug 2023 at 03:39, Colin Watson wrote:
> > On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote:
> > > This all seems promising. Unfortunately, the man page is
> > > hand-crafted, not generated from another source, so groff is never
> > > invoked, and no other documents are referenced in the file.
> >
> > groff must be run somewhere, because you're seeing a warning from
> > groff.
> 
> I meant that groff is never called by FreeType's build system, as the
> man page is hand-crafted.

Okay.  But Lintian _is_ calling groff, to format man pages and sniff out
problems with them.

So whether the man page is hand-crafted or generated from some other
format at build time is not relevant.  In fact, it's _meta_ irrelevant
(if that's even a thing) because the only reason (apart from the
validation Lintian's doing) for a source project to run groff at build
time on a man page is to generate a PDF, "cat page", or other
_formatted_ version of the man page.[1]  Examples of these are rare, but
Bash and NetHack generate cat pages, and groff itself generates a PDF
compilation of all its man pages.[2]

> > What exact check is failing here (is it lintian, or something else)?
> > Could you please give us a pointer to the man page in question?
> 
> Lintian issues the warning when checking for man-page issues using
> groff (via man). This particular warning has only appeared since the
> recent groff 1.23.0 upload.

The warning is new to groff 1.23.0.[3]

> The Lintian tag is 'groff-message'. The tag description helpfully
> provides the exact command used during the check:
> 
> LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
> man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
> 
> The man page in question -- ftlint.1 -- is in the freetype2-demos
> package [1], or you can get an online copy from [2].

In the course of composing this message, I see that Colin covered this
point.[4]

I would also note that you can use the grog(1) command (new and improved
in groff 1.23.0![5]) to help you figure out which preprocessors (and
macro package) a *roff document needs.[6]

Let me know if this helps, or does not.

Regards,
Branden

[1] Another use case is to produce non-man-page manuals from *roff
sources using a macro package like "ms", "me", or "mm".  groff
supports all of these and it was commonly done in pre-Web days, but
it's now sadly close to a lost art.  The _Unix Time-Sharing System
Programmer's Manual Seventh Edition Volume 2_ (1979) remains
valuable reading and an example of high-quality technical writing
apply *roff to ends other than man pages.


https://archive.org/details/bitsavers_attunix7thersManualSeventhEditionVol21983_34117955/

It's particularly valuable for learning "classical Unix" tools in
their early and more easily grasped forms.  I've found that GNU
manuals, in spite of the advantages touted for Texinfo for
preparation of book-length works over mere reference guides (a.k.a.
man pages), are nevertheless often written in the style of man pages
with little effort made to give the reader a perspective from which
to integrate knowledge of the (nearly always) larger interface and
feature list of GNU replacements for Unix tools.  In other words,
they too often suffer from the same defects that the GNU Coding
Standards attribute to man pages.


https://web.archive.org/web/20041029120203/http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals

(To be fair, more recent versions of the GNU Coding Standards have
moved--slightly--in the direction of acknowledging that the
quality of the technical writing, not the formatting language used
to compose it, that is the predominant factor in production of
useful manuals.)

[2] https://www.gnu.org/software/groff/manual/groff-man-pages.pdf
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=80ee140eb0616b794b853bbad623263cbea06abc
[4] https://lists.debian.org/debian-devel/2023/08/msg00220.html
[5] Yes, I can feel my eternal soul tumbling down several rungs in Hell
for engaging in promotion.

[6] https://man.cx/grog

I was going to link to
https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
the man page is missing!  groff definitely ships it.  Any advice?


signature.asc
Description: PGP signature

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

Hi Hugh,

I work on groff upstream.

At 2023-08-15T22:46:30+1000, Hugh McMaster wrote:
> groff-message an.tmac::66: warning: tbl preprocessor
> failed, or it or soelim was not run; table(s) likely not rendered (TE
> macro called with TW register undefined)
> 
> It seems TW is not defined in the number register.
> 
> While I can define TW by adding `.nr TW 0` before .TS, I don't know if
> that's the correct solution.

It is a bad idea.  The purpose of the `TW` register is defined in the
tbl(1) man page.

The register TW stores the width of the table region in basic units;
it can’t be used within the region itself, but is defined before the
.TE token is output so that a groff macro named TE can make use of
it. [...]

This information is necessary for macro packages that want to center
tables, a common feature of packages _except_ those that render man
pages.  Because forgetting to run the tbl preprocessor is a common
error, during groff 1.23.0 development it occurred to me that I could
use this register as an indicator.

> Any ideas on fixing this warning, or is it best to ignore it for now?

The diagnostic message is trying to warn you that you _probably_ forgot
to run tbl.  But there are other causes.

1.  tbl crashed or aborted.

2.  The man(7) document embedded the beginning of table in a different
file that it "sourced" with the `so` request, but soelim(1) was not
run on the document.  This is valid, but not considered portable man
page composition style.[1]

3.  A `TE` macro call is in the man page with no `TS` preceding it.
This could arise due to clumsy editing, unfamiliarity with the
man(7) language, or bad luck combined with inexperience (an ordinary
text line happened to begin with `.TE` and the page author didn't
realize that *roff would attempt to interpret that as a macro call).

I tried to cover these bases in the diagnostic, but might have failed.

Can you tell me what part of the message was confusing?

Regards,
Branden

[1] Any *roff can handle this.  So can mandoc(1)--I just found that out.
This fact raises some interesting possibilities, since everything
that was ever called "man2html", the original motive for
groff_man(7)'s Portability section[2] has long gone to the dustbin.

[2] In groff 1.23.0, this section is now in groff_man_style(7).


signature.asc
Description: PGP signature

Re: How do you cause a re-run of autopkgtests?

[G. Branden Robinson]

At 2023-07-21T13:43:05+0200, IOhannes m zmölnig (Debian/GNU) wrote:
> On 7/21/23 12:57, G. Branden Robinson wrote:
> > Hi folks,
> > 
> > But I see no mechanism for interacting with autopkgtests to force
> > them to re-run due to the remedy of a defect in the test harness
> > itself.
> > 
> > How is this to be done?
> 
> you mean, apart from clicking on the ♻ retry icon?

Oh, _that's_ what that means!  It had no tooltip, but if I peer at the
URL preview it does say "retry", so I must confess blindness as well as
ignorance.

> (you probably have to be authenticated in order to even see these
> icons)

I don't have to be authed to _see_ it, but if I click on it, a login is
demanded of me.  Fair enough (robot/DoS defense).

> > Should some automated mechanism for achieving this be added, and if
> > so, where?
> 
> https://ci.debian.net/api/doc

As a bear of little brain, I can indeed infer from this that a mechanism
for prompting retry exists.

Thanks for the pointers!

Regards,
Branden


signature.asc
Description: PGP signature

How do you cause a re-run of autopkgtests?

[G. Branden Robinson]

Hi folks,

Regarding:

https://tracker.debian.org/pkg/groff

...progress of groff into testing is blocked because autopkgtests went
bonkers, failing on every architecture.  This was due to a change in a
groff diagnostic message not getting scraped away by dgit, which was
using a regex to match the message text, and employing one of its own
man pages as a model document to, I think, validate correct man/groff
operation, or man page rendering.  Unfortunately the dgit man page in
question was defective.  I reported the bug with an explanation and
patch, and Ian Jackson promptly fixed and uploaded it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041317
https://tracker.debian.org/news/1446065/accepted-dgit-111-source-into-unstable/

But I see no mechanism for interacting with autopkgtests to force them
to re-run due to the remedy of a defect in the test harness itself.

How is this to be done?  Should some automated mechanism for achieving
this be added, and if so, where?

Regards,
Branden


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:32:40+0100, Colin Watson wrote:
> I occasionally use 32-bit x86 even today (mostly for not very good
> historical reasons, but nevertheless), and I do it by using a 32-bit
> container on a 64-bit x86 machine instead.  It's much faster to run,
> and it doesn't depend on installer support.  There are doubtless edge
> cases where you need a completely separate kernel, but they aren't
> really ones I run into.

Yeah, I knew the containerization rejoinder would arise but failed to
pre-empt it.  And since time_t is a userland problem, it's probably good
enough for the subject of the parent thread.  But I still feel a twinge
of worry for the _unanticipated_ problems...

I am probably also utterly failing to manage my secret desire that by
2037 we'll all[1] be running RISC-V 64 and that no major fab in the
world will still be etching dies of x86-{32,64} cores.

You can laugh at my optimism now.

Regards,
Branden

[1] Not all.  I hope there will still be m68k machines humming away.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:03:40+0100, Steve McIntyre wrote:
> Luca Boccassi wrote:
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to
> >buy a cheap, low-power replacement like a raspberry pi, that also
> >provides better performance.
> 
> Exactly.
[...]
> My plan is therefore [...]  to disable those builds for testing/trixie
> ~immediately after the release.
> 
> If people have strong opinions about that plan, let us know please.

Well, maybe not a strong view, but a sense of vague unease--possibly an
ill-informed one.  As someone who has used SIMH for "real" work[1], I
have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.
Ordinarily, I'd turn to this:

https://wiki.debian.org/DebianInstaller/Qemu

What happens to that with trixie?

I think simulation of 32-bit x86 will get _more_ important as year 2038
approaches, not less, because in about 2037, people will suddenly notice
they need to test things before deployment.

And there are reasons we might not anticipate today.[2]

Regards,
Branden

[1] Running nroff and troff on an emulated PDP-11/45 running Version 7
Unix, to resolve compatibility defects in groff and settle arguments
about "authentic" Unix *roff behavior.

[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp==7974703


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[G. Branden Robinson]

At 2023-05-17T11:30:36+0200, Helmut Grohne wrote:
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.

I'd like to nominate you for a Russ Allbery Award for the most useful
post to the thread.  Your attention to concrete, empirical details,
arising necessarily from practical experimentation rather than pure
cogitation, made the nature of the problems here clearly comprehensible
to me.  And if I was befogged, I'll wager other people were too.

Regards,
Branden


signature.asc
Description: PGP signature

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

[G. Branden Robinson]

[I am not subscribed to debian-gcc or c-std-porting]

Hi Florian,

At 2023-04-18T16:07:45+0200, Florian Weimer wrote:
> TL;DR: I want to propose a GCC 14 change which will impact
> distributions, so I'd like to gather some feedback from Debian.
> 
> Clang has disabled support for a few historic C features by default
> over the last few releases.  This mirrors a process that Apple has
> begun in Xcode even earlier (perhaps motivated in part by their
> AArch64 Darwin ABI, which is pretty much incompatible with some of the
> C89-only features).
> 
> These changes bring real benefits to C programmers because errors are
> much harder to miss during the build than warnings.  In many cases,
> the compiler is not able to generate correct code when such issues are
> present, and programmers who look at the generated machine code
> suspect a compiler bug.  And all this happens because they missed a
> warning.  So we want this change for GCC, too.
[...]
> Specifically, I'm investigating the following changes:
> 
> * -Werror=implicit-function-declaration: Functions can no longer be
>called without be declaring first.  Fixing this may need additional
>prototypes in package header files, or inclusion of additional
>header files (both package-specific and system headers).
> 
> * -Werror=implict-int: int types can no longer be omitted in old-style
>function definitions, function return types, or variable
>declarations or definitions.  Fixing that involves adding the int
>type (or the correct type if it is not actually int).  If there is
>already a matching declaration in scope that has a different type,
>that needs to be resolved somehow, too.
[reordered]
> I want to propose at least the first two for GCC 14.
[reordered]
> The exact mechanism how the default is changed may not be -Werror=,
> perhaps something along the lines of -fpermissive for C++.  The C89
> modes (-std=gnu89 etc.) will likely still enable all these features
> (even if they are not part of C89).  As an opt-out mechanism,
> -std=gnu89 is insufficient because there are packages out there which
> use features which are C99-and-later-only in GCC (predominantly
> C99-style inlining, I believe) together with
> implicit-int/implicit-function-declaration.

Perhaps the thing to do here is have, , yet another command-line
option for GCC.  The Ada language did something similar a couple of
decades ago to tighten up the language for hard real-time demands, with
what it called the "Ravenscar profile".[1]  That proved successful (as
successful as anything was in poor neglected Ada).

The term "profile" is perhaps unfortunate since it already has another
meaning in software performance measurement.  Maybe we could use the
term "contour", which isn't any longer, unlike "silhouette".  A
"contour" furthermore suggests boundaries, which would seem to be
apropos for what you're trying to do in two respects: (a) "ruling out"
certain coding practices that are accepted as standard, or at least
tolerated, otherwise; and (b) reducing the amount of undefined behavior
compiled code exhibits.

Whatever its name, some advantages to this approach are that
distributors could opt-in to such a thing, make it a clear matter of
policy, and more easily track adoption and progress.  You could also
version the contour much like the C standard itself.  So, for instance,
you introduce a contour called "clave23"[2] with the above features...

> * (tentative) -Werror=int-conversion: Conversion between pointer and
>   integer types without an explicit cast is now a compiler error.
>   Usually fixed by one of the two things above.  I do not have data
>   yet how many other cases remain after the initial issues are fixed,
>   but should have that in the coming weeks.  (Quite frankly, I'm
>   amazed that we created 64-bit ports without making this an error.)

So was I, 20 years ago when working on IA-64 ports...

> * (very tentative) -Werror=incompatible-pointer-types: GCC will no
>   longer automatically convert between pointer values of unrelated
>   pointer types (except when one of them is void * or its qualified
>   versions).  The fallout from this could be quite large, I do not
>   have data yet.  Clang does this for function pointer types only
>   (probably based on their ABI issues), but I'm not sure if it's a
>   reasonable distinction for our ABIs (the ppc64le cases I've seen had
>   explicit casts and no warnings).

And then perhaps adopt the above two for "clave26" in 2026 or so.

> * For -Wdiscarded-qualifies (e.g., using const pointers as non-const),
>   and -Wpointe-rsign (using char * as unsigned char *) I do not have
>   any plans.

With a versioned "profile" or "contour", you need not eat the elephant
all at once, and maintain ambitions that seem hopelessly distant today.

> I would appreciate some discussion on the Debian impact.  As Debian
> generally doesn't do mass rebuilds and we have upstreamed the fixes,
> maybe the impact is somewhat 

Re: Reducing allowed Vcs for packaging?

[G. Branden Robinson]

At 2023-03-26T13:56:55-0700, Sean Whitton wrote:
> On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
> > But git or svn or even sccs and rcs is NOT, in any way, preferred
> > for of modification. Only one way of storage and handling some
> > metadata.
> 
> This is Debian's official position, but it's debateable.
> 
> There is the preferred form for modification for an individual *file*,
> and that probably doesn't include version control.  But the preferred
> form for modifying a *project* arguably does.

I wonder if, after twelve years, we have any empirical data regarding
whether Red Hat's stance, that change sets (discretized by the process
of commits to VCSes) are not constitutive of the "preferred form for
modifying a copyrighted work" when that is the form invariably used by
those performing the modifications, frustrated Oracle's aims, or whether
this deliberately anemic interpretation of the GPL was a perfomative
weakening of copyleft to little or no commercial advantage.

https://lwn.net/Articles/432012/

Regards,
Branden


signature.asc
Description: PGP signature

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

At 2023-02-26T11:52:39+0100, Andrey Rakhmatullin wrote:
> Just import them? Do you have any specific questions or problems with
> this?
[...]
> Again, which advice? You said that it works for you.

Hi Andrey,

I think at least some of my confusion arose from trying to use gbp with
a git-dpm-based repository.  I was working in a big hurry, trying to
make the Bullseye release but that is now looking hopeless.

Thanks for responding so swiftly to my plea for help.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

[added Alex Colomar to CC]

At 2023-02-26T13:30:58+, Colin Watson wrote:
> Sorry about that!  Feel free to grab me on IRC if I'm not replying to
> email.

Ah!  I'm never on IRC anymore.  I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
destroyed my IRC continuity.  (I hear there are ways around this...)

> > I am not a proficient gbp user, but I think I have done what is
> > necessary.
> 
> groff doesn't use gbp - it uses git-dpm.

Right.  You told me that before and the information trickled out of my
sieve-like brain.  TLA overload, so I was SOL.  FML.

> If you try to use gbp for it then you will probably get quite confused
> and so will I, so please don't.

Yes, indeed, thanks.

> First, move your current branch somewhere for reference, then make a new
> one.  Then, my routine for pulling in new upstreams looks roughly like
> this:
> 
>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
> ../foo.orig.tar.gz
>   # this imports the unpacked upstream tarball onto an upstream branch
>   # based on $UPSTREAMTAG, then drops you into a rebase session
> 
>   ... continue with rebase as needed, then once you're finished ...
> 
>   git-dpm update-patches --amend
>   # the --amend is just because the import-new-upstream step will
>   # already have recorded the new upstream on the branch you started
>   # from, but the history looks clearer if you bundle the rebase with
>   # that in a single merge commit, which this does
> 
> Then you can cherry-pick your packaging changes on top of this, as well
> as telling pristine-tar about the new upstream tarball based on the
> appropriate imported branch.
> 
> If you push the results to a temporary branch on salsa then I can look
> over them, which is probably a good idea since you're unfamiliar with
> git-dpm.

Thanks for this.  I also found
https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
fallback plan described below.

> > How do we move forward with this?  I am anxious about the closing of the
> > soft freeze window.
> 
> There is no way that this giant new upstream release will be suitable
> at this stage in the freeze; it's too late.  This should be targeted
> at experimental.

Oh, man.  That really sucks the wind out of my sails.  :(

(Good thing I did the packaging update work already!)

The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
are appropriate for bookworm. We want maintainers to focus on small,
targeted fixes. This is mainly at the maintainers discretion, there will
be no hard rule that will be enforced."[1]

I was kind of hoping for an exercise of that discretion in favor of
getting the groff release in.  I hope you feel I have been attentive to
issues of implementation quality.  Nevertheless I admit I have a
conflict of interest as an active upstream (for the moment, still
unoffical) co-maintainer who wants to see his 4,000 commits including
400 bug fixes get into the next Debian release.[2]

But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
quite a bit for personal reasons) is going to be unavailable to tag
1.23.0 final until _next_ weekend so I think groff and Debian release
timing may simply have a curse on them.

Please find attached my much more modest proposal.  Let's make sure the
groff in Debian bookworm will not throw confusing undefined register
warnings or drop text from man pages that begin to embrace groff 1.23's
new features.

Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
that will be undergoing a transition in the next few months, I expect.

Meanwhile I reckon I'll start praying to the gods of backports and point
releases.

Regards,
Branden

[1] https://release.debian.org/testing/freeze_policy.html#soft
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
commit 69e844df84929b8a6a440cbbafe55dcd134107b6
Author: G. Branden Robinson 
Date:   Mon Feb 27 06:27:17 2023 -0600

Rename and document patch

diff --git a/debian/changelog b/debian/changelog
index ca8a27d5..4f867aeb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-groff (1.22.4-10) UNRELEASED; urgency=medium
+groff (1.22.4-10) unstable; urgency=medium
 
+  [ Colin Watson ]
   * Set upstream metadata fields: Repository-Browse.
 
- -- Colin Watson   Mon, 02 Jan 2023 13:38:52 -
+  [ G. Branden Robinson ]
+  * debian/patches/add-groff-1.23-forward-compatibility.patch: Prevent
+formatter warnings and dropped man(7) document text when encountering
+documents written using new features of groff 1.23.
+
+ -- G. Branden Robinson   Mo

need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011666

Can someone advise me as to the correct procedure for merging upstream
release candidate archives into https://salsa.debian.org/debian/groff ?

I am not a proficient gbp user, but I think I have done what is
necessary.

...except that I don't think I did the upstream merge/tagging right.

I suspect this because if I do a "git rebase -i origin", git goes crazy
and tells me I have merge conflicts.  None of the release candidates
were already staged even as reference points, so I had to wade into the
gbp documentation myself, and I probably screwed it up.

*** I have not PUSHED anything. ***

Some relevant shell history is at the end of this message.[1]

But after the point where I merged the upstream tarballs, things are
clean and I can rebase at will.

The upstream diffs are too gigantic to enclose (4,500+ commits since
groff 1.22.4), and not very interesting as they can be seen at groff's
own Git repo.

I'm attaching a git diff -p of my changes after that, meaning the actual
packaging work.

For the benefit of people reading this message, here are the commit
messages themselves (git log -r HEAD~21..HEAD).

commit 3cff7c6967e89d187efb160ce7d2a09af5ea82aa (HEAD -> master)
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:53:06 2023 -0600

debian/changelog: Add upstream bug closers.

commit 1fd80f4151713e9f1d3cb52a4b749fa643776908
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:29:27 2023 -0600

debian/groff{,-base}.install: Add new files

...provided upstream (en.tmac, hyphen.it, it.tmac, groff_font.5,
groff_out.5, groff_tmac.5, groff_man_style.7, groff_rfc1345.7,
FontMap-X11, ptx.tmac, rfc1345.tmac, sanitize.tmac, sboxes.tmac; see
upstream NEWS).

commit 56bf101afd21b9516775f58511e51d85dde06ef1
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:09:23 2023 -0600

debian/groff{,-base}.install: Drop files

...that are no longer produced upstream (see upstream NEWS).

commit 9e99a662a4512e1f6656da2b9408f0f411abd311
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:53:50 2023 -0600

debian/rules (confflags): Migrate option name.

...to "--with-appdefdir" from "--with-appresdir" per upstream NEWS.

commit 21ca0ea6c2162a95faf850b7f9c208b4d6d05374
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:47:03 2023 -0600

Drop {meintro,meref,pic}.txt.

commit 58720f040d16da8bc868eca5466c91ee1a343889
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:17:45 2023 -0600

debian/patches/clamp-negative-tab-stop*: Drop

Applied upstream in commit 6692653f7cae4116d4e70318f71b3d0808f2261f,
2021-09-11.

commit 01d76131b10c44f05ba7378a6193a5ce74f10fb9
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:14:29 2023 -0600

debian/patches/destructor-segv.patch: Drop

Applied upstream in commit c788cf8c6bbe939fa11f7ec032e525a7e33f41b6,
2020-09-29.

commit 0323958c2ea85b86d24e07907e5718584fe5e746
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:11:54 2023 -0600

debian/patches/document-sgr.patch: Resync

...with upstream.

commit 34942d9ebdb365be2765d1cf05850f7a8a6b78ad
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:07:36 2023 -0600

debian/patches/bsd-updates.patch: Drop

Applied upstream in commit 5a8af7104f1c581bcfbad12b56033ad403b0afe1,
2019-12-21.

commit 915e5df22c31ce935de36322f1fa4db933c923e5
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:04:51 2023 -0600

debian/patches/mdoc-Lk-arguments.patch: Drop

Applied upstream in commit 76e4db6e839904d2e2a28b29b483678214598f3b,
2019-01-12.

commit 34fe473ff1c2853d823d5acd3362aeef3e634c7b
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:00:23 2023 -0600

debian/patches/avoid-perl-diamond.patch: Drop

Applied upstream in commit 27472b5ae548d3dbe933713d488d676708996253,
2019-01-24.

commit 4266e24f1d65d5e7c06ac3c2ae2a202c3d0629ce
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:57:25 2023 -0600

debian/patches/sort-perl-hash-keys.patch: Drop

Applied upstream in commit fcf3dc68839d83bfba206d1febffd9514a71ee82,
2015-11-06.

commit cb1cbb55e73e877c73a45d070eed89179699f316
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:52:43 2023 -0600

debian/patches/series: Drop display-utc-times.*

commit 2ec0236804bf60e18282526d343068e9c26d6df2
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:49:14 2023 -0600

debian/patches/mmse-note.patch: Resync w/ upstream

commit e8e7c6ce1e8267bbf6c65ce5910140ccc5a8993a
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:45:39 2023 -0600

debian/patches/load-desc-failure.patch: Resync

...with upstream.

commit b7dc5d92ac984184ab30aef76e5d21752a044fe9
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:40:55 2023 -0600

debian/patches/papersize-config.patch: Resync

...with upstream.

commit bb6d8e31ae4f60afd1ede232618dbff17e64ac87
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:35:

dh_clean fails with diagnostics involving cp, checksums, and a "bucket"

[G. Branden Robinson]

Hi folks,

It's been a while since I've done any packaging.  I was baffled when
presented with the following.

   dh_clean
cp: cannot stat 
'debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c':
 No such file or directory
dh_clean: error: cp -an --reflink=auto 
debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c
 
debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c.tmp
 returned exit code 1
make: *** [debian/rules:3: clean] Error 25

1.  What is the debhelper "bucket"?  A web search turns up no
documentation of this architectural feature, one evidently important
enough that its identification is permitted to leak into diagnostic
messages.
2.  Why is dh_clean trying to copy files around at all?  Nothing about
this is disclosed in dh_clean(1).
3.  Why is dh_clean's own diagnostic message pretty much a
recapitulation of the one before?  First, dh_clean should know why
it is calling cp, and be able to emit an informative diagnostic
about the context of the failure.  Second, why is there no handler
for this failure mode?  It looks like the diagnostic was generated
by a generic wrapper around execve() (or Perl's system(), maybe):
it reports the attempted command line verbatim and its exit status.
This sort of interaction, even with sophisticated users, is suitable
more for tracing or debugging output.
4.  The exit status "25" is fairly unusual, suggesting that it has
significant semantics.  Yet I find no documentation of such
significance in dh_clean's own man page nor in debhelper(7).  Why?
"Exit status" is a common and well-known section heading.

Can someone shed some light on these matters?

Please CC me on replies--many years ago I kept up obsessively with
debian-devel traffic, but not any more, I'm sorry to say.

Thank you in advance.

Regards,
Branden

...so help me, a _bucket_...
https://www.hactrn.net/sra/vaxen.html


signature.asc
Description: PGP signature

Re: Realizing Good Ideas with Debian Money

[G. Branden Robinson]

At 2019-06-01T09:04:39+0200, Philipp Kern wrote:
> Are we then looking more closely at AMD-based machines given that
> those had less problems around speculative attacks?

To borrow a phrase from Christopher Hitchens, this comment gives a
hostage to fortune.

My team at work closely follows (and part of it contributes to) the
research in microarchitectural timing-channel attacks; we just covered
the white paper on one of the three new attacks (RIDL)[1] on Friday.

I'll say this now because I don't know of anything embargoed that could
get me into trouble: don't count on AMD's good smell just this second to
last.  Remember that the previous round of embarrassments
(Spectre/Meltdown) didn't entirely spare AMD and ARM, and we haven't yet
seen any ground-up reimplementations of CPU cores with publically
auditable, formally-verified proofs of immunity to microarchitectural
timing channel attacks.

I see no reason to reward AMD with purchases based on what may be an
accidental and temporary lack of egg on the face.  This is the same firm
that followed Intel into the land of unauditable system management
firmware[2] and acquired ATI and shut down the information channels
enabling good free video drivers to be developed[3].

My two cents[4] is that DSA should make its purchasing and hardware
solicitation decisions with the architectural security issue fairly far
down the priority list.  It saddens me to say that, but this new class
of exploits, what van Schaik et al. call "microarchitectural data
sampling" (MDS), is a playground for security researchers right now; a
big rock has been turned over and bugs are erupting from the soil in a
squamous frenzy.  It will take months or years for the situation to
settle down.

To acquire hardware based on what is known today is to risk buyer's
remorse.  Plan on inescapable remorse later; every chip vendor will let
us down until corporate managers learn to treat confidentiality and
integrity as feature rather than cost centers.  (And count on them to
forget what they've learned after a few quarters pass without
embarassing headlines.)

Some day, perhaps, if the universe is less than maximally cruel, we'll
have the option of server-class RISC-V systems with fully-documented,
formally-verified designs.  But that day is not yet here.

In the meantime, always keep a fork with some cooked crow on it ready to
hand, so that the next time you run into one of the many "pragmatic"
people in our community who puffed and blew about how we didn't "really
need" open hardware, you can invite them to eat the stuff and so be
silent.

One wonders how pragmatic they'll feel when it's _their_ private data
being exfiltrated.

[1] https://mdsattacks.com/files/ridl.pdf
[2] https://libreboot.org/faq.html#amd
[3] I don't have a good cite handy for this, but Michel Dänzer can
doubtless tell the story with more accuracy and precision than I
can.
[4] ...further discounted reflecting my rather low level of project
activity.


signature.asc
Description: PGP signature

Accepted xtrs 4.9d-2 (source amd64) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 15 Aug 2018 11:59:02 -0400
Source: xtrs
Binary: xtrs
Architecture: source amd64
Version: 4.9d-2
Distribution: unstable
Urgency: low
Maintainer: G. Branden Robinson 
Changed-By: G. Branden Robinson 
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 905584
Changes:
 xtrs (4.9d-2) unstable; urgency=low
 .
   * debian/control: Bump Standards-Version to 4.0.0.
 + Update debian/patches/make-plain-text-docs-from-html.patch and
   debian/patches/makefile-generate-pdf-manpages.patch to respect "nodoc"
   in DEB_BUILD_OPTIONS.
 .
   * debian/rules: Set DEB_CFLAGS_MAINT_APPEND to "-Wall -Werror".  Set
 DEB_LDFLAGS_MAINT_APPEND to "-Wl,--as-needed".
 .
   * debian/rules: Run upstream "check" target as part of our "check-binary"
 target.
 .
   * debian/rules: Add "maintainer-clean" target to work around the fact that
 some of our patches cause new files to be created, and the package build
 unapplies all the patches without cleaning the build tree.
 .
   * debian/control: Add link to upstream GitHub site in package description;
 thanks, Reiner Herrmann!  (Closes: #905584)
   * debian/control: Tweak English style in package description.
 .
   * debian/README.source: Add material from the Debian Policy Manual's
 upgrading checklist to document my findings regarding this package's
 compliance with it.
 .
   * debian/patches/stop-mkdisk-from-overflowing-buffers.patch:
 + Don't spuriously report test failures if $MKDISK is set to a non-default
   value.
   * debian/patches/ignore-alt-key-events.patch:
 + Update help window to stop documenting Alt key bindings.
   * debian/patches/map-f12-to-shifted-down-arrow.patch:
 + Update help window to document what F12 does now.
   * debian/patches/move-error.c-prototypes-to-new-error.h.patch:
 + Move diagnostic function prototypes into their own header.
   * debian/copyright: Add patch-created error.h file.
   * debian/patches/add-warning-diagnostic-function.patch:
 + A few places in the code were calling error() with "warning:" in the
   argument string, which looked weird.  Make a warn() function for these
   use cases.
   * debian/patches/fix-compiler-warnings.patch:
 + Fix clunky logic in unused variable warning suppression when neither
   SB_SOUND nor HAVE_OSS is #defined.  Don't bother specifying the
   signedness of the ints we use as booleans.  Move declaration of
   sb_address such that it is only present if either SB_SOUND and/or
   HAVE_OSS is #defined.  Add explanatory comment.  Actually throw a
   warning about lack of host system sound support for emulated cassette
   and sound ports only once each.  Don't bother zeroing sb_address after
   issuing said warning.
   * debian/patches/stop-mkdisk-from-overflowing-buffers.patch:
 + Update to resolve GCC 8's stringop-truncation warnings (which
   mysteriously do not appear with debian/rules-driven builds, just with
   manual "make"s).  Get rid of unneeded variable fname_truncated.  Use
   GCC pragmas to suppress remaining instance; add comment explaining that
   we know what we're doing, since we're writing to a static buffer inside
   a struct.
   * debian/patches/fix-stringop-truncation-warning.patch:
 + Issue warning diagnostic if the argument to cmddump -p is too long.
   Swap order of space-padding strncat and forced setting of pdsbuf[8] to a
   null byte.  This persuades GCC that we're ensuring pdsbuf has a string
   terminator.  Use '\0' instead of '\000' as null character escape.
Checksums-Sha1:
 af78b65bce7b23e92bdff4319367160af694de87 1812 xtrs_4.9d-2.dsc
 377bd11ed46bf0bf20858b7e9f01382a00fee5bf 113720 xtrs_4.9d-2.debian.tar.xz
 61118f3baf8e2cb0e36e582cfc133da56074725c 206192 xtrs-dbgsym_4.9d-2_amd64.deb
 9228ee97538e5398a5be9470b591c2c8cd229907 6822 xtrs_4.9d-2_amd64.buildinfo
 296fdca87ff74159943abdcc625ce49f6448491a 371464 xtrs_4.9d-2_amd64.deb
Checksums-Sha256:
 8a136fb45be3f012ded5c919f904bc5e7f4738c7907d01881204ae6d8728a06f 1812 
xtrs_4.9d-2.dsc
 56bd451fbe8d92c7cc54ffd5418c8dfc6625241c37c2a30e68f1fd9e70d23012 113720 
xtrs_4.9d-2.debian.tar.xz
 c2970bb5d542f7b0a9ffd6fceeb4bd0be8cf521b98e6435a1ef7701ed5443393 206192 
xtrs-dbgsym_4.9d-2_amd64.deb
 8cf93042bc1609966f1c84f49913b42b5e90bef2f030d2840ecb03e19eddd7f6 6822 
xtrs_4.9d-2_amd64.buildinfo
 17ed3704913b13c7673453d2fb33045a492f0bee3e785f2844469ddede407e6e 371464 
xtrs_4.9d-2_amd64.deb
Files:
 b7a33e98b438657b9a75ee2c7be5fb60 1812 contrib/otherosfs optional 
xtrs_4.9d-2.dsc
 9c8bd7747c10898e7b580836889d7b53 113720 contrib/otherosfs optional 
xtrs_4.9d-2.debian.tar.xz
 80a4d3f7eff308fd0667191ad1353723 206192 contrib/debug optional 
xtrs-dbgsym_4.9d-2_amd64.deb
 502775bcfd6b66d475d2dcad8ef6c30b 6822 contrib/otherosfs optional 
xtrs_4

Accepted xtrs 4.9d-1 (source amd64) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 08 Aug 2018 03:21:44 -0400
Source: xtrs
Binary: xtrs
Architecture: source amd64
Version: 4.9d-1
Distribution: unstable
Urgency: medium
Maintainer: G. Branden Robinson 
Changed-By: G. Branden Robinson 
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 511645 757864 767488 835622 859751
Changes:
 xtrs (4.9d-1) unstable; urgency=medium
 .
   * Merge new upstream release.
 + "Deleted all SIGIO code.  The code was a kludge to begin with and it no
   longer worked with current X libraries and Linux kernels, causing xtrs
   to hang.  It was also reported to cause hangs when xtrs was compiled for
   Windows using Cygwin.  Thanks to Howard Pepper, Dennis Lovelady, Arumin
   Nueckel, Christopher Currie, and Joe Peterson for bug reports."
   (Closes: #511645)
 .
   * Patches to upstream:
 + trs_imp_exp.c: Turn on the "emtsafe" flag by default, preventing actions
   potentially harmful to the host environment (like removing the user's
   files or running shell commands) from being done within the emulator.
   - xtrs.man: Document the new default.
 + trs_keyboard.c: Map F12 to the TRS-80 shifted down-arrow key.
 + mkdisk.c: Fix buffer overflow when given filename >8 characters.
   Truncate filename by default when copying to hard disk image.  Add -S
   ("spill") flag to partially simulate old behavior.  Exit with error if
   filename argument would overflow even the subsequent structure member
   historically used by xtrs to store extra filename characters.
   - mkdisk.man: Document -S flag and related issues.
   - test-mkdisk.sh: Add tests for overflow and new filename truncation and
 spillage logic.
   - Makefile: Add "check" target to run the foregoing test.  Nothing
 upstream calls this target automatically.
 + mkdisk.c: Check return value of fopen() when creating DMK disk image
   file.
 + mkdisk.c: Refuse to clobber files by default.  Add -f ("force") flag to
   override this behavior.
   - mkdisk.man: Document new behavior and -f flag.
   - test-mkdisk.sh: Test default no-clobber and -f flag behavior.
 + mkdisk.c: Document the -d option for hard disk images in usage message.
 + trs_xinterface.c: Write the key binding help to standard error if the
   emulator's X window is too small to hold it.
 + trs_xinterface.c, main.c: Convert the last users of fprintf(stderr, ...)
   to use the functions from error.c.
 + Makefile: Observe LDFLAGS when building internal "compile_rom" tool.
   Thanks to Graham Inggs for the discussion!  (Closes: #859751)
 + Port to C11 and build with -std=c11.
 + Makefile: Generate and install PDF versions of man pages.
   - debian/xtrs.docs: Ship them, too.
   - debian/control: Promote groff-base build-dependency to full groff, for
 gropdf.
   * Export Debian build flags to environment.  Executables are now hardened
 per < https://wiki.debian.org/Hardening >.
   * Add Turkish debconf template translations; thanks, Mert Dirik!
 (Closes: #757864)
   * Add Dutch debconf template translations; thanks, Frans Spiesschaert!
 (Closes: #767488)
   * Add Indonesian debconf template translations; thanks, Izharul Haq!
 (Closes: #835622)
   * Update README.Debian to refresh URLs and reflect developments in the
 TRS-80 retrocomputing enthusiast community over the past several years.
   * Implement debian/compare-copyright script.
 + Add "check-source" target to debian/rules to call the script.
 + Add debian/{no-,}copyright-info.expected files.
   * Migrate former contents of debian/checklist to debian/README.source.
   * Rewrite debian/copyright using machine-readable copyright info.
   * Migrate to new (to me) quilt-based Debian source format 3.0.
 + Migrate former contents of debian/patches to debian/patch/*; dropping
   patches now merged upstream.
   * Migrate former contents of debian/README.contrib-only to Disclaimer field
 of debian/copyright, and update discussion.
   * Stop shipping Tim Mann's TRS-80 FAQ document.  It's great, but strictly
 speaking, it doesn't carry a license, I don't want to pester him to put
 one on it, and in any event it updates much more frequently than the xtrs
 software itself.  Finally, I trust people to do web searches, and
 archive.org to stick around, more now than I did 19 years ago.
   * Write doc-base descriptions for the supplementary documentation in
 /usr/share/doc/xtrs.
   * Add check-binary target to debian/rules to aid regression testing.
   * Thanks to Christian Perrier, Hector Oron, Cyril Brulebois, and
 YunQiang Su for taking care of this package during my long absence.
Checksums-Sha1:
 dd71428b33a8e2aa90f8c8f51247dad042a41e33 1812 xtrs_4.

Accepted xtrs 4.9c-4 (source) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Mar 2017 09:20:32 -0400
Source: xtrs
Binary: xtrs
Architecture: source
Version: 4.9c-4
Distribution: unstable
Urgency: medium
Maintainer: G. Branden Robinson <g.branden.robin...@gmail.com>
Changed-By: G. Branden Robinson <g.branden.robin...@gmail.com>
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 511645
Changes:
 xtrs (4.9c-4) unstable; urgency=medium
 .
   * Makefile: Undefine HAVE_SIGIO.  (Closes: #511645)
   * Update Maintainer full name and email address from the "old me" to the
 "new me".
Checksums-Sha1:
 032f2eedfc1a4d260f0826d3e076cf5e482f37e0 1810 xtrs_4.9c-4.dsc
 f31203ae8c2f1cc8eceb5cb687dad8b4b5731bb1 101820 xtrs_4.9c-4.diff.gz
Checksums-Sha256:
 5f8d4d18df9bc446c257f7cc4f3af2d6d411acbc48241c0969b14b0ded9bf126 1810 
xtrs_4.9c-4.dsc
 6a14a7cd2e815bf77632b230be22640c43e0b30b2c790a916c138d18fe7e4f9a 101820 
xtrs_4.9c-4.diff.gz
Files:
 c21752b27198f31f3ce6677c18623b65 1810 contrib/otherosfs extra xtrs_4.9c-4.dsc
 75efbc8ac0abadc9b766ef1990e0907d 101820 contrib/otherosfs extra 
xtrs_4.9c-4.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAljfwuwACgkQaVt65L8G
YkCyzxAAskyuTdd9vUuayR/Cz7CfQ6kAg3sz8W03f3TaNVeC3kLDNAKXc8Bl//Dr
29pDjqek+wVQVEcQH5ZgF08968SSR0X0o2wOcl+ampodBn3sNWNbD9U29XJ5x+Aa
v5+Y5NbGgu9/XNEEdGJ7TR8V/GQe8iu2QtD6q6qXZYWNFCTEcIcAmKQjFVwWOPx0
sZo2ZdKAecIrBCuEBGVJ5KFZvSTxCeTPckRxrU5Uq5jagJ8MjVqX4ebLv6OLRKDM
r7aM9dWfLQYDRS2HLplVS24jVvBTw129uzs6EWa6v7f2X4m37qrVJJgX6SQueqA2
FVL4dWwVuJyRbJIZa/bUIqltdVs634dG84TGDVa5Pb3HUgm8PzxM6XZ2eKphlmN0
rdHDH1B38WqMLJ/yL3ki5/P/7s7XcwkCdASLZiRVEM1R4Fj1fZYk95cL9IUo7H/+
5GVhLWcDmFXuxKZbBT7GFauY+eX6IwfNmFeSStBLP44gZ0SNtLrS9Vf0s/Vk3RBJ
qeWq/5+GjGwIZq0PAKZiwGLZKXuToD5cWKFjg6r0gFoOO7Z+ebfA913A1Moku4kY
2hRh66Rd4NKGfYaDQH3dZKRwPQ8jEenVE30ifawOrrGhhdVBiNRMiai1X4ChAoAh
ubaRl3xRJOnANWg3HQLlNF04gPwgx3YPJcmkJhYVyCLJ1LJLwzU=
=TW2m
-END PGP SIGNATURE-

Accepted xtrs 4.9c-3 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 12 May 2008 02:36:30 -0400
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9c-3
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 480129
Changes: 
 xtrs (4.9c-3) unstable; urgency=low
 .
   * Update my copyright notice in debian/copyright since I wrote the help
 window patch this year.
   * Update architecture-detection logic to use a more modern interface to
 dpkg-architecture and recognize armeb.  Thanks, Riku Voipio!
 (Closes: #480129)
Checksums-Sha1: 
 565eaa23dec69756d02e1cb4cc09e5d1e6680ae4 1006 xtrs_4.9c-3.dsc
 b220cbc999306b45c6162e8a48b8a3665c840c96 59844 xtrs_4.9c-3.diff.gz
 e18f1f06c9124fd5be6d5cd4f4b31ce035b1eece 349770 xtrs_4.9c-3_powerpc.deb
Checksums-Sha256: 
 807d6b1c7b44ddbc4a88fbe3ee02cb19a9f19eabce6eb03d5d0458c81ccc6f66 1006 
xtrs_4.9c-3.dsc
 a986194b4fc1dcbd25b00f57c3b8b3afed3ad048fc2d8965ac832214a810dc4b 59844 
xtrs_4.9c-3.diff.gz
 2aeb955fc0bd651052261de96b61cc037eb56f1d02e3fa251471cebd6e39c718 349770 
xtrs_4.9c-3_powerpc.deb
Files: 
 837831be034eb38c2f7cf93a62e08935 1006 contrib/otherosfs extra xtrs_4.9c-3.dsc
 6eab47dc673725c2956b6ca66242106d 59844 contrib/otherosfs extra 
xtrs_4.9c-3.diff.gz
 8257deef8956798dc58df6962f9b2892 349770 contrib/otherosfs extra 
xtrs_4.9c-3_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAkgn6cgACgkQ6kxmHytGonzV4gCffsSquvph7rGdRfs/omHDnlvW
pIMAnRzy9z40P9yK6yYLvstujxJ7tt/5
=i+Wy
-END PGP SIGNATURE-


Accepted:
xtrs_4.9c-3.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9c-3.diff.gz
xtrs_4.9c-3.dsc
  to pool/contrib/x/xtrs/xtrs_4.9c-3.dsc
xtrs_4.9c-3_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9c-3_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Copyright question (BSD with advertisement clause)

[Branden Robinson]

[You didn't honor my M-F-T so I guess this will continue to go to both
lists.]

On Thu, Feb 07, 2008 at 12:29:29PM -0800, Russ Allbery wrote:
 Branden Robinson [EMAIL PROTECTED] writes:
 
  I believe your reasoning is faulty, because it is based on incomplete
  information.  There was more than one BSD license in use well before
  USB's Office of Technology Licensing withdrew the 4-clause version.
 
 [snip]
 
 While this is very interesting (I was aware of some of this, but not all
 of it), and I appreciate the time that you took to write it up, I think
 that:
 
 http://web.archive.org/web/19990210065944/http://www.debian.org/misc/bsd.license
 
 shows that indeed the original BSD license to which the DFSG was linked
 was the four-clause version.  (Thanks to Charles Plessey for uncovering
 that.)
 
 The version in /usr/share/common-licenses/BSD is very specifically the UCB
 version,

A major point of this whole discussion is that there is no the UCB
version.  There have been multiple BSD licenses, even promulgated by the
single source we call the University of California at Berkeley.

 not any of the other versions, and my assumption was that that had
 historically also been the case (since it wouldn't make sense to me to
 move from a less specific copyright holder to a more specific one).
[...]
 Certainly agreed; however, I was specifically talking about the UCB
 version as seen in /usr/share/common-licenses, so I was really being
 inaccurate with my original statement.

The copyright line in /usr/share/common-licenses should be made generic, or
better yet, not even be present.  Much of the benefit of the
common-licenses directory is lost if it can serve as a stand-in for
particular licenses *as applied by particular copyright holders*.

  (I have heard rumors that the OTL was in large part persuaded to drop
  the advertising clause because of threatened counter-litigation by a
  party that was violating it, who made an apparently strong argument that
  the clause was unenforceable under U.S. law.  Unfortunately, despite
  poking around for this over the years and talking to some luminaries who
  might have been aware of it--though not William Hoskins himself--I have
  been unable to substantiate it.  If this turns out to be true, Debian
  should not be recommending as a best practice licensing provisions which
  are legally void significant jurisdictions like the United States.)
 
 Note that I have never argued that Debian should be recommending the
 four-clause BSD license as best licensing practice.  It manifestly isn't.
 Only that it is and has been DFSG-free since the beginning of the concept.

First, I think you are reading far more deliberation into where the Debian
Project has pointed web links in the past, and what it's put into
/usr/share/common-licenses/BSD, than is warranted.

If I were to write some code and license it under the BSD license (in the
terms spelled out in /usr/share/common-licenses/BSD), package it, and have
my debian/copyright file refer to /usr/share/common-licenses/BSD, that
would not mean that the Regents hold the copyright on my code, nor would
such an action on my part transfer the copyright to them.

Secondly, phraseology like is and has been (and will be for all time!
usually follows in arguments like this), denies the very real phenomenon
that humans learn over time.

It would not surprise me if a majority of Debian Developers in 1997, if
surveyed on the subject, would hold the 4-clause BSD license to be
DFSG-free (with degrees of passion ranging from yeah, I guess so to
hell, yeah! It's way better than that GPL crap![1]).

I would suggest that our experiences with the GNU FDL, and with the
XFree86's projects relicensing of its code base, have taught us just how
onerous mandatory invariant testimonials can be.  While some folks may feel
that Debian was an outlier with respect to our dissent on the GNU FDL
front, it's pretty difficult to make that argument about the revised
XFree86 license, whose resemblance to the 4-clause BSD license is much more
clear.  (In fact, that was one of David Dawes's ultimately futile arguments
for trying to get the community to accept his license as free.)

If I'm not mistaken, I have argued on -legal in the past that having
section 10 of the DFSG has turned out to be a bad idea, because people
misread examples as paragons.

I think it is instructive that every single license we identified in 1997
as a good example of a free software license has seen significant revision.
The 4-clause BSD license has evolved into 3-clause and 2-clause variants,
dropping various restrictions; the Perl folks came up with a Clarified
Artistic license several years ago, and of course there is the case of the
GNU GPL v3.

Moreover, these license exemplars have been revised *by their original
promulgators*.  Consequently, I do not think you can argue that the
supersession of the licenses we originally identified as examples in 1997
is the work of upstarts who

Accepted xtrs 4.9c-2 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 07 Feb 2008 00:09:13 -0500
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9c-2
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 437302
Changes: 
 xtrs (4.9c-2) unstable; urgency=low
 .
   * When handling X Enter and Leave events, track which one we handled
 previously, and fake a Leave event before handling an Enter if the
 previous of these two events was also an Enter.  This prevents the global
 autorepeat from getting wrongly kept off when two Enter events are seen in
 a row, as can happen when the unclutter X client is used.
   * Add Portuguese debconf template translations; thanks, Américo Monteiro!
 (Closes: #437302)
   * Update TRS-80 FAQ to be based on Tim Mann's version 1.59 (2007-02-21).
   * Implement an overlay window that summarizes the first few paragraphs of
 keyboard usage information from the manpage; F11 toggles the window on and
 off.  Update the xtrs(1) manpage to mention this feature.
   * Patch Makefile.local to not explicitly link against ncurses, which is only
 used indirectly via GNU readline (brought to light by the new
 symbols-aware dpkg-shlibdeps).
   * Increment debhelper compatibility level to 5.
   * Update README.Debian and README.contrib-only.
   * Fix debian/rules to stop ignoring errors from $(MAKE) clean (he noted
 wryly, in light of who filed #325372--though in fairness this package
 doesn't use GNU Automake).
   * Update Debian menu section to Applications/Emulators per new Debian Menu
 Policy.
   * Stop shipping useless empty directory /usr/lib/menu.
   * Increment Standards-Version to 3.7.3.
Files: 
 58c2141f0212d6128f3c4a180c7cab09 644 contrib/otherosfs extra xtrs_4.9c-2.dsc
 e20ee966d6d944630d240fd3e1c6fe42 87121 contrib/otherosfs extra 
xtrs_4.9c-2.diff.gz
 3d2e947652fb7379fb8fa659a70fcac5 349682 contrib/otherosfs extra 
xtrs_4.9c-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAkeqlSoACgkQ6kxmHytGonxxFQCcC2GfiNSwa37nVv9ZuTlCCmyo
2GYAnjv1NRcur6CLT56D0wjZwDlfuWNb
=bcah
-END PGP SIGNATURE-


Accepted:
xtrs_4.9c-2.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9c-2.diff.gz
xtrs_4.9c-2.dsc
  to pool/contrib/x/xtrs/xtrs_4.9c-2.dsc
xtrs_4.9c-2_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9c-2_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted ctwm 3.7-3 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 21 Jul 2006 10:27:56 -0400
Source: ctwm
Binary: ctwm
Architecture: source powerpc
Version: 3.7-3
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 ctwm   - Claude's Tab window manager
Closes: 364239 375240
Changes: 
 ctwm (3.7-3) unstable; urgency=low
 .
   * Merge Luk Claes's NMU.  Thanks, Luk!  Luk's changes are:
 + Make ctwm pre-depend on x11-common (= 1:7.0.0).
 + Correct comment in the menu-method file.
 + I reverted Luk's deletion of the SVN Id keyword and Vim modeline in this
   changelog.  (We finally got a comment character for control files, now
   we need one for changelogs as well.  Lesson?  Never, ever, ever, ever
   make a file format that will be machine-parsed by anything without
   supporting comments.  ALGOL 60 called and wants its innovations back.)
   * I had already done the following in SVN but was too slow to release.
 Shame on me.
 + Build-depend on xutils-dev instead of xutils for the X11R7 transition.
 + Adjust debian/rules and debian/postinst to use FHS paths, moving from
   /usr/X11R6 to /usr.  Based on a patch by Steve Langasek.  Thanks, Steve!
   (Closes: #364239)
 + Point menu-method to install-menu interpreter in /usr/bin, not
   /usr/sbin, per Lintian.
 + Add empty binary-indep target in debian/rules to quiet Lintian error.
   * Fix SEGV when attempting to bring up the TwmWindows menu when no workspace
 manager is active.  Thanks to Mike O'Connor for the analysis and the
 patch! (Closes: #375240)
   * Bump Standards-Version from 3.6.2 to 3.7.2; required changes involving
 placement of files in X11 paths and pre-dependency on x11-common made as
 described above.
Files: 
 548742120f13360979a9450cc2dab870 700 x11 optional ctwm_3.7-3.dsc
 8b52a5504c8af9afb2346609ed5a42db 25351 x11 optional ctwm_3.7-3.diff.gz
 fa3353fb8dabb3b541c72d9b526f3fd9 527552 x11 optional ctwm_3.7-3_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iEYEARECAAYFAkTA6J4ACgkQ6kxmHytGonwgjACgpt490vbUuefIkpUiIllhIL1l
pTwAnRAv7fqqZBaUVzUR83VOp/3K0iyO
=q4u8
-END PGP SIGNATURE-


Accepted:
ctwm_3.7-3.diff.gz
  to pool/main/c/ctwm/ctwm_3.7-3.diff.gz
ctwm_3.7-3.dsc
  to pool/main/c/ctwm/ctwm_3.7-3.dsc
ctwm_3.7-3_powerpc.deb
  to pool/main/c/ctwm/ctwm_3.7-3_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xtrs 4.9c-1 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 15 May 2006 01:21:50 -0400
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9c-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Changes: 
 xtrs (4.9c-1) unstable; urgency=low
 .
   * Merge upstream 4.9c release.
 + Fix the new -e command-line option to IMPORT/CMD and EXPORT/CMD to
   actually work.
   * Fix non-ASCII character in Debian changelog entry for previous release.
   * Update Japanese debconf template translations to remove period from the
 end of the title of the debconf note, for consistency with the other
 translations.  Thanks to Kenshi Muto for his consulation on this issue.
   * Scale back the .hex file mtime update fix in debian/rules to just
 fakerom.hex and xtrsrom4p.hex, as in the new upstream release only these
 files are affected.
Files: 
 6fa2b0ec5cdf96d02d8084d4a31ec22f 644 contrib/otherosfs extra xtrs_4.9c-1.dsc
 92b9b1fc28b4f341452b14e28c7e302d 443651 contrib/otherosfs extra 
xtrs_4.9c.orig.tar.gz
 bf2f15fb1a2b208071e1933a32a50ba2 54567 contrib/otherosfs extra 
xtrs_4.9c-1.diff.gz
 ef2be78993ee4cd4270fe957329c338b 343448 contrib/otherosfs extra 
xtrs_4.9c-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iEYEARECAAYFAkRoFlkACgkQ6kxmHytGonyvaACgoJCKHWigENI9+iBt0LXN30kb
64cAoJZquuVhYhOZpkHTNis+wOkBqmsB
=j+QK
-END PGP SIGNATURE-


Accepted:
xtrs_4.9c-1.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9c-1.diff.gz
xtrs_4.9c-1.dsc
  to pool/contrib/x/xtrs/xtrs_4.9c-1.dsc
xtrs_4.9c-1_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9c-1_powerpc.deb
xtrs_4.9c.orig.tar.gz
  to pool/contrib/x/xtrs/xtrs_4.9c.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xtrs 4.9b-1 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 14 May 2006 01:07:16 -0400
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9b-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Changes: 
 xtrs (4.9b-1) unstable; urgency=low
 .
   * Merge upstream 4.9b release.
 + Bundle Roland Gerlach's CP/M utilties for xtrs and corresponding
   documentation.
 + Add -emtsafe command-line option to xtrs to prevent emulator traps from
   writing to unexpected places in the host filesystem.  Use this flag if
   you believe your xtrs instances may run malicious code aware of xtrs's
   traps within the emulator.
 + Add -e command-line option to the IMPORT/CMD and EXPORT/CMD utilities.
   Use this flag if your TRS‐80 operating system uses the NEWDOS/80
   convention for representing the ending record number in an open file
   control block, and this fact is not autodetected by the emulator.
 + Drop old method of importing/exporting files from the host filesystem
   using fake I/O ports.  IMPORT/BAS and EXPORT/BAS are no longer provided.
 + Merge Debian patches by Branden Robinson to add watchpoints and the
   zbxinfo command to the debugger, and make miscellaneous cleanups.
 + Merge Debian patches by Andreas Jochens to make signed/unsigned casts
   where appropriate.
   * Update CP/M utility disk documentation to point Debian users to the
 locally installed copy of the disk in /usr/lib/xtrs.
   * Drop patches to debug.c, trs_imp_exp.c, trs_cassette.c, and z80.c from
 debian/patches, as they have been merged upstream.
   * Update TRS-80 FAQ to be based on Tim Mann's version 1.58 (2006-04-22).
 + Update URLs to various TRS-80 resources.
   * Fix grammar errors in package description and remove statement claiming
 instructions on retrieving ROM images are available in the package.  This
 is no longer true, as I know of no active site offering them for download.
   * Update debian/rules to touch the mtimes on the assembled .hex files before
 invoking Make on the upstream sources; when Tim Mann renamed the Z-80
 assembly sources from .z to .z80, their mtimes got updated and
 therefore Make thinks the .hex files need to be remade, using the zmac
 assembler, which is not widely available.  This is hopefully a temporary
 kludge, and the timestamps will be fixed in the next xtrs release.
   * Add empty, phony binary-indep target to debian/rules to keep lintian
 happy.
   * Remove period from title of debconf note template, per squawking from
 lintian about section 6.5.4.2.4 of the Developers' Reference.  I went
 ahead and updated the po files for cs, da, de, es, fr, pt_BR, ru, and sv
 (Czech, Danish, German, Spanish, French, Brazilian Portuguese, Russian,
 and Swedish) and un-fuzzied them, on the wild assumption that periods
 don't belong in titles in those languages either.  I left Japanese alone
 because I do not understand its grammar and because I do not know what a
 Japanese period looks like.  Japanese translators, please consider
 un-fuzzing this translation with an appropriate update, and send a patch
 to the BTS.
   * Increment Standards-Version to 3.7.2; no changes necessary.
Files: 
 5c0fa82b43573dfa52c6413166c1ded2 644 contrib/otherosfs extra xtrs_4.9b-1.dsc
 77b93d2af5999e759976f2a2ecd6b5d7 443301 contrib/otherosfs extra 
xtrs_4.9b.orig.tar.gz
 e291b67c863872d0f6c15c9f3ed2f80e 54422 contrib/otherosfs extra 
xtrs_4.9b-1.diff.gz
 95b996feb2e7d2d2d434fd245c8577e9 342570 contrib/otherosfs extra 
xtrs_4.9b-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iEYEARECAAYFAkRmwT0ACgkQ6kxmHytGonySVwCgn6Pf2hc12Al2Hc9zkGSyzx/x
WckAn0XtYQaplBAIXtSdqyvsp0YQdvOI
=2X8D
-END PGP SIGNATURE-


Accepted:
xtrs_4.9b-1.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9b-1.diff.gz
xtrs_4.9b-1.dsc
  to pool/contrib/x/xtrs/xtrs_4.9b-1.dsc
xtrs_4.9b-1_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9b-1_powerpc.deb
xtrs_4.9b.orig.tar.gz
  to pool/contrib/x/xtrs/xtrs_4.9b.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted vtwm 5.4.7-2 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun,  6 Nov 2005 09:44:15 -0500
Source: vtwm
Binary: vtwm
Architecture: source powerpc
Version: 5.4.7-2
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 vtwm   - Virtual Tab Window Manager
Changes: 
 vtwm (5.4.7-2) unstable; urgency=low
 .
   * Add build-dependency on librplay3-dev to fix FTBFS (librplay3-dev does not
 depend on libc6-dev for some reason, so I didn't catch this when scrubbing
 my chroot.  Sigh.)
Files: 
 219cbf65ce8dc8cdc7b9903419bfe382 687 x11 optional vtwm_5.4.7-2.dsc
 e54381ba55b7d61b09962f3a1ef54905 16493 x11 optional vtwm_5.4.7-2.diff.gz
 49c4016aedf84299726b8c65d03e5d16 222330 x11 optional vtwm_5.4.7-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkNuHIAACgkQ6kxmHytGonymkQCfYNOWg8PllkLEXy3MO/Oi3IcI
/FkAn3a9uQggCV5OFBRY1OlockoV/SI3
=98U/
-END PGP SIGNATURE-


Accepted:
vtwm_5.4.7-2.diff.gz
  to pool/main/v/vtwm/vtwm_5.4.7-2.diff.gz
vtwm_5.4.7-2.dsc
  to pool/main/v/vtwm/vtwm_5.4.7-2.dsc
vtwm_5.4.7-2_powerpc.deb
  to pool/main/v/vtwm/vtwm_5.4.7-2_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xtrs 4.9a-2 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  5 Nov 2005 11:42:38 -0500
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9a-2
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 319855 330443
Changes: 
 xtrs (4.9a-2) unstable; urgency=low
 .
   * Update README.Debian to stop documenting now-defunct site where Model I
 and Model III ROM images can  be obtained.  Also migrate /usr/doc
 references to /usr/share/doc.
   * Update comment in z80.c to make it more legible (submitted upstream).
   * Tweak zbx debugger UI (submitted upstream):
 + Report maximum number of traps when user tries to set too many.
 + Inform user of existence of help command when entering debugger.
 + Implement zbxinfo command, which credits authors, reports number of
   traps set, size of address space, maximum length of zbx command line,
   and whether GNU Readline support is enabled.  Document existence of
   zbxinfo command in help output.
 + Kill off hard tab in help output.
   * Implement watch command in zbx debugger, providing the ability to set
 watchpoints on addresses in memory (submitted upstream).
   * Add upstream location of TRS-80 FAQ to Debian copyright file.
   * Update TRS-80 FAQ to be based on Tim Mann's version 1.57 (2005-09-17).
 + Update question 14: What are the differences among single, double, quad,
   and high density floppy media?
 + Add question 26: How can I read the back of a disk that was written in a
   flippy drive?
   * Add Czech debconf template translations; thanks, Katarína Bubli
 Machálková!  (Closes: #319855)
   * Add Swedish debconf template translations; thanks, Daniel Nylander!
 (Closes: #330443)
   * Bump Debian standards version to 3.6.2; no changes needed.
Files: 
 885425e1c3faacf642a6fa71ad71901a 644 contrib/otherosfs extra xtrs_4.9a-2.dsc
 df3a38c3cccb5c94f30e96e70acdd61e 58108 contrib/otherosfs extra 
xtrs_4.9a-2.diff.gz
 b74678b997816c86a46b5f943a897eaf 336282 contrib/otherosfs extra 
xtrs_4.9a-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkNs4u8ACgkQ6kxmHytGonwgTwCcCdURqQFIQi5RqufKT8ApvHfj
BngAn2u8p7DMkRtbcfesW2mwRD8WkZVD
=ogs0
-END PGP SIGNATURE-


Accepted:
xtrs_4.9a-2.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9a-2.diff.gz
xtrs_4.9a-2.dsc
  to pool/contrib/x/xtrs/xtrs_4.9a-2.dsc
xtrs_4.9a-2_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9a-2_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted vtwm 5.4.7-1 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  5 Nov 2005 19:35:41 -0500
Source: vtwm
Binary: vtwm
Architecture: source powerpc
Version: 5.4.7-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 vtwm   - Virtual Tab Window Manager
Closes: 319510
Changes: 
 vtwm (5.4.7-1) unstable; urgency=low
 .
   * Merge new upstream release.
 + This release is dedicated to the memory of David J. Hawkey, Jr., who
   passed away in 2004.  VTWM is now team-developed by the VTWM hackers at
   http://www.vtwm.org/, and Callum Gibson is the release manager.
 + See /usr/share/doc/vtwm/HISTORY for a comprehensive list of new
   features, behavior changes, and bug fixes.
   * Bump Debian standards version to 3.6.2; no changes necessary.
   * Update URL in package description.
   * Tweak Debian rules file:
 + Explicitly set optimization to -O0 if DEB_BUILD_OPTS contains noopt.
 + Export the CDEBUGFLAGS variable instead of manually passing it to Make.
 + Make shell style tweaks.
   * Remove Debian patch to remove increment of yylineno variable from parse.c;
 upstream has #ifdefed it out so that it can be restored for systems
 where lex doesn't define and use this variable for itself.
   * Ship more upstream documentation files: 4.6.ANNOUNCE, 4.6.README,
 4.7.README, DEVELOPERS, HISTORY, and SOUND.
   * Remove SunkFocusWindowTitle configuration parameter from
 debian/system.vtwmrc-menu, since it is no longer supported.
   * Fix menu-method file to background launched apps, so the window manager
 doesn't wedge.  Whoops.  Thanks to Matthew A. Micholson for the patch!
 (Closes: #319510)
Files: 
 8e5b970730f5f33e6157f06c5acd2d06 672 x11 optional vtwm_5.4.7-1.dsc
 707f8d93b19b46fb3d036053be66288b 1021160 x11 optional vtwm_5.4.7.orig.tar.gz
 88c2496ca8af82497399708b75881914 15834 x11 optional vtwm_5.4.7-1.diff.gz
 52121c307119cd41d689eaa6fbd44355 30 x11 optional vtwm_5.4.7-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkNtUe0ACgkQ6kxmHytGonzuwwCaA8wkZHlslWuUM+yiA6BB1IN+
VCoAoIJFoPj0JL70YvPNDxxCWnk3+dJZ
=V+Fj
-END PGP SIGNATURE-


Accepted:
vtwm_5.4.7-1.diff.gz
  to pool/main/v/vtwm/vtwm_5.4.7-1.diff.gz
vtwm_5.4.7-1.dsc
  to pool/main/v/vtwm/vtwm_5.4.7-1.dsc
vtwm_5.4.7-1_powerpc.deb
  to pool/main/v/vtwm/vtwm_5.4.7-1_powerpc.deb
vtwm_5.4.7.orig.tar.gz
  to pool/main/v/vtwm/vtwm_5.4.7.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted ctwm 3.7-1 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  2 Nov 2005 13:03:57 -0500
Source: ctwm
Binary: ctwm
Architecture: source powerpc
Version: 3.7-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 ctwm   - Claude's Tab window manager
Changes: 
 ctwm (3.7-1) unstable; urgency=low
 .
   * Merge upstream 3.7 release.
 + The upstream maintainer is now Richard Levitte, not Claude Lecommandeur.
 + Add workspace context for keybindings.
 + Add AlwaysSqueezeToGravity configuration keyword and feature.
 + Add TwmKeys and TwmVisible menus.
 + Implement preliminary GNOME compliance (see README.gnome and TODO.gnome
   in /usr/share/doc/ctwm.)
 + Add IconifyStyle configuration keyword and feature for fancy graphical
   effects.
 + Add JPEG/JFIF image support, using jpeg:filename syntax.
 + Add f.showbackground action, which unmaps all windows in the current
   workspace.
 + Add preliminary support for Xinerama extension using the VirtualScreens
   configuration keyword.
 + Change Imakefile to support a distribution target.
 + Change :xpm:cross to be a bit larger, appear more three-dimensional, and
   be more visible even in very dark configurations.
 + Make AlwaysSqueezeToGravity work for all windows if no window list is
   given.
 + Add NoImagesInWorkSpaceManager configuration keyword and feature which
   prevents background images from being displayed in the workspace map.
 + Add -cfgchk command-line option, which simply performs a parse check on
   the configuration file, without launching the window manager.
 + Change the behavior of DontMoveOff/MoveOffResistance (see upstream
   changelog).
 + Change behavior of random placement to respect DontMoveOff (see upstream
   changelog).
 + Change f.warpring action so that the icon manager doesn't get enter and
   leave events if IconManagerFocus is set.
 + Add f.movetoprevworkspace, f.movetonextworkspace,
   f.movetoprevworkspaceandfollow, and f.movetonextworkspaceandfollow
   actions (see upstream changelog).
 + Add vertical as a parameter to the f.fill action (see upstream
   changelog).
 + Add hack to ensure that a window that had been maximized keeps the focus
   when it is restored to its previous size.
 + Fix f.zoom action to stop moving the window up.
 + Add IgnoreTransient configuration keyword and feature to ignore a
   specified list of transient windows.
 + Optimize workspace switch performance by preventing redraws of windows
   that occupy all workspaces when switching workspaces.
 + Make ctwm aware of the mysterious GTK+ group leader windows.
 + Fix BorderResizeCursors to work for top and left borders when
   non-3D-borders are used.
 + Stop GetWMPropertyString() from leaking memory.
 + Fix bug in f.warpring action where the pointer would be moved to the
   right and end up outside the title bar.
 + Fix bug in f.warpring action where if the active window was closed and
   the cursor ended up in the root window, it wouldn't move until moved
   with a pointer motion event.
 + Add NoWarpToMenuTitle configuration keyword to keep the cursor from
   warping to the menu title if the menu won't fit on the screen below the
   current cursor position.
 + Initialize Scr-workSpaceMgr.windowFont.
 + Add support for full GNU regular expressions in window and class names
   by defining USE_GNU_REGEX in the Imakefile (disabled by default).
 + Add DontToggleWorkSpaceManagerState configuration keyword to turn off
   the feature which toggles the workspace manager state between map and
   button when the control key is pressed and the workspace manager window
   is in focus.
 + Add a TWMAllIcons menu, which lists all iconified windows on all
   workspaces.
 + Add f.changesize action, which allows you to change the size of the
   focused window bia menus and key bindings.
 + Fix focus problems with f.changesize action and add ability to set a new
   fixed window size.
 + Update email address used for upstream bug reports when ctwm crashes.
 + Convert all KR function headers to use ANSI C prototypes.
 + Only use the DefaultFunction if no function was found.
 + Modify random placement algorithm when DontMoveOff is set (see upstream
   changelog).
 + Fix bug where resizing windows from the menu when not using 3D borders
   would move the target window down and right by a border width.
 + Enhance info window to include the outer geometry and 3D border width.
 + Rework SIGHUP handler to set a global flag and have CtwmNextEvent()
   react to it by calling DoRestart(). [BR: I think this is how W. Richard
   Stevens and other Unix gurus have been telling people how

Accepted ctwm 3.7-2 (source powerpc)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  2 Nov 2005 15:00:00 -0500
Source: ctwm
Binary: ctwm
Architecture: source powerpc
Version: 3.7-2
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 ctwm   - Claude's Tab window manager
Changes: 
 ctwm (3.7-2) unstable; urgency=low
 .
   * Add build-dependency on libjpeg62-dev to fix FTBFS.  Shame on me for not
 building in a clean chroot.
Files: 
 131162ca0f50399723613c0564291d39 696 x11 optional ctwm_3.7-2.dsc
 24470594677ed866c4bd40f79169db1c 24006 x11 optional ctwm_3.7-2.diff.gz
 ecee8d3f3359af0e9f20250a67cced96 525662 x11 optional ctwm_3.7-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkNpJOUACgkQ6kxmHytGonwUlwCgiFh6E/lUFH1iN0J47pSjBNGf
faYAnjjRo0NDQLY7iSPBxcf508pSEfa8
=ZWpb
-END PGP SIGNATURE-


Accepted:
ctwm_3.7-2.diff.gz
  to pool/main/c/ctwm/ctwm_3.7-2.diff.gz
ctwm_3.7-2.dsc
  to pool/main/c/ctwm/ctwm_3.7-2.dsc
ctwm_3.7-2_powerpc.deb
  to pool/main/c/ctwm/ctwm_3.7-2_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Branden Robinson]

Anthony Towns wrote:
   Looking at the source it seems more based on than inspired by,
   particular to rpmstrap itself, though the functions and scripts/*
   files sure seem more derivative than just coincidently similar. If
   so, it's in violation of debootstrap's license (by not including
   debootstrap's copyright text), and it seems fairly rude to relicense it
   from debootstrap's BSD-ish license to GPLv2+, not to mention expunging
   my name and copyright notice from the source, and for that matter all
   references to debootstrap.
   
   Removing the copyright's a license violation, and presumably renders the
   program undistributable and unpackagable, afaics.
   
   At least Bastian Blank's cdebootstrap was written from scratch to
   justify its different license and lack of recognition. Colour me
   unimpressed.

Sam Hart wrote:
  For what it's worth, rpmstrap as it is today is actually based on a tool
  developed in house at Progeny. This tool could only bootstrap Fedora
  Core 2 at a specific revision. Looking at that code now and comparing it
  to what I see inside of debootstrap, the only real similarities I see
  are that they both have functions common to /many/ other shell scripts
  (usage(), die(), warn(), trace()).

Anthony, I've been using shell functions with these names (and the
expected corresponding behaviors) in shell scripts I write for years
now, so you're probably going to need to accuse me of copyright
infringement in shell-lib.sh[1] in the XFree86 and X.Org packages as well.

  I will have to check the legacy on this tool used internally at Progeny
  to ensure nothing came from debootstrap, but to the best of my knowledge
  it did not. In fact, looking at this internal tool now, it is only 314
  lines of code, 153 of which are lists of FC2 packages, so it doesn't
  seem likely to share any common ancestry with debootstrap.
 
 I have just been given permission to post the original internal tool
 used at Progeny which rpmstrap is based upon, in case anyone would care
 to check the legacy for debootstrap code.
 
 This original tool was also called rpmstrap and was written from
 scratch by Branden Robinson. It does not contain any code borrowed from
 debootstrap.

I assert this to be the case.  I'm easily capable of writing the trivial
shell script that constitutes the original rpmstrap, and the
modifications I made to it subsequently.

For your edification, I'm attaching the SVN commit log for rpmstrap up
to and including my last change to it.  None of this is rocket science.

Oh, what the hell, how about I attach the diff of each commit as well,
making it all the easier to identify the exact spots where I absconded
with debootstrap code, mustache twitching!

 The first appearance of rpmstrap in the internal Progeny svn is the
 following code:
 http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap-original
 
 The most current revision of rpmstrap in the same svn is:
 http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap
 
 This is the actual base for what is now rpmstrap as I maintain. It is
 also why the current rpmstrap is GPLv2.
 
 The one thing I have just realized is that the current rpmstrap script
 does not actually have Branden's name in it as an author (although his
 name does exist in some of the suite scripts). I will rectify this
 shortly and apologize for the oversight.

Well, only if there's any of my original nasty kludge *left*.  I kind of
hope it isn't.  :)  (Okay, you can keep usage()/trace()/warn()/die(),
but as for the rest... :) )

The original rpmstrap I wrote was done in haste, but it was not
plagiarized.  The accusation would be amusing if it weren't so
insulting.

[1] http://necrotic.deadbeast.net/svn/xorg-x11/trunk/debian/shell-lib.sh

(There, trace() is not present, but a similar function, observe(),
is.  Neither function is an example of anything more than highly
trivial and idiomatic shell usage.)

-- 
Branden Robinson  | GPG signed/encrypted mail welcome
[EMAIL PROTECTED]   | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
  | 72E8 0F42 191A 9C0B CBFB

r16721 | branden | 2005-02-15 12:06:40 -0500 (Tue, 15 Feb 2005) | 2 lines

Install i386, not i686, version of openssl on x86_64 systems.


r15950 | branden | 2004-10-01 12:22:58 -0500 (Fri, 01 Oct 2004) | 3 lines

Fix erroneous architecture string in x86 glibc package for
x86_64.


r15943 | branden | 2004-09-29 15:35:44 -0500 (Wed, 29 Sep 2004) | 13 lines

Add command-line options -h | --help, -l | --list, and -v |
--verbose.

The new -l | --list feature simply prints the list of required
RPMs and exits.

Stop hard-coding target directory name.  Make the user specify
it as an operand.

Add usage message.

Improve

Re: Documentation of alioth?

[Branden Robinson / Debian Project Leader]

On Mon, Aug 29, 2005 at 06:56:56PM +0200, Raphaël Hertzog wrote:
 Le lundi 29 août 2005 à 11:42 -0500, Branden Robinson / Debian Project
 Leader a écrit :
  Eh?  What exactly did I say?
 
 Overfiend wiggy: if anyone from d-a is responding to any of the offers
 they're getting, they're not CCing me.
 Overfiend And we all know how much good it will do if I cheerfully
 accept hardware that d-a refuses to touch.

Oh, that.  :)

   It looks like the actual problem is more lack of donors and the fact
   that Branden is not willing to spend money on it.
  
  Actually, I was contacted just very recently by a potential hardware donor
  that should have some pretty reasonable iron at its disposal.
  
  I don't rule out cash expenditures on hardware in general, but when we're
  seeking entire machines, I'd rather exhaust donation opportunties first.
 
 I have no problem with that but we should also avoid waiting for ever
 when the donor doesn't come.
 
 I hope the issue will be solved until the end of the year. :-)

It's not my intention to wait *that* long.  I know of several outstanding
offers of hardware.  Not all may be a perfect fit, but I'd be surprised if
all of them were unsatisfactory.

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Re: Documentation of alioth?

[Branden Robinson / Debian Project Leader]

[Gack, what a nasty CC line.  Is all that really necessary?]

On Fri, Aug 26, 2005 at 12:23:14PM +0200, Raphaël Hertzog wrote:
 Le vendredi 26 août 2005 à 12:04 +0200, Martin Schulze a écrit :
  Hi Raphaël,
 
 Hi Joey,
 
  I'm sorry, but I have to tell you that you're wrong in your assertion.
 
 I've been corrected by Wiggy on IRC too. Although what I said before was
 not invented, I've read part of it in #debian-devel in the mouth of
 Overfiend (Branden)...

Eh?  What exactly did I say?

 It looks like the actual problem is more lack of donors and the fact
 that Branden is not willing to spend money on it.

Actually, I was contacted just very recently by a potential hardware donor
that should have some pretty reasonable iron at its disposal.

I don't rule out cash expenditures on hardware in general, but when we're
seeking entire machines, I'd rather exhaust donation opportunties first.
As far as I can tell, they haven't yet been exhausted.  When we just need
parts, the main thing I need is a proposal that enumerates what is to be
purchased and includes a cost breakdown (or at least a bottom-line figure
including taxes and shipping costs).

I don't categorically rule anything out in the case of an emergency.  It's
been my impression that the situation with alioth is uncomfortable as
opposed to emergent.

 Maybe a brief status of the hardware donations people would be nice ?

Yes, I'd love to see such a report myself.  :)

  Also DSA does not have anything to do with ftpmaster work.  The
  ftpmaster people organise themselves on their own.

Well, in theory, when a task crosses a lane of responsibility from
ftpmaster to DSA and back, these people do actually communicate with each
other.

(I *did* say in theory...)

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Branden Robinson]

On Tue, Jun 14, 2005 at 01:38:53PM +0100, Matthew Garrett wrote:
 Julien BLACHE [EMAIL PROTECTED] wrote:
 
  Their trademark policy is something that should not exist in a free
  software context. They don't care about free software. They don't care
  about distributors/vendors.
 
 What is DFSG 4 if not a grudging acceptance of this sort of behaviour as
 free?

Integrity of The Author's Source Code

The license may restrict source-code from being distributed in modified
form _only_ if the license allows the distribution of patch files with
the source code for the purpose of modifying the program at build time. The
license must explicitly permit distribution of software built from modified
source code. The license may require derived works to carry a different
name or version number from the original software. (This is a compromise.
The Debian group encourages all authors not to restrict any files, source
or binary, from being modified.)

The point of DFSG 4, as I understand it, is to permit the licensor to take
certain explicit steps to prevent people from drawing the inference that
the licensor endorses modified versions in any way.

I think if DFSG 4 had intended to grant licensors broad latitude to invent
novel ways of prevent such an inference from being drawn, it would have
been worded differently -- or, at least, the last two sentences would have
been.

In my opinion, DFSG 4 somewhat clumsily lumps together two related but
distinguishable issues -- one is a presentation format for distribution,
the other is a means for the work to identify itself.

-- 
G. Branden Robinson| Religious bondage shackles and
Debian GNU/Linux   | debilitates the mind and unfits it
[EMAIL PROTECTED] | for every noble enterprise.
http://people.debian.org/~branden/ | -- James Madison


signature.asc
Description: Digital signature

new delegates: Package Policy Committee

[Branden Robinson / Debian Project Leader]

I'm pleased to announce the delegation (under §5.1.1 of the Debian
Constitution[1]) of formal authority to the present team of editors who handle
the Debian Policy Manual[2].

I hereby appoint the following individuals to serve as delegates of the Debian
Project Leader, in the role of members (including a chair) of a Package Policy
Committee:

* Manoj Srivastava, chair
* Andreas Barth
* Matt Zimmerman

The Package Policy Committee shall have authority to:
* maintain one or more documents defining standards of Debian technical
  policy applicable to the content of software and other works distributed
  by the Debian Project as components of its products (packages);
* define levels of conformance with the above standards they establish and
  document; and
* publish authoritative findings regarding the degree of conformance that
  packages exhibit with respect to the above standards.

All members of the Package Policy Committee are delegates of the Debian
Project Leader.

The Package Policy Committee shall have a chair, appointed to the post by
the Debian Project Leader, who serves as the official representative of
the Committee to the Debian Project Leader.

It is the sense of the Debian Project Leader that while overlap in
membership between the Package Policy Committee and the Technical Committee
(see §6 of the Debian Constitution) is permitted, at least one member of the
Package Policy Committee should not be a member of the Technical Committee.
Ideally, provided sufficiently qualified and trusted individuals are available
to fill both teams, there should be little overlap in membership, so that the
bodies have mutual independence.

[1] http://www.debian.org/devel/constitution
[2] http://www.debian.org/doc/debian-policy/

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Accepted libxrender 1:0.9.0-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 17 Jun 2005 17:07:31 -0500
Source: libxrender
Binary: libxrender1-dbg libxrender-dev libxrender1
Architecture: source powerpc
Version: 1:0.9.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
Changes: 
 libxrender (1:0.9.0-1) unstable; urgency=low
 .
   * Merge upstream 0.9.0 release (0.8.4 was skipped and saw no Debian package
 release).
 .
   * Rename source package to libxrender to track upstream change.
 .
   * Forward-port Debian-specific patches:
 + Define (in acinclude.m4) and use (in configure.ac)
   AC_PATH_XTRA_CORRECTED.
 + Define AM_MAINTAINER_MODE in configure.ac.
 .
   * Regenerate Makefile.in, aclocal.m4, and configure.
 .
   * Account for new shared library version (1.2.2 - 1.3.0):
 + Update names of installed files in libxrender1{,-dbg}.install.
 + Define DEB_DH_MAKESHLIBS_ARGS_libxrender1 CDBS variable in debian/rules;
   dependent packages will now depend on libxrender1 ( 1.3.0).
 .
   * Update copyright notices in files that claimed their copyright was held by
 Software in the Public Interest, Inc. (SPI) to assert copyright ownership 
by
 Branden Robinson.  Branden never signed a written instrument transferring
 ownership of any copyrights to SPI; therefore, under U.S. law as Branden
 understands it at least, no such transfer ever took place.
 .
   * Change license terms on Debian packaging to use original MIT/X11 license
 wording (without the anti-publicity clause later added by X.Org), instead
 of the different language used by Keith Packard upstream.
Files: 
 3588846a59a881356e9a3b69d27b184d 744 x11 optional libxrender_0.9.0-1.dsc
 df6efe087786f9082e3a0e8588eea8ab 308650 x11 optional 
libxrender_0.9.0.orig.tar.gz
 27fd0549e8a2eddc2d988ec4c658df12 45866 x11 optional libxrender_0.9.0-1.diff.gz
 162b2a6ded2b3fa4c07ab24da8eee6f6 30084 libs optional 
libxrender1_0.9.0-1_powerpc.deb
 4b1cdead502b8076f870936ecd9bffeb 540500 libdevel extra 
libxrender1-dbg_0.9.0-1_powerpc.deb
 ca75e31cf24b7d2d55d23eaa81566b02 32550 libdevel optional 
libxrender-dev_0.9.0-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iEYEARECAAYFAkK2Z7YACgkQ6kxmHytGony1YwCggi2rIpO1QYxd1f2Gp4Glc7yj
+7cAnj8NLjazXdFyOmuYL4BHp+F7kgPk
=bk5E
-END PGP SIGNATURE-


Accepted:
libxrender-dev_0.9.0-1_powerpc.deb
  to pool/main/libx/libxrender/libxrender-dev_0.9.0-1_powerpc.deb
libxrender1-dbg_0.9.0-1_powerpc.deb
  to pool/main/libx/libxrender/libxrender1-dbg_0.9.0-1_powerpc.deb
libxrender1_0.9.0-1_powerpc.deb
  to pool/main/libx/libxrender/libxrender1_0.9.0-1_powerpc.deb
libxrender_0.9.0-1.diff.gz
  to pool/main/libx/libxrender/libxrender_0.9.0-1.diff.gz
libxrender_0.9.0-1.dsc
  to pool/main/libx/libxrender/libxrender_0.9.0-1.dsc
libxrender_0.9.0.orig.tar.gz
  to pool/main/libx/libxrender/libxrender_0.9.0.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted libxrender 1:0.9.0-2 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 20 Jun 2005 01:59:31 -0500
Source: libxrender
Binary: libxrender1-dbg libxrender-dev libxrender1
Architecture: source powerpc
Version: 1:0.9.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
Changes: 
 libxrender (1:0.9.0-2) unstable; urgency=medium
 .
   * Make source package's build-dependency and -dev package's dependency on
 render-dev versioned at ( 1:0.9); this will prevent FTBFSes of libxrender
 itself, and of libxrender1-dependent packages that use the new features in
 version 0.9 of the RENDER extension exposed by this library.
Files: 
 1604e181177ec7ec24ad541cbc570f50 755 x11 optional libxrender_0.9.0-2.dsc
 b38d8aa450cdc8dd311062d4130bca00 45981 x11 optional libxrender_0.9.0-2.diff.gz
 5f5934b6225faa20c8d9e3e8b14e640f 30186 libs optional 
libxrender1_0.9.0-2_powerpc.deb
 1c26d867123abfaecc68cdb33048908a 540610 libdevel extra 
libxrender1-dbg_0.9.0-2_powerpc.deb
 98f9a7d2ef50b6b9173d7bfd6420b07e 32640 libdevel optional 
libxrender-dev_0.9.0-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iEYEARECAAYFAkK2bxIACgkQ6kxmHytGonzjBACeIScNVEiz0PM2GpGtoBSsHQKb
k2sAoIB0kNGjqX7Mrv8i6bOJWXRLjX+2
=LLt3
-END PGP SIGNATURE-


Accepted:
libxrender-dev_0.9.0-2_powerpc.deb
  to pool/main/libx/libxrender/libxrender-dev_0.9.0-2_powerpc.deb
libxrender1-dbg_0.9.0-2_powerpc.deb
  to pool/main/libx/libxrender/libxrender1-dbg_0.9.0-2_powerpc.deb
libxrender1_0.9.0-2_powerpc.deb
  to pool/main/libx/libxrender/libxrender1_0.9.0-2_powerpc.deb
libxrender_0.9.0-2.diff.gz
  to pool/main/libx/libxrender/libxrender_0.9.0-2.diff.gz
libxrender_0.9.0-2.dsc
  to pool/main/libx/libxrender/libxrender_0.9.0-2.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted renderext 1:0.9-1 (all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 16 Jun 2005 12:09:26 -0500
Source: renderext
Binary: render-dev
Architecture: source all
Version: 1:0.9-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 render-dev - X Rendering Extension header files and documentation
Closes: 312953
Changes: 
 renderext (1:0.9-1) unstable; urgency=low
 .
   * Merge new upstream 0.9 release.  (Closes: #312953)
 + The following symbols are new:
   - constants: sz_xSpanFix, sz_xTrap, sz_xRenderAddTrapsReq
   - structures: xSpanFix, xTrap, xRenderAddTrapsReq
 If you #include X11/extensions/renderproto.h and use any of the above
 symbols, you will need to declare a versioned dependency and/or
 build-dependency on render-dev (= 1:0.9-1).
 .
   * Rename source package to renderext to follow upstream rename.
Files: 
 34f954d68d7deeef8298d2376784e5a0 638 libdevel optional renderext_0.9-1.dsc
 ddb63b719699b5c093df5235f5ef4341 63716 libdevel optional 
renderext_0.9.orig.tar.gz
 69ce5a81533341f512585ae9e9ff665f 3601 libdevel optional renderext_0.9-1.diff.gz
 9116630f293f6974b2b9581eb48de101 26148 libdevel optional 
render-dev_0.9-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iEYEARECAAYFAkKxwSoACgkQ6kxmHytGonzAAQCeI/kPndapm8GYF27CsvCgiF2z
nl4AoJSQfd9HkEq7l3P5mPR/YtIpiroS
=AT2T
-END PGP SIGNATURE-


Accepted:
render-dev_0.9-1_all.deb
  to pool/main/r/renderext/render-dev_0.9-1_all.deb
renderext_0.9-1.diff.gz
  to pool/main/r/renderext/renderext_0.9-1.diff.gz
renderext_0.9-1.dsc
  to pool/main/r/renderext/renderext_0.9-1.dsc
renderext_0.9.orig.tar.gz
  to pool/main/r/renderext/renderext_0.9.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Debian Project Leader report for 2005-05-08

[Branden Robinson / Debian Project Leader]

 Linux Format, but unfortunately was unable to get my
response to him because he's `blocking my mail`_.  A freelancer for the
`Gartner Group`_ also contacted me with a very long message, to which
I'm not sure how to reply yet.

Conclusion
--
I'm curious to know how you feel I am fulfilling my responsibilities as
Debian Project Leader.  You can reach me at [EMAIL PROTECTED]

``$Id: 2005-05-08.rst 170 2005-05-09 06:07:42Z branden $``

.. _Sarge has frozen: 
http://lists.debian.org/debian-devel-announce/2005/05/msg1.html
.. _release critical bugs: http://bugs.debian.org/release-critical/
.. _first DPL report: 
http://people.debian.org/~branden/dpl/reports/2005-04-24.html
.. _Simtec Hardware: http://www.simtec.co.uk/
.. _Xandros: http://www.xandros.com/
.. _listed as down and being relocated: 
http://db.debian.org/machines.cgi?host=rameau
.. _Software in the Public Interest, Inc.: http://www.spi-inc.org/
.. _members of SPI: http://www.spi-inc.org/membershipguidelines
.. _Debian UK Society: http://wiki.earth.li/DebianUKSociety
.. _Debian UK Society Treasurer's report for April 2005: 
http://www.chiark.greenend.org.uk/pipermail/debian-uk/2005-May/010317.html
.. _ffis e.V.: http://www.ffis.de/
.. _blocking my mail: http://deadbeast.net/~branden/homepage/mailblock.html
.. _Associação SoftwareLivre.org: http://www.softwarelivre.org/
.. _Linux Australia: http://www.linux.org.au/
.. _Skolelinux: http://www.skolelinux.org/no/
.. _Hardware Donations Team: http://www.debian.org/donations#equipment_donations
.. _minutes of the 24 April DPL Team meeting: 
http://lists.debian.org/debian-project/2005/04/msg00401.html
.. _brief IRC interview with Sean Michael Kerner: 
http://www.internetnews.com/dev-news/article.php/3500321
.. _Congrés de Programari Lliure: http://www.lliurex.net/congresii/val/index.htm
.. _FISL 6.0: http://fisl.softwarelivre.org/6.0/
.. _presentation on where Debian is going: 
http://fisl.softwarelivre.org/papers/pub/
.. _Gartner Group: http://www.newsfactor.com/story.xhtml?story_id=27311

.. vim:set ai et sts=4 sw=4 tw=72:

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Accepted render 1:0.8-1 (all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  9 May 2005 13:53:44 -0500
Source: render
Binary: render-dev
Architecture: source all
Version: 1:0.8-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 render-dev - X Rendering Extension header files and documentation
Changes: 
 render (1:0.8-1) unstable; urgency=low
 .
   * Sponsored upload of package prepared at Branden's request by Josh Triplett
 [EMAIL PROTECTED].
 .
   * Re-upload 0.8-4 as epoched version 1:0.8-1 to supersede hijack
 of package.  No other changes were made.
Files: 
 d423bbfc1ee118317f0cd111000cc175 629 libdevel optional render_0.8-1.dsc
 59233e186243574a5f2f2e00be972cee 3395 libdevel optional render_0.8-1.diff.gz
 d1f68f541032b89b3d8a2dbbe0af9da5 25214 libdevel optional 
render-dev_0.8-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iEYEARECAAYFAkKARxsACgkQ6kxmHytGonzreQCffXat7mN2v1HnbThIAsOnNMAE
AgAAoJ5CEfXf1pi49SWLiJoyMhNX5deU
=j8tY
-END PGP SIGNATURE-


Accepted:
render-dev_0.8-1_all.deb
  to pool/main/r/render/render-dev_0.8-1_all.deb
render_0.8-1.diff.gz
  to pool/main/r/render/render_0.8-1.diff.gz
render_0.8-1.dsc
  to pool/main/r/render/render_0.8-1.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xrender 1:0.8.3-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  9 May 2005 14:05:22 -0500
Source: xrender
Binary: libxrender1-dbg libxrender-dev libxrender1
Architecture: source powerpc
Version: 1:0.8.3-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
Closes: 257187 280092
Changes: 
 xrender (1:0.8.3-1) unstable; urgency=low
 .
   * Sponsored upload of package prepared at Branden's request by Josh Triplett
 [EMAIL PROTECTED].
 .
   * Re-upload 0.8.3-1 as epoched version 1:0.8.3-1 to supersede hijack of
 package.
 .
   * Tell configure to put include files in /usr/X11R6/include, rather than
 installing include files from debian/tmp/usr/include to
 /usr/X11R6/include, which caused pkg-config and libtool to think they
 should be in /usr/include.  (Closes: #257187, #280092)
 - debian/rules: set DEB_CONFIGURE_INCLUDEDIR.
 - debian/libxrender-dev.install: Install Xrender.h from
   /usr/X11R6/include, rather than moving it from /usr/include.
Files: 
 d3f0d63b9f1f3051dc7fe9050f069963 736 x11 optional xrender_0.8.3-1.dsc
 8e74cd624bd62ea2c9e28ecbf9d47322 230561 x11 optional xrender_0.8.3-1.diff.gz
 8096e7266e5747799fd78f727a8b46c5 28282 libs optional 
libxrender1_0.8.3-1_powerpc.deb
 dd116f875da7e01ff758f637b5d9cfa8 498298 libdevel extra 
libxrender1-dbg_0.8.3-1_powerpc.deb
 195a5930f73d10df6a0a7acdc5f51f4f 30490 libdevel optional 
libxrender-dev_0.8.3-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iEYEARECAAYFAkKASAsACgkQ6kxmHytGonxkdwCgnJMkQVxa/BU5NnezixOYjsAs
64gAnR5PhKLBOCPmAQHUtrcNaHF4XMsG
=VOJv
-END PGP SIGNATURE-


Accepted:
libxrender-dev_0.8.3-1_powerpc.deb
  to pool/main/x/xrender/libxrender-dev_0.8.3-1_powerpc.deb
libxrender1-dbg_0.8.3-1_powerpc.deb
  to pool/main/x/xrender/libxrender1-dbg_0.8.3-1_powerpc.deb
libxrender1_0.8.3-1_powerpc.deb
  to pool/main/x/xrender/libxrender1_0.8.3-1_powerpc.deb
xrender_0.8.3-1.diff.gz
  to pool/main/x/xrender/xrender_0.8.3-1.diff.gz
xrender_0.8.3-1.dsc
  to pool/main/x/xrender/xrender_0.8.3-1.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian Project Leader report for 2005-04-24

[Branden Robinson]

On Mon, Apr 25, 2005 at 01:45:52PM +0200, Josselin Mouette wrote:
 Le lundi 25 avril 2005 à 01:03 -0500, Branden Robinson / Debian Project
 Leader a écrit :
  Woody Security Update Challenges and Progress
  -
  The ARM problems we've had have also affected the timeliness with which
  we've been able to get security updates out.  A security fix to
  ``xfree86``, for example, has been stalled for weeks because no ARM
  build daemon has been operational to compile it.  (See `Debian bug
  #298939`_ for details.)
 
 Why, in this case, isn't the package released for the other
 architectures? There's nothing wrong with sending an update later for
 architectures that were missing in the first run.

I don't have an answer for this.  My guess is that the Security Team
decided delaying the update was the lesser of two evils.

Security folks, would you care to comment?

In any event, we have recovered from the ARM situation (and xfree86 for
stable/arm is built for it), and you can expect some happy details in my
next DPL report.

-- 
G. Branden Robinson| The power of accurate observation
Debian GNU/Linux   | is frequently called cynicism by
[EMAIL PROTECTED] | those who don't have it.
http://people.debian.org/~branden/ | -- George Bernard Shaw


signature.asc
Description: Digital signature

Accepted xtrs 4.9a-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 29 Apr 2005 23:51:58 -0500
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9a-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Changes: 
 xtrs (4.9a-1) unstable; urgency=low
 .
   * Package new upstream version.
   * Update copyright file to reflect new upstream archive and copyright notice
 for Debian modifications.  I never signed a written instrument assigning
 copyright in my changes to Software in the Public Interest, Inc., so under
 my understanding of U.S. law, the copyright remains with me.
   * Update TRS-80 FAQ to be based on Tim Mann's version 1.53 (2005-04-07).
Files: 
 cce206e1285c1c8a60a77126f89a59cd 644 contrib/otherosfs extra xtrs_4.9a-1.dsc
 9a6968771f5c293bae89c2fd32b17cc2 427197 contrib/otherosfs extra 
xtrs_4.9a.orig.tar.gz
 f3902a11fe150f32bf87c8c37a5d74e9 50994 contrib/otherosfs extra 
xtrs_4.9a-1.diff.gz
 ff7ebfc2b3c27c3ea8a0282d010c2350 330546 contrib/otherosfs extra 
xtrs_4.9a-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iEYEARECAAYFAkJzEVIACgkQ6kxmHytGonybnQCgh3ggVQUUshilc6XaJct8W3cC
74kAn2BD8CTseW/16YzltxHFUNAc8uQ1
=lMTT
-END PGP SIGNATURE-


Accepted:
xtrs_4.9a-1.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9a-1.diff.gz
xtrs_4.9a-1.dsc
  to pool/contrib/x/xtrs/xtrs_4.9a-1.dsc
xtrs_4.9a-1_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9a-1_powerpc.deb
xtrs_4.9a.orig.tar.gz
  to pool/contrib/x/xtrs/xtrs_4.9a.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Debian Project Leader report for 2005-04-24

[Branden Robinson / Debian Project Leader]

.  In the future, we expect to have the agenda published farther
in advance of the meeting so there is a useful public comment period.
We continue to grapple with ways to balance openness and accountability
with the discretion that some issues sometimes require, and welcome your
feedback on how we can better achieve this.  Andreas Schuldei
volunteered to be our secretary, and minutes of the meeting will be
posted to the -project list as soon as they have been prepared and
approved by those in attendance.

One thing I thought I would note in advance of the meeting minutes is
that we voted to extend an invitation to Benjamin Mako Hill to join
our numbers, and he accepted.

Interviews and Public Appearances
-
I haven't made any public appearances yet, but I have been invited to
`FISL 6.0`_.  I hope to attend this conference, and am working on the
details of sponsorship for my flight and visa fees.

Three interviews with me have appeared over the past week.
Interestingly, each was conducted (predominantly) via a different
medium.  Please let me know in which forum I make the best (or worst)
impression.

* `email interview with Joe Zonker Brockmeier`_
* `IRC interview with Rob Levin`_
* `phone interview with Bruce Byfield`_

I'm pretty happy with all of the above interviews, and do not feel
misrepresented.  If you have any concerns about about any of the issues
in the above interviews, I urge you to contact me.

Internal Communications
---
Much of the initial mail I received at the ``leader`` alias was, as you
might expect, CCs or forwards of messages regarding ongoing business
that Martin Michlmayr was involved in when his term ended.  The very
*first* message I received via that alias was -- as you might expect --
Nigerian 4-1-9 spam.

Martin has been very helpful and responsive with the transition.  Some
of the matters not already mentioned above and currently under
discussion are:

* developing contacts at `Sun Microsystems`_
* establishing a backup site for ``snapshot.debian.net``
* sponsoring Debian Developer attendance at `aKademy 2005`_
* developing a more comprehensive backup strategy for machines critical
  to Debian's infrastructure
* working with `SPI`__ to figure out how to invoice IBM (at their request)
  for their sponsorship of `DebConf 5`_

Items of Interest
-
I have run across a couple of interesting articles and thought I would
commend them to wider attention:

* `Anthony Towns's analysis of Ubuntu Hoary Hedgehog`_
* `Rafael Laboissière's election analysis`_

Conclusion
--
That's all I have for now.  I hope you have found this report useful,
and I welcome your feedback on how I can improve on it for next time.

``$Id: 2005-04-24.rst 140 2005-04-25 05:45:14Z branden $``

.. _`my platform`: 
http://people.debian.org/~branden/dpl/campaign/2005/platform.xhtml
.. _`Xandros`: http://www.xandros.com/
.. _`Ian Lynagh's statistics`: 
http://people.debian.org/~igloo/needs-build-graph/index.php?arches=armdays=60
.. _`Debian bug #298939`: http://bugs.debian.org/298939
.. _`Software in the Public Interest, Inc.`: http://www.spi-inc.org/
__ `Software in the Public Interest, Inc.`_
.. _`Constitution`: http://www.debian.org/devel/constitution
.. _`DebConf 4`: http://www.debconf.org/debconf4/
.. _`Debian UK Society`: http://wiki.earth.li/DebianUKSociety
.. _`meeting agenda`: 
http://lists.debian.org/debian-project/2005/04/msg00324.html
.. _`debian-project mailing list`: http://lists.debian.org/debian-project/
.. _`FISL 6.0`: http://fisl.softwarelivre.org/6.0/
.. _`email interview with Joe Zonker Brockmeier`: 
http://www.linux-mag.com/content/view/1870/2107/
.. _`IRC interview with Rob Levin`: 
http://dunnage.blogspot.com/2005/04/interview-with-branden-robinson.html
.. _`phone interview with Bruce Byfield`: 
http://distrocenter.linux.com/article.pl?sid=05/04/19/164235from=rss
.. _`Sun Microsystems`: http://www.sun.com/
.. _`aKademy 2005`: http://conference2005.kde.org
.. _`IBM`: http://www.ibm.com/
.. _`DebConf 5`: http://www.debconf.org/debconf5/
.. _`Anthony Towns's analysis of Ubuntu Hoary Hedgehog`: 
http://azure.humbug.org.au/~aj/blog/2005/04/14#2005-04-14-sarge-v-hoary
.. _`Rafael Laboissière's election analysis`: 
http://people.debian.org/~rafael/dpl-vote-2005-analysis/

.. vim:set ai et sts=4 sw=4 tw=72:

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden


signature.asc
Description: Digital signature

Re: Bug#302138: incorrect Description line wrapping with bullet lists

[Branden Robinson]

On Wed, Mar 30, 2005 at 03:54:36AM -0600, Peter Samuelson wrote:
 [Peter Samuelson]
  I'd like to file a mass bug for these, but it's on the order of 583
  binary packages in 430 source packages, so I obviously want to get
  some feedback first.
 
 Jeroen van Wolffelaar pointed out to me that 430 source packages is a
 bit much for a mass bug, especially if lintian/linda could flag this
 stuff automatically, which is probably the case.
 
 Lars Wirzenius also suggested that I name names so people will know if
 they're affected.  So here are source packages grouped by maintainer.
 Data is from /var/lib/apt/lists/*_Packages on an i386 sid box.
[...]
 Branden Robinson [EMAIL PROTECTED]:
   twofish

Go ahead and file a bug for this one, please -- twofish sees so little
activity that I'm likely to forget to fix this, and having an open bug
report against it will remind me to start maintaining the package from a
Subversion repository.

Thanks for helping to make our package descriptions something we can be
proud of!

-- 
G. Branden Robinson|
Debian GNU/Linux   |Yeah, that's what Jesus would do.
[EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Accepted xft 2.1.7-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri,  1 Apr 2005 13:13:48 -0500
Source: xft
Binary: libxft-dev libxft2 libxft2-dbg
Architecture: source powerpc
Version: 2.1.7-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxft-dev - FreeType-based font drawing library for X (development files)
 libxft2- FreeType-based font drawing library for X
 libxft2-dbg - FreeType-based font drawing library for X (unstripped)
Changes: 
 xft (2.1.7-1) unstable; urgency=low
 .
   * New upstream release.
 + Keith Packard attests, and Branden Robinson verified as far as he is
   able, that no interface changes have been made since 2.1.2.
 + Highlights of upstream changes:
   - Change FC_CHARCELL and FC_MONO interpretation.  FC_MONO no longer
 clips glyphs to charcell, you must specify FC_CHARCELL for that.
   - Add support for FT_GlyphSlot_Embolden where it exists (which it
 usually doesn't).
   - Avoid crashing when using FT_Face objects.
   - Deal with broken FreeType 2.1.7 BDF/PCF loaders by trying both
 y_ppem/x_ppem and width/height values.
   - Work with older versions of Fontconfig by using various pattern
 elements only when defined.
   - Change Freetype includes to new syntax.
   - Search for nearest bitmap for bitmap-only fonts.
   - Support fontconfig 2.2 release which doesn't include FC_HINT_STYLE.
 .
   * Update Debian copyright file with URL to new tar archive, and identify
 Keith Packard as the upstream maintainer, not the upstream author
 (upstream now provides an AUTHORS file to clarify the latter).
 .
   * Correct and enhance xft-config's usage message:
 + No non-option arguments are allowed.
 + At least one option argument must be specified.
 + Use ellipsis notation to indicate that more than one option is allowed.
 + Provide one-sentence summary of the command's purpose.
 + Sort option names in lexicographic order.
 .
   * Write and ship manual page for xft-config.
 .
   * Drop libxft2.docs debhelper file; CDBS is now brainy enough to identify
 and tell dh_installdocs to ship a non-empty README file, so libxft2.docs
 has become redundant.
 .
   * Add debian/compat file to declare debhelper version 4 compatibility.
Files: 
 7d9862b1b85b790f11c57dd98dcbcf39 762 devel optional xft_2.1.7-1.dsc
 e8bab0995bdb96bf0efd06706aeb0494 338415 devel optional xft_2.1.7.orig.tar.gz
 3867745695c862594da0858bc8838170 14274 devel optional xft_2.1.7-1.diff.gz
 162169aed1185dea7dfeeec6431b9bde 5 libs optional 
libxft2_2.1.7-1_powerpc.deb
 30ba2691fe0a8521c530c514b1cb525c 822398 libdevel extra 
libxft2-dbg_2.1.7-1_powerpc.deb
 ad1609b8cc0ffc36931b739c1e98fe49 70566 libdevel optional 
libxft-dev_2.1.7-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iEYEARECAAYFAkJNvv0ACgkQ6kxmHytGonxD7gCeLqHl7Gv1aYO4T+u+aI9LqZKa
JOEAoJEqW/j5mh7AZInNmHL9DJRsVIoc
=d5el
-END PGP SIGNATURE-


Accepted:
libxft-dev_2.1.7-1_powerpc.deb
  to pool/main/x/xft/libxft-dev_2.1.7-1_powerpc.deb
libxft2-dbg_2.1.7-1_powerpc.deb
  to pool/main/x/xft/libxft2-dbg_2.1.7-1_powerpc.deb
libxft2_2.1.7-1_powerpc.deb
  to pool/main/x/xft/libxft2_2.1.7-1_powerpc.deb
xft_2.1.7-1.diff.gz
  to pool/main/x/xft/xft_2.1.7-1.diff.gz
xft_2.1.7-1.dsc
  to pool/main/x/xft/xft_2.1.7-1.dsc
xft_2.1.7.orig.tar.gz
  to pool/main/x/xft/xft_2.1.7.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug 295175 followup

[Branden Robinson]

On Sun, Feb 20, 2005 at 01:16:58PM -0800, Thomas Bushnell BSG wrote:
 Bug 295175, the grave xfree86-common bug that was blocking many
 autobuilds has now had its fix uploaded to the archive.
 
 Unfortunately, the xfree86 build with the fix is failing, and looking
 at the build logs, I think it's because the buildd chroots are still
 corrupted with the damage that the buggy package did.

Well, the damage is in part the package's fault, and in part (apparently)
dpkg's -- if you do a --purge of an installed package, the package does not
pass through the removed ok conffiles-only stage.  Instead, despite the
package payload being removed, the package is marked as still being
installed, which is where all this grief comes from.

 We need the buildd maintainers to all clean the chroots by hand

Yes, but...

 (perhaps it would be best to just rebuild them from scratch),

I don't think that's necessary.  Just apply the attached patch[1] in
/var/lib/dpkg/info.

 and then reschedule builds of xfree86.

That part's necessary too.  :)

 Regardless of exactly what the correct procedure is, is there someone
 who is taking the lead of making sure all this happens?  More than a
 few packages have gotten stalled by the corrupted chroots on the
 buildd's causing spurious build failures and it needs by-hand work to
 correct each one.

Steve Langasek has been working with me and some of the buildd admins on
this via IRC, but it is good to give this cleanup procedure broader
exposure.

[1] also available at URL: 
http://redwald.deadbeast.net/tmp/xfree86-common_postrm_buildd_fix.diff 

-- 
G. Branden Robinson|   The software said it required
Debian GNU/Linux   |   Windows 3.1 or better, so I
[EMAIL PROTECTED] |   installed Linux.
http://people.debian.org/~branden/ |
--- xfree86-common.postrm~  2004-02-17 18:20:44.0 -0500
+++ xfree86-common.postrm   2005-02-19 14:07:19.323055852 -0500
@@ -599,7 +599,7 @@
 
 
 if [ $1 = purge ]; then
-  update-rc.d $THIS_PACKAGE remove
+  update-rc.d $THIS_PACKAGE /dev/null remove
   for DIR in /etc/X11/Xresources /etc/X11/Xsession.d /etc/X11; do
 rmdir $DIR 2 /dev/null || true
   done


signature.asc
Description: Digital signature

Accepted xfree86 4.3.0.dfsg.1-12 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 14:45:15 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 
xlibmesa-gl-dev xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data 
x-window-system xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 
xlibmesa-glu libxaw7-dev xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg 
libxrandr2-dbg libxmu6 xlibmesa-glu-dbg libx11-dev xlibs-static-pic libxpm4-dbg 
libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev libxmuu-dev pm-dev libxext6 
libxft1-dbg libxtst-dev libxv-dev libxp-dev twm x-window-system-dev libsm-dev 
xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 libxmu-dev xlibs 
libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 libdps1 
proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg 
xfonts-base xlibs-dbg libxpm-dev xlibme
 sa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0.dfsg.1-12
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library 
(unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension 
library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension 
library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development 
f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library 
(unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library 
(un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X

Accepted xfree86 4.3.0.dfsg.1-11 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 11 Feb 2005 02:14:27 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 
xlibmesa-gl-dev xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data 
x-window-system xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 
xlibmesa-glu libxaw7-dev xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg 
libxrandr2-dbg libxmu6 xlibmesa-glu-dbg libx11-dev xlibs-static-pic libxpm4-dbg 
libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev libxmuu-dev pm-dev libxext6 
libxft1-dbg libxtst-dev libxv-dev libxp-dev twm x-window-system-dev libsm-dev 
xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 libxmu-dev xlibs 
libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 libdps1 
proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg 
xfonts-base xlibs-dbg libxpm-dev xlibme
 sa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0.dfsg.1-11
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force debian-x@lists.debian.org
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library 
(unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension 
library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension 
library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development 
f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library 
(unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library 
(un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X

Accepted shermans-aquarium 2.2.0-1.1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  2 Feb 2005 03:29:17 -0500
Source: shermans-aquarium
Binary: shermans-aquarium
Architecture: source powerpc
Version: 2.2.0-1.1
Distribution: unstable
Urgency: medium
Maintainer: Jose M. Moya [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 shermans-aquarium - Sherman's aquarium applet for GNOME 2
Closes: 287089
Changes: 
 shermans-aquarium (2.2.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload prepared by Helen Faulkner; reviewed by Branden
 Robinson.  Urgency due to fix for release-critical bug (non-free license
 problem).
   * Changed COPYING and debian/copyright to reflect the new DFSG-free (2
 clause BSD-style) licensing of the fish images, which has recently been
 negotiated with the copyright holder.  (Closes: #287089)
Files: 
 2fa487a37d95dab83fd3428ce74071be 664 gnome optional 
shermans-aquarium_2.2.0-1.1.dsc
 86083d5cf668442eca236e719c66c43b 23927 gnome optional 
shermans-aquarium_2.2.0-1.1.diff.gz
 c8c50a598598c191555cd8c9681782be 173394 gnome optional 
shermans-aquarium_2.2.0-1.1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iEYEARECAAYFAkIAlS4ACgkQ6kxmHytGonyy8QCfVlkYHk+mfdTG2gc+7Vetg2Kg
kMkAn3Uto1ZQVKJalPMFu4Lq0St/AQpD
=BbwA
-END PGP SIGNATURE-


Accepted:
shermans-aquarium_2.2.0-1.1.diff.gz
  to pool/main/s/shermans-aquarium/shermans-aquarium_2.2.0-1.1.diff.gz
shermans-aquarium_2.2.0-1.1.dsc
  to pool/main/s/shermans-aquarium/shermans-aquarium_2.2.0-1.1.dsc
shermans-aquarium_2.2.0-1.1_powerpc.deb
  to pool/main/s/shermans-aquarium/shermans-aquarium_2.2.0-1.1_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Editing history... (about debian/changelog in experimental)

[Branden Robinson]

On Wed, Jan 12, 2005 at 07:13:57PM +0100, Jeroen van Wolffelaar wrote:
 Branden Robinson told me that he does changelog editing of past
 revisions continuously for X, for reasons of being able to correctly
 lookup when a certain bug was fixed. Especially typo's in bugnumber for
 example can make a changelog quite useless if I want to determine when a
 certain bug was fixed, and a correct changelog makes it very easy to
 close bugs that were fixed some time ago by quoting the relevant
 changelog entry.

That's correct.

The purpose of the changelog is to document history[1], not be an indelible
document.

We'd all prefer to document history accurately the first time around, and
we should take care to do so, but we do make mistakes from time to time.

I did maybe feel a bit more strongly about indelible changelog entries a
couple of years back (and longer) before I even kept the XFree86 packages
in revision control, though I don't think I was ever quite the hard-liner
that some people are.

Again, the fundamental question is: does the changelog entry in question
document history as accurately as it can?  If so, leave it alone.  If not,
and the inaccuracy is likely to mislead people, fix it.

Similarly, it is not the job of a changelog entry to document things that
aren't changes (as evidence that people will behave more absurdly than you
can at first believe, I offer [2]).

IMO, the Policy Manual should countenance retroactive modification of
changelog entries under such circumstances.

[1] ...with a secondary function of automatically closing bugs.
[2] Message-id: [EMAIL PROTECTED]
http://lists.debian.org/debian-devel/2004/03/msg01377.html

-- 
G. Branden Robinson| There's nothing an agnostic can't
Debian GNU/Linux   | do if he doesn't know whether he
[EMAIL PROTECTED] | believes in it or not.
http://people.debian.org/~branden/ | -- Graham Chapman


signature.asc
Description: Digital signature

Accepted xtrs 4.9-5 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 13 Jan 2005 18:51:57 -0500
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9-5
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 288767
Changes: 
 xtrs (4.9-5) unstable; urgency=low
 .
   * Actually apply the patches in debian/patches, which were neglected in the
 4.9-4 release.
   * Add recognition of amd64 and ppc64 architectures in debian/rules (thanks,
 Andreas Jochens).
   * Update build-dependency on libreadline4-dev (= 4.1) to libreadline5-dev.
 Thanks to Andreas Jochens for pointing this out.
   * Apply patch from Andreas Jochens to fix compilation errors on AMD64
 by adding more explicit casts.  (Closes: #288767)
Files: 
 44cc875bcc161d4cd7c82f0d5a555ecd 641 contrib/otherosfs extra xtrs_4.9-5.dsc
 3d6574abd851325297bb8274aaad8cba 55244 contrib/otherosfs extra 
xtrs_4.9-5.diff.gz
 e5013b64bbd3428dd28cb7a2d6daab79 327690 contrib/otherosfs extra 
xtrs_4.9-5_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iEYEARECAAYFAkHnCx0ACgkQ6kxmHytGonydhQCfZwWlax9zCB1VuDPgXwWmsCUP
L9cAnA+5mAisryaoxTPW3wP2uooRrlWi
=g40D
-END PGP SIGNATURE-


Accepted:
xtrs_4.9-5.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9-5.diff.gz
xtrs_4.9-5.dsc
  to pool/contrib/x/xtrs/xtrs_4.9-5.dsc
xtrs_4.9-5_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9-5_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted vtwm 5.4.6b-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 30 Dec 2004 23:20:05 -0500
Source: vtwm
Binary: vtwm
Architecture: source powerpc
Version: 5.4.6b-1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 vtwm   - Virtual Tab Window Manager
Closes: 193695 194110 194158 201738 201741 225945 286951
Changes: 
 vtwm (5.4.6b-1) unstable; urgency=low
 .
   * Update to new upstream version.  (Closes: #193695)
 + Fixes problem where certain window types (often transient dialogs) cause
   VTWM to restart itself.  (Closes: #286951)
 + The VirtualDesktopFont configuration variable is now documented under
   that name, instead of the incorrect VirtualFont.  (Closes: #201738)
   * Resync Debian patches with new version.
 + Fix for gram.y is now upstream.
 + Replace VTWMLIBDIR symbol with VTWMCONFDIR since all we use it for is
   installation of the configuration file.  Create a new TWMCONFDIR symbol,
   which we use to locate twm's configration file.  If Imake defines
   EtcX11Directory, use a subdirectory of ETCX11DIR for vtwm's
   configuration; otherwise, use a subdirectory of LIBDIR.  (This is an
   improved -- and hopefully upstream-tolerable -- version of a patch
   previously applied.)
   * Update copyright information:
 + Update URL to new source version and hosting location.
 + Update list of copyright holders, authors and contributors based on
   current version of manual page.
 + Undocument Martin Joey Schulze as a Debian package author, as he
   wasn't responsible for *this* packaging (which has been done at least 3
   times from scratch in the past 10 years, most recently by me).
   Acknowledge Joey's previous packaging.
 + Update my copyright notice.  I have never signed a written instrument
   assigning my copyright in the packaging desiderata to Software in the
   Public Interest, Inc., so it's probably misleading to claim the
   copyright belongs to them.
   * Rewrite package's extended description based on current information from
 upstream.
   * Update build-dependencies to depend on real X protocol header and library
 development packages, rather than xlibs-dev, which is a dummy package
 nowadays.
   * Update menu item quoting functions in vtwm's menu-method file to align
 them with twm's, which are a little easier to understand.
   * Add support for launching other window managers to menu-method file, using
 VTWM's f.startwm function.  Add 10 points to vtwm command's alternatives
 priority per Debian Policy section 11.8.4.  (Closes: #194158)
   * Re-case VTWM's name in its menu entry per upstream usage.
   * Use a debian/compat file instead of the DH_COMPAT variable in the rules
 file, per debhelper(7).
   * Add FixManagedVirtualGeometries and FixTransientVirtualGeometries to
 system.vtwmrc-menu file per suggestion from Neil Stewart; this should fix
 various problems with placement of transient and pop-up dialog windows.
 (Closes: #194110, #225945)
   * Grab fix to twm's parse.c from XFree86 CVS (revision 1.9, 2001/04/23) that
 fixes line numbers in error messages about the vtwmrc file from being
 double their correct value.  (Closes: #201741)
   * Bump Standards-Version to 3.6.1; no changes necessary.
   * Quote strings in menu file, per Lintian.
   * Tidy up the manual page in several respects:
 + Add copyright notice to the manual page itself, copied from the
   copyright information on twm's source files in X11R4, from which VTWM
   was forked.
 + Fix up the .TH directive:
   - Downcase the command name (rendering a command's name in full caps is
 a presentation decision).
   - Change the date to reflect my modifications.
   - Indicate the source as VTWM 5.4.6b, not X11R4-6, since this
 manual page is independently maintained by the VTWM hackers.
 + Fix up the NAME section:
   - Remove spurious paragraph break at the beginning of the section.
   - Use \- instead of - to separate the manpage's name and summary and so
 that mkwhatis is less easily confused.  (See man(7).)
 + Rename the SYNTAX section to SYNOPSIS.  (See man(7).)
 + Use an macros for type face selection in the SYNOPSIS section.
 + Use \- instead of - in the SYNOPSIS section to notate literal dashes
   that the user will type (e.g., when specifying command-line options).
 + Rename the SIGNALS section to ASYNCHRONOUS EVENTS (after SUSv3
   manpages).
 + Rename the ENVIRONMENT VARIABLES section to ENVIRONMENT.  (See
   man(7).)
 + Use an typeface macros instead of roff \f escapes for font changes
   where practical in the ASYNCHRONOUS EVENTS, BUGS, FILES,
   ENVIRONMENT, COPYRIGHT, and SEE ALSO sections.
 + Quote multi-word arguments to the .SH macro in the ASYNCHRONOUS

Accepted xtrs 4.9-4 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 24 Dec 2004 22:51:10 -0500
Source: xtrs
Binary: xtrs
Architecture: source powerpc
Version: 4.9-4
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 264120 285963
Changes: 
 xtrs (4.9-4) unstable; urgency=low
 .
   * Transcode changelog to UTF-8.
   * Modernify comments and metadata in templates.pot.
   * Modernize comments and metadata in existing po files.
   * Re-run debconf-update po on existing po files (this recoded them to UTF-8,
 reflowed the text, and made some other cosmetic fixes).
   * Add Japanese debconf template translations (thanks, Hideki Yamane).
 (Closes: #264120)
   * Add Danish debconf template translations (thanks, Morten Bo Johansen).
 (Closes: #285963)
   * Update TRS-80 FAQ to be based on Tim Mann's version 1.50 (2004/12/06).
   * Rename plain text documentation to use an extension of .txt instead of
 .text.
   * Tidy up style of debian/rules file.
   * Migrate from using dh_installmanpages to dh_installman in debian/rules.
   * Bump Standards-Version to 3.6.1; changelog already recoded per above -- no
 other changes necessary.
   * Quote strings in Debian menu data fields (per Lintian).  Reflow menu data.
   * Replace build-dependency on dummy package xlibs-dev with
 build-dependencies on libx11-dev and x-dev.
Files: 
 0d5427704348cc41c2841910d2e2f9fb 650 contrib/otherosfs extra xtrs_4.9-4.dsc
 4bec7f17b63d88f4dd8733708d594d11 53225 contrib/otherosfs extra 
xtrs_4.9-4.diff.gz
 7d7580aa050dc5951427e3edccef1b16 327652 contrib/otherosfs extra 
xtrs_4.9-4_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iEYEARECAAYFAkHM7l4ACgkQ6kxmHytGonw8QwCghLX5IBOsnF/Drhi7uQFC7EED
cpkAn0piS1sWc74KwK68FeCkL9JfXzYM
=fey2
-END PGP SIGNATURE-


Accepted:
xtrs_4.9-4.diff.gz
  to pool/contrib/x/xtrs/xtrs_4.9-4.diff.gz
xtrs_4.9-4.dsc
  to pool/contrib/x/xtrs/xtrs_4.9-4.dsc
xtrs_4.9-4_powerpc.deb
  to pool/contrib/x/xtrs/xtrs_4.9-4_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

having trouble with xdm/xfs 4.3.0.dfsg.1-9?

[Branden Robinson]

[Followups set to debian-x.]

Hi folks,

I just wanted to bring the following information to the attention of those
who may be frustrated by problems with the latest xdm and xfs packages.

[...]
   [14 December] XFree86 4.3.0.dfsg.1-9 sneaked out with a couple of
   small but annoying bugs in it. Specifically, the xdm and xfs packages
   suffer from some bad shell syntax in conffiles. Fabio and I plan to
   release what it is currently on the SVN trunk as 4.3.0.dfsg.1-10 in a
   couple of days. In the meantime, you can grab fixes (in unified diff
   format) for the [14]xdm bug and the [15]xfs bug from the archives of
   the debian-x mailing list.

  14. http://lists.debian.org/debian-x/2004/12/msg00411.html
  15. http://lists.debian.org/debian-x/2004/12/msg00410.html
[...]

The above is from the X Strike Force news page.  If you use Debian X Strike
Force-maintained packages from testing or unstable, please bookmark the
following site:

http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml

-- 
G. Branden Robinson|  The greatest productive force is
Debian GNU/Linux   |  human selfishness.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 10:57:24AM +0200, Tollef Fog Heen wrote:
 * Branden Robinson 
 
 | On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote:
 |  environment variables, at least, are trivial to accomplish using the
 |  pam_env module.  Properly setting a umask would call for something else
 |  yet.
 | 
 | Would pam_umask.so be a worthwhile exercise for some enterprising person?
 | 
 | I somehow suspect that umasks predate environment variables in the misty
 | early history of Unix, else the umask would've been made one.
 
 Give me a decent description for it (as in, what goes into the long
 description in debian/control) and it's on its way to incoming.

Wow, thanks!

Hmmm.

 This PAM module sets the umask for successfully authenticated sessions.
 The umask affects the permissions assigned to newly created files by
 default.
 .
 This package is useful to ensure that users' umasks are set consistently
 whether their session is initiated by login, SSH, a display manager for
 the X Window System, or some other means.

I'm not thrilled with it, but maybe you can make something useful out of
that.

Thanks again for the lightning-fast coding.  :)

-- 
G. Branden Robinson|The basic test of freedom is
Debian GNU/Linux   |perhaps less in what we are free to
[EMAIL PROTECTED] |do than in what we are free not to
http://people.debian.org/~branden/ |do.  -- Eric Hoffer


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 09:43:33AM +0200, Jan Nieuwenhuizen wrote:
 I wonder if filing a bug report against the offending MUA would be
 more efficient?

I think such bugs are best filed by those who actually use the MUA in
question (I use Mutt, which already respects M-C-T and M-F-T).

After all, if I can't persuade the users of those MUAs that honoring
people's wishes is a good idea, I don't suspect I'll make much more headway
with anyone else.

-- 
G. Branden Robinson|
Debian GNU/Linux   |   If ignorance is bliss,
[EMAIL PROTECTED] |   is omniscience hell?
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Mon, Oct 18, 2004 at 09:41:45PM +0200, Tomas Fasth wrote:
 I have re-read your mail and I beg you for pardon. I was wrong.

Thanks.  My anger dissipates with a wave of the hand.  :)

 | And, by the way: X-No-CC: I subscribe to this list; do not CC me
 | on replies.
 
 I'm very sorry but I'm not perfect. My earlier reply did not cc:
 you. Could you please wait for it to happen a second time in the
 same thread before complaining? You seem a bit touchy about it.

It's one of my long-standing pet peeves.

 | Please get an MUA that respects Mail-Copies-To:.
 
 Thanks for the advice, but I prefer Firefox for the time being. I
 may try to persuade the Mozilla people to accept a patch. Can you
 give me a reference to a RFC-draft or something equivalent?

The best I can do is my usual boilerplate message, which has some
references at the bottom.

[The following is a form letter.]

Hello,

You recently sent a message to a Debian Project mailing list to which I am
subscribed, and also included me in the To or CC header.

Please don't do this.  The Debian Mailing List Code of Conduct says:

  When using the Debian mailing lists, please follow these rules:

[...]
  * When replying to messages on the mailing list, do not send a carbon
copy (CC) to the original poster unless they explicitly request to be
copied.

(You can review the entire Debian Mailing List Code of Conduct at
URL:http://www.debian.org/MailingLists/.)

Rationally interpreted, this of course includes anything that works
equivalently to a CC, such including the original poster in the To: or Bcc:
headers, forwarding the message to the original poster, or using the
bounce feature of some mailers to send the message again, but rewriting the
SMTP envelope to address the original poster instead of the list.

Some people feel that it is best to send email to everyone who might
possibly be interested in a message, indifferent to whom might be
subscribed to various mailing lists, be part of the expansion of various
mailing lists, be behind an SMTP exploder, and so forth -- in other words,
that it is the responsibility of the recipient of duplicate mail messages
to handle them.

The Debian Mailing List Code of Conduct does not endorse that philosophy.
There are proven limitations with using procmail rules to eliminate
duplicate message based on Message-ID, for instance.  More importantly, the
Debian Mailing List Code of Conduct expects the *senders* of mail to
exercise discretion and good judgement; it does not place the burden of
pruning unwanted copies of mail messages upon the recipient.  You can find
discussions of this aspect of the Mailing List Code of Conduct in the
Debian mailing lists themselves, if you are interested: please see
URL:http://lists.debian.org/search.html to perform a search.

The subject has come up several times over the past years, and time and
again, the existing policy has been affirmed as the wisest course of
action.  Many people, myself included, use the Mail-Followup-To and
Mail-Copies-To message headers, which are honored by mail user agents such
as Mutt to control the distribution of replies to mailing lists.   Using
such headers, a person can easily indicate that he does (or does not) want
to be sent copies of replies to his message.  You may want to use an MUA
that honors these headers, as they are in fairly wide usage on the Debian
mailing lists, and may help you avoid mistakes resulting in inadvertent
violations of Debian's Mailing List Code of Conduct.

You can read more about the Mail-Followup-To and Mail-Copies-To message
headers at:

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt
http://www.newsreaders.com/misc/mail-copies-to.html

Please note that no assertions of deliberate misconduct on your part are
intended by this message.  It is meant only to advise you as to how to
communicate more harmoniously with people involved with the Debian Project.

Thank you for your patience with this form letter, for your respect for the
Debian Project's mailing list conventions, and for your participation in
Debian.

-- 
G. Branden Robinson|When we call others dogmatic, what
Debian GNU/Linux   |we really object to is their
[EMAIL PROTECTED] |holding dogmas that are different
http://people.debian.org/~branden/ |from our own. -- Charles Issawi


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote:
 environment variables, at least, are trivial to accomplish using the
 pam_env module.  Properly setting a umask would call for something else
 yet.

Would pam_umask.so be a worthwhile exercise for some enterprising person?

I somehow suspect that umasks predate environment variables in the misty
early history of Unix, else the umask would've been made one.

-- 
G. Branden Robinson|   The Bible is probably the most
Debian GNU/Linux   |   genocidal book ever written.
[EMAIL PROTECTED] |   -- Noam Chomsky
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Sat, Oct 16, 2004 at 01:28:31PM +0200, Tomas Fasth wrote:
 However, umask is not an ordinary software configuration property,
 it's a process property initially inherited from init which, by the
 way, set it to 022 (I just checked the source of sysvinit in unstable).

Yes, we know that.

[...]
 What I don't understand is why you think the umask preference should be
 applied differently depending on the type of interface the user choose to
 initiate an interactive session with.

I don't.  Kindly stop putting words in my mouth, and re-read my original
mail.  If you can discuss this subject without indulging yourself in
straw-man attacks like this, please follow-up with a more reasonable
message.

And, by the way:
X-No-CC: I subscribe to this list; do not CC me on replies.

Please get an MUA that respects Mail-Copies-To:.

-- 
G. Branden Robinson|I must despise the world which does
Debian GNU/Linux   |not know that music is a higher
[EMAIL PROTECTED] |revelation than all wisdom and
http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote:
 Branden Robinson wrote:
 /etc/login.defs explicitly indicates that it is Configuration
 control definitions for the login package, and many of its
 parameters are inapplicable to display managers, or already
 implemented in parallel (e.g., how long do wait after a failed
 login before displaying the prompt/greeter again?).
 
 I believe that /etc/login.defs _is_ the right place to define the
 default umask property.

It feels wrong to me to make display managers selectively parse the
configuration file of a different piece of software for configuration
parameters that might be of interest to them.

$ man 5 login.defs

No mention of X Window System display managers there.

Huh, well...

BUGS
   Much of the functionality that used to be provided by the shadow
   password suite is now handled by PAM.  Thus, /etc/login.defs is no
   longer used by programs  such  as  login(1), passwd(1) and su(1).
   Please refer to the corresponding PAM configuration files instead.

Maybe that's the direction we should head?

-- 
G. Branden Robinson| If God had intended for man to go
Debian GNU/Linux   | about naked, we would have been
[EMAIL PROTECTED] | born that way.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

[Redirecting to debian-devel; followups set.]

On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff wrote:
 Hi,
 
 After a fresh sarge install, I'm having problems with umask settings. In
 /etc/login.defs I set umask to 002, and that works for logging in on the
 console or remote via ssh. However, if I use {g,x,k}dm I keep getting an
 umask of 022, because Xsession is started by the display manager which
 has a default umask of 022.
 
 It seems that Xsession doesn't change the UMASK at all. Should it do so?
 If not, which program should set the umask during a graphical login?

Good question.

debian-devel folks, what do you think?  I'm having difficulty deciding how
to think about this issue.

/etc/login.defs explicitly indicates that it is Configuration control
definitions for the login package, and many of its parameters are
inapplicable to display managers, or already implemented in parallel (e.g.,
how long do wait after a failed login before displaying the prompt/greeter
again?).

By analogy, /etc/environment is a PAM thing and should only be dealt with
by PAM.  (We can't use it anyway since the umask is not an environment
variable.)

* What's the path of least resistance?
* What would violate user expectations the least?
* What would be a good ideal approach, if code changes weren't an issue?

-- 
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux   | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson


signature.asc
Description: Digital signature

Jörg Schilling is damage; the community should route around him

[Branden Robinson]

I don't know about anyone else, but I am tired of reading about the
petulant behavior of cdrtools's upstream author ([1][2][3]).

Mr. Schilling is clearly unhappy with his choice of the GNU GPL for his
software.  That is his prerogative, but in my view he causes too much chaos
and confusion by continuing to add GPL-incompatible riders to his license.
He is furthermore unwilling to pay heed to the needs of the community,
which requires that important tools like cdrecord be under the stewardship
of a non-mercurial personality (at least when it comes to licensing
decisions).

It's time to fork.  Let us work with the rest of the community to
standardize on a new set of tools based on the last free version of
cdrtools, thank Mr. Schilling for his valuable contributions, and leave him
be to pursue his interests in proprietary software without interference
or argument from us.  He appears to regard placing his work under the plain
vanilla GNU GPL that works for so many projects as an act that he cannot
perform in good conscience.  Let us stop placing him in that uncomfortable
position.

[The subject is a reference to a famous quote by John Gilmore.]

[1] http://lwn.net/Articles/97469/
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270060

-- 
G. Branden Robinson|   If you want your name spelled
Debian GNU/Linux   |   wrong, die.
[EMAIL PROTECTED] |   -- Al Blanchard
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Looking for ontologies useful for debtags

[Branden Robinson]

On Sun, Oct 03, 2004 at 01:22:13AM +0200, Enrico Zini wrote:
 in organizing the tags that compose debtags, it would be nice to reuse
 existing ontologies for our facets (groups of tags from specific points
 of view), so that we could have some facets that could be linking points
 for other existing knowledge bases.

Enrico,

Casting Eray Summoning IX is prohibited in Debian and is a bannable
offense.  :-P

Quick, everyone, scoot your feet across his thaumaturgic circle before he
finishes his spell...

-- 
G. Branden Robinson|  Never underestimate the power of
Debian GNU/Linux   |  human stupidity.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Accepted ctwm 3.6-2 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Jun 2004 23:21:26 -0500
Source: ctwm
Binary: ctwm
Architecture: source powerpc
Version: 3.6-2
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 ctwm   - Claude's Tab window manager
Closes: 224348 234782 250905
Changes: 
 ctwm (3.6-2) unstable; urgency=low
 .
   * Fix typo in copyright file.
   * Define I18N symbol in Imakefile per request by Alexander Mikhailian.
 (Closes: #250905)
   * Permit non-transient windows in the same group (e.g., Mozilla browser
 windows) to occupy different workspaces (thanks, Arun A. Tharuvai).
 (Closes: #234782)
   * Don't randomly place windows that have an explicit geometry (thanks,
 Terran Melconian).  (Closes: #224348)
   * Remove redundant AllTarget(ctwm) rule from Imakefile; this is already
 handled by ComplexProgramTarget(ctwm).
   * Enable preprocessing of manpage by using undocumented(!) -D option to
 xmkmf.
   * Replace hash character with XCOMM in manpage so the preprocessor doesn't
 get confused.
   * Quote all parameter values in menu file; shuts up lintian warnings.
   * Update build-dependencies to reflect (XFree86) X library package split.
   * Increment Standards-Version to 3.6.1; no changes needed.
   * Resynchronize menu-method file with twm's (see #193759).
Files: 
 ff88aa6c86268083cca64ee2317a6ef7 684 x11 optional ctwm_3.6-2.dsc
 0e47e0e74db66984bc02df8754637760 87646 x11 optional ctwm_3.6-2.diff.gz
 830d8cd89f58616af900d9897ec670fd 454824 x11 optional ctwm_3.6-2_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkDTwPgACgkQ6kxmHytGonwOaQCgqBb41nNN9hl6BPJNpquBORR5
iKsAn3CaRNXCMW2PDAUfH4HvzLs8T/J4
=9Zsd
-END PGP SIGNATURE-


Accepted:
ctwm_3.6-2.diff.gz
  to pool/main/c/ctwm/ctwm_3.6-2.diff.gz
ctwm_3.6-2.dsc
  to pool/main/c/ctwm/ctwm_3.6-2.dsc
ctwm_3.6-2_powerpc.deb
  to pool/main/c/ctwm/ctwm_3.6-2_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xfree86 4.3.0.dfsg.1-4 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 28 May 2004 21:49:53 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0.dfsg.1-4
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window

Accepted xcursor 1.1.3-1 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 19 Apr 2004 15:39:41 -0500
Source: xcursor
Binary: libxcursor1-dbg libxcursor-dev libxcursor1
Architecture: source powerpc
Version: 1.1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxcursor-dev - X cursor management library (development files)
 libxcursor1 - X cursor management library
 libxcursor1-dbg - X cursor management library (unstripped)
Closes: 241249
Changes: 
 xcursor (1.1.3-1) unstable; urgency=medium
 .
   * Urgency due to fix for release-critical bug.
 .
   * New upstream version.
 + Invokes AC_SUBST() on X_CFLAGS and X_LIBS, unbreaking xcursor.pc file.
   (Closes: #241249)
 .
   * Add versioning to libxcursor1's shlibs information, since Xcursor 1.1.2
 added a member to the XcursorImages structure and added the
 XcursorImagesSetName() and XcursorLibraryPath() functions.
 .
   * Disable upstream autoconf check for the XFIXES library, as this library is
 not packaged for Debian yet, and upstream supports no option to the
 configure script to avoid checking (neverthless, the source is designed to
 be buildable without it).  Regenerate related files with autogen.sh
 script.
 .
   * Modify AC_PATH_XTRA invocation to take advantage of Debian's enhancements
 (from autoconf 2.59-3); don't use the macro's defaults, which look for the
 Xt library which we don't use.  Instead search for the X11 library, the
 Xlib.h header file, and the XInternAtom() function, all of which are
 actually used by the Xcursor library.  Regenerate related files with the
 autogen.sh script.
 .
   * Update config.guess, config.sub, and ltmain.sh with libtoolize --force
 --copy.
 .
   * Update package descriptions.
Files: 
 dc6f4affbb2ab88fbef6369432e5d7e0 812 devel optional xcursor_1.1.3-1.dsc
 429a33f81d222ef6300f7cc4d146641f 31625 devel optional xcursor_1.1.3.orig.tar.gz
 0cd98ece39b11b9d0e861275ee78e36f 289195 devel optional xcursor_1.1.3-1.diff.gz
 c4cd423d2cb7c645cd594a67e1ceccec 25870 libs optional libxcursor1_1.1.3-1_powerpc.deb
 aa4f3d088e204551db0a96b0067b2770 123752 libdevel extra 
libxcursor1-dbg_1.1.3-1_powerpc.deb
 2102764971c08944336b266213edaeda 33554 libdevel optional 
libxcursor-dev_1.1.3-1_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkCEPgMACgkQ6kxmHytGonzCzQCeIYQn31kzodv5v28+dLNZBcFe
2SIAoJ8/w5iRLB7JrQpNNhCjfjJoUivQ
=GZiH
-END PGP SIGNATURE-


Accepted:
libxcursor-dev_1.1.3-1_powerpc.deb
  to pool/main/x/xcursor/libxcursor-dev_1.1.3-1_powerpc.deb
libxcursor1-dbg_1.1.3-1_powerpc.deb
  to pool/main/x/xcursor/libxcursor1-dbg_1.1.3-1_powerpc.deb
libxcursor1_1.1.3-1_powerpc.deb
  to pool/main/x/xcursor/libxcursor1_1.1.3-1_powerpc.deb
xcursor_1.1.3-1.diff.gz
  to pool/main/x/xcursor/xcursor_1.1.3-1.diff.gz
xcursor_1.1.3-1.dsc
  to pool/main/x/xcursor/xcursor_1.1.3-1.dsc
xcursor_1.1.3.orig.tar.gz
  to pool/main/x/xcursor/xcursor_1.1.3.orig.tar.gz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xfree86 4.3.0-6 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 16 Mar 2004 15:44:17 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0-6
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window System

Accepted xfree86 4.3.0-7 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 17 Mar 2004 13:13:31 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0-7
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window System

Accepted xcursor 1.0.2-5 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 12 Mar 2004 12:51:55 -0500
Source: xcursor
Binary: libxcursor1-dbg libxcursor-dev libxcursor1
Architecture: source powerpc
Version: 1.0.2-5
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxcursor-dev - X Cursor management library (development files)
 libxcursor1 - X Cursor management library
 libxcursor1-dbg - X Cursor management library (unstripped)
Changes: 
 xcursor (1.0.2-5) unstable; urgency=low
 .
   * Make package compatible with the XFree86 4.3.0 package reorganization.
 - debian/control
   + package build-depends on x-dev and libx11-dev instead of xlibs-dev
   + libxcursor-dev depends on x-dev and libx11-dev instead of xlibs-dev
 .
   * Remove README.Debian; the release of xfree86 4.3.0-1 to unstable renders
 advice about installing these xcursor packages in conjunction with
 experimental XFree86 4.3.0 packages unecessary.
 - debian/README.Debian
 .
   * Give source package a section (devel, just like xft) to shut up
 complaints from dpkg-genchanges.
 - debian/control
 .
   * Remove AC_PATH_X and subsequent bailout logic from configure.ac; the
 mechanism used to find the Xrender suffices to configure the build
 environment.  Run aclocal  automake --foreign  autoconf.
 - configure
 - Makefile.in
 - config.h.in
 - configure.ac
 - aclocal.m4
Files: 
 306046ed085824447c6956fd9c45393d 813 devel optional xcursor_1.0.2-5.dsc
 1d6df28c31d312020c5b83d5bb7c28dc 224044 devel optional xcursor_1.0.2-5.diff.gz
 4f0b43edd36ae7b989469f84328734ce 23856 libs optional libxcursor1_1.0.2-5_powerpc.deb
 658a99522d62bf2c22737876ee9b588a 121542 libdevel extra 
libxcursor1-dbg_1.0.2-5_powerpc.deb
 9b8d05f14ffcb883f7230b55917562c9 31706 libdevel optional 
libxcursor-dev_1.0.2-5_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkBR/lkACgkQ6kxmHytGonw+awCfXgR+7OA+9cqjshWSttPdWwaF
hqoAn2ui57wB/fqgbJWt902V6mWrqPHK
=fLMd
-END PGP SIGNATURE-


Accepted:
libxcursor-dev_1.0.2-5_powerpc.deb
  to pool/main/x/xcursor/libxcursor-dev_1.0.2-5_powerpc.deb
libxcursor1-dbg_1.0.2-5_powerpc.deb
  to pool/main/x/xcursor/libxcursor1-dbg_1.0.2-5_powerpc.deb
libxcursor1_1.0.2-5_powerpc.deb
  to pool/main/x/xcursor/libxcursor1_1.0.2-5_powerpc.deb
xcursor_1.0.2-5.diff.gz
  to pool/main/x/xcursor/xcursor_1.0.2-5.diff.gz
xcursor_1.0.2-5.dsc
  to pool/main/x/xcursor/xcursor_1.0.2-5.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xft 2.1.2-6 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 11 Mar 2004 02:13:15 -0500
Source: xft
Binary: libxft-dev libxft2 libxft2-dbg
Architecture: source powerpc
Version: 2.1.2-6
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxft-dev - FreeType-based font drawing library for X (development files)
 libxft2- FreeType-based font drawing library for X
 libxft2-dbg - FreeType-based font drawing library for X (unstripped)
Changes: 
 xft (2.1.2-6) unstable; urgency=low
 .
   * Make package compatible with the XFree86 4.3.0 package reorganization.
 - debian/control:
   + package build-depends on x-dev and libx11-dev instead of xlibs-dev
   + libxrender-dev depends on x-dev and libx11-dev instead of xlibs-dev
   + make libxft-dev conflict with xlibs-dev ( 4.3.0) due to (now
 undiverted) file overlaps
 - debian/libxft-dev.preinst: remove diversions made by previous versions
   of package if present
 - debian/libxft-dev.postrm: deleted
Files: 
 773234980d1284b794d353b013f9b393 763 devel optional xft_2.1.2-6.dsc
 de9fb1c0fc0cc17afc23deffe14c7817 218603 devel optional xft_2.1.2-6.diff.gz
 5ab7936312010cb1a6316865433cf396 52762 libs optional libxft2_2.1.2-6_powerpc.deb
 b6572fa2ed40c50e41c7e0f91f03c857 356100 libdevel extra libxft2-dbg_2.1.2-6_powerpc.deb
 0b6705dbe6a65d9376d81668bc38045a 64634 libdevel optional 
libxft-dev_2.1.2-6_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkBQJxAACgkQ6kxmHytGonw8IQCfbmYs611d6wrU4fL++J0fDxmA
RUkAnRsOosaRiN9sLFENu6A9qcG2QlzM
=pJGI
-END PGP SIGNATURE-


Accepted:
libxft-dev_2.1.2-6_powerpc.deb
  to pool/main/x/xft/libxft-dev_2.1.2-6_powerpc.deb
libxft2-dbg_2.1.2-6_powerpc.deb
  to pool/main/x/xft/libxft2-dbg_2.1.2-6_powerpc.deb
libxft2_2.1.2-6_powerpc.deb
  to pool/main/x/xft/libxft2_2.1.2-6_powerpc.deb
xft_2.1.2-6.diff.gz
  to pool/main/x/xft/xft_2.1.2-6.diff.gz
xft_2.1.2-6.dsc
  to pool/main/x/xft/xft_2.1.2-6.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xrender 0.8.3-7 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue,  9 Mar 2004 23:56:21 -0500
Source: xrender
Binary: libxrender1-dbg libxrender-dev libxrender1
Architecture: source powerpc
Version: 0.8.3-7
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
Closes: 233969
Changes: 
 xrender (0.8.3-7) unstable; urgency=medium
 .
   * Urgency due to fix for FTBFS.
 .
   * Define and use AC_PATH_XTRA_CORRECTED autoconf macro instead of
 AC_PATH_XTRA, which does not know how to find X libraries or headers when
 only x-dev and libx11-dev are installed (which are the only XFree86
 packages that Xrender needs to actually build).   Re-run aclocal 
 automake --foreign  autoconf to resynchronize with change to
 configure.ac.  Fixes FTBFS; thanks to Jurij Smakov for this patch.
 (Closes: #233969)
 - acinclude.m4: define AC_PATH_XTRA_CORRECTED macro
 - configure.ac: use AC_PATH_XTRA_CORRECTED macro
 - Makefile.in, aclocal.m4, configure: regenerate
Files: 
 b8f25253541bae440aa5fe1ed226a417 734 x11 optional xrender_0.8.3-7.dsc
 0f06d5de045ff576542001811c3fbe88 230306 x11 optional xrender_0.8.3-7.diff.gz
 9e393b501e790ea43e34df2b42c70fef 28020 libs optional libxrender1_0.8.3-7_powerpc.deb
 3beb00a87aaa6be5ce7b7f2815142e7c 321136 libdevel extra 
libxrender1-dbg_0.8.3-7_powerpc.deb
 daeb8030fcbcc00628e36519049a070b 30250 libdevel optional 
libxrender-dev_0.8.3-7_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkBOqfQACgkQ6kxmHytGonyn5gCfXTENHyzTBggRdZdQMmO8mwxy
NVAAn0dqWKFBMNrGsRjR8+WpuOa1LmgJ
=kEgL
-END PGP SIGNATURE-


Accepted:
libxrender-dev_0.8.3-7_powerpc.deb
  to pool/main/x/xrender/libxrender-dev_0.8.3-7_powerpc.deb
libxrender1-dbg_0.8.3-7_powerpc.deb
  to pool/main/x/xrender/libxrender1-dbg_0.8.3-7_powerpc.deb
libxrender1_0.8.3-7_powerpc.deb
  to pool/main/x/xrender/libxrender1_0.8.3-7_powerpc.deb
xrender_0.8.3-7.diff.gz
  to pool/main/x/xrender/xrender_0.8.3-7.diff.gz
xrender_0.8.3-7.dsc
  to pool/main/x/xrender/xrender_0.8.3-7.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xfree86 4.3.0-5 (i386 source all)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  4 Mar 2004 23:08:44 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source i386 all
Version: 4.3.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window System video

Italian translation of my DPL platform available

[Branden Robinson]

[I am not subscribed to this list; please Cc me on replies.]

[Sorry for posting in English.]

I was invited to announce the availability of an Italian translation of
my platform for Debian Project Leader to this list.

It is available at:
http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml.it

If you have your browser configured appropriately, then:

http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml

...will bring up my platform in your preferred language, if a
translation is available.

My thanks to the gentlemen who performed this translation, who are
remaining anonymous for the time being.  You know who you are, and
you're very kind.

Spelling errors are probably the translators' responsibility, but
objectionable content is probably mine, so if you have feedback, please
raise it on the debian-vote list. :)

-- 
G. Branden Robinson|I am sorry, but what you have
Debian GNU/Linux   |mistaken for malicious intent is
[EMAIL PROTECTED] |nothing more than sheer
http://people.debian.org/~branden/ |incompetence! -- J. L. Rizzo II


signature.asc
Description: Digital signature

Accepted xfree86 4.3.0-4 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  4 Mar 2004 09:21:36 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source powerpc all
Version: 4.3.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window System

Accepted xfree86 4.3.0-3 (i386 source all)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 27 Feb 2004 15:07:25 -0500
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg 
xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh 
libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev 
xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system 
xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev 
xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg 
libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev 
libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm 
x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 
libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 
libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core 
xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base 
xlibs-dbg libxpm-de
 v xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev 
xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev 
xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source i386 all
Version: 4.3.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6- Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6 - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1- FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6 - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6- X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6 - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4- X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6 - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1 - X Window System video

Accepted render 0.8-4 (all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 19 Feb 2004 22:49:42 -0500
Source: render
Binary: render-dev
Architecture: source all
Version: 0.8-4
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 render-dev - X Rendering Extension header files and documentation
Changes: 
 render (0.8-4) unstable; urgency=low
 .
   * Make package compatible with the XFree86 4.3.0 package reorganization.
 - debian/control:
   + render-dev depends on x-dev for X protocol headers
   + render-dev conflicts with xlibs-dev ( 4.3.0) due to (now undiverted)
 file overlaps
 - debian/render-dev.preinst: remove diversions made by previous versions
   of render-dev if present
 - debian/render-dev.postrm: deleted
Files: 
 e1a8923ce693ee95713756bfd6a1 627 libdevel optional render_0.8-4.dsc
 561d1941fa02dbe073a5d746fd568e68 3311 libdevel optional render_0.8-4.diff.gz
 cca4a589d77484a80b13d6accb2b157c 25122 libdevel optional render-dev_0.8-4_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkA1nPoACgkQ6kxmHytGonzbOwCgnABeeszD7C5p7/z5+zm4KdJv
SD4AnRmaNmSPy+7YdjYp7b+yxcjDQM2o
=EM8t
-END PGP SIGNATURE-


Accepted:
render-dev_0.8-4_all.deb
  to pool/main/r/render/render-dev_0.8-4_all.deb
render_0.8-4.diff.gz
  to pool/main/r/render/render_0.8-4.diff.gz
render_0.8-4.dsc
  to pool/main/r/render/render_0.8-4.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xrender 0.8.3-6 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 19 Feb 2004 22:07:24 -0500
Source: xrender
Binary: libxrender1-dbg libxrender-dev libxrender1
Architecture: source powerpc
Version: 0.8.3-6
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
Closes: 225450 227867 230803 233812
Changes: 
 xrender (0.8.3-6) unstable; urgency=low
 .
   * Make package compatible with the XFree86 4.3.0 package reorganization.
 - debian/control:
   + package build-depends on x-dev and libx11-dev instead of xlibs-dev
   + libxrender-dev depends on x-dev and libx11-dev instead of xlibs-dev
   + increased versioned conflict of libxrender1 on xlibs to ( 4.3.0)
 due to (now undiverted) file overlaps
   + increased versioned conflict of libxrender1-dbg on xlibs-dbg to (
 4.3.0) due to (now undiverted) file overlaps
   + increased versioned conflict of libxrender-dev on xlibs-dev to (
 4.3.0) due to (now undiverted) file overlaps
 - debian/{libxrender1,libxrender1-dbg,libxrender-dev}.preinst: remove
   diversions made by previous versions of package if present
 - debian/{libxrender1,libxrender1-dbg,libxrender-dev}.postrm: deleted
 .
   * Removal of the package diversions eliminates several related problems.
 (Closes: #227867,#230803,#233812)
 .
   * Previous changelog entry corrected.  (Closes: #225450)
Files: 
 fbfa6ac25eb4bf3930a36f22f26bf679 734 x11 optional xrender_0.8.3-6.dsc
 b3c31920de66cc357cc2d8e5cd58ddfd 211104 x11 optional xrender_0.8.3-6.diff.gz
 1b7fa89b0cab910b9700e3988a59c216 27802 libs optional libxrender1_0.8.3-6_powerpc.deb
 8c580e5398f2ff8b99a5836ec6255238 320746 libdevel extra 
libxrender1-dbg_0.8.3-6_powerpc.deb
 876b7285912f2eaad92293f781a6c36c 30026 libdevel optional 
libxrender-dev_0.8.3-6_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iEYEARECAAYFAkA1p6QACgkQ6kxmHytGonyWJACfY+F9lpNFUS9I3HzP+bjSWDyv
OtsAnjZAGLakC+aK7klDSdeZDjU08Vuv
=zdip
-END PGP SIGNATURE-


Accepted:
libxrender-dev_0.8.3-6_powerpc.deb
  to pool/main/x/xrender/libxrender-dev_0.8.3-6_powerpc.deb
libxrender1-dbg_0.8.3-6_powerpc.deb
  to pool/main/x/xrender/libxrender1-dbg_0.8.3-6_powerpc.deb
libxrender1_0.8.3-6_powerpc.deb
  to pool/main/x/xrender/libxrender1_0.8.3-6_powerpc.deb
xrender_0.8.3-6.diff.gz
  to pool/main/x/xrender/xrender_0.8.3-6.diff.gz
xrender_0.8.3-6.dsc
  to pool/main/x/xrender/xrender_0.8.3-6.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Accepted xfree86 4.2.1-16 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 28 Jan 2004 11:51:38 -0500
Source: xfree86
Binary: xlibmesa3-gl xserver-common libxaw7-dbg xlibmesa-glu-dev xbase-clients twm 
x-window-system-dev xlibmesa3-dbg xfonts-scalable xfonts-75dpi libdps1-dbg xmh 
libxaw6-dbg xfwp xlibs xlibosmesa3-dbg xlibmesa3-glu libdps-dev xserver-xfree86-dbg 
xlibmesa-dev xserver-xfree86 libdps1 proxymngr xlibmesa3-glu-dbg 
xfonts-base-transcoded xlibmesa-gl-dev libxaw6-dev lbxproxy xfonts-cyrillic 
xlibmesa3-gl-dbg x-window-system-core xutils xspecs xlibs-pic x-window-system 
xfree86-common xfs xlibmesa3 xfonts-base xlibs-dbg libxaw7-dev xnest 
xfonts-100dpi-transcoded libxaw6 xfonts-100dpi xterm xfonts-75dpi-transcoded xprt 
xlibosmesa-dev xvfb libxaw7 xlibosmesa3 xdm xlibs-dev
Architecture: source powerpc all
Version: 4.2.1-16
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6) (unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 proxymngr  - X proxy services manager
 twm- Tab window manager
 x-window-system - X Window System
 x-window-system-core - X Window System core components
 x-window-system-dev - X Window System development components
 xbase-clients - miscellaneous X clients
 xdm- X display manager
 xfonts-100dpi - 100 dpi fonts for X
 xfonts-100dpi-transcoded - 100 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-75dpi - 75 dpi fonts for X
 xfonts-75dpi-transcoded - 75 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-base - standard fonts for X
 xfonts-base-transcoded - standard fonts for X (transcoded from ISO 10646-1)
 xfonts-cyrillic - Cyrillic fonts for X
 xfonts-scalable - scalable fonts for X
 xfree86-common - X Window System (XFree86) infrastructure
 xfs- X font server
 xfwp   - X firewall proxy server
 xlibmesa-dev - XFree86 Mesa development libraries pseudopackage
 xlibmesa-gl-dev - Mesa 3D graphics library development files [XFree86]
 xlibmesa-glu-dev - Mesa OpenGL utility library development files [XFree86]
 xlibmesa3  - XFree86 Mesa libraries pseudopackage
 xlibmesa3-dbg - XFree86 Mesa unstripped libraries pseudopackage
 xlibmesa3-gl - Mesa 3D graphics library [XFree86]
 xlibmesa3-gl-dbg - Mesa 3D graphics library (unstripped) [XFree86]
 xlibmesa3-glu - Mesa OpenGL utility library [XFree86]
 xlibmesa3-glu-dbg - Mesa OpenGL utility library (unstripped) [XFree86]
 xlibosmesa-dev - Mesa off-screen rendering library development files [XFree86]
 xlibosmesa3 - Mesa off-screen rendering library [XFree86]
 xlibosmesa3-dbg - Mesa off-screen rendering library (unstripped) [XFree86]
 xlibs  - X Window System client libraries
 xlibs-dbg  - X Window System client libraries (unstripped)
 xlibs-dev  - X Window System client library development files
 xlibs-pic  - X Window System client extension library PIC archives
 xmh- X interface to the MH mail system
 xnest  - nested X server
 xprt   - X print server (XFree86 version)
 xserver-common - files and utilities common to all X servers
 xserver-xfree86 - the XFree86 X server
 xserver-xfree86-dbg - the XFree86 X server (static version with debugging symbols)
 xspecs - X protocol, extension, and library technical specifications
 xterm  - X terminal emulator
 xutils - X Window System utility programs
 xvfb   - virtual framebuffer X server
Closes: 220814
Changes: 
 xfree86 (4.2.1-16) unstable; urgency=low
 .
   * Neutralize the workaround for the Linux kernel kbd_rate structure change
 after it is no longer needed, so that we don't inadvertently re-#define a
 symbol used by the Linux kernel's kbd_repeat structure.  Yeesh.  Fixes
 FTBFS on SPARC (thanks, Daniel Jacobowitz and Nathanael Nerode!)
 (Closes: #220814)
 - debian/patches/098_fix_lnx_io_kbd_rate_fix.diff
 .
   * Make xlibs's shlibs file report names of post-xlibs-split packages (and
 post-separate Xrender packaging) from experimental as alternatives to a
 versioned dependency on xlibs (requested by Daniel Stone).
 - debian/xlibs.shlibs
 - debian/shlibs.local: resync with xlibs.shlibs
Files: 
 a6c14ad37e3a2911b6431d09c6d18f1d 1713 x11 optional xfree86_4.2.1-16.dsc
 c9143c358a5891c9691eedb8039e86d1 1662615 x11 optional xfree86_4.2.1-16.diff.gz
 80c85e9e2aef5a10166685896037d529 188404 x11 optional lbxproxy_4.2.1-16_powerpc.deb
 c1eeeb8c5a3839a4730a7e9476575c4a

Accepted xcursor 1.0.2-4 (powerpc source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 Dec 2003 11:46:15 -0500
Source: xcursor
Binary: libxcursor1-dbg libxcursor-dev libxcursor1
Architecture: source powerpc
Version: 1.0.2-4
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 libxcursor-dev - X Cursor management library (development files)
 libxcursor1 - X Cursor management library
 libxcursor1-dbg - X Cursor management library (unstripped)
Closes: 225433
Changes: 
 xcursor (1.0.2-4) unstable; urgency=medium
 .
   * urgency due to fix for FTBFS
 .
   * Set priority of libxcursor1-dbg package to extra (resolves override
 disparity).
 - debian/control
 .
   * Restore build-dependency on pkg-config; AM_MAINTAINER_MODE doesn't prevent
 the ./configure script from running during a package build, and the
 ./configure script does indeed invoke pkg-config (fixes FTBFS).
 (Closes: #225433)
 - debian/control
Files: 
 94c9aef4616e1717ba815e79d450cfbe 805 - optional xcursor_1.0.2-4.dsc
 9e1817759fbe8d373fd21d4933ecf07a 208168 - optional xcursor_1.0.2-4.diff.gz
 5bbb859bf2ef7c808740f26a67194a15 24034 libs optional libxcursor1_1.0.2-4_powerpc.deb
 bdcb15afb71f7ee248498c91e65a9729 121132 libdevel extra 
libxcursor1-dbg_1.0.2-4_powerpc.deb
 e4b5e05f1827f67a4e98c5637489462a 31346 libdevel optional 
libxcursor-dev_1.0.2-4_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iEYEARECAAYFAj/xuIQACgkQ6kxmHytGonw4xACeLhYl4dhgTT/PFaHWXIy777W6
rhgAoI8+ADesBW/ghguYbYThFe4tSTT7
=e6kr
-END PGP SIGNATURE-


Accepted:
libxcursor-dev_1.0.2-4_powerpc.deb
  to pool/main/x/xcursor/libxcursor-dev_1.0.2-4_powerpc.deb
libxcursor1-dbg_1.0.2-4_powerpc.deb
  to pool/main/x/xcursor/libxcursor1-dbg_1.0.2-4_powerpc.deb
libxcursor1_1.0.2-4_powerpc.deb
  to pool/main/x/xcursor/libxcursor1_1.0.2-4_powerpc.deb
xcursor_1.0.2-4.diff.gz
  to pool/main/x/xcursor/xcursor_1.0.2-4.diff.gz
xcursor_1.0.2-4.dsc
  to pool/main/x/xcursor/xcursor_1.0.2-4.dsc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]