Bug#1061118: debram: The debram binary is missing from the package.

[Thaddeus H. Black]

John:

Thanks for your notice.  Few even remember the debram
package any longer.  I don't recall the last time
someone emailed me about it!

Most of what used to be the debram package is obsolete,
except that there is a data file in debram-data I
believe some still find useful.  The existing
debram(1) *executable* serves no current, useful
purpose, so I removed it years ago.

The debram(1) executable could be rewritten and readded
to the debram package, if I (or anyone else) ever got
around to doing it.  Meanwhile, the debram package
remains in limbo.  It isn't hurting anything that I
know, installing debram is harmless, and debram-data
remains useful; so other than by suppressing the
executable, I haven't done anything about debram.

If this state of affairs is causing a specific,
significant problem for you or other users, let me know
and I'll see when I can find time to do something about
it; or, if I'm too slow, then you or someone else
can NMU with my blessing.  If you want my advice,
though, I suspect that the effort may not be worth your
time.  The worst that can be said about debram in its
present state is that it isn't doing anything; the best
is that it holds a place for a redesigned debram(1)
executable that might (or might not) someday be
reintroduced.

> * What led up to the situation?

Enrico Zini's debtags suite came to duplicate the
functionality of debram(1) nearly enough that
for Debian contributors to work on both debram and
debtags at the same time no longer seemed worthwhile,
for the time being.

> * What exactly did you do (or not do) that was
>   effective (or ineffective)?

Everything was effective as far as I know.  The debram
package works as intended.

> * What was the outcome of this action?

1. The obsolete executable has been suppressed.
   The executable is neither built nor installed.
2. The dependency debram-data, which is not obsolete,
   continues to be autoinstalled.
3. The debram binary package remains as a placeholder
   in which a revised executable could be reintroduced.

> * What outcome did you expect instead?

The same.

If you emailed me again, I'd be glad to hear from you,
but don't expect a speedy reply!  As I said, if you
wish to NMU and feel that it's worth your time, then
you have my blessing.

I appreciate the notice.  Good luck.


signature.asc
Description: PGP signature

Bug#1000372: ITP: ocaml-magic-mime -- OCaml library to map filenames to common MIME types

[Thaddeus H. Black]

On Mon, Nov 22, 2021 at 09:55:52AM +0100, Stéphane Glondu wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stéphane Glondu 
> X-Debbugs-Cc: debian-de...@lists.debian.org, 
> debian-ocaml-ma...@lists.debian.org
> 
> * Package name: ocaml-magic-mime
>   Version : 1.2.0
>   Upstream Author : Anil Madhavapeddy
> * URL : https://github.com/mirage/ocaml-magic-mime
> * License : ISC
>   Programming Lang: OCaml
>   Description : OCaml library to map filenames to common MIME types
> 
>  This library contains a database of MIME types that maps filename
>  extensions into MIME types suitable for use in many Internet
>  protocols such as HTTP or e-mail. It is generated from the mime.types
>  file found in Unix systems, but has no dependency on a filesystem
>  since it includes the contents of the database as an ML
>  datastructure.
> 
> This is a new transitive dependency of ocsigenserver.

A typical Debian system already has two such
databases: /etc/mime.types /usr/share/mime/globs

I do not mean to challenge you, nor to discourage you,
but am merely curious:  why a third database?


signature.asc
Description: PGP signature

Bug#999837: ITP: merecat -- simple web server with only basic features

[Thaddeus H. Black]

On Wed, Nov 17, 2021 at 01:54:20PM +0100, Joost van Baal-Ilić wrote:
> Package: wnpp
> Owner: Joost van Baal-Ilić 
> Severity: wishlist
> 
> * Package name: merecat
>   Upstream Author : Joachim Wiberg 
> * URL : https://troglobit.com/projects/merecat/
> * License : BSD 2-clause
>   Programming Lang: C
>   Description : simple web server with only basic features
> 
>  Merecat is a simple web server based on Jef Poskanzer's thttpd.
>  It supports all basic features required for most use-cases. The
>  most prominent features are probably HTTPS, using OpenSSL, PHP,
>  multiple servers with HTTP redirect support, redirect from HTTP
>  to HTTPS, virtual hosts, and the URL-traffic-based throttling.
>  .
>  Its small footprint makes it is suitable for small and embedded
>  systems.
> 
> I plan to migrate my personal web servers to merecat, and maintain
> the software using git at https://salsa.debian.org/debian .  Upstream
> also publishes a debian/ directory btw, at their git repo
> at https://github.com/troglobit/merecat ; and I published a first
> shot at packaging at http://mdcc.cx/tmp/merecat/ .

If I ask you how merecat improves upon simple web servers already in
Debian, I do not mean to challenge you, nor to discourage you.  I am
merely curious.

If you don't mind telling me, how *does* merecat improve upon simple
web servers already in Debian?


signature.asc
Description: PGP signature

Bug#999424: ITP: geners -- generic serialization library for C++

[Thaddeus H. Black]

On Wed, Nov 10, 2021 at 09:34:36PM +0100, Pierre Gruet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre Gruet 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: geners
>   Version : 1.12.0
>   Upstream Author : Igor Volobouev
> * URL : https://geners.hepforge.org/
> * License : Expat
>   Programming Lang: C++
>   Description : generic serialization library for C++
> 
> The Generic Serialization library is designed to address the problem of C++
> object persistence in situations where the most typical data access pattern is
> "write once read many" (WORM). "Geners" is a set of tools and conventions
> which allows its users to develop C++ classes that can be converted to and
> from a storable stream of bytes in a well-organized and type-safe manner.
> Serialization of STL containers is supported, including the ones added in the
> C++11 standard. Independent versioning of each class definition is allowed.
> 
> Among others, compared to the boost serialization package, Geners archives
> provide random access to stored objects and can be used to create and
> serialize very large archive-based objects. Yet, only binary archives are
> implemented, and implementing non-intrusive serialization is less transparent.
> 
> I am packaging this software as a dependency of stopt, which is a packaging
> target of mine. I plan to maintain it myself.

That is interesting.  For information, what is stopt, please?
Is it [1], [2], or something else?

1: https://github.com/husk214/stopt/
2: https://github.com/anitan0925/STOPT/



signature.asc
Description: PGP signature

Bug#997798: ITP: dedalus -- Dedalus is a framework for solving PDEs useful for astrophysical and geophysical fluid dynamics

[Thaddeus H. Black]

Usually not available for immediate reply, I was online when your
email arrived.

On Sat, Nov 06, 2021 at 09:09:17AM -0700, Mac Lee wrote:
> I haven't gotten a sponsor yet. Could you be my sponsor?

I would be glad.

I'll have to review your package when it's ready.  A package that works
on your own machine is a starting point; but in most cases, several
changes are required to polish a private package up to Debian's usual
level for general distribution.  My sponsor, Giacomo Catenazzi, guided
me to make such changes to my first package when he sponsored me
in 2004, so I am to do likewise for you.

I am not a prolific sponsor, having done it only once, and that over a
decade ago, so I'll be a bit rusty on the procedure; but you and I will
work it out.

Meanwhile, several questions:

1.  Have you already packaged the software as a *.deb that successfully
installs on your own machine?  (If not, then let me know if and how I
can help.)

2.  Have you read or reviewed Debian's New Maintainers' Guide?  (It can
be found among other places in the Developers' corner of the debian.org
web site).  If not then, when you have time, you'll probably want to
do that.

3.  Does your software build and run on bullseye?  On sid?  On both?

4.  Have you already chosen a package builder?  If not, there are two
or three, and you can use whichever you prefer; but for information,
pbuilder is the one with which I happen to be familiar.

5.  Does your software access the display (as via GTK, for example)?

Incidentally, the extent to which to continue to Cc our correspondence
to bugs.debian.org is up to you; but you can drop the Cc at your
discretion if you wish.


signature.asc
Description: PGP signature

Bug#998243: ITP: lg-gpio -- Control GPIO pins via the kernel's gpiochip device interface

[Thaddeus H. Black]

On Mon, Nov 01, 2021 at 02:04:40PM +, Dave Jones wrote:
> * Package name: lg-gpio
[...]
> A request for sponsorship is (possibly prematurely!) open in #990280.

Have you got your sponsor?

I would make a nonideal sponsor, not least because Python happens to
lie mostly outside my domain.  However, GPIO is an interesting subject,
so let me know if I can help.

-- 
Thad Black
Pearisburg, Virginia


signature.asc
Description: PGP signature

Bug#997798: ITP: dedalus -- Dedalus is a framework for solving PDEs useful for astrophysical and geophysical fluid dynamics

[Thaddeus H. Black]

On Mon, Oct 25, 2021 at 03:20:07PM -0700, Mac Lee wrote:
> No I don't have a sponsor yet.

All right.  Since I

  * seldom program in Python,
  * unlike many Debian Developers, do not code for a living, and
  * attend to Debian development admittedly inconsistently,

I might make a suboptimal sponsor; but if no more suitable sponsor
appears then I might be available, to the extent to which a suboptimal
sponsor is better than none.  At least I know a little about spectral
methods, for what that's worth; and I've been a Debian Developer, though
an obscure one, since 2005.

If you like, wait a week or so for a more suitable sponsor and then, if
none appears, at your discretion, let me know how I can help.

Meanwhile, one hadn't expected to encounter a high-performance,
serious-pedigree, heavy-duty MPI numerical code in Python, but rather
in C++ or the like, so this could be interesting.

-- 
Thaddeus H. Black, P.E.
Pearisburg, Virginia


signature.asc
Description: PGP signature

Bug#997798: ITP: dedalus -- Dedalus is a framework for solving PDEs useful for astrophysical and geophysical fluid dynamics

[Thaddeus H. Black]

On Sun, Oct 24, 2021 at 11:42:32AM -0700, Mac Lee wrote:
> * Package name: dedalus
> [...]
> I plan to maintain
> the package as part of the Python team and I am looking for a sponsor
> since this is my very first Debian package.

The project looks interesting.  Have you got a sponsor yet?


signature.asc
Description: PGP signature

Bug#996958: ITP: mumax -- GPU accelerated micromagnetic simulator

[Thaddeus H. Black]

> This sentence was copy/pasted from http://mumax.github.io/. I haven't really
> started working on the package yet, nor am I a regular user.

I see.

> I guess you should ask upstream rather than me, I'm just a poor packager in
> this case :-)

Thanks.


signature.asc
Description: PGP signature

Bug#996958: ITP: mumax -- GPU accelerated micromagnetic simulator

[Thaddeus H. Black]

That's a neat project.

The README.md says:
> if you don't have git:
> 
> *  seriously, no git?

The question is not whether one does not have git, but whether one does
not have CUDA, unfortunately.

> The Design and Verification of mumax3:
> 
> http://scitation.aip.org/content/aip/journal/adva/4/10/10.1063/1.4899186

The hyperlink seems to be paywalled or broken.

You write:
> A speed-up of the order of 100x compared to CPU-based simulations can
> easily be reached

Since I am unable to view the paper, would you briefly, approximately
tell me how you achieved the speed-up?  Alternately, would you link me
to relevant presentation slides, a presentation video, or the like?
Again alternately, would you advise me in which source file one should
look for the core of the main loop, where the 100x speed-up is
implemented?

I ask because I have a simulation that improperly relies on g++'s
optimizer to vectorize the simulation's main loop, the elements
being 64+64 = 128-bit complex doubles.  Even if my loop technique were
not clumsy and 15 years outdated, the optimizer goes only to SSE
hardware, and not (as far as I can tell by reviewing the disassembly)
to the GPU at all.  One could try OpenCL, of course; but without a good
example to follow, I'd probably flounder around six months trying to
figure out how to apply OpenCL intelligently

Anyway, if you believe that your code is a good example, then I'd be
interested to see how you have achieved the 100x.


signature.asc
Description: PGP signature

Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

[Thaddeus H. Black]

On Fri, Sep 10, 2021 at 09:05:34AM +0200, Gerardo Ballabio wrote:
> Diederik de Haas wrote:
> > But then the question becomes: what is the authoritative version?
> 
> Was the Social Contract approved by a General Resolution?
> 
> If so, then the authoritative version is the text that appeared in the
> GR ballot.

Aha.  Good point.

As far as I know, here it is:

https://lists.debian.org/debian-vote/2004/04/msg00038.html


signature.asc
Description: PGP signature

Bug#993486: ITP: mirrorrib -- tool locally to mirror a Debian release, including backports

[Thaddeus H. Black]

Package: wnpp
Severity: wishlist
Owner: "Thaddeus H. Black" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mirrorrib
  Version : 0.14.4
  Upstream Author : Thaddeus H. Black 
* URL : https://www.derivations.org/mirrorrib/
* License : GPL-2
  Programming Lang: Shell (bash)
  Description : tool locally to mirror a Debian release, including backports

Debian releases a major revision of its operating system about every
two years and a minor revision approximately quarterly, but these
revisions exclude Debian backports.  Debian releases backports only on
a rolling basis like sid.

Mirrorrib is for Debian users who want an approximately quarterly,
stable revision of backports to accompany the approximately quarterly,
stable revision of the rest of the operating system -- with both
revisions dated as of the same date.

Mirrorrib reproducibly assembles a stable backports revision and
release to accompany a stable regular revision and release.  It
downloads the matched pair of releases with all their packages and
associated files, mirroring the pair together to your hard drive.
After running Mirrorrib and configuring /etc/apt/sources.list to
access the local repository Mirrorrib has assembled, one no longer
needs a live network connection to update or reinstall one's system to
Debian stable -- not even if the update or reinstallation requires
access to backports.

Mirrorrib's name stands for "MIRROR Release Including Backports."

I will maintain the package.  No sponsor is needed.  Because the
software is Debian-specific and is useful only to users of Debian, the
package is a Debian-native package.

Bug#887139: installation-reports: Debian Installer Bullseye RC 1 damages UEFI setup on Dell Latitude 5510

[Thaddeus H. Black]

Package: installation-reports
Followup-For: Bug #887139

Dear Maintainer,

Paul Gevers has asked subscribers to debian-devel-announce to try out
the debian-installer, so I tried it.

-- Package-specific info:

Boot method: netinst.iso on a USB flash drive
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc1/amd64/iso-cd/debian-bullseye-DI-rc1-amd64-netinst.iso
 as downloaded 2021-05-06 14:00 UTC
Date: 2021-05-06 14:30 UTC

Machine: Dell Latitude 5510 laptop, Intel Comet Lake i7-10610U CPU with 
associated Intel chipset, Intel Wifi, Intel integrated graphics

Partitions: the command "df -Tl" reports the following while *buster* is
running.  Is this information useful, though?  I include it only because
installation-report specifically requests it.
Filesystem  Type  1K-blocks  Used Available Use% Mounted on
udevdevtmpfs   16223268 0  16223268   0% /dev
tmpfs   tmpfs   3247352  9972   3237380   1% /run
/dev/nvme0n1p9  ext4  263174212  17009396 232726660   7% /
tmpfs   tmpfs  16236752 69528  16167224   1% /dev/shm
tmpfs   tmpfs  5120 4  5116   1% /run/lock
tmpfs   tmpfs  16236752 0  16236752   0% /sys/fs/cgroup
/dev/nvme0n1p11 ext4 1254007444 451985672 738251968  38% /arc
/dev/nvme0n1p1  vfat 50790411397904  22% /boot/efi
tmpfs   tmpfs   3247348 12756   3234592   1% /run/user/1000
/dev/sda1   iso9660  369664369664 0 100% /media/thb/Debian 
bullseye-DI-rc1 amd64 n

Partitions: the command "fdisk -l" reports the following. This may be
more informative than the above.  Buster is installed on p9; bullseye,
on p12.
Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: INTEL SSDPEKNW020T9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E40D7C7A-2099-49F3-808B-FB583DFE4C6C
Device   StartEndSectors   Size Type
/dev/nvme0n1p1204810260471024000   500M EFI System
/dev/nvme0n1p2 10260481288191 262144   128M Microsoft reserved
/dev/nvme0n1p3 1288192  774707199  773419008 368.8G Microsoft basic data
/dev/nvme0n1p4  3995934720 39979622392027520   990M Windows recovery 
environment
/dev/nvme0n1p5  3997962240 40007598072797568   1.3G Windows recovery 
environment
/dev/nvme0n1p6   774709245  774709245  1   512B Microsoft basic data
/dev/nvme0n1p7   774709246  774709246  1   512B Microsoft basic data
/dev/nvme0n1p8   774709247  774709247  1   512B Microsoft basic data
/dev/nvme0n1p9   774709248 1311580159  536870912   256G Linux filesystem
/dev/nvme0n1p10 1311580160 1378689023   6710886432G Linux swap
/dev/nvme0n1p11 1378689024 3928825855 2550136832   1.2T Linux filesystem
/dev/nvme0n1p12 3928825856 3995934719   6710886432G Linux filesystem

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [ ]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

The installation went as expected.  Unfortunately, after installation,

* bullseye testing (newly installed) booted normally but
* buster stable (already installed) booted abnormally.

Installation of bullseye on one partition disrupts buster on another
partition.  Insofar as bullseye's installer was not asked by me to touch
buster's partition, I assume that the problem is a UEFI problem.
It may be that bullseye's installer damages UEFI.

Buster still boots, but takes two or three minutes instead of the
usual 20 seconds or so.  Buster's boot stalled so long, I had time to
write down the messages that appeared live on the screen during the
stall (though I cannot promise that I have precisely copied all the
hexidecimal numbers and such):
fsckd-cancel-msg:Press Ctrl-C to cancel all filesystem checks in progress
[35.99] ioremap-errorr for 0x7698-0x76981000, requested 0x2, got 0x0
[some messages about iwlwifi]
[some messages about Plymouth]
[37.99] tpm tpm0: tpm_try_transmit send(): error -62
[37.99] tpm tpm0: [Firmware bug]: TPM interrupt not working, polling instead
[   ***   ] A start job is running for 
/dev/disk/by-uuid/ef70f152-a70a-4d70-8402-a3e2a0c6db90 (59s / 1min 30s)

To emphasize, the above messages appear during a stall when *buster*
boots after *bullseye* is installed.  There is no stall when bullseye
boots.

-- 

The following were generated while buster was running, not bullseye.

==
Installer 

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Thaddeus H. Black]

> I need sponsor.

Have you got your sponsor?


signature.asc
Description: PGP signature

Bug#982341: ITP: simlib -- SIMulation LIBrary for C++

[Thaddeus H. Black]

It looks interesting.  Unfortunately, the description is somewhat hard
to understand.

On Tue, Feb 09, 2021 at 03:03:51AM +0100, Roman Ondráček wrote:
> This library allows you to create models directly in C++ language using
> simulation abstractions and tools from the library.
> SIMLIB allows object-oriented description of continuous, discrete, combined,
> and various experimental (2D/3D vector, fuzzy) models.

Simulation of what?  Abstraction from what?

I am just a random one of 1000 or so Debian Developers, so if I offer a
suggestion, you can regard or ignore as you like.

I gather that the package does some kind of time-domain,
frequency-domain, eigenvalue, integral-equation, or other kind of
mechanical simulation for purpose of checking analyses and for other
purposes.  However, I gather this only because I happen to have done
work of this general kind.

Consider adding a brief introductory sentence that orients the reader to
the *kind* of thing the package is or does.  For example, suppose that
the user were looking for libcairo (to generate 2-D graphics) or
libunbound (to resolve Internet domain names).  Your description's first
line should probably, very briefly, inform the reader that your library
is not the kind of library such a user seeks.

Also consider writing, "C++ library" rather than "library ... in C++,"
at your discretion.  For example, your description *might* begin:

SIMLIB is C++ library that models [foo] using continuous,
discrete and combined techniques.

Or, for less accuracy but more punch:

SIMLIB is C++ library that models continuous, discrete and
combined [foo].

I like that your description is short.



signature.asc
Description: PGP signature

Bug#924166: debram: broken symlink: /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz

[Thaddeus H. Black]

Good notice. I believe that you are right. I don't suppose that this bug is
important enough to bother the release managers about, since the package in
question is used by almost no one, but if not before the release this bug
should be addressed after.

Thank you for the notice. I appreciate it. I do not believe that you and I
have met face to face but I hope that we shall someday meet. I admire your
OpenCL work and would like to discuss that matter further with you sometime.

At any rate, after the release (or before, if you think it important
enough), I will fix that link.


On Sun, Mar 10, 2019 at 12:18 AM Andreas Beckmann  wrote:

> Package: debram
> Version: 2.1.0
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + debram-data
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> >From the attached log (scroll to the bottom...):
>
> 0m19.7s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/debram/HISTORY.gz -> ../debram-data/HISTORY.gz (debram)
>
> The target file does not (any longer) exist.
>
>
> cheers,
>
> Andreas
>

Bug#884476: derivations FTBFS with poppler 0.61.1

[Thaddeus H. Black]

Thank you for the reminder. Poppler is always changing, isn't it?

NMUs are always okay with me, but I assume that you have better things to
do than to NMU an obscure package like my derivations. When I have some
time, I will look into the matter.

I need to update the package to the upstream version sometime, anyway.


On Thu, Dec 28, 2017 at 10:24 AM, Juhani Numminen  wrote:

> Control: tags 884476 upstream
>
> On Fri, 15 Dec 2017 18:59:41 +0200 Adrian Bunk  wrote:
> > Source: derivations
> > Version: 0.53.20120414-2
> > Severity: serious
> > Tags: buster sid
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/
> unstable/amd64/derivations.html
> >
> > ...
> > update_catalog.cc: In function 'int {anonymous}::copy_but(Dict*, Dict*,
> const set&)':
> > update_catalog.cc:39:33: error: no matching function for call to
> 'Dict::getValNF(int&, Object*)'
> >src ->getValNF( i  ,  );
> >  ^
> > In file included from /usr/include/poppler/Object.h:342:0,
> >  from /usr/include/poppler/XRef.h:42,
> >  from /usr/include/poppler/PDFDoc.h:49,
> >  from PDF_rep.h:6,
> >  from update_catalog.cc:12:
> > /usr/include/poppler/Dict.h:85:10: note: candidate: Object
> Dict::getValNF(int) const
> >Object getValNF(int i) const;
> >   ^~~~
>
> Dear Maintainer,
> CCing your derivations.org address since this seems like an "upstream"
> matter.
>
> Looks like there has been a major API change in poppler:
> https://cgit.freedesktop.org/poppler/poppler/commit/?id=9773c1534
>
> I superficially checked the latest derivations source and it isn't updated
> for
> the new API yet.
> http://www.derivations.org/derivations_0.55.20170703.orig.tar.xz
>
>
> Thanks,
> Juhani Numminen
>

Bug#836943: To instruct the bug server to stop emailing Colin Darie re #842472

[Thaddeus H. Black]

Control: owner -1 !

Hopefully, this should be the last email Colin Darie receives
regarding this bug report.  Future emails should go only
to Thaddeus H. Black.



signature.asc
Description: Digital signature

Bug#842472: To instruct the bug server to stop emailing Colin Darie re #842472

[Thaddeus H. Black]

Control: owner -1 !

Hopefully, this should be the last email Colin Darie receives
regarding this bug report.  Future emails should go only
to Thaddeus H. Black.



signature.asc
Description: Digital signature

Bug#842472: tags -1 - upstream

[Thaddeus H. Black]

Control: tags -1 - upstream



signature.asc
Description: Digital signature

Bug#836943: (no subject)

[Thaddeus H. Black]

Control: tags -1 - upstream


signature.asc
Description: Digital signature

Bug#842472: [Bug-wget] [PATCH] new option --convert-specified-links

[Thaddeus H. Black]

Control: tags -1 + upstream

This message is to Tim Rühsen, upstream developer of Wget,
and Noël Köthe, maintainer of Wget's Debian package.

Summary: Tim recommends that I convert my code for wget2.
Meanwhile, I can locally work around this bug.  Only the
arrival of wget2 is likely to close the bug.

Details follow.

Tim writes:
> We, the maintainers, are currently pretty busy with preparing
> a release for wget2. Also, we do all new stuff just for
> wget2, but wget1.x will receive bug fixes of course.
> 
> Thus, it is appreciated if you convert your code for wget2.

Received and understood.  I would like to do that as soon as
possible -- though "as soon as possible" is not very precise,
is it?  As always, time is limited.  We shall see.

I think that Tim is right: wget2 will help.  One would rather
not retire a working program like wget1, but now I understand
why my bug has never been fixed.  The relevant code is just not
straightforward.  One could hack an inelegant solution into
wget1, but the edge-case logic of src/convert.c
register_download() is hard to understand.  That function
seems to pretend to enforce an invariant but, as far as I can
tell, does not actually enforce one.  In short, the function is
confusing, it's brittle, the comments in it may be incorrect,
and one fears to touch it lest it break.  (Amusingly, the
function has a goto in it.  I am not one to deprecate goto
generally -- occasionally, I even like goto -- but this
particular goto may be a symptom of trouble.)

For reference (Noël, you need not follow the link; it's just
for reference), my post to bug-wget is linked [1].

1: https://lists.gnu.org/archive/html/bug-wget/2016-12/msg00011.html

At any rate, with the benefit of your kind advice, I believe
that I can now probably hack my own, local copy of wget2 well
enough to work around Debian bugs #836943 [2] and #842472 [3]
until wget2 arrives.

2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836943
3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842472

For additional reference (Tim, you need not follow any of these
links; they're just for reference), the bug log against
Debian's wget package is also linked [4].

4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847216

And here is Peng Yu's original bug report in the year 2010 [5]
with Giuseppe Scrivano's reply [6].

5: https://lists.gnu.org/archive/html/bug-wget/2010-05/msg00051.html
6: https://lists.gnu.org/archive/html/bug-wget/2010-05/msg00052.html

Tim's email address is obscured (Bcc) in the header
because Tim didn't ask me to publish the address, but I
suppose that Noël probably has it.  Replies sent
to <847...@bugs.debian.org> will reach both Noël and me,
at any rate.

Thanks for the help.  Noël, you can decide whether to leave
this Debian bug report #847216 open or to close it.  I would
probably leave it open but, basically, this bug awaits wget2.



signature.asc
Description: Digital signature

Bug#847216: wget: let the user --convert-links separately, without downloading

[Thaddeus H. Black]

On Tue, Dec 13, 2016 at 09:22:19AM +0100, Noël Köthe wrote:
> My strong advise is to contact the upstream mailinglist were you will
> get the best feedback regarding patches and hints for integration.
> The upstream maintainer switched since 2010 and other developer are
> very active on the mailinglist.
> 
> https://lists.gnu.org/mailman/listinfo/bug-wget

Okay.  Upstream will ask how the patch works, of course, especially
since the patch serializes existing data structures.  I will be
able to answer upstream better once I can show minimally
working code.  Therefore, let me hack some more, after which I
will seek feedback and hints on bug-wget as you advise, within
the next 30 days.

Thanks!  I will keep you apprised here.

Obviously, this bug will be for stretch+1 == buster.  As far as
I know, there is nothing to do for stretch.



signature.asc
Description: Digital signature

Bug#847216: wget: let the user --convert-links separately, without downloading

[Thaddeus H. Black]

Summary: I am working on a patch which will be hundreds of
lines long.  I have not yet mentioned the patch upstream.
Upstream has already heard of this bug from others.

Details follow.

A similar bug has been reported upstream as early as 2010, by
one Peng Yu.  In response, upstream developer Giuseppe Scrivano
has not himself tried to fix the bug, but has invited others
to try. [1]

1: https://lists.gnu.org/archive/html/bug-wget/2010-05/msg00052.html

So, I am trying.

I have not yet spoken to anyone upstream about this patch, but
of course (unless you advise otherwise) I eventually will.

I had asked:
> ... which of these do you prefer?
> 
>   * XML
>   * JSON
>   * RFC 3986/3987 (URI percent notation)
>   * Some other style

On investigation, RFC 3986 seems most compatible with the
existing code.  If acceptable to you, I'll just use that.

It appears that my patch, if successful, will be hundreds of
lines long, touching several source files, chiefly
src/convert.c.  The patch will need to refactor some existing
code, but will otherwise try to alter as little as it can.

If you have advice or feedback, let me know.



signature.asc
Description: Digital signature

Bug#842472: ITA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)

[Thaddeus H. Black]

Update: bug #847216 [1] is slowing me down.  I do not need a
fix for that other bug uploaded before I can proceed, but I do
at least probably need to fix that bug on my own PC.
Therefore, I am off hacking that other source.

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847216



signature.asc
Description: Digital signature

Bug#847216: wget: let the user --convert-links separately, without downloading

[Thaddeus H. Black]

Package: wget
Version: 1.18-4
Severity: wishlist

Would you answer just one question today: which of these do
you prefer?

  * XML
  * JSON
  * RFC 3986/3987 (URI percent notation)
  * Some other style

I ask because I am working on a patch to let the
user --convert-links separately, without downloading.  The
patch will probably require some data serialization.

If you have no preference, then RFC 3986/3987 is probably
closest to what wget(1) already does, so I might choose that;
but really I have no preference of my own.  Since it's your
package, you can choose.



signature.asc
Description: Digital signature

Bug#842472: ITA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)

[Thaddeus H. Black]

Control: retitle -1 ITA: w3-recs -- Recommendations of the World Wide Web 
Consortium (W3C)
Control: owner -1 !
Control: stop

Thanks for your work on this package, Colin.  It does not look
as though any other competent person were stepping forward to
maintain the package, so I will adopt it.



signature.asc
Description: Digital signature

Bug#842472: O: w3-recs -- search for a new maintainer

[Thaddeus H. Black]

Colin Darie writes:

> I'm not interested and I can't maintain this package anymore.
> It hasn't been updated since 2011 and needs a serious refresh :

Okay.  In the unlikely event that a third competent person
wishes to adopt this package, my own time is limited, so I'd
happily yield.  However, insofar as five years have passed, I
assume that there probably exists no third person.

In that case, I'd be glad to adopt the package.

Still, let's give a third person a week or two to show up
before I step forward.  Thanks.



signature.asc
Description: Digital signature

Bug#244724: Related bug reports

[Thaddeus H. Black]

For information, Debian bug #837535 [1] (closed and archived)
and upstream Exim.org bug #1885 [2] (closed and tagged wontfix)
probably turn out to be instances of the Debian bug whose log
you are reading, #244724 [3].

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837535
2: https://bugs.exim.org/show_bug.cgi?id=1885
3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244724

No action is requested.  No reply is needed (unless you have
something you would like me to test).  This message is just for
information.  Thank you for maintaining Exim.

For users affected by this issue:  the aforementioned Exim.org
bug log details a thorough and apparently effective workaround.
(The workaround is probably not new, but the discussion with
upstream developers in the Exim.org bug log is unusually
informative.  The discussion starts with an incorrect premise
of mine, but ends with a fairly clear understanding of the
problem by everybody involved.)



signature.asc
Description: Digital signature

Bug#836943: Incorporate new and revised documents from upstream

[Thaddeus H. Black]

I'd like to start working toward an NMU to fix this bug, since
you seem too busy to respond at the moment.  The patch would
consist mostly of a large amount of data, so the patch would be
too big to post here, but maybe I can post it elsewhere and
link from here to it; or maybe I'll find another way to
describe or represent the patch.

Objections?  If not, or if I hear no response within two weeks,
then I'll start work and, if I achieve what seems to me to be a
satisfactory patch (which is not guaranteed, for I do not know
this package as well as you do), then I'll post a link to (or
otherwise describe or represent) the patch, wait another two
weeks, and finally upload to DELAYED/10-day.



signature.asc
Description: Digital signature

Bug#837535: When a relay host lacks an IPv6 interface, mail heisenbounces

[Thaddeus H. Black]

> I would appreciate if you would report this upstream. We might apply
> this patch in Debian without an exim release if upstream accepts it as
> well.

Done. [1]

[1] https://bugs.exim.org/show_bug.cgi?id=1885

Bug#837535: When a relay host lacks an IPv6 interface, mail heisenbounces

[Thaddeus H. Black]

Stand by. Do not act on this bug yet. I had believed that the
heisenbounces had stopped, but now I *seem* to notice another
heisenbounce.

I will investigate. This may take some time. If it develops that the
bug report is not useful, I will close it (unless you yourself have
already done so).

Thanks.

Bug#837535: When a relay host lacks an IPv6 interface, mail heisenbounces

[Thaddeus H. Black]

> Full details are discussed here
> [http://unix.stackexchange.com/q/308283/18202], where a user named
> Rui F. Ribeiro cleverly discovers the fix.

The bug server's web archived does not seem to like the way I
have formatted that URL.  This may work better: [1].

[1] http://unix.stackexchange.com/q/308283/18202



signature.asc
Description: Digital signature

Bug#837535: When a relay host lacks an IPv6 interface, mail heisenbounces

[Thaddeus H. Black]

Package: exim4-config
Version: 4.84.2-1

I doubt that this bug, which affects only some users, will be
your most urgent bug to fix.  However, the fix is subtle.
Since I can now describe the fix (though I have not attached a
patch), I report the fix here.  The fix can be implemented and
packaged whenever you have time, whether before or after
stretch's release.

When an Exim4 relay host lacks an IPv6 interface, mail
heisenbounces -- that is, it bounces sporadically, due
apparently to an obscure timeout or a race condition.

Full details are discussed here
[http://unix.stackexchange.com/q/308283/18202], where a user named
Rui F. Ribeiro cleverly discovers the fix.

LOGS AND CLUES

Here is a typical excerpt from my relay host's
/var/log/exim4/mainlog:

2016-09-11 18:31:30 H=dpc6935235115.direcpc.com (localhost) [69.35.235.115] 
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 F= rejected RCPT 
: relay not permitted
2016-09-11 18:32:46 1bj9Ya-0006aq-Jt <= t...@b-tk.org 
H=dpc6935235115.direcpc.com (localhost) [69.35.235.115] P=esmtpsa 
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 A=plain_server:thb S=762 
id=20160911183227.ga1...@b-tk.org
2016-09-11 18:32:46 1bj9Ya-0006aq-Jt gmail-smtp-in.l.google.com 
[2607:f8b0:400d:c04::1b] Network is unreachable
2016-09-11 18:32:47 1bj9Ya-0006aq-Jt => thaddeus.h.bl...@gmail.com R=dnslookup 
T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.29.26] 
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=US,ST=California,L=Mountain 
View,O=Google Inc,CN=mx.google.com" C="250 2.0.0 OK 1473618767 
u126si8954672qkc.66 - gsmtp"
2016-09-11 18:32:47 1bj9Ya-0006aq-Jt Completed

In this log excerpt, two emails are sent.  The first email
bounces at 18:31:30.  The second email, sent to the same
recipient at 18:32:46, passes through.  The recipient (which
in this instance happens to be a Gmail account I control)
receives the second email promptly.  The first email however
never arrives.

The clue in this log is obscure.  The aforementioned Mr.
Ribeiro is a fine detective to find it.  Look at the third of
the five log lines, "Network is unreachable".  The IP address
the line mentions is an IPv6 that belongs to the relay
recipient.

SO WHAT?  WHO CARES?

But who cares?  The email goes through to the relay
recipient's IPv4, instead, one second later, right?

Answer:  Yes, the email does go through; but the *other* email
does not go through.  What is confusing is that
the IPv6 "Network is unreachable" is reported only for the
email that does indeed go through, whereas the error turns out
to be more relevant with respect to the other email.

This is why this bug was so hard to diagnose.  Some obscure
interaction between my nonexistent IPv6 interface and the
authenticator -- or some other interaction of the kind -- was
apparently instituting a timeout or race condition.

THE FIX

Once the bug is diagnosed, the fix is fairly
straightforward:  if the relay host has no IPv6 interface, then
in /etc/exim4/exim4.conf.template, add "disable_ipv6 = true" to
the section main/01_exim4-config_listmacrosdefs.  The neat way
to do this would probably be to add a suitable new parameter to
/etc/exim4/update-exim4.conf.conf, perhaps with "low" debconf
priority.  On my own host, however, to save time, I have just
manually added the line and invoked "dpkg-reconfigure -phigh
exim4-config", bypassing update-exim4.conf.conf.

REMARKS

To be clear:  this bug matters only if the relay host lacks
an IPv6 interface and (as I believe) the relay recipient has
an IPv6 interface.  If you think about it, though, Exim4 should
probably not be exercising a nonexistent IPv6 interface,
anyway, should it?  We never knew that this was an actual
problem, but now it turns out to be an actual problem, at least
for some users, or at any rate for Mr. Ribeiro and me.

Additional information:  my relay server is plaintext password
protected after STARTTLS on port 587.  (The X.509 certificate
happens to be a real one, not a snakeoil, but this is probably
not relevant to you.)

I have not tried the fix on sid, nor indeed have I verified the
bug on sid.  Reviewing post-jessie changelogs however, I see no
entry that would already have fixed this.  Thus, as far as I
know, the bug remains current.

If you have questions (whenever you get around to addressing
this bug, this year, next year, some year), let me know.  I'll
be here.  Meanwhile, users who discover this bug report and are
affected by the bug can straightforwardly implement the fix for
themselves.



signature.asc
Description: Digital signature

Bug#836943: Incorporate new and revised documents from upstream

[Thaddeus H. Black]

Package: w3-recs
Version: 20110107-1

Please incorporate new and revised documents from upstream.

Stefano once included a helper script in the source package to
do this, did he not?

The latest update to the package is over five years old.
That's all right -- it's no blame to you -- but W3 documents
have much advanced during the past five years.  The time has
probably come to update this package.



signature.asc
Description: Digital signature

Bug#835423: Add a man page to document shortcuts

[Thaddeus H. Black]

The man-page draft should have gone in man section 7, for no
command firefox-shortcuts(1) exists.

Once you have approved the general approach and instructed me
to proceed, I'll move the page to the right section.



signature.asc
Description: Digital signature

Bug#835423: Add a man page to document shortcuts

[Thaddeus H. Black]

Package: firefox-esr
Version: 45.3.0esr-1
Tags: patch

Please take four minutes to review.  This won't take long
today.

I have started a man page, attached, to document Firefox's
keyboard and mouse shortcuts.  Please briefly look at
it, "man ./browser-shortcuts.1.in".  If it looks okay, then let
me know; I would finish it.  Alternately, if you prefer a
different approach, please advise.

The man page is to aid offline Firefox users, including users
who are browsing "file:///" URLs.

.\" (C) Copyright 2016 Thaddeus H. Black <t...@debian.org>
.\" Licensed CC-BY-SA 3.0, which is the same license Mozilla by
.\" which Mozilla distributes its online documentation, from which
.\" documentation this man page is substantially derived.
.ds indent_a 0.50i
.ds indent_b 1.25i
.TH @BROWSER@ 1 "August 25, 2016" @browser@ "Manual"
.SH NAME
@browser@ shortcuts - @Browser@ keyboard and mouse shortcuts

.SH DESCRIPTION
.BR @browser@ (1)
affords the user several keyboard and mouse shortcuts.

.SS Keyboard Shortcuts
Available keyboard shortcuts include the following.

.B Navigation
.RS \*[indent_a]
.TP \*[indent_b]
Go back
.B <Alt+Left>
or
.B <Ctrl+[>
.TP
Go forward
.B <Alt+Right>
or
.B <Ctrl+]>
.TP
Go home
.B <Alt+Home>
.TP
Open file
.B <Ctrl+O>
.TP
Reload
.B 
or
.B <Ctrl+R>
.TP
Reload, overriding the cache
.B <Ctrl+F5>
or
.B <Ctrl+Shift+R>
.TP
Stop
.B 
.RE

.B Movement within the current page
.RS \*[indent_a]
.TP \*[indent_b]
Go up a screen
.B 
.TP
Go down a screen
.B 
.RE
(And so on)

.SS Mouse Shortcuts
Available mouse shortcuts include the following.

(To be completed.)




signature.asc
Description: Digital signature

Bug#813998: O: debmirror -- package is now orphaned

[Thaddeus H. Black]

Package: debmirror
Version: 1:2.18+nmu1
Severity: normal

Regrettably, I seem to have become a barrier to the
timely maintenance of debmirror. For the other two
packages I maintain, this would be less important,
because few use those packages and because I doubt that
anyone else would adopt them. Those other packages can
wait for me to fix their bugs.

This package is more important. It cannot wait. At the
moment, I lack sufficient time to keep atop this
package's bugs. Let me step aside.

Debmirror is now orphaned. If no one ever adopts it, it
is not impossible that I may again adopt it, myself,
since I have learned some things regarding the package's
internals, but it would be better if another competent
person took the package over.

I believe that the work I have done on the package will
make maintenance at least a little easier for the next
maintainer.

I can still answer questions regarding the package. For
a prompt response, I can be reached at thaddeus.h.black
at gmail.com or +1 540 921 1759 (8 a.m. to 8 p.m. U.S.
Eastern Time.)

Thanks for the helpful bug reports. My best wishes go to
the next maintainer.



signature.asc
Description: Digital signature

Bug#813999: O: debmirror -- package is now orphaned

[Thaddeus H. Black]

Package: wnpp
Version: 0
Severity: normal

Regrettably, I seem to have become a barrier to the
timely maintenance of debmirror. For the other two
packages I maintain, this would be less important,
because few use those packages and because I doubt that
anyone else would adopt them. Those other packages can
wait for me to fix their bugs.

This package is more important. It cannot wait. At the
moment, I lack sufficient time to keep atop this
package's bugs. Let me step aside.

Debmirror is now orphaned. If no one ever adopts it, it
is not impossible that I may again adopt it, myself,
since I have learned some things regarding the package's
internals, but it would be better if another competent
person took the package over.

I believe that the work I have done on the package will
make maintenance at least a little easier for the next
maintainer.

I can still answer questions regarding the package. For
a prompt response, I can be reached at thaddeus.h.black
at gmail.com or +1 540 921 1759 (8 a.m. to 8 p.m. U.S.
Eastern Time.)

Thanks for the helpful bug reports. My best wishes go to
the next maintainer.



signature.asc
Description: Digital signature

Bug#797384: debmirror: i18n hash sums not checked

[Thaddeus H. Black]

Thank you for your bug report. I am unfortunately so busy, I cannot
respond to your report at the moment. In fact, I do not even have an
up-to-date sid installation at the moment against which to compile.
This is of course my fault, not yours.

If you have Debian upload privileges, would you fix this and upload it
yourself, if you think it appropriate to do so?

If you absolutely need my attention in the matter right now, please
copy your messages to thaddeus.h.bl...@gmail.com; or better, if your
spoken English is sufficiently good, phone me at +1 540 921 1759 after
13:00 UTC, before 01:00 UTC.


On Sun, Aug 30, 2015 at 8:57 AM, core  wrote:
> Package: debmirror
> Version: 1:2.16
> Severity: normal
> Tags: upstream patch
>
> Dear Maintainer,
>
> When I use debmirror to download i18n, files checksums are not checked.
> I believe if the checksums for i18n files are available, it should be
> verified.
>
> Not failing when upstream has broken i18n files lead to such issues when
> running `apt-get update`:
>
> W: Failed to fetch http://some.custom.mirror/.../main/i18n/Translation-en
> Hash Sum mismatch
>
> Thank you!
>
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages debmirror depends on:
> ii  bzip2   1.0.6-7+b3
> pn  libdigest-md5-perl  
> ii  liblockfile-simple-perl 0.208-1
> ii  libnet-inet6glue-perl   0.603-1
> ii  libwww-perl 6.08-1
> ii  perl [libdigest-sha-perl]   5.20.2-3
> ii  perl-modules [libnet-perl]  5.20.2-3
> ii  rsync   3.1.1-3
>
> Versions of packages debmirror recommends:
> ii  ed 1.10-2
> ii  gpgv   1.4.18-7
> ii  patch  2.7.5-1
>
> Versions of packages debmirror suggests:
> ii  gnupg  1.4.18-7
>
> -- no debconf information

Bug#737057: debmirror: Please add xz support

[Thaddeus H. Black]

Sorry, friends. Obviously too busy, I am not keeping up with Debmirror
work at the moment. You have my blessing to help, to upload, to
hijack, as you think best. I regret having impeded your work in the
meantime.

I do not even have an up-to-date sid installation at the moment
against which to compile, so I cannot help right now.

Should you absolutely require my prompt attention in the matter
(though I doubt that I can help), please copy your messages to
thaddeus.h.bl...@gmail.com; or better, phone me after 13:00 UTC but
before 01:00 UTC at +1 540 921 1759.



On Sat, Sep 12, 2015 at 11:10 AM, John Paul Adrian Glaubitz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Control: tags -1 patch
>
> Hi!
>
> On 09/11/2015 12:08 PM, Cyril Brulebois wrote:
>> That doesn't seem unreasonable; helping the new maintainer with a
>> few patches would probably be appreciated as well, especially if
>> you're a regular user for your local mirror.
>
> I have patched my local installation of debmirror now to always try to
> download xz files instead of bz2 files. This is basically a lazy fix
> which solves the issue I currently had with debmirror but introduces
> a new regression by not being able to download the Translation files
> anymore which, to my big surprise, are still bz2-compressed [1].
>
> Since I don't really care about the translations, I just disabled
> those in /etc/apt/apt.conf on the clients and I can now continue
> to use debmirror normally. For anyone who doesn't know, adding
> Acquire::Languages "none"; to the apt configuration is enough.
>
> Feel free to merge my patch, but be aware that it removes bz2 support
> from debmirror completely. However, I expect that the translation
> files will move away from bz2 to xz in the future as well, so
> this might solve itself then.
>
> Cheers,
> Adrian
>
>> [1] ftp://ftp.debian.org/debian/dists/sid/main/i18n/
>
> - --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJV9AgfAAoJEHQmOzf1tfkTm4YP/jIg686bDmDpkcPEA5p/UcR2
> EDAoeqRBMIF3OjPMyDkcOHAr/HsA7xehSLIBtro65kP458BwLWOYisPDhT79N0UE
> BfZnHXEcDSZtVz8J9wQFrBB0N9cvLiKd7CDYbbmfiSQJANST7wovu9bkyUs1A8CU
> qQgK1BGPGfTxpjcLSNaFCNVMpnEKKqm3LM7NTzYwpOkHTu9vuATW3FM+aklDVvI0
> 49aIPY1yT+vlgoRRfrAwEDHtvAw2dWFDf3XCqpU4gfyebVe84E4noEn4ztCigJ6W
> VtrFYz5J5nXzof8Od25uc0q2whigUf8Tx1/RiGGkGR4uoGRZMJY+erqhzEgRNuby
> G1Ct1qSK04IO7evTo9rywYy1n/FjsIXXt4aeEAWW+ncb14il10HyCxHT0qnXcfo3
> pYWBNdcBYVaYS/m4gUkro7Ps0Irac0VqV3xkU3XoPpzVRyU9PBQpNpOi+vuNU4Mf
> X1IP4fNf+VG2NsA7Nb4Ydv6n63PzEZWDo6zeDJPPgknOutLUZ+GQeEyGLRTu1epG
> Vo+2+ekL80NyI4RbyV8xOe3I3k5ccpzmFh5WANjaEea2zTbX0ES6gtyj3BmB2sMn
> seJsJO4LyzF49Z3ucBY8Zd6YPGLcRY72PcMfmNrqV6sMpVXkpzmXxc3gXOALyW8H
> SvtIwWav/Cj5D6i+K+6l
> =LRQZ
> -END PGP SIGNATURE-

Bug#797706: debram: illegal date format in debian/changelog

[Thaddeus H. Black]

Thanks, James. You are quite right, of course. It's supposed to be
"Jun", not "June".

It is no fault of yours, only my fault, but I am so busy with
non-Debian work at the moment, I regrettably lack the time to update
my sid installation to rebuild and upload. I'll get to this when I
can.

In the meantime, if the Debram package is blocking or stalling
anyone's work, please remove it from testing.


On Tue, Sep 1, 2015 at 6:28 PM, James Cowgill <james...@cowgill.org.uk> wrote:
> Source: debram
> Severity: serious
> Version: 2.0.0.4
> Justification: Policy 4.4
>
> Hi,
>
> The latest changelog entry of debram has an illegal date format which
> causes dpkg-parsechangelog to choke (and thus the package to FTBFS).
>
>  -- Thaddeus H. Black <t...@debian.org>  Fri, 26 June 2015 00:00:00 +
> 
>
> Policy 4.4 requires the month to contain exactly 3 characters.
>
> Failed mips64el build log:
> https://buildd.debian.org/status/fetch.php?pkg=debram=mips64el=2.0.0.4=1441108414
>
> Thanks,
> James

Bug#789293: debram: FTBFS with pbuilder: dsc file missing newline before BEGIN PGP SIGNATURE line

[Thaddeus H. Black]

Daniel:

Interesting bug report.  I had not known that an extra
newline was needed there; but now that you point it
out, I see that the extra newline is standard in other
packages, and even in my own other packages.  I'll add
the newline and upload again.  Thanks.

I would explain why the newline was missing, but the
explanation is neither interesting nor important.

I appreciate the clear explanation of the problem.
Your explanation makes it easy to fix.



signature.asc
Description: Digital signature

Bug#652138: debmirror: does not download Contents-source.gz files with --getcontents --source

[Thaddeus H. Black]

Control: tags -1 + confirmed

Yes, this does seem to be a bug.

To fix this bug right wants some refactoring.  Let us
take this in stages.

Version 2.18 of debmirror (which I mean to upload as
adopting new maintainer) partly refactors the relevant
code.  We'll let the partly refactored 2.18 stay in
sid and testing a while, in case the refactoring has
inadvertently broken something.  After that, I or
someone else can try to fix the bug itself.

I have tested the refactoring.  As far as I can tell,
it cleans up the relevant part of the program's
internal logic without materially altering the
program's external behavior, but also therefore without
fixing the bug.

If someone besides me ends up trying to fix the bug:
I can recommend starting by searching in the debmirror
script executable for the symbol
do_contents_for_each_dist_arch_sect, which my recent
refactoring has introduced pursuant to this bug.  I
suspect that the bug lies in the neighborhood of one of
the several occurrences of this symbol.  I also suspect
that the bug will now be easier to isolate than it
was before, provided that you can read Perl at a
moderately advanced level.

You can also search in the debmirror script executable
for the hash key do_for_source, which is not yet used,
but which I have introduced to prepare to attack
this bug.



signature.asc
Description: Digital signature

Bug#625696: debmirror: please do not forcibly use rsync for trace files

[Thaddeus H. Black]

Control: tags -1 + confirmed

Adopting maintenance of debmirror, I wish to
acknowledge this bug.  As Joey Hess observes in
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625696#10],
rsync is necessary to enumerate the file list.
Notwithstanding, A Mennucc is probably right that the
rsync solution is not quite right.

No fix for this bug is contemplated, but who knows?
Maybe someone will someday think of suitable fix.
In the meantime, as A Mennucc suggests:

 let's keep this bug standing until someone
 has some better ideas.



signature.asc
Description: Digital signature

Bug#581013: [debmirror] debmirror ignore the section 'debian-installer' for the distribution '.*-proposed-updates'

[Thaddeus H. Black]

Control: tags -1 + moreinfo
Control: stop

Hello, Philippe. My name is Thaddeus Black. I am
adopting maintenance of Debian's package debmirror in
place of the late Frans Pop and the retired Joey Hess.

During 2010, you reported bug 581013 against debmirror:

 debmirror ignore the section 'debian-installer' for
 the distributions '.*-proposed-updates'. It is
 hardcoded in the debmirror script itself. Is there
 any raisons to do that ? 

If you still care about this bug, please note: After
three hours of trying, I have failed to reproduce the
bug. Maybe the bug does not exist in the current
version of debmirror, or (more likely) maybe I just do
not understand it.

Specifically, I have set up a mock archive with a
main/debian-installer/binary-amd64 but no
main/debian-installer/binary-i386. As far as I can
tell, the current debmirror behaves no differently for
the one architecture than for the other in this case.

Feel free to explain more, if this bug is still
relevant to you.

I will leave your report open here for another three
months. If no further information is added during this
time, I will close the report.

Thanks.



signature.asc
Description: Digital signature

Bug#619361: No longer capable of mirroring debian-installer section for Ubuntu *-updates

[Thaddeus H. Black]

Control: tags -1 + moreinfo help
Control: stop

Hello, Max. Hello, Steve. My name is Thaddeus Black.
I am adopting maintenance of Debian's package debmirror
in place of the late Frans Pop and the retired
Joey Hess.

During 2012, Max reported bug 619361 against debmirror:

 The fix for #619146 Should not attempt to mirror
 debian-installer for squeeze-updates has accidentally
 widened the regexp of dists that omit a
 debian-installer section a little too far.
 
 Whilst squeeze-updates and successors do not have a
 debian-installer section, Ubuntu's *-updates do.

Steve followed with a patch and this observation:

 It looks like all the dists currently on
 ftp.debian.org have a main/debian-installer section.

However, as Frans had noted two years earlier in
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581013#10],
what Steve observed is not necessarily always the case.
Thus, it would seem that Steve's patch cannot be
applied.

Joey is smarter than I am, and he did not seem to know
how to fix this bug. Moreover, Joey was as wary of
being drafted into Ubuntu maintenance as I am. (We
don't use Ubuntu and lack time to maintain it.)

Still, Debian would rather not be the cause of Ubuntu
bugs.

I have set up a mock archive with a
main/debian-installer/binary-amd64 but no
main/debian-installer/binary-i386. As far as I can
tell, the current debmirror behaves no differently
against the mock archive for the one architecture than
for the other in this case. Moreover, the current
debmirror does not seem to evince Max's bug in either
case. The most likely explanation for this is that I do
not understand the bug!

Feel free to explain more, if this bug is still
relevant to you.

One gets the feeling that fixing this bug will not be
trivial. Someone who cares about Ubuntu may have to
delve into this, to come up with a clean solution that
fixes Ubuntu's problem while improving, rather than
merely hacking, debmirror's code and behavior with
respect to Debian proper.

If you would like to set up my mock archive on your
machine, so that you can prove the bug against it to
show me more clearly, exactly what the problem is, let
me know.

Thanks.



signature.asc
Description: Digital signature

Bug#768532: ITA debmirror

[Thaddeus H. Black]

A new maintainer of mature software like debmirror never knows which
line of the existing code, a line that *looks* inelegant or pointless,
might actually fix some obscure bug from seven years ago for a guy
who (say) uses debmirror over AX.25 in Nepal.  One has to be careful
about that.

For this among other reasons, I do not plan to redesign the software,
but to maintain it in its current form.

There seems to exist a newer package named aptly.  I do not know much
about that, nor even if it conveniently does (or at all does) what
debmirror does.  Nevertheless, its developer seems enthusiastic enough;
so, if you should happen to require an overall redesign, then you might
investigate that package.



signature.asc
Description: Digital signature

Bug#768532: ITA: debmirror

[Thaddeus H. Black]

For reference, the bug report (with patch)
to which I referred yesterday was #787760.


signature.asc
Description: Digital signature

Bug#787760: Add the file download method

[Thaddeus H. Black]

Package: debmirror
Version: 1:2.17
Severity: normal
Tags: patch

Debmirror can download via ftp://, http://, https:// or rsync://, but
not via file://.  That is, a command like this does not work:

debmirror --dist=stable --arch=amd64 --method=file\
 --root=$SOURCE_DIRECTORY --no-check-gpg $TARGET_DIRECTORY

Why do you care that this does not work?  Answer: testing.  It can be
more convenient for users, and maybe even more convenient for
developers, to test debmirror's behavior on localhost than over
the network.

Besides, most or all programs that support multiple network protocols
should probably support a file:// method, for approximately the same
reason your network should support a localhost and your system should
support a /dev/null.  Even if the file:// method is not often used, it
should remain available as a null method, so to speak.  (I believe that
pbuilder has recently added a file:// method, for instance.)

Please find attached a suggested patch to implement the change.  I have
successfully tested the patched binary by using it download jessie 8.0
stable, with source and binary-amd64, about 100 GiB, from one hard-drive
partition of my laptop to another.

Observe that though rsync is incidentally used in the normal debmirror
manner, no rsync *daemon* is required to use the file:// method as the
patch implements it.

The severity is normal rather than wishlist because applying this patch
may make it easier to fix some of debmirror's other, outstanding bugs of
normal severity.

At the time this bug is reported, debmirror has been orphaned (#768532)
six months.  Since no one else has maintained this package for the past
six months, since I have now spent the time to learn a little about how
debmirror internally works, and since I have used debmirror for years
and prefer its bugs to be fixed, I had probably better adopt the
package.  I will file ITA after this report.

diff -turN debmirror-2.17/debmirror debmirror-2.17.1/debmirror
--- debmirror-2.17/debmirror	2014-07-02 20:54:08.0 +
+++ debmirror-2.17.1/debmirror	2015-06-03 22:41:55.517583458 +
@@ -103,7 +103,8 @@
 =item B--method=Imethod
 
 Specify the method to download files. Currently, supported methods are
-Bftp, Bhttp, Bhttps, and Brsync.
+Bftp, Bhttp, Bhttps, and Brsync. The Bfile method is
+experimentally supported.
 
 =item B--passive
 
@@ -766,7 +767,7 @@
 }
 
 # Backwards compatibility: remote root dir no longer needs prefix
-$remoteroot =~ s%^[:/]%%;
+$remoteroot =~ s%^[:/]%% unless downloads_via_file();
 
 # Post-process arrays. Allow commas to separate values the user entered.
 # If the user entered nothing, provide defaults.
@@ -802,7 +803,7 @@
 # Display configuration.
 $|=1 if $debug;
 if ($passwd eq anonymous@) {
-  if ($download_method eq http) {
+  if (downloads_via_http()) {
 say(Mirroring to $mirrordir from $download_method://$host/$remoteroot/);
   } else {
 say(Mirroring to $mirrordir from $download_method://$user\@$host/$remoteroot/);
@@ -823,7 +824,7 @@
 say(Passive mode on.) if $passive;
 say(Proxy: $proxy) if $proxy;
 say(Download at most $max_batch files.) if ($max_batch  0);
-say(Download at most $rsync_batch files per rsync call.) if ($download_method eq rsync);
+say(Download at most $rsync_batch files per rsync call.) if (downloads_via_rsync());
 if ($pre_cleanup) {
   say(Will clean up before mirroring.);
 } elsif ($post_cleanup) {
@@ -878,7 +879,7 @@
 sub init_connection {
   $_ = $download_method;
 
-  /^http$/  do {
+  downloads_via_http()  do {
 $ua = LWP::UserAgent-new(keep_alive = 1);
 $ua-timeout($timeout);
 $ua-proxy('http', $ENV{http_proxy}) if $ENV{http_proxy};
@@ -887,7 +888,7 @@
 return;
   };
   
-  /^https$/  do {
+  downloads_via_https()  do {
 $ua = LWP::UserAgent-new(keep_alive = 1, ssl_opts = {
 verify_hostname = ! $disable_ssl_verification });
 $ua-timeout($timeout);
@@ -898,7 +899,7 @@
   };
 
 
-  /^ftp$/  do {
+  downloads_via_ftp()  do {
 if ($proxy || $ENV{ftp_proxy}) {
   $ua = LWP::UserAgent-new;
   $ua-timeout($timeout);
@@ -915,7 +916,15 @@
 return;
   };
 
-  /^rsync$/  do {
+  downloads_via_file()  do {
+$ua = LWP::UserAgent-new;
+$ua-timeout($timeout);
+$ua-show_progress($progress);
+$host='localhost';
+return;
+  };
+  
+  downloads_via_rsync()  do {
 return;
   };
 
@@ -926,13 +935,18 @@
 # determine remote root for rsync transfers
 my $rsyncremote;
 if (length $remoteroot) {
-$rsyncremote = $host\:\:$remoteroot/;
-if ($user ne 'anonymous') {
-$rsyncremote = $user\@$rsyncremote;
+if (downloads_via_file()) {
+$rsyncremote = $remoteroot/;
+}
+else {
+$rsyncremote = $host\:\:$remoteroot/;
+if ($user ne 'anonymous') {
+$rsyncremote = $user\@$rsyncremote;
+}
 }
 }
 else {
-if ($download_method eq 'rsync') {
+

Bug#768532: ITA debmirror

[Thaddeus H. Black]

That is, if you wish to help, let me know at t...@debian.org.
(E-mail to that other address won't reach me.)



signature.asc
Description: Digital signature

Bug#768532: ITA: debmirror

[Thaddeus H. Black]

I am hardly the ideal maintainer for this package.  Nevertheless,

  * I have used the package for years;
  * the package is implemented in Perl, a language with which
I am familiar and which I often use;
  * I have recently spent some hours to learn a little about
the package's software internals;
  * among the package's outstanding bug reports is one with
a patch by me;
  * the package has a not insignificant number of users;
  * the package has now been orphaned six months; and
  * no other maintainer seems to be stepping forward to adopt
the package.

So, I'll adopt it, at least for now, and we shall see how it goes.
If the adoption does not work out, then I'll orphan the package again,
and we'll be no worse off than we now are.

I miss former maintainers Frans Pop (deceased) and Joey Hess (retired),
two of my favorite DDs of all time.  Those were important DDs, giants
of Debian; whereas I am so unimportant a DD that (despite my having been
a DD ten years), 90 percent of the project's members have never heard
of me.  That's just as well, and I'll not fill Frans' or Joey's shoes;
but still, after the great have left, the less must carry on.

If you wish to help, let me know.



signature.asc
Description: Digital signature

Bug#690161: derivations: compatibility with poppler 0.20

[Thaddeus H. Black]

Hello Pino.  Thank you for the patches.  I am ill situated to process your
patches at the moment, but will be pleased to do so later.  Alternately,
feel free to incorporate the patches yourself and to upload NMU at your
convenience:  you need not wait for me.


On Wed, Oct 10, 2012 at 3:45 PM, Pino Toscano p...@debian.org wrote:

 Source: derivations
 Version: 0.53.20120414-1.1
 Severity: normal
 Tags: patch

 Hi,

 libextractor uses the private poppler core API, and thus is likely to
 break on new upstream releases.
 With poppler = 0.20.x (should be since 0.20.3, to be precise),
 compiling stuff using the private core headers really needs the poppler
 include path added to the CFLAGS/CXXFLAGS; this causes derivations to
 not compile.

 It seems derivations has no way to add/set CXXFLAGS while building,
 so the fix is in two parts:
 * cflags:
   a patch to pass CXXFLAGS, if set, to g++
 * Makefile:
   a real makefile which should replace the symlink btool/PDF/Makefile;
   what it does is just including ../Makefile-subdir (the makefile it
   was a symlink to), but setting CXXFLAGS first with the flags for
   poppler, got using pkg-config (which must be added to the build
   dependencies)
 * debian.diff:
   following what said above, add pkg-config to the build-depends-indep

 (Note that poppler 0.20 or greater is not for Wheezy, but for Jessie,
 so this fix can wait after the release.)

 Thanks,
 --
 Pino

Bug#688828: Solution or workaround?

[Thaddeus H. Black]

Have you solved or worked around your Debian Bug#688828:
xserver-xorg-video-radeon: brightness controls don't work?

If so, how, please?  I have precisely the same problem you have, and can
confirm similar symptoms in detail, including the unresponsiveness in
/sys/class/backlight.  My machine is no Mac, but its video chip is an AMD
7570M (despite its 7xxxM model number, apparently really a 6xxxM, Northern
Islands series, Turks architecture, similar to yours).

If you have a solution or workaround, please advise.  Thanks.

Bug#482446: The Debian package debram, and your ancient patch

[Thaddeus H. Black]

Long ago, you submitted a patch to the Debian package
Debram, on which I never acted.  I have had plans to
update this package, but the task gets harder and harder
and I have less and less time.  I should no longer
maintain this package.

You can take over maintenance of the package if you
wish.  You can become the regular maintainer of Debram.
If you did, then it would be your package rather than
mine, and you could add your patch and otherwise manage
the package as you saw fit.  Otherwise, three weeks from
now, I should ask to have Debram permanently removed
from Debian.



signature.asc
Description: Digital signature

Bug#680845: derivations: FTBFS: Can't create output index file /«PKGBUILDDIR»/tex/main.ind.

[Thaddeus H. Black]

The patch and testing are appreciated.  Please NMU with my thanks.
Otherwise, I'll test, build and upload as soon as I can, though this
may not be soon enough.

If you can read the book and your PDF reader can display its table of
contents in a sidebar, then your patch is very likely good.  If you
can read the book but your PDF reader cannot display the table of
contents in a sidebar, the sidebar is not crucial and you should still
upload.  (After all, the book still has a fine table of contents for
the human reader to read and use.  If the PDF reader cannot parse the
table, too, this is no disaster.)

The book purposely has no PDF hyperlinks in it.  In other words, it
doesn't have those blue page numbers you can click to go straight to
the referenced page.  Thus, if you do not see blue page numbers, this
does not mean that you have done something wrong.

[Recent package transitions unfortunately have made awkward what used
to be a rather elegant build.  At the root of the trouble is the need
(a) to create a PDF from LaTeX, (b) to give the PDF a proper PDF table
of contents without using PDFLaTeX, (c) to include LaTeX-nonstandard
PostScript in the PDF, and (d) to do all this using special build
tools, compiled from source as part of the Derivations package's build
procedure.  All this used to work rather nicely, and recently I have
accepted well-appreciated patches to kludge the build procedure to get
it through the upcoming stable release.  Hopefully, this will be the
last adjustment to the kludge.  After the stable release, when time
permits, I'll probably reform the entire build procedure, but for now
the patches, and NMU if appropriate, are welcomed with thanks.]

-- 
Thaddeus H. Black


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660986: derivations: please migrate the libpoppler-dev build dependency to libpoppler-private-dev

[Thaddeus H. Black]

 I would like to close this in wheezy, so I'll NMU/5 within today or
 tomorrow.


Thank you, Pino.  Besides your helpful NMU, which I appreciate, you are
also most diplomatic.

Bug#677881: debram: binNMUs are not installable

[Thaddeus H. Black]

Thank you for the report, to which regrettably I cannot immediately attend.
 Though no one but me is responsible to fix this bug, did someone (not
necessarily you) wish to NMU, I would not object but would thank him for it.

Incidentally, it is acknowledged that this package has outdated data.  A
few users seem still to be using the package, anyway, and the package does
not break anything, which is why I have not requested its removal; but a
reasonable case could be made to remove Debram and Debram-data from Debian
entirely.  The disk space the package consumes is not inconsiderable, and
much of the data that occupies this space is probably no longer being used
by anyone.

My guess is that the few users in question are still using the package's
file cmdsel.txt, but I don't really know.

Bug#677881: debram: diff for NMU version 1.0.3-0.2

[Thaddeus H. Black]

 I've prepared an NMU for debram (versioned as 1.0.3-0.2) and
 uploaded it to DELAYED/0. Please feel free to tell me if I
 should delay it longer.


You needn't delay.  Accept my thanks, rather.

Bug#566340: derivations: Versioned build dependency on texlive-base-bin

[Thaddeus H. Black]

reopen 566340
severity 566340 minor
stop

Michael Bienia reports an outdated TeX-related build-dependency in my
package 'derivations'.  I thank him.  The latest upload treats the bug
and closes the report.

However, Frank Kuester, who knows rather more about TeX packaging than I
do, further suspects that 'derivations' suffers some unnecessary
build-dependencies.  I do not doubt that Frank is right, so let me
reopen the report now with reduced severity.

If that is all you want to know, then you can stop reading here.
Otherwise, further details follow.

I seem to remember that I once had a good reason to specify the
build-dependencies Frank questions, but unfortunately I no longer
remember the reason, nor do I remember much else, so let me say this:
though no action is expected of Frank he can NMU with my thanks should
he feel sufficiently motivated to do so.  Otherwise, well, time is hard
to find and my Internet connectivity is regrettably much worse than it
used to be; but probably, eventually, I will address the matter myself.

If the information is relevant to Frank or any other competent person
who might choose to NMU this bug before I do, the build-process
for 'derivations' exercises the LaTeX and postprocessing software pretty
hard.  This is not a typical LaTeX compilation and PDF presentation, but
a relatively complex processing train with a script or two hooked in and
even a special-purpose C++ program (compiled, run and then deleted as
part of the build) to interfere with and to specialize the build.  Maybe
this complexity has something to do with the unusual-seeming
build-dependencies, or maybe it does not: as I said, unfortunately I no
longer remember.

Since I do not know as much about TeX's internals as Frank undoubtedly
does, I admit to a certain superstition against disturbing a somewhat
complex build process which in fact is working right now in Sid.  TeX
though lovable is somewhat archaic, which can make it *feel*
unpredictable or brittle when driven hard.  I just do not understand the
TeX-packaging issues implicated.  For these reasons among others, I am
likely to defer the matter until after the release---though, as I said,
if Frank feels confident or does not care for my answer, and wants the
bug fixed, then he can NMU at his discretion now.

At the very least, whatever betide, I appreciate the good counsel on all
sides.  Let me know if further questions arise.

-- 
Thaddeus



signature.asc
Description: Digital signature

Bug#566340: derivations: Versioned build dependency on texlive-base-bin

[Thaddeus H. Black]

Incidentally, in the unlikely event that someone competent NMUs this
bug, would he, before uploading, try the build on stable lenny as well
as on sid?  There is no good reason that the unmodified source should
not build its own backport.

-- 
Thaddeus



signature.asc
Description: Digital signature

Bug#453160: debram: FTBFS: utf8.h:15: error: expected declaration specifiers or '...' before 'size_t'

[Thaddeus H. Black]

Would Kumar like to adopt my package whose RC bug he has
fixed?

In December, Lucas wrote,

 During a rebuild of all packages in sid, your package
 failed to build on i386.

Also in December, Kumar wrote,

 Please find a simple patch to find size_t and fix
 this FTBFS.

Today, I finally turned attention to Kumar's patch,
learning that Bart on Sunday had already applied and
uploaded it.

Lucas, Kumar and Bart, please accept my thanks
respectively for finding, patching and closing this bug
on my package debram.  I appreciate the aid.  Plainly I
am no longer maintaining this package in a timely
manner, so my question to Kumar is this: in December,
were you merely hunting for random RC bugs, or have you
developed an actual interest in the debram package?  If
the latter, if you wished to adopt the package, and if
you understood (as one suspects that you do) what
adopting this particular package would mean, then I
would be amenable to turning it over to you.

Please advise.

This message is copied to A. Costa, who has a
long-outstanding bug filed against the package and might
be interested in the package's future (or, conceivably,
might wish to take over its maintenance himself); to the
relevant bug logs; and to Giacomo Catenazzi, who
sponsored the package years ago.  If Kumar (or one of
the others receiving this message) were to take over the
package, then I have some never-uploaded data updates
that bring debram-data fully up-to-date at least as of
the final r0 etch release.  He might wish me to send
these to him.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#413128: This ITP remains active.

[Thaddeus H. Black]

This ping is just to inform anyone who might be
interested that the ITP is still active.  Looking today
at dlmf.nist.gov, I no longer see NIST's schedule to
release the DLMF in 2007.  Presumably this means that
the DLMF is delayed.

So, we mathematics fans will patiently have to keep
using Abramowitz  Stegun for the time being.  I do mean
to package nist-dlmf when it finally does appear.

Watch this space for further news.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]



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

Bug#413128: This ITP remains active.

[Thaddeus H. Black]

[Forgot to sign the last mail.  Here it is again.]

This ping is just to inform anyone who might be
interested that the ITP is still active.  Looking today
at dlmf.nist.gov, I no longer see NIST's schedule to
release the DLMF in 2007.  Presumably this means that
the DLMF is delayed.

So, we mathematics fans will patiently have to keep
using Abramowitz  Stegun for the time being.  I do mean
to package nist-dlmf when it finally does appear.

Watch this space for further news.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#413128: ITP: nist-dlmf -- NIST's Digital Library of Mathematical Functions

[Thaddeus H. Black]

The following ITP went
to debian-devel@lists.debian.org a few days ago.
However, there is so much noise over there that, of
courtesy, I ought to have posted it here too.  The ITP
follows below.  The BTS number is 413128.

Florian Weimer believes that the package might
experience license problems.  I do not think that it
will, but on the other hand upstream has not actually
released the work yet; so, Florian might be right.  For
the time being, the assumption is that the license will
resemble that of Abramowitz  Stegun's Handbook of
Mathematical Functions or of NIST's libtnt/libjama.

- Forwarded message from Thaddeus H. Black [EMAIL PROTECTED] -

Package: wnpp
Severity: wishlist
Owner: Thaddeus H. Black [EMAIL PROTECTED]

* Package name: nist-dlmf
  Version : 1.0.0
  Upstream Author : U.S. National Institute of Standards and Technology [EMAIL 
PROTECTED]
* URL : http://dlmf.nist.gov/
* License : U.S. government issue, uncopyrighted (refer to Abramowitz  
Stegun, page II)
  Description : NIST's Digital Library of Mathematical Functions

From the upstream web site:

Abramowitz and Stegun's Handbook of Mathematical Functions with
Formulas, Graphs, and Mathematical Tables is being completely
rewritten with regard to the needs of today.  The new DLMF
(Digital Library of Mathematical Functions) will appear in a
hardcover edition and as a free electronic publication on the
World Wide Web.  The authors will review the relevant published
literature and produce approximately twice the number of
formulas that were contained in the original Handboook.  The
DLMF will make full use of advanced communications and
computational resources to present downloadable math data,
manipulable graphs, tables of numerical values, and math-aware
search.  The authoritative status of the existing Handbook, and
its orientation toward applications in science, statistics,
engineering and computation, will be preserved.

Thus the utilitarian value of the Handbook will be extended far
beyond its original scope and the traditional limitations of
printed media.  The term digital library has gained acceptance
for this kind of information resource, and our choice of project
title reflects our hope that the NIST DLMF will be a vehicle for
revolutionizing the way applicable mathematics in general is
practiced and delivered.

NIST plans to release the DLMF during 2007.

- End forwarded message -

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#413128: ITP: nist-dlmf -- NIST's Digital Library of Mathematical Functions

[Thaddeus H. Black]

Package: wnpp
Severity: wishlist
Owner: Thaddeus H. Black [EMAIL PROTECTED]

* Package name: nist-dlmf
  Version : 1.0.0
  Upstream Author : U.S. National Institute of Standards and Technology [EMAIL 
PROTECTED]
* URL : http://dlmf.nist.gov/
* License : U.S. government issue, uncopyrighted (refer to Abramowitz  
Stegun, page II)
  Description : NIST's Digital Library of Mathematical Functions

From the upstream web site:

Abramowitz and Stegun's Handbook of Mathematical Functions with
Formulas, Graphs, and Mathematical Tables is being completely
rewritten with regard to the needs of today.  The new DLMF
(Digital Library of Mathematical Functions) will appear in a
hardcover edition and as a free electronic publication on the
World Wide Web.  The authors will review the relevant published
literature and produce approximately twice the number of
formulas that were contained in the original Handboook.  The
DLMF will make full use of advanced communications and
computational resources to present downloadable math data,
manipulable graphs, tables of numerical values, and math-aware
search.  The authoritative status of the existing Handbook, and
its orientation toward applications in science, statistics,
engineering and computation, will be preserved.

Thus the utilitarian value of the Handbook will be extended far
beyond its original scope and the traditional limitations of
printed media.  The term digital library has gained acceptance
for this kind of information resource, and our choice of project
title reflects our hope that the NIST DLMF will be a vehicle for
revolutionizing the way applicable mathematics in general is
practiced and delivered.

NIST plans to release the DLMF during 2007.


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

Bug#413128: ITP: nist-dlmf -- NIST's Digital Library of Mathematical Functions

[Thaddeus H. Black]

Florian Weimer wrote:
 * Thaddeus H. Black:
 
  * License : U.S. government issue, uncopyrighted (refer to 
  Abramowitz  Stegun, page II)
 
 Hum?  The NIST web pages claim copyright AFAICT.  And U.S. copyright
 only prevent the government from enforcing its copyrights
 domestically.

Thank you for the notice.  I will look into the matter.
If you happen to find further information before I do,
though, please do post it here.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#384953: 'man debram': needless neologisms subramifications, misramifications, metaramification, etc.

[Thaddeus H. Black]

Ninety days have now passed with no activity in this bug
log, and I was thinking of closing the log; but although
I am not sure exactly what to do about it, I do tend to
think this bug report legitimate.  Maybe when I edit the
package's manpage for Debian lenny (etch+1), I shall
look into the terminology then.  It will be hard to say
exactly when the bug is fixed as such, but unless you
object at the time I shall probably close the bug when I
edit the manpage.

Until then, let's let this log linger open.  Wishlist
bugs have no time limit, so there is no hurry that I
know of.

Thanks for the report.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#384953: 'man debram': needless neologisms subramifications, misramifications, metaramification, etc.

[Thaddeus H. Black]

This is to acknowledge your last post to the BTS
log.  I have read it, and have only two comments to
add at present:

1.  The control-file description must remain as brief as
possible.  One begrudges every line.  The description
need give only enough information to let the sysadmin
decide if he wants to install the package and learn
more.  (A few Debian packages have long descriptions.
Sometimes this is necessary, but in general I think it a
mistake.)  The description should also enjoy a degree of
concise rhetorical flair.  So, sterile accuracy there
was never my aim.

The description you see, I wrote in many, many revisions
in 2002 and 2003, weighing each word.  Naturally, the
wordsmith may be flawed!  Improvements are acceptable
and appreciated, but disagreement as to what constitutes
an improvement remains possible.  I admit a degree of
subjective attachment to the existing paragraph, which
does not necessarily apply to the manpage as a whole.

2.  The library thing is a problem.  Neither
university library nor public library is quite
right, since a library with a catalog system can be one
or the other, both or neither.  I have never asked which
country is yours, but in mine, many non-academic public
libraries have regrettably become unpleasant places, for
reasons which have nothing to do with cataloging.  May I
avoid the association of public library for this
reason?  Plain library, I feel, does not work in a
Debian context.  Still, if university library does not
sit right with you, since bibliotheque is no proper
English word, perhaps book library, library of
books, or academic library.  See what you can do with
this.  I do not really like university library,
either, now that you point it out.  On the other hand,
it's an analogy not a definition; exact precision may
not absolutely be required.

As I write this e-mail, Tyler Kramer, a friend here on
my end, suggests library catalog system in place of
university library.  This strikes me as not a bad
idea.

Please proceed with your debram work as time permits.
The development aid is appreciated.  (The reward for
good word is usually *more work.*  Keep this up, and
Anoop and I are likely to give you a pile of new
packages to ramify.)

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#372153:

[Thaddeus H. Black]

Well, I have investigated as best as I can.  Justin, I
appreciate the bug report, but I just cannot find this
bug.  Maybe I am blind to it; or, more likely I think,
there was a momentary bug, not in debram, but in the
sid-version tools you happened to use when you analyzed
debram.  If the latter, then the bug would now seem to
have disappeared.

Unless new information emerges, I plan no further action
on this bug.  However, since I have never found the bug
and, at one time, you did find it, one feels a bit
uneasy about just closing the report.  I would like to
leave this BTS log open three more months.  If neither
you nor anyone else adds anything new in that time, I
should close the report then.

Debram users or others reading this log are asked to add
more information in the matter, if they have any.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#384953: 'man debram': needless neologisms subramifications, misramifications, metaramification, etc.

[Thaddeus H. Black]

 me).  The assignment is in /usr/share/debram-data/.

Note:  The etch freeze is now in its early stages but is underway,
which for complex intra-Debian Project reasons limits what you and I
can now do to debram for etch.  Debram is an odd package: it gives
metadata *on* packages, yet it *is* a package; so purely for practical
Debian development reasons, debram must be handled with a little extra
care.  You and I can and should discuss and agree on changes now, but
please don't be disappointed if some or all of the changes actually wait
for etch+1.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#384953: 'man debram': needless neologisms subramifications, misramifications, metaramification, etc.

[Thaddeus H. Black]

What timing!  I was, quite literally, just preparing to build and upload
debram 0.7.0 (probably soon to be debram 1.0.0) for etch, when I met
your bug report.

 Package: debram
 Version: 0.6.5a
 Severity: wishlist
 
 
 A counted list of similar neologisms from 'man debram':
 
 1  metaramification
 1  misramifications
 1  misramified
 1  subramification
 3  subramifications
 
 ...'ramus' is Latin for branch.  All those are just bigger words to
 signify variations of tree and branch.
 
 subramification is needless -- presumably it means sub-branch, but
 ramification itself has meant that since at least 1913:
 
  2. A small branch or offshoot proceeding from a main stock or
 channel; as, the ramifications of an artery, vein, or
 nerve.
 [1913 Webster]
 
 There are several better words and word roots, (better meaning
 shorter and plainer), e.g.:  branch, tree, root, index, category,
 class, set, group, family, genus, system, etc.
 
 Caveat:  hope it doesn't seem as though I don't appreciate the 'debram'
 package, or its name.   Many fine utils are named after less usual
 synonyms.  I'd suppose the good intention of the author was to use a
 memorable English word, or portion of one, as the name of the util; yet
 tree and all the obvious ones were already used... and 'ramify'
 wasn't.  

Precisely.  Well, regrettably I have never learned classical Latin, nor
read Cicero, Vergil, etc., which is a real lack in my education; so I
appreciate the correction.  For better or for worse, I think that we are
stuck with the honorable package name debram now.  Can we work within
this constraint, in your view?

The word neologism came new to me in your e-mail, incidentally.  I
have just looked it up.  It is ironic that it is a Greek word, because I
had wanted Latin not Greek for Debram's purpose.  Nonetheless, it was
never my intent to neologize needlessly.  The very large number of
French-, Italian-, Spanish- and Portuguese-speaking Debian users
recommended a Latin root if practicable.

Is there not a Latin verb ramere, meaning to branch?  For some
reason I had thought that there were such a verb.  I had admittedly not
even been aware of the noun ramus; I had been thinking ramere, for
which, I had thought, subramere made sense.

Is the English verb to ramify only a back-formation from the English
noun ramification?  Has the verb to ramify no direct link to the
Latin?  If it has none, then clearly you are right; my language is
twisted.

I first got the word from Tolkien's Lord of the Rings,
incidentally---another irony, since Tolkien usually avoided Latin words
when he could.  Tolkien describes the ancestral smials or burrows of
Brandy Hall as large and ramifying, which seemed to describe the
Debram catalog about as well as it did Brandy Hall.

 The man page shows good intent by trying to consistently employ the
 utility's word root to memorably describe what the util does.  With
 common words that works well:
 
 % whatis tree
 tree (1)  - list contents of directories in a tree-like format.
 
 ...it should be avoided when the only way to emphasize the word root
 is to weld on novel prefixes -- unless the task of the util was so new
 and different that preexisting terms weren't adequate.
 
 If it would help, I'd be willing to make a man page patch file
 with some tentative rewordings.

Please begin, but then check back here.  Like any other Debian
maintainer not yet acquainted with a new contributor, I would ask you to
begin in moderately small steps.  I recommend that you put three hours
or less toward your proposal before posting back here for further
discussion.  (One tries to avoid artist's pride, but to some degree it
is unavoidable.  Only human, I may need some time to grow used to an
improved terminology.)

Look for debram 0.7.0 after the 21:00 GMT sid refresh Monday night, or
earlier in incoming.debian.com.

 PS: The 'debram' index itself is quite useful, I've found all sorts  of
 good stuff with it.  Thanks for putting it out there.
 
 
 
 
 
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/dash
 Kernel: Linux 2.6.16-2-686
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
 
 Versions of packages debram depends on:
 ii  debram-data  0.6.5a  debram's 
 architecture-independent 
 ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
 ii  zlib1g   1:1.2.3-13  compression library - runtime
 
 debram recommends no packages.
 
 -- no debconf information

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#384735: derivations: FTBFS: trig.tex:1188: Illegal unit of measure (pt inserted).

[Thaddeus H. Black]

tags 384735 + confirmed pending
stop

On Mon, Aug 28, 2006 at 04:51:59PM +0100, Julian Gilbey wrote:
 tags 384735 + patch
 thanks
 
 On Sat, Aug 26, 2006 at 01:13:52PM +0200, Andreas Jochens wrote:
  Package: derivations
  Version: 0.4.20060804-1
  Severity: serious
  
  Hello,
  
  when building 'derivations' on unstable, I get the following error:
  
  trig.tex:1188: leading text:   \sphere
  trig.tex:1188: Illegal unit of measure (pt inserted).
  [...]
 
 Somehow, the author got the syntax of the \scalebox command wrong.
 This patch fixes the problem.

Fine bug report, Andreas.  Excellent patch, Julian.  Thank you both.
Someone has evidently fixed a bug in teTeX recently, breaking my
old \scalebox workaround!  I'll upload within 24 hours.

Andreas, do you repeatedly autobuild all arch-independent Debian
packages from source?  If so, good work; I am glad that you have caught
this bug.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#381899: Please expand SGL.

[Thaddeus H. Black]

Package: libalps-sgl1
Version: 1.2.2-2
Severity: minor

Hello Robert.

Please expand and/or explain the acronym SGL in the
debian/control package Description.  Such expansion
and/or explanation may be unnecessary for elements
like MPI, PVM or heap, which Debian users of your
software normally would already know; but SGL is no
standard Debian acronym.

If SGL stands for Silicon Graphics something, then
also consider moving the binary and associated -dev to
Section: contrib.

Thank you for packaging ALPS.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#372153: debram: recursive symlinks

[Thaddeus H. Black]

Please follow up your Debian bug report # 372153:
debram: recursive symlinks.  Maybe the report is
clear, but somehow it is not clear to me, so I need help
from you to understand it.  If there is no bug there, as
I (perhaps mistakenly) think, or if you are unable or
unwilling to provide more information as requested in a
timely fashion, then please close the report.  I am not
ignoring your report, but I cannot fix a bug I don't
understand and can't see.  Thanks.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#372153: debram: recursive symlinks

[Thaddeus H. Black]

tags 372153 + moreinfo
stop

On Thu, Jun 08, 2006 at 10:52:48AM -0400, Justin Pryzby wrote:
 Package: debram
 Version: 0.6.5
 Severity: important
 
 /usr/share/doc/debram-data/cmdsel.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram-data/maint.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram-data/HISTORY.gz: Too many levels of symbolic links
 /usr/share/doc/debram-data/cmdsel-debs.txt.gz: Too many levels of symbolic 
 links
 /usr/share/doc/debram-data/debram.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram/maint.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram/debram.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram/HISTORY.gz: Too many levels of symbolic links
 /usr/share/doc/debram/cmdsel-debs.txt.gz: Too many levels of symbolic links
 /usr/share/doc/debram/cmdsel.txt.gz: Too many levels of symbolic links
 
 $ ls -l /usr/share/doc/debram{-data,}
 lrwxr-xr-x 1 root root   11 Jun 23  2004 /usr/share/doc/debram - debram-data
 
 /usr/share/doc/debram-data:
 total 12
 lrwxrwxrwx 1 root root   25 Oct  6  2005 HISTORY.gz - 
 ../debram-data/HISTORY.gz
 -rw-r--r-- 1 root root 6188 Sep 14  2005 changelog.gz
 lrwxrwxrwx 1 root root   33 Oct  6  2005 cmdsel-debs.txt.gz - 
 ../debram-data/cmdsel-debs.txt.gz
 lrwxrwxrwx 1 root root   28 Oct  6  2005 cmdsel.txt.gz - 
 ../debram-data/cmdsel.txt.gz
 -rw-r--r-- 1 root root  959 Sep  3  2005 copyright
 lrwxrwxrwx 1 root root   28 Oct  6  2005 debram.txt.gz - 
 ../debram-data/debram.txt.gz
 lrwxrwxrwx 1 root root   27 Oct  6  2005 maint.txt.gz - 
 ../debram-data/maint.txt.gz

Hello Justin.  Thank you for the bug report.  On receiving your report,
I have updated my sid installation to the latest and have rebuilt the
debram (0.6.5) source on it, but am unfortunately unable to reproduce
the bug.  Would you give me some more information as to how you achieved
the output above?

When I type

$ ls -l /usr/share/doc/debram{-data,}

I get

  /usr/share/doc/debram:
  total 16
  lrwxrwxrwx  1 root root   25 May 25 16:37 HISTORY.gz - 
../debram-data/HISTORY.gz
  lrwxrwxrwx  1 root root   21 May 25 16:37 README - ../debram-data/README
  -rw-r--r--  1 root root 8406 Feb 24 23:43 changelog.gz
  lrwxrwxrwx  1 root root   33 May 25 16:37 cmdsel-debs.txt.gz - 
../debram-data/cmdsel-debs.txt.gz
  lrwxrwxrwx  1 root root   28 May 25 16:37 cmdsel.txt.gz - 
../debram-data/cmdsel.txt.gz
  -rw-r--r--  1 root root  973 Jan  8 00:55 copyright
  lrwxrwxrwx  1 root root   28 May 25 16:37 debram.txt.gz - 
../debram-data/debram.txt.gz
  lrwxrwxrwx  1 root root   27 May 25 16:37 maint.txt.gz - 
../debram-data/maint.txt.gz
  
  /usr/share/doc/debram-data:
  total 100
  -rw-r--r--  1 root root  2508 Sep  3  2005 HISTORY.gz
  -rw-r--r--  1 root root  1070 Feb 24 22:34 README
  -rw-r--r--  1 root root  8406 Feb 24 23:43 changelog.gz
  -rw-r--r--  1 root root  9127 Feb 24 22:11 cmdsel-debs.txt.gz
  -rw-r--r--  1 root root 38828 Feb 25 02:59 cmdsel.txt.gz
  -rw-r--r--  1 root root   973 Jan  8 00:55 copyright
  lrwxrwxrwx  1 root root31 May 25 16:37 debram.txt.gz - 
../../debram-data/debram.txt.gz
  -rw-r--r--  1 root root 21693 Feb 20 22:27 maint.txt.gz

which is not what is listed above and which suffers no recursive
symlinks.  Surely there are multiple levels of symlinks, but not more
than four levels, I think; and certainly not more than the kernel and
the standard tools can handle.

Which tool complains, Too many levels of symbolic links?

Please elaborate.  Thanks.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#365924: derivations: table 2.2, line 5

[Thaddeus H. Black]

tags 365924 + pending
stop

Good report.  Thank you.  I have swapped the p and q in
the development source per your suggestion.

I am not sure exactly when the next upload will come,
but when it does it will include your fix, with proper
credit to you in the changelog.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#360278: wyrd as an alternative to tk8.4

[Thaddeus H. Black]

On Sat, Apr 01, 2006 at 10:05:08AM +0200, Ren?? van Bevern wrote:
 Thaddeus H. Black [EMAIL PROTECTED] writes:
 
 Hello Thaddeus,
 
  Given wyrd, console-only users can install and use
  remind normally, can't they?  Tk8.4 Depends on libx11-6,
  which console-only users normally lack.  Refer to
  Policy 7.2.
 
 The reason why I moved tk8.4 and tcl8.4 to Recommends actually _is_
 because there are console replacements for tkremind, it has been a
 Dependency before. Because it is only a Recommends currently, you do
 not have to install TCL/Tk, if you do not want to. There are also
 other frontends for remind that would also have to be listed
 alike. Ok, these are not in Debian (yet), but that may change at any
 time.
 
 If the Recommends really annoys users, I might rather split the
 package, considering the long dependency chain that only goes out from
 one single tool in the package or move TCL/Tk to a Suggests:
 line. What do you think?

I think that your reasoning is good, and I think that you know your own
package best, so I should not argue against you; but let me say the
following, then you can decide what to do.  In ordinary English as you
know, recommends means strongly suggests, but this is not what the
technical term Recommends means in Debian.  If

Package: bar
Recommends: foo

then anyone *can* install bar (installing bar alone won't break
anything), but bar doesn't really do anything useful unless foo also is
installed.  In other words, the Recommendation advises non-foo users to
ignore bar.

However, sometimes the relationship between two packages is so strong
that you should use Recommends, anyway.  A typical example of this is 

Package: bar-data
Recommends: bar

Maybe someone wants bar-data without bar, but this is unlikely.

If you are in doubt, I think that you should just close the bug and not
apply the patch, but just pocket it.  You can always come back and apply
the patch later if you change your mind.  The judgment is yours.  The
only reason I filed the report is that using Recommends for strongly
suggests is a fairly common packaging error, when in fact what
Recommends really means is weakly depends.  But if you do not feel
comfortable with the patch, then it's not a good patch for your package.

If you have some time, Micah Anderson's bittornado (0.3.7-5)
debian/changelog entry is instructive to this end.  Thanks for replying.

-- 
Thaddeus Black


signature.asc
Description: Digital signature

Bug#360250: RFH: debram -- ramified catalog of available .debs

[Thaddeus H. Black]

Package: wnpp
Severity: normal

Debram is doing fine, but with a good comaintainer it
could do even better.  I am pleased today to open debram
to collaboration leading to eventual comaintenance.  One
stable, genial collaborator is sought.

The principal duty will be to join me in ramifying
(sorting and cataloging) new packages for debram as they
enter Debian's archive.  The role gives scope for you to
grow into a key development player as you demonstrate
reliability, do useful work and learn the debram system.
You need not be a Debian package Maintainer yet, but for
general background you should bring at least a little C
or C++ programming experience.  A limited acquaintance
with ELF wouldn't hurt, either.

At a minimum, six months' experience using Debian is
required; one year's is preferred.  Knowledge of
Chinese, Japanese and/or Korean (which I lack but debram
needs) would be a plus.  I will spend the time needed to
mentor the right volunteer.

Reply to me off-list (or on the BTS, but not on
debian-mentors) if interested.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#360278: wyrd as an alternative to tk8.4

[Thaddeus H. Black]

Package: remind
Severity: minor

Given wyrd, console-only users can install and use
remind normally, can't they?  Tk8.4 Depends on libx11-6,
which console-only users normally lack.  Refer to
Policy 7.2.

Apply the small patch attached if you like it and if you
think it correct.  Thank you for maintaining remind.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]
diff -ruN remind-03.00.24.orig/debian/changelog remind-03.00.24/debian/changelog
--- remind-03.00.24.orig/debian/changelog   2006-03-31 19:20:22.161864000 
+
+++ remind-03.00.24/debian/changelog2006-03-31 20:55:18.670863440 +
@@ -1,3 +1,11 @@
+remind (03.00.24-2.1) unstable; urgency=low
+
+  * debian/control:
++ Closes: #nn: Recommend wyrd as an alternative to tk8.4
+  and tcl8.4, patch by Thaddeus H. Black [EMAIL PROTECTED]
+
+ -- Ren?? van Bevern [EMAIL PROTECTED]  Thu, 01 Jan 1970 00:00:00 +
+
 remind (03.00.24-2) unstable; urgency=low
 
   * Scripts in www/ are examples rather than documentation.
diff -ruN remind-03.00.24.orig/debian/control remind-03.00.24/debian/control
--- remind-03.00.24.orig/debian/control 2006-03-31 19:20:22.161864000 +
+++ remind-03.00.24/debian/control  2006-03-31 19:21:15.893695960 +
@@ -8,7 +8,7 @@
 Package: remind
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: tk8.4 | wish, tcl8.4 | tclsh
+Recommends: tk8.4 | wish | wyrd, tcl8.4 | tclsh | wyrd
 Description: a sophisticated reminder service
  Remind allows you to remind yourself of upcoming events and
  appointments.  Each reminder or alarm can consist of a message sent


signature.asc
Description: Digital signature

Bug#360278: version 03.00.24-2

[Thaddeus H. Black]

I forgot to note the remind package version number in
the pseudo-header.  Here it is:

Package: remind
Version: 03.00.24-2

-- 
Thaddeus Black


signature.asc
Description: Digital signature

Bug#338520: ITP: derivations -- book: Derivations of Applied Mathematics

[Thaddeus H. Black]

Package: wnpp
Severity: wishlist
Owner: Thaddeus H. Black [EMAIL PROTECTED]

* Package name: derivations
  Version : 0.2.20051110
  Upstream Author : Thaddeus H. Black [EMAIL PROTECTED]
* URL : http://home.ntelos.net/~b-tk/derivations/
* License : GPL-2
  Description : book: Derivations of Applied Mathematics

Understandably, program sources rarely derive the mathematical formulas
they use.  Not wishing to take the formulas on faith, a user might
nevertheless reasonably wish to see such formulas somewhere derived.

Derivations of Applied Mathematics is a book which documents and
derives many of the mathematical formulas and methods implemented in
free software or used in science and engineering generally.  It
documents and derives the Taylor series (used to calculate
trigonometrics), the Newton-Raphson method (used to calculate square
roots), the Pythagorean theorem (used to calculate distances) and many
others.

The book is a work in progress.


signature.asc
Description: Digital signature

Bug#324166: sr -help gratuitously insults the user.

[Thaddeus H. Black]

Package: surfraw
Version: 2.1.0-1
Severity: important

This is embarrassing.  In sr -help output, please
change

 -p0rn=yes|no Yes, yes, harder, deeper, faster, oh baybe

to

 -amoral=yes|no   Deactivate moral content-filtering

Keep the existing option as an undocumented alias for
backward compatibility.

I wish to emphasize that I am not trying to tell the
maintainers or anyone else how to run their lives.
However, this foolish bug is by definition `important'
because it unnecessarily renders the package largely
unusable to a significant minority of users, including
me.

Don't be angry.  Consider.  In the U.S. (at least), if
your boss were familiar with the output of sr -help
and still installed surfraw on your machine, you could
sue him over it.  Observant Catholics, Orthodox and
Mormons who do not promptly uninstall the package will
find themselves going to confession over it.  To other
traditionally decent people, sr -help is at least
insulting.  It is hard to imagine many women
liking sr -help.  Teenage hackers' conservative
parents who had thought Debian a positive influence are
likely to change their minds.  Et cetera.

We should respect those people.

Does this bug report challenge your right intentionally
to insult people?  No.  That would be a different
discussion which this report does not mean to open.
However, unless you tell me otherwise, I have no reason
to believe the insult intentional!  Presumably whoever
wrote the line in question was only trying to describe
surfraw's functionality in a colorful way.  But is there
any reason for a search-engine front end to
be rated R?  Surfraw is a useful tool.

You could say, what's the big deal, dude? or what
about bible-kjv? but please don't say that; it wouldn't
be right.  Out of respect and tolerance for the minority
of users who love Debian but feel differently about
moral issues than you might, please fix this, along with
any related problems you know of in the man page and
other documentation.

Thanks.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#314830: Priority in debian/control

[Thaddeus H. Black]

Package: libttf-dev
Version: 1.4pre.20030402-1.1
Severity: minor

  Note: FreeType 1 (libttf soname 2, Debian package libttf2) is obsolete.
FreeType 2 (libfreetype soname 6, Debian packages libfreetype6 and
libfreetype6-dev) has arrived.  The FreeType 2 API is a lot simpler
than the one in 1.x while being much more powerful.  We thus
encourage you to adapt your source code to it as this should not
involve much work.

If libttf2 is obsolete, then shouldn't libttf-dev have Priority extra?

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


pgpI9qrig4DFP.pgp
Description: PGP signature

Bug#314481: swapped Descriptions in debian/control

[Thaddeus H. Black]

Package: libmxml1
Version: 2.2-1

Greetings Eduardo.  The one-line Descriptions of
libmxml1 and libmxml-dev seem to be swapped in
debian/control.  A candidate patch is attached for your
review, redaction and approval.

If this bug report proves incorrect, please just close
the report.  Thank you for mxml.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]
diff -ruN mxml-2.2-1/debian/changelog mxml-2.2-1.1/debian/changelog
--- mxml-2.2-1/debian/changelog Thu Jun 16 14:25:43 2005
+++ mxml-2.2-1.1/debian/changelog   Thu Jun 16 14:48:00 2005
@@ -1,3 +1,9 @@
+mxml (2.2-1.1) unstable; urgency=low
+
+  * Unswapped binary Descriptions in debian/control (closes: #??).
+
+ -- Thaddeus H. Black [EMAIL PROTECTED]  Thu, 16 Jun 2005 00:00:00 +
+
 mxml (2.2-1) unstable; urgency=low
 
   * New upstream release (closes: #287839)
diff -ruN mxml-2.2-1/debian/control mxml-2.2-1.1/debian/control
--- mxml-2.2-1/debian/control   Thu Jun 16 14:25:43 2005
+++ mxml-2.2-1.1/debian/control Thu Jun 16 14:27:32 2005
@@ -9,12 +9,12 @@
 Section: libdevel
 Architecture: any
 Depends: libmxml1 (= ${Source-Version})
-Description:  small XML parsing library
+Description: development files for libmlxml
  small and simple XML parsing library
 
 Package: libmxml1
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: development files for libmlxml
+Description: small XML parsing library
  development files for the mxml library


pgpjeJKBb2SfJ.pgp
Description: PGP signature

Bug#313610: ITP: libnoise -- a portable, open-source, coherent noise-generating library for C++

[Thaddeus H. Black]

It looks interesting.

 libnoise is a portable C++ library that is used to generate coherent noise,
 a type of smoothly-changing noise.

Is coherent noise another name for bandlimited noise, or is it
something else?

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


pgpX652stVSna.pgp
Description: PGP signature

Bug#282283: Ceasing dselect work

[Thaddeus H. Black]

I do not plan to pursue this RFH any longer.  I now see
why Scott lost interest.  If someone reading this wants
to develop dselect, he is invited to step right in.

Partial rationale:

In studying the dselect source, one of the things I did
was to go over and use aptitude for a while.  I had
never really used aptitude before, so I wanted to see
what made it different.  Unfortunately for dselect
development, what I discovered was that I prefer
aptitude over dselect.

There is an old question in Debian as to whether and
when developers should compete against one another in
attacking the same problem separately (witness Gnome and
KDE, for instance).  The right answer to this question
depends in my view on the specific problem, projects and
personalities involved.  Sometimes it seems better to
standardize on one project; sometimes it seems better to
compete.  It depends.

In the specific case of Debian package management, my
view in the matter has shifted somewhat since I first
replied to this RFH.  I now tend to feel that the Debian
Project should standardize; that we should encourage
Debian sysadmins to use aptitude, layered atop apt,
layered atop dpkg.  If dselect's interface is preferred,
then let this be further layered *atop aptitude*.
Dselect as an alternative to aptitude should probably be
deprecated by us.

If anyone should pursue this RFH further, my well wishes
go with him.  Good luck.

Signing off.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]


pgpEpTzLzlMwp.pgp
Description: PGP signature

Bug#282283: [PATCH] dpkg: add transparency support to dselect, misc. fixes

[Thaddeus H. Black]

Bernhard Fischer:

 Attached patch implements support for transparent terminals in dselect.
 It also contains various cosmetic fixes as well as a potential real bug
 in lib/varbuf.c.

Hi Bernhard.  Please see [http://bugs.debian.org/282283], reported by
dpkg's lead maintainer Scott James Remnant.  After reading the bug log,
you may wish to take over from me there.  You would seem at first glance
to have the motivation and the skills for it, and by contributing this
patch it seems to me that you have earned the right.

As to me, I have not lost interest, but my progress on # 282283 is too
slow for Dpkg development to wait for me, if there is a more capable
person who also has interest and who will devote more time than I will.
If you do not act on this, eventually I will, but in the meantime you
are not required to wait for me.

 [i sent this to dpkg-devel a few weeks ago but got no reponse, so
 retrying here; please keep me CC'ed, i'm not on d-d]

Sorry for overlooking your earlier post to dpkg-devel.  The overlook was
inadvertent.

(For completeness of the # 282283 BTS record to which this message is
copied, it is noted here that Bernhard's patch is found at
[http://lists.debian.org/debian-devel/2005/05/msg01021.html].)

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]


pgpd1w1SY9xmO.pgp
Description: PGP signature

Bug#282283: dselect development

[Thaddeus H. Black]

Status update.  Scott has perhaps been
skeptical---properly so---of my commitment to dselect
development.  He does not know me, after all, and I have
contributed no patches as yet.  However, matters proceed
according to plan.  At present, I am very slowly reading
my way through the latest experimental dpkg sources
(1.13.2 as of today).  This is a learning experience for
me.  In November Scott said something about standing on
one's head to understand iwj-C++, but to me the dselect
source really doesn't look too bad; by the end of the
calendar year I should be fairly familiar with it.

I remain unfamiliar with autotools, but apparently this
is not much of a handicap in treating the dselect bugs.
I can learn autotools over time.  A greater problem for
me is that I have no experience in managing long, long
lists of old BTS reports.  It is hard to know where to
start.  At the present moment, it is not clear to me
that anything at all should be done about many of the
dselect bug reports, but I am not nearly so confident
yet as to propose closing a lot of open bugs.

After reviewing the BTS logs, lacking other guidance, my
current inclination is to start with the TODO item of
adding support for Enhances.  Perhaps supporting
Enhances without slowing program execution involves
constituting a look-up hash with the standard library's
search.h.  Apparently adding Enhances support begins
in the dpkg source proper, so I have some work to do.

Anyway, as my earlier messages in the #282283 BTS log
indicate, please do not expect anything from me too
soon.  Some of you are highly skilled hackers, but I
still have much to learn, and dpkg is sufficiently
important a package that I do not feel comfortable
contributing dpkg patches until I understand the overall
source better.  Gandalf observed that Barliman Butterbur
could see through a brick wall in time.  So if you are
Gandalf, permit me to play Butterbur's role today.  I
shall need some time to see through this wall.

If anyone else here is already working on the
dpkg/dselect Enhances problem, please advise.
Otherwise, contact me any time, for any reason.

-- 
Thaddeus H. Butterbur Black
(staring hard at a brick wall)
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]


pgpGFytSXoDxA.pgp
Description: PGP signature

Bug#295155: ITP: steam -- environment for cooperative knowledgemanagment

[Thaddeus H. Black]

Good idea.

 Different from most other cooperation tools is the novel possibility of
 self-organisation and self-administration by the members within the virtual
 environment.

Can server and client both be installed with minimal dependencies?  For
example, without xlibs?

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]


pgp4p707C0daF.pgp
Description: PGP signature