Bug#1061118: debram: The debram binary is missing from the package.
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
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
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++
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
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
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
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
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
> 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
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
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
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
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 lsb-r
Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C
> I need sponsor. Have you got your sponsor? signature.asc Description: PGP signature
Bug#982341: ITP: simlib -- SIMulation LIBrary for C++
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
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
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 , &obj ); > > ^ > > 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
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
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
Control: tags -1 - upstream signature.asc Description: Digital signature
Bug#836943: (no subject)
Control: tags -1 - upstream signature.asc Description: Digital signature
Bug#842472: [Bug-wget] [PATCH] new option --convert-specified-links
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
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
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)
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
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)
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
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
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
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
> 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
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
> 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
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
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
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
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 .\" 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 or .B .TP Go forward .B or .B .TP Go home .B .TP Open file .B .TP Reload .B or .B .TP Reload, overriding the cache .B or .B .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#813999: O: debmirror -- package is now orphaned
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#813998: O: debmirror -- package is now orphaned
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#737057: debmirror: Please add xz support
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
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 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 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&arch=mips64el&ver=2.0.0.4&stamp=1441108414 > > Thanks, > James
Bug#797384: debmirror: i18n hash sums not checked
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#789293: debram: FTBFS with pbuilder: dsc file missing newline before BEGIN PGP SIGNATURE line
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
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
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#619361: No longer capable of mirroring debian-installer section for Ubuntu *-updates
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#581013: [debmirror] debmirror ignore the section 'debian-installer' for the distribution '.*-proposed-updates'
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#768532: ITA: debmirror
For reference, the bug report (with patch) to which I referred yesterday was #787760. signature.asc Description: Digital signature
Bug#768532: ITA debmirror
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
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
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#787760: Add the file download method
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>=I Specify the method to download files. Currently, supported methods are -B, B, B, and B. +B, B, B, and B. The B 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
Bug#688828: Solution or workaround?
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#690161: derivations: compatibility with poppler 0.20
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 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#482446: The Debian package debram, and your ancient patch
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.
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#677881: debram: diff for NMU version 1.0.3-0.2
> > 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#677881: debram: binNMUs are not installable
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#660986: derivations: please migrate the libpoppler-dev build dependency to libpoppler-private-dev
> > 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#566340: derivations: Versioned build dependency on texlive-base-bin
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#566340: derivations: Versioned build dependency on texlive-base-bin
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#453160: debram: FTBFS: utf8.h:15: error: expected declaration specifiers or '...' before 'size_t'
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.
[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: This ITP remains active.
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: ITP: nist-dlmf -- NIST's Digital Library of Mathematical Functions
The following ITP went to 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
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#413128: ITP: nist-dlmf -- NIST's Digital Library of Mathematical Functions
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#384953: 'man debram': needless neologisms "subramifications", "misramifications", "metaramification", etc.
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#372153:
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.
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#384953: 'man debram': needless neologisms "subramifications", "misramifications", "metaramification", etc.
ram works, I *think* that debram is pretty transparent. Nevertheless, if a better expression occurs to you---more accurate but not less accessible---then I should be glad to receive it. If the man page confuses users to think that debram(1) somehow exercises artificial intelligence, then this is a "Severity: important" bug which needs correcting immediately. Of course all the numbers are preassigned by a human (usually 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#384735: derivations: FTBFS: trig.tex:1188: Illegal unit of measure (pt inserted).
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#384953: 'man debram': needless neologisms "subramifications", "misramifications", "metaramification", etc.
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
Bug#381899: Please expand "SGL".
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
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
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
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
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#360278: version 03.00.24-2
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#360278: wyrd as an alternative to tk8.4
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#360250: RFH: debram -- ramified catalog of available .debs
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#338520: ITP: derivations -- book: Derivations of Applied Mathematics
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.
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
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
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++
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
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
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
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 . 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
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
Bug#292667: ITP: autoreply -- A safe, rate-limited autoresponder
Good idea. > * Package name: autoreply > Version : 1.2 > Upstream Author : Giles Lean > * URL : http://www.nemeton.com.au/sw/autoreply/ > * License : BSD > Description : A safe, rate-limited autoresponder > > Autoreply is a simple autoresponder useful for replying to > email upon receipt. I might use this package. Good luck. pgpwW1v8aHVE5.pgp Description: PGP signature