Bug#808234: signify: Depends on virtual package "perl5" which is gone with perl/5.22

[Brian White]

Thanks.  I no longer have a Debian development machine.
-- Brian


On Thu, Dec 17, 2015 at 9:16 AM, Dominic Hargreaves  wrote:

> Package: signify
> Version: 1.14-1
> Severity: serious
> Justification: package uninstallable
> Tags: sid pending
> User: debian-p...@lists.debian.org
> Usertags: perl-5.22-transition
>
> The perl 5.22 transition just started (see
> https://lists.debian.org/debian-devel-announce/2015/12/msg5.html)
> and we seem to have missed that this package depends on the deprecated
> virtual package "perl5" like some other packages did.
>
> The perl 5.22 packages don't provide perl5, making this package
> uninstallable.
>
> I'll do a QA upload shortly.
>
> Cheers,
> Dominic.
>



-- 
  Brian
  bcwh...@pobox.com
--

*Treat someone as they are and they will remain that way.Treat someone as
they can be and they will become that way.*

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Brian White]

I don't maintain Signify it any longer (or even use it) so feel free to do
with it whatever you like.

-- Brian

On Sat, Jan 10, 2015 at 12:31 AM, Riley Baird 
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:

 Thanks for the review

 
 http://mentors.debian.net/debian/pool/main/s/signify-openbsd/signify-openbsd_8-1.dsc
 
 
  The package FTBFS here:
  |dh_auto_clean
  | make[1]: Entering directory
  '/build/signify-openbsd-EGTooy/signify-openbsd-8'
  | /bin/sh: 1: pkg-config: not found
  | Makefile:52: *** libbsd is not installed or version is older than
  0.7.  Stop.
  | make[1]: Leaving directory
  '/build/signify-openbsd-EGTooy/signify-openbsd-8'
  | dh_auto_clean: make -j1 distclean returned exit code 2
  | make: *** [clean] Error 2

 I've added pkg-config as a Build-Depends, and tested the package using
 cowbuilder. This error is no longer be present.

  Renaming files using patches (move-manpage.patch) is a bad idea. Rename
  it in debian/rules instead.

 Done.

  Have you talked with upstream about the name collision?

 No, I haven't. OpenBSD is definitely not going to change the name,
 although the maintainer of the portable version might.

 Before I ask the maintainer of the portable version to do so, I'd like
 to see what the maintainer of Debian's signify thinks about this. If he
 would be willing to rename /usr/bin/signify and
 /usr/share/man/man1/signify.1.gz to something else, signify-openbsd
 would be easier to maintain, and more consistent with upstream.

 There hasn't been an upload of the signify package since 2004, so it
 should be easier to keep up with upstream changes (if there are any more).

 I've CC'd this message to the signify maintainer for input.

  Typos in upstream code:
  equivilent - equivalent
  ouput - output

 Do these really have to be fixed? They won't be visible to the user, and
 it's likely to annoy upstream more than anything. I'll do it if I have
 to, though.




-- 
  Brian
  bcwh...@pobox.com
--

*Treat someone as they are and they will remain that way.Treat someone as
they can be and they will become that way.*

Bug#658139: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).

[Brian White]

 Lastly, I would like to thank Brian for his impressively 16-years long
 work on
 mime-support.  Brian, feel free to stay among the uploaders !


Thanks.  I wish I had the energy to make some of the much-needed changes
but I'm just not involved with the project enough these days to have a good
feel for how it should be improved.

Make it great!

  Brian
  bcwh...@pobox.com
--
*Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.*

Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems

[Brian White]

 In 3.52-1 you removed application/x-httpd-* to close #589384.


I have no preference to it being present or not.  It was marked as release
critical by the Apache/PHP folks.  Decide among yourselves what is correct
and I'll make it that way.

-- Brian



 This happened without any notice to the NEWS files and I really
 wonder whether any though has been spent on which tremendous
 security effects this can have.

 Given that most people (reasonably) rely on /etc/mime.types
 to determine the MIME type for files e.g. with Apache removal
 of the above means e.g. that php scripts are no longer determined
 as such, but now diretcly shown as text files.

 With all secruity effects you can think of and all you even can't
 think of.
 And of course it breaks countless of working installations
 using e.g. php.


 a) If you make such a tremendous change you have to announce it
 in the release file.


 b) Removing the type is definitly the wrong decision.
 Apache provides many means to change the handlers and if all that
 shouldn't work (which I doubt) on can simply disable the use of
 /etc/mime.types.
 It's not the business of mime.type to please any specifc user,...
 like it seems to me with the aforementioned bug.
 Nor should it be mime.type's business to please any software if that
 was borken (but as said, apache is not).



 Obviously application/x-* are not official flags, but if that was
 the reason we'd have to remove much more than just the php ones.



 Cheers,
 Chris.


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

 Kernel: Linux 3.2.17-heisenberg (SMP w/2 CPU cores; PREEMPT)
 Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 mime-support depends on no packages.

 Versions of packages mime-support recommends:
 ii  file  5.11-1

 mime-support suggests no packages.

 -- no debconf information

Bug#661240: mime-support 3.52-1 breaks WordPress

[Brian White]

There's a number of new mime.type changes in 3.52.  Would you be willing to
copy /etc/mime.types from 3.51 to a temp location, install 3.52, copy that
version elsewhere, copy the old version back to its original location, and
see if it's okay again?  If so, would you send me the diff -u output of
the two versions?

If you want, you could try to narrow down exactly what difference is
causing your problem.

  Brian
  bcwh...@pobox.com
--
*Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.*

Bug#623384: mime-support: /usr/bin/see runs in an endless loop and spawn lot of processes

[Brian White]

At the very least I'd need to know the type of the attachment causing the
problem, the contents of your /etc/mime.types file, the contents of your
/etc/mailcap file, and any ~/.mime.types or ~/.mailcap file you may have.

  Brian
  bcwh...@pobox.com
--
*Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.*

Bug#639580: [mime-support] A detailed error output

[Brian White]

Inserting quotes somewhere in the middle of a command-line argument is no
different than putting quotes around the entire thing.  The shell strips
them and considers whitespace in the middle to not be an argument boundary.
 You can omit the quotes completely from the mailcap rule and update-mime
will add them appropriately.

-- Brian

On Mon, Aug 29, 2011 at 12:08, Uwe Kerstan uwe.kers...@gmx.de wrote:

 Package: mime-support
 Version: 3.48-1

 --- Please enter the report below this line. ---

 $ see --debug /usr/share/pixmaps/gnome-debian.png
  - parsing parameter /usr/share/pixmaps/gnome-debian.png
  - Reading mime.types file /home/user/.mime.types...
  - Reading mime.types file /etc/mime.types...
  - extension png maps to mime-type image/png
  - Reading mailcap file /etc/mailcap...
 Processing file /usr/share/pixmaps/gnome-debian.png of type image/png
 (encoding=none)...
  - checking mailcap entry image/png; display 'png:'%s''; test=test -n
 $DISPLAY
  - program to execute: display 'png:'%s''
  - running test: test -n $DISPLAY  (result=0=true)
  - executing: display 'png:'/usr/share/pixmaps/gnome-debian.png'
 sh: Syntax error: Unterminated quoted string
 Warning: program returned non-zero exit code #2

 It is missing an apostrophe at the end of the executing command line.


 --- System information. ---
 Architecture: amd64
 Kernel:   Linux 2.6.32-5-amd64

 Debian Release: 6.0.2
  500 stable  security.debian.org
  500 stable  ftp.de.debian.org

 --- Package information. ---
 Package's Depends field is empty.

 Recommends   (Version) | Installed
 ==-+-
 file   (= 3.27-3) | 5.04-5


 Package's Suggests field is empty.






-- 
  Brian
  bcwh...@pobox.com
--
*Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.*

Bug#646461: /usr/bin/run-mailcap: cannot view HTML files

[Brian White]

run-mailcap is doing the right thing here and calling sensible-browser to
view the file.  That program is the one claiming that there is now known
browser on your system.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#646462: mime-support: Runs notepad to view text files

[Brian White]

Something is creating an entry in the /etc/mailcap (or ~/.mailcap) for this
file type.  Mime support is just following the instructions there.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#646462: mime-support: Runs notepad to view text files

[Brian White]

 Excerpts from Brian White's message of Mon Oct 24 14:14:15 +0200 2011:
  Something is creating an entry in the /etc/mailcap (or ~/.mailcap) for
 this file
  type.  Mime support is just following the instructions there.

 Actually, there is no usable entry for text/plain in /etc/mailcap so
 notepad may be just fallback of some sort.


No, there is no automatic fallback in Mime.  Check for a text/* entry.  It's
possible that sensible-editor is doing it, too.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#608342: [mime-support] Please add cautious-launcher support to work with Wine.

[Brian White]

Can you attach the entire program instead of just a patch?

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#605250: mime-support: application/rss+xml is not a registered MIME Type

[Brian White]

 There are other unofficial mappings, outside the x- namesapce, e.g. for
 rar.

 What's the policy of the mime-support package on them?

 IMHO all unofficials (except the x-*'s) should be removed.


When it comes to mappings, official mappings take precedence.  Beyond that,
I don't care.  Mapping an extension to an unofficial type is not worse than
no mapping at all.

I used to ask for references to add types, but it was just an exercise in
frustration for me.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#605254: mime-support: compression schemes inconsistencies

[Brian White]

 Guess I was wrong with some of the above:
 All of them, whose _decompressed_ data is more than just any raw data
 (i.e. all archives which can have multiple files, or so)
 can have their own (un)official mime type.


If an application stores information about the original file (like it's
filename) rather than just act without thought on a data stream, then it's
more than just an encoding.



 Especially
 application/x-gtar-compressed   tgz taz
 however not (don't know about the others).
 tgz and taz should be added to application/x-tar (in addition to .tar), as
 they're both tar archives just with an gzip/compress Content-Encoding.


Correct, but not so simple.  Expecting a program/person to recognize .gz and
meaning gzipped is more reasonable than expecting it/them to reliably
recognize that some (but not all) extensions ending with a z are also
such.

After that, we're left with the fact that tar will not process a tgz or taz
file without an added option on the command line.  Thus, it must map to a
different type to get opened in a different way.  I gather newer version of
tar can recognize some file extensions but I don't know to what degree and
apparently not by analyzing the data stream itself (which is important
should the data be coming from stdin).  There's also something to be said
for backwards compatibility.



 You already do this nicely with svgz, which is just an gzipped svg and
 which you map to the svg mime type.


Presumably because the application can natively handle both formats.  That
mapping was asked for by someone else.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

 There are many more of these.  Debian's (lack of) handling of gzip as
 a MIME type is broken, even with respect to HTTP.  HTTP's handling of
 gzip as a content encoding is intended to be transparent to the user:
 if the file is stored on the server as a .gz file, it should arrive at
 the user's end as a .gz file.  Apache (or whatever web server) should
 not tell the client to decompress it.


It's a feature of Apache to be able to pre-compress files to reduce network
bandwidth and thus transmission time.  In order to make this transparent to
the user, Apache tells the browser the real type and that it is compressed.
 If the browser does not support tranfer-encoding, then it uncompresses
before sending.



   So, in other words, Debian broke it.  Debian failed to recognize that
   MIME and HTTP treat data types differently, and continues to do so.
   And instead of fixing it properly, Debian decided to break MIME to
   make it work for HTTP.  Brilliant.
 
  Hindsight is always perfect.

 And having hindsight, you can always fix your mistakes.  Even if you
 don't fix it for current versions, you can correct your broken policy
 and fix it for future ones.


If that's all it was, I wouldn't have a problem adding those types to the
file despite the fact that mail programs *should *work with or without them.
 The risk of breaking existing webservers, however, is a very serious thing
to consider.


   Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

Dear Apache Maintainers...

I'm being petitioned quite strongly to re-add types for gzipped files to the
/etc/mime.types file.  I originally removed those types from that file
because they caused Apache to work incorrectly, namely that Apache would
then send a foo.html.gz file as type=application/x-gzip instead of
type=text/html;encoding=gzip.

If I were to add these types back, what havoc might that wreak on current
and previous releases of Apache?

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#573518: mime-support: upstream and out of date mime.types

[Brian White]

   http://git.fedoraproject.org/git/mailcap.git?f=mime.types;hb=HEAD


Do you have an up-to-date link for that?

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#569738: mime-support: Should allow user-specific configuration

[Brian White]

 However, the coolest thing would be if I needn't keep my own .mailcap by
 hand.  Instead, I would just have my ~/.mailcap.order and call
 update-mime with a --userdir option.


I've added a --local option todo this.  Let me know if it doesn't work for
you.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#560118: miscategorized mimetypes

[Brian White]

 Package: mime-support
 Version: 3.46-1

 I think application/x-go-sgf should be text/x-go-sgf.

 I also think its likely that application/x-chess-pgn and
 application/x-ruby, as well as possibly some others, should be text.
  Additionally, it seems that these are the same on gentoo/KDE as well
 as debian/gnome so I'm not sure if I should just file a separate bug
 report with gentoo or what.


I'm not sure.  Just because a file is human readable doesn't mean it's
text.  If it's intended as input for a program (rather than direct reading
by a user), then it should be under application/.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#445267: mime-support: Please make it possible to specify fallbacks in ~/.mailcap

[Brian White]

  At the moment ~/.mailcap takes precedence over /etc/mailcap, so a user
 can't specify a program to use for types that don't have a rule in
 /etc/mailcap.

 Specifically, I'd like to be able to specify fallbacks for text/* and
 application/* (and just point them to my editor). If I do this at the
 moment, then of course the setting overrides everything in
 /etc/mailcap, which isn't what I want.


 I think that what you're asking would go against the directions of the
 RFCs.

 Even if I change the behavion of run-mailcap, though, it may not help you
 as many programs implement the processing of ~/.mailcap and /etc/mailcap in
 their own code rather than calling my program.  Thus, the operation of the
 system would not be consistent as it would vary depending on what program
 you're running.


 OK. Is what I want to do stupid? If not, how do you think it is best
 accomplished?


 Not at all.  I understand why that would be beneficial.  However, the /*
 entries are more of an afterthought in mime-types rather than a planned out
 feature.

 If you don't care about per-user, you could just add a rule is the
 /usr/share/lib/mime/packages (or something like that) with the rule you
 want.  That will make it system-wide next time update-mime is run.


With the release of mime-support I'm about to make, you can do update-mime
--local to generate a ~/.mailcap entry that will completely replace the one
in /etc.  I think that with a ~/.mailcap.order and some custom rules
inserted in the correct place, you can achieve what you want.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

   Everything is an encoding.  HTML is an encoding.  MP3 is an encoding.
   ASCII is an encoding.  All digital data on a computer is an encoding
   of some sort.  Purpose *absolutely* matters.
  
 
  All of those are more than an encoding.  They apply some meaning to the
  data.
 
  As you say, purpose matters.  There is no purpose to data just because
 it's
  gzipped.

 False.  The purpose is to take up less space.


That's why you compressed it.  That's not the purpose of the data.


  But how does mime-support identify what the file type is?  It can't...
   because the file type of *this file* is gzip data, and you've not
   provided a type for that.
 
  It's smart.  It recognizes the indication that the data has been
  compressed and then uncompresses it before using the type of the
  data to determine the proper destination.

 No, HTTP does this.  MIME, as I have said repeatedly, has ABSOLUTELY
 NO PROVISION to do this.


You didn't ask about MIME.  You asked about how mime-support does it.  My
program is smart.



  Gzipped data is not a type.

 It absolutely is.  Your failure to recognize this simple fact is the
 sole reason that your mime package is broken and that some mail
 programs have trouble correctly dealing with gzip files.


Just because other systems associate a type with a .gz extension does not
mean that is correct.  It's an encoding.  You want to assign a type to it
because you believe it will make things work better.



  Yes, with a type, some mail programs may better handle the file
  because it won't treat it as text but dumping the uncompressed
  output isn't any better.

 The point is they will do no such thing.  They will correctly
 recognize these files as compressed archives, and allow the user to do
 what is intended to be done with them: store them on disk compressed.


That makes no sense at all.  Disks don't care about the type of the data
so data, compressed or not, can *always* be stored on disk.  MIME has
nothing to do with that.



 That is the purpose of gzipped files.  To be stored in less space than
 they would otherwise occupy.  Providing a type allows mail clients to
 do exactly that.  Not providing one causes them (in at least some
 cases) to fail.


Fail how?



   Then fix Apache.  Or explain why other Linux distros which do have
   these types (e.g. most any Red-Hat based distro) don't have this
   problem...
  
 
  Apache used to come with its own mime.types file independent of the
  system.  The Debian package used the system one.

 So, in other words, Debian broke it.  Debian failed to recognize that
 MIME and HTTP treat data types differently, and continues to do so.
 And instead of fixing it properly, Debian decided to break MIME to
 make it work for HTTP.  Brilliant.


Hindsight is always perfect.



  *You* fix apache!  And fix all previous releases.  And push that change
 to
  every Debian-based webserver on Earth.  Then we can talk.

 There's nothing to do, except for debian to reverse it's
 ill-conceived, broken policy decision.  And fixing that is exactly
 what I'm attempting to do now.  Unfortunately I lack the required
 access to make the necessary change.


You can always build your own mime-support package from source and install
that on your own workstations.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

  Because if .gz was present, it would send the file as the associated
 type.
  If it wasn't, then it would look beyond and send the correct type with a
  content-encoding of gzip.

 Then Apache (or possibly the HTTP standard itself) is broken, and
 should be fixed.  You can not justify breaking a pre-existing standard
 to make a subsequent unrelated one happy.


MIME is far more broken than HTTP.



 It has the same features as something that is uuencoded.

  
   False.  Something uuencoded has been re-encoded in a different format
   expressly for the purpose of *transfering* it via mechanisms which
   require 7-bit ASCII (SMTP).
 
  The purpose does not matter.  It's an encoding.  Whether it's an encoding
  for a 7-bit, non-clean channel or any other kind of encoding, it's still
 an
  encoding.

 Everything is an encoding.  HTML is an encoding.  MP3 is an encoding.
 ASCII is an encoding.  All digital data on a computer is an encoding
 of some sort.  Purpose *absolutely* matters.


All of those are more than an encoding.  They apply some meaning to the
data.

As you say, purpose matters.  There is no purpose to data just because it's
gzipped.  The purpose of the data is the same both before and after the
compression.



tar xvf - . | gzip -c  my_archive.gz
 
  That's still one file, a tar file.  The fact that tar contains other
 files
  within it is not relevant.  As far as gzip is concerned, it is a single
  entity.

 But how does mime-support identify what the file type is?  It can't...
 because the file type of *this file* is gzip data, and you've not
 provided a type for that.


It's smart.  It recognizes the indication that the data has been compressed
and then uncompresses it before using the type of the data to determine the
proper destination.



  The content type is x-tar (or whatever) and the encoding is gzip.

 for i in * do; echo __divider__ ; cat $i; done |gzip -c  my_archive.gz

 Now what is it?


It's still one data stream and one file as far as gzip is concerned.



 Again, the point is that gzip data is arbitrary; all
 that the e-mail system knows, and needs to know, about this file is
 that it is gzip data.


No!  Knowing that it's compressed is absolutely useless to an e-mail system
because it cannot _do_ anything with it.



 Just as MP3 files are meaningless until they
 are decoded with an mp3 player, this archive file is meaningless until
 it is decoded with a decompression program.


It's meaningless after, too, which is the difference.



  MIME, i.e. the e-mail
 system need not know what type of data is compressed; MIME exists to
 convey to the user what to do with the attached file.  This file needs
 to be processed with a decompression program.  You're failing to
 provide that by not providing MIME types for gzip.

Thus, both the type and the encoding are available in the filename.
  
   Clearly false from the above.
 
  Clearly true if you start with a file and don't specifically choose to
  obfuscate the data.

 Only true if you actually *have* a file.  The gzip application makes
 no such assumption, and MIME must not either.  Arbitrary data on stdin
 is not a file and has no data type, as far as gzip is concerned.  The
 resulting file does: gzip data.


No, it's gzipped arbitrary data since arbitrary data was the input.



  In the end, the amount of information about the type of data is the same
  both before and after gzip touches it.  If it came from a file, the type
  (extension) is preserved.  If it came as an arbitrary octet stream, the
  output is an arbitrary octet stream.

 But with respect to your e-mail via which you're transporting the
 archive, it's a gzip archive.


No, it's gzipped something.



 There is a way to know; use content-type and content-encoding, just
 as
   HTTP
does.
  
   Please show me where in the MIME standards this is allowed.
   Content-encoding is not a valid MIME header, as far as I'm aware.
   Content-transfer-encoding is, but gzip is not a valid content transfer
   encoding defined by the MIME standards, and in fact it can not be one,
   because attachments encoded in gzip can not be sent as-is over SMTP.
  
 
  MIME allows for extensions.  I didn't say it was part of the RFC.

 Sure it does, but no such standardized extensions exist, and no such
 extensions are implemented in a standard fashion.  And the fact is
 none is needed or desired; all that is required is to specify that the
 attached file is gzip data.  Users who transmit gzipped files
 typically don't want you to uncompress the files upon delivery (which
 is also true for files downloaded via HTTP, in my experience)... they
 want to save the compressed archive for later processing.

 Regardless, your insistance that gzip is an encoding is not supported
 by the MIME spec or any standard extension.  It's invalid for MIME,
 though it's perfectly correct for HTTP.

   This is essentially true, but providing a proper MIME type prevents
   e-mail clients from 

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

  At one point (the point at which they were removed from this file),
  including them would break Apache.

 That's probably an apache bug, but I think you're confusing the issue.
 MIME standards apply to e-mail, not HTTP, and as such Apache is
 irrelevant to this discussion.


HTTP uses the same content-type values as MIME.



 But I don't see why adding these MIME types -- which many other OSes
 do include in their system-wide mime.types file, including many other
 Linux distros -- should break Apache.


Because if .gz was present, it would send the file as the associated type.
If it wasn't, then it would look beyond and send the correct type with a
content-encoding of gzip.



   A file that has been gzipped contains data, and is a particular
   type of file: a compressed archive.
 
  Gzip, unlike tar or zip, is not an archive.  It is one file.

 The fact that it contains only one file in no way makes it not an
 archive.  The primary purpose of data compression historically was to
 make it smaller for storage: i.e. archival.  Besides which, a gzipped
 file need not contain only one file; see below.


You can't say archive for transmission and then define an archive as
something for storage.



   It has the same features as something that is uuencoded.

 False.  Something uuencoded has been re-encoded in a different format
 expressly for the purpose of *transfering* it via mechanisms which
 require 7-bit ASCII (SMTP).


The purpose does not matter.  It's an encoding.  Whether it's an encoding
for a 7-bit, non-clean channel or any other kind of encoding, it's still an
encoding.



  In addition, gzip does not change the extension but merely adds a .gz
  extension.

 You're making assumptions that are false.  That's the default behavior
 of the gzip program when run against a single file (which even in that
 mode can be overridden).  This is not the only mode in which gzip
 works.  One can run it like so, for instance:

  tar xvf - . | gzip -c  my_archive.gz


That's still one file, a tar file.  The fact that tar contains other files
within it is not relevant.  As far as gzip is concerned, it is a single
entity.


What type of data is that?


The content type is x-tar (or whatever) and the encoding is gzip.



 You need not use tar... any arbitrary
 program can feed data to gzip in this manner, and there need not be a
 specific file type associated with it.


I believe I said just that.  It's arbitrary data.  The type is in the
original data.  Gzip does not change the type, it merely encodes it in a
convenient manner.



 Thus again, you do not
 have any way to determine what type of data is in the gzip archive.


No arbitrary stream of data has a type associated with it -- introspection
of the data notwithstanding.



 All that MIME knows is that this file is a gzipped archive -- except
 in Debian it doesn't, because you've removed  the MIME types from the
 system mime.types file.  So it knows absolutely nothing.


Even if it knew it was gzipped data, it would still know nothing.  Knowing
how it was encoded tells you nothing about what the dencoded data means.



  Thus, both the type and the encoding are available in the filename.

 Clearly false from the above.


Clearly true if you start with a file and don't specifically choose to
obfuscate the data.

In the end, the amount of information about the type of data is the same
both before and after gzip touches it.  If it came from a file, the type
(extension) is preserved.  If it came as an arbitrary octet stream, the
output is an arbitrary octet stream.



   There is a way to know; use content-type and content-encoding, just as
 HTTP
  does.

 Please show me where in the MIME standards this is allowed.
 Content-encoding is not a valid MIME header, as far as I'm aware.
 Content-transfer-encoding is, but gzip is not a valid content transfer
 encoding defined by the MIME standards, and in fact it can not be one,
 because attachments encoded in gzip can not be sent as-is over SMTP.


MIME allows for extensions.  I didn't say it was part of the RFC.



it is only suitable for MIME handlers to treat such files as
   application data, which can be processed by the gzip program, as
   MIME was always intended to be used.
 
  Processing by the gzip program is equally useless on its own.  You're
 just
  changing one stream of bytes for another.

 This is essentially true, but providing a proper MIME type prevents
 e-mail clients from mishandling gzip files, for example by attaching
 them with an incorrect MIME type (or none at all) or attempting to
 display them as plain text when their mime-type lookup fails.


That is unfortunate, I agree.  I could assign octet-stream as the type to
the .gz file and make that go away.  In the end, it's just as meaningful.



  on the file will not display the file because gzip will not display
  anything.

  Despite the problems, mapping .gz to a gzip type gains nothing.
  Clicking
 It gains something very important: it 

Bug#589991: mime-support: MIME types needed for x-gzip and x-compress

[Brian White]

 I will systematically prove that (depending on semantics) either this
 is outright false, or that the term encoding has been
 misappropriated and, in the context of MIME, excluding these on the
 basis that they are encodings is completely inappropriate.


At one point (the point at which they were removed from this file),
including them would break Apache.



 A file that has been gzipped contains data, and is a particular type
 of file: a compressed archive.


Gzip, unlike tar or zip, is not an archive.  It is one file.  It has the
same features as something that is uuencoded.

In addition, gzip does not change the extension but merely adds a .gz
extension.  Thus, both the type and the encoding are available in the
filename.



 An archive of what, MIME has no way to
 know, and no reason to care.


There is a way to know; use content-type and content-encoding, just as HTTP
does.



 It matters only that it is a gzip
 archive.  In order for MUAs to handle such files suitably when
 attached to a MIME e-mail, it must be possible for those mailers to
 identify the type of file that has been attached.  Without a MIME
 type, MUAs are expected to assume that an attached file is plain text
 (see RFC 2045, section 5.2).


MIME, by definition, includes the type of the data.

What you are referring to is mime-types, a simple system designed to guess
an appropriate mime-type based on a filename extension.  I can only assume
that you mean that the sender set the wrong content-type or it was not MIME
at all and the receiver can only guess the content-type based on the
extension.



 The primary purpose of file compression is to archive data in a
 smaller amount of space than it otherwise would consume.  It's true
 that compressing the file constitutes an encoding -- but then the
 same is true of encoding music as MP3, images as PNG, HTML-formatted
 text, etc.


Not true.  Gzip is an outside encoding.  MP3, etc. are encodings inside the
type itself.



 compressing a file with gzip *does not* fulfill the purpose
 of the transfer encoding with respect to MIME.


Gzip is a content-encoding, not a content-transfer-encoding.


Additionally, a gzip archive provides no means to identify the type of
 content that is encoded.


Yes, it does.  The original file extension is still present which is just as
good an indication of the type as .gz is of anything.



 All that one can be sure of is that the data
 so provided can be reprocessed by gzip to uncompress it.  The MIME
 standards likewise currently provide nothing suitable for e-mail
 clients to convey this information.  For these reasons, it is only
 suitable for MIME handlers to treat such files as application data,
 which can be processed by the gzip program, as MIME was always
 intended to be used.


Processing by the gzip program is equally useless on its own.  You're just
changing one stream of bytes for another.



 Finally, the MIME standards dictate that files not marked with an
 associated Content-Type (MIME type) be asssumed to be plain text (RFC
 2045 sect. 5.2).  This clearly is unacceptable for gzipped data, as it
 is quite certainly invalid plain text.  As such, it *must* have a
 suitable MIME type associated with it.


It's the sender that sets the content-type of a MIME attachment.  Adding a
mapping to the receiving machine will not change this.


Please add MIME types for gzip and compress archive files.


Despite the problems, mapping .gz to a gzip type gains nothing.  Clicking
on the file will not display the file because gzip will not display
anything.

However, other programs (like Apache) may be smart enough to properly deal
with the encoding and pass this information to the clients and creating the
entry for which you ask could break a great many web-servers around the
world.

  Brian
  bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#572658: O: signify -- Automatic, semi-random .signature rotator/generator

[Brian White]

close 572658
--

As the original author of this code, I do do work on it at times.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#261162: Processed: reassign 261162 to mime-support, affects 261162

[Brian White]

  Sorry to say, I don't think there's any way to fix this.  I can't write
 to
  the current directory and I can't pass a filename with shell
 meta-characters
  to the command.

 What's so hard on properly escaping this?


It's impossible because there is no way to know how it will be injected into
the command line.  Imagine these two mailcap command entries:

myprog %s
myprog '%s'

There is no way to escape the meta-characters such that it will be correct
in both cases when substituted for %s.  Since the contents of the mailcap
files is under user control, both of the above are possible.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

  I can change the cat option to only match copiousoutput entries if
 you
  wish.  It's a perfectly reasonable behavior given that cat isn't
 defined
  in the first place.

 Yes, could you please do so.

 That would be the best since as you say cat isn't defined in the first
 place and at least some people need canonical way to run run-mailcap as
 filter, where cat fits perfectly imho.


Done in v3.48, just uploaded.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

 I too think, --action=cat should ignore X viewers.

 After all, original --action=cat use case (as requested by me btw in
 #526690) was to use it as canonical filter. So _filtering_ functionality
 was assumed by --action=cat, and otherwise to me cat seems to be useless
 because we have --action=view.


 For my needs I created an extra script

  8 astextplain 
 #!/bin/sh
 unset DISPLAY
 run-mailcap --action=cat $*
  8 

 instead of just using `run-mailcap --action=cat` where appropriate.

 What are use-cases for current cat behaviour? If there is none besides
 being used as a filter, let's please make it ignore interactive viewers
 and just pipe the result to stdout.


That makes sense, but I can think of no generic way to know if it's an
interactive viewer.  I suppose we can say that between $DISPLAY and
needsterminal that covers almost all possibilities.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

  What are use-cases for current cat behaviour? If there is none
  besides being used as a filter, let's please make it ignore
  interactive viewers and just pipe the result to stdout.

 That would be my preference too. To obtain the functionality as
 Brian implemented it, I'd probably rather something like
 run-mailcap --action=view --nopager since it's such a minor
 change from the default view action. However that isn't
 interesting to me so I didn't implement it.


That would be an easier change.  Plus, it would mean not violating the RFC
by adding a new action.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#261162: Processed: reassign 261162 to mime-support, affects 261162

[Brian White]

close 261162
--

Sorry to say, I don't think there's any way to fix this.  I can't write to
the current directory and I can't pass a filename with shell meta-characters
to the command.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.


On Mon, Nov 2, 2009 at 10:54 AM, Debian Bug Tracking System 
ow...@bugs.debian.org wrote:

 Processing commands for cont...@bugs.debian.org:

  reassign 261162 mime-support 3.46-1
 Bug #261162 [gqview] gqview: mime entry (see has problems with displaying
 files with brackets
 Bug reassigned from package 'gqview' to 'mime-support'.
 Bug No longer marked as found in versions 1.4.3-1.
 Bug #261162 [mime-support] gqview: mime entry (see has problems with
 displaying files with brackets
 Bug Marked as found in versions mime-support/3.46-1.
  affects 261162 geeqie
 Bug #261162 [mime-support] gqview: mime entry (see has problems with
 displaying files with brackets
 Added indication that 261162 affects geeqie
 
 End of message, stopping processing here.

 Please contact me if you need assistance.

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

Bug#558650: mime-support: Smooth handling of gzipped files ?

[Brian White]

 application/pdf; okular '%s'; nametemplate=%s.pdf; test=test $DISPLAY !=
 ; encodings=gzip,bzip,bzip2,compress;
 (note that the nametemplate would probably have to be removed, or
 run-mailcap would
 have to append the default compresser extension for the app to be fine).


That's an interesting idea.  Unfortunately, there is an RFC that spells out
quite clearly how mailcap is laid out and arbitrarily adding things to it
isn't such a good choice.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

   What are use-cases for current cat behaviour? If there is
   none besides being used as a filter, let's please make it
   ignore interactive viewers and just pipe the result to
   stdout.
 
  That makes sense, but I can think of no generic way to know if it's an
  interactive viewer.

 I thought copiousoutput meant non-interactive stdout.  Am
 I mistaken?


copiousoutput indicates that the program produces a lot of output and
should be fed into a pager program so as to not overwhelm the user.  I've
added a --nopager option in the latest upload.



  I suppose we can say that between $DISPLAY and
  needsterminal that covers almost all possibilities.

 Unfortunately I know of at least one filter (unoconv) that
 connects to the X server (to access the openoffice server,
 I believe). So if we want that to work, it's not really an option
 to unset DISPLAY prior to running mailcap tests.


I've left cat in place though it now unsets DISPLAY.  There's no perfect
solution, I'm afraid.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

   I thought copiousoutput meant non-interactive stdout.  Am
   I mistaken?
 
  copiousoutput indicates that the program produces a lot of output
  and should be fed into a pager program so as to not overwhelm the
  user.  I've added a --nopager option in the latest upload.

 So by strict RFC interpretation, a mailcap rule specifying
 copiousoutput implies non-interactive output on stdout, however
 a mailcap rule lacking copiousoutput does not strictly imply
 the opposite.


No, it doesn't.  You can't win here.  Mailcap was written with the intent of
user interaction, not for filtering.  No solution is going to work in all
situations unless you deviate from the RFC.



 Unfortunately this strict interpretation of the flag isn't
 useful for a couple reasons:

 1. there's no way for the mailcap rule to know the length of the
   output since it depends on the input.

 2. the use of a pager depends on the size of the output compared
   to the size of the terminal, but the mailcap doesn't know the
   size of the terminal either.

 This is probably why mutt deviates from strict RFC for the
 copiousoutput flag, meaning that mutt uses the flag to find
 rules that generate non-interactive stdout.


Sure, but you can't depend on the people writing the mailcap entries to flag
their programs that way unless you want to create a new RFC or make it
Debian policy.

I can change the cat option to only match copiousoutput entries if you
wish.  It's a perfectly reasonable behavior given that cat isn't defined
in the first place.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#545087: mime-support: gzip and bz2 should be listed as mime.types

[Brian White]

 while troubleshooting bug #541241 of the mutt package and reporting it to
 upstream [0], I found out that Debian does not list .gz and .bz2 in
 mime.types
 because they are considered 'encodings'. I saw that this change happened in
 version 3.1-1 but I wasn't able to find a related bug report.


Did you read the top of the /etc/mime.types file for an explanation?

There might have been a time back in v1.x where there was mistakenly a .gz
or .bz2 file, but I'm pretty sure that they weren't present in any 3.x
version.



 Can you please review Derek Martin's correspondence in the upstream mutt
 bug [0]
 and tell me your thoughts? I would like to know what is the reason behind
 the
 fact that we don't have mime-types for these two compression formats,
 considering that they still need to be handled by 'application', even after
 the
 attachment is saved.


I didn't see any way for me to comment so I can't follow-up there.

Saying gzip is a type would be as valid as saying that a .uu (uuencoded)
file is a type.  It's not.  It's an encoding around some other type of
data.  Apache, at one time, used the extension to tell web clients that the
following data was encoded such and then use the inside extension to look up
the file type.  When .gz was present, Apache returned a mime-type of gzip
which was useless to clients.  That was what originally brought it to my
attention.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

 Hi Brian, I must be missing the point of --action=cat.  Its name
 seems to imply non-interactive stdout, but it will still run
 X-based viewers and needsterminal viewers.  The latter seems
 especially strange since the user probably doesn't want an
 interactive curses viewer if they used --action=cat to avoid the
 pager.


I don't mind changing it to ignore X viewers or needsterminal viewers, but
those that can be the case even when copiousoutput is not specified.



 How did you feel I was trying to shoe-horn extra functionality?


--action=filter adds a new type of functionality.  Filtering is not
necessarily the same as viewing.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533722: mime-support: run-mailcap should discard non-applicable entries prior to calling test commands

[Brian White]

 Presently run-mailcap will run mailcap test commands even
 though the rule will eventually be discarded because of
 needsterminal or copiousoutput flags.


Neither of these options should even disallow a rule.  Instead, a new
terminal will be created or the output will be passed to a pager.

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries

[Brian White]

 I came to the conclusion that --action=cat should ignore mailcap
 entries other than copiousoutput.


I don't agree.  Cat is like view but without a pager.  To have it choose
otherwise would be confusing.  The mailcap system is pretty fragile in
general; I don't think you should try to shoe-horn extra functionality this
way.  Instead, create a filter action in the rules you want and use
--action=filter (or similar).

 Brian
 bcwh...@pobox.com
-
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bug#497779: mime-support: should use information in /usr/share/applications

[Brian White]

I’m tired of receiving bug reports asking to add a debian/mime file to
support an outdated MIME system that no application I know besides mutt
still uses.


Thank you for your polite and informative email.  I'll get to it soon.

-- Brian



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

Bug#485863: [mime-support] missing .ogv = video/ogg mime

[Brian White]

i just found out the i was missing this mime type after i tried to open
a .ogv video capture i got from the application gtk-recordmydesktop.


ogv is mapped to video/ogg in v3.43.



i use kde, so i added it locally and my issue was solved but maybe we should
see if their is upstream to mime-support which could add all ogg mime types.

i guess some more mime types are missing from the /etc/mime.types
file... see : http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions


I'll add them.

-- Brian



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

Bug#458691: mime-support should not register a view alternative at any priority

[Brian White]

severity 458691 wishlist
tag 458691 wontfix
--


mime-support does not provide the same functionality but different
implementations.  It provides a program with different functionality
but the same filename.  That does not represent an appropriate use of
the alternatives mechanism.


Sure it does.  It views a file without changing it.  Not all web
browsers provide identical functionality and yet they're considered the
same.  Heck, not even all vi instances provide identical functionality.

-- Brian




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

Bug#458691: mime-support: diff for NMU version 3.40-1.1

[Brian White]

Brian, any particular reason why you didn't include this patch in your
subsequent uploads, or did you just miss it?  This bug is
release-critical, was filed in January and has no comment from you...
Your latest uploads of mime-support still install the /usr/bin/view
alternative, and don't clean it up in prerm.


I just missed it, which is odd since I specifically looked for it. 
Sorry.  I'll take care of it.


-- Brian



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

Bug#480374: Update

[Brian White]

-rw-r--r-- 1 debmirror debmirror   419 2008-05-26 15:17 rfc1522.txt
-rw-r--r-- 1 debmirror debmirror 22502 1993-09-23 01:08 rfc1522.txt~
-rw-r--r-- 1 debmirror debmirror   393 2008-05-26 15:17 rfc1523.txt
-rw-r--r-- 1 debmirror debmirror 32691 1993-09-23 01:10 rfc1523.txt~
-rw-r--r-- 1 debmirror debmirror   393 2008-05-26 15:18 rfc1524.txt
-rw-r--r-- 1 debmirror debmirror 26464 1993-09-23 01:11 rfc1524.txt~


Oh!  The ~ files got included.  I'll fix that.

-- Brian



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

Bug#448023: mime-support: update-mime doesn't pick up everything in mailcap.order?

[Brian White]

Yes.  Add --debug=1 to the command line.

-- Brian



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

Bug#428899: Support RFC4709: application/davmount+xml

[Brian White]

I'll add it to the mime.types file but you'll have to add the rule and 
script to whatever package includes the webdav-client program.


-- Brian



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

Bug#454520: jukebox-mercury: should this package be removed?

[Brian White]

severity 454520 normal
reassign 454520 ftp.debian.org
retitle 454520 RM: jukebox-mercury -- not supported
--


While reviewing some packages, your package came up as a possible
candidate for removal from Debian, because:

 * several RC bugs
 * long since last maintainer upload, last NMU in 2003
 * low popcon

If you think that it should be orphaned instead of being removed from
Debian, please reply to this bug and tell so.


I'm not supporting it.  Do with it what you will.

-- Brian



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

Bug#445267: mime-support: Please make it possible to specify fallbacks in ~/.mailcap

[Brian White]

At the moment ~/.mailcap takes precedence over /etc/mailcap, so a user
can't specify a program to use for types that don't have a rule in
/etc/mailcap.

Specifically, I'd like to be able to specify fallbacks for text/* and
application/* (and just point them to my editor). If I do this at the
moment, then of course the setting overrides everything in
/etc/mailcap, which isn't what I want.


I think that what you're asking would go against the directions of the 
RFCs.


Even if I change the behavion of run-mailcap, though, it may not help 
you as many programs implement the processing of ~/.mailcap and 
/etc/mailcap in their own code rather than calling my program.  Thus, 
the operation of the system would not be consistent as it would vary 
depending on what program you're running.


OK. Is what I want to do stupid? If not, how do you think it is best 
accomplished?


Not at all.  I understand why that would be beneficial.  However, the 
/* entries are more of an afterthought in mime-types rather than a 
planned out feature.


If you don't care about per-user, you could just add a rule is the 
/usr/share/lib/mime/packages (or something like that) with the rule you 
want.  That will make it system-wide next time update-mime is run.


-- Brian



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

Bug#445267: mime-support: Please make it possible to specify fallbacks in ~/.mailcap

[Brian White]

At the moment ~/.mailcap takes precedence over /etc/mailcap, so a user
can't specify a program to use for types that don't have a rule in
/etc/mailcap.

Specifically, I'd like to be able to specify fallbacks for text/* and
application/* (and just point them to my editor). If I do this at the
moment, then of course the setting overrides everything in
/etc/mailcap, which isn't what I want.


I think that what you're asking would go against the directions of the RFCs.

Even if I change the behavion of run-mailcap, though, it may not help 
you as many programs implement the processing of ~/.mailcap and 
/etc/mailcap in their own code rather than calling my program.  Thus, 
the operation of the system would not be consistent as it would vary 
depending on what program you're running.


-- Brian




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

Bug#442072: scrabble: won't let you play both blanks at once

[Brian White]

So I had both blanks in my rack, and the Q and enough good stuff to score big
with it, but it wouldn't let me.


Odd.  I've seen the computer play multiple blanks at once and so it 
should allow it for players, too.  At what positions in the word were 
the blanks located?  There's a restriction on computer play not to allow 
two blanks in the first three letters in order to keep computation time 
reasonable and I wonder if it got applied to the player, too.


-- Brian




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

Bug#367727: jukebox-mercury: must use invoke-rc.d

[Brian White]

tags 367727 +patch
thanks

On 06/05/18 00:21 +0300, Lars Wirzenius said ...

As of Debian Policy Manual version 3.7.2, the use of invoke-rc.d to
run init.d scripts has been made mandatory. Earlier, its use was


I no longer have the Mercury box I used to originally play with this. 
If you're using it, why not take over the package?


-- Brian




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

Bug#274987: Bug#297293: Error Copying to Sent Folder

[Brian White]

Thank you for your bug report.
Is this still a problem for you with latest version of Thunderbird?


I haven't seen it recently, no.

-- Brian


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

Bug#400701: Confirm bug report

[Brian White]

Can you please confirm that this bug (#400701) still exists in the
latest versions of the cyrus packages?


Sorry.  I no longer work at the company that had that configuration so I 
cannot test it.


-- Brian


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

Bug#413379: mime-support: /usr/bin/see does not handle whitespace in names.

[Brian White]

/usr/bin/see does not handle whitespace in names properly.


It should.  Please run

see --debug=1 'A B.pdf'

and send me the output.  Thanks!

-- Brian


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

Bug#408252: jukebox-mercury is not suitable for a stable release

[Brian White]

On 24/01/07 at 11:05 -0500, Brian White wrote:

It's in experimental.  It's not supposed to be considered stable.


No, it's in sarge, etch and sid, according to
http://packages.qa.debian.org/j/jukebox-mercury.html


Hmmm...  Then somebody moved it.  Do you know the steps required to 
remove it?


-- Brian


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

Bug#137967: symlinks: convert relative to absolute

[Brian White]

There's a problem with the patch.  While it will indeed convert a 
relative path to an absolute one, it will also convert any absolute 
paths it finds in to relative ones.


Attached is an updated patch that avoids this.

  Brian
  ( [EMAIL PROTECTED] )

---
The only bad mistakes are those you fail to learn from.
--- symlinks-1.2.orig/symlinks.8
+++ symlinks-1.2/symlinks.8
@@ -26,7 +26,10 @@
 .PP
 .B relative
 links are those expressed as paths relative to the directory in which
-the links reside, usually independent of the mount point of the filesystem.
+the links reside, usually independent of the mount point of the
+filesystem.  These are changed when
+.B -a
+is specified.
 .PP
 .B absolute
 links are those given as an absolute path from the root directory
@@ -76,6 +79,21 @@
 links are also shortened.
 Links affected by
 .B -c
+are prefixed with
+.B changed
+in the output.
+.TP
+.I -a
+make absolute links from relative links.  This permits links to remain
+valid when the link itself is moved.  This is especially useful for
+moving directories of links; using
+.B -a
+first, moving the directory, and then using
+.B -c
+restores relative links even if they pointed outside (or above) the
+moved tree.
+Links affected by
+.B -a
 are prefixed with
 .B changed
 in the output.
--- symlinks-1.2.orig/symlinks.c
+++ symlinks-1.2/symlinks.c
--- symlinks.c.orig	2007-01-21 20:55:42.0 -0500
+++ symlinks.c	2007-01-21 21:04:05.0 -0500
@@ -3,6 +3,7 @@
 #define _LARGEFILE64_SOURCE
 
 #include unistd.h
+#include stdlib.h
 #ifndef _POSIX_SOURCE
 #define _POSIX_SOURCE
 #endif
@@ -28,7 +29,7 @@
 
 #define progver %s: scan/change symbolic links - v1.2 - by Mark Lord\n\n
 static char *progname;
-static int verbose = 0, fix_links = 0, recurse = 0, delete = 0, shorten = 0, testing = 0;
+static int verbose = 0, fix_links = 0, recurse = 0, delete = 0, shorten = 0, testing = 0, make_absolute_links = 0;
 
 /*
  * tidypath removes excess slashes and . references from a path string
@@ -155,7 +156,7 @@
 static void fix_symlink (char *path, dev_t my_dev)
 {
 	static char lpath[PATH_MAX], new[PATH_MAX], abspath[PATH_MAX];
-	char *p, *np, *lp, *tail, *msg;
+	char *p, *np, *lp, *tail, *msg = NULL;
 	struct stat stbuf;
 	int c, fix_abs = 0, fix_messy = 0, fix_long = 0;
 
@@ -192,12 +193,16 @@
 	if (stbuf.st_dev != my_dev) {
 		msg = other_fs:;
 	} else if (lpath[0] == '/') {
-		msg = absolute:;
-		fix_abs = 1;
+		if (!make_absolute_links || verbose) {
+			msg = absolute:;
+		}
+		if (!make_absolute_links) {
+			fix_abs = 1;
+		}
 	} else if (verbose) {
 		msg = relative:;
-	} else
-		msg = NULL;
+	}
+
 	fix_messy = tidy_path(strcpy(new,lpath));
 	if (shorten)
 		fix_long = shorten_path(new, path);
@@ -209,7 +214,8 @@
 	}
 	if (msg != NULL)
 		printf(%s %s - %s\n, msg, path, lpath);
-	if (!(fix_links || testing) || !(fix_messy || fix_abs || fix_long))
+
+	if (!(fix_links || testing || make_absolute_links) || !(fix_messy || fix_abs || fix_long || make_absolute_links))
 		return;
 
 	if (fix_abs) {
@@ -238,7 +244,14 @@
 		}
 		strcpy (np, tail);
 		(void) tidy_path(new);
+	} else if (make_absolute_links) {
+		/* turn relative link into an absolute one */
+		if (!realpath(path, new)) {
+			perror(path);
+			return;
+		}
 	}
+
 	if (!testing) {
 		if (unlink (path)) {
 			perror(path);
@@ -291,6 +304,7 @@
 	fprintf(stderr, progver, progname);
 	fprintf(stderr, Usage:\t%s [-crsv] dirlist\n\n, progname);
 	fprintf(stderr, Flags:\t-c == change absolute/messy links to relative\n
+		\t-a == make absolute links from relative\n
 		\t-d == delete dangling links\n
 		\t-r == recurse into subdirs\n
 		\t-s == shorten lengthy links\n
@@ -324,6 +338,7 @@
 			while ((c = *p++)) {
  if (c == 'v')	verbose   = 1;
 else if (c == 'c')	fix_links = 1;
+else if (c == 'a')	make_absolute_links = 1;
 else if (c == 'r')	recurse   = 1;
 else if (c == 'd')	delete= 1;
 else if (c == 's')	shorten   = 1;

Bug#364167: missing sound drivers (were in 2.6.8 but gone in 2.6.17 and above)

[Brian White]

I, too, have noticed that since 2.6.8, some OSS drivers are missing. 
For me specifically, osssolo1.ko is missing and my IBM ThinkPad needs it.


This module is present in 2.6.8 but that version is too old to support 
udev and some other things.


Please include these modules if possible.  Thanks!

  Brian
  ( [EMAIL PROTECTED] )

---
If it weren't for the last minute, nothing would ever get done.


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

Bug#364167: missing sound drivers (were in 2.6.8 but gone in 2.6.17 and above)

[Brian White]

this is an obsolote sound module and oss is superseded by alsa.
there is an equivalent sound driver for your sound card available.
make sure you have the alsa userland installed aka alsa-utils
and run alsaconf it will load the apprioriate sound driver.


Okay, I got it.  It was found and loaded by discover but there was a 
USB webcam that somehow took first position so everything tried to play 
through that.


  Brian
  ( [EMAIL PROTECTED] )

---
If it weren't for the last minute, nothing would ever get done.


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

Bug#403394: conflicts with scrabble

[Brian White]

While installing scribble it creates /usr/games/scrabble symlink which
is also the name of the binary from scrabble package and having the
latter installed on your system it tries to overwrite it.


I don't undestand.  scribble both conflicts and replaces scrabble 
and so should have removed the old package automatically.


  Brian
  ( [EMAIL PROTECTED] )

---
If it weren't for the last minute, nothing would ever get done.


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

Bug#402778: mime-support: add documentation

[Brian White]

I suppose that would be useful, but let me see if I can help you with 
your problem...




Today I will recount my story of trying to get
text/x-wiki
treated as
text/plain
by firefox.


To start, you need to realize that the mime-type is provided by the web 
server in the reply header that proceeds the content data.  Therefore, 
it is up to the server to know that a particular document is of type 
text/x-wiki and send that information to the client (firefox).




I got as far as
$ cat ~/.mime.types
text/x-wiki txt


How the server knows that a particular document is server-dependant.  It 
could be included somewhere in the document contents itself, added in a 
control file like httpd.conf, or determined via the filename itself.


It is this last case that the mime.types file is used.  It defines 
mappings from filename extensions to mime types.


Remember, this is done ON THE SERVER.



(thinking it is like an alias)
which indeed gets read as firefox, but due to a lack of documentation
in /usr/share/doc/mime-support/
and /etc/mime.types
I was not able to proceed further.


In fact, it does not get used by firefox because it, as a client, will 
use whatever mime-type was sent by the server.  Yes, firefox may read 
that file, but it is not used when processing fetched documents.


On the client, it is the /etc/mailcap (or ~/.mailcap) file that defines 
how to operate based on a files mime-type.  Do man mailcap for more 
information (that one is part of the mime-support package).




One indeed finds /usr/share/man/man5/mime.types.5.gz, belonging to a
totally different package.


Interesting.  Can you tell me which one and I'll look at moving it over 
to the mime-support package?




OK, never mind. It will forever remain a mystery. I now use WWWOFFLE's
CensorHeader
{
 http://*/*?*action=rawContent-Type=text/plain; charset=utf-8
}


WWWOFFLE is an http proxy and thus is able to make adjustments to the 
reply header sent by the web server to the client.


  Brian
  ( [EMAIL PROTECTED] )

---
 Don't marry someone you can live with.  Marry someone you can't live 
without.



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

Bug#311046: scrabble: unable to place word

[Brian White]

Actually, here's a sample (run in level 1) with two attempted words
that fail, then one that succeeds.  (Excuse the line wrapping, gpm
joins if column 80 is filled and not if not.)


Okay, got it.  There is a rule that won't allow more than one blank 
within the first three letters in order to reduce the search time for 
computer play.  However, a bug made it that if a blank was used in the 
first three letters, then no other blanks were allowed anywhere.


I've fixed this and removed the in the first three letters restriction 
for the player.


It's going to take a few days to get this changed on the Debian servers 
since I also need to rename the package to avoid trademark infringement. 
 The new package is scribble.


Oh, and remind me...  Never play scrabble against you!  (Your words are 
too good.)


  Brian
  ( [EMAIL PROTECTED] )

---
 Don't marry someone you can live with.  Marry someone you can't live 
without.



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

Bug#340504: mime-support: mailcap.order should consider Provides:

[Brian White]

severity 340504 wishlist
tags 340504 wontfix
--

I agree this would be nice, but it would require knowledge of the 
packaging system that is not within it's scope.  Sorry.


  Brian
  ( [EMAIL PROTECTED] )

---
 Don't marry someone you can live with.  Marry someone you can't live 
without.



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

Bug#311046: scrabble: unable to place word

[Brian White]

Sorry for the long delay getting to this...

If you encounter it again, give a command of debug and then try the 
play again.  That should give me enough info to track down the problem. 
 Just ender debug again to turn it off.


That sucks, though, getting a 7-letter word rejected!

  Brian
  ( [EMAIL PROTECTED] )

---
 Don't marry someone you can live with.  Marry someone you can't live 
without.



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

Bug#400701: cyrdeliver: ignores -q option

[Brian White]

# Deliver to local cyrus IMAP server via LMTP
cyrus:
  debug_print = T: cyrus for [EMAIL PROTECTED]
  driver = lmtp
  delivery_date_add
  envelope_to_add
  return_path_add
  user = cyrus
  socket =  /var/run/cyrus/socket/lmtp
  batch_max = 40


I've found this doesn't work for me.  It keeps trying to access my 
user's (dummy) home directories which aren't accessible from that host.


2006-11-28 16:11:31 1GpAEl-0008Uj-2P == [EMAIL PROTECTED] 
[EMAIL PROTECTED] R=local_user T=cyrus_delivery defer (2): No such 
file or directory: failed to chdir to /home/kodiak/bcwhite


  Brian
 ( [EMAIL PROTECTED] )

---
 ... was no trading on the NYSE today; everybody was happy with what 
they had.



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

Bug#400701: cyrdeliver: ignores -q option

[Brian White]

Package: cyrus-imapd-2.2
Version: 2.2.13-9

I've just upgrade from the cryus package in stable and have the 
following deliver rule in my exim4 configuration:


# This transport uses cyrus for mail delivery
cyrus_delivery:
  driver = lmtp
  command = /usr/sbin/cyrdeliver -l -q ${local_part}
  user = cyrus
  home_directory = /tmp
  return_path_add
  envelope_to_add
  delivery_date_add

I've passed the -q option to cyrdeliver so it will deliver even if 
over quota.  However, the log shows it failing for just that reason:


Nov 27 22:41:56 kodiak cyrus/lmtpunix[21564]: accepted connection
Nov 27 22:41:56 kodiak cyrus/lmtpunix[21564]: lmtp connection preauth'd 
as postman
Nov 27 22:41:56 kodiak cyrus/lmtpunix[21564]: verify_user(user.fschafer) 
failed: Over quota


  Brian
  ( [EMAIL PROTECTED] )

---
 ... was no trading on the NYSE today; everybody was happy with what 
they had.



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

Bug#325441: remove from debian

[Brian White]

Brian said that he was going to rename it, but that was a year ago.
Unless there's some plan to fix it RSN, I think we should remove it from
the archive in the meantime.


I tried to rename it but it was rejected as being a new package and I 
just haven't had the time/will/desire to follow through.


  Brian
  ( [EMAIL PROTECTED] )

---
When you love someone, you're always insecure.  (Tell Her About It -- 
B.Joel)



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

Bug#388597: upgrade didn't preserve all kernel parameters

[Brian White]

Package: kernel-image-2.6.8-3-686
Version: 2.6.8-16sarge4

Upon upgrading this package to the latest (the first upgrade since the 
machine was built), it lost the pci=conf1 parameter passed to the 
kernel via grub.  Other parameters, like noapic were preserved.


Here is the grub menu entry:

title   Debian GNU/Linux, kernel 2.6.8-3-686
root(hd0,1)
kernel  /boot/vmlinuz-2.6.8-3-686 root=/dev/hda2 ro noapic pci=conf1
initrd  /boot/initrd.img-2.6.8-3-686
savedefault
boot

  Brian
 ( [EMAIL PROTECTED] )

---
In the confrontation between the stream and the rock, the stream always
wins...  not through strength, but through persistence.


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

Bug#388597: upgrade didn't preserve all kernel parameters

[Brian White]

Upon upgrading this package to the latest (the first upgrade since the machine was built), it lost the pci=conf1 parameter passed to the kernel via 
grub.  Other parameters, like noapic were preserved.


grub in sarge has a strange method of configuration where you make
your changes in the commented-out portion of the config file and
update-grub uses these settings when it regenerates this file when
called after kernel upgrade.

This should be described somewhere in your grub documentation (I
learned about it in an old HOWTO on the web, but my links to it are no
longer valid). Please verify that this is indeed the problem and reply
to this bug report.

For now, I'll reassign to the grub package since the kernel package is
not responsible for these settings.


Oddly, it preserved them when it was first installed.  I had to add the 
pci=conf1 during the initial install (from CD) to get anything to 
work.  The parameter was there when grub was first installed.


  Brian
 ( [EMAIL PROTECTED] )

---
  It takes months to find a customer and seconds to lose one.


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

Bug#387262: mime-support: RTF isn't really a text format

[Brian White]

RTF format, tough a textual format, is not really readable as text (just
like PostScript is not very readable). mime.types should rather only
provide:

application/rtf rtf


Do you know of an official page specifying this?

  Brian
  ( [EMAIL PROTECTED] )

---
   Touch passion when it comes your way.  It's rare enough as it is.
   Don't walk away when it calls you by name.  -- Marcus (Babylon 5)


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

Bug#355627: passing the filename to shell via environment variable

[Brian White]

The name alias occurs because said file has shell meta characters in it, 
specifically, the .  Since according to the RFC, all commands from 
the mailcap file are to be passed to /bin/sh, including shell 
meta-characters in the filename can cause problems.


Imagine trying to open a file named such:

picture; rm -rf / .jpg


btw, filenames cannot contain slashes, at least on systems where slashes are
used as pathname separators :)


Okay...  .. or ~, then.  Besides, said file doesn't have to actually 
exist; you just have to substitute said filename in the command. 
Imagine a web browser that tries to save the file but doesn't check 
whether it was successful or not before calling the command on that 
file.  Or an email program that tries to be too smart and will create a 
picture; rm -rf  directory with a  .jpg file.


When it comes to security, never trust what you don't absolutely have to.


You would end up trying to erase every file on your system.  Thus, 
mime-support creates an alias for any files with such characters.


The first thought of an alternative would be to simply escape the 
meta-characters so the shell doesn't try to interpret them. 
Unfortunately, the RFC did not address this issue but did state that the 
command must be run exactly as-is with the needed substitutions. Thus, 
quoting meta-characters may not work in all cases


image/jpeg: xv %f   would be okay
but image/jpeg: xv '%f' would be wrong

In the latter case, the \ quoting would be considered part of the 
filename and said file would not be found.


Sorry, but there is no easy (or hard, for that matter) fix for this. 
Best if you don't include such characters in your filenames.


I've looked at this problem and it looks that if '%s' is provided within the
mailcap file, the filename won't get substitued even if containg
metacharacters. That's probably why all of records in my current mailcap
call '%s' instead of %s which would be imho a bug in them, not in
run-mailcap.


Actually, the update-mime program that creates the mailcap file will 
add quotes around the %s if not already there, just as a safety 
precaution.  This makes no difference to the run-mailcap tool but may 
offer some additional protection to other programs that use their own, 
less vigilant, code.


Always do security in layers.



I think that run-mailcap could check if the filename is provided as '%s' and
if so, not to use temporary name but provide the filename directly.


It could, but how do you _guarantee_ that it won't be interpreted by the 
shell?  What about a rule


image/jpeg: xv ''%s''   (pairs of single quotes)

Now the single-quotes cancel out when passed to the shell.  True, a rule 
like this shouldn't exist, but it illustrates the point.  The mailcap 
file is outside of the control of a mime-aware program and so should be 
granted only limited trust.




.. It's not always possible not to use filenames, especially when accessing
remore read-only filesystems :)


That is why run-mailcap creates a temporary symlink to the oddly named 
file and uses that.


  Brian
 ( [EMAIL PROTECTED] )

---
 Successful people do the things unsuccessful people don't want to do.


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

Bug#195716: Fixing Bug Info

[Brian White]

severity 195716 important
--

After watching my external access logs for a while, I saw numerous 
attempts to log in to different accounts with password guessing.  I try 
to keep user passwords pretty secure, but there's always a chance of it 
not being that way or being guessed anyway.


For the time being, I'll remove the ability to log in with only a 
password, but that's not ideal either as I cannot control the strength 
of the pass-phrase attached to an SSH key and it a user's home machine 
were to be breached or his/her laptop stolen, then there is always 
possible access this way.


The only way around this that I can see is to require users to use both 
a public key (can be stored, forwarded, etc.) AND their login password 
(which may be weak but is not stored).


  Brian
 ( [EMAIL PROTECTED] )

---
Treat someone as they are and they will remain that way.  Treat someone
 as they can be and they will become that way.


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

Bug#352644: no longer a problem?

[Brian White]

Since upgrading a few components on my system, I no longer encounter 
this problem.


exim4:  4.62-2
sa-exim:4.2.1-2
spamassassin:   3.1.1-1

  Brian
 ( [EMAIL PROTECTED] )

---
Treat someone as they are and they will remain that way.  Treat someone
 as they can be and they will become that way.


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

Bug#378072: newer kernels don't find secondary IDE controller during boot

[Brian White]

Package: linux-image-2.6.17-1-686
Version: 2.6.17-2

I cannot get my system to come up with the 2.6.17 kernel.  It starts
fine, but is unable to find drive hde,hdf,hdg, and hdh.  These are all
drives connected to a second IDE controller, a Promise PDC20268
(Ultra100 TX2).

The 2.6.15 kernel also had this problem.  2.6.12 works fine.

The PCI scan seems to find it, but apparently the module for it does not
get loaded.  I've been unable to figure out why, but I'm working on it.

I've checked the kernel configs and the only PDC202 difference I see is
that CONFIG_PDC202XX_FORCE=y was present in 2.6.12 but missing in
2.6.17.  Comparing the source code of the two driver versions, it
appears that FORCE=y is the only way it operates.

Attached are the dmesg outputs of the 2.6.12 and 2.6.17 kernels.  There 
are several differences, but the missing PDC20268 lines in the 2.6.17 
output is the most notable.


lspci -v under 2.6.12 gives:

:02:0a.0 Unknown mass storage controller: Promise Technology, Inc. 
PDC20268 (Ultra100 TX2) (rev 02) (prog-if 85)

Subsystem: Promise Technology, Inc. Ultra100TX2
Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 177
I/O ports at dfe0 [size=8]
I/O ports at dfac [size=4]
I/O ports at dfa0 [size=8]
I/O ports at dfa8 [size=4]
I/O ports at df90 [size=16]
Memory at feaf4000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at feae [disabled] [size=16K]
Capabilities: available only to root

I can't run lspci under 2.6.17 because the system won't boot that far.

Let me know if there is any more information I can provide.  I'll keep 
working on it, too.


  Brian
  ( [EMAIL PROTECTED] )

---
  For children, the road to happiness and success is usually paved by
example.

Linux version 2.6.12-1-686 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 
(prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:52:50 JST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e8000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffb (usable)
 BIOS-e820: 7ffb - 7ffc (ACPI data)
 BIOS-e820: 7ffc - 7fff (ACPI NVS)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: ffb8 - 0001 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 524208
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 294832 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v002 ACPIAM) @ 0x000fad80
ACPI: XSDT (v001 A M I  OEMXSDT  0x02000425 MSFT 0x0097) @ 0x7ffb0100
ACPI: FADT (v003 A M I  OEMFACP  0x02000425 MSFT 0x0097) @ 0x7ffb0290
ACPI: MADT (v001 A M I  OEMAPIC  0x02000425 MSFT 0x0097) @ 0x7ffb0390
ACPI: OEMB (v001 A M I  OEMBIOS  0x02000425 MSFT 0x0097) @ 0x7ffc0040
ACPI: DSDT (v001  A0030 A0030006 0x0006 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
WARNING: NR_CPUS limit of 1 reached.  Processor ignored.
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 8000:7fb8)
Built 1 zonelists
Kernel command line: root=/dev/hda1
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2799.216 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2070620k/2096832k available (1701k kernel code, 24888k reserved, 712k 
data, 180k init, 1179328k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5554.17 BogoMIPS (lpj=2777088)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff    041d 
 
CPU: After vendor identify, caps: bfebfbff  

Bug#365348: kmail: IMAP-SSL fails with connection to server is broken

[Brian White]

Okay...  It is reproducable because I just ran in to the same problem.

Package: kmail
Version: 4:3.3.2-3

This is from the stable distribution.

I believe my problem to be that it is not honoring the port setting. 
I have it set to 993 for IMAPS but tcpdump shows that connection 
attempts are still going to port 143 (imap2).


  Brian
 ( [EMAIL PROTECTED] )

---
Treat someone as they are and they will remain that way.  Treat someone
 as they can be and they will become that way.


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

Bug#352644: exim4-daemon-heavy: calls local_scan() with O_WRONLY|O_APPEND fd causing EBADF in read()

[Brian White]

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352644

Was there ever a resolution to this? 


Not that I am aware of. Unfortunately, upstream's handling of issue
reports in the content scanning code is a little bit suboptimal in the
last months.


Is there a way I can contribute directly to the upstream bug report? 
Pretty much the only spam getting in these days is because of these 
failures.


  Brian
 ( [EMAIL PROTECTED] )

---
Treat someone as they are and they will remain that way.  Treat someone
 as they can be and they will become that way.


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

Bug#352644: exim4-daemon-heavy: calls local_scan() with O_WRONLY|O_APPEND fd causing EBADF in read()

[Brian White]

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352644

Was there ever a resolution to this?  I'm encountering the same log 
messages on a new server installation (exim 4.50-8sarge2).


I have not verified that the flags are incorrect.

  Brian
 ( [EMAIL PROTECTED] )

---
   I am Homer of Borg.  Resistance is futi...  M, donuts!


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

Bug#373831: shorewall: won't forward back on same interface

[Brian White]

Package: shorewall
Version: 3.0.5-1

When shorewall sets up the forwarding rules for loc interfaces, it 
omits a rules for forwarding back out the interface on which it arrives.


Chain eth1_fwd (1 references)
 pkts bytes target prot opt in out source 
destination
 1219 73105 dynamicall  --  *  *   0.0.0.0/0 
0.0.0.0/0   state INVALID,NEW
 1219 73105 smurfs all  --  *  *   0.0.0.0/0 
0.0.0.0/0   state INVALID,NEW
 1212 72720 tcpflags   tcp  --  *  *   0.0.0.0/0 
0.0.0.0/0
8   445 lab2netall  --  *  eth00.0.0.0/0 
0.0.0.0/0
0 0 lab2laball  --  *  eth20.0.0.0/0 
0.0.0.0/0
0 0 lab2laball  --  *  eth30.0.0.0/0 
0.0.0.0/0
0 0 lab2laball  --  *  eth40.0.0.0/0 
0.0.0.0/0


Notice that there is no lab2lab for eth1 in this eth1_fwd chain. 
For most situations, this would be just fine as no traffic for that 
subnet should be routed through this firewall.


However, if there is a DNAT rule for the firewall address that rewrites 
the destination to an address on eth1, then those modified packets get 
rejected by the eth1_forward rule if the source is also on that subnet.


I searched the Shorewall documentation but couldn't find any mention of 
how to work around this sort of problem.


Could shorewall be modified to include this rule?  I can't see how it 
would cause any harm to include rules for forwarding back out the same 
interface it came in and it would help special cases like mine.


Thanks!

  Brian
 ( [EMAIL PROTECTED] )

---
We seldom regret doing things.  We often regret not doing them.


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

Bug#372133: cups: can't print test-page when not accepting jobs

[Brian White]

Package: cupsys
Version: 1.1.23-10sarge1

I'm unable to print a test page when a printer is currently set to 
reject jobs.


Since it is reasonable to expect a printer might be set to reject all 
jobs until such time as it can be verified, and printing a test page is 
one step in that verification, it would be useful to have test pages 
ignore that setting.


  Brian
 ( [EMAIL PROTECTED] )

---
 ... was no trading on the NYSE today; everybody was happy with what 
they had.



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

Bug#370714: exim4: seems to always require auth

[Brian White]

Package: exim4
Version: 4.50-8sarge2

The default config for exim4 includes this:

remote_smtp_smarthost:
  debug_print = T: remote_smtp_smarthost for [EMAIL PROTECTED]
  driver = smtp
  hosts_try_auth = ${if exists {CONFDIR/passwd.client}{DCsmarthost}{}}
  tls_tempfail_tryclear = false

However, if no password has been set, the passwd.client file still 
exists and all access to the smarthost fails because it can't auth and 
won't try without it.


  Brian
 ( [EMAIL PROTECTED] )

---
Everything that can be invented already has been.  --U.S. Patent 
Office, 1899



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

Bug#370714: passwd.client file

[Brian White]

One simple solution may be to just rename the passwd.client file in 
the exim4-config package to passwd.client-example.


  Brian
 ( [EMAIL PROTECTED] )

---
If it doesn't work, force it.  If it breaks, it needed replacing 
anyway.



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

Bug#370714: exim4: seems to always require auth

[Brian White]

reopen 370714
--

Perhaps this is an invalid bug, but it would be nice to await my 
clarification _before_ simply closing it.



remote_smtp_smarthost:
 debug_print = T: remote_smtp_smarthost for [EMAIL PROTECTED]
 driver = smtp
 hosts_try_auth = ${if exists {CONFDIR/passwd.client}{DCsmarthost}{}}
 tls_tempfail_tryclear = false

However, if no password has been set, the passwd.client file still 
exists and all access to the smarthost fails because it can't auth and 
won't try without it.



|++
||hosts_try_auth|Use: smtp|Type: host list*|Default: unset|
|++
|
|This option provides a list of servers to which, provided they
|announce authentication support, Exim will attempt to authenticate as
|a client when it connects. If authentication fails, Exim will try to
|transfer the message unauthenticated. See also hosts_require_auth, and
|chapter 33 for details of authentication.

Please note if authentication fails, exim will try to transfer the
message unauthenticated.

If you still think this is wrong, please show an example of a message
transmission failing and outline a way to fix the issue.


The problem is when used in conjunction with the next line:

tls_tempfail_tryclear = false

When both were set (and no password available in the file), the system 
would just sit forever waiting.  I'm not exactly sure what it was 
waiting for (I didn't do a TCP-level trace), but removing either line 
caused it to start working again.


I suggest not having the passwd.client file exist unless there is 
actually something to put in it.


Perhaps it would be best to have tryclear = true in all cases. 
Setting a password for one smarthost could cause others to stop working.


  Brian
 ( [EMAIL PROTECTED] )

---
The only bad mistakes are those you fail to learn from.


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

Bug#370550: slapd.conf: support for shadow password aging

[Brian White]

Package: slapd
Version: 2.2.23-8
Severity: minor

In order for password aging to work with LDAP, a user has to be able to 
both read and change the shadowLastChange field in their user object.


I suggest the following be included in the default slapd.conf file, 
possibly commented-out by default.


 access to attrs=shadowLastChange
by dn=cn=admin,dc=example,dc=com write
by self write
by * read

It seems it should be possible to just add this field to the attrs list 
(after userPassword) that limits access to reading the password, but 
it doesn't work there for some reason I don't understand.


  Brian
 ( [EMAIL PROTECTED] )

---
 We've all had bad experiences, but there is no such thing as bad 
experience.



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

Bug#369701: networking restart: doesn't kill dhclient processes

[Brian White]

Package: netbase
Version: 4.21

If an interface configuration in /etc/networking/intefaces changes from 
dhcp to static and /etc/init.d/networking restart is done, the 
dhclient process monitoring that interface is not aborted.  Thus, next 
time it does a refresh it will overwrite the static info and once again 
use a dhcp address.


  Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.


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

Bug#369563: cups: won't delete jobs with AuthType Group

[Brian White]

Package: cupsys
Version: 1.1.23-10sarge1

I've been trying to get CUPS to allow cancelling of jobs via the web 
interface.  The browser would get an client-error-forbidden error and 
the log would show


  cancel_job user not authorized to delete job id ## owned by other

I tried using:

Location /jobs
AuthType Basic
AuthClass Group
AuthGroupName admin
Order Deny,Allow
Deny From All
Allow From 127.0.0.0/24
Allow From 10.0.1.2/16
/Location

But it didn't work.  I could see the jobs but not cancel them.  So I 
switched to the following...



Location /jobs
AuthType Basic
AuthClass System
Order Deny,Allow
Deny From All
Allow From 127.0.0.0/24
Allow From 10.0.1.2/16
/Location

And that worked.  Only AuthClass System will honor the admin group.

  Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.


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

Bug#368488: tmpreaper: extended config

[Brian White]

Package: tmpreaper
Version: 1.6.5
Severity: wishlist

I'd like to see TmpReaper extended to be more versatile.

1) Allow different time checks for different directories: It's 
concievable that I would want files in /var/tmp to live longer than 
those in /tmp.


2) Allow both atime and mtime checks: This would allow me to delete 
files that have not been modified in 7 days OR accessed in 3 days.


I know I should stop complaining and write some code, and I may do 
that.  I post it here for tracking.


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#368369: dhcpd3: signal to push all known host info to ddns

[Brian White]

Package: dhcp3-server
Version: 3.0.1-2
Severity: wishlist

I'd like to see a signal that can be sent to the dhcp3-server that will 
cause it to immediately send updates about all knows hosts to the 
dynamic dns server.


That would allow quick recovery in the case where the dns server is 
known to have lost all of it's dynamic information.


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.



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

Bug#367648: aptitude: Can't Hold a Package Being Removed Automatically

[Brian White]

Package: aptitude
Version: 0.2.15.9-2
Severity: minor

If a package is about to be removed because it was automatically 
installed but is no longer needed, it is not possible to press : to 
tell aptitude to not do this on this run.


This is important when the package being removed is the running kernel 
(because kernel-image-2.6-686 now depends on a newer version).  I'd like 
to press : to delay the removal of the 2.6.8-2 kernel until the next 
run, after the 2.6.8-3 kernel has been installed on this run.


My only alternative seems to be to press + to install the current 
version and the remember to find and remove it during a later run.


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#367557: Samba Doesn't Log Fatal Errors

[Brian White]

Are you in the position of trying to reproduce it with samba 3.0.22 in
etch?


I'll see what I can do.  Right now I'm still trying to figure out why I 
can't join to it's domain.  sigh  What fun!


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#367507: Samba Documentation Problem

[Brian White]

Package: samba
Version: 3.0.14a-3sarge1
Severity: minor

In the samba man-page for smb.conf, the some of the ldap settings are 
not correct.


It says, for example...

   ldap group suffix (G)
  This  parameters specifies the suffix that is used for
  groups when these are added to the LDAP directory. If this
  parameter is unset, the value of ldap suffix will be used
  instead.

However, it seems the case that this value is prepended to the default 
ldap suffix rather than replacing that value (as would seem to be 
indicated).  The following works for me:


ldap suffix = dc=precidia
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Hosts

  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#367507: Samba Documenation Problem

[Brian White]

Another man-page problem:

   interfaces (G)
  This option allows you to override the default network
  interfaces list that Samba will use for browsing, name
  registration and other  NBT traffic.  By  default  Samba
  will query the kernel for the list of all active
  interfaces and use any interfaces except 127.0.0.1 that
  are broadcast capable.

  The option takes a list of interface strings. Each string
  can be in any of the following forms:

  o  a network interface name (such as eth0). This may
  include shell-like wildcards so eth* will match any
  interface starting with the sub-string eth

This last part implies that all shell wildcards can be used, but that
is not the case.  I tried eth[1-9] and it failed.  If only * or ? 
are supported, then that should be stated explicitly.


Or, it could be improved to use these patterns!

  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#367507: Samba Documenation Problem

[Brian White]

 o  a network interface name (such as eth0). This may
 include shell-like wildcards so eth* will match any
 interface starting with the sub-string eth

This last part implies that all shell wildcards can be used, but that
is not the case.  I tried eth[1-9] and it failed.  If only * or ? 
are supported, then that should be stated explicitly.


Or, it could be improved to use these patterns!


Well, I think that's debatable as the man page doesn't make the
assumption that all shell wildcards are supported.


True, but why mention shell wildcards at all, then.

  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#367557: Samba Doesn't Log Fatal Errors

[Brian White]

Package: samba
Version: 3.0.14a-3sarge1
Severity: minor

While trying to get a samba server set up via ldap, I ran in to the case 
where smbd would apparently start successfully but then exit without any 
messages of any kind and nothing in the log.smbd file.



1) The first problem was I had:

; LDAP settings
ldap admin dn = uid=samba,ou=Services,dc=precidia
ldap suffix = dc=precidia
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Hosts
ldap replication sleep = 1000
ldap password sync = true
ldapsam:trusted = true

This would cause invalid DN errors from the ldap server.  I had to use 
strace and tcpdump to figure out that there shouldn't be any quotes here.



2) The second problem I had was missing sambaSID values in the groups 
in my directory.  Once I added these, the smbd daemon kept running.



Just to reiterate...  These were all mistakes on my part.  My bug 
concerns only that samba reported _nothing_ and left me to find these 
problems with tools like strace and tcpdump -- not the most 
user-friendly methods of debugging.


It occurred to me later that I should have increased the logging level. 
 I think fatal errors should always get logged, though.


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#195716: Is this a security bug?

[Brian White]

Just wondering if perhaps this isn't a security level bug instead of 
just a wishlist.


  Brian
 ( [EMAIL PROTECTED] )

---
  Until we are first independent, we cannot be interdependent.


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

Bug#361128: aptitude: show distribution that versions come from

[Brian White]

Package: aptitude
Version: 0.2.15.9-2
Severity: wishlist

When aptitude shows multiple versions available for a package, it would 
be great if it showed where each version came from (i.e. obsolete, 
stable, testing, unstable, etc.).


I use stable primarily with an occasional testing package.  Often, 
when trying to resolve problems, I need to select a specific version and 
I can't tell by just the version number if it's in the list because it 
is what I have installed but no longer exists (obsolete), a new 
security patch (stable) or from the testing distribution (testing).


Thanks!

  Brian
 ( [EMAIL PROTECTED] )

---
   According to my calculations, that problem doesn't exist.


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

Bug#349745: squid-prefetch: Crashes every few minutes

[Brian White]

I now stays up thanks, though I can't work out how to
be sure it's doing anything since it doesn't have a log file.


Check out Squid's log file.  Accesses from 127.0.0.1 will be from the 
prefetch.


  Brian
  ( [EMAIL PROTECTED] )

---
Idleness, indifference  irresponsibility are healthy responses to 
absurd work.



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

Bug#349745: squid-prefetch: Crashes every few minutes

[Brian White]

Not necessarily. 127.0.0.1 is the network loopback device, so *any*
program on that machine which accesses the outside world via squid
will show as 127.0.0.1 in the squid log, not just squid-prefetch as you
imply.


True.  I don't use the loopback interface for connecting to squid from 
user clients, so I don't have that ambiguity.


You can usually differentiate between clients and squid-prefetch by the 
log line itself.  The first access by squid-prefetch will always be a 
TCP_HIT/200 or TCP_MISS/504 (I think it's 504).  After that will be the 
prefetches.


Or... just run it from the command line so you can see STDOUT.

  Brian
  ( [EMAIL PROTECTED] )

---
 There's no healthy way to mess with the line between wrong and right.
oel)


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

Bug#355894: [Ticket#1001673] Bug#355894: mime-support: Enhancement of update-mime

[Brian White]

If /etc/update-mime.conf doesn't exist, our modified version should behave
just like the original one does. We just didn't want to drop files into
/usr/lib/mime/packages, but NFS mount them.


Oh...  I misunderstood.  I thought you were talking about where to look 
for mailcap and mime.types files.


  Brian
 ( [EMAIL PROTECTED] )

---
  Integrity is one of several paths.  It distinguishes itself from the 
others
  because it is the right path, and the only one upon which you will 
never get

 lost.  -- M.H. McKee


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

Bug#355894: mime-support: Enhancement of update-mime

[Brian White]

We're using Sarge for our workstations and we had to import several 
programs via nfs. These programs also use mime files and we had to patch 
update mime to look in these directories too.


We created a generalized version that uses a simple config file with the 
directories we're looking at.


I have nothing against the idea, but I'm worried about the potential 
incompatibility.  Many programs don't use run-mailcap to decide what 
program to use.  Thus, they might choose a different program than mine.


  Brian
  ( [EMAIL PROTECTED] )

---
Seize the moment!  Live now.  Make now always the most important time. 
-- JLP



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

Bug#355627: Local filename treated as non-local

[Brian White]

tag 355627 wontfix
--

The name alias occurs because said file has shell meta characters in it, 
specifically, the .  Since according to the RFC, all commands from 
the mailcap file are to be passed to /bin/sh, including shell 
meta-characters in the filename can cause problems.


Imagine trying to open a file named such:

picture; rm -rf / .jpg

You would end up trying to erase every file on your system.  Thus, 
mime-support creates an alias for any files with such characters.


The first thought of an alternative would be to simply escape the 
meta-characters so the shell doesn't try to interpret them. 
Unfortunately, the RFC did not address this issue but did state that the 
command must be run exactly as-is with the needed substitutions.  Thus, 
quoting meta-characters may not work in all cases


image/jpeg: xv %f   would be okay
but image/jpeg: xv '%f' would be wrong

In the latter case, the \ quoting would be considered part of the 
filename and said file would not be found.


Sorry, but there is no easy (or hard, for that matter) fix for this. 
Best if you don't include such characters in your filenames.


  Brian
  ( [EMAIL PROTECTED] )

---
It seems that anything people have learned prior to puberty takes 
on the
  status of an immutable truth (this is something well understood by 
parents,

governments, and religions). Rational explanations of why some previous
belief might be incompatible with the behavior of nature, and a careful
   explanation of the actual behavior of nature are of little avail.


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

Bug#355882: mdadm: more information in report

[Brian White]

Package: mdadm
Version: 1.9.0-4sarge1
Severity: wishlist

When mdadm reports a DegradedArray event (or any other event) via 
email, it would be beneficial to include the contents of /proc/mdstat as 
well.


  Brian
 ( [EMAIL PROTECTED] )

---
 ... was no trading on the NYSE today; everybody was happy with what 
they had.



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

Bug#351243: xargs: option to use \n as separator

[Brian White]

Package: findutils
Version: 4.1.20-6
Severity: wishlist

It would be useful to have an option in xargs that specifies that the 
filename separator is a linefeed (or an option to specify any arbitrary 
separotor).


This would be really useful with find where filenames have spaces.  I 
know that you can use -print0 and -0 like this


  find / -name *find* -print0 | xargs -0 command

but that doesn't allow for more extended pipelines.  There is no way to 
process the find output with other commands.  This won't work:


  find / -name *find* -print0 | grep -v baddir | xargs -0 command

Thanks!

  Brian
 ( [EMAIL PROTECTED] )

---
 ... was no trading on the NYSE today; everybody was happy with what 
they had.



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

Bug#351243: xargs: option to use \n as separator

[Brian White]

 find / -name *find* -print0 | grep -v baddir | xargs -0 command


[...]

/me points to grep's -z and -Z option


True, but you get the point.  There are many command that could be in 
that pipe: sed, sort, etc.




There is also the possibility to plug in tr in between:

find ... -print | do someting | do something ... \
   tr '\n' '\0' \
   xargs -0 command


Good tip.



I'd strongly advise against this hack (actually any use of xargs
without -n) on untrusted directories as it will break dangerously
with filenames containing newline.

[EMAIL PROTECTED]:/tmp/test$ mkdir 'foo


'


[EMAIL PROTECTED]:/tmp/test$ mkdir 'foo
'/etc
[EMAIL PROTECTED]:/tmp/test$ echo blah  'foo
/etc'/passwd
[EMAIL PROTECTED]:/tmp/test$ find
.
./foo?
./foo?/etc
./foo?/etc/passwd
[EMAIL PROTECTED]:/tmp/test$ find -type f -print | xargs ls -l
ls: ./foo: No such file or directory
-rw-r--r--  1 root root 1201 Jan 22 11:16 /etc/passwd


An interesting example.  Isn't security wonderful?  However, in 
non-security related matters, having spaces is quite common while having 
newlines is extremely rare.


  Brian
 ( [EMAIL PROTECTED] )

---
  Do, or do not.  There is no try.  -- Yoda


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

Bug#350134: mime-support: It is trying to use some not-installed programs for some mime-types

[Brian White]

And take a look at this:
~$ see --debug=10 elen7b.doc 
 - parsing parameter elen7b.doc

 - Reading mime.types file /home/emil/.mime.types...
 - Reading mime.types file /etc/mime.types...
 - extension doc maps to mime-type application/msword
 - Reading mailcap file /home/emil/.mailcap...
 - Reading mailcap file /etc/mailcap...
Processing file elen7b.doc of type application/msword (encoding=none)...
 - checking mailcap entry application/msword; wvMime '%s'; copiousoutput; 
description=Microsoft Word Document; test=test -n $DISPLAY; print=wvWare --nographics 
-x /usr/share/wv/wvHtml.xml '%s' | lynx -dump -force_html -nolist /dev/stdin | print 
text/plain:-
 - program to execute: wvMime '%s'
 - running test: test -n $DISPLAY  (result=0=true)
 - executing: wvMime 'elen7b.doc' | /usr/bin/see --action=view text/plain:-


Some package other than mime-support has installed this rule.  Try

  grep wvMime /usr/lib/mime/packages/*

Then reassign this bug against that package.



And I dont have crappy lynx. Why the hell it is trying to use not installed
programs for displaying this *.doc


It shouldn't be calling lynx.  It should instead pipe it to

print text/html:-

and let that rule determine how to convert text/html to text/plain for 
printing.


  Brian
  ( [EMAIL PROTECTED] )

---
A bend in the road is not the end of the road unless you fail to make 
the turn.



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