fichiers desktop
Bonjour, Je me pose des petites questions au sujet des fichiers desktop. Dans quel cas faut-il prévoir l'installation voir la création de ces fichiers? Est-ce valable uniquement pour des applis gnome ou kde (...)? Faut-il respecter la même arborescence (ex Apps\games\... que celle définie pour les menus debian? Comment gère t-on l'internationalisation de ces fichiers? Merci d'avance pour votre aide. Alexandre
Re: fichiers desktop
Le Wed, Oct 25, 2006 at 10:48:17PM +0200, Alexandre Pineau a écrit : Bonjour, Je me pose des petites questions au sujet des fichiers desktop. Dans quel cas faut-il prévoir l'installation voir la création de ces fichiers? Est-ce valable uniquement pour des applis gnome ou kde (...)? Faut-il respecter la même arborescence (ex Apps\games\... que celle définie pour les menus debian? Comment gère t-on l'internationalisation de ces fichiers? Bonjour, Il me semble que Debian n'a pas de recommandation officielle à ce sujet. Par contre, chez Ubuntu, c'est un bug de ne pas fournir un fichier desktop, quelle que soit l'origine des applications. En conséquence, il y a eu un gros effort de mise en conformité, et on peut retrouver ces fichiers dans les patches Ubuntu disponible à travers le PTS le cas échéant. Sur la liste Ubuntu-science, j'ai essayé de sensibiliser au respect des licences lorsqu'ils s'agissait de créer une icône (une entrée sans icône dans un menu GNOME, ça fait un trou...), car prendre un png sur une page web s'il n'y a pas de licence résulte en un patch que Debian n'acceptera pas). https://wiki.ubuntu.com/MOTU/Packages/NoDesktopFile L'arborescence du menu est gérée selon un standard défini chez FreeDesktop il me semble. Elle est différente de celle de Debian. http://standards.freedesktop.org/desktop-entry-spec/latest/ En ce qui concerne les traductions de ces fichiers, je ne suis pas la personne la mieux informée, mais il me semble qu'il n'y a rien de prévu chez Debian. Je ne sais pas ce qu'il en est chez Ubuntu. Peut-être y a-t-il matière à collaboration, puisque les fichiers .desktop semblent plus important pour Ubuntu que pour Debian ? Bonne journée à tous, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
First draft of review of policy must usage
Hi, Here is a first draft of changes to the policy that I think are required to bring ot closer in line with extant practice. I removed portions from the policy that linked policy violations to bug severities, since this has been deemed controversial and a bug in policy. Next, I removed the DFSG text and replaced it by a pointer to the DFSG document itself, this prevents duplication, and I am not sure I would have remembered to edit it here if we ever changed the DFSG. Next, I removed clauses that said that all the requirements of policy must be met for a package to be in main or contrib; we know that is not true. I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for must. This still needs to be done for should (which I often replace with 'ought to'). Finally, for your review, are some downgrades from must to should, which bring the document close to the release policy (though I think the release policy is not exhaustive [one must not ignore errors in maintainer scripts, and stop installation if needed, according to policy, but that is not an RC bug, various and sundry must directives in the package name area, and others], and may in itself be buggy). If you have objections to or comments on any of these changes, please quote just the relevant chunk, and explain why you think the change is not good. Not that any one can change policy at the moment, but who knows, I may yet in the future be able to change policy again. manoj --- orig/policy.sgml +++ mod/policy.sgml @@ -62,7 +62,7 @@ GNU/Linux distribution. This includes the structure and contents of the Debian archive and several design issues of the operating system, as well as technical requirements that - each package must satisfy to be included in the + each package needs to satisfy to be included in the distribution. /p @@ -113,36 +113,6 @@ either. Please see ref id=pkg-scope for more information. /p - p - In the normative part of this manual, - the words emmust/em, emshould/em and - emmay/em, and the adjectives emrequired/em, - emrecommended/em and emoptional/em, are used to - distinguish the significance of the various guidelines in - this policy document. Packages that do not conform to the - guidelines denoted by emmust/em (or emrequired/em) - will generally not be considered acceptable for the Debian - distribution. Non-conformance with guidelines denoted by - emshould/em (or emrecommended/em) will generally be - considered a bug, but will not necessarily render a package - unsuitable for distribution. Guidelines denoted by - emmay/em (or emoptional/em) are truly optional and - adherence is left to the maintainer's discretion. - /p - - p - These classifications are roughly equivalent to the bug - severities emserious/em (for emmust/em or - emrequired/em directive violations), emminor/em, - emnormal/em or emimportant/em - (for emshould/em or emrecommended/em directive - violations) and emwishlist/em (for emoptional/em - items). - footnote - Compare RFC 2119. Note, however, that these words are - used in a different way in this document. - /footnote - /p p Much of the information presented in this manual will be @@ -327,98 +327,11 @@ headingThe Debian Free Software Guidelines/heading p The Debian Free Software Guidelines (DFSG) form our - definition of free software. These are: - taglist - tagFree Redistribution - /tag - item - The license of a Debian component may not restrict any - party from selling or giving away the software as a - component of an aggregate software distribution - containing programs from several different - sources. The license may not require a royalty or - other fee for such sale. - /item - tagSource Code - /tag - item - The program must include source code, and must allow - distribution in source code as well as compiled form. - /item - tagDerived Works - /tag - item - The license must allow modifications and derived - works, and must allow them to be distributed under the - same terms as the license of the original software. - /item - tagIntegrity of The Author's Source Code - /tag - item - The license may restrict source-code from being - distributed in modified form emonly/em if the - license allows the distribution of patch files - with the source code for the purpose of modifying the - program at build time. The license must explicitly - permit distribution of software built from modified - source code. The license may require derived works to - carry a different name or version number from the - original software. (This is a compromise. The Debian - Project encourages all authors to
Re: First draft of review of policy must usage
Manoj Srivastava wrote: Hi, Hi Manoj Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? Thank you very much. Luk PS: For those people that seem to think they can't help: there is still a long list of RC bugs, the release notes definitely still need work, translations can still be improved, installation and upgrade tests are always welcome... -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Dear Luk, On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes [EMAIL PROTECTED] said: Manoj Srivastava wrote: Hi, Hi Manoj Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? Thank you very much. The next time you feel the urge to be patronizing, ponder on these: a) what gives you the right to pontificate and tell people what to do from your high horse? b) Why do you think getting on a soap box is likely to help anything, including a dialogue on this list? c) that for some of us doing things right trumps releasing on some arbitrary deadline hands down? Part of doing things right it to lick the technical policy in shape; reviewing the must directives for bloat has been long overdue. If the policy is so far from reality that release managers do not consider violation of must directives as something that would compromise the high standards of what Debian considers fit for release, then it seems to me we need to fix policy. Now, if you can stop lecturing and review the changes, and provide feedback on whether my judgement for thechanges is on the right path, you would be helping. If noit, could you please let the rest of us work on getting a better technical policy out? thank you, manoj -- Give him an evasive answer. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: Getting rid of circular dependencies, stage 6
On Wed, 25 Oct 2006 07:01:22 +0200, Christian Perrier [EMAIL PROTECTED] said: install time are indeed buggy, but I see no indication that the jihad against circular dependencies is making any such distinctions. Is the word jihad meant to mean holy, and aggressive, war to spread out a religion here? It also means, at least in farsi, and urdu, a war fought with passion on a principle or belief. Lots of crusades and wars foought for religion (though not necessarily to spread the religion) do fit the definition. I recently had an argument with another maintainer who also used tha word with that meaning, which it doesn't have in the muslim culture (I'm personnally a bit sensitive about that, for reasons I would have much difficulties to explain). I felt it to be pretty offensive to my muslim friends. They felt offended by the term that roughly translates into holy war? how ... strange. It that's the case, I'm not sure this is the best way to make the point. I'm actually following this thread and I try to understand whether the circular dependencies used by console-common (for which I act as co-maintainer with Alastair McKinstry) are Good or Bad. I do think that there is a whift of dogma around the current crusade against all circular dependencies, whther or not the installation phase actually cares about the dependency or not. Oh dear -- have I now offended all Christians? I appreciate the work done by Bill on that issue and I currently do not have the feeling that it is run with the intents you seem to put in the word jihad. One can appreciate work done to reduce un-needed circular dependencies without bying the cool aid that all circular dependencies are bad and must be eliminated at all costs. I appreciate the former, I think the latter is a bad idea. manoj -- A bird in the hand is worth what it will bring. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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 mass filling
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote: So certain bugs can be marked $STABLE-ignore to allow transient rc issues to be ignored for a release and will become no-ops after release. Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? If a rule defining a bug ended in the policy document, it certainly is worthy of being addressed. As Manoj expressed several times, if a bug can be ignored for an arbitrary length of time, it certainly should be a note in the developer reference and not a sentence in the policy document. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]: If you are aware of issues that are violations of muSt directives that are never going to be RC, there should be a bug opened on policy with severity important for every one of them. I hope to have time post-etch-release to do that (that is what I meant with syncing between policy and release-policy). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
* Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]: [...] Manoj, I'm seriously asking you if we can delay this discussion until after Etch is out. I'm very interessted in takeing part in the discussion, but I really have already to many open very urgent tasks at my hands. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 6
On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote: One can appreciate work done to reduce un-needed circular dependencies without bying the cool aid that all circular dependencies are bad and must be eliminated at all costs. I appreciate the former, I think the latter is a bad idea. well, as long APT gets fixed once and for all. -- c u henning signature.asc Description: Digital signature
should, ought, must (was: Bug mass filling)
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said: Is the word generally here an error? I read this as implying the normal meaning of should -- that not everything which violates a should mandate is a bug. I am of the opinion that it is. We can replace non-buggy instances of should by 'ought to be', if needed. But please don't forget a legal definition of those terms. For me, as a non-native speaker, I have no idea whether ought to is weaker or stronger than should, or just something different (and what). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: arches and etch
On Tue, 24 Oct 2006, Reinhard Tartler wrote: The only clean way to do this is IMO a dedicated upgrader tool. This tool could then have special rules for the following issues: I don't know if we need such a tool, but it would be definitely helpful if we had a mechanism to give hints to aptitude/apt-get in order to let them know important changes in the packaging: It could be new fields like: Package: python-something Supersedes: python2.3-something, python2.4-something Renders-Useless: python-something-common It could be some generic regexps: Hint: python\d.\d-(.*) - python-$1 We could have some priorities associated to hints so that very specific hints overrides global ones. This is of course an etch+1 thing, and really specific for a given release. You can of course imagine that these ideas don't come out of the blue. In fact, such a tool is already deployed in ubuntu. I think we could port it to debian as well, if enough people see a need for it. I've never evaluated it but such a tool should try to be generic: for example it should detect priority changes and proposes for example the replacement of netkit-inetd by openbsd-inetd. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said: Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. That does not make sense. After etch is released, etch-ignore tags are no-ops -- so there is no need to go back and untag anything. The work would be to change the tag to whatever-ignore. And if there are anyissues that are policy must directives that the release team has take upon itself to say are policy directives it is not worth following, then they should file important bugs against polocuy to either have the requirements removed, or the issue resovled by the tech ctte. I don't like your wording of not worth following. A policy dictum might well be important to follow, but non-conformance may still (always or in particular cases) not be a reason to exclude it from the release. But you're of course right that Policy and the release-policy should be synchronized... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Getting rid of circular dependencies, stage 6
On Wed, Oct 25, 2006 at 07:01:22AM +0200, Christian Perrier wrote:
install time are indeed buggy, but I see no indication that the jihad
against circular dependencies is making any such distinctions.
It that's the case, I'm not sure this is the best way to make the
point. I'm actually following this thread and I try to understand
whether the circular dependencies used by console-common (for which I
act as co-maintainer with Alastair McKinstry) are Good or Bad.
During my switch to aptitude instead of debfoster/apt-get, I recently
thought that:
aptitude markauto '~i(!~M)((~R(~i))|(~Rrecommends:(~i!~M)))'
or even
aptitude markauto '~i(!~M)~R(~i)'
should be an idempotent operation. And that once this is done, I could
not mark any more packages as automatic (ok, you have to refine a bit to
hold in account the fact that recommends is as good as depends for
aptitude in default mode ; I did not include the more complicated search
for the sake of simplicity).
Once I have selected console-data to be marked manual and the rest
(console-tools, console-common) to be automatic, I expect it would
see that everything holds. Instead of that, it just finds the circular
dependency loop and says that since they only depend on themselves,
those packages are probably a useless loop.
As a matter of fact, I can live with a few exceptions. But this way
(with a more complicated search in aptitude that accounts for the
Recommends dependency) is a quick way to find circular dependencies.
On my system, there is a dependency loop for
console-* packages, {sys,}klogd packages and
fortune-* packages, at least.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
Hi, On Wed, 25 Oct 2006, Andreas Barth wrote: * Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]: [...] Manoj, I'm seriously asking you if we can delay this discussion until after Etch is out. I'm very interessted in takeing part in the discussion, but I really have already to many open very urgent tasks at my hands. Andreas, I understand your feeling but you have to accept that you can't be on all fronts at the same time. I understand we need to make concessions towards a release (like concentrating on fixing bugs instead of introducing new major upstream changes) but it shouldn't block Debian's progress in all areas. You must understand that if Manoj is not fixing the policy, he probably won't use that time to fix RC bugs. And in that particular case, I have the feeling that Manoj has taken into account the remarks of the RM since he removed the problematic parts for now, and loosened some must into should in order to better fit the RM conception of 'release critical'. Manoj, I have reviewed your patch and it looks ok for me. I haven't checked its completeness (wrt etch_release_policy.txt) however. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On 10818 March 1977, Luk Claes wrote: Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? No, the release is no reason to stop everything else. -- bye Joerg exa Snow-Man: Please don't talk to me. You have demonstrated yourself sufficiently. There is a serious matter being talked. Snow-Man exa: It's hardly serious, it's about you. pgpIgTtmtEa1Q.pgp Description: PGP signature
Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor
* Moritz Muehlenhoff ([EMAIL PROTECTED]) : That would be much appreciated. The package tinymce has just been uploaded to the NEW queue. FYI it's the first package handled by the Webapps Team. You can grab the sources form our SVN repository: http://svn.debian.org/wsvn/webapps-common/packages/tinymce/?rev=0sc=0 Regards, -- Alexis Sukrieh [EMAIL PROTECTED] 0x1EE5DD34 Debian http://www.debian.org Backup Manager http://www.backup-manager.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian kernels and APM poweroff
Moin, there is one issue with the newer debian kernels, as they have SMP enabled: as documented in bugs #376089 and #378323, apm poweroff does not work anymore. A possible solution is to put options apm poweroff somewhere under /etc/modprobe.d/ and regenerate the initrd. IMHO it would be a good idea to enable apm poweroff by default (as it worked before, when there were separate uniprocessor kernels). The most obvious place to put this would be module-init-tools:/etc/modprobe.d/arch/i386 which is a bit hard to change now, as base is frozen... -- c u henning signature.asc Description: Digital signature
Re: should, ought, must (was: Bug mass filling)
* Frank Küster ([EMAIL PROTECTED]) [061025 09:49]: Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said: Is the word generally here an error? I read this as implying the normal meaning of should -- that not everything which violates a should mandate is a bug. I am of the opinion that it is. We can replace non-buggy instances of should by 'ought to be', if needed. But please don't forget a legal definition of those terms. For me, as a non-native speaker, I have no idea whether ought to is weaker or stronger than should, or just something different (and what). I think we should (hehe) use the same definitions as the RFCs - or is this text non-DFSG-free? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian kernels and APM poweroff
On Wed, Oct 25, 2006 at 11:01:04AM +0200, Henning Glawe wrote: A possible solution is to put options apm poweroff argh. stupid typo. should be: options apm power_off -- c u henning signature.asc Description: Digital signature
libc6 2.5 and Etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Is there any reasonable possibility that it will make it into Etch? Thanks - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPzAqS9HxQb37XmcRAjgZAKC3dYy5e9XE9wb+K8O2xwh31a808QCglzSs p+Pmg1YDH9LnaS/HLTayG2w= =4rrZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
On Wed, Oct 25, 2006 at 04:36:42AM -0500, Ron Johnson wrote: Is there any reasonable possibility that it will make it into Etch? libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
* Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: Is there any reasonable possibility that it will make it into Etch? No, of course not. We cannot put a copletely new and untested libc in at this point of the release cycle. In fact, we don't even have 2.4 because there are a number of architectures that still need LinuxThreads. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
* Steinar H. Gunderson [EMAIL PROTECTED] [2006-10-25 11:48]: Is there any reasonable possibility that it will make it into Etch? libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no. 2.5 came out a few days ago. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
* Ron Johnson ([EMAIL PROTECTED]) [061025 11:37]: Is there any reasonable possibility that it will make it into Etch? No. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/06 04:53, Martin Michlmayr wrote: * Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: Is there any reasonable possibility that it will make it into Etch? No, of course not. We cannot put a copletely new and untested libc in at this point of the release cycle. That's what I figured, but 2.5 has been sitting in experimental for a while, and I didn't know whether it was just waiting for final release to be dropped into Sid just before the freeze. In fact, we don't even have 2.4 because there are a number of architectures that still need LinuxThreads. Then how will 2.5 be adopted? - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPzv5S9HxQb37XmcRAisnAKDQg7Tko2ljAZCrHM2nptXzGUMacQCfeLyN H7JMdWAtz6XSgttmLNATnWA= =ev7a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Matthew Garrett [EMAIL PROTECTED] writes: Hamish Moffatt [EMAIL PROTECTED] wrote: That might explain some trouble with X on obscure video chipsets recently reported on debian-amd64 then. On any architecture other than i386, Xorg builds use the x86emu backend rather than the vm86 one. In theory that should let things work happily, but there's no guarantee that the x86emu emulation is strictly accurate. I still get the vm86 warning in dmesg when X starts up on amd64. So it at least tries to use it directly before falling back. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Matthew Garrett [EMAIL PROTECTED] writes: Juliusz Chroboczek [EMAIL PROTECTED] wrote: If I'm reading the function int10LinuxLoadSubModule in os-support/linux/int10/linux.c right, it shouldn't matter. vm86 will return ENOSYS, which will cause vm86_tst to fail, which will cause the X server to use x86emu instead of vm86. Or am I missing something? The x86emu code doesn't get built on i386, does it? It doesn't look like the INT10_VM86 and INT10_X86EMU conditionals can both be set simultaneously. That would be a reason to write a bug to X about it but not a reason to exclude 64bit kernels. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 6
Frank Küster [EMAIL PROTECTED] writes: Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006, Petter Reinholdtsen wrote: [Ian Jackson] The only argument I've heard against circular dependencies as a general rule is that they can trigger a particularly stupid (and probably not very hard to fix) bug in apt, You seem to have missed the argument that packages with circular dependencies are impossible to install and configure in the correct (dependency) order, and thus will end up being installed and configured in a nondeterministic order instead. It is documented that dpkg try its best to find a sensible order for the packages, but it is bound to fail one way or another if two packages really do need each other to be configured before they are configured. Packages which have circular dependencies and depend on the other package being configured are buggy; at most they can depend on the other package being unpacked. Since there is no way to specify this kind of dependency, Depends: is as close as you can get. It seems to me that the solution in such situation shouldn't be a circular dependency with its nondeterministic behavior, but instead to separate one of the packages into two. For example if package b needs package a unpacked, but not configured, separate package a in a-data and a-therest, where a-data provides all that package b needs: Now b can depend on a-data, and a-therest can depend on b. Regards, Frank You can have an arch:any package and arch:all package that depend on each other. It can also not make sense to further split them due to size. Now say that the depends is only that at usage time some binaries need shared scripts and the shared scripts need arch specific data (closing the depends cycle). No dependency is there when configuring. It is perfectly save for dpkg to break the cycle at any point. Should there really be a further package split with a few K big package? The only problem with such cycles is that apt screws up its ordering and cycle breaking and sometimes tries to configure A without B, which dpkg then refuses. Maybe someone should fix apt to use the command-fd interface to dpkg to get rid of the command line length limit that causes this random spliting of cycles. Some cycles are better left as such. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
Raphael Hertzog [EMAIL PROTECTED] wrote: I understand we need to make concessions towards a release (like concentrating on fixing bugs instead of introducing new major upstream changes) but it shouldn't block Debian's progress in all areas. You must understand that if Manoj is not fixing the policy, he probably won't use that time to fix RC bugs. That's quite correct, but it seems strange that resynchronizing of two documents takes place while the group who authored one of them is too busy to take part in that process. I would hope that in this process, not only policy is improved, but also the release-policy (if not in meaning then at least in wording and clearness), but we can't expect this to happen right now. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: libc6 2.5 and Etch
Ron Johnson a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/06 04:53, Martin Michlmayr wrote: * Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: Is there any reasonable possibility that it will make it into Etch? No, of course not. We cannot put a copletely new and untested libc in at this point of the release cycle. That's what I figured, but 2.5 has been sitting in experimental for a while, and I didn't know whether it was just waiting for final release to be dropped into Sid just before the freeze. In fact, we don't even have 2.4 because there are a number of architectures that still need LinuxThreads. Then how will 2.5 be adopted? We plan to upload it right after the release of etch. This version works on all architectures, but m68k, hurd and hppa which don't have TLS support. For hppa the work is almost done, I am currently building the packages (but on a slow machine) to test them. For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/06 06:27, Aurelien Jarno wrote: Ron Johnson a écrit : On 10/25/06 04:53, Martin Michlmayr wrote: * Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: [snip] For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. m68k was dropped from Etch last week. :( - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFP2TjS9HxQb37XmcRAudzAJ9ifXc19sv2sRizUNgHxmXfisqMPACfQAhV NkwEjreLLR0K65wc1+8uuU8= =p7Gy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On 10/25/06, Manoj Srivastava [EMAIL PROTECTED] wrote: I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for must. This still needs to be done for should (which I often replace with 'ought to'). It would be nice to have a comment, footnote or similar thing that explains the differences between all these indicators: Something like this: * must / have to: you have to do this, no matter what. * should / ought to: it's a very good idea to do this, but in some special cases you might have a reason not to. I don't know if these are the meanings intended. All these verbs sound the same to me, but it seems they are intended to have different meanings, and I think it's better to make things as clear as possible. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 09:35:13 +0200, Andreas Barth [EMAIL PROTECTED] said: * Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]: [...] Manoj, I'm seriously asking you if we can delay this discussion until after Etch is out. I'm very interessted in takeing part in the discussion, but I really have already to many open very urgent tasks at my hands. You do not have to worry about any action being taken on this issue; by FTP master action, uploads to policy are now verboten until post etch anyway. Is there any harm in refining the changes and building consensus over time? The change document can exist as a talking point, and you can still come in and provide us your input when you have time (post etch). manoj -- I couldn't remember things until I took that Sam Carnegie course. Bill Peterson, former Houston Oiler football coach Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: First draft of review of policy must usage
Manoj Srivastava [EMAIL PROTECTED] wrote: Is there any harm in refining the changes and building consensus over time? The change document can exist as a talking point, and you can still come in and provide us your input when you have time (post etch). Personally, I would see it as a waste of time to take part in a discussion in which one of the involved parties is not involved (due to time constraints). And that's going to be my last public mail about this topic... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 10:35:07 -0300, Margarita Manterola [EMAIL PROTECTED] said: On 10/25/06, Manoj Srivastava [EMAIL PROTECTED] wrote: I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for must. This still needs to be done for should (which I often replace with 'ought to'). It would be nice to have a comment, footnote or similar thing that explains the differences between all these indicators: Something like this: * must / have to: you have to do this, no matter what. * should / ought to: it's a very good idea to do this, but in some special cases you might have a reason not to. I don't know if these are the meanings intended. All these verbs sound the same to me, but it seems they are intended to have different meanings, and I think it's better to make things as clear as possible. The only normative words are MUST, SHOULD, MAY, and RECOMMENDED. I am considering using upper case where we expect conformance. ought to is a phrase used when doing something is a good idea, but not doing so does not result in a bug on a package. Consider the case when a ftp repository pool contains more than one source version of a package. If you get a diff.gz file from one version, and an orig.tar.gz file from another version, the results might not be something that builds. p As it exists on the FTP site, a Debian source package - consists of three related files. You must have the right + consists of three related files. You need to have the right versions of all three to be able to use them. /p The use of must could have been confusing, changing the phrase to you have to tells the user that not following the get all files from the same source version is a great idea, butif a user does not do so, no serious bug needs to be filed :) manoj -- lisp, v.: To call a spade a thpade. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: First draft of review of policy must usage
Manoj Srivastava wrote: Dear Luk, On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes [EMAIL PROTECTED] said: Manoj Srivastava wrote: Hi, Hi Manoj Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? Thank you very much. The next time you feel the urge to be patronizing, ponder on these: a) what gives you the right to pontificate and tell people what to do from your high horse? Look who's talking... b) Why do you think getting on a soap box is likely to help anything, including a dialogue on this list? I don't understand this sentence: 'getting on a soap box'? c) that for some of us doing things right trumps releasing on some arbitrary deadline hands down? Same for 'trumps' in previous sentence. Part of doing things right it to lick the technical policy in shape; reviewing the must directives for bloat has been long overdue. If the policy is so far from reality that release managers do not consider violation of must directives as something that would compromise the high standards of what Debian considers fit for release, then it seems to me we need to fix policy. You keep putting things in the release managers' mouth... It's not because in some cases the must in policy isn't considered RC that release managers think violation of must directives is ok to release with in general... Now, if you can stop lecturing and review the changes, and provide feedback on whether my judgement for thechanges is on the right path, you would be helping. If noit, could you please let the rest of us work on getting a better technical policy out? I don't like the timing at all. As you said above it's long overdue, so I don't see why it should happen near release time? Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Joerg Jaspert wrote: On 10818 March 1977, Luk Claes wrote: Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? No, the release is no reason to stop everything else. It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 16:08:36 +0200, Frank Küster [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] wrote: Is there any harm in refining the changes and building consensus over time? The change document can exist as a talking point, and you can still come in and provide us your input when you have time (post etch). Personally, I would see it as a waste of time to take part in a discussion in which one of the involved parties is not involved (due to time constraints). And that's going to be my last public mail about this topic... I see this as a long process, and by no means do I want to exclude any one. There are a number of low hanging errors that can be eliminated before we get to the more complex cases where we need to get the input of everyone. Also, consider the fact that in a project this size, there is probably no time that is good enough for every one. By starting the refinement now, and taking our time to get it right (I do not have an arbitrary deadline before which policy must be fixed and rushed out of the door), we are more likely to get a document that is in good shape. If you think you can only participate in the process after Etch is released, that is fine. Policy is not going anywhere. manoj -- You don't move to Edina, you achieve Edina. Guindon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: Getting rid of circular dependencies, stage 6
I do think that there is a whift of dogma around the current crusade against all circular dependencies, whther or not the installation phase actually cares about the dependency or not. Oh dear -- have I now offended all Christians? Well, dunno...:-) Seriously speaking, I think that any word that could sound rude is, especially with e-mail, best avoided in arguments. Back to the point: I appreciate the work done by Bill on that issue and I currently do not have the feeling that it is run with the intents you seem to put in the word jihad. One can appreciate work done to reduce un-needed circular dependencies without bying the cool aid that all circular dependencies are bad and must be eliminated at all costs. I appreciate the former, I think the latter is a bad idea. Well, we probably agree on that matter. But my understanding about this action is that it is not conducted as to eliminate these circular dependencies at all costs (maybe the getting rid is not the best choice of words for that). Which indeed, does not yet make it clear to me about what could be corrected in the circular dependency which console-common is involved in, anyway. signature.asc Description: Digital signature
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote: Next, I removed clauses that said that all the requirements of policy must be met for a package to be in main or contrib; we know that is not true. I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for must. This still needs to be done for should (which I often replace with 'ought to'). So, you changes some things from must to needs, because we don't consider them RC anymore. But then also remove the requirement to comply with the policy for us to distribute it? I think you're trying to do the same thing twice. I don't think we should remove the requirement to comply with all the requirements. @@ -986,7 +891,7 @@ particular version of that package.footnote p Essential is defined as the minimal set of functionality - that must be available and usable on the system even + that have to be available and usable on the system even when packages are in an unconfigured (but unpacked) state. This is needed to avoid unresolvable dependency loops on upgrade. If packages add unnecessary Why do you downgrade this? Maybe this should be reworded though. This seems to be the only place in the policy that says that an essential package must have all it's functionality when it's in an unpackaged state. I think that should atleast be moved to the part about essential (3.8) instead of a footnote about Dependencies. @@ -1931,7 +1848,7 @@ p The ttbuild/tt, ttbinary/tt and - ttclean/tt targets must be invoked with the current + ttclean/tt targets need to be invoked with the current directory being the package's top-level directory. /p I don't see why you want to change that. I think packages rely on it that it's called with a proper current working directory. @@ -3195,8 +3112,8 @@ p Additionally, packages interacting with users using ttdebconf/tt in the prgnpostinst/prgn script should - install a prgnconfig/prgn script in the control area, - see ref id=maintscriptprompt for details. + usually install a prgnconfig/prgn script in the control + area, see ref id=maintscriptprompt for details. /p p You seem to have changed should to should usually, and I don't see what the real difference is. p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. @@ -4722,7 +4640,7 @@ p If a package contains a binary or library which links to a - shared library, we must ensure that when the package is + shared library, we have to ensure that when the package is installed on the system, all of the libraries needed are also installed. This requirement led to the creation of the ttshlibs/tt system, which is very simple in its design: I have no idea why you want to change that. If it's linked to a shared library, it really needs that library and won't work without it. So this should be a must. Also, if you really want to change that, you might want to change the This requirement too. @@ -4748,7 +4666,7 @@ determined by calling prgnldd/prgn, but now prgnobjdump/prgn is used to do this. The only change this makes to package building is that - prgndpkg-shlibdeps/prgn must also be run on shared + prgndpkg-shlibdeps/prgn also has to be run on shared libraries, whereas in the past this was unnecessary. The rest of this footnote explains the advantage that this method gives. It really must be run on it, or things will break. @@ -4865,7 +4783,7 @@ determine whether ttfoo-prog/tt's library dependencies are satisfied by any of the libraries provided by ttlibfoo2/tt. For this reason, - prgndpkg-shlibdeps/prgn must only be run once + prgndpkg-shlibdeps/prgn has to be run only once all of the individual binary packages' ttshlibs/tt files have been installed into the build directory. If you remove that requirement, I think you need to another one. foo-runtime really needs to have a dependency on libfoo2, one way or another. @@
Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes [EMAIL PROTECTED] said: Joerg Jaspert wrote: On 10818 March 1977, Luk Claes wrote: Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? No, the release is no reason to stop everything else. It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... In a project this size, not all activities come to a dead end every couple of years for a few months. Consistent with releasing, activities geared towards improving the infrastructure, subsystems, and packages can and should still be on going. The reason I have initiated this at this point is that I was not aware that policy is perceived to be so far out of whack with the project processes that violations of MUST directives in policy are considered to be unrelated to bugs serious enough to warrant fixing -- and that policy directives linking ciolations to bug severities are now considered an unreported bug in policy itself. I realized that there never has been a comprehensive review of the MUST/SHOULD/MAY dictums in policy, and also, policy has grown organically, since until recently there was no single cohesive editor -- the old piecemeal approach of any small group of developers just adding language for each policy change leads to a disjoint, incoherent document. It is about time we started looking at policy holistically. That was the trigger. Also, consider the fact that we are all (for the most part), volunteers. there a re number of demands on our time. Real life intervenes. Private and pet projects go hot or cold. the release process is just one such drain on our timel but there are others. For a process like a broad review of policy, where one needs to get the buy in and eye balls of a large group of developers, it is impossible to pick a time that is convenient for every one. Unlike Etch, there is no pressing directive that policy review be all done by Dec 4rth; we can and should take our time and do this _right_. Correctness and completeness should be preferred over speed at this point. manoj -- Can you program? Well, I'm literate, if that's what you mean! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: libc6 2.5 and Etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/2006 11:21 AM, Ron Johnson wrote: On 10/25/06 06:27, Aurelien Jarno wrote: Ron Johnson a écrit : On 10/25/06 04:53, Martin Michlmayr wrote: * Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: [snip] For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. m68k was dropped from Etch last week. :( But I hope it is going to be back for etch+1. :-) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFFP5zeCjAO0JDlykYRAo6CAKCkkNr4GhTfd0X44ORaJ1V1youQBACeOWTg TFl/0VOFZbRuyrBc3a6xuTA= =CfOA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 20:01:32 +0200, Kurt Roeckx [EMAIL PROTECTED] said: On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote: Next, I removed clauses that said that all the requirements of policy must be met for a package to be in main or contrib; we know that is not true. I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for must. This still needs to be done for should (which I often replace with 'ought to'). So, you changes some things from must to needs, because we don't consider them RC anymore. But then also remove the requirement to comply with the policy for us to distribute it? I think you're trying to do the same thing twice. I don't think we should remove the requirement to comply with all the requirements. Well, we know that packages are in Debian that do not comply with all directives in policy right now. The wording is poor -- 'all directives; include SHOULD and MAY as well, and we don not throw packages out of Debian (or even a stable release) based on even MUST criteria -- so those bits in policy are just plain wrong. @@ -986,7 +891,7 @@ particular version of that package.footnote p Essential is defined as the minimal set of functionality - that must be available and usable on the system even + that have to be available and usable on the system even when packages are in an unconfigured (but unpacked) state. This is needed to avoid unresolvable dependency loops on upgrade. If packages add unnecessary Why do you downgrade this? Maybe this should be reworded though. This is a foto note. Foot notes are not normative. This seems to be the only place in the policy that says that an essential package must have all it's functionality when it's in an unpackaged state. I think that should atleast be moved to the part about essential (3.8) instead of a footnote about Dependencies. I think there is language elsewhere about that, though. @@ -1931,7 +1848,7 @@ p The ttbuild/tt, ttbinary/tt and - ttclean/tt targets must be invoked with the current + ttclean/tt targets need to be invoked with the current directory being the package's top-level directory. /p I don't see why you want to change that. I think packages rely on it that it's called with a proper current working directory. This is advice to the user, and thus not a normative directive for packaging. @@ -3195,8 +3112,8 @@ p Additionally, packages interacting with users using ttdebconf/tt in the prgnpostinst/prgn script should - install a prgnconfig/prgn script in the control area, - see ref id=maintscriptprompt for details. + usually install a prgnconfig/prgn script in the control + area, see ref id=maintscriptprompt for details. /p p You seem to have changed should to should usually, and I don't see what the real difference is. Not all packages have to install config files or be buggy -- for example, packages that only ask questions based on information available only after unpacking, for instance. Such packages may or may not ask questions, and the question they ask may need values gathered by programs that are contained in the package itself. In this case, there can be no config file -- and all the questions are conditionally asked in the postinst. Since this is not the default, I use the term should usually provide. not an unconditional should provide. p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. This is something I want to discuss further. Consider the case where there is a package with a set of, say, 20 binaries with a lot of common code, and upstream decided to abstract it out into a shared lib. This is a shred lib used by anyone else, and it is changing rapidly enough that there is the equivalent of a soname change on every upload. There is no interest in supporting older versions, or even having multiple versions of that lib. In this case, either we can make packaging that software hard (since moving the lib out of /usr/lib etc may involve some work), or we allow some packages to include share libs in the package. I don't know which way one should lean, so I decided to go
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote: p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. This is something I want to discuss further. Consider the case where there is a package with a set of, say, 20 binaries with a lot of common code, and upstream decided to abstract it out into a shared lib. This is a shred lib used by anyone else, and it is changing rapidly enough that there is the equivalent of a soname change on every upload. There is no interest in supporting older versions, or even having multiple versions of that lib. In this case, either we can make packaging that software hard (since moving the lib out of /usr/lib etc may involve some work), or we allow some packages to include share libs in the package. I don't know which way one should lean, so I decided to go the route of fewer bugs. If it's not supposed to be used by an other package, it should be moved to /usr/lib/package/. If it doesn't contain any other libraries in /usr/lib, it shouldn't provide a -dev package. So there really isn't a need for a seperate lib package either. Anyway, that's why it says should in the first place, and I don't see why it needs to be changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
Manoj Srivastava wrote: On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes [EMAIL PROTECTED] said: Joerg Jaspert wrote: On 10818 March 1977, Luk Claes wrote: Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? No, the release is no reason to stop everything else. It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... In a project this size, not all activities come to a dead end every couple of years for a few months. Consistent with releasing, activities geared towards improving the infrastructure, subsystems, and packages can and should still be on going. Indeed, though starting such discussions near release time is unfortunate at the least... The reason I have initiated this at this point is that I was not aware that policy is perceived to be so far out of whack with the project processes that violations of MUST directives in policy are considered to be unrelated to bugs serious enough to warrant fixing -- and that policy directives linking ciolations to bug severities are now considered an unreported bug in policy itself. I rather see policy as a guideline for long term compliance, but the etch RC policy for short term compliance. Of course there are some bugs in policy and it's indeed a good idea to review the consitency, but I think you overreact when you say that must directives in policy are unrelated to serious bugs... Also, consider the fact that we are all (for the most part), volunteers. there a re number of demands on our time. Real life intervenes. Private and pet projects go hot or cold. the release process is just one such drain on our timel but there are others. Right, though a release should be a common goal. It should be a joined effort... For a process like a broad review of policy, where one needs to get the buy in and eye balls of a large group of developers, it is impossible to pick a time that is convenient for every one. Sure, but that's something else than not a really good time for anyone... Unlike Etch, there is no pressing directive that policy review be all done by Dec 4rth; we can and should take our time and do this _right_. Correctness and completeness should be preferred over speed at this point. This is true for release work too, but the time between releases should be manageable. If we release on Dec 4th with nasty bugs, I'd rather have we release at middle or end of december without these nasty bugs... Sorry if my message came across too harsh, but I do think quality of the release is more important than quality of the policy at the moment and not only because I'm on the release team, but because I as a user want to still be proud to be part of Debian after Dec 4th :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: First draft of review of policy must usage
Luk Claes, 2006-10-25 18:51:26 +0200 : It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Topics that are long overdue should, by definition, be discussed and worked on *now*, regardless of whether now happens to be (presented as) close to release time. Roland. -- Roland Mas LinkedIn profile: http://www.linkedin.com/in/rolandmas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
* Roland Mas ([EMAIL PROTECTED]) [061025 22:38]: Luk Claes, 2006-10-25 18:51:26 +0200 : It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Topics that are long overdue should, by definition, be discussed and worked on *now*, regardless of whether now happens to be (presented as) close to release time. Changing the release policy is obviously a non-possibility now. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote: Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? No. Why would anyone want this when downgrading these bugs to important has the same effect in all respects and doesn't require changing code in 20 different places to account for a change in semantics? -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 6
On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote: I appreciate the work done by Bill on that issue and I currently do not have the feeling that it is run with the intents you seem to put in the word jihad. One can appreciate work done to reduce un-needed circular dependencies without bying the cool aid that all circular dependencies are bad and must be eliminated at all costs. I appreciate the former, I think the latter is a bad idea. FWIW, I think this is very much like turning on -Wall -Werror when compiling. It will complain about things which aren't errors, but, *because they are not mechanically distinguishable from things that are errors*, they should be reported anyway. Removing a non-buggy circular dependency may be worthwhile for the same reason fixing non-bug compiler warnings may be worthwhile -- so that the real bugs aren't drowned out by the noise. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Wed, 25 Oct 2006 09:31:42 +0200, Andreas Barth [EMAIL PROTECTED] said: * Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]: If you are aware of issues that are violations of muSt directives that are never going to be RC, there should be a bug opened on policy with severity important for every one of them. I hope to have time post-etch-release to do that (that is what I meant with syncing between policy and release-policy). Thanks. Your input shall be appreciated -- in the mean while, those of us with time and the inclination can work on fixing the low hanging errors, so you may find your work later reduced a bit. manoj -- The more complex the mind, the greater the need for the simplicity of play. Kirk, Shore Leave, stardate 3025.8 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: First draft of review of policy must usage
On Wed, 25 Oct 2006 22:39:14 +0200, Andreas Barth [EMAIL PROTECTED] said: * Roland Mas ([EMAIL PROTECTED]) [061025 22:38]: Luk Claes, 2006-10-25 18:51:26 +0200 : It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Topics that are long overdue should, by definition, be discussed and worked on *now*, regardless of whether now happens to be (presented as) close to release time. Changing the release policy is obviously a non-possibility now. Quite so. But getting a handle on policy flaws and creating a list of issues that need clarification can start now -- assuming, of course, that the people working on this do not let it hamper their efforts directed at improving release quality. manoj -- No question is so difficult as one to which the answer is obvious. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: cmake build-depends
On Mon, Oct 23, 2006 at 01:43:56PM +0200, Fathi Boudra wrote: we have a cmake class, proposed for inclusion in cdbs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377524 I use it at least on strigi and kde4 packages. Dunno if it's the same, but I have one that is working on libwibble-dev and libept-dev. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Is something wrong to XGL, Compiz, Cgwd be packaged?
Hi, I just wanna know if there are any problems regarding the License or something else that make these packages actually unavailable? Thanks
Re: Is something wrong to XGL, Compiz, Cgwd be packaged?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/06 18:50, eduardo.oliva barruzi wrote: Hi, I just wanna know if there are any problems regarding the License or something else that make these packages actually unavailable? $ wajig policy compiz compiz: Installed: (none) Candidate: 0.2.0-1 Version table: 0.2.0-1 0 500 ftp://mirrors.kernel.org unstable/main Packages - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFP/spS9HxQb37XmcRAhL5AJ9xLTGp3uaSNkaZlB/2BHbH8G6roACg0Ytq 45Ri+C+lC/0yDFG8U1muQbo= =7nSZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh packages with updated selinux patch
On Tuesday 24 October 2006 23:18, Manoj Srivastava wrote: Either of these would be fine (though looking at the size of libselinux1, I wonder if there are any numbers behind the burden theory?), but that would be a more intrusive change for openssh than I am willing to make as a non-maintainer at this stage of the game. We don't need any numbers. The installer runs fully in memory, sometimes on systems with very little memory, and a lot of it runs before swap is/can be enabled. This means that _every_ byte is worth saving. Call it a design goal. Cheers, FJP pgp8UvXF83xpQ.pgp Description: PGP signature
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote: The only normative words are MUST, SHOULD, MAY, and RECOMMENDED. I am considering using upper case where we expect conformance. Didn't the definitions of MUST/SHOULD/MAY get removed in your patch though? Cheers, aj signature.asc Description: Digital signature
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 10:39:14PM +0200, Andreas Barth wrote: * Roland Mas ([EMAIL PROTECTED]) [061025 22:38]: Luk Claes, 2006-10-25 18:51:26 +0200 : It was not meant that way at all. I just don't like that people start to discuss topics that are long overdue near release time... Topics that are long overdue should, by definition, be discussed and worked on *now*, regardless of whether now happens to be (presented as) close to release time. Changing the release policy is obviously a non-possibility now. Hi, there is the policy manual and release policy. Is not Manoj discussing changes to the former? if the policy manual is in a document repositories, anyone can reference a certain version from the past as applying to release policy while changes are introduced. 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: libc6 2.5 and Etch
On Wed, Oct 25, 2006 at 08:21:39AM -0500, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/06 06:27, Aurelien Jarno wrote: Ron Johnson a écrit : On 10/25/06 04:53, Martin Michlmayr wrote: * Ron Johnson [EMAIL PROTECTED] [2006-10-25 04:36]: [snip] For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. m68k was dropped from Etch last week. :( When Sarge was released, amd64 was not officially released but had an unofficial release. why not do the same with the hopes tha etch+1 will see m68k in relase shape? -- | .''`. == 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: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote: @@ -3195,8 +3112,8 @@ p Additionally, packages interacting with users using ttdebconf/tt in the prgnpostinst/prgn script should - install a prgnconfig/prgn script in the control area, - see ref id=maintscriptprompt for details. + usually install a prgnconfig/prgn script in the control + area, see ref id=maintscriptprompt for details. /p p You seem to have changed should to should usually, and I don't see what the real difference is. Not all packages have to install config files or be buggy -- for example, packages that only ask questions based on information available only after unpacking, for instance. Such packages may or may not ask questions, and the question they ask may need values gathered by programs that are contained in the package itself. In this case, there can be no config file -- and all the questions are conditionally asked in the postinst. Since this is not the default, I use the term should usually provide. not an unconditional should provide. However, I think it's important that policy outline those cases in which it's not a bug to omit a .config script. Doesn't the absence of the .config script require additional by-hand handling of the templates which is otherwise done automatically through apt? p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. This is something I want to discuss further. Consider the case where there is a package with a set of, say, 20 binaries with a lot of common code, and upstream decided to abstract it out into a shared lib. This is a shred lib used by anyone else, and it is changing rapidly enough that there is the equivalent of a soname change on every upload. There is no interest in supporting older versions, or even having multiple versions of that lib. In this case, either we can make packaging that software hard (since moving the lib out of /usr/lib etc may involve some work), or we allow some packages to include share libs in the package. This tells me that the guidelines for when shared library packages must be split up are still ill-defined in some corner cases. I don't think we should be gutting such an important requirement from policy just because there may be corner cases that need sorting, when the cost of non-compliance with this requirement is so high. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 6
On Wed, 25 Oct 2006 01:43:34 -0700, Steve Langasek [EMAIL PROTECTED] said: On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote: I appreciate the work done by Bill on that issue and I currently do not have the feeling that it is run with the intents you seem to put in the word jihad. One can appreciate work done to reduce un-needed circular dependencies without bying the cool aid that all circular dependencies are bad and must be eliminated at all costs. I appreciate the former, I think the latter is a bad idea. FWIW, I think this is very much like turning on -Wall -Werror when compiling. It will complain about things which aren't errors, but, *because they are not mechanically distinguishable from things that are errors*, they should be reported anyway. Removing a non-buggy circular dependency may be worthwhile for the same reason fixing non-bug compiler warnings may be worthwhile -- so that the real bugs aren't drowned out by the noise. In both cases, I am all for stripping the low hanging fruit. But if a circular dependency normally exits, I am suggesting we keep an eye on the contortions required to remove the dependency loop. For some cases, it might not be worth the effort -- some times the cure for the noise is worse than the noise itself. manoj -- Genius is ten percent inspiration and fifty percent capital gains. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: First draft of review of policy must usage
On Wed, 25 Oct 2006 19:44:38 -0700, Steve Langasek [EMAIL PROTECTED] said: On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote: @@ -3195,8 +3112,8 @@ p Additionally, packages interacting with users using ttdebconf/tt in the prgnpostinst/prgn script should - install a prgnconfig/prgn script in the control area, - see ref id=maintscriptprompt for details. + usually install a prgnconfig/prgn script in the control + area, see ref id=maintscriptprompt for details. /p p You seem to have changed should to should usually, and I don't see what the real difference is. Not all packages have to install config files or be buggy -- for example, packages that only ask questions based on information available only after unpacking, for instance. Such packages may or may not ask questions, and the question they ask may need values gathered by programs that are contained in the package itself. In this case, there can be no config file -- and all the questions are conditionally asked in the postinst. Since this is not the default, I use the term should usually provide. not an unconditional should provide. However, I think it's important that policy outline those cases in which it's not a bug to omit a .config script. I don't think I know _all_ use cases in which it is ok not to add a .config file. I can provide a few use cases. I think the reader should be allowed to make their own judgement calls, in case they have a use case we might miss. Doesn't the absence of the .config script require additional by-hand handling of the templates which is otherwise done automatically through apt? No. From debconf-devel (7): , | A question is an instantiated template. By asking debconf to display a | question, your config script can interact with the user. When debconf | loads a templates file (this happens whenever a config or postinst | script is run), it automatically instantiates a question from each tem‐ | plate. It is actually possible to instantiate several independent ques‐ | tions from the same template (using the REGISTER command), but that is | rarely necessary. ` p - Packages involving shared libraries should be split up into + Packages involving shared libraries ought to be split up into several binary packages. This section mostly deals with how this separation is to be accomplished; rules for files within - the shared library packages are in ref id=libraries instead. + the shared library packages are in ref id=libraries + instead. /p sect id=sharedlibs-runtime I think the should there was good. This is something I want to discuss further. Consider the case where there is a package with a set of, say, 20 binaries with a lot of common code, and upstream decided to abstract it out into a shared lib. This is a shred lib used by anyone else, and it is changing rapidly enough that there is the equivalent of a soname change on every upload. There is no interest in supporting older versions, or even having multiple versions of that lib. In this case, either we can make packaging that software hard (since moving the lib out of /usr/lib etc may involve some work), or we allow some packages to include share libs in the package. This tells me that the guidelines for when shared library packages must be split up are still ill-defined in some corner cases. I don't think we should be gutting such an important requirement from policy just because there may be corner cases that need sorting, when the cost of non-compliance with this requirement is so high. Making a SHOULD directive a suggestion is hardly what I call gutting. However, since this is one area I was fuzzy about, and now I have seen two strong negative reactions, and none in favour, this seems like something that may be reverted. manoj -- The Nazis have no sense of humor, so why should they want television? Philip K. Dick Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: First draft of review of policy must usage
On Thu, 26 Oct 2006 10:44:53 +1000, Anthony Towns aj@azure.humbug.org.au said: On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote: The only normative words are MUST, SHOULD, MAY, and RECOMMENDED. I am considering using upper case where we expect conformance. Didn't the definitions of MUST/SHOULD/MAY get removed in your patch though? It did in the first draft. Based on feedback, a modified version was re-introduced in the second draft, which ought to meet the flexibility requirements mentioned by the release managers. manoj -- Backed up the system lately? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: libc6 2.5 and Etch
On Wednesday 25 October 2006 20:42, Kevin Mark wrote: When Sarge was released, amd64 was not officially released but had an unofficial release. why not do the same with the hopes tha etch+1 will see m68k in relase shape? AMD64 is a modern architecture. M68k is an architecture that saw its prime many years ago. AMD64 also has a much larger user base considering that most of the m68k machines I know of are more toys than workhorses. Also, I think it could be that the Debian folks saw a strategic advantage is shipping a more normal version of Debian for the AMD64 arch. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting package build dependencies
I am interested in getting build-dependencies for a source package on a system using aptitude. In the past I've used apt-get build-dep, but that was on systems managed with apt-get. I think aptitude won't know about apt-get's selections, and may toss the packages at the first chance (or perhaps get confused in some other way). Is this analysis correct? If so, is there a good solution? The two other routes I see are to use dpkg-checkbuilddeps (but then I still need to get the output into aptitude) or to use one of the autobuilders that work in a chroot (which seems kind of heavy weight). Thanks. Ross Boylan cc's appreciated. P.S. apt-get build-dep has always made me a bit uncomfortable, since I presume it goes by the installed binary package. If you want to build some other version (e.g., system is testing but you want to build unstable) the dependencies aren't necessarily quite right. So I'd be happy to discover an alternative. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nini 1.1.0+dfsg-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 06:53:05 +0200 Source: nini Binary: libnini1.1-cil libnini-doc Architecture: source all Version: 1.1.0+dfsg-2 Distribution: unstable Urgency: low Maintainer: Debian Mono Group [EMAIL PROTECTED] Changed-By: Debian Mono Group [EMAIL PROTECTED] Description: libnini-doc - CLI library for managing configuration files (Documentation) libnini1.1-cil - CLI library for managing configuration files Closes: 395043 Changes: nini (1.1.0+dfsg-2) unstable; urgency=low . * Sebastian 'slomo' Dröge: + debian/rules: - Run dh_install before dh_installcligac to fix FTBFS (Closes: #395043) + debian/control: - Raise Build-Depends on cli-common-dev to (= 0.4.4) to remove warnings at build time - Update Standards-Version to 3.7.2 Files: 1043708a45119c7c96be46f7ac3f591e 771 devel optional nini_1.1.0+dfsg-2.dsc 3246fead5f8761628bf785aa8c3ac38d 3561 devel optional nini_1.1.0+dfsg-2.diff.gz 7c0b746ce393a2c588cef9afdb06c4e3 45082 devel optional libnini1.1-cil_1.1.0+dfsg-2_all.deb fad51ab1dc28aa631642b9b4c4dc5475 372398 doc optional libnini-doc_1.1.0+dfsg-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPv2wQ+ySUE9xlVoRAjWBAKCdC5rMvnVJ5hz/SFL7VHyOtyz0sACeJ1LQ v4cfvK1f5F+b9LLNZ/bYDo0= =PHKi -END PGP SIGNATURE- Accepted: libnini-doc_1.1.0+dfsg-2_all.deb to pool/main/n/nini/libnini-doc_1.1.0+dfsg-2_all.deb libnini1.1-cil_1.1.0+dfsg-2_all.deb to pool/main/n/nini/libnini1.1-cil_1.1.0+dfsg-2_all.deb nini_1.1.0+dfsg-2.diff.gz to pool/main/n/nini/nini_1.1.0+dfsg-2.diff.gz nini_1.1.0+dfsg-2.dsc to pool/main/n/nini/nini_1.1.0+dfsg-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk 1:1.2.13~dfsg-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 06:46:52 +0100 Source: asterisk Binary: asterisk-h323 asterisk-web-vmail asterisk asterisk-classic asterisk-dev asterisk-doc asterisk-sounds-main asterisk-bristuff asterisk-config Architecture: source all i386 Version: 1:1.2.13~dfsg-1 Distribution: unstable Urgency: high Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: asterisk - Open Source Private Branch Exchange (PBX) asterisk-bristuff - Open Source Private Branch Exchange (PBX) - BRIstuff-enabled vers asterisk-classic - Open Source Private Branch Exchange (PBX) - original Digium versi asterisk-config - config files for asterisk asterisk-dev - development files for asterisk asterisk-doc - documentation for asterisk asterisk-h323 - asterisk H.323 VoIP channel asterisk-sounds-main - sound files for asterisk asterisk-web-vmail - Web-based (CGI) voice mail interface for Asterisk Closes: 338116 342138 348194 375141 386113 389376 394025 394122 395080 Changes: asterisk (1:1.2.13~dfsg-1) unstable; urgency=high . [ Kilian Krause ] * Fixup dfsg versions with increased upstream build count. . [ Santiago Ruano Rincón ] * Added cdr_sqlite3_custom dpatch . [ Mark Purcell ] * New upstream release - Remote compromise (Closes: #394025) - CVE-2006-5444/5:security issues in asterisk (Closes: #395080) - Urgency high as this fixes remote compromise security issue - Information disclosure of voice mail messages through vmail.cgi (Closes: #338116) - package asterisk-dev should contain asterisk.h main header (Closes: #342138) - format_ogg_vorbis.so was present in i386, no longer in packages (Closes: #375141) * Update debian/patches/bristuff.dpatch * bristuff-0.3.0-PRE-1v - Please package bristuff 0.3.0PREu (Closes: #394122) - please include app_pickup.c from bristuff (Closes: #348194) * Build Depends: dpkg ( = 1.13.19) - Asterisk must build-depend upon dpkg ( = 1.13.19) (Closes: #386113) * Build-Depends: libpq-dev - obsolete build dependency postgresql-dev (Closes: #389376) Files: 14426527db1c7abf12a02b745cae91b0 1395 comm optional asterisk_1.2.13~dfsg-1.dsc f8ee088b2e4feffe2b35d78079f90b69 3835589 comm optional asterisk_1.2.13~dfsg.orig.tar.gz a75d403e861600e0a50e5d3f5688985f 173367 comm optional asterisk_1.2.13~dfsg-1.diff.gz e9a80c1e404ac596ba7c31074e348e7b 145536 comm optional asterisk_1.2.13~dfsg-1_all.deb 73d0100ba93d2f1193c9e227be83d8e5 19121500 doc optional asterisk-doc_1.2.13~dfsg-1_all.deb f25a5e8e52b262c07d3645024f6e1b14 168992 devel optional asterisk-dev_1.2.13~dfsg-1_all.deb 189167a3c013dda5bb26b80c1518f313 1503672 comm optional asterisk-sounds-main_1.2.13~dfsg-1_all.deb 0d31a0872756006e310c64e171f1e268 72796 comm optional asterisk-web-vmail_1.2.13~dfsg-1_all.deb ecae111f8aa9e43ee65e31dcac7e0e3b 130726 comm optional asterisk-config_1.2.13~dfsg-1_all.deb 8da1c58282bcfccc944ab62f3f35321a 1614394 comm optional asterisk-classic_1.2.13~dfsg-1_i386.deb 0e6df112a50fb2d859e713e2a1922c95 1647624 comm optional asterisk-bristuff_1.2.13~dfsg-1_i386.deb 46e7f3bf3fbbfb248fc20ae839b7a854 129878 comm optional asterisk-h323_1.2.13~dfsg-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPv4ToCzanz0IthIRAlenAJ9wJZlZlwJB7pGtrhrC916T9FZprACfYtx+ fpIysXNrCHdbPtaFLWqZfL8= =y4D5 -END PGP SIGNATURE- Accepted: asterisk-bristuff_1.2.13~dfsg-1_i386.deb to pool/main/a/asterisk/asterisk-bristuff_1.2.13~dfsg-1_i386.deb asterisk-classic_1.2.13~dfsg-1_i386.deb to pool/main/a/asterisk/asterisk-classic_1.2.13~dfsg-1_i386.deb asterisk-config_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk-config_1.2.13~dfsg-1_all.deb asterisk-dev_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk-dev_1.2.13~dfsg-1_all.deb asterisk-doc_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk-doc_1.2.13~dfsg-1_all.deb asterisk-h323_1.2.13~dfsg-1_i386.deb to pool/main/a/asterisk/asterisk-h323_1.2.13~dfsg-1_i386.deb asterisk-sounds-main_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk-sounds-main_1.2.13~dfsg-1_all.deb asterisk-web-vmail_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk-web-vmail_1.2.13~dfsg-1_all.deb asterisk_1.2.13~dfsg-1.diff.gz to pool/main/a/asterisk/asterisk_1.2.13~dfsg-1.diff.gz asterisk_1.2.13~dfsg-1.dsc to pool/main/a/asterisk/asterisk_1.2.13~dfsg-1.dsc asterisk_1.2.13~dfsg-1_all.deb to pool/main/a/asterisk/asterisk_1.2.13~dfsg-1_all.deb asterisk_1.2.13~dfsg.orig.tar.gz to pool/main/a/asterisk/asterisk_1.2.13~dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ftpwatch 1.20 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 08:35:22 +0200 Source: ftpwatch Binary: ftpwatch Architecture: source all Version: 1.20 Distribution: unstable Urgency: low Maintainer: Hakan Ardo [EMAIL PROTECTED] Changed-By: Hakan Ardo [EMAIL PROTECTED] Description: ftpwatch - Notifies you of changes on remote ftp servers Closes: 373002 Changes: ftpwatch (1.20) unstable; urgency=low . * Applied patch from Pawel Tecza [EMAIL PROTECTED] adding a -dopt option which passes opt as options to diff * Moved from debmake to debhelper (closes: #373002) * Added -p option to run ftp in passive mode Files: f1e81cde3135817204828070305d5397 478 main extra ftpwatch_1.20.dsc 4f3726018aa8832133145f93e2eafa6a 11782 main extra ftpwatch_1.20.tar.gz eefa628988226f56870a7fed05e8eccd 5702 net extra ftpwatch_1.20_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFPwXTAbtddT3jfcARAk0PAJ4nBYdckRJPvW6i+7BBvlhlao54AACfbzgz S3ahFBwQ2btHIfMSeo244d8= =HmCu -END PGP SIGNATURE- Accepted: ftpwatch_1.20.dsc to pool/main/f/ftpwatch/ftpwatch_1.20.dsc ftpwatch_1.20.tar.gz to pool/main/f/ftpwatch/ftpwatch_1.20.tar.gz ftpwatch_1.20_all.deb to pool/main/f/ftpwatch/ftpwatch_1.20_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kdevelop 4:3.3.5-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 11:59:24 +0200 Source: kdevelop Binary: kdevelop-doc kdevelop-data kdevelop kdevelop-dev Architecture: source i386 all Version: 4:3.3.5-1 Distribution: unstable Urgency: low Maintainer: Jeremy Lainé [EMAIL PROTECTED] Changed-By: Jeremy Lainé [EMAIL PROTECTED] Description: kdevelop - An IDE for Unix/X11 kdevelop-data - An IDE for Unix/X11 - data kdevelop-dev - An IDE for Unix/X11 - development files kdevelop-doc - An IDE for Unix/X11 - documentation Changes: kdevelop (4:3.3.5-1) unstable; urgency=low . * New upstream release. + Contains up-to-date KDE admin dir in application templates. * Remove patches included upstream: + 05_support_autoconf26.diff + 06_xim_crash_caused_by_qt.diff + 07_documentation_plugins_path.diff * Fix not-binnmuable-any-depends-all kdevelop - kdevelop-data. Files: fe348d1e18252f0310ddd7d2c980c31d 801 kde optional kdevelop_3.3.5-1.dsc 895f209c4c9c5f46536c020c2b9bcf95 10786218 kde optional kdevelop_3.3.5.orig.tar.gz 5b2d9a29e5de4c14f92b9ebcc8460aca 90071 kde optional kdevelop_3.3.5-1.diff.gz d3cf4b97a04e2a678d7f711be1313dd6 2467870 doc optional kdevelop-doc_3.3.5-1_all.deb 03f887d3b4a80bc48106ea8a684c4f93 2573576 kde optional kdevelop-data_3.3.5-1_all.deb eed12ef18ca34331327a24072ed2dda3 8134728 kde optional kdevelop_3.3.5-1_i386.deb c8c5dcea431f402767056301080dff48 162344 kde optional kdevelop-dev_3.3.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPwpT4mJJZqJp2ScRAngyAKCU9FwL/jh2Nf0o2nvTV6v734m9mwCgj91l J4XfNMaB+sdq35a0DpvZ+CY= =AL7z -END PGP SIGNATURE- Accepted: kdevelop-data_3.3.5-1_all.deb to pool/main/k/kdevelop/kdevelop-data_3.3.5-1_all.deb kdevelop-dev_3.3.5-1_i386.deb to pool/main/k/kdevelop/kdevelop-dev_3.3.5-1_i386.deb kdevelop-doc_3.3.5-1_all.deb to pool/main/k/kdevelop/kdevelop-doc_3.3.5-1_all.deb kdevelop_3.3.5-1.diff.gz to pool/main/k/kdevelop/kdevelop_3.3.5-1.diff.gz kdevelop_3.3.5-1.dsc to pool/main/k/kdevelop/kdevelop_3.3.5-1.dsc kdevelop_3.3.5-1_i386.deb to pool/main/k/kdevelop/kdevelop_3.3.5-1_i386.deb kdevelop_3.3.5.orig.tar.gz to pool/main/k/kdevelop/kdevelop_3.3.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-contextl 0.30-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 18:04:04 +0200 Source: cl-contextl Binary: cl-contextl Architecture: source all Version: 0.30-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-contextl - context orientation for Common Lisp Changes: cl-contextl (0.30-1) unstable; urgency=low . * updated standard version, now real changes * updated watch file * Updated upstream, with some extra bugfixes done afterwards. * move debhelper to build-depends Files: 0e27af43776ab8ae50aa9f44a4f20345 606 libs optional cl-contextl_0.30-1.dsc 4f75bfd5dbf66e5cdad867a1e548bd38 14306 libs optional cl-contextl_0.30.orig.tar.gz 9d6d1733f83d8905a204cb4b03df89f6 3177 libs optional cl-contextl_0.30-1.diff.gz 0bf3e916031591e7c68ae9c18500ce37 13848 libs optional cl-contextl_0.30-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPjmf11ldN0tyliURAoBHAKC4yNqB2v61Kx929w/SZvjmRyAdkQCfbiuO 0qSog8Zlp4HJD7TQtwZOjIg= =53h6 -END PGP SIGNATURE- Accepted: cl-contextl_0.30-1.diff.gz to pool/main/c/cl-contextl/cl-contextl_0.30-1.diff.gz cl-contextl_0.30-1.dsc to pool/main/c/cl-contextl/cl-contextl_0.30-1.dsc cl-contextl_0.30-1_all.deb to pool/main/c/cl-contextl/cl-contextl_0.30-1_all.deb cl-contextl_0.30.orig.tar.gz to pool/main/c/cl-contextl/cl-contextl_0.30.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-pg 1:20061022-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 15:03:38 +0200 Source: cl-pg Binary: cl-pg Architecture: source all Version: 1:20061022-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-pg - Common Lisp library that provides a socket level postgresql inter Changes: cl-pg (1:20061022-1) unstable; urgency=low . * Added XS-X-Vcs-Darcs header * modified S-X-Vcs-Darcs to XS-Vcs-Darcs field * New upstream with many bugfixes Files: 6b1f69852107cdb23afda6c83c1793bc 671 devel optional cl-pg_20061022-1.dsc 459e076de3bcdddaefec0733608d2a66 49452 devel optional cl-pg_20061022.orig.tar.gz 6fed63fb98ad3614367f91178f5940db 6096 devel optional cl-pg_20061022-1.diff.gz 5563bc8fd5eab43994885d3d0e4ffb69 45902 devel optional cl-pg_20061022-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPjaH11ldN0tyliURAlruAJ9pVItQi0BBLc12omy2S6MRJV2mvgCeLcYk mPYZw70JPQ7rJW/1eLmzpl4= =ZYS9 -END PGP SIGNATURE- Accepted: cl-pg_20061022-1.diff.gz to pool/main/c/cl-pg/cl-pg_20061022-1.diff.gz cl-pg_20061022-1.dsc to pool/main/c/cl-pg/cl-pg_20061022-1.dsc cl-pg_20061022-1_all.deb to pool/main/c/cl-pg/cl-pg_20061022-1_all.deb cl-pg_20061022.orig.tar.gz to pool/main/c/cl-pg/cl-pg_20061022.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kpax 20061019-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 14:57:40 +0200 Source: kpax Binary: cl-kpax Architecture: source all Version: 20061019-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-kpax- A Common Lisp Application Framework Changes: kpax (20061019-1) unstable; urgency=low . * Added XS-X-Vcs-Darcs header * modified S-X-Vcs-Darcs to XS-Vcs-Darcs field * New upstream version Files: 14a53a58bf9a96710f66c875770ff400 666 web optional kpax_20061019-1.dsc 64ef6361412f055330ebe5db55ce19df 150031 web optional kpax_20061019.orig.tar.gz 7fce4ad16639e5a15fd2a18dba5cd80f 3483 web optional kpax_20061019-1.diff.gz 8749f68c1333ed7c2b43b6bdec1bd647 72766 web optional cl-kpax_20061019-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPjai11ldN0tyliURAhCpAJsHwizA6o6AIXcsvkfabyjUB+6qsgCfR3va pjBwlZ/2pB4+2TIstoNfgUI= =2DbW -END PGP SIGNATURE- Accepted: cl-kpax_20061019-1_all.deb to pool/main/k/kpax/cl-kpax_20061019-1_all.deb kpax_20061019-1.diff.gz to pool/main/k/kpax/kpax_20061019-1.diff.gz kpax_20061019-1.dsc to pool/main/k/kpax/kpax_20061019-1.dsc kpax_20061019.orig.tar.gz to pool/main/k/kpax/kpax_20061019.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted s-http-server 20061109-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 14:59:29 +0200 Source: s-http-server Binary: cl-s-http-server Architecture: source all Version: 20061109-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-s-http-server - A Minimal Standalone Common Lisp HTTP Server Changes: s-http-server (20061109-1) unstable; urgency=low . * Added XS-X-Vcs-Darcs header * modified S-X-Vcs-Darcs to XS-Vcs-Darcs field * New upstream version Files: 50293105e79a76a0a700a3194ccade52 710 libs optional s-http-server_20061109-1.dsc 31912b8bb1ae1399b13a8e31fe3e03cb 21506 libs optional s-http-server_20061109.orig.tar.gz 05a93d9b5a4fb38b472c899c5a079469 3258 libs optional s-http-server_20061109-1.diff.gz 0137d0dff091c74b3caf72aa52374465 18786 libs optional cl-s-http-server_20061109-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPjaf11ldN0tyliURAhc7AJoCaJE4z10gy1PATx+Vp5XiKu78JgCeJ3Rd em1jGsde9OFAMDBFoFTI4mE= =jHb7 -END PGP SIGNATURE- Accepted: cl-s-http-server_20061109-1_all.deb to pool/main/s/s-http-server/cl-s-http-server_20061109-1_all.deb s-http-server_20061109-1.diff.gz to pool/main/s/s-http-server/s-http-server_20061109-1.diff.gz s-http-server_20061109-1.dsc to pool/main/s/s-http-server/s-http-server_20061109-1.dsc s-http-server_20061109.orig.tar.gz to pool/main/s/s-http-server/s-http-server_20061109.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted epix1 1.0.19-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Oct 2006 21:13:37 +0100 Source: epix1 Binary: epix1 Architecture: source i386 Version: 1.0.19-1 Distribution: unstable Urgency: low Maintainer: Julian Gilbey [EMAIL PROTECTED] Changed-By: Julian Gilbey [EMAIL PROTECTED] Description: epix1 - Create mathematically accurate line figures, plots and movies Changes: epix1 (1.0.19-1) unstable; urgency=low . * New upstream release Files: d6c8c5ca21cb9f7b496f33f3750ff09b 608 tex optional epix1_1.0.19-1.dsc d196536653885ea4f1b2a3f13cc640d7 690635 tex optional epix1_1.0.19.orig.tar.gz 0b5d955516b40ba4f83ebdeeb15a3d92 4107 tex optional epix1_1.0.19-1.diff.gz f7441850ea995eb71b46940d4bf76834 2287980 tex optional epix1_1.0.19-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPx0DDU59w/205FkRAgcIAKCOaKVEAxqSsMTgphigunMM7nffkACeLPrF G5J1nLxsROOP8LFVQtv1KZw= =QUQr -END PGP SIGNATURE- Accepted: epix1_1.0.19-1.diff.gz to pool/main/e/epix1/epix1_1.0.19-1.diff.gz epix1_1.0.19-1.dsc to pool/main/e/epix1/epix1_1.0.19-1.dsc epix1_1.0.19-1_i386.deb to pool/main/e/epix1/epix1_1.0.19-1_i386.deb epix1_1.0.19.orig.tar.gz to pool/main/e/epix1/epix1_1.0.19.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dgpsip 1.33-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 10:54:31 +0200 Source: dgpsip Binary: dgpsip Architecture: source amd64 Version: 1.33-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: dgpsip - Correct GPS location with DGPS signal from internet Changes: dgpsip (1.33-2) unstable; urgency=low . * QA upload. * Set maintainer to QA Group; Orphaned: #392666 * Conforms with latest Standards Version 3.7.2 Files: 4f8d0460fdd78e845e8eba5e9fbc5588 556 misc extra dgpsip_1.33-2.dsc aa28987fde1076c6f478253547888ef1 2718 misc extra dgpsip_1.33-2.diff.gz 194deae405ad30539da38d4dbe31be24 29570 misc extra dgpsip_1.33-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPyaBEFV7g4B8rCURAhttAKCh+352pPrAJKWIUl0bwWI7UVffEwCgh6G7 lfkZ76lEO7uO8rIj91L4FYY= =XVyn -END PGP SIGNATURE- Accepted: dgpsip_1.33-2.diff.gz to pool/main/d/dgpsip/dgpsip_1.33-2.diff.gz dgpsip_1.33-2.dsc to pool/main/d/dgpsip/dgpsip_1.33-2.dsc dgpsip_1.33-2_amd64.deb to pool/main/d/dgpsip/dgpsip_1.33-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monodevelop 0.12+dfsg-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 9 Sep 2006 23:23:45 +0200 Source: monodevelop Binary: monodevelop-versioncontrol monodevelop-nunit monodevelop-java monodevelop-boo monodevelop monodevelop-query Architecture: source all Version: 0.12+dfsg-1 Distribution: unstable Urgency: low Maintainer: Mirco Bauer [EMAIL PROTECTED] Changed-By: Mirco Bauer [EMAIL PROTECTED] Description: monodevelop - C#/Boo/Java/Nemerle/ILasm/ASP.NET Development Environment monodevelop-boo - Boo plugin for MonoDevelop monodevelop-java - Java plugin for MonoDevelop monodevelop-nunit - NUnit plugin for MonoDevelop monodevelop-query - MonoQuery plugin for MonoDevelop monodevelop-versioncontrol - VersionControl plugin for MonoDevelop Closes: 391747 Changes: monodevelop (0.12+dfsg-1) unstable; urgency=low . * DFSG version of MonoDevelop 0.12 (deleted all precompiled binaries from the tarball) * New upstream release + Added support for C# 2.0 (as supporting C# 1.0) + Added support for ASP.NET + ASP.NET designer support not enabled, it's pre-alpha and not usable. (and needs additional packages which I created for testing) * debian/watch: + Updated * debian/patches/00list: + Disabled use_xulrunner.dpatch, startup script supports xulrunner by default now. * debian/rules: + Fixed configure target dependencies. * debian/control: + Updated mono-mcs build-dep to mono-gmcs and CLI 1.0 packages to 2.0, MonoDevelop now uses C# 2.0 (gmcs). + Added libmono-system-runtime2.0-cil to build-deps. + Added stetic to build-deps. + Added mono-xsp and mono-xsp2 to build-deps (needed for ASP.NET support) + Added ASP.NET to package description. + Removed boo from Build-Conflicts-Indep, not needed anymore. + Added libsvn-dev and libapr1-dev to build-deps. (dh_clideps needs the shlibs for dep tracking) + Removed hardcoded libsvn0 and libapr0 dependencies from monodevelop-versioncontrol (dh_clideps tracks this now, Closes: #391747) Files: ff7a4d630fd351c64e64de827d31df3f 1418 devel optional monodevelop_0.12+dfsg-1.dsc 118256544cdb5e709842447c7ed781f8 2784690 devel optional monodevelop_0.12+dfsg.orig.tar.gz 13d6ff197e967bba4827af33cbfdc0bc 16833 devel optional monodevelop_0.12+dfsg-1.diff.gz de81a32ae56388ec3a0aede12a15a637 1799426 devel optional monodevelop_0.12+dfsg-1_all.deb 338520d41f28b6220fa7d71479f5b6cd 59158 devel optional monodevelop-boo_0.12+dfsg-1_all.deb 9070f93ce3999a563065ce412d168755 51404 devel optional monodevelop-java_0.12+dfsg-1_all.deb ad608b1c31305549610af14827e7bb2c 51378 devel optional monodevelop-nunit_0.12+dfsg-1_all.deb ba72273115c9590a2ddd281d0fc25f6a 53834 devel optional monodevelop-versioncontrol_0.12+dfsg-1_all.deb 9f1842064900bc330a36a936a9c838ea 67420 devel optional monodevelop-query_0.12+dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPp+P4XrXtQkN2NURAmhlAJ9IQxuY0wOm8VN6/6rg2jbKxHSJAACfaUZ0 UIhJinXLy5uPQ63BWaokgRw= =zWMP -END PGP SIGNATURE- Accepted: monodevelop-boo_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop-boo_0.12+dfsg-1_all.deb monodevelop-java_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop-java_0.12+dfsg-1_all.deb monodevelop-nunit_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop-nunit_0.12+dfsg-1_all.deb monodevelop-query_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop-query_0.12+dfsg-1_all.deb monodevelop-versioncontrol_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop-versioncontrol_0.12+dfsg-1_all.deb monodevelop_0.12+dfsg-1.diff.gz to pool/main/m/monodevelop/monodevelop_0.12+dfsg-1.diff.gz monodevelop_0.12+dfsg-1.dsc to pool/main/m/monodevelop/monodevelop_0.12+dfsg-1.dsc monodevelop_0.12+dfsg-1_all.deb to pool/main/m/monodevelop/monodevelop_0.12+dfsg-1_all.deb monodevelop_0.12+dfsg.orig.tar.gz to pool/main/m/monodevelop/monodevelop_0.12+dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ee 1:1.4.2-7 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 10:50:51 +0200 Source: ee Binary: ee Architecture: source amd64 Version: 1:1.4.2-7 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: ee - An easy editor for novices and compuphobics Changes: ee (1:1.4.2-7) unstable; urgency=low . * QA upload. * Set maintainer to QA Group; Orphaned: #392671 Files: e2100fc6a43583bd955e9e4708ef72a6 566 editors optional ee_1.4.2-7.dsc e5ddd2cf2a22ea1d5ea078e95b46f062 5518 editors optional ee_1.4.2-7.diff.gz a5d7a554ba518ddfb903341f4f07dc76 49908 editors optional ee_1.4.2-7_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPyXzEFV7g4B8rCURAvHfAJ9p45leYTgiYh65ihkBGHj2CfaPzQCfeyxa ZhGHDjStd6jL3hc+Qscmj0g= =7Db9 -END PGP SIGNATURE- Accepted: ee_1.4.2-7.diff.gz to pool/main/e/ee/ee_1.4.2-7.diff.gz ee_1.4.2-7.dsc to pool/main/e/ee/ee_1.4.2-7.dsc ee_1.4.2-7_amd64.deb to pool/main/e/ee/ee_1.4.2-7_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted positron 1:1.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 11:01:58 +0200 Source: positron Binary: positron Architecture: source all Version: 1:1.1-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: positron - synchronization manager for the Neuros Audio Computer Closes: 380895 Changes: positron (1:1.1-2) unstable; urgency=low . * QA upload. (ACK NMU; Closes: #380895) * Set maintainer to QA Group; Orphaned: #392672 Files: 0809e8ac13f9b5bb97c3014e739b698e 642 sound optional positron_1.1-2.dsc 20a43fd11d3e86e41e8d9b0f13cc5479 7138 sound optional positron_1.1-2.diff.gz a3649beaa71ca0e972f472cb36b1e738 88660 sound optional positron_1.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPyh9EFV7g4B8rCURAk8hAKDaBnxILfmYOWHbSlc/GFcvp2fYYgCcD13T VtXl/IRN0WaNhsSWrPNtcyU= =Els1 -END PGP SIGNATURE- Accepted: positron_1.1-2.diff.gz to pool/main/p/positron/positron_1.1-2.diff.gz positron_1.1-2.dsc to pool/main/p/positron/positron_1.1-2.dsc positron_1.1-2_all.deb to pool/main/p/positron/positron_1.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted network-manager 0.6.4-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 11:00:34 +0200 Source: network-manager Binary: libnm-util-dev network-manager-gnome network-manager-dev libnm-util0 libnm-glib0 network-manager libnm-glib-dev Architecture: source i386 Version: 0.6.4-5 Distribution: unstable Urgency: low Maintainer: Riccardo Setti [EMAIL PROTECTED] Changed-By: Michael Biebl [EMAIL PROTECTED] Description: libnm-glib-dev - network management framework (GLib interface) libnm-glib0 - network management framework (GLib shared library) libnm-util-dev - network management framework (development files) libnm-util0 - network management framework (shared library) network-manager - network management framework daemon network-manager-dev - network management framework (development files) network-manager-gnome - network management framework (GNOME frontend) Changes: network-manager (0.6.4-5) unstable; urgency=low . * Small fix for the NetworkManagerDispatcher init script. Files: 041a1a138990b66698676396bc76f770 1013 net optional network-manager_0.6.4-5.dsc f143c04bf41153232c84c3f8283fcb84 18886 net optional network-manager_0.6.4-5.diff.gz c2aa5d5ecf932f0a07ac6cdede72e99c 238028 net optional network-manager_0.6.4-5_i386.deb d4366f5b811ff3891ca0ed5a9947b259 368826 gnome optional network-manager-gnome_0.6.4-5_i386.deb f1299dd19b2425a6c6c679623c687494 112308 devel optional network-manager-dev_0.6.4-5_i386.deb b435838e4fa086a21127e24ae7a4671b 117580 libs optional libnm-glib0_0.6.4-5_i386.deb ac1bdbf88273c8cf158e82924ba172d4 118006 libdevel optional libnm-glib-dev_0.6.4-5_i386.deb c2102e0aa839f272fdd24b21cfd82951 123286 libs optional libnm-util0_0.6.4-5_i386.deb 99cb420678294a4ae290db410c1b0450 125670 libdevel optional libnm-util-dev_0.6.4-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPynxh7PER70FhVQRAmEmAKCx1rdnNshGSHhQO+PzZwyuREsCrACfaWdJ jGZ5Nf2+TqRoEoQScKUmSA0= =pNmm -END PGP SIGNATURE- Accepted: libnm-glib-dev_0.6.4-5_i386.deb to pool/main/n/network-manager/libnm-glib-dev_0.6.4-5_i386.deb libnm-glib0_0.6.4-5_i386.deb to pool/main/n/network-manager/libnm-glib0_0.6.4-5_i386.deb libnm-util-dev_0.6.4-5_i386.deb to pool/main/n/network-manager/libnm-util-dev_0.6.4-5_i386.deb libnm-util0_0.6.4-5_i386.deb to pool/main/n/network-manager/libnm-util0_0.6.4-5_i386.deb network-manager-dev_0.6.4-5_i386.deb to pool/main/n/network-manager/network-manager-dev_0.6.4-5_i386.deb network-manager-gnome_0.6.4-5_i386.deb to pool/main/n/network-manager/network-manager-gnome_0.6.4-5_i386.deb network-manager_0.6.4-5.diff.gz to pool/main/n/network-manager/network-manager_0.6.4-5.diff.gz network-manager_0.6.4-5.dsc to pool/main/n/network-manager/network-manager_0.6.4-5.dsc network-manager_0.6.4-5_i386.deb to pool/main/n/network-manager/network-manager_0.6.4-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted diffmon 20020222-2.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 11:15:18 +0200 Source: diffmon Binary: diffmon Architecture: source all Version: 20020222-2.2 Distribution: unstable Urgency: medium Maintainer: Jeff Bailey [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: diffmon- Tool for reporting changes in system configuration. Closes: 382132 Changes: diffmon (20020222-2.2) unstable; urgency=medium . * Non-maintainer upload. * Fix a security hole with bad umask (Closes: #382132) * Bump standards version * Change Build-Depends-Indep to Build-Depends Files: 9de192ba6dcbb6dffb1150d99357b5fd 505 admin optional diffmon_20020222-2.2.dsc 7ac202b3e6a4ed4eca42ff20975c60e9 15726 admin optional diffmon_20020222-2.2.tar.gz b4fa52f9e376b63f5b68d9b0a4224cdd 12050 admin optional diffmon_20020222-2.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPyuLpGK1HsL+5c0RAsm5AJ45PDJ2poxsedp/zpQfEGPPZwPMzQCcDyG4 5zIyFPc/XVUzwPN95XvguYQ= =zC6k -END PGP SIGNATURE- Accepted: diffmon_20020222-2.2.dsc to pool/main/d/diffmon/diffmon_20020222-2.2.dsc diffmon_20020222-2.2.tar.gz to pool/main/d/diffmon/diffmon_20020222-2.2.tar.gz diffmon_20020222-2.2_all.deb to pool/main/d/diffmon/diffmon_20020222-2.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-headers 2.6.18-6 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 05:14:08 -0400 Source: linux-kernel-headers Binary: linux-kernel-headers Architecture: source sparc Version: 2.6.18-6 Distribution: unstable Urgency: high Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Changed-By: Clint Adams [EMAIL PROTECTED] Description: linux-kernel-headers - Linux Kernel Headers for development Closes: 395135 Changes: linux-kernel-headers (2.6.18-6) unstable; urgency=high . * Add alpha-asm-compiler.patch from Steve Langasek: Don't hide the __always_inline define inside #ifdef __KERNEL__, because the uses of it sure aren't hidden there! closes: #395135. Files: ca04eff8632d8882b4dfc759272e497a 881 devel standard linux-kernel-headers_2.6.18-6.dsc 98d659a78c17907a60ed94bca3cfd4e6 24616 devel standard linux-kernel-headers_2.6.18-6.diff.gz 2acef425960a81f8c03d7ebae3921da8 1857558 devel standard linux-kernel-headers_2.6.18-6_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Debian! iD8DBQFFPyz75m0u66uWM3ARApdeAJwNQwu1SFbvhJdkPWX6/PVXZAq9TACfSndV 5BrHtV53ErkZdahlfDnZfSs= =Hx9i -END PGP SIGNATURE- Accepted: linux-kernel-headers_2.6.18-6.diff.gz to pool/main/l/linux-kernel-headers/linux-kernel-headers_2.6.18-6.diff.gz linux-kernel-headers_2.6.18-6.dsc to pool/main/l/linux-kernel-headers/linux-kernel-headers_2.6.18-6.dsc linux-kernel-headers_2.6.18-6_sparc.deb to pool/main/l/linux-kernel-headers/linux-kernel-headers_2.6.18-6_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nfs-utils 1:1.0.10-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 11:50:52 +0200 Source: nfs-utils Binary: nhfsstone nfs-kernel-server nfs-common Architecture: source i386 Version: 1:1.0.10-3 Distribution: unstable Urgency: low Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED] Changed-By: Steinar H. Gunderson [EMAIL PROTECTED] Description: nfs-common - NFS support files common to client and server nfs-kernel-server - Kernel NFS server support nhfsstone - NFS benchmark program Closes: 394810 394916 Changes: nfs-utils (1:1.0.10-3) unstable; urgency=low . * Copy the do_modprobe() definition from nfs-kernel-server.init to nfs-common.init, fixing spurious warnings when running a non-modular kernel. (Closes: #394810) * Wrap README.Debian.nfsv4 at 80 columns. (Closes: #394916) * In README.Debian.nfsv4, added a note about /etc/hosts entries containing non-global IP addresses. Files: 9a44a24061cc603a1ff0b687a820ea68 971 net standard nfs-utils_1.0.10-3.dsc 8fb9c7fdbf6267eff6ad8c4358968e6f 26302 net standard nfs-utils_1.0.10-3.diff.gz 2cb86107cb214820c7e6e21116aa6ec4 133238 net optional nfs-kernel-server_1.0.10-3_i386.deb 6ceb0ed51cc86c841abe9e28886dfadd 125868 net standard nfs-common_1.0.10-3_i386.deb e1d7029f838030ac4d47160935d47c8e 66290 net extra nhfsstone_1.0.10-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRT81an7hqgLJpbVOAQJ+ewP+MraA3GrR9MQZFBJfLUMUWOlTg/ymL+lH 8HO67T63utbmjUbhq1uSrBNmD4KAu8cA+KWJjWjUCqn0zdgP571OpfCYANlCEWbj TXPIiOqFQ2qtzINpVpqTEkEOTvpXOjMbKpSLVRIhNkNgud/5isfvMYOqSJzWCvTc wRcll3g+XPo= =bqC5 -END PGP SIGNATURE- Accepted: nfs-common_1.0.10-3_i386.deb to pool/main/n/nfs-utils/nfs-common_1.0.10-3_i386.deb nfs-kernel-server_1.0.10-3_i386.deb to pool/main/n/nfs-utils/nfs-kernel-server_1.0.10-3_i386.deb nfs-utils_1.0.10-3.diff.gz to pool/main/n/nfs-utils/nfs-utils_1.0.10-3.diff.gz nfs-utils_1.0.10-3.dsc to pool/main/n/nfs-utils/nfs-utils_1.0.10-3.dsc nhfsstone_1.0.10-3_i386.deb to pool/main/n/nfs-utils/nhfsstone_1.0.10-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gforge 4.5.14-16 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 12:12:11 +0200 Source: gforge Binary: gforge-lists-mailman gforge-db-postgresql gforge-mta-postfix gforge-shell-ldap gforge gforge-common gforge-web-apache gforge-mta-exim gforge-mta-courier gforge-ftp-proftpd gforge-shell-postgresql gforge-mta-exim4 gforge-dns-bind9 gforge-ldap-openldap Architecture: source all Version: 4.5.14-16 Distribution: unstable Urgency: high Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: gforge - collaborative development tool - meta-package gforge-common - collaborative development tool - shared files gforge-db-postgresql - collaborative development tool - database (using PostgreSQL) gforge-dns-bind9 - collaborative development tool - DNS management (using Bind9) gforge-ftp-proftpd - collaborative development tool - FTP management (using ProFTPd) gforge-ldap-openldap - collaborative development tool - LDAP directory (using OpenLDAP) gforge-lists-mailman - collaborative development tool - mailing-lists (using Mailman) gforge-mta-courier - collaborative development tool - mail tools (using Courier) gforge-mta-exim - collaborative development tool - mail tools (using Exim) gforge-mta-exim4 - collaborative development tool - mail tools (using Exim 4) gforge-mta-postfix - collaborative development tool - mail tools (using Postfix) gforge-shell-ldap - collaborative development tool - shell accounts (using LDAP) gforge-shell-postgresql - collaborative development tool - shell accounts (using PostgreSQL gforge-web-apache - collaborative development tool - web part (using Apache) Closes: 394933 395088 Changes: gforge (4.5.14-16) unstable; urgency=high . * [Roland] install-nsspgsql.sh: Create an empty pam_pgsql.conf if it doesn't exist prior to installation. * [Roland] install-ldap.sh: Ditto for libnss-ldap.conf. * [Roland] gforge-mta-exim4: Invoke update-exim4.conf on installation and removal, so Exim is actually configured... * [Roland] fix-mailing-lists.pl needs to be run as root, not gforge, otherwise it has no access to the mailing-lists data. Fixed gforge-mta-mailman.postinst and fix-mailing-lists.pl accordingly. * [Roland] install-db.sh: Made purge more resistant (closes: #395088). * [Roland] install-ldap.sh: Made installation more resistant. * [Roland] Made Apache setup less invasive (closes: #394933). Files: 6c6374745c2fad746c95e445fee85cf6 939 devel optional gforge_4.5.14-16.dsc e8ff9c9b84c7847e8843d431bcdc3606 50355 devel optional gforge_4.5.14-16.diff.gz 479214bcd0e0e5758a1101385726912f 78910 devel optional gforge_4.5.14-16_all.deb 0766afba8468c7e457f9453d93b40b91 1008660 devel optional gforge-common_4.5.14-16_all.deb 940513d6286caa5f178d37c6d43f9512 699248 devel optional gforge-web-apache_4.5.14-16_all.deb 10297a38917f5c592f9a26801d2f43d9 205586 devel optional gforge-db-postgresql_4.5.14-16_all.deb f4dbba1addfc97c1dd3648fa7e300859 85876 devel optional gforge-mta-exim4_4.5.14-16_all.deb 7f5e04f5039c761fc6f96a0bed437055 85372 devel optional gforge-mta-exim_4.5.14-16_all.deb a4ce1d4394d78e8c0b2531e2b11af1c0 85274 devel optional gforge-mta-postfix_4.5.14-16_all.deb 11b19eea94b7a0c6abf3f4ae32240700 74724 devel optional gforge-mta-courier_4.5.14-16_all.deb fe1c5489972259cbb4299607cb1d5874 83326 devel optional gforge-shell-ldap_4.5.14-16_all.deb d306906b7206fc7172571294c10ac919 84962 devel optional gforge-shell-postgresql_4.5.14-16_all.deb b2361f26706877f0ec8e2af4c74f88cf 83912 devel optional gforge-ftp-proftpd_4.5.14-16_all.deb 0b39b42e3605da34ed5a243e3964ceaf 92880 devel optional gforge-ldap-openldap_4.5.14-16_all.deb 4d24f27fa1481347580135d1107984ac 94334 devel optional gforge-dns-bind9_4.5.14-16_all.deb 02cf292666ca26710a6aaa687a5019ae 80744 devel optional gforge-lists-mailman_4.5.14-16_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPzqADqdWtRRIQ/URAgrLAJ93pK2RFJZvauh79eu2TksepE+aRACfQhkn NxLKWzNF9IWw4Qxh7rccC5c= =/H06 -END PGP SIGNATURE- Accepted: gforge-common_4.5.14-16_all.deb to pool/main/g/gforge/gforge-common_4.5.14-16_all.deb gforge-db-postgresql_4.5.14-16_all.deb to pool/main/g/gforge/gforge-db-postgresql_4.5.14-16_all.deb gforge-dns-bind9_4.5.14-16_all.deb to pool/main/g/gforge/gforge-dns-bind9_4.5.14-16_all.deb gforge-ftp-proftpd_4.5.14-16_all.deb to pool/main/g/gforge/gforge-ftp-proftpd_4.5.14-16_all.deb gforge-ldap-openldap_4.5.14-16_all.deb to pool/main/g/gforge/gforge-ldap-openldap_4.5.14-16_all.deb gforge-lists-mailman_4.5.14-16_all.deb to pool/main/g/gforge/gforge-lists-mailman_4.5.14-16_all.deb gforge-mta-courier_4.5.14-16_all.deb to pool/main/g/gforge/gforge-mta-courier_4.5.14-16_all.deb gforge-mta-exim4_4.5.14-16_all.deb to pool/main/g/gforge/gforge-mta-exim4_4.5.14-16_all.deb gforge-mta-exim_4.5.14-16_all.deb to pool/main/g/gforge/gforge-mta-exim_4.5.14-16_all.deb
Accepted powersave 0.14.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 Oct 2006 01:02:01 +0200 Source: powersave Binary: libpowersave-dev libpowersave10 powersaved Architecture: source i386 Version: 0.14.0-3 Distribution: unstable Urgency: low Maintainer: Michael Biebl [EMAIL PROTECTED] Changed-By: Michael Biebl [EMAIL PROTECTED] Description: libpowersave-dev - power management daemon - development files libpowersave10 - power management daemon - shared library powersaved - power management daemon Closes: 372295 377798 390792 Changes: powersave (0.14.0-3) unstable; urgency=low . * Update maintainer email address to [EMAIL PROTECTED] * debian/patches/dont_unload_ipw2200.patch - Added. Do not blacklist ipw2200 module. Closes: #390792 * debian/patches/power_button_event.patch - Added. Do not shut down by default when power button is pressed. Closes: #372295 - If you want to restore previous behaviour, set EVENT_BUTTON_POWER to wm_shutdown in /etc/powersave/events. * debian/patches/uswsusp.patch - Added. Support for userspace software suspend. Closes: #377798 Install the uswsusp package and set SUSPEND2DISK_METHOD to userspace in /etc/powersave/sleep if you want to use this method. * debian/control - Add a Recommends on uswsusp. Files: 1393b61870c733f317c39cb6c7d9f166 778 admin optional powersave_0.14.0-3.dsc b49dd035d84ef477fe956278f696c9da 11611 admin optional powersave_0.14.0-3.diff.gz 83736bf5b80269acb43eef45088408b2 445308 admin optional powersaved_0.14.0-3_i386.deb 957aba10b174af722e3ed535516f17f5 44890 libs optional libpowersave10_0.14.0-3_i386.deb 184228a5b0061b14672f55fba41d6112 56106 libdevel optional libpowersave-dev_0.14.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFPzinh7PER70FhVQRAsnzAJ9ZJIlVbWSrtKzEhLHl/hRDeMo/2QCfRq1Q hkPt2scDesKA56je0A+84M8= =4ruU -END PGP SIGNATURE- Accepted: libpowersave-dev_0.14.0-3_i386.deb to pool/main/p/powersave/libpowersave-dev_0.14.0-3_i386.deb libpowersave10_0.14.0-3_i386.deb to pool/main/p/powersave/libpowersave10_0.14.0-3_i386.deb powersave_0.14.0-3.diff.gz to pool/main/p/powersave/powersave_0.14.0-3.diff.gz powersave_0.14.0-3.dsc to pool/main/p/powersave/powersave_0.14.0-3.dsc powersaved_0.14.0-3_i386.deb to pool/main/p/powersave/powersaved_0.14.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-django 0.95-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 Oct 2006 12:10:27 +0200 Source: python-django Binary: python-django Architecture: source all Version: 0.95-1 Distribution: unstable Urgency: low Maintainer: Brett Parker [EMAIL PROTECTED] Changed-By: Raphael Hertzog [EMAIL PROTECTED] Description: python-django - A high-level Python Web framework Changes: python-django (0.95-1) unstable; urgency=low . [ Brett Parker ] * 0.95 release - initial packaging . [ Raphael Hertzog ] * Fix recommends: s/python-sqlite/python-pysqlite2/ * Add debian/pyversions to ensure that we have at least python 2.3 (and to work around bug #391689 of python-support). Files: 3ebfc94427f7b0670543483f2d8bb59e 805 python optional python-django_0.95-1.dsc 9ed7d6a0daa147c012e31d0894802951 1287781 python optional python-django_0.95.orig.tar.gz 6d8633bf0d823751fcee81e73c5866c2 2559 python optional python-django_0.95-1.diff.gz 1b800974556a5b9150f27161ddd76c08 1025964 python optional python-django_0.95-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKiH0vPbGD26BadIRAs4GAKC7BOPK/JSW2S8apveCVlSe7O5AoQCcDksA G5h14iyWR0+gibYJ3EUpbtY= =s2Mp -END PGP SIGNATURE- Accepted: python-django_0.95-1.diff.gz to pool/main/p/python-django/python-django_0.95-1.diff.gz python-django_0.95-1.dsc to pool/main/p/python-django/python-django_0.95-1.dsc python-django_0.95-1_all.deb to pool/main/p/python-django/python-django_0.95-1_all.deb python-django_0.95.orig.tar.gz to pool/main/p/python-django/python-django_0.95.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-plugins-farsight 0.10.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 Oct 2006 12:12:29 -0400 Source: gst-plugins-farsight Binary: gstreamer0.10-plugins-farsight Architecture: source i386 Version: 0.10.2-1 Distribution: unstable Urgency: low Maintainer: Dafydd Harries [EMAIL PROTECTED] Changed-By: Dafydd Harries [EMAIL PROTECTED] Description: gstreamer0.10-plugins-farsight - Gstreamer plugins for audio/video conferencing Changes: gst-plugins-farsight (0.10.2-1) unstable; urgency=low . * New upstream release. Files: ca0c45220316440629cf0a8d80d96414 762 sound optional gst-plugins-farsight_0.10.2-1.dsc 77c92554c2bd57ad1b426e5ba50eb9a8 442873 sound optional gst-plugins-farsight_0.10.2.orig.tar.gz d201a217b7fe6f7ca6a670f3d165fa8a 2769 sound optional gst-plugins-farsight_0.10.2-1.diff.gz 243496b28e6d2fbfb7d05ad1fa0906a0 53342 sound optional gstreamer0.10-plugins-farsight_0.10.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKsFOpD5tJxKCh+gRAuBeAJwKGPatG06NwMtaR9W3/H6avM796ACePUiG lUYosiXwde2g633o7nV4lUM= =FuPd -END PGP SIGNATURE- Accepted: gst-plugins-farsight_0.10.2-1.diff.gz to pool/main/g/gst-plugins-farsight/gst-plugins-farsight_0.10.2-1.diff.gz gst-plugins-farsight_0.10.2-1.dsc to pool/main/g/gst-plugins-farsight/gst-plugins-farsight_0.10.2-1.dsc gst-plugins-farsight_0.10.2.orig.tar.gz to pool/main/g/gst-plugins-farsight/gst-plugins-farsight_0.10.2.orig.tar.gz gstreamer0.10-plugins-farsight_0.10.2-1_i386.deb to pool/main/g/gst-plugins-farsight/gstreamer0.10-plugins-farsight_0.10.2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mahoro 0.1-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 Oct 2006 07:44:13 +0200 Source: mahoro Binary: mahoro-ruby1.8 mahoro-ruby Architecture: source all i386 Version: 0.1-1 Distribution: unstable Urgency: low Maintainer: Romain Francoise [EMAIL PROTECTED] Changed-By: Romain Francoise [EMAIL PROTECTED] Description: mahoro-ruby - File type determination library for Ruby mahoro-ruby1.8 - File type determination library for Ruby 1.8 Closes: 391839 Changes: mahoro (0.1-1) unstable; urgency=low . * Initial release (closes: #391839). Files: 351b1bf7227e3390c2e2ce6cb9179a27 610 interpreters optional mahoro_0.1-1.dsc ef875ddda8ced77819c3183c60ffada3 1820 interpreters optional mahoro_0.1.orig.tar.gz 7a55679be825fa90c89e9429013ed4bc 1149 interpreters optional mahoro_0.1-1.diff.gz 269ded3f64908c7688866c3502c7a4b4 1462 interpreters optional mahoro-ruby_0.1-1_all.deb aafa85701ca86245a3415db705dc8650 4654 interpreters optional mahoro-ruby1.8_0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKeQCogN2vsA8Vt8RAhjWAJ92lsS4tQLxfhyj6621uawBZnN8LwCgtZGd UFzWwDU/Mv+DL+mNi4RASq8= =BjuK -END PGP SIGNATURE- Accepted: mahoro-ruby1.8_0.1-1_i386.deb to pool/main/m/mahoro/mahoro-ruby1.8_0.1-1_i386.deb mahoro-ruby_0.1-1_all.deb to pool/main/m/mahoro/mahoro-ruby_0.1-1_all.deb mahoro_0.1-1.diff.gz to pool/main/m/mahoro/mahoro_0.1-1.diff.gz mahoro_0.1-1.dsc to pool/main/m/mahoro/mahoro_0.1-1.dsc mahoro_0.1.orig.tar.gz to pool/main/m/mahoro/mahoro_0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted audacious 1.1.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 1 Sep 2006 20:56:15 +0200 Source: audacious Binary: audacious-plugins libaudacious-dev audacious libaudacious3 Architecture: source i386 Version: 1.1.2-1 Distribution: unstable Urgency: low Maintainer: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Changed-By: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Description: audacious - Small and fast audio player which supports lots of formats audacious-plugins - Various extra plugins for audacious libaudacious-dev - Audacious C++ library (development files) libaudacious3 - Audacious C++ shared library Closes: 360524 Changes: audacious (1.1.2-1) unstable; urgency=low . * Initial release (Closes: #360524). Files: f8ec8a1c79afd7ae26ba0b9176782d36 1340 sound optional audacious_1.1.2-1.dsc 14aba1f9c42a48afeeb6ce5dcaf180c6 3394364 sound optional audacious_1.1.2.orig.tar.gz 485de13103483025f119dcf562562350 21959 sound optional audacious_1.1.2-1.diff.gz dbc39c2beb2847ab2b26776f4e7220d1 986702 sound optional audacious_1.1.2-1_i386.deb b1be02fc832706fc850c00a23d24d4ad 8788 libdevel optional libaudacious-dev_1.1.2-1_i386.deb c38946fdd91b31c7f88e828b3161a4c1 158486 libs optional libaudacious3_1.1.2-1_i386.deb 2e0ddf13f2a5221726fea510ab3cc652 899744 sound optional audacious-plugins_1.1.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKtfB+C5cwEsrK54RAm/5AKCfzmCKlxjgpIJwJ/YARoieQOe2XACgzotw 2Q0JldCQXdeP+gpJF47ReZQ= =joPr -END PGP SIGNATURE- Accepted: audacious-plugins_1.1.2-1_i386.deb to pool/main/a/audacious/audacious-plugins_1.1.2-1_i386.deb audacious_1.1.2-1.diff.gz to pool/main/a/audacious/audacious_1.1.2-1.diff.gz audacious_1.1.2-1.dsc to pool/main/a/audacious/audacious_1.1.2-1.dsc audacious_1.1.2-1_i386.deb to pool/main/a/audacious/audacious_1.1.2-1_i386.deb audacious_1.1.2.orig.tar.gz to pool/main/a/audacious/audacious_1.1.2.orig.tar.gz libaudacious-dev_1.1.2-1_i386.deb to pool/main/a/audacious/libaudacious-dev_1.1.2-1_i386.deb libaudacious3_1.1.2-1_i386.deb to pool/main/a/audacious/libaudacious3_1.1.2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted backport-util-concurrent 2.2+dfsg-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Oct 2006 14:33:47 +0200 Source: backport-util-concurrent Binary: libbackport-util-concurrent-java Architecture: source all Version: 2.2+dfsg-1 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers pkg-java-maintainers@lists.alioth.debian.org Changed-By: Marcus Better [EMAIL PROTECTED] Description: libbackport-util-concurrent-java - backport of java.util.concurrent to Java 1.4 Closes: 392097 Changes: backport-util-concurrent (2.2+dfsg-1) unstable; urgency=low . * Initial release. (Closes: #392097) Files: 269e935fb1c046167c8a819499ba7bde 794 libs optional backport-util-concurrent_2.2+dfsg-1.dsc bd1f3f17b02d9e922fa1a74b8eb56fce 652792 libs optional backport-util-concurrent_2.2+dfsg.orig.tar.gz 37bcace5c5e7acb63d2b82faf6323020 1834 libs optional backport-util-concurrent_2.2+dfsg-1.diff.gz fc06664e47b59167a4e25bda2ddf4761 595640 libs optional libbackport-util-concurrent-java_2.2+dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK55i+C5cwEsrK54RAsL7AJ9XUfczFOP6pKf2EqftMvMPni5xtQCeKEF0 TCo4ev/BHLnQCThTW4RGBWQ= =ApkH -END PGP SIGNATURE- Accepted: backport-util-concurrent_2.2+dfsg-1.diff.gz to pool/main/b/backport-util-concurrent/backport-util-concurrent_2.2+dfsg-1.diff.gz backport-util-concurrent_2.2+dfsg-1.dsc to pool/main/b/backport-util-concurrent/backport-util-concurrent_2.2+dfsg-1.dsc backport-util-concurrent_2.2+dfsg.orig.tar.gz to pool/main/b/backport-util-concurrent/backport-util-concurrent_2.2+dfsg.orig.tar.gz libbackport-util-concurrent-java_2.2+dfsg-1_all.deb to pool/main/b/backport-util-concurrent/libbackport-util-concurrent-java_2.2+dfsg-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hellanzb 0.9-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Sep 2006 21:12:36 +0200 Source: hellanzb Binary: hellanzb Architecture: source all Version: 0.9-1 Distribution: unstable Urgency: low Maintainer: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Changed-By: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Description: hellanzb - Newzbin (nzb) BinNews (bns) files downloader and post-processor Closes: 386706 Changes: hellanzb (0.9-1) unstable; urgency=low . * Initial release (Closes: #386706). Files: a51a3e2f9826eba16157524e91af36f3 654 net optional hellanzb_0.9-1.dsc 2564b78b0639c4f4e7b128d00a51dcf4 146537 net optional hellanzb_0.9.orig.tar.gz 9c0e15e10aaf79a862c9ff0dc863e422 7717 net optional hellanzb_0.9-1.diff.gz 221ae62db3ecf847677d00d5f92a45b9 154476 net optional hellanzb_0.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK6cP+C5cwEsrK54RAhqgAKC1bS8jCbkRmzUtsC2ZSncetzGaXwCfa1A/ Yi5KAuNuMEri7z+ZUcpQWMs= =Vo0W -END PGP SIGNATURE- Accepted: hellanzb_0.9-1.diff.gz to pool/main/h/hellanzb/hellanzb_0.9-1.diff.gz hellanzb_0.9-1.dsc to pool/main/h/hellanzb/hellanzb_0.9-1.dsc hellanzb_0.9-1_all.deb to pool/main/h/hellanzb/hellanzb_0.9-1_all.deb hellanzb_0.9.orig.tar.gz to pool/main/h/hellanzb/hellanzb_0.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted createrepo 0.4.6-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Sep 2006 10:14:17 +0200 Source: createrepo Binary: createrepo Architecture: source all Version: 0.4.6-1 Distribution: unstable Urgency: low Maintainer: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Changed-By: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Description: createrepo - generates the metadata necessary for a RPM package repository Closes: 386953 Changes: createrepo (0.4.6-1) unstable; urgency=low . * Initial release (Closes: #386953). Files: 8168529206a8f765de3e8dec869a1afa 647 admin optional createrepo_0.4.6-1.dsc b4f5228c5e2058c3e5a6b4c66ac6a260 20311 admin optional createrepo_0.4.6.orig.tar.gz f03ab539ce3f4f661168a9ef65cf5d18 1578 admin optional createrepo_0.4.6-1.diff.gz be013c0ea630abe837ff4473037137bd 20976 admin optional createrepo_0.4.6-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK6Wf+C5cwEsrK54RAizWAJ9GPLC4BA9AUVCAHuV9c+x619kO+QCffOVX bXXq5p4BeHvOtTg/5d3rew8= =XM9Q -END PGP SIGNATURE- Accepted: createrepo_0.4.6-1.diff.gz to pool/main/c/createrepo/createrepo_0.4.6-1.diff.gz createrepo_0.4.6-1.dsc to pool/main/c/createrepo/createrepo_0.4.6-1.dsc createrepo_0.4.6-1_all.deb to pool/main/c/createrepo/createrepo_0.4.6-1_all.deb createrepo_0.4.6.orig.tar.gz to pool/main/c/createrepo/createrepo_0.4.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ghc6 6.6-3 (source all arm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 22 Oct 2006 22:36:32 + Source: ghc6 Binary: ghc6-prof ghc6 ghc6-libsrc ghc6-doc Architecture: source all arm Version: 6.6-3 Distribution: unstable Urgency: low Maintainer: Ian Lynagh (wibble) [EMAIL PROTECTED] Changed-By: Ian Lynagh (wibble) [EMAIL PROTECTED] Description: ghc6 - GHC - the Glasgow Haskell Compilation system ghc6-doc - Documentation for the Glasgow Haskell Compilation system ghc6-libsrc - Library Sources of GHC, the Glasgow Haskell Compilation system ghc6-prof - Profiling libraries for the Glasgow Haskell Compilation system Changes: ghc6 (6.6-3) unstable; urgency=low . * Add arm to the list of arches that have ghc6. * Add arm to the arches in compiler/cmm/PprC.hs for which loads and stores to be printed in a way that works if they are not aligned as the arch wishes. * For arm's odd floating point numbers: * Add FPTOOLS_FLOAT_WORD_ORDER_BIGENDIAN test to aclocal.m4 * Call FPTOOLS_FLOAT_WORD_ORDER_BIGENDIAN after AC_C_BIGENDIAN in configure.ac. * Extra section for the FPTOOLS_FLOAT_WORD_ORDER_BIGENDIAN test in configure. * Add #undef FLOAT_WORDS_BIGENDIAN to mk/config.h.in. * Add FLOAT_WORDS_BIGENDIAN cases to rts/StgPrimFloat.c. * Apply the following upstream patch, to fix potential problems compiling ghc6 on amd64 (and possibly others): . Fri Oct 20 16:39:25 BST 2006 Simon Marlow [EMAIL PROTECTED] * In hashExpr, use Word32 rather than relying on wrapping behaviour of Int Fixes #952, as it turns out. . When compiling via C, we are at the mercy of C's undefined behaviour with respect to overflow of signed integer operations, and this was biting us here. . Perhaps we should always add the -fwrapv flag to gcc, but since Haskell doesn't define overflow on Int either, it seemed the right thing to do to fix this code anyway. Files: 1060f3c6773411d0a3c9e3fc99c66dfb 806 devel optional ghc6_6.6-3.dsc 70ca7322bc629e0f379ff251bcf03023 24632 devel optional ghc6_6.6-3.diff.gz 2352b6c33990b48b6d92cfb438a08573 1010618 doc optional ghc6-doc_6.6-3_all.deb 9dcc4575218671d9d9219f0096c3ff0b 866012 doc optional ghc6-libsrc_6.6-3_all.deb da3d61971dffb35ed9fc2f21cbddc55c 23578638 devel optional ghc6_6.6-3_arm.deb 6e8e91701b979e237c7c0f9988d62949 9413972 devel optional ghc6-prof_6.6-3_arm.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFP06G63y6poDIPo4RAnVbAJ9nmDaZkKLlh3+HAxkS5nEWVrH7dgCfYIUw o8hGN7gN24Q7flLvwttlQug= =wgSc -END PGP SIGNATURE- Accepted: ghc6-doc_6.6-3_all.deb to pool/main/g/ghc6/ghc6-doc_6.6-3_all.deb ghc6-libsrc_6.6-3_all.deb to pool/main/g/ghc6/ghc6-libsrc_6.6-3_all.deb ghc6-prof_6.6-3_arm.deb to pool/main/g/ghc6/ghc6-prof_6.6-3_arm.deb ghc6_6.6-3.diff.gz to pool/main/g/ghc6/ghc6_6.6-3.diff.gz ghc6_6.6-3.dsc to pool/main/g/ghc6/ghc6_6.6-3.dsc ghc6_6.6-3_arm.deb to pool/main/g/ghc6/ghc6_6.6-3_arm.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted grepcidr 1.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 Oct 2006 01:58:17 -0700 Source: grepcidr Binary: grepcidr Architecture: source i386 Version: 1.3-1 Distribution: unstable Urgency: low Maintainer: Ryan Finnie [EMAIL PROTECTED] Changed-By: Ryan Finnie [EMAIL PROTECTED] Description: grepcidr - Filter IP addresses matching IPv4 CIDR/network specification Closes: 391168 Changes: grepcidr (1.3-1) unstable; urgency=low . * Initial release (Closes: #391168) Files: d42bbc6e365dd99f01ee4f415e8ad90e 574 net optional grepcidr_1.3-1.dsc 7ccade25ce9fe6d6a02348ba8e4cf4a3 21691 net optional grepcidr_1.3.orig.tar.gz 983aba2771d2e8e2dbf5bec6a666d0ac 5729 net optional grepcidr_1.3-1.diff.gz 88656e38a07ecbded0de87a2c066f246 9054 net optional grepcidr_1.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK9U0gZalRGu6PIQRAhS5AJ9v47rNuh0uY6j6288i4Y4rvgBqMQCdHuwl KYSB0K3VZX3sHW3X/RWPOnM= =Ugva -END PGP SIGNATURE- Accepted: grepcidr_1.3-1.diff.gz to pool/main/g/grepcidr/grepcidr_1.3-1.diff.gz grepcidr_1.3-1.dsc to pool/main/g/grepcidr/grepcidr_1.3-1.dsc grepcidr_1.3-1_i386.deb to pool/main/g/grepcidr/grepcidr_1.3-1_i386.deb grepcidr_1.3.orig.tar.gz to pool/main/g/grepcidr/grepcidr_1.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ink 0.3.2~rc3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Sep 2006 20:20:06 +0200 Source: ink Binary: ink Architecture: source i386 Version: 0.3.2~rc3-1 Distribution: unstable Urgency: low Maintainer: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Changed-By: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Description: ink- tool for checking the ink level of your local printer Closes: 386878 Changes: ink (0.3.2~rc3-1) unstable; urgency=low . * Initial release (Closes: #386878). Files: 5dda5ef7632977d2121ca4128b2d88cc 594 admin optional ink_0.3.2~rc3-1.dsc 26bcd7aa589f250eeae7a9a7c65db8ec 8822 admin optional ink_0.3.2~rc3.orig.tar.gz 11673f25dc0deae2ce33afbdb1e29cde 2227 admin optional ink_0.3.2~rc3-1.diff.gz fffecbabe525e53c55f4589dda961fb9 5980 admin optional ink_0.3.2~rc3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK6lI+C5cwEsrK54RAqETAKCR+H1y71XEJDbX9fpNaC5X6FGxIgCg4hdK X2ypdF7iXu70PJAFg9bFqtQ= =sU/f -END PGP SIGNATURE- Accepted: ink_0.3.2~rc3-1.diff.gz to pool/main/i/ink/ink_0.3.2~rc3-1.diff.gz ink_0.3.2~rc3-1.dsc to pool/main/i/ink/ink_0.3.2~rc3-1.dsc ink_0.3.2~rc3-1_i386.deb to pool/main/i/ink/ink_0.3.2~rc3-1_i386.deb ink_0.3.2~rc3.orig.tar.gz to pool/main/i/ink/ink_0.3.2~rc3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libinklevel 0.6.6~rc5-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Sep 2006 17:54:08 +0200 Source: libinklevel Binary: libinklevel3 libinklevel-dev Architecture: source i386 Version: 0.6.6~rc5-1 Distribution: unstable Urgency: low Maintainer: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Changed-By: Adam Cécile (Le_Vert) [EMAIL PROTECTED] Description: libinklevel-dev - development files for libinklevel3 libinklevel3 - library for checking the ink level of your local printer Closes: 386849 Changes: libinklevel (0.6.6~rc5-1) unstable; urgency=low . * Initial release (Closes: #386849). Files: 1fb5e0a131f1f7c6ca3087502c539273 640 libs optional libinklevel_0.6.6~rc5-1.dsc e1ac2a8f24a1b553e884c1edf1bf5271 29495 libs optional libinklevel_0.6.6~rc5.orig.tar.gz ea69bdda65a3f212f8aac926da0a0a5a 3180 libs optional libinklevel_0.6.6~rc5-1.diff.gz 9e4ec2d3a1c1bd6c5284f827a570a4eb 1900 libdevel optional libinklevel-dev_0.6.6~rc5-1_i386.deb 9b3ed2e499ecc9758d459563c4dcbdf7 20008 libs optional libinklevel3_0.6.6~rc5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK6hg+C5cwEsrK54RAjbvAJ9LRczm8E5MdMs3DD5V+z4zDQ9AbgCfTqoy JEmKRJXdbY3xEWYUnPM1j7k= =8KiC -END PGP SIGNATURE- Accepted: libinklevel-dev_0.6.6~rc5-1_i386.deb to pool/main/libi/libinklevel/libinklevel-dev_0.6.6~rc5-1_i386.deb libinklevel3_0.6.6~rc5-1_i386.deb to pool/main/libi/libinklevel/libinklevel3_0.6.6~rc5-1_i386.deb libinklevel_0.6.6~rc5-1.diff.gz to pool/main/libi/libinklevel/libinklevel_0.6.6~rc5-1.diff.gz libinklevel_0.6.6~rc5-1.dsc to pool/main/libi/libinklevel/libinklevel_0.6.6~rc5-1.dsc libinklevel_0.6.6~rc5.orig.tar.gz to pool/main/libi/libinklevel/libinklevel_0.6.6~rc5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gw-fonts-ttf 1.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 Oct 2006 00:10:03 +0200 Source: gw-fonts-ttf Binary: ttf-georgewilliams Architecture: source all Version: 1.0-1 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün [EMAIL PROTECTED] Changed-By: Gürkan Sengün [EMAIL PROTECTED] Description: ttf-georgewilliams - Free unicode TrueType fonts by George Williams Closes: 391662 Changes: gw-fonts-ttf (1.0-1) unstable; urgency=low . * Initial release. (Closes: #391662) Files: 6efb0a1cebd4c5390dfd34bec1234212 619 x11 optional gw-fonts-ttf_1.0-1.dsc 298c1e66a86ab25f013cfb68f7d9e0ba 1770093 x11 optional gw-fonts-ttf_1.0.orig.tar.gz 429098f1495cc6f2a1f476c3f2296bd0 2416 x11 optional gw-fonts-ttf_1.0-1.diff.gz 9da0d5c858e0258319d80df70b332d4c 1773628 x11 optional ttf-georgewilliams_1.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFK//b+C5cwEsrK54RAoKGAKCKMZ9Rg1mMEMxegPoeSF7rHSVTLQCfav8n X6+lCA0en4GraVt0RCfVi+w= =Y7+A -END PGP SIGNATURE- Accepted: gw-fonts-ttf_1.0-1.diff.gz to pool/main/g/gw-fonts-ttf/gw-fonts-ttf_1.0-1.diff.gz gw-fonts-ttf_1.0-1.dsc to pool/main/g/gw-fonts-ttf/gw-fonts-ttf_1.0-1.dsc gw-fonts-ttf_1.0.orig.tar.gz to pool/main/g/gw-fonts-ttf/gw-fonts-ttf_1.0.orig.tar.gz ttf-georgewilliams_1.0-1_all.deb to pool/main/g/gw-fonts-ttf/ttf-georgewilliams_1.0-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xapian-core 0.9.7-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 Oct 2006 17:44:47 +0100 Source: xapian-core Binary: xapian-examples xapian-tools libxapian13 libxapian-dev xapian-doc Architecture: source all i386 Version: 0.9.7-1 Distribution: unstable Urgency: low Maintainer: Olly Betts [EMAIL PROTECTED] Changed-By: Olly Betts [EMAIL PROTECTED] Description: libxapian-dev - Development files for Xapian search engine library libxapian13 - Search engine library xapian-doc - Core Xapian documentation xapian-examples - Xapian simple example programs xapian-tools - Basic tools for Xapian search engine library Changes: xapian-core (0.9.7-1) unstable; urgency=low . * New upstream release. * debian/xapian-tools.install: Install /usr/bin/xapian-progsrv. * debian/copyright: Add Richard Boulton. Files: abf86a3bd5544f6b10d0d15788ee 647 libs optional xapian-core_0.9.7-1.dsc 9c9ea6595e1d3e31145231c4aafdae5f 2820558 libs optional xapian-core_0.9.7.orig.tar.gz d78c28da49c22ee15bbb149e1c3142a1 8686 libs optional xapian-core_0.9.7-1.diff.gz 30cbec7e8b7c8f20539f7efd672212f7 670080 libs optional libxapian13_0.9.7-1_i386.deb 6b4eab834955471674f9e2b50cf30e71 1174390 libdevel optional libxapian-dev_0.9.7-1_i386.deb e22a5b1d07282ac7db8cb4b22a0c8e8f 214136 utils optional xapian-tools_0.9.7-1_i386.deb 8dadf2100b22e7b5a9d299871ccba359 146310 doc optional xapian-examples_0.9.7-1_i386.deb 6c9b3962a0ce44d0a9df708454657440 1041006 doc optional xapian-doc_0.9.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLXXkIWclcBdP7jURAsbzAJ43YFNgjxVDTuwOs8KkLZ2WtGMqgwCdHOgf /EqVkN554EmcNeTNKZ0nHtI= =ABSK -END PGP SIGNATURE- Accepted: libxapian-dev_0.9.7-1_i386.deb to pool/main/x/xapian-core/libxapian-dev_0.9.7-1_i386.deb libxapian13_0.9.7-1_i386.deb to pool/main/x/xapian-core/libxapian13_0.9.7-1_i386.deb xapian-core_0.9.7-1.diff.gz to pool/main/x/xapian-core/xapian-core_0.9.7-1.diff.gz xapian-core_0.9.7-1.dsc to pool/main/x/xapian-core/xapian-core_0.9.7-1.dsc xapian-core_0.9.7.orig.tar.gz to pool/main/x/xapian-core/xapian-core_0.9.7.orig.tar.gz xapian-doc_0.9.7-1_all.deb to pool/main/x/xapian-core/xapian-doc_0.9.7-1_all.deb xapian-examples_0.9.7-1_i386.deb to pool/main/x/xapian-core/xapian-examples_0.9.7-1_i386.deb xapian-tools_0.9.7-1_i386.deb to pool/main/x/xapian-core/xapian-tools_0.9.7-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted guile-1.8 1.8.1+1-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 Oct 2006 20:34:21 -0700 Source: guile-1.8 Binary: guile-1.8-doc guile-1.8 guile-1.8-libs guile-1.8-dev Architecture: source i386 all Version: 1.8.1+1-1 Distribution: unstable Urgency: medium Maintainer: Rob Browning [EMAIL PROTECTED] Changed-By: Rob Browning [EMAIL PROTECTED] Description: guile-1.8 - The GNU extension language and Scheme interpreter guile-1.8-dev - Development files for Guile 1.8 guile-1.8-doc - Documentation for Guile 1.8 guile-1.8-libs - Main Guile libraries Changes: guile-1.8 (1.8.1+1-1) unstable; urgency=medium . * Incorporate new upstream stable release. . * Remove the debian/patches for items fixed upstream (all of them). . * In accordance with the recent General Resolution (http://www.debian.org/vote/2006/vote_001), move all non-DFSG files to new packages that will be included in Debian's non-free section. The debian/dfsg-splitter script has been used to split the upstream archive. . * Version the doc package info files so that the doc package for each Guile stable series no longer conflicts with the doc package for other stable series. This has made the virtual guile-doc package obsolete. . * Delete debian/need-empty-autofiles-diff when not needed, always start with an empty autofiles.diff when regenerating, and fix a few other things in rules. . * Work around a dh_installinfo bug. It always inserts \Q and \E around the --section, which doesn't work. Files: 1e15e5a77e35adad252e34a8011cc9f0 709 interpreters optional guile-1.8_1.8.1+1-1.dsc d4034e0d88fc7a5c061017431a5f9535 2816100 interpreters optional guile-1.8_1.8.1+1.orig.tar.gz 61dab42b418bc690aedfffd45d25379d 10668 interpreters optional guile-1.8_1.8.1+1-1.diff.gz 7dda90d334737b8029b1c3843bb36a05 20480 doc optional guile-1.8-doc_1.8.1+1-1_all.deb ed7ec212a23e670cf20be3393a6c6332 7096 interpreters optional guile-1.8_1.8.1+1-1_i386.deb 471873c8c698da9bf4142a9bf9ae9db2 556372 devel optional guile-1.8-dev_1.8.1+1-1_i386.deb 816ab9d98d316f08d12044f2531e0297 667850 libs optional guile-1.8-libs_1.8.1+1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLK3dJcjTd4x+c6QRAvYvAJ4mwDBPL+KyOullG/LoeXDNaTJJZQCg8OOG uyWC/QkBQVj0vaXedZD81wY= =5yK2 -END PGP SIGNATURE- Accepted: guile-1.8-dev_1.8.1+1-1_i386.deb to pool/main/g/guile-1.8/guile-1.8-dev_1.8.1+1-1_i386.deb guile-1.8-doc_1.8.1+1-1_all.deb to pool/main/g/guile-1.8/guile-1.8-doc_1.8.1+1-1_all.deb guile-1.8-libs_1.8.1+1-1_i386.deb to pool/main/g/guile-1.8/guile-1.8-libs_1.8.1+1-1_i386.deb guile-1.8_1.8.1+1-1.diff.gz to pool/main/g/guile-1.8/guile-1.8_1.8.1+1-1.diff.gz guile-1.8_1.8.1+1-1.dsc to pool/main/g/guile-1.8/guile-1.8_1.8.1+1-1.dsc guile-1.8_1.8.1+1-1_i386.deb to pool/main/g/guile-1.8/guile-1.8_1.8.1+1-1_i386.deb guile-1.8_1.8.1+1.orig.tar.gz to pool/main/g/guile-1.8/guile-1.8_1.8.1+1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted guile-1.8-non-dfsg 1.8.1+1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 Oct 2006 19:21:48 -0700 Source: guile-1.8-non-dfsg Binary: guile-1.8-doc-non-dfsg Architecture: source all Version: 1.8.1+1-1 Distribution: unstable Urgency: medium Maintainer: Rob Browning [EMAIL PROTECTED] Changed-By: Rob Browning [EMAIL PROTECTED] Description: guile-1.8-doc-non-dfsg - Reference documentation for Guile 1.8 (non-DFSG items) Changes: guile-1.8-non-dfsg (1.8.1+1-1) unstable; urgency=medium . * New package: in accordance with the recent General Resolution (http://www.debian.org/vote/2006/vote_001), move all non-DFSG files to new packages that will be included in Debian's non-free section. Files: 9f2b2cfdc4522cb3984e26f4e6dad504 640 non-free/interpreters optional guile-1.8-non-dfsg_1.8.1+1-1.dsc ce6d8ae957ba32ed6791639c23d2f5d4 1022312 non-free/interpreters optional guile-1.8-non-dfsg_1.8.1+1.orig.tar.gz 634ec341fb1ab01abc7496a11a4336e5 147591 non-free/interpreters optional guile-1.8-non-dfsg_1.8.1+1-1.diff.gz 9041f4ce0971c3d360d4e4d2718d3793 456416 non-free/doc optional guile-1.8-doc-non-dfsg_1.8.1+1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLK4EJcjTd4x+c6QRAgSBAJ4lfthrz39S8SyU/LMDs7S7RzT8twCglXtl HP67prAbrr1F8TiWbsMjPwI= =JXwG -END PGP SIGNATURE- Accepted: guile-1.8-doc-non-dfsg_1.8.1+1-1_all.deb to pool/non-free/g/guile-1.8-non-dfsg/guile-1.8-doc-non-dfsg_1.8.1+1-1_all.deb guile-1.8-non-dfsg_1.8.1+1-1.diff.gz to pool/non-free/g/guile-1.8-non-dfsg/guile-1.8-non-dfsg_1.8.1+1-1.diff.gz guile-1.8-non-dfsg_1.8.1+1-1.dsc to pool/non-free/g/guile-1.8-non-dfsg/guile-1.8-non-dfsg_1.8.1+1-1.dsc guile-1.8-non-dfsg_1.8.1+1.orig.tar.gz to pool/non-free/g/guile-1.8-non-dfsg/guile-1.8-non-dfsg_1.8.1+1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dwm-tools 0.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 12 Oct 2006 12:16:00 +0200 Source: dwm-tools Binary: dwm-tools Architecture: source i386 Version: 0.1-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: dwm-tools - dynamic window manager (tools) Changes: dwm-tools (0.1-1) unstable; urgency=low . * Initial release. * Added manpages. Files: a00bc6272c2de68affb2f49cc983a159 579 x11 optional dwm-tools_0.1-1.dsc e48af4e7a736bbfd4522f6dcc5b27a31 15279 x11 optional dwm-tools_0.1.orig.tar.gz f8bfb14b5fc2b2ba4ebe62c33f92074c 2851 x11 optional dwm-tools_0.1-1.diff.gz 50ebad03a10c48abc50b7155eb7241ab 13070 x11 optional dwm-tools_0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFL2px+C5cwEsrK54RAjNTAJ9nPXubIbMXEal4lHz179Kx+++ovwCfRlfK qAbhu74rIra4HXAW9102BH0= =9ko+ -END PGP SIGNATURE- Accepted: dwm-tools_0.1-1.diff.gz to pool/main/d/dwm-tools/dwm-tools_0.1-1.diff.gz dwm-tools_0.1-1.dsc to pool/main/d/dwm-tools/dwm-tools_0.1-1.dsc dwm-tools_0.1-1_i386.deb to pool/main/d/dwm-tools/dwm-tools_0.1-1_i386.deb dwm-tools_0.1.orig.tar.gz to pool/main/d/dwm-tools/dwm-tools_0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
