minimizing downtime of a daemon
One of the template NM questions is about how to minimize the downtime of a daemon during package upgrade (in maintainer scripts). ssh does an /etc/init.d/ssh restart in postinstall, which (with luck) means that there will be *no* downtime. This doesn't seem to be necessary for allowing ssh upgrades, since running /etc/init.d/ssh stop over an ssh connection doesn't disconnect existing ssh connections, but only prevents establishing new connections until the next start. This is different from how everybody else seems to do it, but does accomplish the goal. But, Debian doesn't seem to do actively persue this goal. Of course, apt-get install daemon-package should always work, and really minimize the downtime, but doesn't solve the general problem for the dist-upgrade case, or for apt-get install many-packages, where it would be a small pain to have to figure out which packages are running daemons. The service isn't actually guaranteed to work during the upgrade anyway, even if it isn't stopped, due to the potential for inconsistencies between files on disk (eg. changed config file format, reread at each connection by a daemon child process, or interrelated files). Packages using debhelper dh_installinit end up with an /etc/init.d/foo stop in prerm and an /etc/init.d/foo start in postinst . During eg. a dist-upgrade, a maximal number of packages are dpkg --unpacked, and afterwards are dpkg --configured. This decidedly does *not* minimize daemon downtime, since it allows an arbitrarily large number of packages to be unpacked and configured before the daemon is restarted. debhelper intends to do what's needed with a simple interface. If it was acceptable to require more package-specific information, it would be possible to only stop the service if it wasn't provided by the new version of the package. (Since binary packages with multiple daemons are uncommon, it is more realistic to think of the same scenario with info documents, which also get registered in postinst, and deregistered in prerm). debhelper would then need an interface to specify that a daemon was included in certain previous versions of the package, and removed at some critical versions. Or, versions in which a daemon is removed (and versions between that version and the next stable release) could be required to have custom, not-generated maintscripts. This is an uncommon problem for daemons, but removal of info documents is much more frequent, and presents the same trouble. The implementation would involve the following in preinst (*not* prerm, since it may not be known in advance that those files/daemons would be removed): ver_removed=1.2-3 ( [ $1 = install ] || [ $1 = upgrade ] ) dpkg --compare-versions $2 lt $ver_removed deregister_info stop_server ... # postrm abort-[install|upgrade] should re-register them, and restart # the server. With this code, the info document and server will always be available *during* upgrades of earlier versions, since dpkg uses an atomic rename(). Upgrading to the critical version correctly stops the server and deregisters the document *before* it is removed. I'm particularly interested in this question since I'm writing a document about dpkg, and, in particular, about use of maintainer scripts. I'm going through NM, and (so far) haven't been asked about this. If you don't want to spoil the fun for other NM's, you might reply to me personally, or think of the same question phrased in terms of info documents and dh_installdocs instead of daemon's and dh_installinit. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
stopping daemons in prerm/preinst (and info doc registration)
It is common for daemons to be stopped in pre{inst,rm}. This makes
sense, but I wonder what the motivation is.
I see two possible explanations:
1. Both postinst and prerm can often abstain from checking their
arguments. prerm is called with any of:
remove [in-favour]
[failed-]upgrade
deconfigure
Stopping a daemon in remove and deconfigure makes sense, and could
make sense for upgrades, too. Is the intent to not provide a false
promise that the daemon will work during the upgrade, since the files
on disk may be in an inconsistent state? (Eg. the daemon executable
has been updated to require a new file format, but that file hasn't
yet been updated, but the daemon forks+opens+parses that file for each
client).
2. Package self containment. If, hypothetically, a package had
multiple daemons (here, daemon means initscript), unconditionally
stopping all of them in prerm would avoid the need for preinst in
future revisions of the packages to stop those daemons, after
relevant checks of $2. This makes the package completely
self-contained WRT upgrades; future revisions don't need any cruft
to handle old upgrade paths (which would have to remain at least until
after the following stable release).
The alternative is to restart the daemon in postinst, and attempt to
provide no downtime; but, still the daemon isn't guaranteed to work
during the upgrade (ssh does this..).
I note that packages containing multiple initscripts are uncommon, but
this same thing also happens for info documents; debhelper presently
registers the document in postinst (makes sense) and deregisters it
in prerm, both the remove *and* upgrade paths. This means that
there's a period during upgrades that the info document isn't
advertised, even though the file itself is guaranteed to exist (as
long as both new and old versions of the package include it). The
advantage, again, is that new package revisions don't need preinst to
conditionally deregister the document.
Are these both considered important?
Please Cc: me.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
installing a package from Config-files state earlier than the most recent stable release
Package upgrades skipping a stable release are advertised as not guaranteed to work, which allows maintainers to drop support for upgrades from versions earlier than oldstable in their uploads to unstable. However I've never heard a requirement that package versions earlier than the most recent stable release be purged before installing. Recall that a package can be in Config-files state whenever it has a postrm script, or it owns conffiles; also, if postrm fails, it is considered to be still in Config-files, even though its conffiles will have been removed from the filesystem and package list. Example: U: Install foo-1, which either owns a conffile or has a postrm script U: Remove (but don't purge) foo M: Maintainer uploads foo-2 D: Debian releases $stable, which includes foo-2 U: Dist-upgrade to $stable M: Maintainer uploads foo-3, which drops support for foo-1 U: Dist-upgrade to $testing U: Install foo-3 from testing, from state Config-files of foo-1, but foo-3 only handles upgrade from foo-2; something terrible happens. Does this mean that maintainers should be expected to support the maintscript install $2 cases for ancient versions, or is there some other convention of which I remain unaware? Please Cc me. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/usr/share and -common pkgs
-common packages are used to reduce the size of the archive; arch independant data need not be included in each of the 10+ arch-specific binary packages; only one package is needed. As expected, most of the contents of the -common packages are in /usr/share: time zgrep -Ff (apt-cache search -n -- -common |sed -ne 's/[^a-z0-9.+-].*//; s/^/\//; /-common/p') /home/pryzbyj/conflict/Contents-i386.gz |grep -Eo '^(usr/)?[^/]*' |uniq -c |sort -nr 46366 usr/share 3319 usr/lib 586 etc 298 var 165 usr/bin 133 usr/include 83 usr/sbin 6 sbin 3 usr/games 3 usr/X11R6 The LFS intent of separating /usr/share and /usr/lib is to allow a filesever to export /usr/share to machines of *any* architecture running the same OS (/usr is supposed to be sharable to machines of the *same* arch). But this is considerably complicated by the fact that many packages *depend* on their -common data (90), or the other way around (20); some both (12) [out of 271]: apt-cache search -n -- -common |sed -ne 's/[^a-z0-9.+-].*//; h;G; s/\n/ /; s/-common//p;' |while read p q; do r=`apt-cache show $q 2/dev/null || continue`; grep -q ^Depends:.* $p[ (,] $r || continue; echo $p; done Twiddle the p's and q's and second || to to taste. Years ago I asked Zed Pobre about this, and he said that the arch and indep packages should recommend each other; in the typical case, they should both be installed; in the fileserver case, only arch is installed on the clients; only indep on the server. Is this recommendation widely accepted, or just for cases where likeliness of using a fileserver is relatively high? Should policy make a recommendation^W^W^W^Wbugs be filed? If not, what is the suggested way to run such a fileserver setup for these packages? equivs? Please Cc: me. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
early dpkg prototype implementation in perl
Apparently dpkg was initially written/prototyped in perl; does there exist somewhere a copy of that implementation? Please Cc: me, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
solicitation for DevRef suggestions for usertags users (Re: Bug#367876: developers-reference: please recommend usertags for mass bug filing)
On Thu, May 18, 2006 at 08:36:05AM +0900, Osamu Aoki wrote: On Thu, May 18, 2006 at 11:01:52AM -0400, Justin Pryzby wrote: Package: developers-reference Version: 3.3.7 Severity: wishlist IMO it is a best-practice to set usertags when filing lots of bugs for a given problem, Good idea. preferably to a publically-known user such as [EMAIL PROTECTED] This choice of e-mail address is debatable depending on what was the problem. Thus please get consensus how it should be chosen and what will be the choice of e-mail adress for each types of reasons on [EMAIL PROTECTED] Please move discussion there and give us final result as a patch :-) What usertags users are in common use? I think everyone will agree that public usernames should be used whenever there is some common interest, for transparency, rather than random groups people all tweaking their own individual bug collections. Please Cc: me, not subscribed Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the experimental autobuilder team (or: For Those Who Care About Experimental...)
On Tue, Apr 11, 2006 at 09:28:27PM +0200, Wouter Verhelst wrote: Hello World, As many of you undoubtedly know, experimental is autobuilt these days. ... However, it will only work if the build-dependencies are fully specified; i.e., if a package 'foo' in experimental requires another package in experimental (let's call that one 'bar'), and another package needs 'foo' from experimental to build, then just installing 'foo' from experimental isn't going to cut it; you would end up with a command line like apt-get install foo=experimental version, which would try to install the experimental version of foo with the unstable version of bar, and fail because of unmet versioned dependencies. The solution[1] to this problem lies in a different use of the build-depends field: we're hereby asking maintainers who upload to experimental, to make sure to fully specify their build-dependencies on experimental packages; not just the packages they directly depend on, but also the packages they indirectly, through other packages, depend on. Let me repeat that, because it's quite important: if you upload a package to experimental, and you declare a versioned build-depends on something that is also in experimental, then you *must* make sure that you also declare a versioned build-depends on any other packages from experimental that your direct build-dependencies depend on; otherwise, your package *will not build*. It is, of course, not necessary to also declare versioned build-depends on indirectly-required packages from unstable. Is there a tool to recurively list version of dependencies, as reportbug does? Justin (Please Cc me) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
solicitation for requests for inclusion in best-practice cronjob example script; was Re: Bug#356689: devscripts: please include a best-practice (example?) script
On Mon, Mar 13, 2006 at 05:23:13PM +, Julian Gilbey wrote: On Mon, Mar 13, 2006 at 10:15:30AM -0500, Justin Pryzby wrote: Package: devscripts Version: 2.9.15 Severity: wishlist I'd like to see a /u/s/d/devscripts/examples/dev-best-practices script which runs things like `rcalert`, `wnppalert` and `bts bugs from: tag=moreinfo`. Stuff that a sane developer could want to know about, related to stuff they're actively involved in, only. Are there any other tools whose output could reasonably be included in a once-a-week message generated by cron? Developers, is is there any other output which might be interesting to include? Sounds reasonable. Can I make `bts bugs` dump the html or formatted text? I'll work on a 0th order approximation to the patch .. what do you think? Would be useful, indeed. Okay; I'm sending a followup which is my first attempt at providing a best-practice script. At least 50% of what I want is to provide something which can be expanded on when people come up with other useful stuff. None of it should be very noisy at all for people following best-practices, but should still catch as many things as possible of course. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sextractor 2.4.4-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 20 Jan 2006 19:37:51 -0500 Source: sextractor Binary: sextractor Architecture: source i386 Version: 2.4.4-1 Distribution: unstable Urgency: low Maintainer: Justin Pryzby [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: sextractor - source extractor for astronomical images Closes: 335745 337281 Changes: sextractor (2.4.4-1) unstable; urgency=low . * New upstream release; closes: 335745. - 'fixes a few triggering issues with WIN parameters' - ./debian/copyright: update URL * Indent homepage pseudo field as per DevRef best-practice. * Clarify public-domain license in ./debian/copyright and ./debian/rules. * Update TODO with stuff from BTS that isn't yet fixed now. * Apply a patch to allow cross-compilation with mingw. * Conflicts+Replaces: sextractor-doc; closes: #337281. * Transpose ./configure and CFLAGS. * Allowing cross compilation with mingw32. Files: 83abacdc39d5c30bbe34cd06f54deb05 597 science extra sextractor_2.4.4-1.dsc 9f1389ae9229c65f0a6a0b264deb314f 1318197 science extra sextractor_2.4.4.orig.tar.gz c4e6e650b1fc798f7e7c2a52e519b7f4 7378 science extra sextractor_2.4.4-1.diff.gz 58fb66854246132fa45ed0cd06ba7796 1141870 science extra sextractor_2.4.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD0h0Ws3U+TVFLPnwRArQoAJ9W1GbCl2e0rNA5mR3iIeCmmQYN1QCeL/8Y pQ95HF06OJvJmrqPtQ2eK/s= =Bl3O -END PGP SIGNATURE- Accepted: sextractor_2.4.4-1.diff.gz to pool/main/s/sextractor/sextractor_2.4.4-1.diff.gz sextractor_2.4.4-1.dsc to pool/main/s/sextractor/sextractor_2.4.4-1.dsc sextractor_2.4.4-1_i386.deb to pool/main/s/sextractor/sextractor_2.4.4-1_i386.deb sextractor_2.4.4.orig.tar.gz to pool/main/s/sextractor/sextractor_2.4.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted groundhog 1.4-7.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 15 Jan 2006 17:31:44 -0500 Source: groundhog Binary: groundhog Architecture: source i386 Version: 1.4-7.1 Distribution: unstable Urgency: low Maintainer: Stephen M Moraco [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: groundhog - A simple logic game Closes: 346716 Changes: groundhog (1.4-7.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346716. Files: ffa13ca2a4e5d7847bda35327d702845 685 games optional groundhog_1.4-7.1.dsc 7b95eff91f44622c0ec50247fa4bf0fc 30130 games optional groundhog_1.4-7.1.diff.gz fe2c829928188cb74eac6ba2f9110506 34592 games optional groundhog_1.4-7.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDz6WHNFDtUT/MKpARAr69AKC14ONdd2uvGmJ5DUmfAewbHQzEogCgsdX4 j4ioBVNAzUiIa4KCgvpU41k= =Wwnr -END PGP SIGNATURE- Accepted: groundhog_1.4-7.1.diff.gz to pool/main/g/groundhog/groundhog_1.4-7.1.diff.gz groundhog_1.4-7.1.dsc to pool/main/g/groundhog/groundhog_1.4-7.1.dsc groundhog_1.4-7.1_i386.deb to pool/main/g/groundhog/groundhog_1.4-7.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quark 3.21-3.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:24:06 -0500 Source: quark Binary: quark Architecture: source i386 Version: 3.21-3.1 Distribution: unstable Urgency: low Maintainer: Sven Luther [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: quark - music player daemon controlled from the gnome panel or cli Closes: 347041 Changes: quark (3.21-3.1) unstable; urgency=low . * Non-maintainer upload with maintainer approval. * Update build-deps for xlibs-dev removal; closes: #347041. Files: 52dff4d78ee61022d2c1e49065f37c91 739 sound optional quark_3.21-3.1.dsc d4548d881dc3d47e357cd1a6a3b1f217 17006 sound optional quark_3.21-3.1.diff.gz f6cd38c41a46d8baf6ae8232f6b0c829 43430 sound optional quark_3.21-3.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzhp9riZpaaIa1PkRAn+WAKDbuqnRgxPzy1zsXyfbKgIdjcVA5ACffpXt HP9oys2grUHx40aeO+OLUFI= =l7Fl -END PGP SIGNATURE- Accepted: quark_3.21-3.1.diff.gz to pool/main/q/quark/quark_3.21-3.1.diff.gz quark_3.21-3.1.dsc to pool/main/q/quark/quark_3.21-3.1.dsc quark_3.21-3.1_i386.deb to pool/main/q/quark/quark_3.21-3.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-randr-applet 0.2-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Jan 2006 14:28:05 -0500 Source: gnome-randr-applet Binary: gnome-randr-applet Architecture: source i386 Version: 0.2-1.1 Distribution: unstable Urgency: low Maintainer: Sven Luther [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: gnome-randr-applet - Simple gnome-panel front end to the xrandr extension Closes: 346698 Changes: gnome-randr-applet (0.2-1.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346698. Files: 998e95f0bcb5c107496bde9f008ab189 753 gnome optional gnome-randr-applet_0.2-1.1.dsc 566a9bb620399bf948957cbd26b0072c 17598 gnome optional gnome-randr-applet_0.2-1.1.diff.gz d1290dd0b69acd4c87528bf9adeefa00 9118 gnome optional gnome-randr-applet_0.2-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzkWGriZpaaIa1PkRAsfnAKCPtbF7HOSOd7G+nl3KgL7fh//epQCgjRFZ 6GdNBe/e+FrHBkCb8me6mJM= =YQmU -END PGP SIGNATURE- Accepted: gnome-randr-applet_0.2-1.1.diff.gz to pool/main/g/gnome-randr-applet/gnome-randr-applet_0.2-1.1.diff.gz gnome-randr-applet_0.2-1.1.dsc to pool/main/g/gnome-randr-applet/gnome-randr-applet_0.2-1.1.dsc gnome-randr-applet_0.2-1.1_i386.deb to pool/main/g/gnome-randr-applet/gnome-randr-applet_0.2-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted baycomepp 0.10-8.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Jan 2006 01:11:52 -0500 Source: baycomepp Binary: baycomepp Architecture: source i386 Version: 0.10-8.1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: baycomepp - Drivers for the HB9JNX packet radio epp modem Closes: 346650 Changes: baycomepp (0.10-8.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346650. Files: b0630cfa00e5fb429d539b0f3dde377f 664 hamradio optional baycomepp_0.10-8.1.dsc d3ddcc0d124c7c37cee2e185fb9cb9a8 10215 hamradio optional baycomepp_0.10-8.1.diff.gz e857f9169ab3042f5f17c56706a94180 34 hamradio optional baycomepp_0.10-8.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzkYvriZpaaIa1PkRAi8ZAJ9GukVLMjlYyoIDZVi0ujDFCNivbQCfVLRq QwbhnBRUPurDux9FSJBdam4= =j330 -END PGP SIGNATURE- Accepted: baycomepp_0.10-8.1.diff.gz to pool/main/b/baycomepp/baycomepp_0.10-8.1.diff.gz baycomepp_0.10-8.1.dsc to pool/main/b/baycomepp/baycomepp_0.10-8.1.dsc baycomepp_0.10-8.1_i386.deb to pool/main/b/baycomepp/baycomepp_0.10-8.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted baken 0.5.3-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Jan 2006 01:07:08 -0500 Source: baken Binary: baken Architecture: source i386 Version: 0.5.3-2.1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: baken - Visualisation of European VHF/UHF and microwave beacons Closes: 346687 Changes: baken (0.5.3-2.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346687. Files: eb49fee886b3d5077db8480a7e55047e 613 hamradio optional baken_0.5.3-2.1.dsc 2ff29c2b3028a8205a317ec4aef8040e 2688 hamradio optional baken_0.5.3-2.1.diff.gz 2dec051d97f388a85dbe81399755ca39 207280 hamradio optional baken_0.5.3-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzkYtriZpaaIa1PkRAqJxAKC0vKu2yFIIunsMqIcO2Hj9e+C01ACgzynf Kk3VcqdroSh+CBgF1zqXse4= =MDg3 -END PGP SIGNATURE- Accepted: baken_0.5.3-2.1.diff.gz to pool/main/b/baken/baken_0.5.3-2.1.diff.gz baken_0.5.3-2.1.dsc to pool/main/b/baken/baken_0.5.3-2.1.dsc baken_0.5.3-2.1_i386.deb to pool/main/b/baken/baken_0.5.3-2.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ibp 0.21-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Jan 2006 01:44:06 -0500 Source: ibp Binary: ibp Architecture: source i386 Version: 0.21-2.1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: ibp- Viewer for the International Beacon Project Closes: 346688 Changes: ibp (0.21-2.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346688. Files: 8dfa5e6b993d2debb16c16641a528e4e 624 hamradio optional ibp_0.21-2.1.dsc bc6bf5b5a6c37dd5ee53dab7ae9eb8ea 11508 hamradio optional ibp_0.21-2.1.diff.gz 70bc5b39daaf1380a55b0aa1e9431633 23196 hamradio optional ibp_0.21-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzkYyriZpaaIa1PkRAsWyAKD7lKq65InpFqJg9VjTyVJ1JM/l9wCeMwhl 16AsGGApnmPofVP+Eb0bJDo= =7OM+ -END PGP SIGNATURE- Accepted: ibp_0.21-2.1.diff.gz to pool/main/i/ibp/ibp_0.21-2.1.diff.gz ibp_0.21-2.1.dsc to pool/main/i/ibp/ibp_0.21-2.1.dsc ibp_0.21-2.1_i386.deb to pool/main/i/ibp/ibp_0.21-2.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted twlog 1.3-3.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Jan 2006 02:31:34 -0500 Source: twlog Binary: twlog Architecture: source i386 Version: 1.3-3.1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: twlog - Logging program for hamradio operators Closes: 346900 Changes: twlog (1.3-3.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346900. Files: 930b482d641c7f0383072e623756ab67 627 hamradio optional twlog_1.3-3.1.dsc 8b7493b06b91a655f150536717961f26 4211 hamradio optional twlog_1.3-3.1.diff.gz 0b9234c233e45369ca672513725821c5 24756 hamradio optional twlog_1.3-3.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDzkXAriZpaaIa1PkRAnrzAKDlRdSxVrgsWKHlAYNun238c7mRFwCg8IKW esHcfgDDRmYLqzKFjr97qxc= =wWWx -END PGP SIGNATURE- Accepted: twlog_1.3-3.1.diff.gz to pool/main/t/twlog/twlog_1.3-3.1.diff.gz twlog_1.3-3.1.dsc to pool/main/t/twlog/twlog_1.3-3.1.dsc twlog_1.3-3.1_i386.deb to pool/main/t/twlog/twlog_1.3-3.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted blast 1.1-13.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:21:16 -0500 Source: blast Binary: blast Architecture: source i386 Version: 1.1-13.1 Distribution: unstable Urgency: low Maintainer: Oliver M. Bolzer [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: blast - Vent your frustration with programs by blowing holes in them Closes: 346630 Changes: blast (1.1-13.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #346630. Files: 7f54fe51df688f691eb73c7d4e92892d 655 games optional blast_1.1-13.1.dsc bf042e643c49f932457446db7f0e879a 3016 games optional blast_1.1-13.1.diff.gz 16a14b5accef9c37a8c6c59935981822 7884 games optional blast_1.1-13.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDy9+2riZpaaIa1PkRAsozAJ4imHr9wx4KyeliPrrHC9i0qa6lfQCgoigL hgFOl6IGjgysOgprPjLCkqw= =HAUW -END PGP SIGNATURE- Accepted: blast_1.1-13.1.diff.gz to pool/main/b/blast/blast_1.1-13.1.diff.gz blast_1.1-13.1.dsc to pool/main/b/blast/blast_1.1-13.1.dsc blast_1.1-13.1_i386.deb to pool/main/b/blast/blast_1.1-13.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nitpic 0.1-10.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:23:17 -0500 Source: nitpic Binary: nitpic Architecture: source i386 Version: 0.1-10.1 Distribution: unstable Urgency: low Maintainer: Ernesto Nadir Crespo Avila [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: nitpic - Simulator for the Microchip PIC16C84 microcontroller Closes: 347138 Changes: nitpic (0.1-10.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #347138. Files: cd167dc36dd50207999d2df35012dbf9 747 electronics extra nitpic_0.1-10.1.dsc d9d36c081307ca669d633f5d072e1699 10123 electronics extra nitpic_0.1-10.1.diff.gz f2ebbdb9b2fd2b7ad93d1c208f3e35b2 33394 electronics extra nitpic_0.1-10.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDy+h1riZpaaIa1PkRAjODAKCRn5qznQu62gAFvYQ4R1kKQ8ObvACgrrgq tO8QyIYB+DlbspSOrq99q2s= =UTid -END PGP SIGNATURE- Accepted: nitpic_0.1-10.1.diff.gz to pool/main/n/nitpic/nitpic_0.1-10.1.diff.gz nitpic_0.1-10.1.dsc to pool/main/n/nitpic/nitpic_0.1-10.1.dsc nitpic_0.1-10.1_i386.deb to pool/main/n/nitpic/nitpic_0.1-10.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wmload 0.9.2-10.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:25:34 -0500 Source: wmload Binary: wmload Architecture: source i386 Version: 0.9.2-10.1 Distribution: unstable Urgency: low Maintainer: Marcelo E. Magallon [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: wmload - system load monitor designed for Window Maker Closes: 347118 Changes: wmload (0.9.2-10.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #347118. Files: 72cb669d882b69d8ba451e3ade1c0a4f 669 x11 optional wmload_0.9.2-10.1.dsc 0f23481d8531620c7888d0888e2dd307 3224 x11 optional wmload_0.9.2-10.1.diff.gz 7af31a8fb20b809e7480c05993fd7ec3 14364 x11 optional wmload_0.9.2-10.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDy+9ZriZpaaIa1PkRAvSuAKDPI+YjxERlXpBSvaXHvaMRj7ccGQCgtfGD RNfwODO/wbc7mva+JZrYf1g= =M3hY -END PGP SIGNATURE- Accepted: wmload_0.9.2-10.1.diff.gz to pool/main/w/wmload/wmload_0.9.2-10.1.diff.gz wmload_0.9.2-10.1.dsc to pool/main/w/wmload/wmload_0.9.2-10.1.dsc wmload_0.9.2-10.1_i386.deb to pool/main/w/wmload/wmload_0.9.2-10.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted qiv 2.0-4.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:23:43 -0500 Source: qiv Binary: qiv Architecture: source i386 Version: 2.0-4.1 Distribution: unstable Urgency: low Maintainer: Christoph Wegscheider [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: qiv- A quick image viewer for X Closes: 347042 Changes: qiv (2.0-4.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #347042. Files: 17669640f02b94c999ea31ba8a6d5a00 699 graphics extra qiv_2.0-4.1.dsc b2498f7aeb9f0c0bf98571807aa19223 8703 graphics extra qiv_2.0-4.1.diff.gz 4f7a3884c40f295288d33d6c37a4b741 66314 graphics extra qiv_2.0-4.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDy/IfriZpaaIa1PkRAhqGAKCDs7excmXTcqvcO32rQZ3N6cS3cwCgpXi8 4QENP6nWp7i4Yn2j0XMJ+44= =Pkww -END PGP SIGNATURE- Accepted: qiv_2.0-4.1.diff.gz to pool/main/q/qiv/qiv_2.0-4.1.diff.gz qiv_2.0-4.1.dsc to pool/main/q/qiv/qiv_2.0-4.1.dsc qiv_2.0-4.1_i386.deb to pool/main/q/qiv/qiv_2.0-4.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted stardict 2.4.5-1.1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:24:45 -0500 Source: stardict Binary: stardict-common stardict-tools stardict Architecture: source i386 all Version: 2.4.5-1.1 Distribution: unstable Urgency: low Maintainer: Roy Hiu-yeung Chan [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: stardict - International dictionary for GNOME 2 stardict-common - International dictionary for GNOME 2 - data files stardict-tools - The dictionary conversion tools of stardict Closes: 347109 Changes: stardict (2.4.5-1.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #347109. Files: b7415e52e2af244fb9f709129846726b 851 utils optional stardict_2.4.5-1.1.dsc e579096beebd6067d2b825520ec90136 155959 utils optional stardict_2.4.5-1.1.diff.gz 481ab1c304557419eba830754fe6646e 120534 utils optional stardict_2.4.5-1.1_i386.deb 04fea9bb442ac0a74ea92cf7d59013e5 773334 utils optional stardict-common_2.4.5-1.1_all.deb f5e593d4559d2e28960b813a16accbb3 50252 utils optional stardict-tools_2.4.5-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDy/Q9riZpaaIa1PkRAiG4AKD1Y6VL0+KPHNV81dGQgLoJRSNvgwCeMRgl HGslWu3lHemdtdaGxryP5Ao= =hzwN -END PGP SIGNATURE- Accepted: stardict-common_2.4.5-1.1_all.deb to pool/main/s/stardict/stardict-common_2.4.5-1.1_all.deb stardict-tools_2.4.5-1.1_i386.deb to pool/main/s/stardict/stardict-tools_2.4.5-1.1_i386.deb stardict_2.4.5-1.1.diff.gz to pool/main/s/stardict/stardict_2.4.5-1.1.diff.gz stardict_2.4.5-1.1.dsc to pool/main/s/stardict/stardict_2.4.5-1.1.dsc stardict_2.4.5-1.1_i386.deb to pool/main/s/stardict/stardict_2.4.5-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xlbiff 4.1-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 15:26:03 -0500 Source: xlbiff Binary: xlbiff Architecture: source i386 Version: 4.1-1.1 Distribution: unstable Urgency: low Maintainer: Christoph Martin [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: xlbiff - X Literate Biff. Displays From and Subject lines of your new mail Closes: 347146 Changes: xlbiff (4.1-1.1) unstable; urgency=low . * Non-maintainer upload. * Update build-deps for xlibs-dev removal; closes: #347146. Files: 2ac8fc076272e94c39be17a098c11039 660 mail optional xlbiff_4.1-1.1.dsc de6db4925637335f1656eb9b75ae4103 9475 mail optional xlbiff_4.1-1.1.diff.gz 00d8a50f13e0fe1627a17271e022be2c 19790 mail optional xlbiff_4.1-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDyspSriZpaaIa1PkRAqlzAKDjJNLq686QOKmNH7/cpfb6LwYeAQCfd03g S7tD3bzY4hAoPOupU0v4TeU= =WoG+ -END PGP SIGNATURE- Accepted: xlbiff_4.1-1.1.diff.gz to pool/main/x/xlbiff/xlbiff_4.1-1.1.diff.gz xlbiff_4.1-1.1.dsc to pool/main/x/xlbiff/xlbiff_4.1-1.1.dsc xlbiff_4.1-1.1_i386.deb to pool/main/x/xlbiff/xlbiff_4.1-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xcdroast 0.98+0alpha15-3.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 11:11:22 -0500 Source: xcdroast Binary: xcdroast Architecture: source i386 Version: 0.98+0alpha15-3.1 Distribution: unstable Urgency: low Maintainer: Hector Garcia [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: xcdroast - X based CD-writer software Closes: 346795 Changes: xcdroast (0.98+0alpha15-3.1) unstable; urgency=low . * NMU for xlibs-dev removal; closes: 346795. Files: 721cc8f791bde11fba0b5f28cf0ac41b 678 otherosfs extra xcdroast_0.98+0alpha15-3.1.dsc 2a175ebd5a9e3c1a2d78b8e74be27f28 104194 otherosfs extra xcdroast_0.98+0alpha15-3.1.diff.gz 7f52317a4d09a1f94b8aca3b3dc6e525 1875776 otherosfs extra xcdroast_0.98+0alpha15-3.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDyYbtriZpaaIa1PkRAjp2AJwPFm5YPUFT6RcBoC6xu7z3KvEicgCfRF7n mY40rWA5t1e7VTZfbjbHTRc= =7RAS -END PGP SIGNATURE- Accepted: xcdroast_0.98+0alpha15-3.1.diff.gz to pool/main/x/xcdroast/xcdroast_0.98+0alpha15-3.1.diff.gz xcdroast_0.98+0alpha15-3.1.dsc to pool/main/x/xcdroast/xcdroast_0.98+0alpha15-3.1.dsc xcdroast_0.98+0alpha15-3.1_i386.deb to pool/main/x/xcdroast/xcdroast_0.98+0alpha15-3.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bdfresize 1.5-3.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 11:06:43 -0500 Source: bdfresize Binary: bdfresize Architecture: source i386 Version: 1.5-3.2 Distribution: unstable Urgency: low Maintainer: Takuo KITAME [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: bdfresize - Resize BDF Format Font Closes: 346634 Changes: bdfresize (1.5-3.2) unstable; urgency=low . * NMU for xlibs-dev removal; closes: #346634. Files: 9ad72869e2a9e06c9b91a8fa738f800a 606 x11 optional bdfresize_1.5-3.2.dsc 5e16e41f06d17d6e47ea7e4954c7eba9 1945 x11 optional bdfresize_1.5-3.2.diff.gz 91edf1a8b1cf548bb1bd8ffacb379778 11646 x11 optional bdfresize_1.5-3.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDyYxkriZpaaIa1PkRAqrlAJ9pPgxlJAQaOBdOjQILNSDddVhrOgCgqHSs 03T4rbQrDcDBi2t+Kc6lUhU= =Tfg2 -END PGP SIGNATURE- Accepted: bdfresize_1.5-3.2.diff.gz to pool/main/b/bdfresize/bdfresize_1.5-3.2.diff.gz bdfresize_1.5-3.2.dsc to pool/main/b/bdfresize/bdfresize_1.5-3.2.dsc bdfresize_1.5-3.2_i386.deb to pool/main/b/bdfresize/bdfresize_1.5-3.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grig 0.4.2-4.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 11:09:11 -0500 Source: grig Binary: grig Architecture: source i386 Version: 0.4.2-4.1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: grig - graphical user interface to the Ham Radio Control Libraries Closes: 346624 Changes: grig (0.4.2-4.1) unstable; urgency=low . * NMU for xlibs-dev removal; closes: 346624. Files: 7d30d5431c2ce4794a646d17fdc76962 679 hamradio optional grig_0.4.2-4.1.dsc 6d04f706f883cf5d2dada3da2eed8d80 119104 hamradio optional grig_0.4.2-4.1.diff.gz 263660e06199a1e8be4d6ecb5dc3aca1 93960 hamradio optional grig_0.4.2-4.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDyY/zriZpaaIa1PkRAmewAJ9zBe1nrzempBzUaXmzZ8TzUPbJVwCgwixk NelpNp/xGReWJBCF2/+iuwY= =cxVX -END PGP SIGNATURE- Accepted: grig_0.4.2-4.1.diff.gz to pool/main/g/grig/grig_0.4.2-4.1.diff.gz grig_0.4.2-4.1.dsc to pool/main/g/grig/grig_0.4.2-4.1.dsc grig_0.4.2-4.1_i386.deb to pool/main/g/grig/grig_0.4.2-4.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmms-jack 0.15-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 14 Jan 2006 11:14:05 -0500 Source: xmms-jack Binary: xmms-jack Architecture: source i386 Version: 0.15-1.1 Distribution: unstable Urgency: low Maintainer: Mike Furr [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: xmms-jack - xmms output plugin to the jack audio server Closes: 346827 Changes: xmms-jack (0.15-1.1) unstable; urgency=low . * NMU for xlibs-dev removal; closes: 346827. Files: b7f9b493a4fbc08be7ebbe15dc85a24d 709 sound optional xmms-jack_0.15-1.1.dsc df027fb8d4e0b539b44246422f1da907 2001 sound optional xmms-jack_0.15-1.1.diff.gz b392b019cfa0f3efe68fbde82cb99923 42490 sound optional xmms-jack_0.15-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDyZWvriZpaaIa1PkRAmcxAJ4iEhDPqn/2ei/Vet1UCp7mayNeVACcC1MP Xyqbt+jLkrNvQDA+DKzcCfM= =YB4i -END PGP SIGNATURE- Accepted: xmms-jack_0.15-1.1.diff.gz to pool/main/x/xmms-jack/xmms-jack_0.15-1.1.diff.gz xmms-jack_0.15-1.1.dsc to pool/main/x/xmms-jack/xmms-jack_0.15-1.1.dsc xmms-jack_0.15-1.1_i386.deb to pool/main/x/xmms-jack/xmms-jack_0.15-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
On Sat, 3 Dec, 2005 at 17:15:58 +, Colin Watson wrote: yaclc provides this. I also have bug #316385: [process.in] allow for process.in commands to restrict themselves to a specific package (like service.in). Presently the BTS doesn't seem to have this functionality, but it would probably not be a big change, since this already exists elsewhere. The source package thing mentioned is another small problem. -- Clear skies, Justin References [0] http://bugs.debian.org/316385 [1] http://lists.debian.org/debian-devel/2005/12/msg00033.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
urgency='low' testing propogation only 5 days for gtk+2.0?
It is my understanding that an urgency='low' upload defines a 10 day delay in testing propogation, unless overridden by hints. However, yesterday's gtk+2.0 upload indications only a 5 day delay. Why? http://packages.qa.debian.org/g/gtk+2.0.html Please Cc me. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is Lars Steinke MIA?
On 2005-11-14, I filed grave bug #339056: Library package fails to include shlibs file [0] on package tktable-dev [1] , on which my package saods9 build-depends. I'm concerned about this bug because 1) its RC; 2) I haven't heard back in a month, despite pinging the maintainer last week; 3) My package depends on it [2]; and 4) Only 1 other package, also maintained by Lars, depends on it. I would have expected some response by now, so I'm alerting -qa and asking -devel for info. Has anyone heard from Lars Steinke [EMAIL PROTECTED] in the last month? A quick google search indicates that he was active early this year, at least, and his bug page indicates that he has probably been inactive for ~6 months. Please Cc: me with relevant info if you are not also mailing QA. -- Clear skies, Justin References [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339056 [1] Now serious, reassigned, and retitled. [2] Though it would be easy to link against the copy of tktable distributed in the DS9 sources by SAO upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341188: ITP: libwcs -- FITS world coordinate system support library
Package: wnpp Severity: wishlist * Package name: libwcs Version : 4.2 Upstream Author : Mark R. Calabretta [EMAIL PROTECTED] * URL : http://www.atnf.csiro.au/people/mcalabre/WCS/ * License : GPL Description : FITS world coordinate system support library Please critique my understanding of library packaging (copy me in responses). Upstream doesn't (yet!) build a shared library, so it seems the burden lies on me to implement that support. But wcslib is used by 2 of my packages (saods9 and sextractor), and seems to provide a highly specialized, yet readily accessible and well-documented API, which I can easily see being useful in my own projects. WCSLIB is a C library, supplied with a full set of Fortran wrappers, that implements the World Coordinate System (WCS) convention in FITS (Flexible Image Transport System). It also includes a PGPLOT-based routine, PGSBOX, for drawing general curvilinear coordinate graticules. The FITS data format is widely used within the international astronomical community, from the radio to gamma-ray regimes, for data interchange and archive, and also increasingly as an online format. It is described in Definition of The Flexible Image Transport System (FITS), Hanisch, R.J., Farris, A., Greisen, E.W., et al. 2001, AA, 376, 359 which formalizes NOST 100-2.0, a document produced by the NASA/Science Office of Standards and Technology, see http://fits.gsfc.nasa.gov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted saods9 4.0b7-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Nov 2005 23:56:09 -0500 Source: saods9 Binary: saods9 Architecture: source i386 Version: 4.0b7-1 Distribution: unstable Urgency: low Maintainer: Justin Pryzby [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: saods9 - image display tool for astronomy Closes: 303665 303668 315690 318042 336098 Changes: saods9 (4.0b7-1) unstable; urgency=low . * New upstream release; Along with a 3-line patch, fixes FTBFS with new GCC (Closes: #318042); Causes rebuild with GCC 4, as needed for transition. * Bump Standards-Version to 3.6.2 (no changes required). * ./debian/rules: get_orig_source now exists to generate a DFSG .orig tarball using fortran CVS copy of SLALIB, the C implementation of which is not GPL; the sources distributed by CfA are obfuscated (Closes: #336098). * Rewrite copyright file; include the unmodified license as distributed by CfA; document all copyright holders and licenses for packages included in the DFSG .orig tarball (Closes: #303665). * ./debian/control: Priority: extra (Closes: #315690). * Include generated manpage; a first step towards closing #303651. * Include documentation relevent to package; (Closes: #303668); selected items from ./ds9/doc/ and ./xpa/doc/; also include docbase templates. Files: 0a6f3f75e010ce306b2b90cca6fd8e89 648 science extra saods9_4.0b7-1.dsc fa714c93ad36facad3b31f53d0916f01 7354666 science extra saods9_4.0b7.orig.tar.gz fe6ee117bad4dd88ae3cd2a7117d41b2 29080 science extra saods9_4.0b7-1.diff.gz 9116178922a965801cf8ed52b706e859 2465672 science extra saods9_4.0b7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhH6ww3ao2vG823MRAl3vAJ9lT0sW2sd3CnP+PyJx3Ol0x9OG7ACfRCBD 630hLC1IeRjNWgbWtj9nh0s= =6qwN -END PGP SIGNATURE- Accepted: saods9_4.0b7-1.diff.gz to pool/main/s/saods9/saods9_4.0b7-1.diff.gz saods9_4.0b7-1.dsc to pool/main/s/saods9/saods9_4.0b7-1.dsc saods9_4.0b7-1_i386.deb to pool/main/s/saods9/saods9_4.0b7-1_i386.deb saods9_4.0b7.orig.tar.gz to pool/main/s/saods9/saods9_4.0b7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)
Package: lintian Severity: wishlist I am including a list of 73 packages which happened to be installed on my laptop which contain a maintscript with the fragment: # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. Maybe this is a debhelper bug? Both of my packages contain postinst and postrm, only, and generated entirely by debhelper. They have sections like: # Automatically added by dh_installmenu ... # End automatically added section Which I think is well done. But IMHO the section about debhelper will replace ... is indicitive of a bug. Either that text should be removed, or something should be put in its place. Maybe these packages are buggy and need to do some certain thing, such that debhelper can do that replacement, but they don't do it? In any case, I would like to request that lintian includes a check to ensure that new packages do not contain that text. Package list follows; 73 out of 1269 (5.8%) installed packages are affected. Please Cc: me. -- Clear skies, Justin apt apt-listchanges apt-show-versions aptitude avifile-player bittornado ca-certificates chaksem checksecurity clara dangen ddclient debtags defoma dhcp3-client dict-bouvier dict-gazetteer2k-counties dict-gazetteer2k-places dict-gazetteer2k-zips dpkg-cross eep24c electricsheep elinks gs-common gs-gpl gsfonts hevea icebreaker imagemagick info2www jadetex le less libcupsys2 libdevmapper1 libgtk1 libgtk2 libmoe1 libmysqlclient12 libmysqlclient14 libpam-runtime libpango1 libroken16-kerberos4kth libruby1 libsensors3 libsndfile0 login lp-solve lprng mailliststat menu-xdg moon-buggy-esd mpg321 ncurses-hexedit nvram-wakeup openssh-client openssh-server passwd procps psfontmgr sbuild tetex-base tetex-bin timidity tkinfo tpconfig upgrade-system usbutils vche vtgrab w3c-dtd-xhtml xfig xtux-server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)
On Tue, Nov 08, 2005 at 12:57:40PM -0800, Russ Allbery wrote: Justin Pryzby [EMAIL PROTECTED] writes: This refers to the #DEBHELPER# token. OH. Maybe I understand. The maintscripts of the packages in my list were probably initially dh_make templates, and the maintainers didn't remove that comment. The packages not in my list either have maintscripts created from scratch by debhelper, or their maintainer removed that comment. Is that a consistent interpretation? -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sextractor 2.4.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 18 Oct 2005 11:39:55 -0400 Source: sextractor Binary: sextractor Architecture: source i386 Version: 2.4.3-1 Distribution: unstable Urgency: low Maintainer: Justin Pryzby [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: sextractor - source extractor for astronomical images Closes: 260740 Changes: sextractor (2.4.3-1) unstable; urgency=low . * New upstream release; - Now handles MEF FITS files; a previous package by Stephen Quinney included a Debian patch to support them. * New maintainer (first official upload of this package maintained by me); Closes: #260740: ITP; - Previously maintained by Stephen Quinney, and updated unofficially by Florian Ernst. Thanks to Florian for sponsoring this upload. - Redo packaging from scratch, taking into account my own previous diffs, Florian's diff, and Stephen's diff. * ./debian/copyright: include the wcs library license as included; neither call it package, nor Lesser GPL, but do update the FSF address to avoid a lintian warning; Files: 2009bb2c7b728a02b4b230c0b7acbdba 643 science extra sextractor_2.4.3-1.dsc a8d9cafc15c1e1a1a357797e2bd07b65 1317578 science extra sextractor_2.4.3.orig.tar.gz b1e7a5a44ef4cf1be6c5b39316022bd8 6075 science extra sextractor_2.4.3-1.diff.gz a656cf645b5e3d6ae8392c61bddd2f0d 1133768 science extra sextractor_2.4.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDViKYs3U+TVFLPnwRAjk3AJ9GMP528FhkETbt0KSvfKYzvGKNDQCfcjQz kpm2/nSncUAiTbnBqMw1mmg= =xNqN -END PGP SIGNATURE- Accepted: sextractor_2.4.3-1.diff.gz to pool/main/s/sextractor/sextractor_2.4.3-1.diff.gz sextractor_2.4.3-1.dsc to pool/main/s/sextractor/sextractor_2.4.3-1.dsc sextractor_2.4.3-1_i386.deb to pool/main/s/sextractor/sextractor_2.4.3-1_i386.deb sextractor_2.4.3.orig.tar.gz to pool/main/s/sextractor/sextractor_2.4.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nonpublic shared libraries (repost; was: Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self)
On Sun, Sep 11, 2005 at 06:12:02PM -0500, Peter Samuelson wrote: [Justin Pryzby] In which case, should the shared libraries go into a separate package? I wouldn't bother unless there are multiple binary packages already which will require the library, and they don't already depend on each other. And this is probably a fairly rare case. Basically, if there's no reason for anyone to install the library package but *not* the binary package that requires it, then there's no reason the library package should be separate. What should they be named (filenames and sonames)? Should they be in /usr/lib/ or in /usr/lib/pkg/? If /u/l/pkg/, what is the recommended way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)? /usr/lib/pkg/, and I would use rpath. Why not? The problems with rpath do not apply to the case where libraries and binaries are tightly coupled, like they're built from the same source and are in the same binary package. Well, rpath was an utter failure for me, in my shared library endevours with IRAF, because it creates an ELF program mkpkg which I wanted to be linked against the shared libraries. Using rpath would make building immensely more complicated, probably requiring a separate -libs package, on which a separate -rpath package depends AND build-depends, and on which all other packages depend and build-depend. Which means that I can no longer build the whole thing (from scratch) with debuild; I'd have to build just the libs, and then install them, and then build just mkpkg, and then install it, and then build the rest. I don't know if this is an acceptible build scenario, since the binary packages build-depend on other binary packages built from the same source package. Even if it is acceptible (maybe because of the initial upload of the -libs and -mkpkg binary packages?), I think it sucks, possibly for different reasons than why other people think so. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
nonpublic shared libraries (repost; was: Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self)
This was originally sent to -mentors, but elicited no response, so I'm
reposting here:
I actually had postponed a message about all these questions for some
6+ months now, while I tried to phrase the questions in a more useful
way. This thread caused me to regain interest. Hopefully someone
here can provide insight, otherwise I guess I will try on -devel.
On Tue, Sep 06, 2005 at 07:18:17PM +0200, Frank K?ster wrote:
Justin Pryzby [EMAIL PROTECTED] wrote:
On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote:
Justin Pryzby [EMAIL PROTECTED] wrote:
Could someone else also comment on how applications should deal with
shared libraries which are not intended to be used by other programs?
If they aren't used by other programs, there's no need to produce a
library. Perhaps it's convienient to create static libraries during
compilation and link against these, but shared libraries are of no use.
What if there are many binaries (10s of them) in your package, and you
want to use shared libs purely for resource efficiency (disk and
memory)?
You're right, that's an other reason for a shared library.
In which case, should the shared libraries go into a separate package?
What should they be named (filenames and sonames)? Should they be in
/usr/lib/ or in /usr/lib/pkg/? If /u/l/pkg/, what is the recommended
way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)?
Is it still okay if the binary interface is not at all stable, or
guaranteed to be compatible between versions? I'm thinking of the
case where a Debian packager adds shared lib support for better
resource efficiency, but upstream doesn't implement it, and interfaces
change at potentially every new release. Is it sufficient (if the
libs are in a separate package) to have the libs and the binaries both
Depends: pkg-{libs,bin} (=${Source-Version})?
It seem to me that there is no reason to requires libs to be in a
separate package, though it might be convenient to make this division,
but probably no deeper reason, correct? For a multiple-binary
package, it could be used as one of the arch-dep packages, if the
indep packages are significanly large to warrent the split.
Thanks,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
inconsistent newlines while configuring packages?
After doing a recent dist-upgrade, I see: $ fg sudo apt-get dist-upgrade Setting up libgphoto2-2 (2.1.5-6) ... Setting up libgphoto2-port0 (2.1.5-6) ... Setting up libxv-dev (4.3.0.dfsg.1-13) ... Setting up libxi-dev (4.3.0.dfsg.1-13) ... Setting up g++-3.3 (3.3.5-13) ... Setting up g++-3.4 (3.4.3-13) ... Setting up gcj-3.3 (3.3.5-13) ... Setting up libgtk2.0-0 (2.6.4-3) ... Setting up gkrellm (2.2.5-1.3) ... Why do some packages [re]configuration cause a newline to be outputted, and others do not? Is it related to the existence of a postinst script?, and, Is it intentional? Please Cc: me, not subscribed. TIA, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted saods9 3.0.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 11:29:52 -0500 Source: saods9 Binary: saods9 Architecture: source i386 Version: 3.0.3-1 Distribution: unstable Urgency: low Maintainer: Justin Pryzby [EMAIL PROTECTED] Changed-By: Justin Pryzby [EMAIL PROTECTED] Description: saods9 - image display tool for astronomy Closes: 289371 Changes: saods9 (3.0.3-1) unstable; urgency=low . * Initial Release (Closes: #289371) - Thanks Aurelien Jarno. * Revert commented-out include in saotk/hal/Makefile. - Thanks Michael Weber. * Remove rpath from ds9 binary. Files: e58691317a3b215e375300ea5a515631 640 science optional saods9_3.0.3-1.dsc f8abbb62801536a16e291c916893eb65 18357280 science optional saods9_3.0.3.orig.tar.gz 63f4f1af473ffb068fba03d5147e954b 6331 science optional saods9_3.0.3-1.diff.gz 9960336371c7a28a655083b95ab6fca9 2209650 science optional saods9_3.0.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCQU6rw3ao2vG823MRAl5pAJ9bbqmBPhNNyXzHEoSgr5fNX1xXjQCgg/SX cdPJJDhSBFGFiQBcwjlvl7Q= =TK/K -END PGP SIGNATURE- Accepted: saods9_3.0.3-1.diff.gz to pool/main/s/saods9/saods9_3.0.3-1.diff.gz saods9_3.0.3-1.dsc to pool/main/s/saods9/saods9_3.0.3-1.dsc saods9_3.0.3-1_i386.deb to pool/main/s/saods9/saods9_3.0.3-1_i386.deb saods9_3.0.3.orig.tar.gz to pool/main/s/saods9/saods9_3.0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
update-menus runs in the background?
It seems that /usr/bin/update-menus now runs in the background. I ran sudo apt-et install glade, and after it finished, I ran ps -ef |tail -5, and the last commands running were update-menus.real, and install-menu. Is it supposed to be a background job, and, if so, why? Thanks, please Cc: me, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295328: general: Help messages to stderr should be banned
Package: general Severity: wishlist I occasionally install a program and need to know how to use it as quickly as possible; for example, while reading through bug reports. So, I run foo --help. Sometimes, the help screen is more than 25 lines long, and it scrolls on past. So, I run foo --help |less. Occasionally, though, foo writes its help output to stderr, and I'm left with an empty less buffer. So, I try again: foo --help 21 |less. This is a pretty obnoxious command to have to type just to see what the required commands are, and in what order they are taken (and, I guess csh doesn't even allow it). I already know that I can use the video buffer with shift-pageup. And I know that help output is supposed to fit on a single page, but I also know that sometimes it doesn't. I suppose I will start filing minor bugs against packages that do this. I'd like to hear other people's opinions, though. (It occurs to me that help output to stderr is arguably appropriate if an invalid option is given). Part of the problem is that its fairly depressing when investigation into one bug leads to filing of another bug:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#60810: contents.gz package
On Sat, Jan 15, 2005 at 07:12:05AM +0100, Goswin von Brederlow wrote: Justin Pryzby [EMAIL PROTECTED] writes: Could we have a package which provides /usr/share/.../Contents.gz? Not sure that share/ is the right place. And as Matt said, versioning is a potential problem. But lintian (and others: apt-file) could depend on this package (say, debian-dist-contents). Justin First of all how do you plan to update the testing package every day? That would be ideal.. They should reflect the testing Contents, right? Contents of whatever is installed, preferably. You also have to release a new version every day. That is an 8MB deb per arch and a source containing all 13 archs. That is 208MB updates per day and suite. ~400MB for testing and unstable every day. Are architectures Contents ever significantly different? Still way way to much data on a daily basis. Hadn't thought of that. I think the only sensible and simple thing to do is to provide a zsync file for the Contents files (zsync can 'look into' gz to rsync just the changes). Then every user can use a cron job to zsync the file to his system on a daily, weekly, monthly, whatever basis. zsync uses the http protocol so any http mirror carrying the Contents files will do as source. So maybe an debian-contents-updater package. It contains some cronjob entry, maybe a debconf question, or it uses /etc/defaults/. Yes, that would work nicely, I think. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289712: ITP: libncar-graphics -- scientific visualization suite from UCAR
Package: wnpp Severity: wishlist * Package name: libncar-graphics Version : 4.4.0 and counting, quickly Upstream Author : UCAR, C/O Mary Haley * URL : http://ngwww.ucar.edu/ng/ * License : GPL2 Description : scientific visualization suite from UCAR Graphics and math libraries and utilities for data visualization. UCAR is University Corporation for Atmospheric Research. My interested in this package is restricted to the ability to link with the provided libraries, as necessary for my IRAF package. If someone else is interested in it, feel free to take over the ITP. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10Y Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289371: ITP: saods9 -- astronomical image tool
Package: wnpp Severity: wishlist * Package name: saods9 Version : 3.0.3 Upstream Author : William Joye [EMAIL PROTECTED] * URL : http://hea-www.harvard.edu/RD/ds9/ * License : GPL2 Description : astronomical image tool DS9 is an application for astronomical imaging and data visualization. . DS9 is the modern imtool used by astronomers. It is most distinguished by its support for displaying 16 bit greyscale images (such as FITS). Most tools (such as GIMP and Photoshop) will read an approximation to such files, and only store the most significant 8 bits of data. DS9 works in full precision, and uses various display parameters to map input data of high dynamic-range such as to be displayed on the screen. . Available parameters include: brightness, contrast, false color, and nonlinear input mapping (such as logarithm, square root, square, etc.) . Although it may be useful in other fields, DS9 includes a fair number of features specific to astronomy. There is an astronomical name resolver which allows a lookup of an arbitrary named object to its coordinates. Given the coordinates of a field, online archive servers may be queried, and an image retrieved. DS9 thusly implements a preliminary Virtual Observatory. . DS9 is entirely controllable from external programs (XPA), which simplifies complex tasks such as realtime or batch analysis. . Images may be aligned by their WCS (World Coordinate System) keywords, and then blinked to search for moving objects. . Homepage: http://hea-www.harvard.edu/RD/ds9/ -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10Y Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Bug#60810: contents.gz package
Could we have a package which provides /usr/share/.../Contents.gz? Not sure that share/ is the right place. And as Matt said, versioning is a potential problem. But lintian (and others: apt-file) could depend on this package (say, debian-dist-contents). Justin
AIPS Part II
Greetings, I mailed the list recently regarding my ITP AIPS: Astronomical Image Processing System. For anyone who might have considered sponsoring, here is some more info regarding its size. Source tar.gz: 67MB Initial .deb Size: 148MB Current .deb Size: 16MB arch dependent, 52MB arch independent Initially, the binary directory ($LOAD) was 200MB, which I've cut down to 20MB by adding the ability to compile using shared libraries (not available from the upstream compile script). The libraries themselves are 10MB. This is still a huge package; it takes almost 2 hours (CPU bound) to compile on my 850MHz laptop. So, no, the size is not a mistake. Still a WIP, I'm presently working on separating the compile-time from install-time process (which are bundled in the upstream script). Justin signature.asc Description: Digital signature
Bug#278868: ITP: aips -- Astronomical Image Processing System
Package: wnpp Severity: wishlist * Package name: aips Version : 20041029 Upstream Author : NRAO [EMAIL PROTECTED] * URL : http://www.aoc.nrao.edu/aips/ * License : GPL Description : Astronomical Image Processing System from NRAO The Astronomical Image Processing System is a software package for calibration, data analysis, image display, plotting, and a variety of ancillary tasks on Astronomical Data. It comes from the National Radio Astronomy Observatory. It is primarily for Radio Astronomy. . Homepage: http://www.aoc.nrao.edu/aips/ Developers, this is a very large package. I'm not even sure if its appropriate for inclusion in Debian. I will be keeping a copy in my personal repository, along with all the other astronomy software. At the moment I'm not even sure how large; it is meant to keep all the source code along with the executables (and sync via cvs every night via cron..). The *source* targzball is 67M at 69% compression. But now I have to come up with a way to isolate the runtime files from the install files (unfortunately not disjoint). (The Debian version will not do the nightly CVS thing, btw). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-rc1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
d-i using kexec
Has anybody ever considered the possibility of a 0-reboot installation? It seems that this should be possible with (or without?) kexec. I think the reason the installer presently reboots is to load the *real* kernel (which will be used during normal runtime) rather than the installer kernel. Rebooting also allows the boot process as a whole to get tested (Did the MBR get written correctly?). Are there other reasons? Justin signature.asc Description: Digital signature
