Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
Julian Gilbey [EMAIL PROTECTED] writes: On Tue, Aug 19, 2003 at 09:24:25PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: How about requiring the debian directory to have an appropriately named parent (as determined by debian/changelog and debian/control, which should probably also have to agree...), unless the user runs debuild with some sort of --force option? But then its a question of what name to use? I do have the following four cases: package package-version package-version.debian_version package-cvs I really like this idea, thank you! I will accept directory names matching the regexp /^$package(-.*)?$/ - does that seem reasonable? Fine with me. MfG Goswin
Re: Bits from the RM
Hi, I'm Troy McClure - you may remeber me from such threads as How do we get Debian to have a useful release timeframe, and... *er, wait*. Okay, that sillyness aside... On Wed, Aug 20, 2003 at 08:51:16AM -0400, Theodore Ts'o wrote: Better to have a hard freeze schedule, and then try to turn out new stable releases every 6-9 months. Then folks won't be so desperate to shove new things in and screw up the release. The problem, though, is the first such attempt take release schedules seriously and agressively (a) a really hardass RM, and (b) a certain amount of faith by the developers that we really can get our act together about short, regular, predictable releases. Much, much better. I'd love to see it manage to hit every six months (and even I agree that more often that that probably isn't feasible; most of the major projects I know of that do scheduled releases don't have cycles 6 months, and generally don't have too many users screaming about out-of-date software). The first time is going to be a lot of unfamiliar, a lot of hectic, and frankly, probably a lot of things that we don't get quite as right as we could with experience - since, of course, part of the need is to gain that experience. I'm glad to see, however, that an RM has decided that targeting an actual date, with an actual and concrete timeline (to compare against and know if we're slipping too far), and clear mileposts along the way, is a meaningful way to attempt a release. You already have (b) from this quarter - and my profound hope that we can, in fact, pull this off. Because it would resolve about 80% of the complaints I've ever heard from folks about Debian (another 19% being the install setup, which is also being remedied, and 1% being it's focus on Linux, which is a separate question entirely - and no, I do not forsee trying to get netbsd-i386 into sarge. If we manage to achieve a six-month turnaround, quite possibly not even into sarge+1; NetBSD hasn't announced a release target for 2.0 yet). Off to hunt some RC bugs, now... (yeah, yeah, I should have been doing this all along, but frankly, porting work took priority when there was no release goal :) -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpmFdFGuvjMV.pgp Description: PGP signature
Re: FTBFS: architecture all packages
Hi, Andrew Suffield wrote:
If its hoop-jumping then it must be intentional. Point is it happens.
Who cares? We cannot build an automated system here that will be able
to stop people doing things like that.
Why not? Just block binary uploads completely, and let everything get
built by the buildds. I certainly plan to do that with my own uploads.
(I've already set up my own buildds).
I'd go one step farther and schedule a low-priority rebuild of everything
that build-depends on a package which gets updated.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Is knowledge knowable? If not, how do we know that?
Re: #206298 spip: prerm script blindly removes directories
On Wed, Aug 20, 2003 at 05:38:42PM +0200, Gaetan Ryckeboer wrote: Le Wed, Aug 20, 2003 at 09:26:14AM -0600, Jamin W. Collins a ?crit : Is this uploaded data recorded anywhere? In the MySQL database perhaps? If so, the file names can be retrieved from there for removal on purge. Mmm... yes and no. Some of them could be. But a user may upload files without using them in the application. So, the files are available, but unused, and unreferenced. That would appear to be a deficiency of the spip app and one that should probably be brought to the upstream developers attention. The application should probably log all uploads. Additionally, you may upset users by simply deleting their uploaded files on purge. Some may see this as deletion of user data, which should not be done. Of course, I understand. But I wonder they won't upload personal files for another use than spip here... This falls into something of a grey area. Can the data concievably be of value ot the user without spip? If so, then it is probably user data and should not be removed without confirmation from the user (debconf prompt that defaults to no?) As someone else has already pointed out, /usr/share should be capable of being made read-only. Any runtime changing data for an application True. But due to the implemntation of the application, which is written in php, datas are stored on the program dir. There is no real separation between datas and functions. And if i symlink some datas (for apache access AND direct file handler access), i'll will setup another alarm... and it won't be accepted. So, use Alias directives to relocate the directories that need changing data to /var/lib. There is no need to use symlinks to accomplish this. As a matter of fact, your current apache include enables the following of symlinks, which it doesn't need and probably shouldn't. I can provide examples of this if you need. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: what about ip's
David Smith writes: my first assumption is that charter sells their users email addresses. does anyone on this list know how an unused email address that has never been used can have spam without the ip giving the address out? Did you use 'dsmith' as the user name for the charter.net account? If so the answer should be obvious. Hint: 99% of my spam is addressed to non-existent users. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Bug#206421: ITP: gaim-encryption -- Gaim plugin that provides transparent RSA encryption
Package: wnpp Version: unavailable; reported 2003-08-20 Severity: wishlist * Package name: gaim-encryption Version : 2.06 Upstream Author : Bill Tompkins obobo at users.sourceforge.net * URL : http://gaim-encryption.sourceforge.net * License : GPL Description : Gaim plugin that provides transparent RSA encryption Features include:
[RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)
Hi,
I've wrote initial draft of debian ruby policy
http://pkg-ruby.alioth.debian.org/ruby-policy.html/index.html
Comments are welcome.
First, I'll intent to package ruby-defaults soon, which provides ruby and
libruby packages in which this ruby policy documents is included, and
rename current ruby package to ruby1.6 (and libruby to libruby1.6, ...).
After doing that, we'll start 1.6-1.8 transition as written in above
ruby policy documents.
I'd also like to hear opinions about ruby 1.8 packaging, especially
from ruby package maintainers who maintain ruby modules package that are
included in upstream ruby 1.8 distribution. As you know, ruby 1.8
includes the following packages in upstream distribution, and now
ruby1.8 make these packages from ruby1.8 source package. Is this ok?
I'm wondering these modules will be released independently from ruby 1.8.x
release. If so, it may be a problem because we may want such modules
that are released separately from ruby 1.8, instead of ruby 1.8 bundled ones.
What do you think about it?
New
liberb-ruby1.8
libdl-ruby1.8
libbigdecimal-ruby1.8
libracc-runtime-ruby1.8 (-ruby1.7?)
akira yamada [EMAIL PROTECTED]
libwebrick-ruby1.8 (- libwebrick-ruby)
libzlib-ruby1.8 (- libzlib-ruby)
libopenssl-ruby1.8 (- libopenssl-ruby)
libstrscan-ruby1.8 (- libstrscan-ruby)
libdrb-ruby1.8 (- drb?)
libiconv-ruby1.8 (- libiconv-ruby)
libxmlrpc-ruby1.8 (- xmlrpc4r?)
Joe Wreschnig [EMAIL PROTECTED]
libtest-unit-ruby1.8 (- libtest-unit-ruby)
Dmitry Borodaenko [EMAIL PROTECTED]
libyaml-ruby1.8 (- libyaml-ruby)
Oliver M. Bolzer [EMAIL PROTECTED]
librexml-ruby1.8 (- librexml-ruby)
At 05 Aug 2003 17:49:16 -0500,
Joe Wreschnig wrote:
On Tue, 2003-08-05 at 12:12, Fumitoshi UKAI wrote:
Since ruby 1.8.0 was released recently, ruby developers will go to
ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai),
are discussing about how to deal with Ruby 1.8 transition and trying to make
debian ruby policy soon.
For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and
ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x. Someone
want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use
alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any
other version of ruby in future).
There was a bug about this at some point, which I can no longer find,
where I suggested doing for Ruby what Python does. Which is essentially:
- 'ruby' is a metapackage depending the current default version of Ruby
for Debian.
- 'rubyX.Y' is a specific version of Ruby. 'ruby' depends on one of
these.
- 'libfoo-bar-ruby' is a metapacakge depending on libfoo-bar-rubyX.Y,
where X.Y is the default version of Ruby (the same as the one 'ruby'
depends on).
- 'libfoo-bar-rubyX.Y' is foo-bar for a specific version of Ruby. The
above depends on one of these. (These packages may be unncessary if the
directory tree I outlined below is used, and the package is
version-independent.)
Hmm, I agree that it would be good.
As for module include paths, they're less important since most Ruby
modules query Ruby for the right information at build-time anyway, but
I'd like to see version-independent directories, and also preferrably a
tree under /usr/share, too. Say,
These are arch-independent:
- /usr/share/ruby for Ruby modules that work with any version.
- /usr/share/ruby/X.Y for Ruby modules that depend on version X.Y.
Currently, ruby upstream doesn't support such version independent module
path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later
to support this?
These are arch-dependent:
- /usr/lib/ruby/version/X.Y/#{arch}-#{os} for all arch-dependent
modules. I believe most architecture-dependent modules need to be
recompiled for each version of Ruby anyway, and so a version-independent
architecture-dependent directory makes no sense.
Yes, I agree.
Regards,
Fumitoshi UKAI
pgpsmdcpVGl6X.pgp
Description: PGP signature
Re: #206298 spip: prerm script blindly removes directories
Le Wed, Aug 20, 2003 at 11:34:40AM -0600, Jamin W. Collins a écrit : Mmm... yes and no. Some of them could be. But a user may upload files without using them in the application. So, the files are available, but unused, and unreferenced. That would appear to be a deficiency of the spip app and one that should probably be brought to the upstream developers attention. The application should probably log all uploads. Not necessary. Web administrators may upload files via FTP, andspip users never use them onto spip ? If so, the files will stay in place in upload, instead of beeing integrated onto the spip tree at the right place, and being logged in the sql database. Of course, I understand. But I wonder they won't upload personal files for another use than spip here... This falls into something of a grey area. Can the data concievably be of value ot the user without spip? If so, then it is probably user data and should not be removed without confirmation from the user (debconf prompt that defaults to no?) You're right. I'll do such a dialog. True. But due to the implemntation of the application, which is written in php, datas are stored on the program dir. There is no real separation between datas and functions. And if i symlink some datas (for apache access AND direct file handler access), i'll will setup another alarm... and it won't be accepted. So, use Alias directives to relocate the directories that need changing data to /var/lib. There is no need to use symlinks to accomplish this. Yes it needs. I've still moves documentation to usr/share/doc, instead of spip/ecrire/doc, but it is rather different with the cache and other application managed files. You may access the php files via apache, but php files may access to other php file, or static file. For instance, to modify the configuration, or read the cache. The cache management will be patched to go to /var/cache, but I cannot do more without symlinks... The application won't be changed to handle FHS correctly without complete rewriting. Just imagine that spip is a set of application datas for apache/php, but is an complete application, with datas, procedures, and cache -- the reason of the packaging. As a matter of fact, your current apache include enables the following of symlinks, which it doesn't need and probably shouldn't. I can provide examples of this if you need. I accept. Please send me examples in private, if you found a way to move php files accessing each other (via include) in another directory, without patching the application. -- Monsieur à qui on ne la fait pas cherche Dame à qui on ne l'a pas fait. Gaétan RYCKEBOER Société Virtual-Net [Tous textes et propos tenus dans ce couriel sont sous license DMDZZ] pgp6Zxum4rF0S.pgp Description: PGP signature
Bug#206429: ITP: ruby-defaults: Debian default version of ruby, libruby
Package: wnpp Version: unavailable; reported 2003-08-21 Severity: wishlist * Package name: ruby-defaults Version : 1.6.8 Upstream Author : Fumitoshi UKAI [EMAIL PROTECTED], Akira Yamada [EMAIL PROTECTED], Akira Tagoh [EMAIL PROTECTED] * URL : http://pkg-ruby.alioth.debian.org/ * License : GPL or Ruby's Description : Debian default version of ruby, libruby ruby-defaults provides ruby and libruby that depends on debian default version of rubyX.Y and librubyX.Y. It also contains Debian ruby policy documents. For now, we already have ruby package in debian archive that is packaged from ruby 1.6.8. I also plan to rename these packages to ruby1.6, libruby1.6 and so on, with this ITP. Regards, Fumitoshi UKAI
Non-free software on linex [was Re: Debian Weekly News - August 19th, 2003]
On Tue, Aug 19, 2003 at 11:33:12PM +0200, Mike Hommey wrote: On Tuesday 19 August 2003 22:12, Martin Schulze wrote: [...] [2]Libranet 2.8, which is based on Debian. Richard Stallman [3]said he now prefers the [4]GNU/LinEx distribution over Debian because of non-free software on our FTP servers. [...] Let me see... I go to the linex home page. What do i see ? GNU/LinEx y tarjetas NVIDIA. Oh well, seems interesting, so I go in the page and see that they seem to provide some package for nvidia drivers. Maybe newer drivers (their distro is based on woody, so...) Ok, let's google a bit, and shazaam ! http://www.linex.org/sources/linex/debian/linex/nvidia-glx_1.0.4349-1_i386.deb Oh ! non-free software ! Thanks Richard for keeping me laughing. There's more of it: http://www.linex.org/sources/linex/debian/linex/ lists acroread_4.05-3, mplayer_0.90pre5-3 flashplugin-nonfree_6.0.79-1, hsflinmodem-linex_0.5.2-1 -- Hans Ekbrand pgp03pbgkbR6p.pgp Description: PGP signature
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote: * Martin Quinson ([EMAIL PROTECTED]) wrote: $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is the ID of my key, available from www.keyserver.net and signed by 2 DD. Did I mess something up ? keyring.debian.org has only DDs in it. I think people were suggesting using the public keyservers. keyring.debian.org isn't a part of the public key servers. That's the part of the system I was criticizing :) Shouldn't Debian make sure that work submition from non-DD contributor are signed, just like it does for the work submition from DD ? Interesting question. While it's not a bad idea I don't see it as entirely necessary either. At least when sponsoring a package the DD performing the sponsor must check everything regardless of if it was sent to them signed or not. [...] Hey, guys, I begun the thread stating that I was mainly a translator and not a packager. Let's say that the test case here is that I send a translation patch to Wichert about dpkg, as I already did. I think that Wichert has no idea about french, so he cannot review the meaning of my work. If he actually understand some french, let's imagine I'm japaneese or whatever. Of course, he can (and should) review the syntax of my po file (a badly formated po file can easily let the application segfault by replacing %d by %s in a printf format). msgfmt will warn him if I made such error. Nevertheless, should he trust the meaning of my translation blindly? I mean, it could contain offending material, and even unlegal material. I guess that there will be someone to engage pursuits if dpkg subtly displayed racial crime incitation, or so. I dunno in the states, but such things can bring you in jail for a bunch of few months (if not years) in France. And it should be easy to insert illegal material for the US in displayed text, thanks to your wonderfull anti terrorist and digital right management acts... Who will get sued in such situation? I guess Debian in first place, but if I understand well, the whole identification process of the NM is exactly about giving Debian the possibility to report the charges on the guilty developper when sued, isn't it? So, I ask again, shouldn't Debian check the real identity of contributors when the maintainer is unable to check the material himself ? If it's ok so, what is the big deal of asking the DD for having a trusted key and signing the packages, anyway ? I know about the public servers, but I was wondering why Debian make things harder for the DD while it has the infrastructure to simplify their work. Thanks for your time, Mt. -- Failure is not an option. It comes bundled with software.
Re: Debian Installation Goals (was: Happy Birthday)
cobaco [EMAIL PROTECTED] writes: On 2003-08-19 21:14, Goswin von Brederlow wrote: cobaco [EMAIL PROTECTED] writes: On 2003-08-17 09:02, Goswin von Brederlow wrote: As bad as it might be I would like to have a menu tree containing all packages that can be configured and when you select one item a menu would pop up with its configuration options. Package: configure-debian When is that used? At what stage? post-installation I'm talking about the selection of udebs and I certainly had no submenus with any images I managed to build. err, we were talking about package configuration, not package selection right? Sort of both. You select udebs for download, which should use tree menus and not a flat list. Then they add menu items to the main menu, which should be a tree too. And thirdly after/during installing base you have the configure options of the debs via debconf. A menu to change some values would be nice there too. So you can answere only neccessary questions while unpacking and then go and pocke some packages for more detailed options. Let me guess. You first have to install the configure-debian.udeb? .oO( Which no newbie would ever find ) true, you do need to install the package to use it, and yes the existence op this package could(should?) be made clearer Until your mail I had never heard of it. Gotta try it out. MfG Goswin
Re: Binaryless uploads
On Wed, 20 Aug 2003 10:04:40 -0400 (EDT), Jaldhar H Vyas [EMAIL PROTECTED] said: Ok. Lets leave aside for a moment the .debs which would go into contrib or non-free so would have to be built seperately. What Whoa there. Are you telling me that webmin's orig.tar.gz that is in main contains non free material? manoj -- Football combines the worst elements of America: Mass violence punctuated by committee meetings. Author Unknown Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposal: make kernel install easier
On Wed 10:51, Adam C Powell IV wrote: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. Don't know about your system, but /vmlinuz and /vmlinuz.old always point to the correct images and lilo.conf is set to use those by default. So, whenever I upgrade the kernel this is all taken care of. -- | Josh Lauricha| | [EMAIL PROTECTED] | | Bioinformatics, UCR | |--| pgp4eCwekoLsj.pgp Description: PGP signature
Re: Debian 10th birthday gear
Hi, I would be interested in two of the steins, if I can make payment without jumping through too many hoops. What are my options? manoj -- A year spent in artificial intelligence is enough to make one believe in God. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bits from the RM
On Wed, Aug 20, 2003 at 04:34:18PM +0200, cobaco wrote: KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by almost two months: * October 15th Final, last-minute, low-risk bug fixes only Monday September 29th, 2003: Preparing Beta1 The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1] is there any reason why stabilization of kde and stabilization of kde-packaging can't be done in parallel? Of course not; but you've missed the crucial difference between stabilization of kde *packaging*, and stabilization of kde *packages*. There is a great deal of testing that must be done with the packages /in situ/ once they've been built, to ensure that they work well amid the other software in Debian. Moreover, Debian users exercise KDE packages on a much wider range of hardware than KDE developers typically do before release; there is simply some testing we can't do before packages have been allowed to hit the archive, and the window between getting the current KDE packages into testing (just in case), and getting KDE 3.2 pre packages into experimental/unstable, doesn't leave any margin for error before the release. -- Steve Langasek postmodern programmer pgpXIAMdhPg1V.pgp Description: PGP signature
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 11:03:32AM -0500, Steve Langasek wrote:
On Wed, Aug 20, 2003 at 11:23:47AM +0200, Martin Quinson wrote:
On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
* Goswin von Brederlow [EMAIL PROTECTED] [2003-08-20 10:31]:
Martin Quinson [EMAIL PROTECTED] wrote:
I just wondered if it would be possible for non-developper
contributors to Debian to get their GPG key in the Debian
keyserver.
You can also apply as a NM for translation work. You don't need to
maintaine a package or know much about the packaging system for
that. You get different taskskill tests.
V I P Martin Quinson [EMAIL PROTECTED]
Exact. I *did* apply. I'm even pretty well advanced in the process.
$ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
This is the ID of my key, available from www.keyserver.net and signed by 2
DD. Did I mess something up ?
Shouldn't Debian make sure that work submition from non-DD contributor are
signed, just like it does for the work submition from DD ?
The keyring on keyring.debian.org is used directly as a means of
authorizing people to a number of Debian resources, including the
package upload queue and d-d-a. Whether you agree with this design or
not, it means that the Debian keyserver is not suitable for use as a
general-purpose means of *authenticating* people. For authenticating
PGP users to one another, you should use the usual Web of Trust to
achieve this.
I have to confess my ignorance here. Since it seems to be 4 keyrings on that
server (according to /usr/share/doc/debian-keyring/README.gz at least), I
was wondering if it would be possible to add a 5th for the trusted
contributors not being DD.
I can well imagine that the debian-keyring.{gpg,pgp} is used to allow people
to upload packages and such and want certainly not to get into that ring
(yet -- I'm in the NM process). But I was dreaming of such trust facility
for non DD contributors.
Another point is that it would constitute a strong signal to non DD
contributors: They would be trusted by Debian. According to the cathedral
and the bazzar, that's the way it should be if not too technically
difficult...
Thanks, Mt.
--
The unavoidable price of reliability is simplicity.
--Hoare
Re: Bits from the RM
On Wed, Aug 20, 2003 at 11:08:28AM +0200, cobaco wrote: On 2003-08-20 10:13, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? What recent change in the KDE releasing schema let you think that they will manage to get a really stable x.y.0 release [*] when it seems like it took 4 minor releases in the 3.1 branch ? Naturally, no offense intended to the kde guys. Needing only 4 minor releases to stabilize such an amount of code is really great. Bye, Mt. [*] ie, suitable for debian stable release, ie a version with which you could live for a year on your desktop, maybe dreaming of new features (we always want more), but not pesting against the bugs. I speak of course of the ideal debian stable release ;) -- Testing can only prove the presence of bugs. --- Dijkstra
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Wed, 20 Aug 2003, Goswin von Brederlow wrote: The only problem with that is the current failure to comply to policy, i.e. build from source as they should. The question remains is simply removing all the extra source from webmin-n.orig.tar.gz except that which is necessary to build the webmin binary package (i.e not any of the modules which will have their own source and binary packages) an aceptable solution to the problem or not? From what I read in this thread webmin-n.orig.tar.gz also contains some non-free sources, right? Then you have no choice but split it up to get the rest into main. And when you don't have a pristine upstream orig.tar.gz you can split it up as far as you like or need to. MfG Goswin
Network Associates Webshield - e-mail Content Alert
Network Associates WebShield SMTP V4.5 MR1a on mailvwy01 intercepted a mail from debian-devel@lists.debian.org which caused the Content Filter Block PIF Attachments to be triggered.
Re: Proposal: make kernel install easier
Adam C Powell IV [EMAIL PROTECTED] writes: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. I believe lilo and grub already have that. From /boot/grub/menu.lst ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default optons below There is also a mechanism in dpkg to install hooks now which is hopefully already used to run update-grub. MfG Goswin
Re: ftp.gnu.org cracked
On Wed, Aug 20, 2003 at 04:25:31PM +0100, Scott James Remnant wrote: [ Moved to debian-devel, I don't think this is relevant to private as the GNU crack is well publicised ] It is, in general, very poor taste to make this choice for others by reposting their content from a private forum to a public forum. While I agree that this should have begun on -devel in the first place, it didn't, and I respected the privacy of those I quoted by following up to -private. -- - mdz
Re: Debian Weekly News - August 19th, 2003
On Wed, Aug 20, 2003 at 05:30:39PM +0200, J?r?me Marant wrote: Quoting Scott James Remnant [EMAIL PROTECTED]: No he wouldn't. FDL is about free documentation. :-) Except it isn't :-) According to you :-) This has been covered to death already. There are a sufficient number of respondents that see it as non-free. The RM's recent post indicates that possibly the FSF has even come around to the idea that their license is less than Free. Can we please move along now? -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Goswin von Brederlow wrote: The only problem with that is the current failure to comply to policy, i.e. build from source as they should. The question remains is simply removing all the extra source from webmin-n.orig.tar.gz except that which is necessary to build the webmin binary package (i.e not any of the modules which will have their own source and binary packages) an aceptable solution to the problem or not? -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: ftp.gnu.org cracked
Scott James Remnant: No problem, this is only a quick run -- others may find ways to improve this script somewhat. What did you use to determine which packages to check? I notice that at least my package for GNU jwhois is missing from your list (although I know that the Debian version is correct since I post the versions to Debian and ftp.gnu.org at the same time...). -- \\// Peter - http://www.softwolves.pp.se/ I do not read or respond to mail with HTML attachments.
Re: Bits from the RM
On Wed, Aug 20, 2003 at 07:13:38PM +0200, Santiago Vila wrote: On Wed, 20 Aug 2003, Steve Langasek wrote: On Wed, Aug 20, 2003 at 03:52:42PM +0200, Santiago Vila wrote: Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built? Do you foresee any reasons why using experimental for new library uploads wouldn't serve the same purpose? Yes, autobuilders do not build stuff from experimental, so it will hardly serve the same purpose as the current unstable, even if you convince a lot of users so that experimental is tested as much as unstable. There was, however, talk of providing an easy interface to allow requests for building. I think this is a design that could be made to work. -- Steve Langasek postmodern programmer pgp1rKf75MNOB.pgp Description: PGP signature
Re: Bits from the RM
On Wed, 20 Aug 2003, Russell Coker wrote: Are there any big features you expect from KDE 3.2? Well it will be built with Qt 3.2 which has proper support of Indian languages. But if a KDE 3.2 beta or 3.1 built against Qt 3.2 goes in, that is good enough for me. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: Debian Weekly News - August 19th, 2003
Jérôme Marant [EMAIL PROTECTED] wrote: Quoting Scott James Remnant [EMAIL PROTECTED]: No he wouldn't. FDL is about free documentation. :-) Except it isn't :-) According to you :-) According to debian-legal consensus.
Re: Bits from the RM
cobaco dijo [Wed, Aug 20, 2003 at 11:08:28AM +0200]:
KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!)
kde 3.2 release is slated for 8th december[1], is there any chance we'll
wait
for it, just so the outdated kde label doesn't apply again immediately after
release?
...And then wait for some 4 months in order for KDE 3.2 not to have all
the bugs introduced by a freshly sent major version? And then, we would
not have an excuse for not including Gnome 2.4... But by the time we got
Gnome 2.4 in, we would have to include XFree 4.4 as well, and not
shipping with kernel 2.6 by default would seem odd. But by then, KDE 3.3
would be knocking the door...
Please, this is Debian. We do not need no shiny new versions of neither
${package} nor ${subsystem}.
Greetings,
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: what about ip's
David Smith [EMAIL PROTECTED] writes: my first assumption is that charter sells their users email addresses. does anyone on this list know how an unused email address that has never been used can have spam without the ip giving the address out? Is it a fairly simple username, like dsmith? Those can get caught by spammers blindly sending to common usernames. Now, if the username were something like hkja89ZJNhks8S12 and got spammed, someone in the organization is probably selling usernames, but it could just be a rogue employee. -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Women were made to be loved, not to be understood.
Re: Non-free software on linex [was Re: Debian Weekly News - August 19th, 2003]
On Wednesday 20 August 2003 20:13, Hans Ekbrand wrote: There's more of it: http://www.linex.org/sources/linex/debian/linex/ lists acroread_4.05-3, mplayer_0.90pre5-3 flashplugin-nonfree_6.0.79-1, hsflinmodem-linex_0.5.2-1 ... and j2re, yes, I saw that afterwards... Some are quite badly packaged, by the way... Mike
Re: #206298 spip: prerm script blindly removes directories
On Wed, Aug 20, 2003 at 07:53:41PM +0200, Gaetan Ryckeboer wrote: Not necessary. Web administrators may upload files via FTP, andspip users never use them onto spip ? If so, the files will stay in place in upload, instead of beeing integrated onto the spip tree at the right place, and being logged in the sql database. In which case should you be deleting them? I would say no. While they are in that directory, they are not used by spip and thus not really a part of spip. The user(s) put them there, when in doubt, leave them there. Yes it needs. I've still moves documentation to usr/share/doc, instead of spip/ecrire/doc, but it is rather different with the cache and other application managed files. You may access the php files via apache, but php files may access to other php file, or static file. For instance, to modify the configuration, or read the cache. Yes, symlinks are needed for direct file access (unless you patch the source). Sorry, when I stated symlinks weren't needed I meant on the Apache side. I've dealt with this exact problem in my packaging of Media Mate (new name for Movie Mate). I'm currently using symlinks to allow the php script to access files by the paths they expect and Apache Alias directives to allow http requests to get the files without enabling symlink following. I accept. Please send me examples in private, if you found a way to move php files accessing each other (via include) in another directory, without patching the application. I'll forward Media Mate's packaging over to you. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: non-DD contributors and the debian keyring
[answer to a private mail on the list with the permission of Christian] On Wed, Aug 20, 2003 at 02:53:49PM +0200, Christian Kurz wrote: On [19/08/03 18:05], Martin Quinson wrote: point is that currently, DD is very very strict about who can upload to the source and the packages, but when I submit a translation to someone who do not speak french, he have to trust me. Well, but even if you are a DD, I would have to trust you and the translation that you provided. And for me that trust doesn't depend on the signature of the e-Mail that contained the translation. For me it doesn't matter if you send me a translation know, with your key signed or with your key in the debian-keyring. I will in both cases apply the same procedure before including the translation. Of course, the signature is not sufficient to get the needed trust. But I'm coordinator of the french translation team since a few years, so my skills should be trustable, I guess. But the point is that without the key, anyone can forge mails which seem to come from me, and thus abuse the trust my work gained me in the mind of some DDs. I see this point as necessary even if not sufficient. That is to say that if I were DD, I would never trust any contribution I cannot check myself and comming from someone I'm not confident in 1) the identity 2) the skills. Judging from the amount of translation rotting in the BTS, I guess some of you guys react the same way, and I want to change this by easing this trust relationship, if possible. Thanks for your time, Mt. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Re: Bits from the RM
El 20-ago-2003 a las 09:49:03, Adrian von Bidder escribió: Content-Description: signed data On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? What about Apache? Should we change the apache2 package to apache? This release will be a funny challenge, so, let's have fun :) Regards, -- Teófilo Ruiz Suárez ||(teo)|| Sevilla, España [EMAIL PROTECTED] GnuPG Key ID: 420718E6 FPR: 0280 862C 064B FA76 9A1C EB64 5755 A66C 4207 18E6 pgpvE8A9WaZQn.pgp Description: PGP signature
Re: FTBFS: architecture all packages
On Wed, 20 Aug 2003, Matthias Urlichs wrote: Why not? Just block binary uploads completely, and let everything get built by the buildds. I certainly plan to do that with my own uploads. (I've already set up my own buildds). I'd go one step farther and schedule a low-priority rebuild of everything that build-depends on a package which gets updated. How about this: * Maintainer does normal build, doing -all and -arch debs. Maintainer uploads. * dak verifies upload as normal. * dak adds new source to unstable, but not the debs. * buildds then proceed to build new source. one buildd is choosen to build the -all debs.
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote: * Martin Quinson ([EMAIL PROTECTED]) wrote: On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote: keyring.debian.org has only DDs in it. I think people were suggesting using the public keyservers. keyring.debian.org isn't a part of the public key servers. That's the part of the system I was criticizing :) Not going to change. Quite definitive answer.. Ok, I guess I got my answer and go back to work ;) Nevertheless, should he trust the meaning of my translation blindly? I mean, it could contain offending material, and even unlegal material. I guess that there will be someone to engage pursuits if dpkg subtly displayed racial crime incitation, or so. To some extent that's what unstable is for. Right I doubt a poor translation would make it into a released version. A lot of poor translation get into stable, mainly by lack of manwork, but you are right no offending translation gets into testing. At least in french. Who will get sued in such situation? I guess Debian in first place, but if I understand well, the whole identification process of the NM is exactly about giving Debian the possibility to report the charges on the guilty developper when sued, isn't it? Ehhh, I'm not sure I'd agree with that specifically, but whatever. Mmm. If so, I really cannot understand the big deal with IDs when signing the key. Knowing my ID is not enough to prove that I won't upload a rootkit, and it is not even needed... I must be perticulary dumb. Honestly I see there being a very big difference between having rude things done in a translation and, for example, having packages which install rootkits. Sorry, that's just life. Sure. Who said the contrary ? I said that really broken translation can lead to issues, too (type 'Y' to erase/list the content of your home dir ;). I never said that it was the most important point in Debian. I'm not *that* dumb ;) I know about the public servers, but I was wondering why Debian make things harder for the DD while it has the infrastructure to simplify their work. What is harder for the DD and how could the existing Debian infrastructure fix that? Nothing in what you've said would lead me to believe that there's something we can change which would make things easier for the DD with regard to 'poor' translations. The whole story is about easing the technical issue in a trust relationship. Of course, I could (and have) uploaded my key on public servers, meaning that other Debian member could check than a given mail with my address desserve the trust they habitually give me. But those guys would have to configure their email specifically on people like me[*]. I was wondering if could be avoided, that's all. A really great improvement of this situation would be to make easily available the keys of people in the NM queue, since translators are supposed to become debian developer, too. But, ok, if the majority here says that there would not be sufficient benefit wrt the effort, I guess I'll have to deal with it. Easy :) Thanks for your time, and sorry for preventing you fixing bugs. Mt. [*] Yeah, I use my personal example because of my borken non-native english, to ease my sentences and have a little chance to get them right, But in fact, we are a whole bunch in my situation. -- Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe. --- F. Nietzsche
Re: Proposal: make kernel install easier
On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV [EMAIL PROTECTED] said: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config Why on earth are you hand editing the lilo.conf file for every kernel image? The postinst already manages two symlinks for you that can be in the lilo.conf file. If you have to hand edit lilo.conf for every kernel image, you are doing something wrong. For the clever, you can manage any number of symlinks automatically for yourselves; the latest kernel-package gives an example of creating a set of symlinks for 2.4 kerels, another set for 2.5 kernels, and so on. files for other bootloaders, from grub Another bad example. For grub you do not need to muck around with symlinks at all, you have update-grub, and again, the kernel-package package gives examples on how to use this script. to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. Rubbish. It is not our of date at all, as long as you have written it corectly, and to be compatible with the image postinst. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. For example, quik could have debconf questions: Manage quik.conf using debconf? and Install new kernels automatically? and perhaps Global kernel option defaults (though perhaps this would be better outside of each individual bootloader). Then each kernel package would have a low- to med-priority debconf question asking with what options to boot the kernel starting from global defaults. It could also ask whether to make this image top priority in the .conf, and what name string to use for this image. Also, quik could Provide virtual package bootloader which kernel-image packages could Suggest. Bloat. You have not yet demonstrated a need that can't be met with the current infrastructure (your examples are fraught with an ignorance of current practice). If there's interest (and no show-stoppers anyone can think of), I'll Well, too late. There are show stoppers galore (lack of need for such bloat being just one of them). start writing patches to kernel-package, lilo, maybe even quik :-) -- that is, unless someone else wants to, e.g. their maintainers. Secondly, most of this creeping featurism does not belong in kernel-package proper, but should be off loaded to the hook scripts. [Please CC me in replies as I'm not subscribed. And apologies if In the old days, it was considered rude to ask questions on a forum when you were not subscribed. this has been brought up before; searches on lists.debian.org didn't turn up anything.] It has not only been brought up, solutions have been found and have been implemented. manoj -- We were so poor we couldn't afford a watchdog. If we heard a noise at night, we'd bark ourselves. Crazy Jimmy Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
ALERT: You may have sent a Virus
Dear debian-devel@lists.debian.org, JARING E-Mail Virus Scanner has detected virus(es) in your e-mail attachment(s) Original Date: Aug 21 02:56:50 Original Sender: debian-devel@lists.debian.org Original To: [EMAIL PROTECTED] Original Subject: Re: Your application Virus info:- Attachname: h7KIumso01649 was infected with [EMAIL PROTECTED], and deleted Thank you, JARING E-Mail Virus Scanner ( http://www.jaring.my )
Re: Proposal: make kernel install easier
On Wed, 2003-08-20 at 14:25, Josh Lauricha wrote: On Wed 10:51, Adam C Powell IV wrote: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. Don't know about your system, but /vmlinuz and /vmlinuz.old always point to the correct images and lilo.conf is set to use those by default. So, whenever I upgrade the kernel this is all taken care of. Not necessarily. Ever removed a kernel? Or tried to switch between kernels with and without initrd.imgs? (Or perhaps you don't use the stock Debian 2.4 kernels...) Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: Bits from the RM
On Wed, Aug 20, 2003 at 04:34:18PM +0200, cobaco wrote: KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by almost two months: * October 15th Final, last-minute, low-risk bug fixes only Monday September 29th, 2003: Preparing Beta1 The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1] is there any reason why stabilization of kde and stabilization of kde-packaging can't be done in parallel? Er you want the final version of KDE in stable to be a KDE 3.2 Beta 1 release? ;) It takes well more than 10 days on average for KDE to be ready to migrate to sarge, esp with slow buildds such as m68k and mips. And with KDE 3.2 Beta 1 releasing to packagers on Sept 29 it won't have even finished building on the buildds much less waited the required 10 days by Oct 1. Debian 3.1 Dates Sept 1 Toolchain freeze. Sept 15 Major package freeze. Oct 1 Everything freezes(?) Chris
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Goswin von Brederlow wrote: Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Wed, 20 Aug 2003, Goswin von Brederlow wrote: The only problem with that is the current failure to comply to policy, i.e. build from source as they should. The question remains is simply removing all the extra source from webmin-n.orig.tar.gz except that which is necessary to build the webmin binary package (i.e not any of the modules which will have their own source and binary packages) an aceptable solution to the problem or not? From what I read in this thread webmin-n.orig.tar.gz also contains some non-free sources, right? It has source for all the modules including the non-free ones. However the binary packages for those modules are built from seperate source packages not this one. Then you have no choice but split it up to get the rest into main. And when you don't have a pristine upstream orig.tar.gz you can split it up as far as you like or need to. The only reason for having the webmin.orig.tar.gz as it is was to provide something approximating the upstream tarball. It sounds like I don't need to bother about that. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Locales in display managers (Was: Re: Locales in init scripts (about gdm bug #147091))
Ok, but /etc/default/language is not created by the locales package which does currently asks the system's default language, but saves it in /etc/environment instead. The question is: Is it ok to a display manager source /etc/environment (at least until another definition is made) into the init script? Because that's the only way (except if init itself set the LANG variable, or the locales package generate /etc/default/language) to get the x login prompt using the system's default locale? P.S.: This is an annoying bug that can be closed with a 1-line patch, but it isn't because of this indefinition (See maintainer comments into the bug history). --daniel Em Qua, 2003-08-20 às 07:53, Javier Fernández-Sanguino Peña escreveu: On Mon, Aug 18, 2003 at 12:19:03PM -0300, Daniel Ruoso wrote: Hi. (...) So, how to make the init scripts localized? What do you think? /etc/default/language? I believe this has been discussed previously, see for example [1] and debian-boot [2]. From briefly looking at redhat's redhat-config-language program (a GUI to setup precisely this) it seem they use /etc/sysconfig/i18n for this (is there also an /etc/sysconfig/language?) which gets sourced from scripts (lang.sh, lang.csh) in /etc/profile.d to setup the user's environment and by /etc/rc.d/init.d/functions which is incorporated by init.d programs. IMHO to get init scripts localized a similar (and policy mandated) set of functions (including i18n/l10n) should be implemented. Locale configuration (or boot-floopies/d-i for that matter) should then modify those on admin's request. Regards Javi [1] www.debian.org/News/weekly/1999/27/mail [2] lists.debian.org/debian-boot/2001/debian-boot-200105/msg00667.html -
Re: Proposal: make kernel install easier
On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote: Adam C Powell IV [EMAIL PROTECTED] writes: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. I believe lilo and grub already have that. From /boot/grub/menu.lst ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default optons below There is also a mechanism in dpkg to install hooks now which is hopefully already used to run update-grub. Cool, did not know. I guess a hooks mechanism would be required for unmodified kernel-image packages... My proposed system would add user control of menu entry names/labels, and finer-grained control of boot options (without editing the .conf files), but these don't seem worth the overhead of such a system. Is this documented somewhere, or should I just look at the latest lilo and grub packages to see how to adapt this to other bootloaders? It would be nice if this were somewhat uniform (at least to the user) across loaders and architectures. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: Proposal: make kernel install easier
On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote: On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV [EMAIL PROTECTED] said: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config Why on earth are you hand editing the lilo.conf file for every kernel image? The postinst already manages two symlinks for you that can be in the lilo.conf file. If you have to hand edit lilo.conf for every kernel image, you are doing something wrong. See my reply to Josh Lauricha: kernel-image packages corrupt the vmlinuz(.old) symlinks when removing a kernel, and switching between kernels with and without initrd.img is not supported. For the clever, you can manage any number of symlinks automatically for yourselves; the latest kernel-package gives an example of creating a set of symlinks for 2.4 kerels, another set for 2.5 kernels, and so on. files for other bootloaders, from grub Another bad example. For grub you do not need to muck around with symlinks at all, you have update-grub, and again, the kernel-package package gives examples on how to use this script. Then /usr/lib/bootloaders/grub would be very small and easy to write. My proposed mechanism would add finer-grained control of boot options (e.g. apm=on for 2.2 kernels but not 2.4) and of menu entry names/labels, with little additional coding. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. For example, quik could have debconf questions: Manage quik.conf using debconf? and Install new kernels automatically? and perhaps Global kernel option defaults (though perhaps this would be better outside of each individual bootloader). Then each kernel package would have a low- to med-priority debconf question asking with what options to boot the kernel starting from global defaults. It could also ask whether to make this image top priority in the .conf, and what name string to use for this image. Also, quik could Provide virtual package bootloader which kernel-image packages could Suggest. Bloat. You have not yet demonstrated a need that can't be met with the current infrastructure (your examples are fraught with an ignorance of current practice). Please forgive me, I had not known that a newer version of quik had just been uploaded which supports such features, and that's what I use to boot my one fully-unstable machine (i.e. not just a chroot). If there's interest (and no show-stoppers anyone can think of), I'll Well, too late. There are show stoppers galore (lack of need for such bloat being just one of them). start writing patches to kernel-package, lilo, maybe even quik :-) -- that is, unless someone else wants to, e.g. their maintainers. Secondly, most of this creeping featurism does not belong in kernel-package proper, but should be off loaded to the hook scripts. Now that there are hook scripts, this makes some sense. But if you think about it for a few seconds, the bloat and creeping featurism of the proposed bootloader scripts is no greater than that required for hook scripts -- in fact, that's what they are (inspired by e.g. update-cluster). [Please CC me in replies as I'm not subscribed. And apologies if In the old days, it was considered rude to ask questions on a forum when you were not subscribed. Then I am glad I do not live in the old days. this has been brought up before; searches on lists.debian.org didn't turn up anything.] It has not only been brought up, solutions have been found and have been implemented. Again forgive me, I had not known these solutions had been applied to aboot, quik, palo, etc. Thank you for the kind and courteous reply, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#206477: ITP: libtunepimp -- MusicBrainz tagging library and simple tagger application
Package: wnpp Version: unavailable; reported 2003-08-21 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libtunepimp Version : 0.2.1 Upstream Author : Robert Kaye [EMAIL PROTECTED] * URL : ftp://ftp.musicbrainz.org/pub/musicbrainz/ * License : GPL2 Description : MusicBrainz tagging library and simple tagger application Libtunepimp simplifies tagging your audio files with the correct data about artist, album and track title using the MusicBrainz infrastrucure. It works on top of libmusicbrainz and libraries to read audio in mp3 files and ogg files. Included is tp_tagger, a simple example tagger application. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q/4ZHSjkv+Av7xERAq+8AJ9OvOJTwNINsfsfUzXxlxZAsBTN3wCfRea1 3ateDFz2qezmXTZZk8BK5S0= =EONA -END PGP SIGNATURE-
Re: Bug#205927: ITP: eggdrop -- Advanced IRC Robot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday August 17 2003 09:35 am, Peter Makholm wrote: Guilherme de S. Pastore [EMAIL PROTECTED] writes: * Package name: eggdrop Version : 1.6.15 Upstream Author : EggHeads [EMAIL PROTECTED] * URL : ftp://ftp.eggheads.org/pub/eggdrop/source/1.6/eggdrop1.6.15.tar.gz * License : GPL Description : Advanced IRC Robot Eggdrop is an IRC bot written in C. Eggdrop, being a bot, sits on a channel Seems to be packaged allready. He's taking it over from me. Guilherme, I believe that all you need to do is upload your package with your name in the Maintainer field of debian/control. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/RAiYHJcvLJR6wWoRAk3mAKCOEnerAsFWI2SD065pI1bb7gInwACgoxuP dPNJhspnj9j05ek0UsRoTYw= =ICeZ -END PGP SIGNATURE-
Re: ftp.gnu.org cracked
Scott James Remnant wrote: No problem, this is only a quick run -- others may find ways to improve this script somewhat. !! xaos: xaos_3.0.orig.tar.gz NOT OK (e0e66a873b6d5193a79bc89345992d6b != 5a63c3b696821e5d5d566ad9da308117) Diff shows the following differences: [EMAIL PROTECTED]:~/tmpdiff -ur fsf/xaos-3.0 deb/XaoS-3.0 diff -ur fsf/xaos-3.0/src/include/xio.h deb/XaoS-3.0/src/include/xio.h --- fsf/xaos-3.0/src/include/xio.h 1998-03-15 15:45:48.0 -0500 +++ deb/XaoS-3.0/src/include/xio.h 1998-03-04 16:49:12.0 -0500 @@ -10,8 +10,8 @@ /*returns xio_file or XIO_FAILED in case it failed*/ #define xio_ropen(fname) fopen(fname,r) #define xio_wopen(fname) fopen(fname,w) -#define xio_rbopen(fname) fopen(fname,rb) -#define xio_wbopen(fname) fopen(fname,wb) +#define xio_rbopen(fname) fopen(fname,r) +#define xio_wbopen(fname) fopen(fname,w) /*returns non zero in case of error*/ #define xio_close(fname) fclose(fname) #define XIO_FAILED NULL To complicate things, there is a third file, on sourceforge.net. This file, XaoS-3.0.tar.gz, md5sums to fa26ce9805d4889174c891b334da6d09. Diff shows no differences between it and the fsf version; inspection shows that they unpack to different directories. Probably this tarball was repackaged to meet FSF standards. The original site I downloaded xaos from in 1998, http://limax.paru.cas.cz/~hubicka/XaoS/ (and packaged as pristine source), is no longer around. Probably the addition of the b's to the fopens happened sometime after that, in a repackaged version of xaos. Since b has no effect in Debian anyway, it's not worth thinking about anymore. :-) -- see shy jo pgpA1pU6JpwWQ.pgp Description: PGP signature
vacation mail
mail recived
Your message was rejected because it contained a virus
Your message was rejected because it contained the file your_details.zip which contains a virus. For more information on this virus please see http://securityresponse.symantec.com
Re: non-DD contributors and the debian keyring
* Martin Quinson ([EMAIL PROTECTED]) wrote: On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote: keyring.debian.org has only DDs in it. I think people were suggesting using the public keyservers. keyring.debian.org isn't a part of the public key servers. That's the part of the system I was criticizing :) Not going to change. Nevertheless, should he trust the meaning of my translation blindly? I mean, it could contain offending material, and even unlegal material. I guess that there will be someone to engage pursuits if dpkg subtly displayed racial crime incitation, or so. To some extent that's what unstable is for. I doubt a poor translation would make it into a released version. Certainly not if we actually start getting a sizable number of people using the translated versions of things. Unfortunately there really isn't a whole lot of choice in the matter either. I dunno in the states, but such things can bring you in jail for a bunch of few months (if not years) in France. And it should be easy to insert illegal material for the US in displayed text, thanks to your wonderfull anti terrorist and digital right management acts... I'm not sure it's as easy as you suggest but that's not really on the topic anyway. Who will get sued in such situation? I guess Debian in first place, but if I understand well, the whole identification process of the NM is exactly about giving Debian the possibility to report the charges on the guilty developper when sued, isn't it? Ehhh, I'm not sure I'd agree with that specifically, but whatever. So, I ask again, shouldn't Debian check the real identity of contributors when the maintainer is unable to check the material himself ? Checking the identity doesn't really help in the situation you've described. If someone not in france submitted a translation patch that had stuff which is illegal in france I doubt they'd be touched, even if you could identify them. Debian servers in France would be targeted and the operators, not even the DDs, would be the ones who could get in trouble. One could have similar concerns about the BTS due to the fact that it displays emails sent to it. This isn't really a new thing which makes me not really worried about it in the end. If it's ok so, what is the big deal of asking the DD for having a trusted key and signing the packages, anyway ? Honestly I see there being a very big difference between having rude things done in a translation and, for example, having packages which install rootkits. Sorry, that's just life. I know about the public servers, but I was wondering why Debian make things harder for the DD while it has the infrastructure to simplify their work. What is harder for the DD and how could the existing Debian infrastructure fix that? Nothing in what you've said would lead me to believe that there's something we can change which would make things easier for the DD with regard to 'poor' translations. Stephen pgpncY6hChw32.pgp Description: PGP signature
Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)
On Wed, 2003-08-20 at 12:53, Fumitoshi UKAI wrote: Joe Wreschnig [EMAIL PROTECTED] libtest-unit-ruby1.8 (- libtest-unit-ruby) Actually, I now only maintain Test::Unit for Ruby 1.6. Since it became included with 1.8, akira yamada maintains that version, and when 1.8 was packaged I dropped support for 1.7 from my package. I'll rename the 1.6 package appropriately, though, but I'll wait until the Ruby/GTK packages are renamed (unless that's going to take a very long time?) Currently, ruby upstream doesn't support such version independent module path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later to support this? I think so, but I'm open to suggestions about it. It does IMO make packaging modules without C code much simpler. The downside is when a major incompatibility happens (i.e. code that works correctly on more than one version is impossible), but I believe this is a rare enough case to ignore (AFAIK it's never happened). -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: non-DD contributors and the debian keyring
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote: Usually the sponsor looks everything over so signing is not realy neccessary. Of cause if you have the same sponsor repeatetly he might want to just check your signature and sponsor the changes blindly knowing you did good work in the past. This should never, ever, ever happen. We have the NM process for a reason and sponsoring things blindly goes completely around it. If you're having to alot of sponsoring from someone then I think the appropriate action would be to drop a mail to the appropriate people informing them of this. If you point out the sponsored uploads you've had to do and the additional work you're having to do which will be removed once the NM becomes a DD I expect things might move a little faster towards that. Stephen pgpa1esOztUcB.pgp Description: PGP signature
Re: Proposal: make kernel install easier
On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote: On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV said: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config Why on earth are you hand editing the lilo.conf file for every kernel image? Well, if they move from an installation kernel to a kernel-image package, they have to add an entry for an initrd file. After that, if they upgrade to another kernel-image package and want to be able to use both the new and the old they need to edit the old entry for an initrd too. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Bits from the RM
On Wed, Aug 20, 2003 at 03:13:11AM -0500, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? An educated guess would produce: [...] XFree 4.3.0 (Branden wants this to happen...) If other people want it to happen as well, I need volunteers for the X Strike Force. I'm the only person doing significant commits lately. Interested parties, please catch up on the last month's worth of traffic to the debian-x mailing list to get a feel for the environment. If you're not scared after that, please join the list and talk about what you'd like to work on. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven pgpOkk6rvAf2U.pgp Description: PGP signature
Packages-arch-specific
Hello, One of my package (camstream) was removed from Packages-arch-specific more than one month ago in the CVS [1]. However, as the corresponding file on buildd.debian.org [2] is not updated, my package is still not built on architectures other than i386. Could somebody with a root access on auric do a cp /org/buildd.debian.org/web/quinn-diff/tmp/Packages-arch-specific /org/buildd.debian.org/web/quinn-diff ? Thanks, Aurelien [1] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak [2] http://buildd.debian.org/quinn-diff/Packages-arch-specific pgpcWfzc79PA9.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 08:49:44PM +0200, Martin Quinson wrote: What recent change in the KDE releasing schema let you think that they will manage to get a really stable x.y.0 release [*] when it seems like it took 4 minor releases in the 3.1 branch ? Naturally, no offense intended to the kde guys. Needing only 4 minor releases to stabilize such an amount of code is really great. Bye, Mt. [*] ie, suitable for debian stable release, ie a version with which you could live for a year on your desktop, maybe dreaming of new features (we always want more), but not pesting against the bugs. I speak of course of the ideal debian stable release ;) KDE usually releases new point releases about every two months until the next major release happens. Then they only update for security related bugs. It doesn't magically become stable after 4 releases. Chris
Re: Bits from the RM
On Wed, Aug 20, 2003 at 11:18:24AM -0600, Bruce Sass wrote: On Wed, 20 Aug 2003, cobaco wrote: I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 - 3.2 is evolutionary without big changes to what was already there. It does not take a big change to break software... e.g., openssh changed a message and the sftp kioslave broke http://bugs.kde.org/show_bug.cgi?id=51359 Not that I disagree with you, but frankly, the sftp kioslave was already broken. It should never have been written to depend on 'ssh -v' output. CHeers, -- Colin Watson [EMAIL PROTECTED]
Content violation
Content violation found in email message. From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Thank you! Matching Subject: *thank you!*
Your message to Consume-thenet awaits moderator approval
Your mail to 'Consume-thenet' with the subject Re: Wicked screensaver Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.consume.net/mailman/confirm/consume-thenet/a0ebfaa83c1a24e8eba7a5964deec76ef6882db6
Re: non-DD contributors and the debian keyring
On Wed, 20 Aug 2003 23:29:52 +0200, Martin Quinson [EMAIL PROTECTED] said: But the point is that without the key, anyone can forge mails which seem to come from me, and thus abuse the trust my work gained me in the mind of some DDs. So start signing your email. I'll download the key in I need to check wo you are -- and if your key has a DD sig on it, it is in the web of trust, once removed. manoj -- Dyslexics of the world, untie! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Your message to Consume-thenet awaits moderator approval
Your mail to 'Consume-thenet' with the subject Re: Wicked screensaver Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.consume.net/mailman/confirm/consume-thenet/8dfc3e54932d47d26bdc95b2abf36989fd96f339
Re: ftp.gnu.org cracked
On Wed, 2003-08-20 at 20:16, Peter Karlsson wrote: Scott James Remnant: No problem, this is only a quick run -- others may find ways to improve this script somewhat. What did you use to determine which packages to check? I notice that at least my package for GNU jwhois is missing from your list (although I know that the Debian version is correct since I post the versions to Debian and ftp.gnu.org at the same time...). If you read the script, you'll see it just checks what it can find. The only MD5 sums that GNU have provided are for 2.4, 2.4.1 and 2.4.2 Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Proposal: make kernel install easier
On 20 Aug 2003 15:39:18 -0400, Adam C Powell IV [EMAIL PROTECTED] said: On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote: Adam C Powell IV [EMAIL PROTECTED] writes: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. I believe lilo and grub already have that. From /boot/grub/menu.lst BEGIN AUTOMAGIC KERNELS LIST lines between the AUTOMAGIC KERNELS LIST markers will be modified by the debian update-grub script except for the default optons below There is also a mechanism in dpkg to install hooks now which is hopefully already used to run update-grub. Cool, did not know. I guess a hooks mechanism would be required for unmodified kernel-image packages... *Sigh*. There already is one implemented. My proposed system would add user control of menu entry names/labels, and finer-grained control of boot options (without editing the .conf files), but these don't seem worth the overhead of such a system. You can do this without needing to modify kernel-package itself. Is this documented somewhere, or should I just look at the latest lilo and grub packages to see how to adapt this to other bootloaders? It would be nice if this were somewhat uniform (at least to the user) across loaders and architectures. If ti is feasible at all (and I have no idea if it would be), the hooks mechanism in kernel-package should enable you to do this as a third party package. manoj -- To YOU I'm an atheist; to God, I'm the Loyal Opposition. Woody Allen Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Binaryless uploads
On Wed, 20 Aug 2003 15:03:15 -0400 (EDT), Jaldhar H Vyas [EMAIL PROTECTED] said: It has source for all the modules including the non-free ones. However the binary packages for those modules are built from seperate source packages not this one. The only reason for having the webmin.orig.tar.gz as it is was to provide something approximating the upstream tarball. It sounds like I don't need to bother about that. Since the source goes into Debian main, keeping the sources together means that we are distributing non-free material in Debian main, which not only violates the social contract, it may well be illegal (or have people who distribute debnian CD's indulge in illegal activity), depending on how non free the non free bits are. This needs be corrected ASAP, and a bug needs be filed on ftp.debian.org to have the old sources, containing the non-fee bits, be removed from main. manoj -- We don't really understand it, so we'll give it to the programmers. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
Goswin von Brederlow [EMAIL PROTECTED] writes: I do have the following four cases: package package-version package-version.debian_version package-cvs It should definitely allow package-upstreamver, since that's more or less canonical. However, generalizing a bit and simply checking that the name of the directory starts with the name of the source package would allow your other cases while still avoiding things like $HOME (unless your username happens to match the package name, but that's probably too much of a corner case to worry about). BTW, no need to Cc: me. (No big deal, though.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: ftp.gnu.org cracked
On Wed, Aug 20, 2003 at 07:59:13PM -0400, Joey Hess wrote: Since b has no effect in Debian anyway, it's not worth thinking about anymore. :-) ...except to swear under our breath about upstreams who sneak in changes without bumping the version number (I personally find this very annoying). -- - mdz
Re: non-DD contributors and the debian keyring
On Thu, 21 Aug 2003 00:16:47 +0200, Martin Quinson [EMAIL PROTECTED] said: Mmm. If so, I really cannot understand the big deal with IDs when signing the key. Knowing my ID is not enough to prove that I won't upload a rootkit, and it is not even needed... I must be perticulary dumb. It is retaliation ;-). If your key has been signed, and identity known, we would know where to send the black helicopters. Of course, I could (and have) uploaded my key on public servers, meaning that other Debian member could check than a given mail with my address desserve the trust they habitually give me. But those guys would have to configure their email specifically on people like me[*]. I was wondering if could be avoided, that's all. Umm, my MUA can download the keys from a keyserver all by itself, and verify the signature; until needed my trust is given to the owner of the key (as I said, the real world id is only needed for the pilot of the black helicopter). manoj -- Blessed is he who expects no gratitude, for he shall not be disappointed. W.C. Bennett Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposal: make kernel install easier
On 20 Aug 2003 16:04:50 -0400, Adam C Powell IV [EMAIL PROTECTED] said: On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote: On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV [EMAIL PROTECTED] said: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config Why on earth are you hand editing the lilo.conf file for every kernel image? The postinst already manages two symlinks for you that can be in the lilo.conf file. If you have to hand edit lilo.conf for every kernel image, you are doing something wrong. See my reply to Josh Lauricha: kernel-image packages corrupt the vmlinuz(.old) symlinks when removing a kernel, and switching between kernels with and without initrd.img is not supported. You can replace the symlink handling of kernel-image packages on the target machine, without modifying kerel-package. And yes, lilo conf files can be tricky with the default symlink handling --- but the example postinstall hook script demonstrates that all this canm be handled exernally to kernel-image packages. For the clever, you can manage any number of symlinks automatically for yourselves; the latest kernel-package gives an example of creating a set of symlinks for 2.4 kerels, another set for 2.5 kernels, and so on. files for other bootloaders, from grub Another bad example. For grub you do not need to muck around with symlinks at all, you have update-grub, and again, the kernel-package package gives examples on how to use this script. Then /usr/lib/bootloaders/grub would be very small and easy to write. My proposed mechanism would add finer-grained control of boot options (e.g. apm=on for 2.2 kernels but not 2.4) and of menu entry names/labels, with little additional coding. The apm=on for 2.2 kernels can already be handled (see the sample postinst hook script provided for hints). I suppose dynamically creating labels is desirable, but all this can be a light weight /usr/sbin/update-lilo-conf script. Please forgive me, I had not known that a newer version of quik had just been uploaded which supports such features, and that's what I use to boot my one fully-unstable machine (i.e. not just a chroot). quik does not follow symlinks? Now that there are hook scripts, this makes some sense. But if you think about it for a few seconds, the bloat and creeping featurism of the proposed bootloader scripts is no greater than that required for hook scripts -- in fact, that's what they are (inspired by e.g. update-cluster). I have no idea what update-cluster is, so I doubt if they were inspired by that (I am an emacs user, hooks are old hat to us). In any case, kernel-package alreasy impolements hooks. The fact that you came in talking about patching kernel-package without even being aware of current capabilities is disheartening -- and leads one to suggest you look at what kernel-image postinst does before you create new solutions. It has not only been brought up, solutions have been found and have been implemented. Again forgive me, I had not known these solutions had been applied to aboot, quik, palo, etc. So do some research about what the postinst does already. If you want to create a third party set of scripts to handle updating various boot loaders, fine. But your use cases for such a change were ill chosen. Thank you for the kind and courteous reply, Thank you for the courtesy of researching the problemset before proposing solutions. manoj -- %DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: python 2.2 - python 2.3 transition
On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. Sure you can: $ sudo apt-get install python2.3 The dependency stuff merely notes that upgrading python without also upgrading wxgtk-python may break stuff. actually, if the dependencies are right, you cannot upgrade to python (2.3) without also upgrading to wxgtk-python (2.3) or de-installing wxgtk-python (2.2). There is a difference between break stuff and not installable :-) When the dependencies are right, you can't break stuff, because a broken combination is not installable. if you can then the dependencies are wrong and you should file a bug-report. -- Donovan Baarda [EMAIL PROTECTED]
Accepted airsnort 0.2.2-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 08:29:00 +0200 Source: airsnort Binary: airsnort Architecture: source i386 Version: 0.2.2-3 Distribution: unstable Urgency: low Maintainer: Noel Koethe [EMAIL PROTECTED] Changed-By: Noel Koethe [EMAIL PROTECTED] Description: airsnort - WLAN sniffer Closes: 202948 Changes: airsnort (0.2.2-3) unstable; urgency=low . * installed missing manpages (closes: Bug#202948) * updated Standards-Version Files: 0a93f568980b1d80d7158059026331ca 664 net optional airsnort_0.2.2-3.dsc 9c31de2a59d2589f987df0a08c46281e 25151 net optional airsnort_0.2.2-3.diff.gz db584570f9b549e9c7eb417b8dbf8242 50218 net optional airsnort_0.2.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QxWv9/DnDzB9Vu0RAnrgAJ9hBjrwY1OUlt77KMGfg+ElbwySUwCfZBY+ VzyQBTHmvlHnWuMIVKq2N70= =UH2O -END PGP SIGNATURE- Accepted: airsnort_0.2.2-3.diff.gz to pool/main/a/airsnort/airsnort_0.2.2-3.diff.gz airsnort_0.2.2-3.dsc to pool/main/a/airsnort/airsnort_0.2.2-3.dsc airsnort_0.2.2-3_i386.deb to pool/main/a/airsnort/airsnort_0.2.2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-patch-2.4-lsm 2003.08.13-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 16:49:00 +1000 Source: kernel-patch-2.4-lsm Binary: kernel-patch-2.4-lsm Architecture: source all Version: 2003.08.13-2 Distribution: unstable Urgency: low Maintainer: Russell Coker [EMAIL PROTECTED] Changed-By: Russell Coker [EMAIL PROTECTED] Description: kernel-patch-2.4-lsm - lsm-full kernel patch - Linux Security Modules Changes: kernel-patch-2.4-lsm (2003.08.13-2) unstable; urgency=low . * Added patch for new-style SE Linux. Files: 7944a95a9855124912ba9f981d3ffc85 560 devel extra kernel-patch-2.4-lsm_2003.08.13-2.dsc a8f7d8424a7a23d85e0dc3fc54435b9b 992667 devel extra kernel-patch-2.4-lsm_2003.08.13-2.tar.gz bb76f1398ff753b3b5891407b465051c 998096 devel extra kernel-patch-2.4-lsm_2003.08.13-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QxnwwrB5/PXHUlYRAhzQAJwMqcCOa+eIq9MHpasltZtsarj/gwCeLjNr dZH2SlsKwkXC3lfOkP07vu4= =q2Cg -END PGP SIGNATURE- Accepted: kernel-patch-2.4-lsm_2003.08.13-2.dsc to pool/main/k/kernel-patch-2.4-lsm/kernel-patch-2.4-lsm_2003.08.13-2.dsc kernel-patch-2.4-lsm_2003.08.13-2.tar.gz to pool/main/k/kernel-patch-2.4-lsm/kernel-patch-2.4-lsm_2003.08.13-2.tar.gz kernel-patch-2.4-lsm_2003.08.13-2_all.deb to pool/main/k/kernel-patch-2.4-lsm/kernel-patch-2.4-lsm_2003.08.13-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted shadow 1:4.0.3-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 02:06:50 -0400 Source: shadow Binary: login passwd Architecture: source i386 Version: 1:4.0.3-9 Distribution: unstable Urgency: low Maintainer: Karl Ramm [EMAIL PROTECTED] Changed-By: Karl Ramm [EMAIL PROTECTED] Description: login - System login tools passwd - Change and administer password and group data. Closes: 79682 94138 110228 118245 166798 171179 171808 183998 186016 196804 198729 200052 200130 204578 205991 Changes: shadow (1:4.0.3-9) unstable; urgency=low . * fix mysterious creeping bug in po/Makefile.in.in, closes: #200052 * dutch debconf translation, closes: #204578 * switch to po-debconf, closes: #183998, #200130 * use automake1.7, closes: #205991 * update german debconf translation, closes: #94138 * I can't come up with a good justification as to why characters other than ':'s and '\0's should be disallowed in group and usernames (other than '-' as the leading character). Thus, the maintenance tools don't anymore. closes: #79682, #166798, #171179 * Fix typo in /etc/pam.d/su. closes: #196804 * danish debconf translation, closes: #118245 * russian debconf translation, closes: #198729 * And last, but not least, what's undoubtedly going to be the most popular change: md5 passwords are turned on by default, and there is no prompt to change them. Yes, this is reduced functionality. No, it can't go back in the way it was; the old code not only modified conffiles, it modified *other*packages* conffiles and was a massive policy violation. I expect this change will motivate the people who have said that they will come up with a proper solution to do so. closes: #186016, #110228, #171808 Files: 5ce2a71d38aded2970d83d7123414c9a 1345 base required shadow_4.0.3-9.dsc 321c5d650a6fddca59a3458e20aa05d1 227610 base required shadow_4.0.3-9.diff.gz f8fed31336e952d7745ed0e06ff750c9 428522 base required passwd_4.0.3-9_i386.deb b3d40a452ce4056ffe63641a49789d05 254758 base required login_4.0.3-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQIVAwUBP0MbwXfSGPI1QaWIAQKsZQ/+NspZt9i4cnmenD778xY2Mylf3fLHTB5f bbwnuy37wTPRAUZIzMF+TqwF42bKMCDq23w7oO8DOGWvcXCXrzhNjsgn2F4DD3Ar YNAbJL7cpyIWfdSpqE7uQzqISL6ohh4CoAKzLT7wgYd4GDFOIdvvmbnMkLUPx8RR UBzYJfIlMZ7PjAMDOU+lUF4fstm1SXQ0u3z+OiMyInPpCaKpd2xOoE1J4d7SmXk0 dadKxB48wMi+144RcG5uZ2YzGjB2tmgENCYuIbqcJ0bdVPCghBFrrnek6iZ9jS07 eYVL9Tv7RzTLpfwBsY8RhIQv/sdP2rdMsOPmX72dXkIFwODNIXbsyyzUPmsR5Ydt uaqYR/+ljAoubOrfJ1i/w0Dq9wMndAM6Xf05yPXyuV1O8XcWbNEPYFjLuJGyVgCT vEFm4dwFcJdlaa9806tmT85g/m1MV4kbaOqlVrV9B6bVqePc1mI7mhxPMLjjf4D+ 1f3l0Gxb05XSCvcDtV2wdez+Z2pAXViHLuAdfiwGRX2wz+7BVmSajXAod4E9lKor J+Wz4AXl8YFKxItqOQOO0s3mFgZJ6ZGujnoMq+L6pNIsoPb1kzCym4V5dcD2nZZx Py8TaS2nHkgsaA7jgRAGNX7CQxSRIjwXTDUO8KDYfD3KSrVXmjqGGxZtsJowXakz /LVQfYao2uo= =LAFZ -END PGP SIGNATURE- Accepted: login_4.0.3-9_i386.deb to pool/main/s/shadow/login_4.0.3-9_i386.deb passwd_4.0.3-9_i386.deb to pool/main/s/shadow/passwd_4.0.3-9_i386.deb shadow_4.0.3-9.diff.gz to pool/main/s/shadow/shadow_4.0.3-9.diff.gz shadow_4.0.3-9.dsc to pool/main/s/shadow/shadow_4.0.3-9.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbuild 0.27 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 09:03:41 +0200 Source: sbuild Binary: sbuild Architecture: source all Version: 0.27 Distribution: unstable Urgency: low Maintainer: Francesco Paolo Lovergine [EMAIL PROTECTED] Changed-By: Francesco Paolo Lovergine [EMAIL PROTECTED] Description: sbuild - Tool for building Debian binary packages from Debian sources Closes: 206270 Changes: sbuild (0.27) unstable; urgency=low . * sg is not available in hurd, removed in postinst and postrm (patch by Michael Banck). (closes: #206270) Files: 0096bc675077cb71dd461b38be5d7050 547 devel extra sbuild_0.27.dsc e1ad617294146fb753798a429d2c7307 51628 devel extra sbuild_0.27.tar.gz fa8feb053ec72f46e6beb09a49a3da7e 55998 devel extra sbuild_0.27_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QyA4pFNRmenyx0cRAsoBAJ0T2+ytPOqmb7WrdUGnR6hAotXW8QCeNpwh EhpwuyybX6SGEYYwMt9MgyU= =//4X -END PGP SIGNATURE- Accepted: sbuild_0.27.dsc to pool/main/s/sbuild/sbuild_0.27.dsc sbuild_0.27.tar.gz to pool/main/s/sbuild/sbuild_0.27.tar.gz sbuild_0.27_all.deb to pool/main/s/sbuild/sbuild_0.27_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yada 0.19 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 10:29:28 +0200 Source: yada Binary: yada-doc yada Architecture: source all Version: 0.19 Distribution: unstable Urgency: medium Maintainer: Piotr Roszatycki [EMAIL PROTECTED] Changed-By: Piotr Roszatycki [EMAIL PROTECTED] Description: yada - Yet Another Debianisation Aid yada-doc - Yet Another Debianisation Aid - documentation and examples Changes: yada (0.19) unstable; urgency=medium . * Fixed problem with detecting of perl dynamically loaded modules. Only directories contained /auto/ are searched for *.so files. * Ignore missing directories when finding perl and python scripts. Files: d8f188369e138247c6f8f0944b89c0f3 523 devel optional yada_0.19.dsc 4b398ebb4c16abe11ab18e32788685ed 126163 devel optional yada_0.19.tar.gz 3504eb504aeb8671b95aeca37e5ab9dc 156922 devel optional yada-doc_0.19_all.deb 4c6d94f92bf15742b68160b4365560f5 35270 devel optional yada_0.19_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QzNehMHHe8CxClsRAiHyAKCnYbGiNu3IbxiBkkukEhWq0YkHIwCeMndM athFz616kxE5YdyE0qFnNsM= =Pyul -END PGP SIGNATURE- Accepted: yada-doc_0.19_all.deb to pool/main/y/yada/yada-doc_0.19_all.deb yada_0.19.dsc to pool/main/y/yada/yada_0.19.dsc yada_0.19.tar.gz to pool/main/y/yada/yada_0.19.tar.gz yada_0.19_all.deb to pool/main/y/yada/yada_0.19_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3mir 1:1.0.10-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 01:31:11 -0700 Source: w3mir Binary: w3mir Architecture: source all Version: 1:1.0.10-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Daniel Schepler [EMAIL PROTECTED] Description: w3mir - w3mir is an all purpose HTTP copying and mirroring tool. Closes: 190618 Changes: w3mir (1:1.0.10-3) unstable; urgency=low . * QA upload. * Add Build-Depends-Indep on debhelper. Closes: #190618. * Move perl modules to /usr/share/perl5. Files: 37b9a627e3325eb8ac7cff51c1c10d7b 580 web optional w3mir_1.0.10-3.dsc dfcc8a11e02f052992131c54da1230c7 11435 web optional w3mir_1.0.10-3.diff.gz 6b157974172c2003b9c764c8ebb3a032 99254 web optional w3mir_1.0.10-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QzQsNC3LAyACFJARAqTcAJ4x2kUSB6otCNItw3gP++esC3jNgwCfV0kX 0nJQeXJWcEzNxhFUCCHuLEI= =ex/c -END PGP SIGNATURE- Accepted: w3mir_1.0.10-3.diff.gz to pool/main/w/w3mir/w3mir_1.0.10-3.diff.gz w3mir_1.0.10-3.dsc to pool/main/w/w3mir/w3mir_1.0.10-3.dsc w3mir_1.0.10-3_all.deb to pool/main/w/w3mir/w3mir_1.0.10-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debootstrap 0.2.4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 10:28:49 +0200 Source: debootstrap Binary: debootstrap-udeb debootstrap Architecture: source i386 Version: 0.2.4 Distribution: unstable Urgency: low Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Description: debootstrap - Bootstrap a basic Debian system debootstrap-udeb - Bootstrap the Debian system (udeb) Closes: 206142 Changes: debootstrap (0.2.4) unstable; urgency=low . * [sid] Added coreutils' new predependencies libacl1 and libattr1. * [debian/README.Debian] Corrected example invocation. (Closes: #206142) * [debian/README.Debian] Fixed a typo. Files: 16ecc4b3ba212ee179866d4fdc864b62 884 admin extra debootstrap_0.2.4.dsc fe6879343973ea28e98ab4757174e779 26422 admin extra debootstrap_0.2.4.tar.gz 92a93494c9b9a9a5376661f5cfcfa5c8 6 debian-installer extra debootstrap-udeb_0.2.4_i386.udeb da371f6fa7554af5d5b8413f9934a890 58544 admin extra debootstrap_0.2.4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQEWAwUBP0M3KQxJU8feGmjHFALPRAP/ZO/zDnRpJoLwxrHsMi4XZJkOJhRfq1uZ SXXyder6bivdgTCRH2XaOZ1XwPIkpjO5Zge974TeqylFRrEc1iRVJLBtiMYiLL2Z r828+IoykVtfwvSNqYnYDR/VHTbPPXTZE1Tw0DGYEEPAEIgF0sa+qUjaGQg/ecyZ DToRb3py9EED+I9i1jXebzqcDuoNNKZmJ2zq7fGB3oSgiaQjLwMYQVIoFYhLpavH ZbnTXBUd8jzmDw8c28NClzwR+vWdao9X6GidMQd2OR8OSGZGa+BppPSJ4mB+aSei Cs5hm351zB5C3lRqj5TlDJyD6upo8ouqNv0YrBwSYom48gqof6zjz7c= =Dqm4 -END PGP SIGNATURE- Accepted: debootstrap-udeb_0.2.4_i386.udeb to pool/main/d/debootstrap/debootstrap-udeb_0.2.4_i386.udeb debootstrap_0.2.4.dsc to pool/main/d/debootstrap/debootstrap_0.2.4.dsc debootstrap_0.2.4.tar.gz to pool/main/d/debootstrap/debootstrap_0.2.4.tar.gz debootstrap_0.2.4_i386.deb to pool/main/d/debootstrap/debootstrap_0.2.4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted freefem 3.5.7-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 10:38:31 +0200 Source: freefem Binary: freefem-doc freefem libfreefem-dev libfreefem-doc libfreefem0 freefem-examples Architecture: source i386 all Version: 3.5.7-2 Distribution: unstable Urgency: low Maintainer: Christophe Prud'homme [EMAIL PROTECTED] Changed-By: Christophe Prud'homme [EMAIL PROTECTED] Description: freefem- A PDE oriented language using Finite Element Method freefem-doc - Documentation for FreeFEM (html and pdf) freefem-examples - Example files for FreeFEM libfreefem-dev - Development library, header files and manpages libfreefem-doc - Documentation for FreeFEM development libfreefem0 - Shared libraries for FreeFEM Closes: 205984 Changes: freefem (3.5.7-2) unstable; urgency=low . * removed automake1.5 dependency thanks to Eric Dorland and Artur R. Czechowski for pointing this out. It was a remnant of an old build system. (closes: #205984) * update Standards-Version to 3.6.0.0 * use dh_install instead of dh_movefile * freefem-examples depends on freefem and there is a link to the example in /usr/share/doc/freefem/examples . Files: ab1cb36709ed14b0f29a39e6c1fd303c 702 math optional freefem_3.5.7-2.dsc 1ceb4c9eb8da2af4a5e0762c3d074811 825763 math optional freefem_3.5.7-2.tar.gz 6c844f7e0ba75a7b8010281bd1d80412 298692 math optional freefem-doc_3.5.7-2_all.deb 5bc82e6043a095a0ef77d0ea25f4ef55 12120 math optional freefem-examples_3.5.7-2_all.deb e1161b50cccb274bf7446fdc992f 42020 math optional libfreefem-doc_3.5.7-2_all.deb cb13ebd67a356166315ba834fdf1c7c8 8854 math optional freefem_3.5.7-2_i386.deb de22cea800d3f572942c88c28992fdef 101856 math optional libfreefem0_3.5.7-2_i386.deb 3b9b69498b20437c3dc6f7812e34b87a 139232 math optional libfreefem-dev_3.5.7-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Qz+CoY+0C9S+FFARAm0uAJwLby2i7UIhQzuAVKNX57K/zQQWVQCfZeiA d8n02nFaRBxy++BOS+sYet0= =y769 -END PGP SIGNATURE- Accepted: freefem-doc_3.5.7-2_all.deb to pool/main/f/freefem/freefem-doc_3.5.7-2_all.deb freefem-examples_3.5.7-2_all.deb to pool/main/f/freefem/freefem-examples_3.5.7-2_all.deb freefem_3.5.7-2.dsc to pool/main/f/freefem/freefem_3.5.7-2.dsc freefem_3.5.7-2.tar.gz to pool/main/f/freefem/freefem_3.5.7-2.tar.gz freefem_3.5.7-2_i386.deb to pool/main/f/freefem/freefem_3.5.7-2_i386.deb libfreefem-dev_3.5.7-2_i386.deb to pool/main/f/freefem/libfreefem-dev_3.5.7-2_i386.deb libfreefem-doc_3.5.7-2_all.deb to pool/main/f/freefem/libfreefem-doc_3.5.7-2_all.deb libfreefem0_3.5.7-2_i386.deb to pool/main/f/freefem/libfreefem0_3.5.7-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ksensors 0.7.2-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 11:24:53 +0200 Source: ksensors Binary: ksensors Architecture: source i386 Version: 0.7.2-8 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: ksensors - lm-sensors frontend for KDE Closes: 204919 Changes: ksensors (0.7.2-8) unstable; urgency=low . * Added nl debconf translation. Thanks to Wessel Dankers. (Closes: bug#204919). * Bumped Standards-Version to 3.6.1. Files: a6b60ba703661253eaa155860994ed01 704 kde optional ksensors_0.7.2-8.dsc 667044ccf78e47da9a9c23bf2bec6e5a 6915 kde optional ksensors_0.7.2-8.diff.gz 212d68c82c970c6ff333457d040f4550 250030 kde optional ksensors_0.7.2-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0GJw3ao2vG823MRAncHAJ9i0kcZXINpPcSwhpES/K8+N9bATgCgj7dh 7syCxBGSqOBIRfKkdFH30QA= =d2Sv -END PGP SIGNATURE- Accepted: ksensors_0.7.2-8.diff.gz to pool/main/k/ksensors/ksensors_0.7.2-8.diff.gz ksensors_0.7.2-8.dsc to pool/main/k/ksensors/ksensors_0.7.2-8.dsc ksensors_0.7.2-8_i386.deb to pool/main/k/ksensors/ksensors_0.7.2-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted popa3d 0.6.3-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 11:30:19 +0200 Source: popa3d Binary: popa3d Architecture: source i386 Version: 0.6.3-3 Distribution: unstable Urgency: low Maintainer: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: popa3d - A tiny POP3 daemon, designed with security as the primary goal Closes: 205165 Changes: popa3d (0.6.3-3) unstable; urgency=low . * Dutch translation of templates file was addes (closes: #205165). Thanks goes to Bart Cornelis [EMAIL PROTECTED]. * debian/control - Standards-Version updated to version 3.6.0.0 Files: b84be5a99c8d5be427cdcac19117db3e 585 mail extra popa3d_0.6.3-3.dsc 96cce97216dbfe3f16c86c5a625cc4fd 7746 mail extra popa3d_0.6.3-3.diff.gz 80d60148fd6221fbbfe0546d80d2a7ff 28572 mail extra popa3d_0.6.3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0EM+NMfSd6w7DERAsKeAJ9ZbCOSN1KoZpsGsUQc3bB0EeaAygCfTt7s e9wXAKpLVLEYPjP/OFc6J5c= =gDAi -END PGP SIGNATURE- Accepted: popa3d_0.6.3-3.diff.gz to pool/main/p/popa3d/popa3d_0.6.3-3.diff.gz popa3d_0.6.3-3.dsc to pool/main/p/popa3d/popa3d_0.6.3-3.dsc popa3d_0.6.3-3_i386.deb to pool/main/p/popa3d/popa3d_0.6.3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted swi-prolog 5.2.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 19 Aug 2003 15:10:19 +0200 Source: swi-prolog Binary: swi-prolog-sgml swi-prolog-table swi-prolog-clib swi-prolog-xpce swi-prolog Architecture: source i386 Version: 5.2.5-1 Distribution: unstable Urgency: low Maintainer: Michael Piefel [EMAIL PROTECTED] Changed-By: Michael Piefel [EMAIL PROTECTED] Description: swi-prolog - Prolog interpreter swi-prolog-clib - Interface to system library for SWI Prolog swi-prolog-sgml - SGML/XML/HTML parser for SWI Prolog swi-prolog-table - Managing external tables for SWI Prolog swi-prolog-xpce - GUI library for SWI Prolog Closes: 186468 187005 Changes: swi-prolog (5.2.5-1) unstable; urgency=low . * New upstream version * Merged the source packages for swi-prolog and swi-prolog-packages together again. The build process upstream uses finally doesn't build-install-build-install anymore. * debian/rules: rearranged for better autotools and DEB_BUILD_OPTIONS * debian/rules: got rid of *.dirs.in ugliness * Remove make call from XPCE postinst (closes: #186468) * Update library index for sgml and clib (closes: #187005) Files: 2493c24d01b34c3a4be4d2b1061e8c93 720 interpreters optional swi-prolog_5.2.5-1.dsc 388311f2382db8908c94c5eb762f26bd 7015970 interpreters optional swi-prolog_5.2.5.orig.tar.gz 97307430b2ba7c5e8377ab9894d09d5e 9680 interpreters optional swi-prolog_5.2.5-1.diff.gz 84b913bf77ee7839c2790b36990c75ec 1062708 interpreters optional swi-prolog_5.2.5-1_i386.deb 412f1011c5f1f6afc9651744b412a1b4 2256264 interpreters optional swi-prolog-xpce_5.2.5-1_i386.deb 5d191b51aa2e3a03928a345ca11a77ef 100124 interpreters optional swi-prolog-sgml_5.2.5-1_i386.deb 46d095897c95c5f48f33a68983845adb 34210 interpreters optional swi-prolog-clib_5.2.5-1_i386.deb 81bf34c98f62880fac7dae0c09fbac44 26740 interpreters optional swi-prolog-table_5.2.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0HSTXj5ne9DlpARAvJpAKCmv4bXXy4hHPYexu6cV4LnbYETGgCgkMqw Sh0p11sSdKbamU5G7r12Cbg= =6OCf -END PGP SIGNATURE- Accepted: swi-prolog-clib_5.2.5-1_i386.deb to pool/main/s/swi-prolog/swi-prolog-clib_5.2.5-1_i386.deb swi-prolog-sgml_5.2.5-1_i386.deb to pool/main/s/swi-prolog/swi-prolog-sgml_5.2.5-1_i386.deb swi-prolog-table_5.2.5-1_i386.deb to pool/main/s/swi-prolog/swi-prolog-table_5.2.5-1_i386.deb swi-prolog-xpce_5.2.5-1_i386.deb to pool/main/s/swi-prolog/swi-prolog-xpce_5.2.5-1_i386.deb swi-prolog_5.2.5-1.diff.gz to pool/main/s/swi-prolog/swi-prolog_5.2.5-1.diff.gz swi-prolog_5.2.5-1.dsc to pool/main/s/swi-prolog/swi-prolog_5.2.5-1.dsc swi-prolog_5.2.5-1_i386.deb to pool/main/s/swi-prolog/swi-prolog_5.2.5-1_i386.deb swi-prolog_5.2.5.orig.tar.gz to pool/main/s/swi-prolog/swi-prolog_5.2.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted icewm 1.2.11-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 19 Aug 2003 21:49:28 +0200 Source: icewm Binary: icewm-gnome icewm icewm-lite icewm-gnome-support icewm-common icewm-experimental Architecture: source i386 Version: 1.2.11-1 Distribution: unstable Urgency: low Maintainer: Jerome Marant [EMAIL PROTECTED] Changed-By: Eduard Bloch [EMAIL PROTECTED] Description: icewm - A wonderful Win95-OS/2-Motif-like window manager icewm-common - A wonderful Win95-OS/2-Motif-like window manager icewm-experimental - A wonderful Win95-OS/2-Motif-like window manager icewm-gnome - A wonderful Win95-OS/2-Motif-like window manager icewm-gnome-support - GNOME support files for IceWM icewm-lite - A wonderful Win95-OS/2-Motif-like window manager Closes: 206189 Changes: icewm (1.2.11-1) unstable; urgency=low . * New upstream release + fixes icewmbg on start invocation, closes: Bug#206189 * Removed po-debconf from Build-Deps Files: a5810a08ff3f67e5bf783d0150df4e75 840 x11 optional icewm_1.2.11-1.dsc 4aeb61b5c28e86edbbb8a8d360785010 836627 x11 optional icewm_1.2.11.orig.tar.gz df557f2127c6a9ee2f4599d030562290 34243 x11 optional icewm_1.2.11-1.diff.gz 3d8b30a69499191042807a29a2519fe0 299710 x11 optional icewm-common_1.2.11-1_i386.deb 369c4beae506875c280bdf49f1ba2ddf 397238 x11 optional icewm_1.2.11-1_i386.deb 2798649a8ce7d77cbd64e6d1fd9ae747 5300 gnome optional icewm-gnome_1.2.11-1_i386.deb 3e3ffc6a5999d25b048b895a13bfbbd6 15464 gnome optional icewm-gnome-support_1.2.11-1_i386.deb 8aac92da937296f1c7ff9771e52bb347 242802 x11 optional icewm-lite_1.2.11-1_i386.deb 30a7ed807052f7af458ce1aee889efca 436034 x11 optional icewm-experimental_1.2.11-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QzpJ4QZIHu3wCMURAhZqAJ0YvAvbc/5eQ+fWsj07yv+hxze7tQCfa04f CVRVzLymQuXj8o9Wv0yef9s= =1M/n -END PGP SIGNATURE- Accepted: icewm-common_1.2.11-1_i386.deb to pool/main/i/icewm/icewm-common_1.2.11-1_i386.deb icewm-experimental_1.2.11-1_i386.deb to pool/main/i/icewm/icewm-experimental_1.2.11-1_i386.deb icewm-gnome-support_1.2.11-1_i386.deb to pool/main/i/icewm/icewm-gnome-support_1.2.11-1_i386.deb icewm-gnome_1.2.11-1_i386.deb to pool/main/i/icewm/icewm-gnome_1.2.11-1_i386.deb icewm-lite_1.2.11-1_i386.deb to pool/main/i/icewm/icewm-lite_1.2.11-1_i386.deb icewm_1.2.11-1.diff.gz to pool/main/i/icewm/icewm_1.2.11-1.diff.gz icewm_1.2.11-1.dsc to pool/main/i/icewm/icewm_1.2.11-1.dsc icewm_1.2.11-1_i386.deb to pool/main/i/icewm/icewm_1.2.11-1_i386.deb icewm_1.2.11.orig.tar.gz to pool/main/i/icewm/icewm_1.2.11.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3m 0.4.1-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 19:15:40 +0900 Source: w3m Binary: w3m w3m-img Architecture: source i386 Version: 0.4.1-6 Distribution: unstable Urgency: low Maintainer: Fumitoshi UKAI [EMAIL PROTECTED] Changed-By: Fumitoshi UKAI [EMAIL PROTECTED] Description: w3m- WWW browsable pager with excellent tables/frames support w3m-img- inline image extension support utilities for w3m Changes: w3m (0.4.1-6) unstable; urgency=low . * rebuild with libgc-dev * build-depends: libgc6-dev = libgc-dev Files: 8a75e799fb3caa0ba7c326672cfd111c 656 text optional w3m_0.4.1-6.dsc dac98ff58c27aaa3eabc64fd316023c6 31800 text optional w3m_0.4.1-6.diff.gz 112d003b1e41a9b02c2937f9a4f26cad 680918 text optional w3m_0.4.1-6_i386.deb 6ea76979acb5fa6cca9e147943f6482f 82346 text optional w3m-img_0.4.1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0uL9D5yZjzIjAkRAiECAJoDqsbaoga4Y4UWimLvE85mmv/i/QCeIKJL Y6AWJsK0mv+CdwNNKLUi/as= =/PE1 -END PGP SIGNATURE- Accepted: w3m-img_0.4.1-6_i386.deb to pool/main/w/w3m/w3m-img_0.4.1-6_i386.deb w3m_0.4.1-6.diff.gz to pool/main/w/w3m/w3m_0.4.1-6.diff.gz w3m_0.4.1-6.dsc to pool/main/w/w3m/w3m_0.4.1-6.dsc w3m_0.4.1-6_i386.deb to pool/main/w/w3m/w3m_0.4.1-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted elk 3.0-16 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 11:34:24 +0200 Source: elk Binary: elkdoc elk Architecture: source i386 all Version: 3.0-16 Distribution: unstable Urgency: low Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: elk- implementation of Scheme (the Extension Language Kit) elkdoc - documentation for the Extension Language Kit Closes: 205645 Changes: elk (3.0-16) unstable; urgency=low . * **/build: Use gcc to link shared objects instead of ld, because gcc does a lot of additional magic. Fixes the __canonicalize_funcptr_for_compare unresolved symbol on HPPA (Closes: #205645). * src/build: Make the build continue if debian/arch-config is not found. * debian/compat: Use this instead of DH_COMPAT. Files: b58d4693d89cc74c1cc17a0e414a585d 626 devel optional elk_3.0-16.dsc 198c44a3f8c40ced456e4eb196f0b0ef 82106 devel optional elk_3.0-16.diff.gz 13f7d70af437b10b554dc6b6ca014091 1043430 doc optional elkdoc_3.0-16_all.deb bd4eed67051bd557e4bc48c811ce294c 1335226 devel optional elk_3.0-16_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0d4fPP1rylJn2ERAr+9AKCtk20weD5vlyeppXmss2/qoRu4OQCfZYvZ QvZU5M9sWS80XssTAMTO91s= =jZEd -END PGP SIGNATURE- Accepted: elk_3.0-16.diff.gz to pool/main/e/elk/elk_3.0-16.diff.gz elk_3.0-16.dsc to pool/main/e/elk/elk_3.0-16.dsc elk_3.0-16_i386.deb to pool/main/e/elk/elk_3.0-16_i386.deb elkdoc_3.0-16_all.deb to pool/main/e/elk/elkdoc_3.0-16_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted w3mmee 0.3.p24.18-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 19:23:22 +0900 Source: w3mmee Binary: w3mmee-img w3mmee Architecture: source i386 Version: 0.3.p24.18-4 Distribution: unstable Urgency: low Maintainer: Fumitoshi UKAI [EMAIL PROTECTED] Changed-By: Fumitoshi UKAI [EMAIL PROTECTED] Description: w3mmee - WWW browsable pager with excellent tables/frames, MB extension w3mmee-img - inline image extension support utilities for w3mmee Changes: w3mmee (0.3.p24.18-4) unstable; urgency=low . * rebuild with libgc-dev * build-depends: libgc6-dev = libgc-dev * main.c w3mbookmark.c w3mhelperpanel.c: no need to include gcmain.c Files: 2f9afa8003a180e48feb884ea08150dc 693 web optional w3mmee_0.3.p24.18-4.dsc bffa7c343b69bf68b134272d4a3e6e36 12375 web optional w3mmee_0.3.p24.18-4.diff.gz fd2639ce0e64626e49f0ac97a5af7901 582912 web optional w3mmee_0.3.p24.18-4_i386.deb 2b2770a89b05738920cc565bb948cecb 72068 web optional w3mmee-img_0.3.p24.18-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q05q9D5yZjzIjAkRAs7eAJ9MO/PBix+LLXvjrYs8oqLNX2pOxACgmcWZ 9ZSyE9G+WTxRmOSSOGBHbMI= =DjYF -END PGP SIGNATURE- Accepted: w3mmee-img_0.3.p24.18-4_i386.deb to pool/main/w/w3mmee/w3mmee-img_0.3.p24.18-4_i386.deb w3mmee_0.3.p24.18-4.diff.gz to pool/main/w/w3mmee/w3mmee_0.3.p24.18-4.diff.gz w3mmee_0.3.p24.18-4.dsc to pool/main/w/w3mmee/w3mmee_0.3.p24.18-4.dsc w3mmee_0.3.p24.18-4_i386.deb to pool/main/w/w3mmee/w3mmee_0.3.p24.18-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted insight 5.3+cvs.2003.08.13-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 19:08:09 +0900 Source: insight Binary: insight Architecture: source i386 Version: 5.3+cvs.2003.08.13-2 Distribution: unstable Urgency: low Maintainer: Masayuki Hatta [EMAIL PROTECTED] Changed-By: Masayuki Hatta [EMAIL PROTECTED] Description: insight- Graphical debugger based on GDB Closes: 206235 Changes: insight (5.3+cvs.2003.08.13-2) unstable; urgency=low . * Added Build-Depends: libncurses-dev - closes: #206235 Files: 7528fa6c6949387b0e444e48288bb2fa 680 devel optional insight_5.3+cvs.2003.08.13-2.dsc e049e72dcfc08763a99eeb2f9d32d439 8508 devel optional insight_5.3+cvs.2003.08.13-2.diff.gz 37c7367306a30aef34680531f74578cb 1858314 devel optional insight_5.3+cvs.2003.08.13-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1OJvA5bJSX0Hx8RAi8eAKCTYH/Pr6yZfuA6Vec3whU3aSlcYACggNqC 04s5m4jvz98aC3Qj5EgYysA= =wIPS -END PGP SIGNATURE- Accepted: insight_5.3+cvs.2003.08.13-2.diff.gz to pool/main/i/insight/insight_5.3+cvs.2003.08.13-2.diff.gz insight_5.3+cvs.2003.08.13-2.dsc to pool/main/i/insight/insight_5.3+cvs.2003.08.13-2.dsc insight_5.3+cvs.2003.08.13-2_i386.deb to pool/main/i/insight/insight_5.3+cvs.2003.08.13-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ksensors 0.7.2-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 12:37:05 +0200 Source: ksensors Binary: ksensors Architecture: source i386 Version: 0.7.2-9 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: ksensors - lm-sensors frontend for KDE Changes: ksensors (0.7.2-9) unstable; urgency=low . * The nl debconf translation is from Bart Cornelis and not Wessel Dankers. Updated the changelog. Sorry Bart. Files: 27397073c6de619d36adf1b4f19605d0 704 kde optional ksensors_0.7.2-9.dsc a409f367d84159b4e7034ffc1d49974e 6979 kde optional ksensors_0.7.2-9.diff.gz 26b2a2d7c2a595978a28b2ed87445f45 250092 kde optional ksensors_0.7.2-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1Juw3ao2vG823MRAlMsAJ92/z1biUURgr/4Yb5eNEyoCSeE9ACdGO8t h+yLFC7SkfuZRMxBS7auFLg= =Va/b -END PGP SIGNATURE- Accepted: ksensors_0.7.2-9.diff.gz to pool/main/k/ksensors/ksensors_0.7.2-9.diff.gz ksensors_0.7.2-9.dsc to pool/main/k/ksensors/ksensors_0.7.2-9.dsc ksensors_0.7.2-9_i386.deb to pool/main/k/ksensors/ksensors_0.7.2-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ident2 1.03-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 10:37:59 +0100 Source: ident2 Binary: ident2 Architecture: source i386 Version: 1.03-7 Distribution: unstable Urgency: low Maintainer: Rob Bradford [EMAIL PROTECTED] Changed-By: Rob Bradford [EMAIL PROTECTED] Description: ident2 - An advanced ident daemon Closes: 206244 206247 Changes: ident2 (1.03-7) unstable; urgency=low . * Modified the postrm's way for dealing with the inetd configuration (Closes: #206244,#206247). Files: c23eb8de9c074b9cf5bdd4c1f63dd940 557 net optional ident2_1.03-7.dsc 152a8779493e3c3f57b0fc1b3534da4e 5157 net optional ident2_1.03-7.diff.gz fb6895e037c1c3cff545b8b2d33f 17386 net optional ident2_1.03-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q00xCw8pKd+B7oMRAtvAAKCBlE8hkF42oOEWQ5wnMWFrP2N9EwCgv5Sw IINNDWK+mn8xl/rbnLwve+A= =9mAx -END PGP SIGNATURE- Accepted: ident2_1.03-7.diff.gz to pool/main/i/ident2/ident2_1.03-7.diff.gz ident2_1.03-7.dsc to pool/main/i/ident2/ident2_1.03-7.dsc ident2_1.03-7_i386.deb to pool/main/i/ident2/ident2_1.03-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libsdl-sge 020904-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 13:15:36 +0200 Source: libsdl-sge Binary: libsdl-sge-dev libsdl-sge Architecture: source i386 Version: 020904-2 Distribution: unstable Urgency: low Maintainer: Julien Danjou [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: libsdl-sge - set of graphic functions that use SDL libsdl-sge-dev - development files for libsdl-sge Changes: libsdl-sge (020904-2) unstable; urgency=low . * Acknowledging NMU, thanks to Sam. This closes #190293, #190294, #190290 * Set policy to 3.6.1.0 Files: cdb42b7c95015c350e9cd021e0a569ff 646 - optional libsdl-sge_020904-2.dsc 4524f4712eef2961ccf17aa347611ed8 3055 - optional libsdl-sge_020904-2.diff.gz be5967cc19667910065f73f590c8c5f0 49828 libs optional libsdl-sge_020904-2_i386.deb 4495034f9e31ad1277a443d9f4978478 55126 libdevel optional libsdl-sge-dev_020904-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1hzpGK1HsL+5c0RAn5dAKCTjKijJPj7YQc27kC+7rQ38EegoACeMQkN U5BbuwKdG9Gi8ZnerzbxhAw= =W//p -END PGP SIGNATURE- Accepted: libsdl-sge-dev_020904-2_i386.deb to pool/main/libs/libsdl-sge/libsdl-sge-dev_020904-2_i386.deb libsdl-sge_020904-2.diff.gz to pool/main/libs/libsdl-sge/libsdl-sge_020904-2.diff.gz libsdl-sge_020904-2.dsc to pool/main/libs/libsdl-sge/libsdl-sge_020904-2.dsc libsdl-sge_020904-2_i386.deb to pool/main/libs/libsdl-sge/libsdl-sge_020904-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted texfam 1.2.1-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 7 May 2003 13:07:39 +0900
Source: texfam
Binary: multex-bin jlatex209-bin jtex-bin
Architecture: source i386 all
Version: 1.2.1-4
Distribution: unstable
Urgency: low
Maintainer: TSUCHIYA Masatoshi [EMAIL PROTECTED]
Changed-By: TSUCHIYA Masatoshi [EMAIL PROTECTED]
Description:
jlatex209-bin - NTT Japanese LaTeX 2.09 command and configuration files
jtex-bin - NTT Japanese TeX binary files
multex-bin - Multilingual TeX binary files
Closes: 191019
Changes:
texfam (1.2.1-4) unstable; urgency=low
.
* debian/jlatex209-bin.{postinst,postrm,prerm}: New files. (closes: #191019)
Files:
bf86dd4798cb7fc6bb2e124b276bc35c 635 tex optional texfam_1.2.1-4.dsc
d046b73cc980f436d9650af1323572cf 19847 tex optional texfam_1.2.1-4.diff.gz
5fd2fda24e9980311578e5ca18e34c88 5148 tex optional jlatex209-bin_1.9.1-4_all.deb
722b17c58130d0b1dfba9e1635508fd4 149414 tex optional jtex-bin_1.9.1-4_i386.deb
04498b95f9f6d23b8ffdabb5bb9731dd 147864 tex optional multex-bin_0.8.1-4_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/Q1muvA5bJSX0Hx8RAudkAJ9caT/5LdUlnAWvkHExLtK2fMjFPQCfWYOs
LwrjKh892wwXv04fBzPBu90=
=0Hzb
-END PGP SIGNATURE-
Accepted:
jlatex209-bin_1.9.1-4_all.deb
to pool/main/t/texfam/jlatex209-bin_1.9.1-4_all.deb
jtex-bin_1.9.1-4_i386.deb
to pool/main/t/texfam/jtex-bin_1.9.1-4_i386.deb
multex-bin_0.8.1-4_i386.deb
to pool/main/t/texfam/multex-bin_0.8.1-4_i386.deb
texfam_1.2.1-4.diff.gz
to pool/main/t/texfam/texfam_1.2.1-4.diff.gz
texfam_1.2.1-4.dsc
to pool/main/t/texfam/texfam_1.2.1-4.dsc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ledstats 0.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 13:28:39 +0200 Source: ledstats Binary: ledstats Architecture: source i386 Version: 0.3-1 Distribution: unstable Urgency: low Maintainer: Julien Danjou [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: ledstats - Show CPU usage on a LED device plugged on parallel port Changes: ledstats (0.3-1) unstable; urgency=low . * NMU ack * New upstream release * No more deps on a dev package ! * Bump Standards-Version to 3.6.1.0 * Include documentation about device (Closes, #186913) Files: c5b229c53e49e3ca89af9a465e96f0da 587 utils optional ledstats_0.3-1.dsc 3d59e5e69f2ca132d4ff1b16389a8875 22794 utils optional ledstats_0.3.orig.tar.gz a1750daa57589ad7e1fc66821e2b049a 2724 utils optional ledstats_0.3-1.diff.gz 3e633a0cabc92bd5e40c29304a10b4b3 5576 utils optional ledstats_0.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q12UpGK1HsL+5c0RAoSkAKCxxOQnTgfPzILZqKNJOIf25RWuEQCeLzAv D37BfEDQAt/s7Y7ZrlYaqfY= =68Zh -END PGP SIGNATURE- Accepted: ledstats_0.3-1.diff.gz to pool/main/l/ledstats/ledstats_0.3-1.diff.gz ledstats_0.3-1.dsc to pool/main/l/ledstats/ledstats_0.3-1.dsc ledstats_0.3-1_i386.deb to pool/main/l/ledstats/ledstats_0.3-1_i386.deb ledstats_0.3.orig.tar.gz to pool/main/l/ledstats/ledstats_0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted inn 1:1.7.2debian-23 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 04:46:14 +0200 Source: inn Binary: inn-dev inewsinn inn Architecture: source i386 Version: 1:1.7.2debian-23 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri [EMAIL PROTECTED] Changed-By: Marco d'Itri [EMAIL PROTECTED] Description: inewsinn - NNTP client news injector, from InterNetNews (INN) inn- News transport system `InterNetNews' by the ISC and Rich Salz inn-dev- The libinn.a library and manpages Closes: 54975 Changes: inn (1:1.7.2debian-23) unstable; urgency=medium . * Fixed the bug introduced in 1:1.7.2-14 by the path_audit patch which caused random segfaults when hosts.nntp was reloaded. * Fixed the innreport path in scanlogs. * Added support for a inewsport config file option. (Closes: #54975) * Remove /etc/news/crontab and add /etc/cron.d/inn. * Updated the default control.ctl from ftp.isc.org. Files: e5782bb5697bccd1a1b44747adb80fa5 625 news extra inn_1.7.2debian-23.dsc 5114e6d4f0df7a956a7d16283f7b1c2b 175396 news extra inn_1.7.2debian-23.diff.gz 641ef11cce44cfbec08c89009ddfbece 751214 news extra inn_1.7.2debian-23_i386.deb 15e0345c92431e262009b5474e93a87f 36416 news extra inewsinn_1.7.2debian-23_i386.deb 7861ce6bc16eb8c48421b1030d898557 58474 news extra inn-dev_1.7.2debian-23_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QuoPFGfw2OHuP7ERAnC2AJ9P/usFaM8Ez3p5gov9gmbKJMIkaACdE4it BifJrH8oX4dOlMm3DWeup38= =3HCR -END PGP SIGNATURE- Accepted: inewsinn_1.7.2debian-23_i386.deb to pool/main/i/inn/inewsinn_1.7.2debian-23_i386.deb inn-dev_1.7.2debian-23_i386.deb to pool/main/i/inn/inn-dev_1.7.2debian-23_i386.deb inn_1.7.2debian-23.diff.gz to pool/main/i/inn/inn_1.7.2debian-23.diff.gz inn_1.7.2debian-23.dsc to pool/main/i/inn/inn_1.7.2debian-23.dsc inn_1.7.2debian-23_i386.deb to pool/main/i/inn/inn_1.7.2debian-23_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-dns 2.3.0-5 (all source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 20 Aug 2003 14:25:29 +0200
Source: python-dns
Binary: python-dns
Architecture: source all
Version: 2.3.0-5
Distribution: unstable
Urgency: low
Maintainer: Joerg Wendland [EMAIL PROTECTED]
Changed-By: Joerg Wendland [EMAIL PROTECTED]
Description:
python-dns - pydns - DNS client module for Python
Closes: 205884
Changes:
python-dns (2.3.0-5) unstable; urgency=low
.
* debian/control:
Use ${python:Depends} for Depends, so that correct Depends are
generated by dh_python. (closes: Bug#205884)
* debian/python-dns.postinst
debian/python-dns.prerm:
Remove these files and let debhelper handle these issues.
Files:
fc9e044a5f09b1f05cee5ab0dc206829 598 python optional python-dns_2.3.0-5.dsc
dd2613a53c37e2b83b63c342ce3b4c3e 1543 python optional python-dns_2.3.0-5.diff.gz
f23e10a69930006cce5d9f83070607f3 21970 python optional python-dns_2.3.0-5_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/Q2l8V6N/vVHPhBcRAoQqAJ9goZZyNkni6t4C84aAuvGq+psbBQCdHDVq
QOAtyjpxGciB9RaJ9uNMXn8=
=o8zg
-END PGP SIGNATURE-
Accepted:
python-dns_2.3.0-5.diff.gz
to pool/main/p/python-dns/python-dns_2.3.0-5.diff.gz
python-dns_2.3.0-5.dsc
to pool/main/p/python-dns/python-dns_2.3.0-5.dsc
python-dns_2.3.0-5_all.deb
to pool/main/p/python-dns/python-dns_2.3.0-5_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmusicbrainz-2.0 2.0.2-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 13 Aug 2003 18:20:33 +0200
Source: libmusicbrainz-2.0
Binary: python2.3-musicbrainz python2.1-musicbrainz libmusicbrainz2
libmusicbrainz2-dev python2.2-musicbrainz
Architecture: source i386
Version: 2.0.2-2
Distribution: unstable
Urgency: low
Maintainer: Andreas Rottmann [EMAIL PROTECTED]
Changed-By: Andreas Rottmann [EMAIL PROTECTED]
Description:
libmusicbrainz2 - Second generation incarnation of the CD Index - library
libmusicbrainz2-dev - Second generation incarnation of the CD Index - development
python2.1-musicbrainz - Second generation incarnation of the CD Index - library
python2.2-musicbrainz - Second generation incarnation of the CD Index - library
python2.3-musicbrainz - Second generation incarnation of the CD Index - library
Closes: 205227
Changes:
libmusicbrainz-2.0 (2.0.2-2) unstable; urgency=low
.
* Added missing build-dependency on python2.{1,2,3}-dev (closes: #205227).
Files:
f8380c2a7a5e4ac5cc8ae3445bac8a0d 756 libs optional libmusicbrainz-2.0_2.0.2-2.dsc
a07cc5f5f66a2153310b5cae584f9094 6466 libs optional libmusicbrainz-2.0_2.0.2-2.diff.gz
e57f62ef014f337cf3df0c7860ce3ccc 129076 libdevel optional
libmusicbrainz2-dev_2.0.2-2_i386.deb
f29f91b37be5f57c1598c3d6e89bd9a0 102724 libs optional libmusicbrainz2_2.0.2-2_i386.deb
60eed6043352cd0034b1819f35b5b73b 20566 libs optional
python2.1-musicbrainz_2.0.2-2_i386.deb
8bda8d810d946c32924afef7d0d02611 20786 python optional
python2.2-musicbrainz_2.0.2-2_i386.deb
262bbcb81062767021a68efdad82768b 13666 python optional
python2.3-musicbrainz_2.0.2-2_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/OnK/+S/PxQH9W2IRAtmIAJ9uWZIKxgF5pUCc6Vnh26/d5biXrgCgi6Ph
pXY1PVbKtUzYq1przoUbMRw=
=BowC
-END PGP SIGNATURE-
Accepted:
libmusicbrainz-2.0_2.0.2-2.diff.gz
to pool/main/libm/libmusicbrainz-2.0/libmusicbrainz-2.0_2.0.2-2.diff.gz
libmusicbrainz-2.0_2.0.2-2.dsc
to pool/main/libm/libmusicbrainz-2.0/libmusicbrainz-2.0_2.0.2-2.dsc
libmusicbrainz2-dev_2.0.2-2_i386.deb
to pool/main/libm/libmusicbrainz-2.0/libmusicbrainz2-dev_2.0.2-2_i386.deb
libmusicbrainz2_2.0.2-2_i386.deb
to pool/main/libm/libmusicbrainz-2.0/libmusicbrainz2_2.0.2-2_i386.deb
python2.1-musicbrainz_2.0.2-2_i386.deb
to pool/main/libm/libmusicbrainz-2.0/python2.1-musicbrainz_2.0.2-2_i386.deb
python2.2-musicbrainz_2.0.2-2_i386.deb
to pool/main/libm/libmusicbrainz-2.0/python2.2-musicbrainz_2.0.2-2_i386.deb
python2.3-musicbrainz_2.0.2-2_i386.deb
to pool/main/libm/libmusicbrainz-2.0/python2.3-musicbrainz_2.0.2-2_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vtk 4.2.2-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 04:48:06 + Source: vtk Binary: python-vtk vtk-tcl vtk-doc libvtk4-dev libvtk4 vtk-examples Architecture: source i386 all Version: 4.2.2-1 Distribution: unstable Urgency: low Maintainer: A. Maitland Bottoms [EMAIL PROTECTED] Changed-By: A. Maitland Bottoms [EMAIL PROTECTED] Description: libvtk4- Visualization Toolkit - A high level 3D visualization library libvtk4-dev - VTK header files for building C++ code python-vtk - Python bindings for VTK vtk-doc- VTK class reference documentation vtk-examples - C++, Tcl and Python example programs/scripts for VTK vtk-tcl- Tcl bindings for VTK Changes: vtk (4.2.2-1) unstable; urgency=low . * New upstream release * use soname fix_linkage from Gavin Baker [EMAIL PROTECTED] * build wiith python2.3 Files: 2b3eda2a0e81b35c2592864cc26e758e 847 graphics optional vtk_4.2.2-1.dsc 8a2355ccdcfcc3b994346dd67212e39a 6179447 graphics optional vtk_4.2.2.orig.tar.gz c1245f406b87b9903ccbd4b97d620b12 43851 graphics optional vtk_4.2.2-1.diff.gz c7df1eaa9eefe0dda959d712510d1a20 24179484 doc optional vtk-doc_4.2.2-1_all.deb 7a041ef918f0366c42257a454f52589f 322306 graphics optional vtk-examples_4.2.2-1_all.deb 94ef566ad24067f6bd5f04f8cb2483fc 703622 devel optional libvtk4-dev_4.2.2-1_all.deb 44a583b7fb7ff75599eecb6c5c16cd30 4583404 libs optional libvtk4_4.2.2-1_i386.deb 69d8de0ffe9c8d4d66a5580e603df8dd 921378 interpreters optional vtk-tcl_4.2.2-1_i386.deb 07edfe1f62efd6584c9d514b28e241e4 2062502 graphics optional python-vtk_4.2.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1R2kwbJvNrxBUwRAjqvAJ47WDFXzQM7gy/FF16534lOKW4HFACeLFDA 0IHHFRNU4dz6ncTj/mdYkV8= =9T+9 -END PGP SIGNATURE- Accepted: libvtk4-dev_4.2.2-1_all.deb to pool/main/v/vtk/libvtk4-dev_4.2.2-1_all.deb libvtk4_4.2.2-1_i386.deb to pool/main/v/vtk/libvtk4_4.2.2-1_i386.deb python-vtk_4.2.2-1_i386.deb to pool/main/v/vtk/python-vtk_4.2.2-1_i386.deb vtk-doc_4.2.2-1_all.deb to pool/main/v/vtk/vtk-doc_4.2.2-1_all.deb vtk-examples_4.2.2-1_all.deb to pool/main/v/vtk/vtk-examples_4.2.2-1_all.deb vtk-tcl_4.2.2-1_i386.deb to pool/main/v/vtk/vtk-tcl_4.2.2-1_i386.deb vtk_4.2.2-1.diff.gz to pool/main/v/vtk/vtk_4.2.2-1.diff.gz vtk_4.2.2-1.dsc to pool/main/v/vtk/vtk_4.2.2-1.dsc vtk_4.2.2.orig.tar.gz to pool/main/v/vtk/vtk_4.2.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apt-build 0.8.6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 13:50:09 +0200 Source: apt-build Binary: apt-build Architecture: source all Version: 0.8.6 Distribution: unstable Urgency: low Maintainer: Julien Danjou [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: apt-build - Frontend to apt to build, optimize and install packages Closes: 201987 203935 Changes: apt-build (0.8.6) unstable; urgency=low . * Fix a postinst bug with zcat on new install * Include patch from Yindong Yu, it should closes: #201987, #203935 Files: 8003e60d32d35397f4553780d9cf3579 500 devel optional apt-build_0.8.6.dsc eaa5e4f745558262860494adb0ac5c16 18828 devel optional apt-build_0.8.6.tar.gz 5105442f230cb4b7405c05459b652aac 17514 devel optional apt-build_0.8.6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q2D/pGK1HsL+5c0RApcRAJ4otTo4alXQAExHZtNWtQGVKIHJYwCdEvoO q/fIa6HvjLQLPd+6+5vX7cg= =OmSL -END PGP SIGNATURE- Accepted: apt-build_0.8.6.dsc to pool/main/a/apt-build/apt-build_0.8.6.dsc apt-build_0.8.6.tar.gz to pool/main/a/apt-build/apt-build_0.8.6.tar.gz apt-build_0.8.6_all.deb to pool/main/a/apt-build/apt-build_0.8.6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pointless 0.4-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 11:14:53 +0200 Source: pointless Binary: pointless Architecture: source i386 Version: 0.4-2 Distribution: unstable Urgency: low Maintainer: Marco Presi (Zufus) [EMAIL PROTECTED] Changed-By: Marco Presi (Zufus) [EMAIL PROTECTED] Description: pointless - A presentation tool based on OpenGL Changes: pointless (0.4-2) unstable; urgency=low . * Simlinked /usr/share/pointless/pointlessrc to /etc/pointlessrc. Files: b31b56f1e01acb113fc5132a0f3cf536 682 misc optional pointless_0.4-2.dsc e52f42882fa07ac22193f60241d6327f 1001362 misc optional pointless_0.4-2.tar.gz fbc77ef693234b8c04d838ac21bca82c 487696 misc optional pointless_0.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q2FLh0XdeHWCwhoRAovSAJ428cnpB5nGaYRVwaPBKJgW/dHpVwCePuR+ s08b877NOVkFszLBK8CYLkw= =OK9T -END PGP SIGNATURE- Accepted: pointless_0.4-2.dsc to pool/main/p/pointless/pointless_0.4-2.dsc pointless_0.4-2.tar.gz to pool/main/p/pointless/pointless_0.4-2.tar.gz pointless_0.4-2_i386.deb to pool/main/p/pointless/pointless_0.4-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sane-backends 1.0.12-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 14:03:14 +0200 Source: sane-backends Binary: libsane-dev sane-utils libsane Architecture: source i386 Version: 1.0.12-7 Distribution: unstable Urgency: low Maintainer: Julien BLACHE [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: libsane- API library for scanners libsane-dev - API development library for scanners [development files] sane-utils - API library for scanners -- utilities Closes: 205291 Changes: sane-backends (1.0.12-7) unstable; urgency=low . * The Maintainer's birthday release. * Simplified the needlessly complex debconf questions. Now use a multiselect question instead of 3 independent questions. + debian/libsane.templates: rewritten to use a multiselect type + debian/libsane.config: ditto, try to convert from the older questions, then purge them once done. + debian/libsane.postinst: rewritten to parse the answer from the new debconf thingy. + debian/control: now Depends: debconf (= 0.5.0) due to the use of db_fset in debian/libsane.config. * debian/libsane.postinst: use ':' as a separator for chown instead of '.'. * debian/libsane.README.Debian: ditto. * debian/control: only Suggests: hotplug (closes: #205291). Files: 5487c73e505c6bd398d3d833e4de7995 833 graphics optional sane-backends_1.0.12-7.dsc 16cce6dfc641aa45c62b3847ce5926b9 88857 graphics optional sane-backends_1.0.12-7.diff.gz 2fd3755e6fe5babdb88488b61def86fc 92330 graphics optional sane-utils_1.0.12-7_i386.deb 3918d2f3c23b3d470e95adbce676cc79 2139584 libs optional libsane_1.0.12-7_i386.deb 7c402cb1750776ebec8ea50483ff6af3 1791016 libdevel optional libsane-dev_1.0.12-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q2V6zWFP1/XWUWkRArk1AJ0XFJWBUVwfEJW0mJ2w1jsPtquh6gCfQEbl 6UPYxYuQGpJJXoTaNZeZkMc= =6LCW -END PGP SIGNATURE- Accepted: libsane-dev_1.0.12-7_i386.deb to pool/main/s/sane-backends/libsane-dev_1.0.12-7_i386.deb libsane_1.0.12-7_i386.deb to pool/main/s/sane-backends/libsane_1.0.12-7_i386.deb sane-backends_1.0.12-7.diff.gz to pool/main/s/sane-backends/sane-backends_1.0.12-7.diff.gz sane-backends_1.0.12-7.dsc to pool/main/s/sane-backends/sane-backends_1.0.12-7.dsc sane-utils_1.0.12-7_i386.deb to pool/main/s/sane-backends/sane-utils_1.0.12-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted snack 2.2.2-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 18 Aug 2003 21:03:01 +0200 Source: snack Binary: libsnack2-doc libsnack2-dev libsnack2 Architecture: source all i386 Version: 2.2.2-2 Distribution: unstable Urgency: low Maintainer: David A. van Leeuwen [EMAIL PROTECTED] Changed-By: David A. van Leeuwen [EMAIL PROTECTED] Description: libsnack2 - Sound functionality extension to the Tcl/Tk language libsnack2-dev - Snack development files libsnack2-doc - Snack documentation Closes: 134397 144488 196635 Changes: snack (2.2.2-2) unstable; urgency=low . * added a million of -a and -i's in debian/rules. Sorry, but i find the mixed architecture dependen/indenpendent rules files not elegant. (closes: #196635) * 2.1.6-1 closed a lot of minor issues. (closes: #144488) * Repeated short description in control file in -dev and -doc packages. (closes: #134397) Files: 96b5cfb6c9ab2f64cc3e70d63de37dc1 614 sound optional snack_2.2.2-2.dsc b5761ca8c8ff53946db36911c589203e 1187329 sound optional snack_2.2.2-2.tar.gz daa0a84c1febd9e7cd99d70a0c2ee7cd 338868 libs optional libsnack2_2.2.2-2_i386.deb 7de1fc3f4521f0f7bdddb4fb53915116 18754 devel optional libsnack2-dev_2.2.2-2_all.deb 94318da23d73dee7ccb5aaaedecfedfa 216150 doc optional libsnack2-doc_2.2.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/Q2qQJrPWgQLzcTwRAjDJAKD2THpCZFYWlVSQZskBBE3kMbBpCwCfY1Uy q2aEysoDRrvD6VQFlytutw4= =SPMH -END PGP SIGNATURE- Accepted: libsnack2-dev_2.2.2-2_all.deb to pool/main/s/snack/libsnack2-dev_2.2.2-2_all.deb libsnack2-doc_2.2.2-2_all.deb to pool/main/s/snack/libsnack2-doc_2.2.2-2_all.deb libsnack2_2.2.2-2_i386.deb to pool/main/s/snack/libsnack2_2.2.2-2_i386.deb snack_2.2.2-2.dsc to pool/main/s/snack/snack_2.2.2-2.dsc snack_2.2.2-2.tar.gz to pool/main/s/snack/snack_2.2.2-2.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ots 0.3.0+cvs.2003.07.27-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 21:49:05 +0900 Source: ots Binary: libots-dev libots0 Architecture: source i386 Version: 0.3.0+cvs.2003.07.27-2 Distribution: unstable Urgency: low Maintainer: Masayuki Hatta [EMAIL PROTECTED] Changed-By: Masayuki Hatta [EMAIL PROTECTED] Description: libots-dev - Open Text Summarizer (development) libots0- Open Text Summarizer (library) Closes: 203772 Changes: ots (0.3.0+cvs.2003.07.27-2) unstable; urgency=low . * Added Build-Depends: libpopt-dev - closes: #203772 Files: e73d24d59584cb5372e340983af5ec3e 637 devel optional ots_0.3.0+cvs.2003.07.27-2.dsc f26aa65673e88ea81c6af44812910263 2491 devel optional ots_0.3.0+cvs.2003.07.27-2.diff.gz 32866d3bb1cd93a2bc4ee2f58da5f768 17634 libdevel optional libots-dev_0.3.0+cvs.2003.07.27-2_i386.deb 0e092b1b96ec9d47230f32e7bc8bde61 33014 libs optional libots0_0.3.0+cvs.2003.07.27-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q27GvA5bJSX0Hx8RAvcrAJ422E4VIvfxDn5id2o6TatLOeNHJACfSTVi L7kkefq/se+wziwvU4ss4GU= =JoDi -END PGP SIGNATURE- Accepted: libots-dev_0.3.0+cvs.2003.07.27-2_i386.deb to pool/main/o/ots/libots-dev_0.3.0+cvs.2003.07.27-2_i386.deb libots0_0.3.0+cvs.2003.07.27-2_i386.deb to pool/main/o/ots/libots0_0.3.0+cvs.2003.07.27-2_i386.deb ots_0.3.0+cvs.2003.07.27-2.diff.gz to pool/main/o/ots/ots_0.3.0+cvs.2003.07.27-2.diff.gz ots_0.3.0+cvs.2003.07.27-2.dsc to pool/main/o/ots/ots_0.3.0+cvs.2003.07.27-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sapphire 0.15.8-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 13:19:34 +0100 Source: sapphire Binary: sapphire Architecture: source i386 Version: 0.15.8-3 Distribution: unstable Urgency: low Maintainer: Chris Boyle [EMAIL PROTECTED] Changed-By: Chris Boyle [EMAIL PROTECTED] Description: sapphire - A minimal but configurable X11R6 window manager Closes: 182430 Changes: sapphire (0.15.8-3) unstable; urgency=low . * Finished upstream's incomplete support for switching window managers, added a new wmexec menu item type, changed menu-method to use it instead of my half-assed kludge using skill sapphire. (closes: #182430) * Corrected version string in windowmanager.cc:30. Files: 259a560089629c7fec0d10bb3f72d884 590 x11 optional sapphire_0.15.8-3.dsc 39f5cbf0355b8a8f2382dbe4d042380d 27468 x11 optional sapphire_0.15.8-3.diff.gz 0b566d3116cfce7577c6434899662762 56064 x11 optional sapphire_0.15.8-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q2jtRi6ArLfYbg8RAkEkAKDRc3u4x+xn1/mDoyEOfIYRRbzOBwCfSg0d E8qiZQS89p+km/m+glLLiHQ= =+7ip -END PGP SIGNATURE- Accepted: sapphire_0.15.8-3.diff.gz to pool/main/s/sapphire/sapphire_0.15.8-3.diff.gz sapphire_0.15.8-3.dsc to pool/main/s/sapphire/sapphire_0.15.8-3.dsc sapphire_0.15.8-3_i386.deb to pool/main/s/sapphire/sapphire_0.15.8-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
