Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

This is an intent to mass-file bugs as required per custom.

Bugs will be filed:

 1) on packages that include GNU Free Documentation Licensed-material;
 2) on packages in 1) that do not include the copyright or license of
the material in their copyright files;
 3) at serious severity (DP sec. 2.2.1 and 12.5);
 4) with reportbug -m (maintonly@);
 5) by a human, with all facts checked first.

Two bugs will be filed on packages that meet criteria in both 1) and
2).  If the release managers would like, I will be happy to auto-tag
the bugs in 1) sarge-ignore, but if you receive such a bug, this does
not excuse you from fixing it promptly.  I will not file a bug where
one with the same subject already exists.  This will take several
days, so please do not panic if your package has not received its
bug(s) yet.

Six bugs have already been filed, and by looking at the rather large
number of packages that are affected, I figured I'd better get devel's
opinion before getting yelled at again.

In case you are wondering about bugs in case 1), please note that the
GNU Free Documentation License is non-free in all its forms, according
to the informal survey taken by Branden Robinson of the debian-legal
denizens and by my understanding of the current consensus of
debian-legal.

Packages that are related to the following info files are *potential*
candidates (please note these files have been stripped of their
suffixes):

autoconf
bison
coreutils
cpp-3.4
diff
emacs-mime
g77-3.4
gawk
gawkinet
gcc-3.4
gccinstall-3.4
gccint-3.4
gdb
gdbint
gnat-style-3.4
gnat_rm-3.4
gnat_ugn_unw-3.4
gnus
grep
groff
gzip
info
info-stnd
libidn
make
message
pgg
rl5userman
sieve
stabs
tar
texinfo
wget

Packages that are related to the following /usr/share/gnome/help/
directories are *possible* candidates:

battstat
cdplayer
char-palette
clock
command-line
dia
drivemount
eog
fdl
file-roller
fish-applet-2
gcalctool
gdm
gedit
geyes
ggv
gkb
gnome-cd
gnome-search-tool
gnome-system-log
gnome-terminal
gpdf
grecord
gtik2_applet2
gucharmap
gweather
mailcheck
mixer_applet2
multiload
rhythmbox
stickynotes_applet
totem
window-list
wireless
workspace-switcher

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

Steve Kemp <[EMAIL PROTECTED]> writes:

> On Wed, Nov 17, 2004 at 06:49:21PM +0000, Brian M. Carlson wrote:
>> This is an intent to mass-file bugs as required per custom.
>> 
>> Bugs will be filed:
>> 
>>  1) on packages that include GNU Free Documentation Licensed-material;
>>  2) on packages in 1) that do not include the copyright or license of
>> the material in their copyright files;
>>  3) at serious severity (DP sec. 2.2.1 and 12.5);
>>  4) with reportbug -m (maintonly@);
>>  5) by a human, with all facts checked first.
>
>   Without wishing to start/take part in a huge flamewar didn't we have
>  a vote and agree to leave such documentation issues until after
>  Sarge's release?
>
>   Here's the result I'm thinking of:
>
>   http://www.debian.org/vote/2004/vote_004

No, you agreed to revert the Social Contract to its previous wording,
IIRC.  The Social Contract as currently worded (with that vote in
consideration) states that "Debian Will Remain 100% Free Software".
debian-legal interprets that to mean that (and please correct me if I
am misstating the consensus) the Debian distribution must consist
completely of free software.  So if it is not software or it is not
free, then it would not be qualified to be in the Debian distribution.

Also, I think that even if those bugs in category 1) were ignored
until after the release (which would not make me happy), those bugs in
category 2) are still release-critical.  And if you are correct and
"we"[0] did agree to such a thing, then the instant that Debian releases
sarge will be the instant that these will be serious.  So fixing them
sooner rather than later is better for our users and free software.

[0] Please note that I am not a DD, and if I had been at the time of
the vote, I would have voted for Proposal F.

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

Colin Watson <[EMAIL PROTECTED]> writes:

> On Wed, Nov 17, 2004 at 06:49:21PM +0000, Brian M. Carlson wrote:
>> Bugs will be filed:
>> 
>>  1) on packages that include GNU Free Documentation Licensed-material;
>
> I recommend not filing bugs on documentation until after sarge. The
> project agreed by vote that it was not to be considered release-critical
> for sarge, so, given that your bugs suggest some highly invasive
> solutions, why be unnecessarily disruptive now?

I disagree with this conclusion.  As to the fact that the bugs suggest
"highly invasive solutions", well, there really isn't a non-invasive
solution, as much as I would like one.

>> Two bugs will be filed on packages that meet criteria in both 1) and
>> 2).  If the release managers would like, I will be happy to auto-tag
>> the bugs in 1) sarge-ignore,
>
> If you insist on filing these bugs pre-sarge, yes, please do so.
>
>> but if you receive such a bug, this does not excuse you from fixing it
>> promptly.
>
> As a matter of fact it may do depending on the contextual circumstances.
> (For example, updates to frozen packages are difficult and therefore
> limited.)

This is of course understood.  But one could always upload to
unstable, AIUI.  I am trying to *improve* the quality of the
distribution, not decrease it.  The sentence was meant to stress to
certain maintainers (who shall remain nameless) that like to ignore
debian-legal or licensing issues that I would that pursue these bugs
as vigorously as any others and that I expected them to be fixed, time
and circumstances permitting.

>> Packages that are related to the following info files are *potential*
>> candidates (please note these files have been stripped of their
>> suffixes):
>
> The number of these that relate to frozen packages scares me. You are
> likely to create a good deal of work for the release management team.
> :-( In future, please perform such widespread audits *before* base
> system freezes, not *during* them.

Sorry, I found one package and then wondered how many other packages
fell into the same category.  Unfortunately, it turned out to be a
lot.

Here's what I'm going to do as a compromise; please note that I am
trying very hard to be reasonable: I will file bugs on those packages
with incorrect or incomplete copyright files that are not frozen
(priorities optional and extra) because these are release critical
according to release policy.  The remainder of the bugs will go onto a
web page to be announced (so that maintainers can check if their
packages are affected) and will be filed as soon as the release
happens.  I will ping debian-devel once more with a notice once sarge
is released; this way, noone can claim they weren't notified of the
mass-filing.  Is this okay?

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> writes:

> El miÃ, 17-11-2004 a las 19:27 +0000, Brian M. Carlson escribiÃ:
>
> [...]
>> >   Without wishing to start/take part in a huge flamewar didn't we have
>> >  a vote and agree to leave such documentation issues until after
>> >  Sarge's release?
>> >
>> >   Here's the result I'm thinking of:
>> >
>> >http://www.debian.org/vote/2004/vote_004
>> 
>> No, you agreed to revert the Social Contract to its previous wording,
>> IIRC.  The Social Contract as currently worded (with that vote in
>> consideration) states that "Debian Will Remain 100% Free Software".
>> debian-legal interprets that to mean that (and please correct me if I
>> am misstating the consensus) the Debian distribution must consist
>> completely of free software.  So if it is not software or it is not
>> free, then it would not be qualified to be in the Debian distribution.
>
>   And documentation is not software.

Have you heard of the Lisp HTML program? Which is it, documentation or
software?

And while some documentation is not software, documentation is treated
as if it were software for the purposes of evaluating its freeness.

>> Also, I think that even if those bugs in category 1) were ignored
>> until after the release (which would not make me happy), those bugs in
>> category 2) are still release-critical.  And if you are correct and
>> "we"[0] did agree to such a thing, then the instant that Debian releases
>> sarge will be the instant that these will be serious.  So fixing them
>> sooner rather than later is better for our users and free software.
>
>  No. You have only detected some packages having GFDL documentation.
> Surgering them now will mean a lot of work, that we should concentrate
> in releasing Sarge, not in other different stuff.

I have offered (what I feel is) a very reasonable offer to hold almost
all of these bugs in abeyance until the release of sarge.  See my
reply to Colin Watson.

>> 
>> [0] Please note that I am not a DD, and if I had been at the time of
>> the vote, I would have voted for Proposal F.
>
>  Whatever you had voted, what counts is what has been decided by
> majority.

I did not claim otherwise.  I attempted to provide insight into my
reasoning.

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Nov 17, "Brian M. Carlson" <[EMAIL PROTECTED]> wrote:
>
>> This is of course understood.  But one could always upload to
>> unstable, AIUI.  I am trying to *improve* the quality of the
>> distribution, not decrease it.  The sentence was meant to stress to
> I'd say that it's not obvious at all how removing crucial documentation
> because some people do not like its license will help the distribution
> and/or the cause of free software.

I don't like a lot of licenses, specifically those that are confusing
and long and contain an "Exhibit A", because they are hard to read and
understand.  But that does not make them *non-free*.  What I have a
specific objection to in this case is the fact that the license is
non-free, not that it is long, or confusing.  You are using a strawman
example by distorting my position.

What will help the cause of free software is if we refuse to
compromise on freedom within the Debian distribution.  That is, in my
opinion, the best thing for the users and for the distribution.  And
furthermore, in my bugs, I am offering a possibility to move the
documentation to non-free.  That may be removing it from the
distribution, but it will still exist and be apt-get'able.

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Nov 17, "Brian M. Carlson" <[EMAIL PROTECTED]> wrote:
>
>> > I'd say that it's not obvious at all how removing crucial documentation
>> > because some people do not like its license will help the distribution
>> > and/or the cause of free software.
>> I don't like a lot of licenses, specifically those that are confusing
>> and long and contain an "Exhibit A", because they are hard to read and
>> understand.  But that does not make them *non-free*.  What I have a
>> specific objection to in this case is the fact that the license is
>> non-free, not that it is long, or confusing.  You are using a strawman
>> example by distorting my position.
> No, you missed the point. The point is that it's not important what
> position you hold, but that whatever your position (or mine) is, it's
> not the criteria that developers should use to determine if they need
> to remove something from the distribution.

The position that matters is that of the ftpmasters, and they usually
delegate to debian-legal.  Now however much you may or may not like
debian-legal, they are usually the ones that decide this.

>> What will help the cause of free software is if we refuse to
>> compromise on freedom within the Debian distribution.  That is, in my
> The DFSG has always been a compromise, see clause 4. It was needed to
> get TeX in debian, or most people in the free software community would
> have considered the project a joke, like it's quickly approaching to be.
> And every license is a compromise on the spectrum of different liberties
> which can be granted or not granted to different entities, it's not
> obvious at all that the specific set of compromises made by the GFDL are
> unacceptable.

I think we're going to have to agree to disagree on this one.

>> opinion, the best thing for the users and for the distribution.  And
>> furthermore, in my bugs, I am offering a possibility to move the
>> documentation to non-free.  That may be removing it from the
>> distribution, but it will still exist and be apt-get'able.
> I understand you want to become a developer. Then you should know that
> non-free is not part of Debian.

Whatever gave you that idea?  I have not once said in this thread (or
in any other, AFAIK) that I wanted to be a Debian Developer.  Maybe
someone said something on -private, I don't know.  Now, the reality is
that I would, *maybe* sometime in the future.  But it is not an urgent
desire by any stretch of the imagination, or I would have already
filed an NM application.

Also, I have known that non-free is not part of Debian for almost as
long as I have known about Debian; Graham Wilson converted me from Red
Hat and taught me what I needed to know about Debian.

Re: Intent to mass-file bugs: FDL/incorrect copyright files

[Brian M. Carlson]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (Brian M. Carlson) writes:
>
>>  1) on packages that include GNU Free Documentation Licensed-material;
>
> These are currently not bugs (but will be as soon as sarge is released
> and the Social Contract upgrade goes into effect); and indeed, I think
> packages with GFDL material already have sarge-ignore bugs filed.  For
> example, the GDB package has bug 212522 filed already.  Yet it is on
> your list.

I said that I would not file bugs on packages that already had them;
that would be silly and counterproductive.  I find that harassing
maintainers with duplicate bug reports does not endear them to you.

I generated the list with grep, awk, and sed.  Before I file the bugs,
I always check to make sure that there are no bugs already filed.  One
example which does not have a bug filed is wget.

>>  2) on packages in 1) that do not include the copyright or license of
>> the material in their copyright files;
>
> This is a bug now, but do you really think there are gobs of such
> packages?

Actually, you'd be shocked to know that this the case in at least 10
packages I've seen, and that would qualify as a mass-filing (which I
consider to be 10 or more bugs).  Usually, this happens when
maintainers don't include the GNU packages' documentation licenses or
don't include things like copyright statements.  This is easy to
overlook, and all too often it happens.  wget is a good example of
this kind of accident also.

Re: Who could be able to help SW vendors to support Debian?

[Brian M. Carlson]

On Tue, 2005-02-01 at 14:27 -0800, Marc Singer wrote:
> On Tue, Feb 01, 2005 at 11:01:25PM +0100, Francesco Paolo Lovergine wrote:
> > On Tue, Feb 01, 2005 at 11:35:41AM -0800, Marc Singer wrote:
> > > I've been under the impression that the only machine-level
> > > incompatibilities are really kernel and driver issues and not issues
> > > with Debian per se.
> > > 
> > > Can you be a little more specific?
> > > 
> > 
> > Currently for instance Matlab 6.5+ cannot be installed without a little 
> > hack in the installer, that's due to a known bug (or feature ?) in our
> > sarge libc: it is not executable, like RH ones.
> 
> I don't get the last part of that.  'it is not executable'?

I think you meant to ask, "Why would anyone want to execute the C
library?"

[EMAIL PROTECTED]:~$ ls -l /lib/libc.so.6
lrwxrwxrwx  1 root root 13 2005-01-12 20:01 /lib/libc.so.6 ->
libc-2.3.2.so
[EMAIL PROTECTED]:~$ /lib/libc.so.6
-bash: /lib/libc.so.6: Permission denied
[EMAIL PROTECTED]:~$ /lib/ld-linux.so.2 /lib/libc.so.6
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-5).
Compiled on a Linux 2.6.0-test7 system on 2004-12-27.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
software FPU emulation by Richard Henderson, Jakub Jelinek and
others
Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>.

This is UltraSparc/sid. Does that answer your question?


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

Re: execturing libc

[Brian M. Carlson]

On Fri, 2005-02-04 at 09:20 +0100, Wouter Verhelst wrote:
> On Thu, Feb 03, 2005 at 04:31:02PM +0100, Goswin von Brederlow wrote:
> > [EMAIL PROTECTED]:~% /lib64/ld-linux-x86-64.so.2 /lib/libc-2.3.2.so 
> > GNU C Library stable release version 2.3.2, by Roland McGrath et al.
> > Copyright (C) 2003 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.
> > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> > PARTICULAR PURPOSE.
> > Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-6).
> > Compiled on a Linux 2.6.0-test7 system on 2005-01-12.
> > Available extensions:
> > GNU libio by Per Bothner
> > crypt add-on version 2.1 by Michael Glad and others
> > NPTL 0.60 by Ulrich Drepper
> > BIND-8.2.3-T5B
> > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> > Thread-local storage support included.
> > Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>.
> > 
> > 
> > And exactly that info is the reason why one may want to execute libc.
> 
> There's also the fact that an executable libc is a nice way to
> circumvent a 'noexec' restriction on a mount point :-)

I don't think libc has to be executable; simply
running /lib/ld-linux.so.2 /file/on/noexec/partition will work just
fine. And personally, I wouldn't disable the executable bit
on /lib/ld-2.3.2.so; I don't know what it might do.


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

Re: list what's in the NEW queue?

[Brian M. Carlson]

On Fri, 2005-02-04 at 13:26 +0100, Frederik Dannemare wrote:
> On Friday 04 February 2005 02:30, Steve Langasek wrote:
> > On Thu, Feb 03, 2005 at 04:05:19PM +0100, Wouter Verhelst wrote:
> > > Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare:
> > > > > which
> > > > > requires no imprimatur from the DPL, before you start throwing
> > > > > packages that have never even been tested by their maintainer
> > > > > at us faster than we already get them.
> > > >
> > > > I see your point if it is really the case that uploads are being
> > > > done without proper testing from the maintainer himself/herself.
> > >
> > > His point is still valid even if all maintainers do proper testing.
> > > You can't be expected as a maintainer to be able to test /every/
> > > possible or impossible situation in which a package could be used.
> > > And then I'm not even talking about packages that should conflict
> > > with eachother but don't, because the maintainer of the new package
> > > didn't know that a file in his package happens to have the same
> > > name as a different file in a completely unrelated package...
> >
> > What I know is that every time an ftpmaster processes a batch of NEW
> > packages, a percentage of them wind up in testing with serious bugs
> > for failing to declare build-dependencies, and then the release team
> > has to track these bugs.
> >
> > Since the testing scripts have no way to distinguish an
> > architecture-specific package from a broken binary that only builds
> > on the maintainer's system, the only strategies I can think of
> > off-hand that would be effective at reducing this problem are to
> > disallow all binary uploads from maintainers, 
> [ snip ]
> 
> Yes, much better to have everything built by the buildd in a clean env, 
> IMO. This would be on my wishlist for post-sarge. This topic was also 
> discussed (for other reasons, though; security concerns, I think it 
> was) last summer.

I think this is an awful idea. This means that developers will no longer
test their packages before uploading, and we will have more bugs than
before. Why build X [0] when you don't "have to"?

[0] No attack on Branden, but it's the largest package I could think
of. 


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

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Brian M. Carlson]

On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote:
>On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
>> On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
>> > But a total of eleven is insane.
>> 
>> It is sometimes hard to get them all to work, yes.
>> 
>> It also vastly increases the quality of the Free Software in our
>> archive, as we discover bugs that appear only on one architecture.
>
>That's an overstatement.  Simply having two architectures (i386 and ppc)
>would be enough to reveal nearly all portability bugs.

False. Unaligned data access is a portability problem, and I've never
seen a bus error on any of my PPCs or i386s[0], but I have on
UltraSparc.

[0] Actually, I did have my current machine (an i686) have a problem
with a bus error, but that was because *somebody* (who shall remain
nameless) accidentally unplugged the hard disk while the computer was
running. Needless to say, the kernel did not take kindly to this.



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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Brian M. Carlson]

On Sun, 2005-03-13 at 20:45 -0800, Steve Langasek wrote:
> Architectures that are no longer being considered for stable releases
> are not going to be left out in the cold.

I disagree. I feel that maintainers are going to ignore the SCC
architectures for the purposes of portability bugs and security fixes.

> - binary packages must be built from the unmodified Debian source
>   (required, among other reasons, for license compliance)

This is a problem. No one will fix the portability bugs that plague, for
example, sparc (memory alignment SIGBUS) without them being severity
serious.

Therefore, I would support this plan *iff* it were stated that
portability bugs were still severity serious (I would not object to an
etch-ignore tag for the purpose of stating that they are irrelevant to
the release), that security bugs were still severity grave and critical
(again etch-ignore would be okay), and that maintainers actually have to
fix such bugs, or their packages could be pulled from the archive as too
buggy to support.

For the record, I own more sparc machines than any other single
architecture, and I am not pleased about this plan.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



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

Re: RFC: allow usage of mknod in postinst

[Brian M. Carlson]

On Sunday 13 November 2005 09:17, Eduard Bloch wrote:
> * Marco d'Itri [Sat, Nov 12 2005, 12:42:07PM]:
> > Package: sl-modem-source
> > Version: 2.9.9d-7
> > Severity: serious
> >
> > See policy 10.6: packages must use MAKEDEV instead of calling mknod.

I must agree with Mr. d'Itri in this case.

> I suggest changing the policy to reflect the reality. Using a wrapper
> like MAKEDEV to maintain device nodes which use arbitrary choosen
> major/minor numbers is just not very useful.

It is useful because it prevents breakage.  GNU/kFreeBSD uses devfs to manage 
devices (because FreeBSD does) and it might break our systems (though 
probably not in this particular instance).  For example:

[EMAIL PROTECTED]:~$ sudo /sbin/MAKEDEV /dev/tty
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
[EMAIL PROTECTED]:~$ uname -s
GNU/kFreeBSD

MAKEDEV does it right, and that's why it's in policy.

> In this case, there is even more code to fix the major/minor numbers
> because of a transition, you cannot seriosly tell me to "do that with
> MAKEDEV". I remember having waited _months_ for addition of DVB devices
> into makedev.

Then you have a problem with the makedev maintainer.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD
Support alternative kernels in Debian!


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[Brian M. Carlson]

On Sunday 20 November 2005 18:44, Blars Blarson wrote:
> If you need to access the BTS data from a program, there is an LDAP
> interface available and a copy of entire BTS database on one of the
> developer accessable machines.

Then "bts cache" should use that, and not HTTP, or perhaps only fall back to 
HTTP.  Additionally, the robots.txt is being violated by "bts cache", so 
perhaps someone should file a bug.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD
Support alternative kernels in Debian!


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

Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

[Brian M. Carlson]

On Wed, 2006-01-25 at 08:25 +0100, Daniel Baumann wrote:
> Joe Wreschnig wrote:
> > Are you going to sign the contract? I'm sure not putting my signature on
> > anything about MP3s.
> 
> I'm afraid I can't as a poor little NM :)

From the Book of Policy (v3.6.2.2), Section 2.3:

  We reserve the right to restrict files from being included anywhere in
  our archives if
 * their use or distribution would break a law,
 * there is an ethical conflict in their distribution or use,
 * we would have to sign a license for them, or
 * their distribution would conflict with other project policies.

Note that third point.  This also prevents shipping Sun/Blackdown Java
even in non-free because of the fourth point:  the license of Java
prohibits us from shipping competing implementations.

> > How does Debian sign a contract anyway?
> 
> I was in a simliar situation with Real, where they wanted to have signed
> a contract by a DD. This very DD is then responsible (legally) for
> compliance with the contract.

I would like to point out that if SPI (Debian's parent) doesn't have
rights to distribute (not just the individual DD), then this cannot
possibly be legally distributed by Debian.

Anyway, if that software is indeed in the archive, then it is in
violation of Policy 2.3, and should have a serious bug filed on it.




signature.asc
Description: This is a digitally signed message part

Re: limitations of reportbug and BTS

[Brian M. Carlson]

On Wed, 2006-02-15 at 14:10 -0500, kamaraju kusumanchi wrote:
> Hi
> 
>I wanted to report a minor bug on kicker using reportbug package 
> tool. But then it forces me to read a huge number of bug titles (around 
> 647 of them) most of which were not filed against kicker. For example it 
> shows bugs against kdeprinter, kate, konsole etc., Why is this so? I 
> think it kind of discourages users who want to report to bugs against a 
> single package...

It searches for bugs on the source package, which in this case is
kdebase.  You can change this behavior with --no-query-source.  My guess
for the reason that --query-source is that quite frequently, especially
with libraries, bugs will be filed on the package in which someone has
found a bug, but the bug will also be present in other packages from the
same source.

For example, see #145786, filed on libarts1 over 3 and one-half *years*
ago (and still not fixed).  This bug is still present in libarts1c2a,
but because they are from the same source package, it can be assumed
that the maintainers know about this.


signature.asc
Description: This is a digitally signed message part

Re: need help with minc

[Brian M. Carlson]

On Fri, 2006-02-17 at 00:10 -0500, Steve M. Robbins wrote:
> Hello,
> 
> I made the mistake of adding "make check" to debian/rules.  Now minc
> won't build on certain architectures.  It builds on i386 (my
> architecture), ia64, s390, and powerpc.  It fails on alpha, sparc,
> mips, hppa, arm, and mipsel.

In that case, don't bother debian-admin about sparc; I have an
UltraSparc (Sun Ultra 5) upon which I can build.  It will be up to 30
minutes before it's up to date with current sid.

> The best would be if someone would install all the build dependencies
> for minc and then let me log in to poke around.
> 
> Alternatively; someone could build minc, step through the failing
> script as follows, and send me the output of each command.

I'll be happy to run the commands, but if that doesn't help very much,
please contact me off-list and I'll be happy to create an account for
you.  That might require some firewall work, so I'd prefer not to do
that if it's not necessary.

Is there a particular version (other than 1.4-3) that I should be using?

bmc



signature.asc
Description: This is a digitally signed message part

Re: buildd and experimental

[Brian M. Carlson]

On Mon, 2006-02-27 at 22:59 -0800, Thomas Bushnell BSG wrote:
> I recently uploaded gnucash 1.9.1 to Debian experimental, but this
> doesn't seem to have affected buildd.debian.org.  Is this normal?

Yes.  You want experimental.ftbfs.de, specifically:
.  Right now,
it's only showing kfreebsd-i386, but that's probably because
experimental packages haven't been built before (and that kfreebsd-i386
uses e.f.d for all packages building).

HTH.  HAND.


signature.asc
Description: This is a digitally signed message part

Re: buildd and experimental

[Brian M. Carlson]

No need to Cc, I'm subscribed[0].

On Mon, 2006-02-27 at 23:39 -0800, Thomas Bushnell BSG wrote:
> "Brian M. Carlson" <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 2006-02-27 at 22:59 -0800, Thomas Bushnell BSG wrote:
[gnucash not appearing on buildd.d.o; is this normal?]
> > Yes.  You want experimental.ftbfs.de, specifically:
> > <http://experimental.ftbfs.de/build.php?arch=&pkg=gnucash>.  Right now,
> > it's only showing kfreebsd-i386, but that's probably because
> > experimental packages haven't been built before (and that kfreebsd-i386
> > uses e.f.d for all packages building).
> 
> Very helpful, thanks.
> 
> How do I get the package queued more generally?  Is it automatic?

I'm not sure I understand.  Is your question "how does a package get in
to the build queues for experimental?"  If so, the answer is yes, it is
automatic.  You can see the queues at www.buildd.net.  For some reason,
it appears that "gnucash [is] not registered" at least for sparc[1].
However, that is probably because gnucash has never (at least, not
recently) been built for experimental before, and the non-sid buildds
just haven't realized that it's there yet.  They'll get to it, I'm sure.

[0] In case you're unsure, you can check the X-Spam-Status header, which
will tell you that I am an LDOSUBSCRIBER, in which case you can assume
that I will ask to be Cc'd if necessary.  Not a complaint, just a note.
[1] And powerpc, but I noted that you actually uploaded the powerpc
binary.  I must remember that you upload powerpc binaries.


signature.asc
Description: This is a digitally signed message part

Re: buildd and experimental

[Brian M. Carlson]

[Please followup to -project; I am subscribed there, too, so you should
*not* Cc me.]

On Tue, 2006-02-28 at 12:13 +0100, Gabor Gombas wrote:
> On Tue, Feb 28, 2006 at 08:59:46AM +0000, Brian M. Carlson wrote:
> 
> > [0] In case you're unsure, you can check the X-Spam-Status header, which
> > will tell you that I am an LDOSUBSCRIBER, in which case you can assume
> 
> Just nitpicking: there is no X-Spam-Status: header in my copy; however,
> there is a X-Qmail-Scanner-MOVED-X-Spam-Status: header instead. And even
> if somebody founds that and somehow guesses that this is the right
> header to look at (I have extra headers added by 3 different spam
> checkers), he/she would probably have still no idea what LDOSUBSCRIBER
> means.

I understand that different mail systems do different things (although I
hope you're not using qmail[0]).  However, the code of conduct seems to
point out that one should not Cc someone unless they specifically ask
for it (a guideline that you neglected to follow, after I pointed this
out to Mr. Bushnell).  But since some new or one-time posters may not
realize this (and want to be Cc'd anyway), this provides a heuristic to
guess if someone is actually subscribed, nothing more.

If you are unsure, you could simply not Cc someone unless they ask.

[0] qmail has a nasty habit of sending backscatter, which, AIUI, cannot
be turned off.


signature.asc
Description: This is a digitally signed message part

Re: dependency on base package adduser ?

[Brian M. Carlson]

On Tue, 2005-05-10 at 11:19 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > libc6 is not and may not be marked Essential, as the NM process taught me.
> > So its a bad example.
> 
> Even if it is marked as essential, you have a versioned dependency, anyway.

But the point is, you cannot mark it essential; doing so is a severity
serious bug.  From the Policy, section 3.8:

   Since these packages cannot be easily removed (one has to specify an
   extra _force option_ to `dpkg' to do so), this flag must not be used
   unless absolutely necessary.  A shared library package must not be
   tagged `essential'; dependencies will prevent its premature removal,
   and we need to be able to remove it when it has been superseded.

Notice the the use of "must not"; that makes it severity serious.  Even
if there is no plan to change the name on GNU/Linux, that does not mean
that is the case on GNU/KFreeBSD, GNU/KNetBSD, or GNU/Hurd; that is why
glibc is not granted an exception.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: Question about replacing obsolete packages.

[Brian M. Carlson]

On Wed, 2005-06-22 at 17:43 -0400, Roberto C. Sanchez wrote:
> I was planning on adopting iceme and icepref.  However, both are no
> longer active upstream.  They are now modules of the IceWM Control Panel
> (IceWMCP).  I will package IceWMCP soon.  However, I would like to
> ensure that users with iceme or icepref currently installed see icewmcp
> as the "next version."  That is, after it goes into sid, someone with
> iceme or icepref installed should see a new version, which brings in
> icewmcp.  What is the best way in which to accomplish this?

Make iceme and icepref dummy packages that just depend on icewmcp.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: Preferred way to genereate a gpg key?

[Brian M. Carlson]

On Fri, 2005-06-24 at 18:39 -0500, Erick Vresnev Castellanos Hernández
wrote:
> While I was reading Developer's Reference [1], in the part about gpg
> keys, it says:
> 
> "You need a type 4 key for use in Debian Development. Your key length [...]"
> 
> I supposed that it refers about the "gpg --gen-key" command, and the
> options that result from executing it. Also I remember that, *in the
> past*, it was a "4" option which was something about ElGamal sign and
> encryption, or something like that. But now, in the Sarge's version of
> gpg, there is only option 1,2, and 5.

You probably want option 1, the default.  The "type 4" refers to key
version.  The only version of key that GnuPG is capable of generating is
version 4, so there should be no problems.  The old versions (versions 2
and 3, which are otherwise identical) are generated by PGP 2.3.x and
2.6.x, respectively.

The Elgamal sign and encrypt has been removed from the proposed new
standard, because it is very hard to make secure, and GnuPG made a
mistake in doing so.

> So, I ask: now what is the preferred way to generete a gpg key to
> become a debian developer? The "4" expression, and my interpretation,
> in that paragraph is it correct?

Again, you probably want option 1.  Your interpretation is probably very
common, just not correct.

> Just want to know. And if it is a bug, I hope somebody could change it
> to avoid confusion.

You are correct; it probably should be fixed.

Furthermore, my suggestion is that if you own a PC or other fast
i386-type machine, that you should use that, as opposed to a PowerPC or
Sparc, because i386s gain entropy faster in my experience, and you need
a lot of entropy.  Just a suggestion; it is not required.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: (Re)Build problem with g++ 4.0

[Brian M. Carlson]

On Thu, 2005-07-07 at 23:57 +0200, Juergen Salk wrote:
> Hi,
> 
> first of all: if this is not the appropriate list for this kind 
> of question, please give me pointer to better one.
> 
> I am having problems with rebuilding my dcmtk package with g++
> 4.0 on Sid. The problem seems to be related to type casting
> between pthread_t and unsigned long int types and vice versa by 
> means of the `reinterpret_cast < > () operator'. With g++ 3.3 the 
> package builds fine right out of the box.
> 
> Here is a bare bone example to illustrate the problem:


> dummy = reinterpret_cast  (a_thread);

This should be a static_cast.  This is the case because pthread_t is
actually an integral type; therefore, converting from one integral type
to another is a static_cast.

On my machine (i386/sid and i386/experimental), the following is the
type of pthread_t:

typedef unsigned long int pthread_t;

> void *thread_func(void *arg) {
> sleep(3);
> pthread_exit(0);

You are also neglecting to return a value here.  You must always return
a value in a non-void function.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: Use clisp shiped with source or from Debian?

[Brian M. Carlson]

On Tue, 2006-04-11 at 21:06 +, Joerg Sommer wrote:
> Hi,
> 
> I would like to pack Xindy an index processing system like makeindex.
> Xindy's source comes with clisp 2.33.2 and it is compiled at build time.
> 
> I've got it managed to build with the clisp package from Debian. But I
> have little problem and saw the Debian package depends on X11. Upstream
> do not support other versions than this one shipped with the source and
> depending on the clisp package would make more packages need to be
> installed to use Xindy -- a simple text processor needs X11.
> 
> On the other hand I can decrease the compile time heavily, make the
> package architecture independent and smaller. And I see the problem that
> I have to track the development of clisp and maybe backport (security)
> bugs if I use the clisp version from the tarball.
> 
> What do you think? Is it better to use the clisp version shipped with the
> source tarball or use the Debian package?

I think it is much better to use the Debian package.  The security team
will thank you, as will current and future porters.  As an occasional
porter for GNU/kFreeBSD, I can say that the biggest problem I've
encountered is the plethora of versions of libgc (the boehm garbage
collector), almost all of which have been slightly hacked to support
some feature or another.

Not only does this make more work for me and other porters, should there
ever be a security bug in libgc, my mail server will probably die under
the load of all the DSAs sent.

Additionally, rebuilding software bloats the archive and prevents fixes
that may be Debian-specific (think FHS) from being uniformly applied.
It also increases build times on older architectures (think m68k).

And, from a purely selfish point of view, you want the Debian clisp
maintainer and clisp upstream to do the work of making clisp work in
Debian, not you.  You will be able to give your package more attention
if you work on fixing the Xindy bugs, and not the clisp bugs.  It's
better for both you and the users.

And if you needed any more arguments: Debian is not Windows.  DLL Hell
is explicitly unsupported on Debian.


signature.asc
Description: This is a digitally signed message part

Re: Trouble with some X applications.

[Brian M. Carlson]

On Fri, 2006-04-28 at 21:03 +0200, Klaus Ethgen wrote:
> Hi,
> 
> After an upgrade of my system some days ago I found some (in words two)
> programms not working. The first ist gkrellm and the second is
> nvidia-settings.
> 
> The effect is that when I try to start them they will hang. strace says
> it hangs in a rt_sigsuspend()-systemcall.
> 
> As I have no exactely clou what did trigger this bug I whanna ask here.

Don't ask here.  Ask on debian-user (or debian-user-german, if it
exists), as this is where the question belongs.  The people there can
help you with some tricks to determine what specifically is not working,
and why.

> My system configuration:
> Dist: sid (In fact the error is not in etch)
> Kernel: 2.4.32 Vanilla with some patches.

Good luck using a 2.4 kernel.  I understand that after etch, glibc 2.4
will be uploaded.  IIRC, glibc 2.4 removes support for LinuxThreads, so
only NPTL (which requires Linux 2.6) will work.  Make the upgrade now,
and save yourself a lot of headaches (of which this might be one).

> Newest updates installed
> 
> I suggest it has anythink to do with the new xorg as it happens on two
> independing software. But which of the xorg components???

When you follow up to -user, you should show the relevant sections of
dpkg.log, so that people know what packages could have caused the
problem.

> Did someone else has the same problemes?

May I point you to the following page:

http://www.catb.org/~esr/faqs/smart-questions.html

Specifically, the following sections:

Before You Ask
Choose your forum carefully
As a second step, use project mailing lists
Be precise and informative about your problem
Describe the problem's symptoms, not your guesses
Describe your problem's symptoms in chronological order

HAND.


signature.asc
Description: This is a digitally signed message part

Re: debian and UDEV

[Brian M. Carlson]

On Tue, 2006-05-16 at 08:52 +0600, Alexander E. Patrakov wrote:
> Matt Zimmerman wrote:
> > You don't need to wait for a particular event to be finished processing;
> > instead you should wait for the resource you actually need to become
> > available, e.g. a device node.
> > 
> > It would be useful to add a simple utility for this to debianutils or
> > similar so that it doesn't need to be reimplemented in so many places.
> 
> Why not use "udevsettle" that comes with new udev just for this purpose?

Probably because:

* you'd have to depend on udev (>= 0.090-1), which:
  - is not Essential: yes, unlike debianutils
  - means your code will no longer work on 2.4 kernels, or non-Linux
ports
  - means that if udev ever goes away (we hope) your package will FTBFS
  - means your code will no longer be backportable
  - means that your package will have a dependency on a package that
breaks frequently[0]
  - means that if any version of udev stops working with your package,
you will have to conflict with it
* "man 8 udevsettle" doesn't tell you:
  - that the default timeout is *three minutes*, which is a totally
unreasonable default for obvious reasons
  - what the return codes are in case of success, failure, or timeout
* whether the event queue has settled tells you nothing about whether a
  resource is available

Need I say more?

[0] No other package, to my knowledge, has the same combination of being
essential for booting the system, huge numbers of high severity bugs,
gratuitous incompatibility with older kernels, and frequent bugs on
non-i386 architectures.


signature.asc
Description: This is a digitally signed message part

Re: I want to modify the gnome panel deb package

[Brian M. Carlson]

On Wed, 2006-05-17 at 02:44 -0400, Roberto C. Sanchez wrote:
> Indraveni wrote:
[snip]
> I notice that you have asked lots of questions on the debian-user and
> debian-devel lists.  Not that there is anything wrong with that, but you
> may wany to consider hiring a Debian consultant [0] to help the process
> go smoother.

However, it *is* a problem to violate the Code of Conduct[0].  To quote
the page:

  Never send your messages in HTML; use plain text instead.

A bug has already been filed[1]; I will be following up to it
encouraging its adoption.

[0] http://www.debian.org/MailingLists/#codeofconduct
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353846


signature.asc
Description: This is a digitally signed message part

Re: Sun Java available from non-free

[Brian M. Carlson]

[For -legal people, the license is attached.]

On Wed, 2006-05-17 at 11:01 +0200, Michael Meskes wrote:
> On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> > Official packages of Sun Java are now available from the non-free
> > section of Debian unstable, thanks to Sun releasing[11 Java under a new
> > license: the Operating System Distributor License for Java (DLJ)[2][3].
> > This license, while still non-free, allows the Sun Java Runtime
> > Environment (JRE) or Java Development Kit (JDK) to be distributed by
> > Debian, with our own packaging.
> 
> Could someone please explain to me why paragraph 2(f) does not pose a
> problem? I couldn't find ANY discussion about the license on Debian legal
> which surprises me a little bit, but then maybe I just missed the
> relevant parts of the license. Anyway, as a non-lawyer I'm surprised
> that we seem to accept that we have to "defend and indemnify Sun".

Also, section 4 poses a major issue.  If, for any reason, the Linux
kernel doesn't do something that Java requires, then we are obligated to
either fix it or inform everyone who has acquired Java from us.

Section 10 is not possible with our infrastructure.  The ftp-master
scripts merely remove the package from the tag database, not the archive
(at least until there are no dependencies), and not from all of our
mirrors.

Section 2(b) prohibits allowing people to develop software with Java
that is to be run on another system.

Section 2(c) prohibits us from using the software in conjunction with C,
C++, Perl, Python, or *any reasonable Turing-complete programming
language*.

Section 12 requires that this software be in non-US/non-free.  It is
not, which is not only a violation of the license, but a violation of
United States law.

This conflicts with other project policies and exposes Debian/SPI to
major legal liabilities.  I think that this should be removed from the
archive as soon as possible, preferably before the next mirror pulse.
Operating System Distributor License for Java version 1.1

SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE JAVA PLATFORM
STANDARD EDITION DEVELOPER KIT ("JDK" - THE "SOFTWARE") TO YOU ONLY
UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
LICENSE AGREEMENT (THE "AGREEMENT").� PLEASE READ THE AGREEMENT
CAREFULLY.� BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
ACCEPT ALL OF THE TERMS OF THE AGREEMENT.

1.  DEFINITIONS. "Software" means the code identified above in binary
form, any other machine readable materials including, but not
limited to, libraries, source files, header files, and data files),
any updates or error corrections provided by Sun, and any user
manuals, programming guides and other documentation provided to you
by Sun under this Agreement, and any subsequent versions that Sun
makes available to you hereunder.  "Operating System" means any
version of the Linux or OpenSolaris operating systems that manages
the hardware resources of a general purpose desktop or server
computer and shares these resources with various software programs
that run on top of it. "Programs" means Java technology applets and
applications intended to run on the Java Platform Standard Edition
(Java SE platform) platform on Java-enabled general purpose desktop
computers and servers.

2.  License Grant. Subject to the terms and conditions of this
Agreement, as well as the restrictions and exceptions set forth in
the Software README file, Sun grants you a non-exclusive,
non-transferable, royalty-free limited license to reproduce and use
the Software internally, complete and unmodified, for the sole
purposes of running Programs and designing, developing and testing
Programs.  Sun also grants you a non-exclusive, non-transferable,
royalty-free limited license to reproduce and distribute the
Software, directly or indirectly through your licensees,
distributors, resellers, or OEMs, electronically or in physical
form or pre-installed with your Operating System on a general
purpose desktop computer or server, provided that: (a) the Software
and any proprietary legends or notices are complete and unmodified;
(b) the Software is distributed with your Operating System, and
such distribution is solely for the purposes of running Programs
under the control of your Operating System and designing,
developing and testing Programs to be run under the control of your
Operating System; (c) you do not combine, configure or distribute
the Software to run in conjunction with any additional software
that implements the same or similar functionality or APIs as the
Software; (d) you do not remove or modify any included license
agreement or impede or prevent it from displaying and requiring
acceptance; (e) you only distribute the Software subject to this
license agreement; and (f) you agree to defend and indemn

Re: Mass bug filing: failure to use invoke-rc.d when required

[Brian M. Carlson]

On Wed, 2006-05-17 at 09:19 +0100, Adam D. Barratt wrote:
> On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <[EMAIL PROTECTED]>
> wrote:
> > On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote:
> >> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti:
> [...]
> >>> AFAIK, vilolating policy always waarent a serious bug:
> [...]
> >> This is not what Steve Langasek tells me (or else I'm seriously
> >> misunderstanding). The etch_rc_policy.txt document is what documents
> >> what is release critical.
> >
> > Doesn't that mean the bug is severity serious, but should be tagged
> > "etch-ignore"? That's what we did with sarge, if I remember well?
> 
> No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it
> for the release of foo". Any bug tagged "etch-ignore" is by definition RC
> the moment etch is released.
> 
> The exact definition of what qualifies for a severity of serious or above
> (i.e. RC) are the purview of the Release team, as noted at
> http://www.debian.org/Bugs/Developer#severities. A "severe violation of
> Debian policy" is one which violates the current release policy, as laid out
> by the Release team.

Then when are we removing the debian-policy package from the archive?
But seriously, if violating Debian Policy has no consequences, then it
probably won't be followed.  As it stands now, Policy is useless because
the worst that can happen is an important bug, which can be safely
ignored almost forever.

As far as the etch_rc_policy.txt, there are at least 10 different issues
with that document that may be unintended, one of which is that as it
stands now, all perl-using packages *must* depend on perl-base, and all
python-using packages *must* depend on the package providing the
interpreter (/usr/bin/python is *not* an interpreter, merely a symlink),
such as python2.3, python2.4, or python2.5[0].

At least with debian-policy, any changes must actually be discussed and
viewed by several people, which increases the probability that this type
of error is found and corrected, hopefully before it even becomes
policy.

Finally, I would prefer if some tag existed that would indicate that a
bug is not a concern for the release but is still a major error in terms
of Debian Policy.  I understand that such tags *do* exist, and that they
are called "sid" and "experimental".  I also understand that these are
deprecated with BTS version tracking; however, since these tags have the
desired effect, and there are no other ones with equivalent effect, I
will use them for all of my current and future bugs.

[0] 5g of the the etch RC policy [sic][1]:
Scripts must include the appropriate #! line, and set executable.
The package providing the script must Depend: on the appropriate
package providing the interpreter.
[1] The text in [0] should say "be set executable" or "be executable"
or even "have been set executable", instead of "set executable".



signature.asc
Description: This is a digitally signed message part

Re: copyright vs. license

[Brian M. Carlson]

On Wed, 2005-01-12 at 12:52 -0500, Justin Pryzby wrote:
> Hi all,
> 
> I've been manually filing bugs against packages with improper
> copyright files, as per this thread:
> 
>   http://lists.debian.org/debian-devel/2004/03/msg02190.html
> 
> I stopped when I started gettign consecutive bug numbers :)  I've been
> using Severity: normal, although it is arguably a violation of Policy
> 12.5:
> 
>   Every package must be accompanied by a verbatim copy of its
>   copyright and distribution license in the file
>   /usr/share/doc/package/copyright.

This is what I was going to file bugs on previously (as well as GFDL
bugs) [0]. Missing copyright statements, lack of references to the GPL,
licenses in the /usr/share/doc/foo directory instead of in the copyright
file, etc. Honestly, I have seen very few good copyright files.

> I have lintian and dh-make bugs that will help prevent this in the
> future:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286842
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286843

Thank you.  I wrote a tool that checks copyright files of installed
packages for problems. It is very, well, anal. But you're welcome to it
if you want it. [1] I wouldn't file bugs on all of its output, though,
because it's so picky.

> But these certainly still need to be fixed:
> 
>   Copyright:
> 
>   GPL 2.0
> 
> another one:
> 
>   Copyright: Most recent version of the GPL.
> 
> and this is common:
> 
>   Copyright:
> 
>   [GPL follows]
> 
> Starting with installed package "aalib1" (no problem there), I opened
> ~30 bugs in specific packages, and I didn't even make it to "gcc".

In future, you should ask on -devel first before mass-filing bugs,
otherwise you will be fed to Colin Watson. [2] And you might want to
wait until after sarge, whenever it happens, because otherwise the
release team will become cross with you.

> Please Cc: me,
> Justin

I am doing so.

[0] http://lists.debian.org/debian-devel/2004/11/msg00429.html
[1] Contact me off-list.
[2] And remember, you are crunchy and taste good with tartar sauce :-)


signature.asc
Description: This is a digitally signed message part

Re: libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)

[Brian M. Carlson]

On Sat, 2005-07-23 at 01:33 +0200, Jens Peter Secher wrote:
> I am fighting with libcrypto++ but so far I am loosing.  
> 
> GCC4 does definitely not like a mix of templates and anonymous enums
> [1,2] but there are easy fixes for this.
> 
> What is worse, it seems that GCC4 silently refuses to generate code for
> some template instantiations, which results in undefined symbols in the
> library, as others have experienced [3].  It might however be the case
> that GCC4, being more C++ standards compliant, has simply revealed a
> problem in the Crypto++ template code.
> 
> In any case, the fact is that the non-debian, clean upstream library
> code (5.2.1) compiles and links fine with GCC3, but fails to do so with
> GCC4.  I am still investigating...

I have experience with porting it to 3.3 or 3.4, I don't remember which.
Some minor restructuring of the code is necessary, but I'll look at it.
Feel free to mail me off-list if you want.

I'll be working on the Debian code, since that likely has fewer problems
(missing some patent-encumbered parts, like IDEA).
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: RFC, problem with g++4

[Brian M. Carlson]

On Fri, 2005-07-29 at 10:55 +0300, Jaakko Niemi wrote:
>  Hello,
> 
>  /usr/include/sys/socket.h has this:
> 
> -
> /* The following constants should be used for the second parameter of
>`shutdown'.  */
> enum
> {
>   SHUT_RD = 0,  /* No more receptions.  */
> #define SHUT_RD SHUT_RD
>   SHUT_WR,  /* No more transmissions.  */
> #define SHUT_WR SHUT_WR
>   SHUT_RDWR /* No more receptions or transmissions.  */
> #define SHUT_RDWR   SHUT_RDWR
> };
> -
> 
>  which results into error when compiling sfs with g++ 4.x:
> 
> rexchan.C: In member function 'virtual void unixfd::data(svccb*)':
> rexchan.C:254: error: '' is/uses anonymous type
> rexchan.C:254: error:   trying to instantiate 'template R, class B1, class A1, class AA1> refcounted B1, A1>, scalar>* wrap(C*, R (C::*)(A1, B1), const AA1&)'
> rexchan.C:254: error: no matching function for call to 'wrap(unixfd*
> const, void (unixfd::*)(int, int), )'
> 
>  rexchan.C:254 is:
> 
> paios_out->setwcb (wrap (this, &unixfd::update_connstate, SHUT_WR));
> 
>  Now, should libc name that enumeration, g++ generate warning instead
> of error or moon be mined for cheese snacks?

I think the moon should be mined for cheese snacks.  No, just kidding.

libc6 should not name an enumeration except either in the implementation
namespace or as required by POSIX.

What I think it should do, and this is JMHO, is just:
#define SHUT_RD 0
#define SHUT_WR 1
#define SHUT_RDWR 2

and leave the enumeration out of it, since it's not required, and can
actually break things, if the values are not within the value of an int.
For example, the Sparc/UltraSparc fpu_control.h.

I definitely like gcc's strictness, so it should definitely be an error.
I think the reason that g++ is so strict on anonymous enums is that it
had problems with mangling their names (since they don't have any name,
it's sort of hard to mangle them).  Also, I believe it violates the C++
standard for that very reason.

Of course, I could be persuaded that the enumeration is a good idea, but
I don't see what problem it solves, and it only seems to cause them.
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Public service announcement about Policy 10.4

[Brian M. Carlson]

This is a public service announcement about Debian Policy section 10.4,
which states in part:

  The standard shell interpreter `/bin/sh' can be a symbolic link to any
  POSIX compatible shell, if `echo -n' does not generate a newline.[1]
  Thus, shell scripts specifying `/bin/sh' as interpreter should only
  use POSIX features.  If a script requires non-POSIX features from the
  shell interpreter, the appropriate shell must be specified in the
  first line of the script (e.g., `#!/bin/bash') and the package must
  depend on the package providing the shell (unless the shell package is
  marked "Essential", as in the case of `bash').

I have found no less than four packages which break with /bin/posh
as /bin/sh, including one that refuses to be removed because of its
brokenness.  I am expecting many more.

I suggest that all maintainers test their packages with /bin/sh
as /bin/posh as well as _POSIX2_VERSION=200112 in their configuration
files.  Please be aware that due to debconf brokenness that is caused by
non-POSIX features, if you do set /bin/sh as /bin/posh, you may not be
able to undo this without manually patching debconf or waiting for it to
be fixed.  Bugs have already been filed about this (not by me).

I would like to point out that the following are not POSIX features:

local
test -o
test -a

You may fix these bugs by specifying "#!/bin/bash" as the first line of
your script, or you may simply remove these non-POSIX extensions.

I would also like to point out that these bugs are severity not less
than important, so you may want to fix these bugs if they occur in your
packages, even if they have not been filed in the BTS yet.

This ends the public service announcement.  Thank you for your attention
to this matter.  Have a nice day.
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: When is the C++ transition needed?

[Brian M. Carlson]

On Thursday 06 October 2005 12:45, Henning Makholm wrote:
> I notice that the newest upload of pstoedit has reverted the C++
> transition name change; instead of libpstoedit0c2 sid now contains
> libpstoedit0, as in sarge.

This is, IMHO, incorrect.

> However, the library exports things with interfaces such as
>
> #ifdef __cplusplus
> extern "C" DLLEXPORT
> int pstoeditwithghostscript(int argc,
> const char *
> const argv[],
> ostream& errstream,

You must not pass by reference with an extern "C" declaration, because C 
doesn't support that.

> const DescriptionRegister* const pushinsPtr=0

You also must not use default parameters, as C does not support that.  The 
alternative implementation with one less/one more parameter would also not 
work because C does not mangle names.

> );
> #endif
>
> Does this not need transitioning for the ABI change?

It does need transitioning.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)


pgpKMO1eXO7Hs.pgp
Description: PGP signature

Re: Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]

[Brian M. Carlson]

On Monday 07 November 2005 11:28 pm, Francesco Poli wrote:
> [Added Cc: debian-legal, because the topic may be of interest there,
> I would say.]
> [No need to Cc: me, as long as you keep Cc:ing debian-legal (just to
> make things clear: I am subscribed to debian-legal, but not to
> debian-devel)]
> > used in conjunction with the presentation. The authors have the
> > freedom to pick a DFSG-free license for the papers themselves and
> > retain all copyrights.
>
> "The authors have the freedom to pick a DFSG-free license" means that
> they *may* do so, but are not required to. Am I correct?

The way I read it was that "the authors may pick any license, so long as it's 
DFSG-free".  Do you see how it could be read that way?

Now, because they are the copyright holders, they could additionally license 
it in some other way, too.  But they must at least offer a DFSG-free license.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: per-user temp directories by default?

[Brian M. Carlson]

On Saturday 05 November 2005 11:27 pm, Brian May wrote:
> Can't we just pick one standard name for the environment variable and
> stick to it?

If we do that, I'd request that it be $TMPDIR, as that's what SUSv3 has 
standardized.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: OT: Humor: Re: Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]

[Brian M. Carlson]

On Tuesday 08 November 2005 01:58 am, Adam Heath wrote:
> On Tue, 8 Nov 2005, Brian M. Carlson wrote:
> > The way I read it was that "the authors may pick any license, so long as
> > it's DFSG-free".  Do you see how it could be read that way?
>
> You sound just like Henry Ford.

My goal was to do exactly that.  I was hoping someone would catch it. :-)

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: miBoot floppies for debian-installer and use of people.debian.org

[brian m. carlson]

On Sat, Jan 26, 2008 at 11:55:05AM -0500, Daniel Dickinson wrote:

Hi all,

I have a question.  I have at various times been interested on getting
Debian working on an Old World PowerPC Macintosh and have come across a
situation that confuses me.  I was able to get the mac working with the
use of floppies that include a tool call miBoot, that are distributed
on people.debian.org/~dontremember.  The main debian-installer daily
builds do not include the miBoot floppy images.

The thing is the reason they are not part of debian proper is that
miBoot is non-free and possibly non-distributable (see below).  My
question is whether including them on p.p.o is therefore a violation of
debian policy?  It seems odd to me that p.p.o should be used as a way
around debian policy.


While this is not within my purview (IANADD), Debian developers may 
choose to have experimental repositories on p.d.o including non-free 
software, so I don't think this is a problem.  Obviously, 
undistributable software is exactly that, but I don't think that is the 
case.


And for the record, if miBoot is GPL'd, it is Free Software.  If it 
requires a non-free compiler to build, that is indeed unfortunate, but 
that does not make miBoot any less GPL'd.



miBoot is GPL but requires CodeWarrior (a proprietary compiler) to
build, and *cannot* be built with free tools (although work is underway
to change this).  My understanding of the debian interpretation of of
the GPL is that this makes miBoot non-distributable because under the
GPL everything required to build the binaries must be available as
source, including the compiler (unless the compiler is part of the
system the code is built on, which is not the case here) and since the
compiler is not available as source code debian cannot meet its GPL
obligations for miBoot-based binaries.


No.  You are mistaken.  Debian requires source and that all packages 
must build from source.  Debian also requires that packages in main must 
require only packages in main for building and execution.  Hence, a 
package that requires packages outside of Debian (main) for compilation 
or execution must be in contrib if it is free, and non-free if it is 
not.


The GPL does not factor into this.  It permits one to use a proprietary 
compiler to build GPL'd source; this has been done on Windows and 
proprietary Unixes for ages.  Obviously, one must comply with the source 
requirements, as always.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Introducing security hardening features for Lenny

[brian m. carlson]

On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:

On Tue, Jan 29, 2008 at 10:31:48PM +, Moritz Muehlenhoff wrote:

There are certainly performance trade-offs involved and the final
selection of features will depend on the testing of the respective
maintainers (testing should be eased by hardening-wrapper).


 I understand. To be fair, I'm worried in the implications of the SSP,
FORTITY_SOURCES and PIE proposals. Others looks fine, but those three
may have very important performance issues embedded.

* PIE is just IMHO not an option on x86 :/


If you use shared libraries, you already have this performance hit, and 
if you want to use %ebx in non-PIC code, you have to save and restore it 
around each shared-library function call.  Also note that x86 has other 
problems (namely the 387) that make it unsuitable as a serious 
architecture.



 Though probably someone should come up with some benchmarks. The usual
culprits (multimedia libraries, html renderers, xml processors, …) all
provide easily deployed bench, and before we go any further I'd like to
see some numbers.


And now for some numbers, on an amd64 machine (/proc/cpuinfo at [0]), 
crypto code with heavy optimization in a shared library.  All object 
files (including for the executable) are compiled with -fPIC, because 
I'm lazy.


Performance without protection:

MD4: 335544320 bytes in 0.745s (429.667 MiB/s)
MD5: 335544320 bytes in 1.055s (303.452 MiB/s)
RMD160: 335544320 bytes in 1.757s (182.169 MiB/s)
SHA1: 335544320 bytes in 1.801s (177.693 MiB/s)
SHA256: 335544320 bytes in 3.519s (90.928 MiB/s)

With -fstack-protector only:

MD4: 335544320 bytes in 0.748s (427.999 MiB/s)
MD5: 335544320 bytes in 1.056s (302.979 MiB/s)
RMD160: 335544320 bytes in 1.751s (182.744 MiB/s)
SHA1: 335544320 bytes in 1.804s (177.348 MiB/s)
SHA256: 335544320 bytes in 3.515s (91.028 MiB/s)

With -D_FORTIFY_SOURCE=2 only:

MD4: 335544320 bytes in 0.745s (429.670 MiB/s)
MD5: 335544320 bytes in 1.053s (303.846 MiB/s)
RMD160: 335544320 bytes in 1.756s (182.225 MiB/s)
SHA1: 335544320 bytes in 1.794s (178.330 MiB/s)
SHA256: 335544320 bytes in 3.514s (91.057 MiB/s)

With -fPIE -pie only:

MD4: 335544320 bytes in 0.741s (431.703 MiB/s)
MD5: 335544320 bytes in 1.052s (304.173 MiB/s)
RMD160: 335544320 bytes in 1.755s (182.381 MiB/s)
SHA1: 335544320 bytes in 1.797s (178.104 MiB/s)
SHA256: 335544320 bytes in 3.517s (90.996 MiB/s)

With all three features:

MD4: 335544320 bytes in 0.744s (429.978 MiB/s)
MD5: 335544320 bytes in 1.058s (302.479 MiB/s)
RMD160: 335544320 bytes in 1.758s (182.071 MiB/s)
SHA1: 335544320 bytes in 1.793s (178.471 MiB/s)
SHA256: 335544320 bytes in 3.520s (90.896 MiB/s)

In conclusion, there is no appreciable performance hit on any algorithm.  
Note that these are all hash algorithms, but they all make heavy use of 
memcpy, and are extremely CPU-intensive.


Code available upon request.

[0] https://crustytoothpaste.ath.cx/machines/lakeview

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: linux-kernel-headers???

[brian m. carlson]

On Wed, Jan 30, 2008 at 12:44:17AM +0100, Cyril Jaquier wrote:

Why do not the linux-source-2.6.* packages provide linux-kernel-headers?


First of all, linux-kernel-headers has been replaced by linux-libc-dev.  
But either way, the answer is the same: those packages install them in 
/usr/include, which is unpacked and accessible to any program being 
compiled.  linux-source-2.6.* (AFAIK) is not unpacked by default, and 
even when it is unpacked, the headers are not accessible under 
/usr/include.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Copyright question

[brian m. carlson]

[Please follow up to -legal only.  Full quote for the benefit of -legal.]

On Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon wrote:

Hi,
I intend to package HPL benchmarks. Copyright file contains the
following statements:
--
1. Redistributions  of  source  code  must retain the above copyright
notice, this list of conditions and the following disclaimer.   

2. Redistributions in binary form must reproduce  the above copyright

notice, this list of conditions,  and the following disclaimer in the
documentation and/or other materials provided with the distribution.

3. All  advertising  materials  mentioning  features  or  use of this
software must display the following acknowledgement:
This  product  includes  software  developed  at  the  University  of
Tennessee, Knoxville, Innovative Computing Laboratories.

4. The name of the  University,  the name of the  Laboratory,  or the

names  of  its  contributors  may  not  be used to endorse or promote
products  derived   from   this  software  without  specific  written
permission.  



I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
someone help me ? If it's not ok, may it be in contrib ?


This is a standard BSD-with-advertising-clause, so yes, this is 
DFSG-free.  Only DFSG-free material may go in main or contrib; material 
that does not meet the DFSG must go in non-free.  Also note that due to 
the advertising clause (clause 3), this license is not compatible with 
the GPL.


In future, please post questions about copyright and licenses to -legal, 
where the regulars are well versed.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: dash bug which is affecting release goal

[brian m. carlson]

On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote:

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Dash has a serious bug which is causing grief.
>
> The problem is that it overrides the system's "test" command (in
> Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> inconsistent with the Debian versions.


As far as I can tell, /usr/bin/test and /usr/bin/[ are completely 
useless, because none of bash, dash, posh, or zsh use them.  Maybe pdksh 
does, but that's pretty much the list of shells that could be coerced 
into being /bin/sh.  I propose we remove those executables from 
coreutils if it turns out that they are never executed.



The only builtin which we identified needed to be on that list was test
itself, and the problem here was that the deviations in posh's
implementation of test would pose serious problems.


The standard posh follows is Debian Policy.  If you change Policy, I am 
pretty sure that posh will follow[0].  Policy currently specifies a set 
of features that are required above and beyond minimal POSIX standards 
(echo -n).


Note that people often like to use local, so if that's something that 
people think should be implemented[1], then you might want to add that 
to the list as well.  IMHO, all five of the shells listed above should 
be able to be used successfully as /bin/sh.



That could be solved by saying something like "test may be builtin in
inconsistent ways, provided that X, Y, and Z features still are
supported."  That could be written (by careful choice of X, Y, and Z) to
enable bash and dash to pass muster and still avoid the problems that
supposedly are raised with posh.  


If you do not like posh's behavior, then please propose an amendment to 
policy to add additional features required by shells implementing 
/bin/sh.  I am certain posh will implement those features.



The other solution--which may be an acceptible short-term one, is to
specify explicitly that shell scripts must work with Debian bash and
Debian dash.  I have no objection to that, and continue to think it is
the simplest approach.


I think this is ridiculous.  One of the benefits of Debian is the huge 
amount of choice.  We provide at least 10 window managers, 6 desktop 
environments, and some insanely large amount of music players.  People 
should be free to choose the shell that best fits their needs, and 
providing an API (a list of required features) is far superior to 
mandating an implementation.


I don't see what your problem is with posh.  It serves a legitimate 
purpose: providing the bare minimum required by Policy.  It's useful as 
a test of Policy-compliance, and not much more, which is fine.


[0] I believe that Clint Adams said as much himself.
[1] I have no opinion on this, other than that I want udev to work with 
posh.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: dash bug which is affecting release goal

[brian m. carlson]

[No need to Cc me; I'm subscribed.  Please respect my M-F-T.]

On Sun, Feb 10, 2008 at 08:39:45PM -0600, William Pitcock wrote:

On Sun, 2008-02-10 at 22:11 +0000, brian m. carlson wrote:
As far as I can tell, /usr/bin/test and /usr/bin/[ are completely 
useless, because none of bash, dash, posh, or zsh use them.  Maybe
pdksh 
does, but that's pretty much the list of shells that could be coerced 
into being /bin/sh.  I propose we remove those executables from 
coreutils if it turns out that they are never executed.


As far as I know, test and [ are infact required to be executables.
POSIX says so. I'm .. beyond words right now at this paragraph.


You are correct; I checked.  And POSIX does provide a good rationale for 
it, so I withdraw my proposal.  I didn't consider the fact that they 
might be used by programs such as /usr/bin/env.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#468221: ITP: missidentify -- a program to find win32 applications

[brian m. carlson]

On Wed, Feb 27, 2008 at 09:07:33PM +0100, Monniez Christophe wrote:

Miss Identify is a program to find Win32 applications.
In its default mode it displays the filename of any executable that 
does not have an executable extension 
(i.e. exe, dll, com, sys, cpl, hxs, hxi, olb, rll, or tlb).
The program can also be run to display all executables encountered, 
regardless of the extension.

This is handy when looking for all of the executables on a drive.
Other options allow the user to record the strings found in an 
executable and to work recursively


What does this do that file(1) does not?

lakeview ok % file setup.exe 
setup.exe: MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit, UPX compressed


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#467249: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale

[brian m. carlson]

On Thu, Feb 28, 2008 at 09:30:55PM +, Colin Watson wrote:

On Thu, Feb 28, 2008 at 09:21:41PM +0100, Adam Borowski wrote:
man-db really does have some special-casing here. Trust me. It was
necessary at the time. There are a finite number of known aliases for
the very small number of locales in question, and until it becomes
unnecessary I will simply support those.

(And I agree that it should go away, but can't easily just yet.)


Is there some way to query what character set a locale uses?  If not, I 
think that man-db should default to UTF-8 (since that *is* the standard 
on Debian) and handle exceptions to that.  Processing an ASCII manpage 
as UTF-8 is a no-op.  And it's pretty easy to tell if something isn't 
valid UTF-8, and man-db can handle that as it normally would.


Of course, I'm not contributing code, so my opinion is worth what you 
paid for it.



Too bad, groff doesn't have real Unicode support, and supports only several
special-cased locales (which may then be transcoded as UTF-8, but they still
get wrapped into their old-style charsets).


AIUI, PostScript doesn't have UTF-8 support either, yet it seems to work 
just fine.  Anyway, newer versions of groff have a conversion tool that 
maps UTF-8 (or any arbitrary character set) input into glyph names.  But 
Debian's groff has been very heavily patched with support for kinsoku 
shori (prohibition character handling) and so we cannot simply update to 
a newer version.  Believe me, if it were that easy, I'm sure Colin would 
have done it.



Are you working with Brian M. Carlson on this? He has been working on a
solution acceptable to groff upstream, which is, frankly, the only way I
want to go now. He has already made substantial progress with character
class support.


Please be aware that I have little time with school right now, so this 
may not be implemented soon.  In fact, it may not be ready in time for 
lenny's release.  I will sit down and work on it some more soon, but my 
time is limited.  If people want more information on my plan of attack, 
please do let me know, and I'll be happy to share.


In fact, I'm off to hack some more on groff right now.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: BitTorrent and ISP interference

[brian m. carlson]

[Ignoring the part of M-F-T that indicates Ben Finney, per his request.]

On Thu, Mar 20, 2008 at 11:31:22AM -0400, Clint Adams wrote:

On Thu, Mar 20, 2008 at 08:50:11AM +1100, Ben Finney wrote:

William, please follow the Debian mailing list code of conduct
http://www.debian.org/MailingLists/#codeofconduct>; specifically,
don't send me individual messages that are also sent to the list,
since I didn't ask for them.


How many times do people have to cite this stupid thing before someone
removes it from the website?


I think it's a good idea.  I'm not a DD, but I don't appreciate getting 
dupe messages from the list.  procmail is not set up to handle them, and 
I read the vast majority of the lists I post to.  I only wish non-Debian 
lists had the same policy.


Ignoring that particular provision, it contains useful tips such as
only post in English (on non-localized lists), use the proper list, and 
don't send HTML email.  These are all things I think we should encourage 
on Debian lists, and on lists in general.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: What CDs and DVDs should we produce for lenny?

[brian m. carlson]

On Sun, Mar 23, 2008 at 02:16:05AM +0100, Peter 'p2' De Schrijver wrote:

Considering that modern machines can boot from network or USB stick,
some machine classes lack optical drives (small laptops, many non
ia32/amd64/ppc machines), DVD readers are uncommon outside the
ia32/amd64/ppc world, optical media are slow compared to network or USB
sticks, I would say the importance of optical media images is low. It's
cool to have CDs or DVDs to give away at fairs etc, but for practical
use much better installation methods (network and USB stick) are available IMO. 
AIUI, USB sticks use the standard business card or netinst images, or a 
special pre-built image.  So creating those for all architectures that 
can boot from USB is obviously important, especially for those people 
that don't want to destroy all the data on their USB sticks.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [RFH] Loki bug #409370: missing 64-bit executablex

[brian m. carlson]

On Mon, Mar 24, 2008 at 06:05:20PM +0100, Andreas Tille wrote:

Hi,

is anybody able to solve this problem that seems to occure only on 64bit
archs.  I compared the build logs and found:


make[2]: Entering directory `/build/buildd/loki-2.4.7.4/lokisrc'
cc -g -Wall -O2 -W -Wall -pedantic -ffloat-store -Wno-long-long -I../include
 -c -o param_parse.o param_parse.c
cc -c -g -Wall -O2 -W -Wall -pedantic -ffloat-store -Wno-long-long -I../include 
  -DYY_NO_UNPUT param_lex.c
In file included from /usr/include/sys/stat.h:107,
 from param_lex.l:25:
/usr/include/bits/stat.h:65: error: expected identifier or '(' before '[' token
make[2]: *** [param_lex.o] Error 1
make[2]: Leaving directory `/build/buildd/loki-2.4.7.4/lokisrc'


Here's the difference: in , the following occurs:

#if __WORDSIZE == 64
long int __unused[3];
#else
# ifndef __USE_FILE_OFFSET64
unsigned long int __unused4;
unsigned long int __unused5;
# else
__ino64_t st_ino;   /* File serial number.  */
# endif
#endif

So on 64-bit platforms, a field called __unused is defined.  But in 
param_lex.c, the following code exists:


#if defined(__FreeBSD__)
#include 
#else
#define __unused
#endif

So that code in  comes out to:
  long int [3];
which isn't valid.  The solution is not to define things that aren't in 
your namespace, so flex shouldn't #define __unused, or use it, for that 
matter.


HTH.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [RFH] Loki bug #409370: missing 64-bit executablex

[brian m. carlson]

On Tue, Mar 25, 2008 at 11:59:53AM +0100, Andreas Tille wrote:

Well, the file param_lex.c was autogenerated in the first place


Right.


$ grep -A2 -B2 __unused *
param_lex.c-#include 
param_lex.c-#else
param_lex.c:#define __unused
param_lex.c-#endif
param_lex.c-


I believe that  on FreeBSD defines __unused to 
__attribute__(unused), or something similar.  This was probably 
generated by a patched flex for FreeBSD.  freebsd-lex might generate the 
same output, I don't know.



So while I probably might be able to patch this via

  s/__unused/__unused_by_other_systems_but__FREEBSD__/

this might break on som Debian/FREEBSD port and it would be better to
fix the according flex input.


Debian GNU/kFreeBSD uses __FreeBSD_kernel__, not __FreeBSD__, so it 
shouldn't affect anything as far as Debian goes.  I don't know what 
Debian GNU/kFreeBSD includes in ; perhaps one of the 
porters could tell you.



I also wonder whether there is some hidden quirk in flex.  It might be that
this only happens in old versions of flex and I have to admit that I have
no idea at all about flex and what I would have to do to.


If you apply the attached patch, and regenerate the C file using flex, 
the program should compile properly.  At least on my amd64 system, the 
executable is built.


HTH.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
--- param_lex.l.old	2008-03-25 13:46:59.0 +
+++ param_lex.l	2008-03-25 13:47:19.0 +
@@ -127,7 +127,7 @@
 
 void yy_cleanup(void)
 {
-	yy_delete_buffer(yy_current_buffer);
+	yy_delete_buffer(YY_CURRENT_BUFFER);
 }
 
 #ifdef FUNC_NAME


signature.asc
Description: Digital signature

Re: Default value for CFLAGS/LDFLAGS set by dpkg

[brian m. carlson]

On Mon, Mar 31, 2008 at 06:57:48PM +0200, Kurt Roeckx wrote:

On Mon, Mar 31, 2008 at 05:34:05PM +0200, Loïc Minier wrote:

 I just wondered: is it possible to reverse/disable the effects of
 -Bsymbolic-functions if LD_PRELOAD is set?  Or is it too late already
 and some information was definitely lost?


If it does the same thing as -Bsymbolic, but only for functions, it
resolved all the relocations already and can only call functions
internally in the library.


According to ld(1):

  -Bsymbolic-functions
	  When creating a shared library, bind references to global function 
	  symbols to the definition within the shared library, if any.
	  This option is only meaningful on ELF platforms which support 
	  shared libraries.



I also have to wonder that if we have something like this as default,
why -Bsymbolic-functions would be a good default, and not -Bsymbolic.


This is not a sensible default for libc6, libstdc++6, or the standard 
library for any other programming language.  libc6 is overridden by all 
means of LD_PRELOAD functions.  Examples I can think of off the top of 
my head are zzuf, electric-fence, valgrind, and fakeroot.  People like 
to override the standard libraries to provide useful functionality, and 
we shouldn't break this.  Also note that there are symbols that are 
present in both libc.so.6 and libpthread.so.0, and that using 
-Bsymbolic-functions would probably break libc thread safety.


IANADD.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Default value for CFLAGS/LDFLAGS set by dpkg

[brian m. carlson]

On Mon, Mar 31, 2008 at 10:51:00PM +0200, Mike Hommey wrote:

According to ld(1):

  -Bsymbolic-functions
	  When creating a shared library, bind references to global function 	  
symbols to the definition within the shared library, if any.
	  This option is only meaningful on ELF platforms which support 	  
shared libraries.


A little bit OT, but does this have the same result as what is done
here[1] ?


No, this renames the symbol and sets the visibility to hidden.  nm would 
mark this symbol with a "t" instead of a "T".  This prevents external 
users from linking against this symbol, since it is not globally 
visible.  In other words, this is much like the "static" specifier, but 
specific to the entire library, instead of just to that object file.


LD_PRELOAD would still be able to override it, because by default, ELF 
shared libraries use relocations that must be serviced by ld.so.  
However, if -Bsymbolic-functions were used, those functions would 
already be relocated, speeding up link time, but preventing LD_PRELOAD 
from working, since no relocation ever occurs for that symbol.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Should -dev packages providing .pc files depend on pkg-config?

[brian m. carlson]

On Sat, Apr 05, 2008 at 04:52:29PM +0200, Tollef Fog Heen wrote:

That depends on the library you are linking against.  I, as an library
author is free to say «the only supported way to use my gargleblaster
library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which
then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
using pkg-config).  If I do that, pkg-config is effectively part of
the API.


If the only supported way to link against your library is to use the 
autotools, you should be shot, especially if libtool is anywhere in the 
equation.  Not everybody uses the autotools, and their only benefit is 
portability.


Secondly, Debian is not necessarily in the business of doing everything 
upstream authors want.  I remember Mozilla was quite upset when we 
started shipping shared libraries of their components (XUL, NSS, etc.), 
because their way was to statically link a stub and then dlopen the 
modules.  Debian decided that was not the way that best served our 
users, and proceeded to ignore their recommendation[0].


I think it is safe to say that Debian supports passing the appropriate 
command line arguments without using pkg-config, even if upstream does 
not.  At least that seems to be my experience.


[0] Google for "Mozilla Debian shared library"

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#476340: ITP: datapacker -- Tool to pack files into minimum number of CDs/DVDs/etc

[brian m. carlson]

On Tue, Apr 15, 2008 at 10:50:23PM -0500, John Goerzen wrote:

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: datapacker
 Version : 1.0.0
 Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://software.complete.org/datapacker
* License : GPL
 Programming Lang: Haskell
 Description : Tool to pack files into minimum number of CDs/DVDs/etc
datapacker is a tool to group files by size. It is
designed to group files such that they fill fixed-size containers
(called "bins") using the minimum number of containers.


This sounds suspiciously like the knapsack problem, which is in NP.  Is 
it guaranteed to use the minimum number, or are there cases when it 
would not?  If the former, I'm sure Merkle and Hellman would like to 
hear from you. ;-)


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo

[brian m. carlson]

On Fri, Apr 25, 2008 at 08:12:58AM +0200, Cyril Brulebois wrote:

Hi,

I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is
(well-)known, and whether its content got reviewed, esp. by porters of
each architecture, who could fix obvious errors or typos, or eventually
add special-cases, exceptions, and the like.

1. http://wiki.debian.org/ArchitectureSpecificsMemo


One other thing that might be useful is alignment for each of 1, 2, 4,
and 8 byte quantities, and the signal used for unaligned accesses.  This
would be useful because it would allow developers to immediately
determine (e.g) what a SIGBUS on sparc means.  Obviously, if a machine
doesn't prohibit unaligned accesses (like the i386) then that field
would be left blank.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[brian m. carlson]

On Mon, Apr 28, 2008 at 12:51:48AM +0200, Thomas Viehmann wrote:

Colin Watson wrote:

I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?


I must say that the thread did not do much to convince me.[1]


The only benefit that this has is to prevent programs from spying on
other programs run by the same user.  I don't know about you, but I
don't run arbitrary programs on my system, so if there is any process
spying on my ssh-agent, then either:

1) it came from Debian, in which case I suggest we handle that program
like micq (which had a malicious upstream); or
2) I wrote it myself, in which case I obviously designed it to do
exactly that.

So basically, the only interesting case is that Debian is shipping some
program that surreptitiously spies on other programs.  Is that the case?

I don't see how we gain any benefit by disabling ptrace.  All it
prevents me from doing is snooping on my own programs, which I might
want to do for any number of reasons (strace comes to mind).

IANADD.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#478518: ITP: librelative-perl -- Load modules with relative names

[brian m. carlson]

On Tue, Apr 29, 2008 at 04:20:42PM +0200, Edi STOJICEVIC wrote:

Package: wnpp
Severity: wishlist
Owner: Edi STOJICEVIC <[EMAIL PROTECTED]>


* Package name: librelative-perl 
 Version : x.y.z


You might want to fill this in.


 Upstream Author : Sébastien Aperghis-Tramoni
* URL : http://search.cpan.org/~saper/relative-0.04/lib/relative.pm
* License : GPL (same terms as perl itself)


Is it GPL, or GPL | Artistic?  The latter is the same terms as Perl
itself.


 Programming Lang: Perl
 Description : Load modules with relative names


A long description would be useful as well.  I think I have a good idea
what this package does, but if there are any things I should know before
installing it, this would be a good place to put them.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Manpages for binaries not in $PATH

[brian m. carlson]

On Sat, May 10, 2008 at 07:18:39PM +0200, David Paleino wrote:

This suggests that it should have a manpage. But, it's a *should*. On the other
hand, I know that many "entities" which are not in $PATH have their own manpage
-- see for example Perl modules.

How should I behave here?


I think the obvious answer makes your question moot: combine the two
into one binary and benchmark to decide what to do, as suggested in
251259.

If you're not willing to do that, then the prudent decision is to decide
whether the user ever needs to run the program manually.  In the case of
cpp-4.3, you never need to run cc1 (since it is an implementation
detail), so it does not require a manpage.  It seems that in the case of
john, the main executable cannot figure out which implementation is
better, so the user may need to run the program manually.  Thus it needs
a manpage.

IANADD.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Thu, May 15, 2008 at 08:09:12AM +1000, Ben Finney wrote:

Roland Mas <[EMAIL PROTECTED]> writes:


- Keys submitted through the web interface are now filtered, and only
  RSA keys end up in your authorized_keys file.  Don't even try
  putting DSA keys in your authorized_keys2 file, the use of that file
  has been disabled (and it'll be deleted anyway).


Could you explain the rationale for this? My impression was that DSA
was recommended over RSA.


It used to be that RSA was patented in the United States, and so only
DSA, DH, or ElGamal algorithms were appropriate for use in main.

Another reason DSA may be preferred is that it produces smaller
signatures than RSA.  The reason DSA is preferred over RSA for GnuPG
keys is because (AIUI) the keyring maintainers no longer accept v3 keys,
but only v4, which for a while meant that DSA was the only option.
(GnuPG now generates v4 RSA keys as well.)

Still another reason DSA may be preferred over RSA is that it is
conjectured that solving the hard problem underlying DSA (the
Diffie-Hellman Problem) is as difficult as computing discrete logarithms
(the Discrete Logarithm Problem), while the underlying hard problem for
RSA (the RSA Problem) is conjectured to be as difficult as the Factoring
Problem.  If one can solve the Discrete Logarithm Problem, then one can
factor, but the reverse is not true.  Thus, it is conjectured that DSA
is based on a harder problem than RSA.

There are reasons not to prefer DSA.  It has a short key size, usually
limited to 1024 bits, which is not enough for continued security.
Because all signatures are made in the field of q, a 160-bit prime, thus
making them no longer than 160 bits, brute-forcing the algorithm is
easier than with RSA.  Also, DSA absolutely requires a good random
number generator for every signature.  If the nonce is not chosen
randomly, it will leak bits of the key.  This is true for all discrete
logarithm algorithms.  Therefore, anyone who had a DSA key has had it
compromised, and RSA is just as good a choice for a new key.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Wed, May 14, 2008 at 11:12:26PM +, brian m. carlson wrote:

Also, DSA absolutely requires a good random
number generator for every signature.  If the nonce is not chosen
randomly, it will leak bits of the key.  This is true for all discrete
logarithm algorithms.  Therefore, anyone who had a DSA key has had it
compromised, and RSA is just as good a choice for a new key.


I apologize.  Using the same nonce more than once or revealing the nonce
does not leak bits of the key; it immediately and trivially reveals the
private key.  See Applied Cryptography, page 492.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Thu, May 15, 2008 at 02:00:25AM +0200, Steinar H. Gunderson wrote:

On Wed, May 14, 2008 at 11:12:26PM +, brian m. carlson wrote:

If one can solve the Discrete Logarithm Problem, then one can
factor, but the reverse is not true.


This is the first time I've ever heard anyone claim this; I've seen people
and textbooks claim they're roughly equivalent, but not that this is a
one-way street. Do you have any references?


I read it somewhere, probably on a PGP forum, but apparently that was
incorrect.  According to http://portal.acm.org/citation.cfm?id=894497 :

  To summarize: solving the discrete logarithm problem for a composite
  modulus is exactly as hard as factoring and solving it modulo primes.

I stand corrected.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[brian m. carlson]

On Fri, May 16, 2008 at 05:26:09PM +0200, nicolas vigier wrote:

If I understand correctly, it means that if you use a good key with a
flawed openssl to connect to an other host using that key, then that
key can be considered compromised.


If I have a DSA key, and the client (my machine) has a bad OpenSSL, then
I have exposed my secret key.  This is because I generate the random
data on the client.


But what about using a good key on a host with a good openssl, to
connect to a server which use a bad openssl ?


Since the random data is generated on the client, I have not exposed my
key.  However, if Diffie-Hellman key exchange is used, the session key
is probably insecure, and thus it is easy to sniff the messages.

Note that this only applies to DSA.  RSA keys only use random data to
pad the signature (such as in PKCS #1), and so it is much less likely
that you have exposed the secret key.  (For the unlikely situation that
you have, see "Low Encryption Exponent Attack against RSA", Applied
Cryptography, p.472).

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: possible mass-bug filing on fc-cache-using packages

[brian m. carlson]

On Tue, May 20, 2008 at 12:05:46PM +0100, martin f krafft wrote:

Hi folks,

I noticed the other day that there are quite a few packages like
ttf-bitstream-vera which do the following in
/var/lib/dpkg/info/ttf-bitstream-vera.postinst:

 if [ "$1" = configure -a -x /usr/bin/fc-cache ]
 then
   echo -n "Regenerating fonts cache... "
   HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1 || \
   (echo "failed; see /var/log/fontconfig.log for more information."; \
   exit 1)
   echo "done."
 fi

This is wrong. Using ()'s creates a subshell, and exit then only
exits the subshell, not the postinst (which I believe it's supposed
to do). The code either needs an "|| exit $?" appended, or {}'s
should be used. Compare


I could be wrong, but if the subshell exits 1, then the entire
expression is false, and so if you are using "set -e" like you're
supposed to, then the postinst fails.

For example, at the prompt, try:
  (set -e; echo 1; false || (echo error; exit 1); echo 2)
which will never print "2".

ttf-bitstream-vera isn't using set -e, which is probably a bug.  ISTR
that policy dictated set -e.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: A dream of the Debian-logo

[brian m. carlson]

On Sun, Jun 08, 2008 at 08:18:18PM +0200, Adeodato Simó wrote:

This picture is a dream of the Debian-logo in the future...


For the record, while I don't dislike the "e = modern swirl" idea, the
font (typeface?) of the rest of the letters is just awful for a logo
(because it's one of the common ones whose name I don't know).


It looks to me like Helvetica[0], which is one of the 14 standard
PostScript fonts.

[0] Or Nimbus Sans L, which is basically the same thing.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

[brian m. carlson]

On Fri, Jun 13, 2008 at 03:07:02PM +0200, Bernhard R. Link wrote:

* Steve Greenland <[EMAIL PROTECTED]> [080612 19:01]:

Isn't the whole point of having cups-bsd etc. to provide replacement
commands that are compatible with older tools?


Well, from my view lpr, lprm, lpc, lpq are the new tools while lp,
cancel, lpstat are the compatibility links for tools coming from sysv.


My experience over eight years of using GNU/Linux distributions is that
programs that don't have native support for a printing implementation
tend to use lpr and friends (the BSD tools) rather than the SysV tools.
I recall seeing lpr as a printing command numerous times, and lp only
once[0].  It appears that at least in GNU/Linux history, the BSD tools
are more prevalent.

Of course, many programs nowadays support CUPS natively through their
desktop environments, so this becomes almost moot.

[0] My first thought on seeing lp was that someone had made a typo.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]

[brian m. carlson]

On Tue, Jun 17, 2008 at 10:12:52AM +0100, Klaus Ethgen wrote:

Am Mo den 16. Jun 2008 um  6:25 schrieb Martin Pitt:

very poor code quality


That might be. But that's a problem of many gnome applications.


To be quite honest, I've seen the code for esd, and it is terrible.
In fact, worse than all the GNOME applications whose code I've ever
seen.

The thing that really stuck out for me was the large number of global
variables in esd.  It's lack of modularity didn't exactly excite me,
either.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Considerations for lilo removal

[brian m. carlson]

On Wed, Jun 18, 2008 at 07:20:36PM +0200, Wouter Verhelst wrote:

grub doesn't work with root-on-LVM, or other similar cryptic
installations. There, your only option is lilo.


Actually, that's not true.  I use root-on-LVM with a /boot partition and
grub 2 (and previously, grub 0.9x).  It is my understanding that if you
don't have a /boot partition, you do need lilo, however.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[brian m. carlson]

On Mon, Jun 23, 2008 at 06:05:28PM +0200, Robert Millan wrote:

On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote:


Certainly, the backports.org keyring is useful to some people, *but* it is,

  1. not free software


I don't think there's a legal basis to claim copyright on a blob of random
bytes generated by a program.  Who's the copyright holder?  gpg?  The authors
of gpg?  The person who typed gpg in command-line?  The entropy source?


Copyright (in the United States) requires an original creation.
Generating several prime numbers for a purely functional purpose is not
at all original and hence not copyrightable.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: bashism question

[brian m. carlson]

On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote:

With our move to dash as sh we have to remove all bashisms from scripts
run by /bin/sh. However, checkbashism seems to moan about clauses that
work in dash as well. I don't know in which shells a trap with a signal number
is guaranteed to work, but it seems to work well in dash. 


As far as I'm aware, there are three shells in Debian that can be used
as /bin/sh: bash, dash, and posh[0].  bash is, in general, the most
featureful of these.  Just because something works in one does not mean
that it works in all of them.  Notably, posh implements the most minimal
set of features, and last time I checked, my system failed to boot
because scripts were using features not mandated by policy.

So, if you're going to fix bugs due to bashisms, please fix them all.
They are all policy violations, and there's no reason to fix only some
bugs.

As for the signal numbers, different architectures have different signal
numbers.  See signal(7), but the most common ones *are* identical.
However, signals such as SIGUSR1 and SIGUSR2 are not, and using a number
for these will break on at least alpha, mips, mipsel, and sparc[1].  Using
names is not only more portable, it is more explicit.  Everyone knows
what SIGABRT does, but not everyone knows what signal 4 does.  Think of
using signal numbers as using magic numbers: it's a bad programming
practice.

Also, as GNU/kFreeBSD becomes more usable, it will be important to have
shell scripts work across kernels.  The FreeBSD kernel does not match
any Linux architecture in its assignment of signal numbers, so fixing
these now is a good idea.

[0] It would be nice if zsh were added to this list, but I'm not holding
my breath.
[1] Assuming, of course, that most people use i386 or amd64 as their
main platform, and program accordingly.  Judging by the number of FTBFS
bugs on sparc due to alignment problems, this is a safe assumption.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: RFC: Idea for improved diversions and alternatives handling

[brian m. carlson]

On Fri, Jun 27, 2008 at 12:58:14PM -0400, James Vega wrote:

On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:

What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?


Several packages shouldn't divert the same file, IMO.  diversions
are useful for specific circumstances and the diverted/diverting
packages should be closely related (if not from the source).
Alternatives are the better solution when there are myriad,
non-conflicting sources which may provide the same file.


You still have to handle multiple diversions for /bin/sh.  When d-i
installs the system, you have to have a working /bin/sh immediately; you
can't wait for the alternatives mechanism to be set up.  And the only
other option I see (other than diversions) is to prohibit changing
/bin/sh, which will make a lot of people very upset.

I agree that alternatives are the optimal tool here, but I don't know
how that can be achieved.  Suggestions welcome.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: RFC: Idea for improved diversions and alternatives handling

[brian m. carlson]

On Fri, Jun 27, 2008 at 07:56:41PM +0100, Ian Jackson wrote:

brian m. carlson writes ("Re: RFC: Idea for improved diversions and alternatives 
handling"):

You still have to handle multiple diversions for /bin/sh.  When d-i
installs the system, you have to have a working /bin/sh immediately; you
can't wait for the alternatives mechanism to be set up.  And the only
other option I see (other than diversions) is to prohibit changing
/bin/sh, which will make a lot of people very upset.

I agree that alternatives are the optimal tool here, but I don't know
how that can be achieved.  Suggestions welcome.


So you're saying this situation calls for diverting a file to make way
for an alternative.  This seems like it will involve the diversions
and alternatives mechanisms fighting each other.  It'll have a great
many moving parts and probably be buggy.


No.  I said that I'd prefer /bin/sh to be managed by alternatives.  I
also said that /bin/sh is essential, even at the very beginning of
installation.  I also demonstrated a case where diversions may have to
be used, even though they're (IMHO) a poor choice, unless some brilliant
person figures out how to make alternatives work.

I did not suggest diverting a file to make way for an alternative.  I
agree that down that path, madness lies.


This scenario leads me to suggest that perhaps the right answer is to
unify diversions and alternatives.  If we can come up with a single
mostly-dpkg-implemented feature to do both then we at least have some
chance to get it right.  (It might also help with some of the
transition problems I mentioned earlier.)


I'm certainly interested in hearing more.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#535143: ITP: gnome-do-docklets -- Dock applets for GNOME Do's "Docky" interface.

[brian m. carlson]

On Tue, Jun 30, 2009 at 02:37:51PM +1000, Christopher James Halse Rogers wrote:
> * Package name: gnome-do-docklets
>   Version : 0.8.2
>   Upstream Author : Jason Smith 
> * URL : http://do.davebsd.org/

This should be <http://do.davebsd.com/>.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: CDPATH and shell scripts

[brian m. carlson]

On Fri, Jul 03, 2009 at 01:01:41AM +0200, Goswin von Brederlow wrote:
> As a middle ground I wouldn't mind $SHELL to unset CDPATH when it
> switches from an interactive shell to a non-interactive shell, when a
> script with #! $SHELL is executed. That one is just to damn scary.

I don't think that's permitted by SUSv3, and Policy says:

  Scripts may assume that /bin/sh implements the SUSv3 Shell Command
  Language

> Also why does it output to stdout and not stderr?

According to SUSv3 (and SUSv4) for the cd utility:

  If a non-empty directory name from CDPATH is used, or if cd - is used,
  an absolute pathname of the new working directory shall be written to
  the standard output as follows:
  
  "%s\n", 

The rationale states that CDPATH was taken from the SysV shell, and it
probably had that behavior.

If you're going to write a /bin/sh script, you need to be aware of the
environment and how it's going to affect your script.  For example, if
you don't want utilities (such as patch) to have POSIX behavior, you
need to unset POSIXLY_CORRECT and _POSIX2_VERSION.  If you don't want
cd to use CDPATH, you need to unset it.  You can probably do something
like

  unset `set | sed -re 's/^([^=]+)=.*$/\1/g' | grep -E '^[A-Za-z0-9]' | grep 
-vE '^(PS|PATH|TERM)'` 2>/dev/null

to get a "clean" environment.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[brian m. carlson]

On Fri, Jul 24, 2009 at 12:58:20AM +0200, Raphael Hertzog wrote:
> On Tue, 30 Jun 2009, Andrei Popescu wrote:
> > On Mon,29.Jun.09, 22:53:53, Raphael Hertzog wrote:
> > > @@ -63,6 +63,10 @@ The set of fields ends on the first empty line. 
> > > Free-form comments follow and be used for any other information that 
> >   ^^
> > I'm not a native speaker, but this doesn't sound very well.
> 
> There's an implicit "can".
> 
> “Free-form comments can follow and [can] be used for”

If you had said "Free-form comments can follow", then that would be
correct.  As a native speaker of en_US, I would say that "Free-form
comments follow and may be used..." sounds best.  "May" is better than
"can" here because there is no doubt about your ability: you *can* write
anything you want, but whether it is permitted or not is another matter.

The implicit direct object of "follow" is "this line".

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Switching /bin/sh to dash without dash essential

[brian m. carlson]

On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote:
> zsh has also historically been fairly buggy in corner cases as /bin/sh and
> requires explicit commands to make it Bourne-compatible.  Autoconf has had
> to add a bunch of workarounds for zsh as sh that I'm sure most of our
> shell scripts don't have.

Actually, if it's invoked as /bin/sh, it is supposed to be
Bourne-compatible.  That's my experience with the current version:

  lakeview ok % emulate; /bin/sh -c emulate
  zsh
  sh

I don't know what other versions do.  I'm working on finding bugs with
zsh as /bin/sh; see #510358.  If anyone knows about a good /bin/sh
(POSIX, XSI, or Debian) testsuite, please let me know off-list.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.

[brian m. carlson]

On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote:
> * Package name: mercury
>   Version : 0.13.1-rotd20090725
>   Upstream Author : Mercury Group 
> * URL : http://www.mercury.csse.unimelb.edu.au/
> * License : GPL2
>   Programming Lang: Mercury
>   Description : The Mercury programming system, a pure logical/functional 
> programming language.

This used to be in Debian some time ago, because I remember trying to
work on the package for some reason.  I believe that it is
self-hosting[0], which may be a problem, except that it supposedly comes
with a C version of the compiler as well.  To make life easy for porters,
I'd request that you always build the C compiler and then, if you want
to, bootstrap the Mercury compiler from that.

If I'm remembering incorrectly, or that's no longer the case, feel free
to disregard this.

[0] That is, the compiler is written in Mercury.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: new package format

[brian m. carlson]

On Fri, Jul 31, 2009 at 03:32:43PM +0300, Eugene Gorodinsky wrote:

> On windows a program may contain some optional components, which you
> can choose at install time. This approach (I mean having some main
> package and some required and some optional subpackages inside it) is
> quite user-friendly. Neither dpkg nor apt have this functionality in
> them, and I do not think it's possible to implement it without
> changing the package format.

We do this by having multiple packages.  For example, OpenOffice has
different components: not only are there the different programs (writer,
math, etc.) but there are different language packs.  These are optional
components; for example, since I do not speak Danish, I would not want
to install the Danish language pack.  It would be useless to me.

I agree that this functionality is not built into one single package,
but I think that Debian's way is superior, since it means that I needn't
download data that I don't need, and it is extremely easy to determine
what components I have installed.  It also makes it easy to reuse those
same components in other, unrelated packages.  If groff can make use of
LaTeX hyphenation patterns, then groff can declare a recommends on those
packages without having to necessarily install LaTeX.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Spam on the lists [Was: Re: Account Upgrade (Unex)]

[brian m. carlson]

On Sat, Aug 01, 2009 at 02:24:28AM +0300, Eugene Gorodinsky wrote:
> Is there any way to actually make it harder to spam the list? I just
> subscribed and already see spam and phishing attacks...

Yes.  There are infinitely many ways to make it harder to spam the list,
among them:

* Allowing posting only by subscribers.
* Requiring a signed agreement and a surety bond before allowing posting
  to the list.
* Only allowing people to post to the list if they have an armed guard
  standing beside them who shoots spammers on sight.
* Not allowing posting to the list.

Unfortunately, all the ways that have yet been proposed and not
implemented have been rejected by the listmasters because all of them
involve tradeoffs that are unacceptable to the listmasters or the Debian
community.  If you think you have a better one that has not yet been
discussed, feel free to file a bug on the lists.debian.org
pseudo-package.

While you're at it, please don't reply to spam, and if you must reply to
it, please don't quote it.  We don't want to see it (again) and you make
it harder for those of us who use statistics-based spam filters.

HTH.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: default character encoding for everything in debian

[brian m. carlson]

On Mon, Aug 10, 2009 at 09:42:18PM +0100, Roger Leigh wrote:
> On Mon, Aug 10, 2009 at 09:49:34PM +0200, Norbert Preining wrote:
> > I didn't call utf-8 itself rubbish, I am myself a strong proponent for
> > utf-8, only your quote that it is "about as compact as an extended encoding
> > is going to get".
> 
> I should have qualified it with "that is both 8-bit and backward-
> compatible with ASCII".  Other encodings will be more compact, but
> AFAIK there isn't a more compact UCS encoding, though UTF-16 /might/
> be more compact for certain languages, albeit without any 8-bit
> backward compatibility.

Actually, SCSU and BOCU-1 are potentially more compact, assuming the
text can be compressed.  However, they are not backward-compatible with
ASCII; SCSU comes closer than BOCU-1.  As a practical matter, nobody of
any importance actually uses SCSU or BOCU-1, except for Reuters (with
SCSU).

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: ITP: libjs-extjs -- a cross-browser JavaScript library

[brian m. carlson]

On Wed, Oct 07, 2009 at 04:13:59PM +0200, Mike Hommey wrote:
> Except the issue is not about dual licensing, but about intent being
> different to what the license actually says. i.e. The GPL3 the code is
> supposed to be released under doesn't have these obligations, and
> anybody not contributing back or taking commercial advantage in a closed
> source solution is in its total rights under the GPL3 license.

Except that the GPLv3 explicitly covers this case (from §7):

All other non-permissive additional terms are considered "further
  restrictions" within the meaning of section 10.  If the Program as you
  received it, or any part of it, contains a notice stating that it is
  governed by this License along with a term that is a further
  restriction, you may remove that term.  If a license document contains
  a further restriction but permits relicensing or conveying under this
  License, you may add to a covered work material governed by the terms
  of that license document, provided that the further restriction does
  not survive such relicensing or conveying.
  
If you add terms to a covered work in accord with this section, you
  must place, in the relevant source files, a statement of the
  additional terms that apply to those files, or a notice indicating
  where to find the applicable terms.

If the relevant source files do not have these terms, then they do not
apply.  If they are present, then we can remove them, because the GPLv3
says we can.  Either way, it should be fine.  This is a distinct
difference between the GPLv2 and the GPLv3.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Is it time to remove sun-java6?

[brian m. carlson]

reassign 541100 icedtea6-plugin
kthxbye

On Thu, Oct 08, 2009 at 07:39:33PM +0200, Stefano Zacchiroli wrote:
> On Thu, Oct 08, 2009 at 11:44:21AM -0400, Barry deFreese wrote:
> > There has also been some similar discussions in Ubuntu with some
> > users reporting that some web sites and packages don't work with
> > openjdk but I have not seen a lot of concrete proof.
> 
> I might look a naive user here, but with openjdk I still don't have
> plugin support in firefox 3.5, whereas it was working with
> sun-java*. I'm on amd64 and using icedtea6-plugin, even the most simple
> examples of http://java.sun.com/products/plugin/1.5.0/demos/applets.html
> do not appear to work.

This is a bug, and it has already been filed.  The maintainer has fixed
it in the Ubuntu version, and therefore it should be fixed in Debian
shortly.  If the bug still isn't fixed by the time Iceweasel 3.5 hits
unstable, I'll upgrade it to grave.

> I know I should have filled the bug report first, but I frankly
> discovered only now that the equivalent of old sun-java6-plugin
> metapackage is icedtea and that's bring me to another subject: users
> should be informed on how to migrate away from sun java6 (even because
> it would be a de facto switch from non-free software to free software,
> even if it is the same).  Do we currently have a smooth migration path
> from the old set of packages to the new set in place for Lenny to
> Squeeze migrations?

Uh, icedtea6-plugin is present and installable; that would be the
replacement for sun-java6-plugin.  It doesn't work in non-Gecko
browsers, but I don't think sun-java6-plugin did either.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#551210: ITP: blame -- display the last modification for each line in an RCS file

[brian m. carlson]

On Fri, Oct 16, 2009 at 05:44:19PM +0200, Mike Hommey wrote:
> As much as I do like this software as it turned out to be useful to me
> in several cases, I'm not sure using the generic 'blame' name is a
> good idea. Probably rcs-blame (with or without dash, you choose) would
> be better IMHO.

I concur.  I'm actually working on a project right now (called "blame")
that does something completely different: aggregate sources of spam and
other network attacks (such as SSH bruteforcing) and automatically
create and modify configuration files to block them.

Probably a less generic name (for both this software and mine) would be
appropriate.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#551550: general: many Java packages needlessly depend on java?-runtime

[brian m. carlson]

Package: general
Severity: normal

Many Java packages work successfully with a headless JRE; that is, one
that does not support graphics.  However, some of these packages depend
on java?-runtime instead of java?-runtime-headless.  As a consequence,
graphical JREs are installed when they are not needed (such as on
servers).

Java applications and libraries that correctly function with a headless
JRE should depend only on such a JRE, possibly with a recommends or
suggests on a graphical JRE if the program can benefit from it.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#545691: diverting telinit

[brian m. carlson]

On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>  if [ -x /sbin/init ] && [ -d /proc/1 ] &&
>  [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
> 2>/dev/null)" ] ; then
>  # So, init exists, and there is a linuxy /proc, and the inode of
>  # the executable of the process with uid 1 is the same as
>  # /sbin/init (ok, no init=/bin/sh going on)
> 
>  if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" 
> ]; then
>  # the devicenumber/inode pair of / is the same as that of
>  # /sbin/init's root, so we're *not* in a chroot
> 
>  # Final sanity check. Make sure there is a /dev/initctl
>  # for us to talk to
>  if [ -e /dev/initctl ]; then

Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
think it's something like /etc/.initctl.  They do, however, have a
linuxy proc.  You should probably check with the porters as to what
location is appropriate on those architectures.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#545691: diverting telinit

[brian m. carlson]

On Mon, Oct 26, 2009 at 10:56:16PM -0700, Steve Langasek wrote:
> Huh, isn't that an FHS violation?  /dev/initctl isn't much better, but seems
> to be covered by "special files"; upstart doesn't use either of these
> locations, fwiw.

I think the issue came down to the fact that with kFreeBSD, /dev is a
devfs, which cannot handle FIFOs, only block and character nodes and
symlinks.  I don't even know if that's still the case; my only kFreeBSD
machine was moved back to Linux due to some problems with the earlier
versions of kFreeBSD, like bind9 not working.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Iceweasel and Firefox compatibility

[brian m. carlson]

On Mon, Nov 09, 2009 at 07:25:40PM +0100, Obey Arthur Liu wrote:
> As someone pointed out in the thread, Mozilla doesn't even allow its trunk
> and alpha versions of Firefox to use the Firefox brand, whether in
> application name, installation directory (for the Windows version) or user
> agent. Third party builds (even if they just add a compiler flag) of final
> releases aren't allowed to use the Firefox brand either.
> I think we're just as not allowed to distribute versions of Firefox that use
> the Firefox user agent as we're not allowed to distribute versions that use
> the Firefox name and logo.

I don't think this is a problem.  Internet Explorer has been claiming to
be Mozilla (as has every Webkit-based browser) for years.  Webkit also
uses Gecko in its user-agent header.  Opera claims to be MSIE.  If we
put something like "(Firefox/3.5.5; compatible)", then this would not be
an issue, since we're not claiming to be Firefox, we're just claiming to
be compatible with it (which we are).  As for the trademark issue,
"Mozilla" is certainly a trademark, and I haven't seen a complaint about
that.

The breakage for Webkit-based browsers is significantly less, since they
all identify themselves as Safari; if a site supports Safari, then it
generally works with all Webkit-based browsers.

I completely agree that sites which use the User-Agent header for
anything other than logging are completely broken, but this issue does
exist and it's difficult to explain to every webmaster that they should
code for standards.

> As also explained, user agent switcher fixes the issue trivially.
>
> And you may want to add Google Wave to the list of webapps which complain
> about the Iceweasel user agent :)

Using the Bing (that is, MS) maps doesn't work either.  Normally I would
use Google Maps, but when my bank's locations tool makes a different
choice, I'm pretty much obligated to accept it.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

[brian m. carlson]

On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote:
> On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote:
> > 2.1 This clause restricts how you can modify the software.  
> > Doing a simple modification to a AGPL-covered software might require 
> > you to
> > write a substantial amount of extra code to comply with this clause.
> 
> How is this any different from the requirement in the regular GPL to
> provide source at no cost? Often this is done through website, too.

If I use a server licensed under the GPL with manual modifications, but
do not further distribute that server, I am not obligated to release the
source.  With the AGPL, I am required to do exactly that.

> This clause applies to service providers who provide a service based
> upon a slightly modified piece of AGPL software. The requirement to
> distribute the modifications only applies to your service:
> 
> "if you modify the program, your modified version must [...] offer [...]
> an opportunity to receive the Corresponding Source of your version"

This obligation does affect the DD who modified the software, but not
Debian users, assuming they do not modify the source.  Honestly, I'm not
sure if it's a good idea to put additional workload on DDs.  Also, this
applies to any Debian user that submits a patch.  I don't know about
other Debian users, but I certainly am not going to submit a patch for
software that is AGPL'd, because it creates a lot of hassle that I just
don't want.  It creates a lot of potential issues for someone who just
wants to do some QA work.

Also, there's the meaning of "you".  Is this "you" the DD?  The
ftpmasters?  Debian?  SPI?

> >-- The code is modified to interact with the user using a network 
> > protocol
> >   that does not allow to display a prominent offer.
> 
> This is actually your best argument so far, but I don't think it's
> completely true either.
> 
> First, network protocols that "do not allow to display" anything are
> abundant, since no network protocol "displays" anything -- clients that
> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot.

This is not the language used by the AGPL.  Network protocols for which
there would be substantial difficulty in complying with this license
requirement include DICT, POP, IMAP, WHOIS, DNS, and myriad others.

For example, while IMAP could theoretically use ALERT notifications for
this purpose[0], POP has no such mechanism.  The protocol has no support
for displaying anything to the user whatsoever.  DNS is also designed to
be transparent to the user.

> If the software uses some other protocol that doesn't allow you to do
> some lay-out like HTTP does, then you simply need to make sure that
> people using your software are informed out-of-band. For instance, if
> the service you provide requires a username and password, then the
> registration email could provide the required information.

Again, this is not the language that the AGPL uses.  It requires that
"your modified version must prominently offer all users interacting with
it remotely through a computer network" the source.  Notice the text
"your modified version".  It's not acceptable to offer it out-of-band.
Also, it says "all users".  That means anyone who calls connect(2),
whether they can authenticate or not.  POP can't do that.  Neither can
DNS.  Those protocols almost never have any indication to the user that
they are working.  Most users don't even know that they're there.

This doesn't even mention the situation for HTTP, where it could be
interpreted to mean that every response requires a modification of the
data in some way so that the user can be offered the source, since the
header is not displayed to the user, let alone "prominently".

> The clause says 
> 
> "your modified version must prominently offer all users interacting with
> it [...]"
> 
> I don't think that must necessarily be interpreted into saying that it
> must be done by the software itself, rather than by anything that would
> be used in cooperation with the network server.

I don't agree.  If it said "you" and not "your modified version", then I
would agree with you, but that's not what it says.

Honestly, I don't have a strong opinion on whether this should be
considered DFSG-free or not, but I do think that it can create a lot of
practical problems that may make it infeasible to support in the
archive.  It may also deter users from sending patches to fix bugs or
add new features.

[0] Any person trying to send IMAP ALERTs to achieve compliance with the
AGPL should be shot.  Repeatedly.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#557431: general: there is no package to install all POSIX utilities at once

[brian m. carlson]

On Sun, Nov 22, 2009 at 03:41:39AM +0200, Dmitri Vorobiev wrote:
> Currently no package exists that would allow installation of all
> utilities specified by the POSIX `Shell and utilities' volume:
> 
> http://www.opengroup.org/onlinepubs/9699919799/idx/utilities.html
> 
> It is considered useful to have such a package, and one such
> package was actually created:
> 
> https://edge.launchpad.net/~codedot/+archive/ppa/+sourcepub/870564/+listing-archive-extra
> 
> This bug is to suggest inclusion of this or a similar package
> into Debian operating system.

Such a package would be of little use since by default, these utilities
are not POSIX-compliant.  For example, patch is not POSIX-compliant by
default and most patch systems rely on this non-POSIX behavior.  Debian
does not have a POSIX-compliant vi, since none of the implementations
have open mode.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Should ucf be of priority required?

[brian m. carlson]

On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
> That is okay, as long as ucf is around. But as soon as it isn't
> the purge of a package is succesful while leaving modified files around.
> So the effect is that a purge does not "remove everything".
> 
> Do we really want that? Should ucf be 'required' to avoid that?

ucf being priority required is not sufficient.  It is still possible to
remove such a package (mawk is a good example) and therefore you would
still need to execute ucf conditionally.  The only way around that is to
make ucf essential, and I don't think that's a good idea.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux

[brian m. carlson]

On Tue, Dec 08, 2009 at 08:23:15PM +, Dmitrijs Ledkovs wrote:
> * Package name: python-portio
>   Version : 0.4
>   Upstream Author : Fabrizio Pollastri 
> * URL : http://portio.inrim.it/
> * License : GPL-3+
>   Programming Lang: Python, C
>   Description : low level port I/O for Linux
> 
> Wrapper for the port I/O macros like outb, inb and other provided by the C
> library on Linux x86 platforms.

Honestly, this doesn't sound like something that should be encouraged.
inb and outb are the source of much incompatibility between
architectures, and any package depending on this one will be (likely
permanently) stuck to i386.

Is there something that you want to package that depends on this?

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Package management unsafe?

[brian m. carlson]

On Sun, Jul 13, 2008 at 02:13:08AM +0200, Franklin PIAT wrote:

If we also consider the fact that the computer local time might be wrong
(hwclock bug + a ntp man-in-the-middle...), re-signing the files doesn't
help either [in this very specific case].


I think that your average user would notice if the time were wrong.
Even if the user isn't in an environment that is time-sensitive (e.g. a
network using Kerberos), most people would wonder what happened if their
computer's time were suddenly several days off.  I think the much more
likely case is that the time is accidentally incorrect, such as when a
new machine is first installed.  That may affect the installation of ntp
itself, perhaps.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Re: Include on first iso: m-a, build essential, kernel headers

[brian m. carlson]

On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote:
I think that including headers, m-a and build essential would be a good  
move for the developers. Other distros have out-of-the-box non-free and  
proprietary apps/drivers/codecs, I would just like to see Debian offer a  
complete base on that first iso. At least offering the means to  
completely setup Debian form the get-go.


Non-free (and contrib) packages are not part of Debian and are therefore
not shipped on Debian CDs or DVDs.  I understand your frustration with
not being able to use your wireless card out of the box; I have the same
problem, since my card (iwl3945) requires non-free firmware.  However,
the Social Contract states very clearly that only Free Software can be
part of Debian.

Even if the packages you request were available on the first CD, you
still don't have the drivers that you would need to compile, since those
are in non-free or contrib and thus aren't on the CDs.  Your best
chances of getting a working system out of the box are if Free drivers
without firmware are included into the kernel.  If this is a serious
concern, I would recommend carefully selecting the hardware you buy for
optimal compatibility.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Need g++-3.4 package in lenny

[brian m. carlson]

On Mon, Aug 11, 2008 at 04:37:53AM -0700, [EMAIL PROTECTED] wrote:
Debian Lenny has gcc-3.4 in 
http://packages.debian.org/lenny/gcc-3.4  but lenny doesnt have g++-3.4. 


It's my understanding that this was intentional.  There are already
three different versions of gcc in lenny, which is a lot to maintain.

I need older gcc and g++ as I have a lot of iostream.h in my code. 


iostream.h has never been a valid C++ header.  Your code is broken and
has been since the standard became effective.


I can not use etch as NSS and NSPR it uses is very old dates back to 2005.


You may find backports.org useful, although I don't know if the things
you need are there.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages

[brian m. carlson]

On Tue, Aug 12, 2008 at 10:38:07AM +0400, Dmitry E. Oboukhov wrote:

SM> A while ago, the use of libpam-tmpdir was suggested in order to mitigate
SM> some of these attacks. It would be nice to see it in use by default, some
SM> day.

SM> Obviously there will always be some programs that don't look at the
SM> TMPDIR environment variable and directly use /tmp.
write file to /tmp/filename == write file to $TMPDIR/filename
both cases are security holes if TMPDIR=/tmp :)


The idea behind libpam-tmpdir is that it creates a subdirectory of /tmp
that is only accessible by that user, and then sets TMPDIR and other
variables to that.  Hence, it doesn't matter nearly as much if you
create a non-random filename, because nobody but you can access it.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Need g++-3.4 package in lenny

[brian m. carlson]

On Sun, Aug 17, 2008 at 05:21:43PM +0200, Florian Weimer wrote:

* brian m. carlson:

iostream.h has never been a valid C++ header.


This is wrong,  contained the standard streams in the early
90s.  Like it or not, there was C++ even before ISO C++.


Yes, this is true.  But by "valid", I meant "conforming to the
standard", as in "valid HTML".  Before ISO C++, there was no standard,
only a reference implementation.

Regardless, using the .h versions has not been correct for a decade.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)

[brian m. carlson]

On Sat, Aug 30, 2008 at 03:16:01PM +0200, Bastian Blank wrote:

On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote:

+ once we have a krb realm we could maybe also use it for other
  stuff like all those web services that require logins.  How
  good is krb support in browsers these days?


Firefox supports it in a whitelist approach. However I never tested it.


I use Kerberos authentication for my OpenID server, and it works
flawlessly with Iceweasel and mod_auth_kerb.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY

[brian m. carlson]

On Tue, Dec 09, 2008 at 11:19:42AM +0200, Damyan Ivanov wrote:

* Package name: libio-pager-perl
 Version : 0.05
 Upstream Author : Jerrad Pierce <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/IO-Pager/
* License : other
- Thou shalt not claim ownership of unmodified materials.
- Thou shalt not claim whole ownership of modified materials.
- Thou shalt grant the indemnity of the provider of materials.


This may be a problem.  I know in the past, clauses requiring
indemnification were not allowed.  CCing debian-legal for discussion.
Please follow up there.


- Thou shalt use and dispense freely without other restrictions.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Out-of-tree kernel module popularity

[brian m. carlson]

On Wed, Oct 24, 2007 at 12:22:32PM +0300, Riku Voipio wrote:
[Fedora disallows non-upstreamed kernel modules]


Very interesting. I'd say we should atleast consider it due to various
points:


My concern is modules in the upstream kernel which have firmware 
problems.  While I am opposed to carrying non-free firmware in main, 
I have no problem with carrying it in non-free.  Therefore, some modules 
might do well in contrib, or even in main[0], if the firmware is not 
required.


This problem does not occur with Fedora, and therefore their policy does 
not consider it.  This is why we should not follow Fedora.


[0] The tg3 driver, which I am using right now for my laptop's ethernet 
card, is just such a case.  See also #446028.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations

[brian m. carlson]

On Sun, Nov 04, 2007 at 10:10:58PM -0500, Mohammad Derakhshani wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: zekr-quran-translations-ur
 Version : 1.1.dfsg
 Upstream Author : Mohsen Saboorian <[EMAIL PROTECTED]>
* URL : http://siahe.com/zekr/resources.html
* License : Only free for non-commercial purposes


This is not in compliance with the Debian Free Software Guidelines, so 
you'll have to upload this to non-free (in which case there's no point 
labeling the version with "dfsg").  But see below.



Urdu - Pakistan Urdu. Authors:
 - Maulana Shah Imam Ahmed Raza Khan (kanzul_iman.zip).


According to Wikipedia, the translator died in 1921, which means that 
his translation occurred prior to 1923.  In this case, the translation 
is in the public domain in the United States, so the license above is 
incorrect.



There is no authenticity or correctness warranty for these
translations. For more information please read the provided
/usr/share/doc/zekr-quran-translations-ur/README.txt file.


Disclaimers are most appropriate in the copyright file, not in the 
package description.  The package description should provide only enough 
information for one to decide whether or not to install the package.  If 
the correctness of the translation is so doubtful as to be useless, then 
perhaps the translation should not be packaged at all.


IANAL; IANADD.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations

[brian m. carlson]

On Mon, Nov 05, 2007 at 01:48:04AM -0500, Mohammad Derakhshani wrote:

I named this packaged based on another package of mine which was reviewed
and accepted:
<http://packages.debian.org/sid/zekr-quran-translations-en>

Do you think the dfsg even in the accepted package
zekr-quran-translations-en should be removed?


You only use "dfsg" in the version number of a package when you have 
repacked the original tarball to exclude materials that aren't in 
compliance with the DFSG.  Since you obviously don't do that with 
non-free packages, there's no point in using the "dfsg" label.


I think that whenever you upload a new upstream version, you should 
remove the "dfsg" in the English translations package, yes.  Don't 
re-upload just to remove the "dfsg".



I think this translation is good enough to be packaged for Debian. But
because
1. issue of translating Quran is very disputable (In Islamic theology,
perfectly translating Quran is considered impossible), and


I'm aware of this debate.


2. we are not sure enough that the current translation is exactly word by
word matches the real translation done by the its translator, and
3. in zekr-quran-translations-en which was reviewed and accepted we used
exactly the same disclaimer,
in my humble opinion, I think it is better to not change the disclaimer.


Okay.  I'm not at all picky.  You're always free to ignore my 
suggestions; you're the maintainer, and I'm not.



P.S: If you can send me a link of howto discussing when a package should be
called dfsg I will appreciate.


Included above.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature