Re: Re Créer le .changes à partir des autres fichiers
Le dimanche 19 février 2006 à 20:31 +0100, Raphael Hertzog a écrit : Y a t il un procédé pour re-générer le .changes ? C'est dpkg-genchanges qui le génère. Mais cela risque de ne pas marcher, en effet le programme s'attend à avoir un paquet source décompacté et compilé. Mais tu peux essayer de: 1/ décompresser avec dpkg-source -x 2/ recréer le fichier debian/files qui est censé lister les paquets binaires générés (cf man dpkg-distaddfile). Le format du fichier est fichier.deb section priorite (un paquet par ligne). 3/ Ensuite lancer dpkg-genchanges. (Le plus simple est quand même de recompiler le paquet :-)) Je vais essayer pour voir, c'est clair que pour manpages la recompilation est envisageable, mais pour xfree ou tout gnome ça me tente pas trop trop en ce moment (pas trop de temps machine à dispo). Merci encore, Éric -- Éric Seigne - Directeur| [EMAIL PROTECTED] RyXéo SARL | http://www.ryxeo.com Le Topaze - Entrée C, 2 rue Jean Bonnardel | tel +33 6 987 444 01 33140 Villenave d'Ornon - FRANCE | fax +33 5 567 542 59 signature.asc Description: Ceci est une partie de message numériquement signée
Re: Problems found by piuparts
I added a Cc to Manoj since I would like to hear his comment. Whoever responds may want to remove the Cc to avoid stuffing his inbox unnecessarily. su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti: On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: * Use of ucf in postrm during a purge, without checking that ucf is installed. Since ucf is not an essential package, postrm during purge cannot rely on it. As it happens, I think it might be good to have ucf (or a subset of it) as an essential package, since this error happens a lot. So assuming that we're stuck with the current implementation for a bit where ucf is not part of essential, I do wonder if checking whether ucf is installed is actually the correct thing to do in postrm purge. The state prior to purge is defined as config files; the difference between config files state and purged is whether there are still config files left on the system. If the package can't actually succeed in removing its config files because ucf is not installed, isn't it *correct* for the postrm purge command to fail? I.e., I think it's more of a bug to allow dpkg to put the package into purged state leaving orphaned config files behind than it is for postrm purge to fail and leave the package in config files state. Hm. I don't use ucf on my own packages (yet), so my understanding is a bit hazy, but if I have understood correctly, the actual config file is removed with rm anyway, and ucf is needed on purge only to remove the config file also from ucf's history data. Thus, only running ucf if it's there should be the right thing. Manoj, could you comment on this? -- Yet another password: just say no. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Lars Wirzenius [EMAIL PROTECTED] wrote: Hm. I don't use ucf on my own packages (yet), so my understanding is a bit hazy, but if I have understood correctly, the actual config file is removed with rm anyway, and ucf is needed on purge only to remove the config file also from ucf's history data. Thus, only running ucf if it's there should be the right thing. Yes, one has to care about manual removing, anyway, and if ucf is already removed or purged, its database is already gone, so there's no point in calling it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: ATT Korn Shell
On Sat, 2006-02-18 at 14:19 +0100, Josh Hurst wrote: Does the Debian ksh93 package include libast and libshell? No - dpkg -L ksh /. /bin /bin/ksh93 /usr /usr/bin /usr/bin/shcomp /usr/share /usr/share/man /usr/share/man/man1 /usr/share/man/man1/ksh93.1.gz /usr/share/man/man1/shcomp.1.gz /usr/share/man/fr /usr/share/man/fr/man1 /usr/share/man/fr/man1/shcomp.1.gz /usr/share/ksh /usr/share/ksh/functions /usr/share/ksh/functions/dirs /usr/share/ksh/functions/popd /usr/share/ksh/functions/pushd /usr/share/doc /usr/share/doc/ksh /usr/share/doc/ksh/OBSOLETE /usr/share/doc/ksh/example.kshrc /usr/share/doc/ksh/copyright /usr/share/doc/ksh/COMPATIBILITY.gz /usr/share/doc/ksh/RELEASE.gz /usr/share/doc/ksh/RELEASE88.gz /usr/share/doc/ksh/RELEASE93.gz /usr/share/doc/ksh/PROMO.mm.gz /usr/share/doc/ksh/changelog.Debian.gz /usr/share/menu /usr/share/menu/ksh signature.asc Description: This is a digitally signed message part
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Kevin Mark] if a piece of software was initially created to enable the use of non-dfsg software with a dfsg system it is classified as 'ícontri', but then someone creates dfsg-software to use this software, now its classified as 'main'. Would this follow? You're trying to sneak in an unspoken premise: namely, that there is reason to believe ndiswrapper would ever be used with a free driver. I claim that this is ridiculous. As far as I've ever heard, free Linux drivers get written much faster than free Windows drivers. If, as I claim, it's exceedingly unlikely that ndiswrapper would ever be used to run free software, it is pure pedantry to say but, but, but, you *could* use it for that. But it also seems that the dfsg-use is not an absolute condition, it has to be deem non-toy and useful which is not an easily agreed upon idea. You seem to be arguing that the Social Contract doesn't say that our software must be of any use. What you're forgetting is that it also doesn't say we *should* ship useless things. Common sense would seem to indicate that we not do so. I don't see a meaningful distinction between non-functional without non-free software and pointless without non-free software. Either way, that's the primary reason we have contrib. signature.asc Description: Digital signature
Re: TrueType fonts packages maintenance team proposal
On Mon, Feb 20, 2006, Christian Perrier wrote: ttf-arabeyes - Arabeyes GPL TrueType Arabic fonts ttf-kacst - KACST free TrueType Arabic fonts ttf-paktype - PakType free OpenType Urdu fonts I am maintaining those three, and would really be happy to know what are the other maintainers best practices in maintaining fonts. As I am not a big font expert too, such a team will be a way to learn a lot. To sum up, count me in! -- adn Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. I can't think of any free NDIS driver, but if such thing exists, NDIS-wrapper should be allowed in main without any problem. [..] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Peter Samuelson] There's a big difference between enabling someone to install non-free software, and enabling someone to view data. (Some of which is free, some not.) Also, in case this was your point, swf content is sometimes generated with free tools such as ploticus. [Michael Poole] What is the difference? I thought GR 2004-003 was all about recognizing software as software, whether some people call it documentation or programs. I suggest you reread GR 2004-003, if you believe it was about defining the term software. It was actually more to the tune of We'll stop using the term 'software' in certain places because it's ambiguous: not everyone interprets it to mean the same thing. If you were confused by my use of the term software to mean executable code, I apologise; I'll try to be more precise in the future. I thought it was clear enough from context, but perhaps it wasn't. Anyway, that's a minor point; the important distinction here is not really whether something is programs or data. You might be familiar with the Doom video game, of which various implementations and forks exist in Debian. Until a free Doom wad file (the game data) was created, the various Doom engines lived in 'contrib', because they were useless without non-free data. Nowadays, free data exists, so the Doom programs are in main. Of all the data viewer programs I can think of in Debian main, there is ample reason to believe there exists content out there for each which is either (a) free (and not useless), and/or (b) created by a Debian user who would want to use Debian to view it. I find it extremely unlikely that the analogous situation is true of ndiswrapper. SWF may be generated with free tools, but under a strict reading of Policy, that is insufficient to qualify for main. OK so I don't understand why you brought up a SWF viewer as an example. I thought it was because the content is generated with non-free tools like Macromedia Flash. Apparently that's not it, since we are agreed that this is not always so. So how else does SWF differ from, say, HTML? What point were you trying to make about libflash? Again, there is no mention of pointless software in Policy -- if there were, some large fraction of main would be moved because it is duplicative, trivial or otherwise pointless to have. No document I'm aware of requires that we ship all free software whether or not it is useful. As it happens, I've always been opposed to pointless software in Debian. It's hard, however, to get it kicked out, because nobody wants to make the judgment call (the maintainer obviously thinks the package has a use, even if nobody else does). I'm sorry if you thought Debian was committed to shipping software with no regard to whether it is useful; this has never been true, although considering some of the fringe packages in the archive, I guess I can see why you might get that impression. But I'm sure you can see that Policy doesn't say we can't is not equivalent to Policy backs up my argument that we should. Likewise, there is no mention of Windows driver developers ... who really wish they could conveniently test their Windows drivers on Debian. Without those developers, and without non-free software, I contend that ndiswrapper is useless. And see above for what I think of *that*. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
[Eduard Bloch] I cannot remember a GR which says exactly this. Neither a GR which would clarify our definition of firmware. And the one I follow is that it is more hardware than a software component. Good. If firmware is hardware rather than software, there is nothing to discuss. Debian doesn't distribute hardware. (And since we don't distribute it, there's no reason to argue about whether it's free or not.) If you think Debian should *distribute* firmware, that's pretty much an admission that it is not hardware. I guess you mean that Editorial changes farce where the majority of the developers just did not participiate and still feel beeing cheated by its creators. Come on. The farce is that, two years later, people are _still_ complaining because they didn't read the thing they voted on, or that they didn't bother to vote at all. Can you all please stop? please file RC bugs against all kernel packages immediately. Their packagers allow people to run non-free software, we need to strike against this evil, now! I know you're not that stupid. You know very well that there is a difference between something that _can_ work with both free and non-free software, and something that _must_ use non-free software. People have speculated that ndiswrapper could be used with free Windows drivers, but that seems not to be true, as nobody has been able to find any free Windows drivers. Oh, except the one nobody would use, because it's a port of a native Linux driver which is already in Debian. signature.asc Description: Digital signature
Bug#353688: ITP: Malayalam-Omega -- A package for typesetting Malayalam using Omega
Package: wnpp Severity: wishlist Owner: Mahesh T. Pai [EMAIL PROTECTED] * Package name: Malayalam-Omega Version : 1.0.0 Upstream Author : Alex A. J. [EMAIL PROTECTED], C. V. Radhakrishnan [EMAIL PROTECTED] * URL : http://malayalam.sarovar.org; http://sarovar.org/projects/malayalam. * License : Latex Project Public License Description : A package for typesetting Malayalam using Omega The Malayalam-Omega Package offers a set of macros and fonts for typesetting Malayalam, which is the primary language of an estimated 33 million people in the South Indian state of Kerala. This version of Malayalam-Omega provides the ability to typeset UTF-8 encoded text in Malayalam using LaTeX. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier: [..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. Read again, that's just what I said in the part that you deleted. HS
Re: Bug#353688: ITP: Malayalam-Omega -- A package for typesetting Malayalam using Omega
Mahesh T. Pai [EMAIL PROTECTED] wrote: Description : A package for typesetting Malayalam using Omega The Malayalam-Omega Package offers a set of macros and fonts for typesetting Malayalam, which is the primary language of an estimated 33 million people in the South Indian state of Kerala. This version of Malayalam-Omega provides the ability to typeset UTF-8 encoded text in Malayalam using LaTeX. Nice to see this in Debian. Be sure to follow the Debian Policy draft in the tex-common package. You can send questions and Policy criticizm to [EMAIL PROTECTED] Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
* David Weinehall: Upstream includes non-free manpages these days, so in reality, we have already forked. Further Debian-specific changes are needed to address bugs such as #295211 (upstream does not document our libc/kernel combination). What manpages in upstream are non-free? Do we have rewritten alternatives in Debian, or are those pages simply removed without replacement? They are simply removed without replacement. For most of the older system calls, the old free manpages (which also contain Linux-specific details) are still included in the upstream package. Only new system calls (such as mq_receive) appear to be undocumented. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Feb 20, Peter Samuelson [EMAIL PROTECTED] wrote: Come on. The farce is that, two years later, people are _still_ complaining because they didn't read the thing they voted on, or that they didn't bother to vote at all. Can you all please stop? No, it will never end. A few people managed to change the definition of freedom which was commonly accepted when I joined the project nine years ago and I do not feel a moral need to support their position. For the records, I voted against the GR. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
* Marco d'Itri [EMAIL PROTECTED] [060219 11:34]: Nevertheless, if you think abiword and openoffice.org should be moved then go for it. Just don't use them as excuse to turn warez wrappers into generic driver interfaces. No excuses are needed, the definition of contrib is enough and ndiswrapper has been uploaded to main using the same criteria which have been used in the past for emulators. Stop rewriting history. Please also stop insulting ndiswrapper users and developers by calling it a warez wrapper. emulators, game engines and other stuff not usefull without something to act on has always been placed in contrib when there was no free stuff available for them. History has always been: Write something free for it, then it is main; if you don't then it is obviously at most contrib. Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft DDP policy
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Fri, Feb 17, 2006 at 08:58:12AM +0100, Frank Küster wrote: Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Policy says to ship HTML, else I wouldn't. Policy is somewhat out of date with respect to documentation. There's actually a (draft) DDP policy which covers this already. I know, I've written it. Where can we look at the draft? http://www.debian.org/doc/docpolicy will direct you to http://www.debian.org/doc/manuals/ddp-policy/ddp-policy BTW, it probably needs a rewrite Indeed, it seems so. I won't have time to do this, but I'd like to make some suggestions. It seems to me that the document addresses two related, but rather different issues. One is How should documentation packages install and register their documents, and it's targetted at any maintainer and could finally find its place in The Policy. The other is How do we want to document Debian and its procedures, administration etc., and it is mostly uninteresting for everybody except those who actually maintain those documents. Even people who regularly submit patches (like I do for developer's reference) need not know this. I therefore suggest to split the document in two, one with the aim of becoming a Documentation Packages Policy within the debian-policy package; the other a kind of Documenting Debian HOWTO with a more limited audience. If casual contributors need to know anything from it (like a requirement to license one's patch explicitly under the license of the document with a signed mail or things like this), it could be included in a how to improve this section in every document. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: TrueType fonts packages maintenance team proposal
Christian Perrier wrote: List of current ttf-* packages -- (just looking at the packages descriptions give a good idea of the non-coordination of font packaging..:-))) [...] ttf-opensymbol - The OpenSymbol TrueType font built from OOo... Regards, Rene signature.asc Description: Digital signature
Re: TrueType fonts packages maintenance team proposal
Christian Perrier [EMAIL PROTECTED] wrote: The first goal for this team would be setting up a font packaging policy. [...] I have voluntarily limited the scope of the project to TTF fonts, which become more an more popular. This is mostly by ignorance and because of my loose knowledge of other font systems. Feel free to propose a wider project (but not too much wide, also: having a first limited focus is probably more realistic). I'd be glad if you'd keep the Debian TeX Task Force (currently at [EMAIL PROTECTED], soon at [EMAIL PROTECTED]) informed about drafts of this policy. Although we don't currently package any TTF fonts, pdftex can in principle use them (as well as PostScript Type1 fonts and, to a still limited extend, OTF). Unfortunately, it has rather specific requirements with respect to file placement and even naming. It would be nice if we'd manage to keep the needed setup (symlink farms...) as simple as possible. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: TrueType fonts packages maintenance team proposal
Beeing the new ttf-bitstream-vera maintainer, I have the same opinion as to other 'team-maintenance-proposals': As long as the package itself is not as complicated as I could not been handled well by one person, I don't like the 'team'-idea - it's unecessary overhead for me. Let's write a fontpackages sub-policy instead, and let it up to the people to decide how they want to maintain their packages. (Sorry, if this sounds a bit harsh, but it's not ment as an offence, and I appreciate your initiative). -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
Christian Perrier wrote: I have voluntarily limited the scope of the project to TTF fonts, which become more an more popular. Perhaps the PostScript fonts in Debian could use some attention as well. I've been trying to package a very simple PHP library which in the upstream version includes copies of the standard Adobe fonts (Courier, Times etc). It turns out that these fonts are included in various Debian packages, but unfortunately they don't make them available to other applications in a uniform manner (especially not if you want to preserve the association between .pfa and .afm files). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le lundi 20 février 2006 à 11:56 +0100, Hendrik Sattler a écrit : Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier: [..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. Read again, that's just what I said in the part that you deleted. Well, I read it again, and I'm sorry to say that I did not understand that from your wording. Also, not breaking lines and having that strange reply format renders it much more difficult to read. But anyway, the essential is that we mean the same. HS
Re: User-defined fields in control file
Steve Langasek [EMAIL PROTECTED] writes: On Tue, Feb 14, 2006 at 08:09:00PM +0100, Andre Majorel wrote: Would it be OK for an ISV to insert a user-defined field (X-Yoyodyne-Peanuts) in their binary Debian packages ? Name collisions aside, no chance of causing problems with dpkg, apt and friends ? Nope, the most you should get is a warning from dpkg-deb. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ dpkg has a special syntax that tells if a custom field in debian/control should end up in the deb, dsc and/or changes file. Correctly used that should cause no problems. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
* Goswin von Brederlow [Sun, 19 Feb 2006 23:42:55 +0100]: But that is just me. Do what you want as long as ndiswraper stays out of non-free. Now, that's an idea. Robert, you listening? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In Italy, for 30 years under the Borgias they had warfare, terror, murder, bloodshed, but they produced Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love - they had 500 years of democracy and peace, and what did that produce? The cuckoo clock. -- Harry Lime in “The Third Man” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Type1 fonts in Debian (was: TrueType fonts packages maintenance team proposal)
Marcus Better [EMAIL PROTECTED] wrote: Christian Perrier wrote: I have voluntarily limited the scope of the project to TTF fonts, which become more an more popular. Perhaps the PostScript fonts in Debian could use some attention as well. I've been trying to package a very simple PHP library which in the upstream version includes copies of the standard Adobe fonts (Courier, Times etc). It turns out that these fonts are included in various Debian packages, ... and sometimes in quite buggy versions. I don't recall the details (but could look them up), but AFAIR the gsfonts package contains a version of the URW fonts that has been labelled experimental and actually is; especially in the Courier font there were severe problems. Somewhere in the debian-tetex-maint list Ralf Stubner posted a description how to make gs use the variants included in tetex instead. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Type1 fonts in Debian (was: TrueType fonts packages maintenance team proposal)
also sprach Frank Küster [EMAIL PROTECTED] [2006.02.20.1619 +0100]: ... and sometimes in quite buggy versions. I don't recall the details (but could look them up), but AFAIR the gsfonts package contains a version of the URW fonts that has been labelled experimental and actually is; especially in the Courier font there were severe problems. i recently purchased some non-free fonts and would like to make them into debian packages for internal use. Thus, I would be very interested in following such efforts to learn how to accomplish what i need. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! i started taking an online add test, linked from someone's blog. i never finished it; i got distracted, and clicked on random other shiny things -- andres salomon signature.asc Description: Digital signature (GPG/PGP)
Re: Type1 fonts in Debian
martin f krafft [EMAIL PROTECTED] wrote: also sprach Frank Küster [EMAIL PROTECTED] [2006.02.20.1619 +0100]: ... and sometimes in quite buggy versions. I don't recall the details (but could look them up), but AFAIR the gsfonts package contains a version of the URW fonts that has been labelled experimental and actually is; especially in the Courier font there were severe problems. i recently purchased some non-free fonts and would like to make them into debian packages for internal use. Thus, I would be very interested in following such efforts to learn how to accomplish what i need. Hm, this is a general remark about a font packaging/integration policy, right? You hardly have bought non-free drop-in replacements for Times, Helvetica, Courier and friends. But Ralf's instructions were only for replacing these Base35 fonts. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Type1 fonts in Debian
also sprach Frank Küster [EMAIL PROTECTED] [2006.02.20.1644 +0100]: Hm, this is a general remark about a font packaging/integration policy, right? You hardly have bought non-free drop-in replacements for Times, Helvetica, Courier and friends. But Ralf's instructions were only for replacing these Base35 fonts. Ah, yes. General policy/instructions. Sorry. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! if builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. -- gerald weinberg signature.asc Description: Digital signature (GPG/PGP)
Brazilian Soccer News
TetraBrazil offers International Coaches the unique opportunity to travel to Brazil and get the Brazilian National Soccer Association Professional Coaches’ License ("A" License). Brazilian National Soccer Coaches Association - ABTF - is the only organization in Brazil that certifies the Professional Soccer Coach. Recognized by FIFA, CBF, and other established soccer organizations. ABTF has been developing educational programs for coaches for the last 25 years.
Register for a TetraBrazil TEAM CLINIC this summer by March 31 and get FREE Tuition to one of our Coahching Programs in Brazil:
Choose from one of the following options:
Tours Media Kit: Video - View Slideshow - FAQ's - Request info
Club Partner in Brazil
Home | About TB | Partnership Program | Soccer Camps | Team Clinics | FUTSAL Training |
©1999-2006 TetraBrazil Soccer Academy, LLC. All Rights Reserved
We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mail updates from TetraBrazil Soccer Academy,please reply this e-mail withsubject “REMOVE".
\
Re: TrueType fonts packages maintenance team proposal
On Mon, 20 Feb 2006, Daniel Baumann wrote: Let's write a fontpackages sub-policy instead, and let it up to the people to decide how they want to maintain their packages. Christian, I have to agree with Daniel here. We don't really need joint maintenance but coordination on font policy would be a good idea. (Also if someone could explain just how the heck defoma is supposed to work...) -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: Please also stop insulting ndiswrapper users and developers by calling it a warez wrapper. Actualy, since such ndis drivers are often provided with very restrictive licensing, or with no licensing at all, I have my doubts that inserting them into Linux kernel is a legal activity. This is of no concern to Debian though, but makes the name warez very appropiate. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
reopen 353278 reassign 353278 tech-ctte reopen 353277 reassign 353277 tech-ctte merge 353278 353277 thanks Hi, I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. My reasons are: - The sole purpose of these packages is allowing the use of non-free Windows drivers. - There are no free Windows drivers for this interface, except a port of a Linux driver to Windows (cipe), which is only used on native Windows platform (since it is pointless to emulate it from Linux, where the original cipe is already available). The maintainer refuses to move it unless you rule a formal decision or a consensus is reached. I think the latter is impossible, and therefore I ask you to consider the issue. Thank you. On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: On Sun, 2006-02-19 at 11:34 +0100, Marco d'Itri wrote: On Feb 19, Robert Millan [EMAIL PROTECTED] wrote: Nevertheless, if you think abiword and openoffice.org should be moved then go for it. Just don't use them as excuse to turn warez wrappers into generic driver interfaces. No excuses are needed, the definition of contrib is enough and ndiswrapper has been uploaded to main using the same criteria which have been used in the past for emulators. Stop rewriting history. Please also stop insulting ndiswrapper users and developers by calling it a warez wrapper. And for fuck's sake, stop filling up my inbox w/ this crap. I'm not doing a thing unless either a) you people come to a consensus on the issue (which you have not in the past threads, and probably never will), or b) a governing body like the ctte tells me that it should be in contrib. Otherwise, it's staying right where it is. Honestly, I could care less whether it's in contrib or main, but it was a decision that was made long ago, and I see no reason to make the change. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Feb 20, Bernhard R. Link [EMAIL PROTECTED] wrote: emulators, game engines and other stuff not usefull without something to act on has always been placed in contrib when there was no free stuff available for them. History has always been: Write something free for it, then it is main; if you don't then it is obviously at most contrib. Yes (even if it was a trivial application), and this has been the case for ndiswrapper too. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
* Mike Hommey [Sun, 19 Feb 2006 11:07:33 +0100]: (Which means apt-file searches over *all* debian packages, contrib and non-free included, despite the fact that i only have main in my apt sources) (Note that the Content.gz files come per dist/arch, not per dist/component/arch.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[EMAIL PROTECTED] (Marco d'Itri) writes: On Feb 20, Peter Samuelson [EMAIL PROTECTED] wrote: Come on. The farce is that, two years later, people are _still_ complaining because they didn't read the thing they voted on, or that they didn't bother to vote at all. Can you all please stop? No, it will never end. A few people managed to change the definition of freedom which was commonly accepted when I joined the project nine years ago and I do not feel a moral need to support their position. This is, I believe, unacceptible. GR's are the way we make decisions as a project. Maintainers are expected to abide by those decisions when they do their work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352073: ITP: gerwin -- CASE tool for edit data model
retitle 335018 ITP:GNU Ferret - GNU Free Entity Relationship and Reverse Engineering Tool Change name package to GNU Ferret. Em Qui, 2006-02-09 às 17:13 +0100, Krzysztof Krzyzaniak escreveu: Fernando Ike de Oliveira wrote: Package: wnpp Severity: wishlist Owner: Fernando Ike de Oliveira [EMAIL PROTECTED] * Package name: gerwin Version : 0.6 Upstream Author : Jose E. Marchesi [EMAIL PROTECTED] * URL : http://www.nongnu.org/gerwin/project/what.html * License : GPL Description : CASE tool for edit data model GerWin (the GNU Entity/Relationship Wished Incarnation) is a CASE tool for edit data models. These data models can then be implemented on some relational dataDB base implementation such as PostgreSQL, Mysql or SGDB compatible SQL-92. When you go to URL page you'll see: The GerWin project has changed its name! The GerWin project has changed its name to GNU Ferret: GNU Free Entity Relationship and Reverse Engineering Tool. The rationale behind the name changing is to avoid futurable legal conflicts with the owners of the Erwin(TM) trademark. eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej -- Fernando Ike de Oliveira [EMAIL PROTECTED] signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)
On Mon, 20 Feb 2006, Joerg Jaspert wrote: On 10571 March 1977, Richard A. Nelson wrote: Not only did you hijack these packages, and without *ANY* communication, you missed tcl3270, ICU builds (for the non-US folk)... You know that this package set was removed since march, so you cant say much against him bringing it back? Yes I know... I'm the one that had it removed ! The issues for which it was removed have gotten better, but have not yet been fully resolved. If you had the courtesy to contact me, as did the last person - who at least followed procedure and issued an ITP, you would know this. You would also know that I use this package every day, have kept it current, fixed some bugs... Even distribute updates. So yes, I can, and will say much against you bringing it back ! Look, I depend upon on this package for my living - It wasn't lightly that it was removed from Debian, some of the final issues were, in my opinion nits - but they still needed to be resolved. If you had managed to clear the remaining issues, courtesy would've compelled you to contact me - I've not fallen off the face of the earth; especially since you started with the last Debian version of the package (even leaving my changelogs intact). -- Rick Nelson _Anarchy_ Argh.. who's handing out the paper bags 8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Type1 fonts in Debian
Frank Küster [EMAIL PROTECTED] writes: Somewhere in the debian-tetex-maint list Ralf Stubner posted a description how to make gs use the variants included in tetex instead. For the record, these instructions can be found at URL:http://www.tfkp.physik.uni-erlangen.de/~ralf/debian/tex-lw35.html. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)
* Richard A Nelson [Mon, 20 Feb 2006 09:36:52 -0800]: If you had the courtesy to contact me, as did the last person - who at least followed procedure and issued an ITP, you would know this. Why are you addressing Joerg Jaspert instead of Bastian Blank? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Create a system that is usable even by idiots, and only idiots will use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353545: ITP: wormsofprey -- Worms like multiplayer, realtime game
Hi! * Oya [EMAIL PROTECTED] [060220 03:04]: * Package name: wormsofprey [..] Description : Worms like multiplayer, realtime game This is another multi-player, real-time clone of Worms just like Liero and NiL. You control a little worm and try to score as many frags as possible by shooting other worms or scoring goals. You might want to extend the long description a bit: What's so special about this one? What are the differences to Liero and NiL? Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: Type1 fonts in Debian
martin f krafft [EMAIL PROTECTED] writes: i recently purchased some non-free fonts and would like to make them into debian packages for internal use. Thus, I would be very interested in following such efforts to learn how to accomplish what i need. The main intention behind mk-tex-fontpack (see URL:http://svn.debian.org/wsvn/debian-tex/make-texfontpkg/trunk/scripts/) is to ease the installation of Type 1 fonts for TeX, which needs several other files beside the fonts themselfs. However, it also registers the fonts with X11 and defoma in the following way: * PFB and AFM files are installed in /usr/share/fonts/type1/$packname * links pointing from /usr/X11R6/lib/X11/fonts/Type1 to PFB and AFM files are created * a fonts.scale (created via mkfontscale or type1inst) is installed as /etc/X11/fonts/Type1/$packname.scale and activated via dh_installxfonts * a defoma-hints file (created via defoma-hints --no-questionin) is palced as debian/$packname.defoma-hints and activated via dh_installdefoma One has to keep in mind that the autogenerated fonts.scale and defoma-hints files are often bad. That is ok for mk-tex-fontpack since its main purpose is fonts for TeX. But if one want to install only for use with X11/defoma, one ought to carefully review these files. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
On Monday 20 February 2006 06:40, Christian Perrier wrote: The project could also include the maintenance of font-related tools, such as fontforge or defoma (which seems mostly abandoned, but probably requires solid knowledge or Perl and cryptic programming...:-)). As several people have noticed, the FreeType packages in Debian could do with some serious love that I do not have time to give. There are several issues in the BTS that are issues with either fonts or FreeType's rendering of a particular font, so it would be useful to get font maintainers actively involved with maintenance of this package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
On Monday 20 February 2006 07:40, Christian Perrier wrote: So, I hereby propose to think about a possible TTF fonts packaging team. A comment as a pure user insofar as fonts are concerned: I don't care if what I see comes from a ttf, metafont, ps, bdf or PEX font. I just want the font to be available everywhere. So I'd suggest that at least ttf and ps fonts should be managed in some common way - so a font packaging (or policy?) team may want to look at more than just ttf fonts. cheers -- vbi (Yes, I realize that bdf and PEX are dying or dead, and that there probably is currently support for TeX/Metafont fonts in X/Pango/whatever KDE uses ;-) (Hmmm. I think I forgot Linux console bitmap fonts... Or are these bdf, too?) -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpIyzPA0AgbQ.pgp Description: PGP signature
Re: Bug#353277: ndiswrapper in main
On 2/20/06, Robert Millan [EMAIL PROTECTED] wrote: I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. This proposal is clear enough. My reasons are: - The sole purpose of these packages is allowing the use of non-free Windows drivers. - There are no free Windows drivers for this interface, except a port of a Linux driver to Windows (cipe), which is only used on native Windows platform (since it is pointless to emulate it from Linux, where the original cipe is already available). I'm not sure I agree with this. When I look at the list of drivers that ndiswrapper supports http://ndiswrapper.sourceforge.net/mediawiki/index.php/List I see several that seem to be open source. You've asserted that none of these drivers satisfy the DFSG, but I think we would need more than an assertion on this issue. As a specific counter example, consider http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which is a project porting a windows driver to linux. This port appears to be possible because the windows driver was made available under a free license. -- Raul
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 06:12:36PM +0200, Lars Wirzenius wrote: la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti: What's the purpose of an assembler without assembly code to use it on? It can be used, for example, to assemble code you write yourself. Exactly. ndiswrapper can be used, for example, to run a driver you write yourself. Software that requires the use of non-free libraries can not ever be used without those non-free libraries. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353777: ITP: multixterm -- drive multiple xterms separately or together
Package: wnpp Severity: wishlist Owner: gregor herrmann [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: multixterm Version : 1.8 Upstream Author : Don Libes [EMAIL PROTECTED] * URL : http://expect.nist.gov/example/ * License : Public domain Description : drive multiple xterms separately or together Multixterm creates multiple xterms that can be driven together or separately. In its simplest form, multixterm is run with no arguments and commands are interactively entered in the first entry field. Press return (or click the new xterm button) to create a new xterm running that command. Keystrokes in the stdin window are redirected to all xterms started by multixterm. xterms may be driven separately simply by focusing on them. The stdin window must have the focus for keystrokes to be sent to the xterms. When it has the focus, the color changes to aquamarine. As characters are entered, the color changes to green for a second. This provides feedback since characters are not echoed in the stdin window. Typing in the stdin window while holding down the alt or meta keys sends an escape character before the typed characters. This provides support for programs such as emacs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+infOzKYnQDzz+QRAr/kAKDU/SPWN6IyEdP4Zhow20+1QZdxIwCgqU/V 5N8CR2jHtf1ISI/RhttJTlo= =Zzao -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352073: ITP: gerwin -- CASE tool for edit data model
Fernando Ike de Oliveira [EMAIL PROTECTED] writes: retitle 335018 ITP:GNU Ferret - GNU Free Entity This should be sent to [EMAIL PROTECTED] -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Robert Millan writes: On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: Please also stop insulting ndiswrapper users and developers by calling it a warez wrapper. Actualy, since such ndis drivers are often provided with very restrictive licensing, or with no licensing at all, I have my doubts that inserting them into Linux kernel is a legal activity. This is an interesting theory. Drivers' licenses are obviously irrelevant to a discussion of whether ndiswrapper is freely licensed. The FSF's usual position[1] is that the GPL does not require GPL compatibility for non-distributed modifications of a GPLed program. Are you saying that the FSF is incorrect about the GPL, or are you making some other claim about what behavior is permitted? [1]- http://www.gnu.org/licenses/gpl-faq.html#StolenCopy Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 20, 2006 at 05:10:42PM +1000, Anthony Towns wrote: On Sun, Feb 19, 2006 at 03:14:40AM +0100, Wouter Verhelst wrote: [...] It is already possible to use ndiswrapper without having any non-free software installed. Granted, it doesn't do much useful that way, If you have to differentiate between able to be used and useful, you don't have a point. What if I'm interested in writing such a driver myself, but less interested in having to run Windows? but a) neither the DFSG nor the SC say anything about usefulness, and b) if a free library package exists in main which no other free package uses it, we don't move the free library package to contrib either. If it's only useful for non-free software, we should probably consider it. More likely, it's not useful at all, and we should consider dropping it entirely. How many libraries do we have in this state? apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? It's very easy, really. Requires the use of non-free software is a far cry from only non-free software requires this software. You need wheels to use a car; you don't need a car to use wheels. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sun, Feb 19, 2006 at 02:11:30AM -0600, Peter Samuelson wrote: [Michael Poole] If you want to move ndiswrapper to contrib, I expect the next step is to do the same to libflash, for the same reasons. There's a big difference between enabling someone to install non-free software, and enabling someone to view data. Uh, isn't data and software the same thing according to the latest version of the DFSG? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
The difference is that antiword is a tool for the user. The user will have doc files to use with antiword, e.g. send by mail. The antiword program on its own provides the user with the ability to view his/her word files. It does not depend on the existance of such a file on the system to provide that service. And what's exactly the difference to: The user will have drivers to run his hardware with, provided by the vendor. ndiswrapper on its own provides the user with the ability to use his/her drivers (and therefore, hardware). ? Olaf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Wouter Verhelst] What if I'm interested in writing such a driver myself, but less interested in having to run Windows? Then you should get busy writing that driver. Without any such drivers in existence, it's hard to take this line of reasoning seriously. I find it absurd that someone would be interested in writing a Windows driver but not interested in running Windows to test it on. If that's really what you want to do, please say so, preferably with some sort of evidence. I hate to have to ask for evidence rather than taking your word for it, but the scenario seems so contrived that I'm afraid only evidence will make it seem less so. apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? No, not really. There's plenty of software, free and otherwise, which one might wish to compile with g++ 2.95. Newer g++ versions get pickier about C++ syntax and semantics, and thus it's reasonable to retain g++ 2.95 so that people don't have to port their old software to modern C++. (Yes, I said their old software. Lots of people have written C++ code that they want to run on Debian, unlike Windows drivers.) Fortunately it seems very few packages in Debian require gcc-2.95 or g++-2.95 anymore. So yes, I agree, at some point we should drop the whole gcc-2.95 source package. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Why on earth would anyone want to run the Windows version of a native Linux app under a Windows emulation under Linux? :-) Because they're a developer of that app and they want to test the Windows port before releasing? Okay, that's a bit of a corner case ;-) but nonetheless valid. Olaf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Anthony Towns aj@azure.humbug.org.au writes: If it's only useful for non-free software, we should probably consider it. More likely, it's not useful at all, and we should consider dropping it entirely. How many libraries do we have in this state? We went through this whole discussion with emulators, with people pushing them towards contrib under the theory that there was no free firmware for them to play. Then people packaged various free firmware just to get the emulators back into main. This process strikes me as a significant waste of time and energy, and I'm not sure what it's supposed to accomplish. If the package absolutely requires a piece of non-free software to work, or if it's an installer for non-free software (such as the various installer packages or the packaging wrappers around djb software), it goes in contrib. If it just implements some sort of API or ABI that isn't specific to some *particular* piece of non-free software, I think shoving it towards contrib is just a waste of everyone's time. As we already saw with emulators, free uses of that API or ABI tend to eventually materialize, making this distinction requires drawing a lot of thin and hazy lines, and (worst of all) it always sparks long, pointless threads about the definition of freedom on debian-devel. I don't think the distinction between main and contrib should be so unstable as to change based on the existence of some theoretical piece of third-party software. As long as the software implements some reasonably generic API or ABI that isn't inherently non-free and doesn't require a dependency on non-free software in the dpkg sense, I say just put it in main and not worry about whether anyone has used that API or ABI in free software yet. It saves on moving things around later, I can't see how it breaks anything in the DFSG, and it means one less controversial grey area decision that we have to make all the time. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 11:11:32AM +0100, Robert Millan wrote: On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote: On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow The availability to do this is enough even if there are other (possibly better) ways to do the same. One free driver _in_ Debian and the package should stay in main. But does the cipe-source build or ship the windows driver for use with ndiswraper? I doubt that. Which means you need some software (even if it is free) from outside Debian for ndiswraper. That makes it contrib imho. Are there any free MSWord files in main ? No ? Then please move antiword and similar tools to contrib. You're turning this into non-sense. An NDIS wrapper is OBVIOUSLY for the exclussive purpose of using non-free Windows drivers. It is so obvious because nobody has written [1] free GPLed NDIS drivers. EVER. It has nothing to do with Wine and MSWord [2]. So, stop throwing unrelated points to this matter. Just fix the bug. Move this to contrib, with all the other warez wrappers. [1] Written, not ported. I know someone ported that CIPE thing from Linux to Windows, but the sole idea of porting something to Windows in order to emulate it from Linux makes me laugh. The sole idea to run Internet Explorer under Wine on Linux makes _me_ laugh. But I've seen people do it. And they were not amused by my laughing. The fact that there is at least one GPL driver for ndiswrapper means that it is possible to use ndiswrapper for useful purposes without non-free software. And since cipe is not part of the kernel yet, that might be a good idea anyway if the native driver doesn't work with the kernel which you're using for some reason while ndiswrapper does. Which is not _that_ strange, I've seen it often enough with out-of-(vanilla)-kernel modules. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 20, 2006 at 04:21:44PM -0600, Peter Samuelson wrote: [Wouter Verhelst] apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? No, not really. There's plenty of software, free and otherwise, which one might wish to compile with g++ 2.95. Newer g++ versions get [...] Fortunately it seems very few packages in Debian require gcc-2.95 or g++-2.95 anymore. Uhm. How many reasonable and up-to-date free software exists that is not in Debian? Seriously. So yes, I agree, at some point we should drop the whole gcc-2.95 source package. I happen to think this discussion is getting increasingly silly. There's only one free driver which would work with ndiswrapper! there's many many many more Windows applications which are free! What people fail to mention is that there are many many many more Windows applications than there are drivers that use the NDIS environment, and that percentually, one free driver might be a *lot* more than the number of Free applications that are ran under wine. How many have ever used wine to run Free Software? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[ObRC: 343781] On Tue, Feb 21, 2006 at 12:16:23AM +0100, Wouter Verhelst wrote: How many have ever used wine to run Free Software? I have. FWIW. I've also used wine in the process of developing and testing non-free software. I think that's a valid rationale for keeping wine in main; we don't require that people demonstrate word processors being used to create free documents before we say they can go in main, because using them to create *non*-free documents is a valid use case, and the Social Contract only talks about whether we *depend* on non-free stuff -- not whether the user chooses to use the program for non-free stuff. The same reasoning potentially applies to ndiswrapper, but I don't think it makes sense to base this on a hypothetical. If people *are* using ndiswrapper for developing drivers -- free or non-free -- then ok. If we're just saying it *could* be used that way, then this is rationalization. I know ndiswrapper wouldn't be useful to me if I didn't have a non-free Windows driver to go with it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)
On 10571 March 1977, Richard A. Nelson wrote: If you had the courtesy to contact me, as did the last person - who at least followed procedure and issued an ITP, you would know this. Tss, calm down, i absolutely do not care about this stupid package. -- bye Joerg Or write yourself a DFSG-free replacement for that piece of software. Using the copy and paste method from the old source, obscured by irrelevant changes. pgp3wQnZdDGCQ.pgp Description: PGP signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote: I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. ndiswrapper is a program to allow users to load Windows drivers for their hardware and use them on Linux. The drivers are executed on the main CPU; there are no free drivers that ndiswrapper is useful for, apart from a single example driver that is a port of a driver already in the kernel. We currently allow both emulators, that play non-free ROMs, and clients for network protocols for which there is no non-free server into main. ndiswrapper was accepted into main in November 2004. AFAICS, this would come under the overrule a developer (3:1 majority) power. The maintainer refuses to move it unless you rule a formal decision or a consensus is reached. I think the latter is impossible, and therefore I ask you to consider the issue. While I would personally rather see the contrib demarkation cover this, emulators, and clients for propietary protocols, I'm disinclined to override both the maintainer and the ftpmaster that accepted it, particularly on this single issue rather than as a global policy change for those issues. I expect I'll either abstain or vote against. Cheers, aj signature.asc Description: Digital signature
Bug#353802: ITP: gcom -- Option GlobeTrotter and Vodafone datacard control tool
Package: wnpp Severity: wishlist Owner: Andreas Gredler [EMAIL PROTECTED] * Package name: gcom Version : 0.3 Upstream Author : Paul Hardwick [EMAIL PROTECTED] * URL : http://www.pharscape.org/content/view/46/70/ * License : GPL Description : Option GlobeTrotter and Vodafone datacard control tool Gcom is a scripting language interpreter useful for establishing communications on serial lines and through PCMCIA modems as well as GPRS and 3G datacards. Works with Option GlobeTrotter GPRS/EDGE/3G/HSDPA and Vodafone 3G/GPRS datacards. I also want to package the kernel modules but have to get more experience/knowledge with the creation of kernel packages, first. greets Jimmy -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: Because it's free software that processes asm input, and there is a significant amount of useful, free i386 asm that makes nasm necessary ? I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. This is beside the point. IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, so there's no reason it can't go in main. In fact, since it would be tremendously useful to be able to activate wireless ethernet devices with non-free drivers (from floppy/cd) during the install process, I'd say that it makes even more sense for ndiswrapper to go into main (and maybe even into base). --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: And for fuck's sake, stop filling up my inbox w/ this crap. I'm not doing a thing unless either a) you people come to a consensus on the issue (which you have not in the past threads, and probably never will), or b) a governing body like the ctte tells me that it should be in contrib. Otherwise, it's staying right where it is. Honestly, I could care less whether it's in contrib or main, but it was a decision that was made long ago, and I see no reason to make the change. The driver should stay in main and hooks should be written into the installer so that our users can easily enable their wireless cards during installation. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
On 20 Feb 2006, Lars Wirzenius stated: I added a Cc to Manoj since I would like to hear his comment. Whoever responds may want to remove the Cc to avoid stuffing his inbox unnecessarily. su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti: On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: * Use of ucf in postrm during a purge, without checking that ucf is installed. Since ucf is not an essential package, postrm during purge cannot rely on it. As it happens, I think it might be good to have ucf (or a subset of it) as an essential package, since this error happens a lot. So assuming that we're stuck with the current implementation for a bit where ucf is not part of essential, I do wonder if checking whether ucf is installed is actually the correct thing to do in postrm purge. The state prior to purge is defined as config files; the difference between config files state and purged is whether there are still config files left on the system. If the package can't actually succeed in removing its config files because ucf is not installed, isn't it *correct* for the postrm purge command to fail? I.e., I think it's more of a bug to allow dpkg to put the package into purged state leaving orphaned config files behind than it is for postrm purge to fail and leave the package in config files state. Hm. I don't use ucf on my own packages (yet), so my understanding is a bit hazy, but if I have understood correctly, the actual config file is removed with rm anyway, and ucf is needed on purge only to remove the config file also from ucf's history data. Thus, only running ucf if it's there should be the right thing. Manoj, could you comment on this? Your analysis is correct. manoj -- I'd love to go out with you, but I did my own thing and now I've got to undo it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 20, 2006 at 09:13:15PM -0800, Adam McKenna wrote: The driver should stay in main and hooks should be written into the s/driver/package.. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Tue, Feb 21, 2006 at 10:40:06AM +1000, Anthony Towns wrote: On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote: I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. ndiswrapper is a program to allow users to load Windows drivers for their hardware and use them on Linux. The drivers are executed on the main CPU; there are no free drivers that ndiswrapper is useful for, apart from a single example driver that is a port of a driver already in the kernel. We currently allow both emulators, that play non-free ROMs, and clients for network protocols for which there is no non-free server into main. ndiswrapper was accepted into main in November 2004. AFAICS, this would come under the overrule a developer (3:1 majority) power. Yes, this is not a request from Andres that we make a decision on his behalf, therefore the Technical Committee would be acting to override the maintainer under 6.1.4 with a 3:1 majority. The maintainer refuses to move it unless you rule a formal decision or a consensus is reached. I think the latter is impossible, and therefore I ask you to consider the issue. While I would personally rather see the contrib demarkation cover this, emulators, and clients for propietary protocols, I'm disinclined to override both the maintainer and the ftpmaster that accepted it, particularly on this single issue rather than as a global policy change for those issues. I expect I'll either abstain or vote against. I suspect I disagree with Anthony on where exactly the line should be drawn, but it does seem to me that the arguments used to justify ndiswrapper's presence in main are rather contrived. Nobody is going to want to run drivers under ndiswrapper in a production environment if there is a suitable free equivalent available for Linux; the only practical applications I see here are using non-free Windows drivers under Linux for otherwise-unsupported hardware, and using ndiswrapper as a tool for preliminary testing of drivers being written for Windows in an environment that doesn't require booting Windows. The former is what I use it for, and what every user I know uses it for, and doesn't justify a claim that ndiswrapper does not depend on non-free software. The latter, IMHO, would be grounds for shipping the software in main, but AFAIK this is purely a hypothetical at this point. Either way, I do agree with Anthony that one-off overrides of maintainers don't seem like the best way for us to be spending our time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote: IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. That's a mistaken view; the purpose of contrib is to give us a place to ship free software that we can't ship in Debian proper (ie, main) because it would violate We will never make the system require the use of a non-free component or, historically, ... we will never make the system depend on an item of non-free software. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: Honestly, I could care less whether it's in contrib or main It's nice to see that Debian Developers actually care about their Social Contract, and hold acceptance by Debian in such high regard. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
I'd be glad if you'd keep the Debian TeX Task Force (currently at [EMAIL PROTECTED], soon at [EMAIL PROTECTED]) informed about drafts of this policy. Although we don't currently package any TTF Of courseActually, I see some difference between TTF fonts which most common use are desktop environments and Type1 fonts, which use is more specialized (correct me if I say stupid things, I'm far from having good knowledge of all this...which is actually one of the motivations for a team...:-)) So, unless some good arguments come up, this team and loose policy would then be limited to TTF fontsbut of course, the TSF will be kept posted (will try to remember crosspositing for a next announcement). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
Quoting Jaldhar H. Vyas ([EMAIL PROTECTED]): Let's write a fontpackages sub-policy instead, and let it up to the people to decide how they want to maintain their packages. Christian, I have to agree with Daniel here. We don't really need joint maintenance but coordination on font policy would be a good idea. (Also if someone could explain just how the heck defoma is supposed to work...) I actually have no intent to enforce this to people who prefer maintaining the package they maintain alone. My current view is more having a common place for package maintenance (for maintainers who want to join), possibly with sub-places for packages which have joined this loose team. There, each package maintainer would have to choice to either be the only responsible person for the package (aka be Maintainer and Uploader alone)or give precedence to the team...or whatever combination. Again, no enforcement for anyone to join the team and the packaging policy would then be more a set of guidelines rather than an enforced policy such as other packaging policies. As you mention, Jaldhar, there are a few things related to font packaging which are not obvious to people who package fonts. defoma is among theseand fontforge os probably another one. So the team could also be a good place for font maintainers to share their experience and maybe also benefit from a wider experience by epople who have a good knowledge of such deep technical stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PROPOSAL: debian/control file to include new License: field
To my understanding the only way to obtain the license information for a package is to actually download it (or install it) and the study the content of /usr/share/doc/package/copyright It would be better if user could use the packaging search commands, like grep-dctrl -F License ... --and -F package ... PROPOSAL: Add new field to the debian/control (which would be generated by dh-make): License: It would contain a canonicalized word to describe the license in questions, like: GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom The number of generic license name can be debated and instead of the last resort Custom there could be word like: DFSG-approved, OSI-approved, FSF-approved etc. DH_MAKE TEMPLATE If given the option --copyright, then the field is initialised with that value, otherwise add Licence: Set here; see http://wiki.debian.org/DFSGLicenses Jari [PS] Should this be disccussed in, (crossposted to) debian-legal as well? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
Jari Aalto [EMAIL PROTECTED] writes: To my understanding the only way to obtain the license information for a package is to actually download it (or install it) and the study the content of /usr/share/doc/package/copyright It would be better if user could use the packaging search commands, like grep-dctrl -F License ... --and -F package ... Out of curiosity, why? What problem are you trying to solve? PROPOSAL: Add new field to the debian/control (which would be generated by dh-make): License: It would contain a canonicalized word to describe the license in questions, like: GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom This has been proposed before. One of the problems with this idea is that many packages have more complex licenses than that, ones that cannot be easily encapsulated into a single term. Many packages contain files under various different licenses and many packages are covered under minor modifications to standard licenses, so coming up with these terms becomes a bit complicated, can't be fully accurate, and seems likely to spawn a complicated set of rules that are hard to verify. In other words, it seems like a lot of work, and it's not clear what problem it would really solve. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
Christian Perrier [EMAIL PROTECTED] writes: Of courseActually, I see some difference between TTF fonts which most common use are desktop environments and Type1 fonts, which use is more specialized From a user point of view, TTF and Type1 fonts are essentially the same; they both work well for typical desktop use in debian. [Maybe in the past there were differences due to e.g. the different hinting strategies, but these days freetype seems to handle both equally well. I don't know whether windows/macos are similarly advanced.] -Miles -- .Numeric stability is probably not all that important when you're guessing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
* Jari Aalto [EMAIL PROTECTED] [2006-02-21 08:01]: To my understanding the only way to obtain the license information for a package is to actually download it (or install it) and the study the content of /usr/share/doc/package/copyright That information can also be obtained from packages.debian.org (currently use pdo.debian.net). yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
On Mon, Feb 20, 2006 at 11:12:46PM -0800, Russ Allbery wrote: Jari Aalto [EMAIL PROTECTED] writes: To my understanding the only way to obtain the license information for a package is to actually download it (or install it) and the study the content of /usr/share/doc/package/copyright It would be better if user could use the packaging search commands, like grep-dctrl -F License ... --and -F package ... Out of curiosity, why? What problem are you trying to solve? PROPOSAL: Add new field to the debian/control (which would be generated by dh-make): License: It would contain a canonicalized word to describe the license in questions, like: GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom This has been proposed before. One of the problems with this idea is that many packages have more complex licenses than that, ones that cannot be easily encapsulated into a single term. Many packages contain files under various different licenses and many packages are covered under minor modifications to standard licenses, so coming up with these terms becomes a bit complicated, can't be fully accurate, and seems likely to spawn a complicated set of rules that are hard to verify. In other words, it seems like a lot of work, and it's not clear what problem it would really solve. Hi, would it provide any automation or easier processing for the NEW queue(ftpmasters)? would it allow for reducing package size by removing license text from all packages and having them installed in a seperate essential package stored in a canonical location (/usr/share/doc/dfsg-license-texts/) (dfsg-license-texts.deb) and have a file-license.txt to list which files are licensed under which license? Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 03:36:16PM +1000, Anthony Towns wrote: On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote: IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. That's a mistaken view; the purpose of contrib is to give us a place to ship free software that we can't ship in Debian proper (ie, main) because it would violate We will never make the system require the use of a non-free component or, historically, ... we will never make the system depend on an item of non-free software. Practically, it's to avoid shipping things on our CDs that depend on stuff that's not on our CDs. In this case, even in the absence of free NDIS drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) Thankfully, there is no need to make that argument, since at least one free NDIS driver exists (the aforementioned CIPE). ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted collatinus 7.13-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 08:11:59 +0100 Source: collatinus Binary: collatinus-data collatinus collatinus-doc Architecture: source all Version: 7.13-2 Distribution: unstable Urgency: low Maintainer: Georges Khaznadar [EMAIL PROTECTED] Changed-By: Georges Khaznadar [EMAIL PROTECTED] Description: collatinus - lemmatisation of latin text collatinus-data - data files for collatinus collatinus-doc - documentation for collatinus Changes: collatinus (7.13-2) unstable; urgency=low . [ Georges Khaznadar ] * removed the dependency on python-wxgtk2.4: python-wxgtk2.6 is mandatory. Closes Bug#353368 Files: 9e7605304df018d1d39043de52cada85 640 text optional collatinus_7.13-2.dsc 0b40ce4d5421ad81b82796003e7d27b7 2926 text optional collatinus_7.13-2.diff.gz 8e72cbc39c1ff1b26a19db04e433e247 59244 text optional collatinus_7.13-2_all.deb 157d0877558ca808d1c0d6e781bdd69c 245062 text optional collatinus-data_7.13-2_all.deb ef0f3ca4fba18d90fa6106bcd117a7ac 76650 text optional collatinus-doc_7.13-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+WzX1OXtrMAUPS0RAimiAJ0fjEkSHcxli8e8DX22r18KG+54LwCgt5qz 9YzwLxAS1KYqyC/+4u81aAw= =V30g -END PGP SIGNATURE- Accepted: collatinus-data_7.13-2_all.deb to pool/main/c/collatinus/collatinus-data_7.13-2_all.deb collatinus-doc_7.13-2_all.deb to pool/main/c/collatinus/collatinus-doc_7.13-2_all.deb collatinus_7.13-2.diff.gz to pool/main/c/collatinus/collatinus_7.13-2.diff.gz collatinus_7.13-2.dsc to pool/main/c/collatinus/collatinus_7.13-2.dsc collatinus_7.13-2_all.deb to pool/main/c/collatinus/collatinus_7.13-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnobog 0.4.3-2.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Feb 2006 22:35:14 -0800 Source: gnobog Binary: gnobog Architecture: source i386 Version: 0.4.3-2.2 Distribution: unstable Urgency: high Maintainer: Jan-Hendrik Palic [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: gnobog - GNOME Bookmarks Organizer Closes: 340118 Changes: gnobog (0.4.3-2.2) unstable; urgency=high . * Non-maintainer upload. * High-urgency upload for RC bugfix. * Drop unneeded build-dependency on non-existent libguile-dev. Closes: #340118. Files: 91c72a23baf0660ec63c948e1fb226d0 630 x11 optional gnobog_0.4.3-2.2.dsc 5ef90bfadca6ca049724af3b1298c950 340640 x11 optional gnobog_0.4.3-2.2.diff.gz 2bbb015df0b5eee83c26800f4ec31e04 319964 x11 optional gnobog_0.4.3-2.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+XPJKN6ufymYLloRAvM7AJ9Qr6DciJzuBFddOopJGHh+x6yJhwCgm0bN 8cJD4uEsmS08FXNrMruSpmg= =q+Nq -END PGP SIGNATURE- Accepted: gnobog_0.4.3-2.2.diff.gz to pool/main/g/gnobog/gnobog_0.4.3-2.2.diff.gz gnobog_0.4.3-2.2.dsc to pool/main/g/gnobog/gnobog_0.4.3-2.2.dsc gnobog_0.4.3-2.2_i386.deb to pool/main/g/gnobog/gnobog_0.4.3-2.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted qemu 0.8.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 09:17:46 +0200 Source: qemu Binary: qemu Architecture: source i386 Version: 0.8.0-2 Distribution: unstable Urgency: low Maintainer: Debian QEMU Team [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: qemu - fast processor emulator Closes: 276276 345772 348098 Changes: qemu (0.8.0-2) unstable; urgency=low . [ Guillem Jover ] * Switch away from cdbs to plain debhelper. * Upgrade to debhelper compat level 5. * Allow overriding CC compiler variable. (Closes: #345772) * Do not redefine 64 bit types on 64 bit arches. - debian/patches/61_safe_64bit_int.patch: New file. * Allow linux_boot.bin to be built on any arch by switching to nasm, and Build-Depending on it. - debian/patches/62_linux_boot_nasm.patch: New file. * The serial hw driver uses a small divider that gets zeroed when shifting bits to the right. (Closes: #276276, #348098) - debian/patches/51_serial_small_divider.patch: New file. Thanks to Samuel Thibault [EMAIL PROTECTED]. * Escaped hyphens in qemu-user manpage, use italics for filenames and parameters and bold for options. * Partial build failure fix for Sparc. (Bugs: #317145, #336970) Thanks to Jurij Smakov [EMAIL PROTECTED]. Files: 9243972564b4051bd3b87d3175ff458c 954 misc optional qemu_0.8.0-2.dsc 0a80a04dce2698d555f21f28b7d180b7 28596 misc optional qemu_0.8.0-2.diff.gz c52e8fb2281e7c9562454514734049da 2759948 misc optional qemu_0.8.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+XS2uW9ciZ2SjJsRAviSAKDQXqcNiQPgwLZVPcA+H+0rHjWkzQCeNBL6 /5PsKxojby7PAK6kAX8lIX4= =4p2e -END PGP SIGNATURE- Accepted: qemu_0.8.0-2.diff.gz to pool/main/q/qemu/qemu_0.8.0-2.diff.gz qemu_0.8.0-2.dsc to pool/main/q/qemu/qemu_0.8.0-2.dsc qemu_0.8.0-2_i386.deb to pool/main/q/qemu/qemu_0.8.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted denemo 0.7.4-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 08:56:16 +0100 Source: denemo Binary: denemo Architecture: source i386 Version: 0.7.4-2.1 Distribution: unstable Urgency: medium Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: denemo - A gtk+ frontend to GNU Lilypond Closes: 327680 352453 Changes: denemo (0.7.4-2.1) unstable; urgency=medium . * NMU. * Add a dependency on librsvg2-common to get the gdk-pixbuf loader for svg. Closes: #352453. * Remove build dependency on libasound2-dev; upstream dropped ALSA support. Closes: #327680. Files: cce36df7a694cfe28a7565ee56d083d3 695 sound optional denemo_0.7.4-2.1.dsc a96e3a413536f17c7a746964002edc84 9928 sound optional denemo_0.7.4-2.1.diff.gz 07981567cc2787e87d7868c137aee408 828262 sound optional denemo_0.7.4-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+Xb7xBYivKllgY8RAmVqAJ9TzTLCbdkntfDdY5WlGnIg4igtogCgmZu0 Vr7ImzrYSwznUt0FXdzJ8h0= =clAW -END PGP SIGNATURE- Accepted: denemo_0.7.4-2.1.diff.gz to pool/main/d/denemo/denemo_0.7.4-2.1.diff.gz denemo_0.7.4-2.1.dsc to pool/main/d/denemo/denemo_0.7.4-2.1.dsc denemo_0.7.4-2.1_i386.deb to pool/main/d/denemo/denemo_0.7.4-2.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gpm 1.19.6-22 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 09:58:55 +0200 Source: gpm Binary: libgpmg1 gpm libgpmg1-dev Architecture: source i386 Version: 1.19.6-22 Distribution: unstable Urgency: low Maintainer: Debian GPM Team [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: gpm- General Purpose Mouse Interface libgpmg1 - General Purpose Mouse - shared library libgpmg1-dev - General Purpose Mouse - development files Closes: 323949 338781 350968 Changes: gpm (1.19.6-22) unstable; urgency=low . [ Guillem Jover ] * Updated Vietnamese translation. (Closes: #323949) Thanks to Clytie Siddall [EMAIL PROTECTED]. * Switched to debhelper compat level 5. * Wrap lines in debian/control fields. * Document the arguments for Gpm_Event in the info file. (Closes: #350968) Thanks to James R. Van Zandt [EMAIL PROTECTED]. * Update FSF's address. . [ Peter Samuelson ] * Added Swedish translation. (Closes: #338781) Thanks to Daniel Nylander [EMAIL PROTECTED]. Files: 34231ce077dac1597af488adcda49271 734 misc optional gpm_1.19.6-22.dsc b2d910f671a7433d4b41f4f5172d89c7 69223 misc optional gpm_1.19.6-22.diff.gz b2df0e2d998157e3e2026e41e25587ff 212288 misc optional gpm_1.19.6-22_i386.deb f4c9e2b848e5ea406ab5ef9af81504b6 50412 libs standard libgpmg1_1.19.6-22_i386.deb 7c7f9a71f3edee88b5a02ab38cc29a0f 53156 libdevel optional libgpmg1-dev_1.19.6-22_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+XsJuW9ciZ2SjJsRAglPAJ9zJS4gemKXRVtH2SCqkxLggR8qYgCgrzzQ lB+T00l7WcWbfufVmQFEUY4= =7rbF -END PGP SIGNATURE- Accepted: gpm_1.19.6-22.diff.gz to pool/main/g/gpm/gpm_1.19.6-22.diff.gz gpm_1.19.6-22.dsc to pool/main/g/gpm/gpm_1.19.6-22.dsc gpm_1.19.6-22_i386.deb to pool/main/g/gpm/gpm_1.19.6-22_i386.deb libgpmg1-dev_1.19.6-22_i386.deb to pool/main/g/gpm/libgpmg1-dev_1.19.6-22_i386.deb libgpmg1_1.19.6-22_i386.deb to pool/main/g/gpm/libgpmg1_1.19.6-22_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnunet-gtk 0.7.0b-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 20 Feb 2006 09:11:50 +0100
Source: gnunet-gtk
Binary: gnunet-gtk
Architecture: source i386
Version: 0.7.0b-1.1
Distribution: unstable
Urgency: high
Maintainer: Arnaud Kyheng [EMAIL PROTECTED]
Changed-By: Matej Vela [EMAIL PROTECTED]
Description:
gnunet-gtk - GTK frontend to GNUnet
Closes: 350150
Changes:
gnunet-gtk (0.7.0b-1.1) unstable; urgency=high
.
* NMU.
* Replace hardcoded dependencies with ${shlibs:Depends}.
Closes: #350150.
Files:
9049ea3636ba85d5b0f15b570991c61b 786 net optional gnunet-gtk_0.7.0b-1.1.dsc
48d4e37fae660cef96f2ac1526c0c025 4014 net optional
gnunet-gtk_0.7.0b-1.1.diff.gz
e8ce75c1f1f610b4988a697f2651f727 145728 net optional
gnunet-gtk_0.7.0b-1.1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD+XrJxBYivKllgY8RAoFMAJ0WANFWxwutCuQxw2LTlip+OE5qQwCfX5Jk
hlMr33Syi8qq8VVSBqbVWd4=
=T9Sa
-END PGP SIGNATURE-
Accepted:
gnunet-gtk_0.7.0b-1.1.diff.gz
to pool/main/g/gnunet-gtk/gnunet-gtk_0.7.0b-1.1.diff.gz
gnunet-gtk_0.7.0b-1.1.dsc
to pool/main/g/gnunet-gtk/gnunet-gtk_0.7.0b-1.1.dsc
gnunet-gtk_0.7.0b-1.1_i386.deb
to pool/main/g/gnunet-gtk/gnunet-gtk_0.7.0b-1.1_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnuserv 3.12.7-1.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 09:42:19 +0100 Source: gnuserv Binary: gnuserv Architecture: source i386 Version: 3.12.7-1.2 Distribution: unstable Urgency: medium Maintainer: Benjamin Drieu [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: gnuserv- Allows you to attach to an already running Emacs Closes: 349554 Changes: gnuserv (3.12.7-1.2) unstable; urgency=medium . * NMU. * Add a build dependency on libxt-dev to placate configure. Closes: #349554. Files: 620e8ee304b27c85a07fd86bca9ff2b6 599 editors optional gnuserv_3.12.7-1.2.dsc c3d04a27890b7de22f969059236de982 15024 editors optional gnuserv_3.12.7-1.2.diff.gz 99c8a4e526e36da7571d94c1e4f70efe 53974 editors optional gnuserv_3.12.7-1.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+YE2xBYivKllgY8RAuKxAKCYq/Nja15oMcGg293Lk9wV/iYDWwCdGsL9 gyP70BNJuSuZJ8MDiAi++xI= =tggN -END PGP SIGNATURE- Accepted: gnuserv_3.12.7-1.2.diff.gz to pool/main/g/gnuserv/gnuserv_3.12.7-1.2.diff.gz gnuserv_3.12.7-1.2.dsc to pool/main/g/gnuserv/gnuserv_3.12.7-1.2.dsc gnuserv_3.12.7-1.2_i386.deb to pool/main/g/gnuserv/gnuserv_3.12.7-1.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnurobots 1:1.0D-6.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 09:27:51 +0100 Source: gnurobots Binary: gnurobots Architecture: source i386 Version: 1:1.0D-6.2 Distribution: unstable Urgency: medium Maintainer: James LewisMoss [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: gnurobots - Program a robot to explore a world Closes: 351950 Changes: gnurobots (1:1.0D-6.2) unstable; urgency=medium . * NMU. * Build-depend on guile-1.6-dev instead of libguile-dev. Closes: #351950. Files: e0fb7a5601677c371f87ee662500e19a 648 games optional gnurobots_1.0D-6.2.dsc 76687c1c2103c68e2dd393f9e79d088b 21126 games optional gnurobots_1.0D-6.2.diff.gz 90080859a7b7e1b20f8f5907c7faf728 46620 games optional gnurobots_1.0D-6.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+X4gxBYivKllgY8RAsCcAJ4ytw64JNd/vLMfz/niLJSen7ACCACcCW27 PTAFCz86oSWfuUc3kSK7+S4= =y4Bo -END PGP SIGNATURE- Accepted: gnurobots_1.0D-6.2.diff.gz to pool/main/g/gnurobots/gnurobots_1.0D-6.2.diff.gz gnurobots_1.0D-6.2.dsc to pool/main/g/gnurobots/gnurobots_1.0D-6.2.dsc gnurobots_1.0D-6.2_i386.deb to pool/main/g/gnurobots/gnurobots_1.0D-6.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asclassic 1.1b-28.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 09:55:21 +0100 Source: asclassic Binary: asclassic Architecture: source i386 Version: 1.1b-28.2 Distribution: unstable Urgency: medium Maintainer: Taketoshi Sano [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: asclassic - X11 window manager, AfterStep Classic (forked from v1.1) Closes: 350782 Changes: asclassic (1.1b-28.2) unstable; urgency=medium . * NMU. * afterstep/alpha_header.h: Rely on sys/select.h and string.h for declarations of select(2) and strlen(3) respectively. Closes: #350782. Files: eb6ddb42b12be2786854c0e4e509d5fe 645 x11 optional asclassic_1.1b-28.2.dsc 90502fc6cba56736f44d773c27e2b9e3 77922 x11 optional asclassic_1.1b-28.2.diff.gz 426e6e2837a89c5fb89e132463589418 533372 x11 optional asclassic_1.1b-28.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+YRKxBYivKllgY8RAqTxAKCRnglrqdg9XSUYzbFtLYZLws4nxwCdGGdH nh2QeyMQkFAMdSjetRQjz6k= =n8aB -END PGP SIGNATURE- Accepted: asclassic_1.1b-28.2.diff.gz to pool/main/a/asclassic/asclassic_1.1b-28.2.diff.gz asclassic_1.1b-28.2.dsc to pool/main/a/asclassic/asclassic_1.1b-28.2.dsc asclassic_1.1b-28.2_i386.deb to pool/main/a/asclassic/asclassic_1.1b-28.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gpsdrive 2.09-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 01:00:45 -0800 Source: gpsdrive Binary: gpsdrive Architecture: source i386 Version: 2.09-2.1 Distribution: unstable Urgency: low Maintainer: Frank Kirschner [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: gpsdrive - Car navigation system Closes: 343815 Changes: gpsdrive (2.09-2.1) unstable; urgency=low . * Non-maintainer upload. * Build-depend on libmysqlclient15-dev instead of the obsolete libmysqlclient10-dev which should be removed for etch; requires minor source changes due to changed library name and a small ABI change. Closes: #343815. Files: f9588456c3dfdb0fe1d097512461b576 642 utils optional gpsdrive_2.09-2.1.dsc 8b90061dbfb9f24cfe59b6cfbf004323 6524 utils optional gpsdrive_2.09-2.1.diff.gz c34135a362333dfddd448851bd00a8ee 1297704 utils optional gpsdrive_2.09-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+ZJvKN6ufymYLloRAlWpAKDM1NtrMDP6+4OIvqy1w53RwIOezwCfdLNb NE5p72UYLUQW3a2+QPdK7Ys= =aHuY -END PGP SIGNATURE- Accepted: gpsdrive_2.09-2.1.diff.gz to pool/main/g/gpsdrive/gpsdrive_2.09-2.1.diff.gz gpsdrive_2.09-2.1.dsc to pool/main/g/gpsdrive/gpsdrive_2.09-2.1.dsc gpsdrive_2.09-2.1_i386.deb to pool/main/g/gpsdrive/gpsdrive_2.09-2.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ddskk 13.0.90.cvs20060220-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 19:03:42 +0900 Source: ddskk Binary: ddskk Architecture: source all Version: 13.0.90.cvs20060220-1 Distribution: unstable Urgency: low Maintainer: Kenshi Muto [EMAIL PROTECTED] Changed-By: Kenshi Muto [EMAIL PROTECTED] Description: ddskk - Simple Kana to Kanji conversion program Closes: 270053 322844 353630 Changes: ddskk (13.0.90.cvs20060220-1) unstable; urgency=low . * New upstream release (cvs snapshot 2006.02.20 version) - Now it supports emacs-snapshot (closes: #322844) * New Maintainer (closes: #353630) * Supports xemacs21-gnome-*. (closes: #270053) Files: 0ec7e85519c17fc60ed092ec7731ac81 662 utils optional ddskk_13.0.90.cvs20060220-1.dsc 8cbd1dc619279c5f29827e4eb7566cbe 683551 utils optional ddskk_13.0.90.cvs20060220.orig.tar.gz 69aa9a4f35edcf3cb6f30b04aa8bec75 7241 utils optional ddskk_13.0.90.cvs20060220-1.diff.gz 86c23ca4a892fba9467d16f39fc888c5 569008 utils optional ddskk_13.0.90.cvs20060220-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iEYEARECAAYFAkP5lp0ACgkQQKW+7XLQPLELwwCdGHPhQznF284o7TUhelRGddjv p8wAn2yU5j+BnC5DOzJfc8AOFQPfgvmG =PEZL -END PGP SIGNATURE- Accepted: ddskk_13.0.90.cvs20060220-1.diff.gz to pool/main/d/ddskk/ddskk_13.0.90.cvs20060220-1.diff.gz ddskk_13.0.90.cvs20060220-1.dsc to pool/main/d/ddskk/ddskk_13.0.90.cvs20060220-1.dsc ddskk_13.0.90.cvs20060220-1_all.deb to pool/main/d/ddskk/ddskk_13.0.90.cvs20060220-1_all.deb ddskk_13.0.90.cvs20060220.orig.tar.gz to pool/main/d/ddskk/ddskk_13.0.90.cvs20060220.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mapserver 4.8.1-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 11:10:25 +0100 Source: mapserver Binary: mapserver-doc perl-mapscript mapserver-bin cgi-mapserver php5-mapscript python-mapscript php4-mapscript Architecture: source all i386 Version: 4.8.1-2 Distribution: unstable Urgency: low Maintainer: Debian GIS Project pkg-grass-devel@lists.alioth.debian.org Changed-By: Petter Reinholdtsen [EMAIL PROTECTED] Description: cgi-mapserver - cgi module of mapserver mapserver-bin - mapserver binary utilities mapserver-doc - documentation for mapserver perl-mapscript - perl mapserver library php4-mapscript - module for php4-cgi to use mapserver php5-mapscript - module for php5-cgi to use mapserver python-mapscript - python mapserver lib Changes: mapserver (4.8.1-2) unstable; urgency=low . [ Paul Wise ] * Make the build target no longer depend on build-indep. This is not policy-compliant (see 7.6 and 4.8), but it is needed to work around the fact that the autobuilders call debian/rules build (instead of build-arch), but do not install Build-Depends-Indep packages. build-indep is an indirect dependency of the binary and binary-indep targets, so non-autobuilder builds will still work. Files: 8b08132d0154370561ba29a2a0ed9fab 1197 devel optional mapserver_4.8.1-2.dsc c6cc18e02a267345a619402991c37fb4 17175 devel optional mapserver_4.8.1-2.diff.gz 58ea0fb43725227cf85800ccdaa24974 88080 doc optional mapserver-doc_4.8.1-2_all.deb 2b4cfd9cadaa6bca693c077ff0aaa1cb 510110 web optional php4-mapscript_4.8.1-2_i386.deb d85c75d92686575b5986fb10e4a347d4 510094 web optional php5-mapscript_4.8.1-2_i386.deb fc18d3badba9a0110973802cad3bc466 697410 perl optional perl-mapscript_4.8.1-2_i386.deb 85181cd398bc02ea7313a838aacebdc6 422386 web optional cgi-mapserver_4.8.1-2_i386.deb 7701b8930d51ece9cd516d43a09c29ec 541342 python optional python-mapscript_4.8.1-2_i386.deb 57ec08fed06097ac2130da810d556243 2715496 misc optional mapserver-bin_4.8.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+Zls20zMSyow1ykRAkzvAKDEsG+d7G6D2d2fR8GrnHtihGxJ+ACghHM2 WP8duz6e/FW3Mxb41mjKNA8= =w59i -END PGP SIGNATURE- Accepted: cgi-mapserver_4.8.1-2_i386.deb to pool/main/m/mapserver/cgi-mapserver_4.8.1-2_i386.deb mapserver-bin_4.8.1-2_i386.deb to pool/main/m/mapserver/mapserver-bin_4.8.1-2_i386.deb mapserver-doc_4.8.1-2_all.deb to pool/main/m/mapserver/mapserver-doc_4.8.1-2_all.deb mapserver_4.8.1-2.diff.gz to pool/main/m/mapserver/mapserver_4.8.1-2.diff.gz mapserver_4.8.1-2.dsc to pool/main/m/mapserver/mapserver_4.8.1-2.dsc perl-mapscript_4.8.1-2_i386.deb to pool/main/m/mapserver/perl-mapscript_4.8.1-2_i386.deb php4-mapscript_4.8.1-2_i386.deb to pool/main/m/mapserver/php4-mapscript_4.8.1-2_i386.deb php5-mapscript_4.8.1-2_i386.deb to pool/main/m/mapserver/php5-mapscript_4.8.1-2_i386.deb python-mapscript_4.8.1-2_i386.deb to pool/main/m/mapserver/python-mapscript_4.8.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quotatool 1.4.9-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 11:19:16 +0100 Source: quotatool Binary: quotatool Architecture: source i386 Version: 1.4.9-1 Distribution: unstable Urgency: low Maintainer: Bas Zoetekouw [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: quotatool - tool to edit disk quotas from the command line Changes: quotatool (1.4.9-1) unstable; urgency=low . * New upstream release - Fixed a bug when fetching XFS quota for a user/group with no current usage/quota * Added a watch file (for real, this time ;) ) * Moved from debhelper 3 to debhelper 5 Files: 3c8fcf731cce0532998b6eae5dfc357e 577 admin extra quotatool_1.4.9-1.dsc ad5fbae6d902fec8a9d166591973bcfa 113541 admin extra quotatool_1.4.9.orig.tar.gz 1b44da83c3c0c6c002227b676f74fd4a 2464 admin extra quotatool_1.4.9-1.diff.gz 867099c553539b606f0b72f52f6531d9 17060 admin extra quotatool_1.4.9-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+ZnfK67kHwZE+rcRAu8fAJ9XsF+ATj7+ue8pRZKKcbfwlX+2qACbBsWd +jQvRjpNqpwbSIIIVz6s8Ps= =wESP -END PGP SIGNATURE- Accepted: quotatool_1.4.9-1.diff.gz to pool/main/q/quotatool/quotatool_1.4.9-1.diff.gz quotatool_1.4.9-1.dsc to pool/main/q/quotatool/quotatool_1.4.9-1.dsc quotatool_1.4.9-1_i386.deb to pool/main/q/quotatool/quotatool_1.4.9-1_i386.deb quotatool_1.4.9.orig.tar.gz to pool/main/q/quotatool/quotatool_1.4.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sagasu 2.0.8-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Feb 2006 03:09:19 +0100 Source: sagasu Binary: sagasu Architecture: source i386 Version: 2.0.8-1 Distribution: unstable Urgency: low Maintainer: Daniel Gubser [EMAIL PROTECTED] Changed-By: Daniel Gubser [EMAIL PROTECTED] Description: sagasu - GNOME tool to find strings in a set of files Closes: 327319 336000 Changes: sagasu (2.0.8-1) unstable; urgency=low . * New upstream release (Closes: #336000) * compiles now with GNOME 2.12 (Closes: #327319) Files: d2d3b52c1981322da395282574291c57 580 utils optional sagasu_2.0.8-1.dsc cd3b451748102f5cc7dd1a1b3db865eb 288667 utils optional sagasu_2.0.8.orig.tar.gz 0c1939593e970f4a686f22fe9c8bf0a2 2351 utils optional sagasu_2.0.8-1.diff.gz 54e627ac098ab1df491297a88deb9ceb 94176 utils optional sagasu_2.0.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD99v3NgbFFFW/0CQRAiqDAKCfJa+VEMfz03/bzzaYDuccRoTosACgqfyq knCMdFlqkxnFt48oP9E9QKM= =56ja -END PGP SIGNATURE- Accepted: sagasu_2.0.8-1.diff.gz to pool/main/s/sagasu/sagasu_2.0.8-1.diff.gz sagasu_2.0.8-1.dsc to pool/main/s/sagasu/sagasu_2.0.8-1.dsc sagasu_2.0.8-1_i386.deb to pool/main/s/sagasu/sagasu_2.0.8-1_i386.deb sagasu_2.0.8.orig.tar.gz to pool/main/s/sagasu/sagasu_2.0.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtkboard 0.11pre0-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 10:30:45 + Source: gtkboard Binary: gtkboard Architecture: source i386 Version: 0.11pre0-5 Distribution: unstable Urgency: low Maintainer: Barak A. Pearlmutter [EMAIL PROTECTED] Changed-By: Barak A. Pearlmutter [EMAIL PROTECTED] Description: gtkboard - many board games in one program Closes: 333118 Changes: gtkboard (0.11pre0-5) unstable; urgency=low . * Accept patch; thanks to Steve Langasek and Matej Vela! (closes: #333118) Files: 7b1bbf87349fa387f26c2f826fb1abb9 647 games optional gtkboard_0.11pre0-5.dsc 5604cc38abf2617dc2b5274b2b9dec10 26067 games optional gtkboard_0.11pre0-5.diff.gz 91790d1bfb20390a19e45aea62d2c4fd 344530 games optional gtkboard_0.11pre0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD+aKKLz4Gnv7CP7IRAukEAKCrVG6jdUp1/vdWHcEVhYcqNiCIGgCg40NT QaShTzPd8v0f1uWGk2HR4P8= =NNcr -END PGP SIGNATURE- Accepted: gtkboard_0.11pre0-5.diff.gz to pool/main/g/gtkboard/gtkboard_0.11pre0-5.diff.gz gtkboard_0.11pre0-5.dsc to pool/main/g/gtkboard/gtkboard_0.11pre0-5.dsc gtkboard_0.11pre0-5_i386.deb to pool/main/g/gtkboard/gtkboard_0.11pre0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tioga 1.0.L-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 11 Feb 2006 14:33:18 +0100 Source: tioga Binary: tioga Architecture: source i386 Version: 1.0.L-1 Distribution: unstable Urgency: low Maintainer: Vincent Fourmond [EMAIL PROTECTED] Changed-By: Vincent Fourmond [EMAIL PROTECTED] Description: tioga - A fantastic ruby library for scientific graphes Closes: 346373 352309 Changes: tioga (1.0.L-1) unstable; urgency=low . * New upstream release (few bug fixes, few more features). * Second upload to debian (Closes: #346373) (the first wasn't seen by the BTS...) * Fix debian/control to Build-Depend on ruby1.8 (Closes: #352309) Files: 452982ee08542a45e7ce2d12d2018069 589 graphics optional tioga_1.0.L-1.dsc 3eec0a7db8c78155eae18ce498c9527b 1370126 graphics optional tioga_1.0.L.orig.tar.gz 449796afcdd25261f42eeb47e3041a63 4441 graphics optional tioga_1.0.L-1.diff.gz 059f740d4d7e77808d33c918b57b678b 555756 graphics optional tioga_1.0.L-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+aWUbJef3kTiKs0RAtYNAJ405fiCd84hH7ftir4jlw2xw4dncgCfZ3Y1 +wXW2KpLefIxsCgfEzfH1Ow= =bsgf -END PGP SIGNATURE- Accepted: tioga_1.0.L-1.diff.gz to pool/main/t/tioga/tioga_1.0.L-1.diff.gz tioga_1.0.L-1.dsc to pool/main/t/tioga/tioga_1.0.L-1.dsc tioga_1.0.L-1_i386.deb to pool/main/t/tioga/tioga_1.0.L-1_i386.deb tioga_1.0.L.orig.tar.gz to pool/main/t/tioga/tioga_1.0.L.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mondo 2.06-3 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 18 Feb 2006 19:45:11 +1100 Source: mondo Binary: mondo-doc mondo Architecture: source i386 all Version: 2.06-3 Distribution: unstable Urgency: low Maintainer: Andree Leidenfrost [EMAIL PROTECTED] Changed-By: Andree Leidenfrost [EMAIL PROTECTED] Description: mondo - powerful disaster recovery suite mondo-doc - manual for Mondo, a powerful disaster recovery suite Closes: 352323 Changes: mondo (2.06-3) unstable; urgency=low . * Removed cruft from source package: make.log. * Removed dependencies on dosfstools and binutils as mindi depends on them now. Changed dependency on mindi to (= 1.06-3) accordingly. * If calling 'mindi ---findkernel' return anything, check whether mindi encountered a fatal error and if so show it using function popup_and_OK(). This helps making the actual problem more visible in situations like the one reported in #352323. Note that the fix for #352323 also requires changes in mindi which are in 1.06-3 which we already depend on. (Committed upstream.) (Closes: #352323.) * Added '#define _LARGEFILE_SOURCE' and '#define _FILE_OFFSET_BITS 64' in various places to allow for processing of files larger 2GB. Replaced lseek() with lseeko() for the same reason (one one occurrence). Files: 8455e850f44a2735c9d02fa969c177ce 691 utils optional mondo_2.06-3.dsc 5fa23c3aa502077d189e33aafba8f194 27414 utils optional mondo_2.06-3.diff.gz 65d49a7dff1e347529307e0432491702 511128 utils optional mondo_2.06-3_i386.deb 487012b19ee78e2a8c4e6dc7cd76bd6c 410486 doc optional mondo-doc_2.06-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+ao1NFDtUT/MKpARAvcBAKC7kV3IVgsTXuJNuKLwFoerN0nKNgCg0Vp5 PegXLQhND90qKHrgBYhXN+o= =f4ax -END PGP SIGNATURE- Accepted: mondo-doc_2.06-3_all.deb to pool/main/m/mondo/mondo-doc_2.06-3_all.deb mondo_2.06-3.diff.gz to pool/main/m/mondo/mondo_2.06-3.diff.gz mondo_2.06-3.dsc to pool/main/m/mondo/mondo_2.06-3.dsc mondo_2.06-3_i386.deb to pool/main/m/mondo/mondo_2.06-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mindi 1.06-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Feb 2006 23:09:16 +1100 Source: mindi Binary: mindi Architecture: source i386 Version: 1.06-3 Distribution: unstable Urgency: low Maintainer: Andree Leidenfrost [EMAIL PROTECTED] Changed-By: Andree Leidenfrost [EMAIL PROTECTED] Description: mindi - creates boot/root disks based on your system Closes: 348966 351446 Changes: mindi (1.06-3) unstable; urgency=low . * Fixed mindi so that it only deletes freshly created 1440kb boot and root floppy images if creation finished with an error. (Committed upstream.) (Closes: #348966.) * Depend on dosfstools and binutils to avoid errors as also reported in above bug report. * Mention mindi parameter FORCE_DUAL_FLOPPIES in README.Debian to help in situations like the one in the above bug report. * Get mindi to look for analyze-my-lvm in it's library directory MINDI_LIB rather than the path. analyze-my-lvm should not be moved into path because it is only useful to mindi and does not have a manpage. (Committed upstream.) (Closes: #351446.) * Changed DebFindFailsafe from an independent script into a code snippet that gets sourced in by mindi. Use mindi's Die function for better error reporting and improve error texts. (Required to fix #352323.) * Recommend mdadm, remove all raidtools-related entries from Debian deplist.txt file and add mdadm and mdrun instead. Files: 0051729cf726e2867caf47410ef611bf 661 utils optional mindi_1.06-3.dsc a59c56ace2dfeb7fccbb240c9b163c74 19426 utils optional mindi_1.06-3.diff.gz b3c5a3f7fbb515c587bd1a4cf0c5e065 150286 utils optional mindi_1.06-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+aonNFDtUT/MKpARArD5AKCCo2N+9qDM0+2i+pSqRnoqkbyhngCgto2T sklCY/MTdfVRzwkCwd6FYAI= =BAM4 -END PGP SIGNATURE- Accepted: mindi_1.06-3.diff.gz to pool/main/m/mindi/mindi_1.06-3.diff.gz mindi_1.06-3.dsc to pool/main/m/mindi/mindi_1.06-3.dsc mindi_1.06-3_i386.deb to pool/main/m/mindi/mindi_1.06-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vlock 1.3-9 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 12:42:06 +0100 Source: vlock Binary: vlock Architecture: source i386 Version: 1.3-9 Distribution: unstable Urgency: low Maintainer: Peter Palfrader [EMAIL PROTECTED] Changed-By: Peter Palfrader [EMAIL PROTECTED] Description: vlock - Virtual Console locking program Closes: 321755 Changes: vlock (1.3-9) unstable; urgency=low . * New Maintainer/Uploaders (closes: #321755). * Use debhelper compatibility level 4 instead of level 2. Accordingly adapted the build time dependencies. * debian/rules cleanup: - removing commented out dh_make cruft, - use rm -f .. instead of -rm .., - change to new chown syntax of chown user:group, replacing user.group. - comment out DH_VERBOSE=1 * Remove debian/conffiles. It only contained etc/pam.d/vlock, which is marked as conffile by debhelper automatically. * Increased standards version from 3.5.7.0 to 3.6.2 (no changes necessary). * Rename debian/docs to debian/vlock.docs to be consistent with debian/vlock.dirs. * Fix debian/changelog: Parts have been duplicated in a previous version, clean up the mess. * Add myself to debian/copyright. * Update the address of the Free Software Foundation in debian/copyright. * Add lintian override for vlock being suid root. * Use dh_install instead of install to copy the vlock binary in place. This way we support DEB_BUILD_OPTIONS=nostrip. * Remove vlock.man in clean target as it's build by upstream's Makefile anyway and we don't need it in the diff. * Do not build vlock.man during build. Files: fdff05836f6d4d690fa61fe77b85189d 681 utils optional vlock_1.3-9.dsc 07177c6988cf162e7794aa28dfaabc33 7072 utils optional vlock_1.3-9.diff.gz 3cd0ffecd4641dce794798aad7ccad97 14618 utils optional vlock_1.3-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3-cvs (GNU/Linux) iD8DBQFD+av4z/ccs6+kS90RAvVAAJ9D1sHT/yoHXQ4FQq6llbGMqvK7QgCfcvNH qN09cpF53uvmxb707+IBtyc= =vbbu -END PGP SIGNATURE- Accepted: vlock_1.3-9.diff.gz to pool/main/v/vlock/vlock_1.3-9.diff.gz vlock_1.3-9.dsc to pool/main/v/vlock/vlock_1.3-9.dsc vlock_1.3-9_i386.deb to pool/main/v/vlock/vlock_1.3-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted logilab-common 0.13.1-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 11:13:22 +0100 Source: logilab-common Binary: python-logilab-common Architecture: source all Version: 0.13.1-4 Distribution: unstable Urgency: low Maintainer: Alexandre Fayolle [EMAIL PROTECTED] Changed-By: Alexandre Fayolle [EMAIL PROTECTED] Description: python-logilab-common - useful miscellaneous modules used by Logilab projects Closes: 353512 Changes: logilab-common (0.13.1-4) unstable; urgency=low . * Force removal of /usr/lib/python2.?/site-packages/logilab/__init__.py* (closes: #353512) * Add Conflicts with version of packages installing modules in subdirectories of /usr/lib/python2.?/site-packages/logilab/ Files: ff5598cd4b03c3b76d5a6fc4e3811808 908 python optional logilab-common_0.13.1-4.dsc df1ec85690c956d787f14efdf08eae24 4238 python optional logilab-common_0.13.1-4.diff.gz df2fc863f8aad830c8ebd2776dce2678 95638 python optional python-logilab-common_0.13.1-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ/mjn16T+PKoJ87eAQK2kAgAmGlyaM9W3E+AGqIrUXWrbKM/GJlChh1P EAguNHqY3Cdu3rT9KiIabSa0zckTxzOWooGhXbDFiHKLoLT02e6fnrrVye9wDdxT 6kbuTc3RrGyOL1Xt3gasWeDmf8ASxnungNvcSwhwymPnQvig1Yh59xNrrT6S3RQI AczK7DEqIRp9yADyvMjAd/i7UKQPB+mMyQtXl0zACK0Dte9klsZcxl7Ry5c2kv2m 2Px34e3DaIPDbAjfSsK8tpDFyce7pN5iIcrlXzX1lnGcNDoq1LSfHYRCgoZsXWGg 6kT8w9vtUgw3TztLuZe7mbX+4YwwCQIfcguRSC9X5h0S2Mr+e02Vnw== =aRke -END PGP SIGNATURE- Accepted: logilab-common_0.13.1-4.diff.gz to pool/main/l/logilab-common/logilab-common_0.13.1-4.diff.gz logilab-common_0.13.1-4.dsc to pool/main/l/logilab-common/logilab-common_0.13.1-4.dsc python-logilab-common_0.13.1-4_all.deb to pool/main/l/logilab-common/python-logilab-common_0.13.1-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libimdb-film-perl 0.18-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 13:45:10 +0100 Source: libimdb-film-perl Binary: libimdb-film-perl Architecture: source all Version: 0.18-1 Distribution: unstable Urgency: low Maintainer: Bas Zoetekouw [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: libimdb-film-perl - Perl extension for retrieving movie info from IMDB.com Changes: libimdb-film-perl (0.18-1) unstable; urgency=low . * New upstream release: - fixed a bug with retrieving ID of writers - fixed a bug with retrieving a list of writers if there is a link 'more' - fixed a documentation of method 'awards' * Added a watch file * Moved from debhelper version 4 to version 5 compatibility * Cleaned up debian/rules a bit Files: 9a4fd88a5fff943c2fdd30b8dfeed30d 629 perl optional libimdb-film-perl_0.18-1.dsc 65992c6cd092c9dec229384e1625ad2b 45838 perl optional libimdb-film-perl_0.18.orig.tar.gz 5246787efad3aba2567cab3a424e8d7b 2020 perl optional libimdb-film-perl_0.18-1.diff.gz 772e0a5bb3b17ee3936fe22ee199c380 24398 perl optional libimdb-film-perl_0.18-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+buZK67kHwZE+rcRAtg9AJ9wBjIjf+1fgguEkarMhFbu6iKLGACfXZe+ FFE34oamPV16iA1qlxKPELs= =gE60 -END PGP SIGNATURE- Accepted: libimdb-film-perl_0.18-1.diff.gz to pool/main/libi/libimdb-film-perl/libimdb-film-perl_0.18-1.diff.gz libimdb-film-perl_0.18-1.dsc to pool/main/libi/libimdb-film-perl/libimdb-film-perl_0.18-1.dsc libimdb-film-perl_0.18-1_all.deb to pool/main/libi/libimdb-film-perl/libimdb-film-perl_0.18-1_all.deb libimdb-film-perl_0.18.orig.tar.gz to pool/main/libi/libimdb-film-perl/libimdb-film-perl_0.18.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted initramfs-tools 0.52b (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 13:30:54 +0100 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.52b Distribution: unstable Urgency: high Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: initramfs-tools - tools for generating an initramfs Closes: 351939 352633 353087 353668 Changes: initramfs-tools (0.52b) unstable; urgency=high . * update-initramfs: Set takeover=1. This allows hooks to regenerate the latest initramfs per default. No need for an kpkg wrapper, as kernel-package doesn't call update-initramfs, but mkinitramfs. . initramfs-tools (0.52) unstable; urgency=low . * hooks/lvm: manual_add_modules dm_snapshot, will allow boot from lvm snapshot. . * init: Fix maybe_break test for the bottom stage. . * scripts/init-premount/udev-helper: Renamed from scripts/init-premount/ide. . * update-initramfs: s/was/has/ been altered. (closes: #351939, #352633, #353087, #353668) . * update-initramfs(8), mkinitramfs(8): The point of the first is to be used on your local box. Highlight its mode of operations. The second cmd is only needed for advanced usage. Files: a51bf3090f09c593cfb7850b4d84ba30 631 utils optional initramfs-tools_0.52b.dsc af864cec41d5128e9eae4b7a1bb6656e 33178 utils optional initramfs-tools_0.52b.tar.gz b2535444829f57adf9e111471742473c 37520 utils optional initramfs-tools_0.52b_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+cbU6n7So0GVSSARAi8CAJwIel601satW8JdYqD6ynvO6Rm1zwCeJSsx drwLw1eWboaHkVynOw3vBB0= =8KyW -END PGP SIGNATURE- Accepted: initramfs-tools_0.52b.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.52b.dsc initramfs-tools_0.52b.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.52b.tar.gz initramfs-tools_0.52b_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.52b_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdbix-class-perl 0.05.006-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 14:34:55 +0100 Source: libdbix-class-perl Binary: libdbix-class-perl Architecture: source all Version: 0.05.006-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libdbix-class-perl - Extensible and flexible object - relational mapper Changes: libdbix-class-perl (0.05.006-1) unstable; urgency=low . * New upstream release * debian/control - libmodule-find-perl removed from dependencies, libdatetime added to Build-Depends-Indep Files: 1b0e7814275ce84fbdcad6563fb79177 1213 perl optional libdbix-class-perl_0.05.006-1.dsc fb9d8a3e08484a7e95164f70591f0114 102821 perl optional libdbix-class-perl_0.05.006.orig.tar.gz 9f36f3354dd9c0b1cd26245bfb53feb2 2747 perl optional libdbix-class-perl_0.05.006-1.diff.gz 1cec1ce0ed1ec7c872950e2e37d2e235 169908 perl optional libdbix-class-perl_0.05.006-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+c1I+NMfSd6w7DERAm//AKCOKlXR6MpPTRkbhltMFWimAwmb3ACeJXjq spMLZ0ayE2FMPhtjTvfhnrY= =CHod -END PGP SIGNATURE- Accepted: libdbix-class-perl_0.05.006-1.diff.gz to pool/main/libd/libdbix-class-perl/libdbix-class-perl_0.05.006-1.diff.gz libdbix-class-perl_0.05.006-1.dsc to pool/main/libd/libdbix-class-perl/libdbix-class-perl_0.05.006-1.dsc libdbix-class-perl_0.05.006-1_all.deb to pool/main/libd/libdbix-class-perl/libdbix-class-perl_0.05.006-1_all.deb libdbix-class-perl_0.05.006.orig.tar.gz to pool/main/libd/libdbix-class-perl/libdbix-class-perl_0.05.006.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grande 0.6-7.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 15:13:44 +0100 Source: grande Binary: grande Architecture: source i386 Version: 0.6-7.1 Distribution: unstable Urgency: medium Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: grande - vertical shoot'em-up in the spirit of Xevious Closes: 350290 Changes: grande (0.6-7.1) unstable; urgency=medium . * NMU. * src/load.c, src/ranking.c: Really fix scanf formats. Closes: #350290. Files: a9aace42843a12b672bbf558c0dc0ff5 607 games optional grande_0.6-7.1.dsc 51d7282589448dd4756168bbf7b7c56a 24101 games optional grande_0.6-7.1.diff.gz 8f6f89da2bfdb850b3d6fc4aba7d8140 207022 games optional grande_0.6-7.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+c9OxBYivKllgY8RAoBzAJ9+0zFwKCMGPJuQ3ASX12HxxI4FfACg4pNY VFXvHYUnRg6t9IX1zxBAENs= =peCW -END PGP SIGNATURE- Accepted: grande_0.6-7.1.diff.gz to pool/main/g/grande/grande_0.6-7.1.diff.gz grande_0.6-7.1.dsc to pool/main/g/grande/grande_0.6-7.1.dsc grande_0.6-7.1_i386.deb to pool/main/g/grande/grande_0.6-7.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debsums 2.0.27 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 21 Feb 2006 01:38:36 +1100 Source: debsums Binary: debsums Architecture: source all Version: 2.0.27 Distribution: unstable Urgency: low Maintainer: Brendan O'Dea [EMAIL PROTECTED] Changed-By: Brendan O'Dea [EMAIL PROTECTED] Description: debsums- Verify installed package files against MD5 checksums. Closes: 353604 Changes: debsums (2.0.27) unstable; urgency=low . * Include Swedish translation from Daniel Nylander (closes: #353604). Files: 217a24861e22c048113fcb5f561dee78 496 admin optional debsums_2.0.27.dsc 01516e3f494bee0c2b8e4d79c44e9d0f 33414 admin optional debsums_2.0.27.tar.gz 1fafafa2882c10381e21640375a84ab0 29950 admin optional debsums_2.0.27_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+dVw8NyOALKMWZURAlZtAJ9dQHa6uzEQWMTKE1LAH3HU+1OeMwCghqSA 8OcsfSWQmp9i5o3ejID+Kt4= =patX -END PGP SIGNATURE- Accepted: debsums_2.0.27.dsc to pool/main/d/debsums/debsums_2.0.27.dsc debsums_2.0.27.tar.gz to pool/main/d/debsums/debsums_2.0.27.tar.gz debsums_2.0.27_all.deb to pool/main/d/debsums/debsums_2.0.27_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-engine-apache-perl 1.07-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 15:25:11 +0100 Source: libcatalyst-engine-apache-perl Binary: libcatalyst-engine-apache-perl Architecture: source all Version: 1.07-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libcatalyst-engine-apache-perl - Base class for Apache 1.99x and 2.x Catalyst engines Changes: libcatalyst-engine-apache-perl (1.07-1) unstable; urgency=low . * New upstream release Files: 41da3a8185b3fef968368d81b4e65b7f 855 perl optional libcatalyst-engine-apache-perl_1.07-1.dsc df6de0afe8496db091f3a7df6603a830 19457 perl optional libcatalyst-engine-apache-perl_1.07.orig.tar.gz f440a9bf6825b838ad31ec8df011183d 2482 perl optional libcatalyst-engine-apache-perl_1.07-1.diff.gz 2ff55f48beeb1468c3a9a835d878d10b 20690 perl optional libcatalyst-engine-apache-perl_1.07-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+dGj+NMfSd6w7DERAvFVAJ0WaCPfzny+QOZYYjktlO70lW/RzwCdEYYn 7BGwVZADoo91clTAD9VUJG0= =1VY8 -END PGP SIGNATURE- Accepted: libcatalyst-engine-apache-perl_1.07-1.diff.gz to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.07-1.diff.gz libcatalyst-engine-apache-perl_1.07-1.dsc to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.07-1.dsc libcatalyst-engine-apache-perl_1.07-1_all.deb to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.07-1_all.deb libcatalyst-engine-apache-perl_1.07.orig.tar.gz to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.07.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
