Re: How important is Architecture: any (Was: Downloads things, ...) (fwd)
Ups, sorry, wrong list debian-devel. Should have gone to debian-edu ... -- http://fam-tille.de -- Forwarded message -- Date: Sat, 1 Mar 2008 00:42:02 +0100 (CET) From: Andreas Tille [EMAIL PROTECTED] To: Debian Developers debian-devel@lists.debian.org Subject: Re: How important is Architecture: any (Was: Downloads things, ...) Resent-Date: Fri, 29 Feb 2008 23:43:13 + (UTC) Resent-From: debian-devel@lists.debian.org On Sat, 1 Mar 2008, Petter Reinholdtsen wrote: I guess you might be right, now. Earlier, we used depends to pull in packages using the meta packages during installation. Now we use tasksel tasks, which are more forgiving about missing packages. We did have a problem with the debian-edu package failing to propagate into testing because it depended on arch-any packages that was missing on some architecture. Now that we are using recommends, and recommends might even be installed by default, I guess the need is not so high. Hmmm, once you say so I remember (non-RC!) bugs for not available Recommended packages. So it will not block anything but I'm not sure about the policy here. If we are just asking for those bug reports (even if non RC) the plan is quite suboptimal. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 29/02/08 at 23:29 -0800, Steve Langasek wrote: On Sat, Mar 01, 2008 at 01:55:49AM +0100, Lucas Nussbaum wrote: Note that the whole did last year projects were successful? issue is secondary. Even if all of last years projects produced fabulous results that totally changed the way Debian is developed, I'm still not sure if we should use GSOC to pay current Debian contributors, instead of using it to bring in new contributors. So you think it's better to focus on people who aren't sufficiently motivated to get involved in Debian without being paid to do so? Motivation isn't the only thing necessary to get involved in a free software project. It seems to me that often, people don't participate because they don't find a good answer to the How can I help? question. Debian isn't really good at answering this question, other projects (GNOME, Ubuntu come to mind) do much better than us. I'm not saying that students that were DD did nothing of their time during GSoc, but most of them produced results that were a bit disappointing given what people could have expected from them, mainly because they used their GSOC time to work on other Debian tasks. Do you have any proof at all for that accusation? If so, please share it. Otherwise, I think that people deserve apologies from you right now. Do you have any proof that GSOC students worked 35-40 hours a week on their GSOC projects? You probably don't. So again, no real data to back either claim. We have different opinions, and have to live with it. Where does this 35-40 hours figure come from? From Steve's example in his mail. OK, thank you for this clarification. To let everybody benefit from it, could you please mention in your next d-d-a mail about GSOC that everybody is welcomed as students, not just people not involved in Debian already? I know at least 2 people that could have applied as students last year, but didn't because they thought that GSOC wasn't for them since they were already involved in Free Software development. [...] While the majority of past student participants were enrolled in university Computer Science and Computer Engineering programs, GSoCers come from a wide variety of educational backgrounds, from computational biology to mining engineering. Many of our past participants had never participated in an open-source project before GSoC; others used the GSoC stipend as an opportunity to concentrate fully on their existing open source coding activities over the summer. Many of our graduates have later become program mentors. http://code.google.com/soc/2008/faqs.html#0.1_what_is Sure, but given the stated goals of the Summer of Code (second entry of the FAQ), you will probably agree that confusion is possible. The fact that GSoC has some policies doesn't mean that we could not add additional policies, about preferring people not involved in Free Software already, or asking our students to dedicate some reasonable amount of time to the project. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
On Sat, Mar 01, 2008 at 12:36:40PM +0900, Charles Plessy wrote: it is good news to read that there is a solution being found. However, I am a bit confused because previous messages were suggesting that the problem was disk speed, not downtime. Downtime caused by ghc6 build causing multiple kernel crashes on mips and mipsel. Newer kernel which might fix the issue are not available due to a kernel bug (#466977) since 2.6.18 ... (Running 2.6.17). To have the buildds catch up faster i as a buildd host was asked to provide a faster disk subsystem which i did... So you might devote your time to a) Find the cause of the build crash b) Hunt down the kernel bug in 2.6.24 c) Poke at the buildd admin to move the buildd to the new disk subsys All those might actually solve the problem and not work around it .. Thanks for you time ... Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Re: Buildd backlog and testing transition.
Charles Plessy [EMAIL PROTECTED] wrote: packages migrate? I just got a message from a user who wants to use one of the blocked packages (emboss), and I am just so ashamed to answer him that he has to use unstable just because it is not built on a platform where nobody is using it. He doesn't have to use unstable. He can use pinning for this specific package. Stop whining. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.29.2153 +0100]:
3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
files. Each diff, applied to the orig.tar.gz , shall recreate for
the interested user the corresponding branch in my development.
Bingo. With this addition, every user that want to see where the
integration branch comes from can examine each topic patch or topic
branch. Each of these topic branches can then be compiled and
experimented with. Upstream can incorporate each of these topic
patches, if they wish.
... until I want to play with two branches at the same time, or
upstream wants to pull two branches. Now you are forcing users to
deal with potential conflicts.
The downside, of course, is shipping the same patch twice, once
in the diff.gz, and once in ./debian/branches/*.diff.gz.
I don't see the added value in your approach. I don't see the use
case. I know your workflow and note how this is a continuation
thereof, but I can't identify the benefit to others and the project
in doing this. Do you really think there are many people or
upstreams who want pristine feature branches without being able to
use the net? Why wouldn't these people be helped with a quilt
series? They just want to work on feature B, do you think they
actually care that quilt first pops A before it applies B,
especially with tools like interdiff around?
Can you try to quantify?
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
good advice is something a man gives
when he is too old to set a bad example.
-- la rouchefoucauld
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
NMU - remove or just let be superceded
A few days ago I uploaded a package to the 7-Day DELAYED queue as an NMU. Per policy I contacted the maintainer, and he recently fixed his version and had it uploaded and it is now in the archives, making my NMU no longer needed. My NMU is in the 2-day queue at present. Should I remove it manually, or just let it go as the version numbers will ensure that it will not be installed? Thanks, Kevin -- Kevin Coyner GnuPG key: 1024D/8CE11941 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU - remove or just let be superceded
On 01/03/2008, Kevin Coyner wrote: Should I remove it manually, or just let it go as the version numbers will ensure that it will not be installed? Wait until it moves to DELAYED/0, and gets REJECTED since there's a newer version in the archive. Cheers, -- Cyril Brulebois pgpiqZDc1WH4s.pgp Description: PGP signature
Re: How to cope with patches sanely
* martin f. krafft:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.29.2153 +0100]:
3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
files. Each diff, applied to the orig.tar.gz , shall recreate for
the interested user the corresponding branch in my development.
Bingo. With this addition, every user that want to see where the
integration branch comes from can examine each topic patch or topic
branch. Each of these topic branches can then be compiled and
experimented with. Upstream can incorporate each of these topic
patches, if they wish.
... until I want to play with two branches at the same time, or
upstream wants to pull two branches. Now you are forcing users to
deal with potential conflicts.
Yes, but that's way it is. You can't publish all possible combinations
of branches upstream might need. If you lump some of them together
(either by combining them altogether, or branching one from the other),
upstream won't be able to take them because there are some changes they
don't want. If you keep them entirely separate, upstream needs to do
some integreation work. Either way, there is some work left to do.
I don't see the added value in your approach. I don't see the use
case. I know your workflow and note how this is a continuation
thereof, but I can't identify the benefit to others and the project
in doing this.
The nice thing about Manoj's proposal that we (as in the security
team, for instance) need not care if the Debian maintainer thinks that
upstream needs pristine topic branches, an integration branch, a weave,
or whatever. We just patch the source and be done with it. This isn't
a problem as long as we tell upstream to pick patches from unstable
(which they will likely do anyway because that version is much closer to
theirs most of the time).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
also sprach Florian Weimer [EMAIL PROTECTED] [2008.03.01.1334 +0100]: The nice thing about Manoj's proposal that we (as in the security team, for instance) need not care if the Debian maintainer thinks that upstream needs pristine topic branches, an integration branch, a weave, or whatever. We just patch the source and be done with it. This isn't a problem as long as we tell upstream to pick patches from unstable (which they will likely do anyway because that version is much closer to theirs most of the time). A quilt series should satisfy those needs as well. If not, please explain where it falls short. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems wahnsinn bei individuen ist selten, aber in gruppen, nationen und epochen die regel. - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Buildd backlog and testing transition.
Charles Plessy wrote: Le Fri, Feb 29, 2008 at 10:40:57AM +0100, Marc 'HE' Brockschmidt a écrit : Due to kernel problems, the mips* buildds haven't been very reliable in the past few weeks, creating a lng backlog of packages that need to be built. As there seems to be a workaround for the kernel bug, this should start getting better from the weekend on. As a maintainer: Just wait. Dear Marc, it is good news to read that there is a solution being found. However, I am a bit confused because previous messages were suggesting that the problem was disk speed, not downtime. The problem is a compound of 1) Not enough RAM (only 512 MB) in some machines, which causes an increasing number of package builds to use swap, and some of them to evenutually fail to build because of a timeout. 2) Slow on-board PIO IDE, from which the firmware can boot from 3) A kernel-imposed limit of 1 GB when PCI DMA devices (like a SATA disk controller) is used. 4) A kernel bug in the cache coherency management which hits PIO IDE, and causes instability since kernel 2.6.18. Up to then, the problem was mostly papered over by an excessive amount of cache flushing in the kernel code. This problem went unnoticed upstream since PIO IDE is these days only used on very small/cheap systems, where a different code path is used. Each of those points costs a chunk of performance and makes the buildds less reliable. The current state is: 4) I tracked this bug down (which was very hard) and wrote a kernel patch which waits for upstream review. The code is hairy enough, so I don't know yet if it is a proper solution or only a workaround. That said, it works fine on my machine (which is the same model than the buildd hardware). 3) This was supposedly fixed in kernel 2.6.22+, and works fine on the successor model of the hardware. It still fails on the buildd hardware, however, so the current choice is between 1GB and fast I/O or more RAM and slow I/O. I am working on fixing this bug. 2) The obvious solution is to add SATA disks to the buildds, this is currently in the works. 1) Upgrades to 1-2 GB RAM are also currently worked on (or already done). For a properly running machine of this type I expect it is capable to build ~5% of the unstable archive per day. IOW, the current backlog should be handled soon. Thiemo
(user)tagging wnpp bugs
Hello folks, following a short discussion with Erich Schubert on the debtags-devel list[1], I decided to come with a simple proposal (are DEPs already active and useful?). In order to have wnpp bugs better categorized (and, as such, searched, shown, and managed), it seems a viable option to use (abuse?) faceted usertags, like somebody from the Debian Science subproject already does[2][3]. These tags could be collected using wiki pages, and should IMHO mostly match debtags' ones (that would enable using them when entering debtags). Of course, using just one ‘login’ for categorizing wnpp tags looks way more useful than having several teams each using a different one. Any comments? What ‘user’ should we use? If nothing against comes up, I'm going to use such usertags as [EMAIL PROTECTED] and report (lots of) RFPs (and possibly some ITP!) for fields I am interested in. [1] http://lists.alioth.debian.org/pipermail/debtags-devel/2008-February/001764.html [2] http://wiki.debian.org/DebianScience/Usertags [3] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] Cheers, -- Luca
Re: Buildd backlog and testing transition.
Le Sat, Mar 01, 2008 at 10:45:31AM +0100, Florian Lohoff a écrit : So you might devote your time to a) Find the cause of the build crash b) Hunt down the kernel bug in 2.6.24 c) Poke at the buildd admin to move the buildd to the new disk subsys This is ridiculus and provocative. I have no interest in the MIPS architecture, and all that I ask is that we can do our works independantly. I would be happy to help by adapting my packaging work, for instance by saving buildd time with less uploads and test disabling on MIPS. But that was never requested, and even argued against. I do not know what else to propose. Why don't the MIPS porters support a request to let packages migrate to testing while they find a solution? Why is it impossible to run the kernel that was used before mid-january? When you will finally have solved your problem, what will Debian have gained in having prevented bugfixes to enter testing for two monthes? If it is impossible to set up backup buildds nor to communicate with your buildd admin, then please do not ask the whole project to wait for your problems to be solved, nor to solve them for you. Please let our pakcages migrate to testing. Thanks for respecting our work, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/08 06:51, David Nusinow wrote: On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. I say we drop every WM DE except GNOME, because that will simplify the distro, and lead to *much* fewer bugs!!! Obviously, what I just wrote is nonsense, and should never happen. Because FLOSS *is* about choice. However... it is perfectly reasonable for a distro to say, We can not be all things to all people, so some limits have to be set, and some users/DDs will be disappointed. - -- Ron Johnson, Jr. Jefferson LA USA (Women are) like compilers. They take simple statements and make them into big productions. Pitr Dubovitch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyXm8S9HxQb37XmcRAnnMAKCWRkcS3Y81U1dJ6Qn3d28DiQj1DQCgks6M NSnyyHAhp+HFwPshl7wWb2M= =G95B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, Feb 25, 2008 at 12:19:33PM -0300, Otavio Salvador wrote: Robert Collins [EMAIL PROTECTED] writes: On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote: Yet, rebasing is still routinely performed in the Linux kernel development. What I find interesting and rather amusing here is Linus talking negatively about rebase: in particular its propensity to turn tested code (what you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). If people doesn't test and review the patches after rebasing, it looks right but everyone is suppose to test the changes after a merging (as for rebasing). I'll note that when I submit a branch, I prefer to do a rebase, and *then* do extensive testing. That's because for a new feature, I generally understand it better than the upstream maintaining, and *I* want to be the one doing the merge and testing after the fact, as opposed to assuming the upstream will do the appropriate merge fixups and testing. For big projects, this is essential, and Linus in fact does *not* test after doing a merge. (It doesn't scale for him to test after every single merge from his Lieutennants.) But for smaller projects, it should really be up to the submitter; I don't think there is any one Absolutely Right Way To Do It. If someone wants to rebase and then test before sending a pull request, I don't think there's anything wrong with that. Especially if the projects have a good regression test suite. (Both git and e2fsprogs have good regression tests, and that makes life *much* easier to test after doing a rebase or a merge; basically, I'll run the full regression test to make sure that anything unanticipated hasn't broken, and then do explicit testing about the feature being merged or rebased.) BTW, because of the regression test suite, and my general policy for e2fsprogs is that I want to make sure that make check has 0 failed tests after every single commit, rebasing to collapse and remove development history makes life easier to fulfill the fully git bisectable with 0 make check failures between every commit constraint. So as long as the person submitting the patch makes it clear that they have tested exactly what is being requested to be pulled, there's nothing wrong with whether or not they do the rebase right before sending the pull request. My preference is to do the rebase and test, and from a smaller project such as dpkg, I can't think of any good reason for the maintainer to force the submitters to follow one approach or another. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Sat, Mar 01, 2008 at 09:43:56AM -0600, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/08 06:51, David Nusinow wrote: On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. SNIP stawman However... it is perfectly reasonable for a distro to say, We can not be all things to all people, so some limits have to be set, and some users/DDs will be disappointed. Which is pretty much what the message said if you bothered to read it. We should focus on the quality of what we do support rather than shoving everything imaginable in to the distro. Adding more redundant crap in to the archive in the name of choice just increases the number of moving parts, and thereby the number of bugs, that we have to deal with. - David Nusinow, who's a happy thttpd user and also doesn't see a need for yet another small httpd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
* martin f. krafft: also sprach Florian Weimer [EMAIL PROTECTED] [2008.03.01.1334 +0100]: The nice thing about Manoj's proposal that we (as in the security team, for instance) need not care if the Debian maintainer thinks that upstream needs pristine topic branches, an integration branch, a weave, or whatever. We just patch the source and be done with it. This isn't a problem as long as we tell upstream to pick patches from unstable (which they will likely do anyway because that version is much closer to theirs most of the time). A quilt series should satisfy those needs as well. If not, please explain where it falls short. It does, if you ship the sources with the series applied. AFAICT, this is not what's usually done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Saturday 01 March 2008 16:43:56 Ron Johnson, vous avez écrit : I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. I say we drop every WM DE except GNOME, because that will simplify the distro, and lead to *much* fewer bugs!!! Obviously, what I just wrote is nonsense, and should never happen. Because FLOSS *is* about choice. However... it is perfectly reasonable for a distro to say, We can not be all things to all people, so some limits have to be set, and some users/DDs will be disappointed. Sure. The fact is, I don't think we have bugs because we have too much choice, but because we don't have enough manpower. So, previous mail was pointing a real issue, lack of manpower and (hence) too many bugs, but giving a false anwser, less/limited choice. Basically, a package has bugs because the maintainer or upstream is not reponsive/available/..., not because there are too much *choice*. It is also pointed out that there are central places, like security fixes, where having too many packages leads to too much work. Sure, but again, it's not related to choice, but to the overall size of the distribution. Here again, the solution is not less choice, but more people. I think too that we should care about how many different similar software we include, but it's important to point out the real issues. Now, if you really want to see how choice is already one aspect of the system, just search through apt-get for yet another you'll be suprised to see how many packages are presented initially as yet another foo-bar... Romain
Bug#468814: ITP: libsoothsayer0 -- intelligent predictive text entry platform (shared library)
Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: libsoothsayer0 Version : 0.6 Upstream Author : Matteo Vescovi [EMAIL PROTECTED] * URL : http://soothsayer.sourceforge.net/ * License : GPL Programming Lang: C++ Description : intelligent predictive text entry platform (shared library) Soothsayer is an intelligent predictive text entry platform. . A predictive text entry system attempts to improve the ease and speed of textual input by predicting words. Word prediction consists in computing which word tokens or word completions are most likely to be entered next. The system analyses the text already entered and combines the information thus extracted with other information sources to calculate the set of most probable tokens. . Soothsayer exploits redundant information embedded in natural languages to generate word predictions. The modular architecture allows its language model to be extended and customized to utilize statistical, syntactic, and semantic information sources. . This package contains the shared library. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
also sprach Florian Weimer [EMAIL PROTECTED] [2008.03.01.1650 +0100]: It does, if you ship the sources with the series applied. AFAICT, this is not what's usually done. ... or if the patches were automatically applied when the source is unpacked, which is where I think we're heading. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems you can't assign IP address 127.0.0.1 to the loopback adapter, because it is a reserved address for loopback devices. -- micro$oft windoze xp professional digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#468817: ITP: libsoothsayer-dev -- intelligent predictive text entry platform (development files)
Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: libsoothsayer-dev Version : 0.6 Upstream Author : Matteo Vescovi [EMAIL PROTECTED] * URL : http://soothsayer.sourceforge.net/ * License : GPL Programming Lang: C++ Description : intelligent predictive text entry platform (development files) Soothsayer is an intelligent predictive text entry platform. . A predictive text entry system attempts to improve the ease and speed of textual input by predicting words. Word prediction consists in computing which word tokens or word completions are most likely to be entered next. The system analyses the text already entered and combines the information thus extracted with other information sources to calculate the set of most probable tokens. . Soothsayer exploits redundant information embedded in natural languages to generate word predictions. The modular architecture allows its language model to be extended and customized to utilize statistical, syntactic, and semantic information sources. . This package contains the development files (headers, static libraries). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, Feb 29, 2008 at 12:40:55PM +, Colin Watson wrote: That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. This makes it more difficult to ask for review while the branch is in progress, which is a valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. It's a bad idea to base work on a feature where the code is still being under review. Even if you keep all of the historical crap on the branch, to be preserved for ever, it's going to cause merge difficulties for people who base branches based on that patch which is under review. So you really, REALLY, don't want people basing work on code which is still being developed, since it may be that the review may include, why don't you totally refactoring the code *THIS* way, which will end up breaking everyone who depends on your new function interface anyway. So how to solve this problem? (a) Send patches via e-mail for review. This actually works better, because people can respond via e-mail much more easily than if it just shows up in a git repository. You can also send an explicit request for people to review the patch when it is sent via e-mail. (b) Put the patches on a git branch which is *guaranteed* to be constantly rewound, and is not to be used as a base for derived patches. By convention the 'pu' branch in the git (and e2fsprogs) source repository is declared to be one which is used only for people who want to test the latest bleeding edge code, but it should not be used as the basis of any derived or child branches. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. It's not a fatal issue, but in the long run, the code is more maintainable if the code revision history is clean. It's like having a few goto's in the code. Does that make the code unmaintainable? No. But it does make it worse. Or think about how much effort some of us spend to make the code gcc -Wall free of warnings. Does not doing it make the code fundamentally bad? No. Is it still worth doing? Many of us believe that it is worth doing, nevertheless. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468818: ITP: soothsayer-data -- intelligent predictive text entry platform (data files)
Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: soothsayer-data Version : 0.6 Upstream Author : Matteo Vescovi [EMAIL PROTECTED] * URL : http://soothsayer.sourceforge.net/ * License : GPL Programming Lang: Description : intelligent predictive text entry platform (data files) Soothsayer is an intelligent predictive text entry platform. . A predictive text entry system attempts to improve the ease and speed of textual input by predicting words. Word prediction consists in computing which word tokens or word completions are most likely to be entered next. The system analyses the text already entered and combines the information thus extracted with other information sources to calculate the set of most probable tokens. . Soothsayer exploits redundant information embedded in natural languages to generate word predictions. The modular architecture allows its language model to be extended and customized to utilize statistical, syntactic, and semantic information sources. . This package contains the sample statistical (n-gram) data files and abbreviation files needed by soothsayer. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468819: ITP: soothsayer-doc -- intelligent predictive text entry platform (documentation)
Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: soothsayer-doc Version : 0.6 Upstream Author : Matteo Vescovi [EMAIL PROTECTED] * URL : http://soothsayer.sourceforge.net/ * License : GPL Programming Lang: Description : intelligent predictive text entry platform (documentation) Soothsayer is an intelligent predictive text entry platform. . A predictive text entry system attempts to improve the ease and speed of textual input by predicting words. Word prediction consists in computing which word tokens or word completions are most likely to be entered next. The system analyses the text already entered and combines the information thus extracted with other information sources to calculate the set of most probable tokens. . Soothsayer exploits redundant information embedded in natural languages to generate word predictions. The modular architecture allows its language model to be extended and customized to utilize statistical, syntactic, and semantic information sources. . This package contains the documentation for soothsayer in HTML and LaTeX format. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the?HTTP/1.1 protocol
On Sat, Mar 01, 2008 at 05:20:28PM +0100, Romain Beauxis wrote: Le Saturday 01 March 2008 16:43:56 Ron Johnson, vous avez écrit : I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. I say we drop every WM DE except GNOME, because that will simplify the distro, and lead to *much* fewer bugs!!! Obviously, what I just wrote is nonsense, and should never happen. Because FLOSS *is* about choice. However... it is perfectly reasonable for a distro to say, We can not be all things to all people, so some limits have to be set, and some users/DDs will be disappointed. Sure. The fact is, I don't think we have bugs because we have too much choice, but because we don't have enough manpower. So, previous mail was pointing a real issue, lack of manpower and (hence) too many bugs, but giving a false anwser, less/limited choice. Basically, a package has bugs because the maintainer or upstream is not reponsive/available/..., not because there are too much *choice*. Um. No. We have lots of people. We also have lots of software. If we lose some of the redundant software and keep the same number of people then we have more people to work on the software that requires attention. It's pretty simple. Unfortunately, people in Debian often are more interested in reinventing the wheel than improving what's already there or *gasp* trying to innovate and do something new and different. Yes, there are valid reasons for providing options, but doing so makes it more difficult to do the important things that actually need to be done to produce a high quality distribution. This is, not coincidentally, one of the many reasons why so many people flock to Ubuntu rather than Debian. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/08 10:14, David Nusinow wrote: On Sat, Mar 01, 2008 at 09:43:56AM -0600, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/08 06:51, David Nusinow wrote: On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html I wish we had some more of this sort of thinking in our own project and a little less of yours. Maybe then we'd have fewer bugs in the packages people actually care about and use. SNIP stawman However... it is perfectly reasonable for a distro to say, We can not be all things to all people, so some limits have to be set, and some users/DDs will be disappointed. Which is pretty much what the message said if you bothered to read it. We should focus on the quality of what we do support rather than shoving everything imaginable in to the distro. Adding more redundant crap in to the archive in the name of choice just increases the number of moving parts, and thereby the number of bugs, that we have to deal with. Who makes the decision as to how much redundancy is too much? And is it crap just because it's redundant? For example, is micro-httpd redundant crap? There are no bug reports, so how much Security QA Team effort goes into maintaining it? - David Nusinow, who's a happy thttpd user and also doesn't see a need for yet another small httpd And I'm a happy GNOME user who doesn't see the need for KDE, XFce, fvwm, ratpoison, ion3, etc, etc, ad nauseum. (Actually, I do see a need for small WMs, and even though I see no need for 18 of them, that's not my call to make.) - -- Ron Johnson, Jr. Jefferson LA USA The knife, the knife, the life of the wife is ended by the knife... Stewie Griffin Eliza Pinchley -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyYZxS9HxQb37XmcRArVrAKDkGLOUjBw7zHrOD1xbD9KEMbNgxACeO1K8 B7nrKYfOihjz7OcwCg8uNDI= =iwgL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Saturday 1 March 2008 17:20, Romain Beauxis wrote: It is also pointed out that there are central places, like security fixes, where having too many packages leads to too much work. Sure, but again, it's not related to choice, but to the overall size of the distribution. Here again, the solution is not less choice, but more people. It's unclear to me while the first solution is disqualified out of hand. I don't have a reason to believe that we will suddenly get lots more people out of nowhere (even besides ignoring the lower marginal benefit that every extra person adds). Thijs pgpz2oPxmzbqL.pgp Description: PGP signature
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/08 10:38, Ron Johnson wrote: [snip] Who makes the decision as to how much redundancy is too much? And is it crap just because it's redundant? For example, is micro-httpd redundant crap? There are no bug reports, so how much Security QA Team effort goes into maintaining it? Shame on me for not looking at the archived bugs. - -- Ron Johnson, Jr. Jefferson LA USA The knife, the knife, the life of the wife is ended by the knife... Stewie Griffin Eliza Pinchley -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyYf5S9HxQb37XmcRApVfAKCMy+b3k2bKA+XxUsRrKOVlN7iHxQCgsfUg YHgwL5sQcY9u+h8iEHIp1rI= =F49q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Sat, 1 Mar 2008 14:16:20 +0100, martin f krafft [EMAIL PROTECTED] said: also sprach Florian Weimer [EMAIL PROTECTED] [2008.03.01.1334 +0100]: The nice thing about Manoj's proposal that we (as in the security team, for instance) need not care if the Debian maintainer thinks that upstream needs pristine topic branches, an integration branch, a weave, or whatever. We just patch the source and be done with it. This isn't a problem as long as we tell upstream to pick patches from unstable (which they will likely do anyway because that version is much closer to theirs most of the time). A quilt series should satisfy those needs as well. If not, please explain where it falls short. A quilt series is hard to generate from my setup; branch diffs are not. A quilt series only becomes viable as an exclusive source package format if it can be created in all cases; forcing people to abandon all their work flows and migrate to quilt is a non-starter. If we are not talking about exclusively using quilt, then I do not understand your question -- sure, some people use quilt. Some of us do not. Unless there is a way to generate a quilt series for the rest of us easily, we are not going to have quilt in all source packages. Why is this so hard to understand? manoj -- Time is an illusion perpetrated by the manufacturers of space. 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: How to cope with patches sanely
On Sat, 1 Mar 2008 12:21:03 +0100, martin f krafft [EMAIL PROTECTED] said:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.29.2153
+0100]:
3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
files. Each diff, applied to the orig.tar.gz , shall recreate for the
interested user the corresponding branch in my development.
Bingo. With this addition, every user that want to see where the
integration branch comes from can examine each topic patch or topic
branch. Each of these topic branches can then be compiled and
experimented with. Upstream can incorporate each of these topic
patches, if they wish.
... until I want to play with two branches at the same time, or
upstream wants to pull two branches. Now you are forcing users to deal
with potential conflicts.
I am not asking users to do any such thing. I am asking
developers who want to play with tweo unrelated and conflcting features
to do some integration work, with my integration branch to use as an
example to see how such conflicts can be resolved.
If you are a developer, and want to play with conflicting or
overlapping features, and can't do integration work given a working
example of how such integration can be done, stay away from the
kitchen. I am not going to jump through hoops to cater to your
incompetence.
The downside, of course, is shipping the same patch twice, once in
the diff.gz, and once in ./debian/branches/*.diff.gz.
I don't see the added value in your approach. I don't see the use
case. I know your workflow and note how this is a continuation
thereof, but I can't identify the benefit to others and the project in
doing this. Do you really think there are many people or upstreams who
want pristine feature branches without being able to use the net?
I am providing people with the same development infrastructure I
use, in the debian source package, without impacting
repeatability. There was a criticism that the source package that
contains only a diff.gz is fairly opaque to developers -- and that an
explanation should be provided to how the diff.gz came about, and what
are its constituent parts. I am providing people a better understanding
of each feature by putting in stand alone, and not making it dependent
on a bunch of unrelated features.
Let me reiterate the goals I put forth for me:
A) All the branches that I use (the pure feature branches, the
upstream branch, and the integration branch) should be made
available to the users. This will give them the same environment I
have, and thus they have the preferred place to make modifications.
B) When people do dpkg-source -x, they should have a fully unpacked
tree that is compiled, with no further action that needs to be
taken
C) In order to reconstitue all the other branches, no network
connectivity should be required. There a lot of people in the
developing world that do not have a readily available network
connection -- my solution must work with source DVD's
D) No knowledge of my SCM should be required. People should be able
to construct the topic branches without knowing arch or git or bzr
or Hg or what have you.
I am also providing developers the pure features, uncluttered by
integration junk, so people can see what the intent of the changes was,
cleanly; and apply any such feature to upstream, and have it work.
There is a combinatorics problem here. If you have N features,
you might want to see them one at a time, two at a time, three at a
time or N! ways. I provide the common cases: One at a time, or all
at the same time.
People who want the rest of the N! ways may have to do some
integration work -- but I do provide a working, fully integrated
example for them to program by example from.
Why wouldn't these people be helped with a quilt series? They just
want to work on feature B, do you think they actually care that quilt
first pops A before it applies B, especially with tools like interdiff
around?
Show me the code. Get me a quilt series from my feature
branches. Until you can get me an automated way to get a quilt series
from my work-flow, the quilt series option is off the table. I find a
quilt series to be inferior to topic branches. I understand others do
not feel that way. I am not forcing them not to use quilt -- though
that would, in my opinion, improve the quality of the distribution.
Stop trying to make me put in work to use quilt.
I dislike the extra work and indirection of using patches (I
am much better at reading code than reading code + patch). I dislike
the extra effort it takes to read code in different branches without
doing extra work, poping and applying stuff -- and dealing with the
integration work every time you pop and reapply and there is a
conflict). I am never going to use quilt -- and if you try to force me,
t.
Now,
Bug#468820: ITP: soothsayer -- intelligent predictive text entry platform (tools and demos)
Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: soothsayer Version : 0.6 Upstream Author : Matteo Vescovi [EMAIL PROTECTED] * URL : http://soothsayer.sourceforge.net/ * License : GPL Programming Lang: C++ Description : intelligent predictive text entry platform (tools and demos) Soothsayer is an intelligent predictive text entry platform. . A predictive text entry system attempts to improve the ease and speed of textual input by predicting words. Word prediction consists in computing which word tokens or word completions are most likely to be entered next. The system analyses the text already entered and combines the information thus extracted with other information sources to calculate the set of most probable tokens. . Soothsayer exploits redundant information embedded in natural languages to generate word predictions. The modular architecture allows its language model to be extended and customized to utilize statistical, syntactic, and semantic information sources. . This package contains the tools required to generate custom statistical data used by soothsayer to generate predictions. . This package also contains simple demonstration programs. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Sat, 1 Mar 2008 17:24:49 +0100, martin f krafft [EMAIL PROTECTED] said: also sprach Florian Weimer [EMAIL PROTECTED] [2008.03.01.1650 +0100]: It does, if you ship the sources with the series applied. AFAICT, this is not what's usually done. ... or if the patches were automatically applied when the source is unpacked, which is where I think we're heading. Why do we have to settle on a quilt based source package, when my proposal meets all the requirements anyway? Why does it have to be one or the other? Why is the requirement not just: a) on dpkg-source -x; you get what you need to compile and build the package b) The monolithic diff.gz has additional information provided that shows the user the different lines of development that have been integrated into the Debian package c) This additional information should not need knowledge of an SCM or network access And let people figure out on their own how to make this happen? (Like, perhaps, teaching dpkg about the top few stacked patch mechanisms). Why standardize on tools instead of specifying results? Methinks that useless conformity comes close to foolish consistency, and I am opposed to hobgoblins. manoj -- Operator, please trace this call and tell me where I am. 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#468820: ITP: soothsayer -- intelligent predictive text entry platform (tools and demos)
Matteo Vescovi wrote: Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: soothsayer Hi Matteo, please see http://lists.debian.org/debian-devel/2008/01/msg00368.html In short: You only file *one* ITP for the source package, not ITPs for every single binary package you build from the source package. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: How to cope with patches sanely
On Sat, 01 Mar 2008, Manoj Srivastava wrote: Why do we have to settle on a quilt based source package, when my proposal meets all the requirements anyway? Why does it have to be one or the other? It's not going to be one or the other. Note that your changes on upstream code can be a single diff in a quilt serie anyway. The way to store patches has no relation with the way you construct your patches. :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Sat, 1 Mar 2008 11:07:54 -0500, Theodore Tso [EMAIL PROTECTED] said: On Fri, Feb 29, 2008 at 12:40:55PM +, Colin Watson wrote: That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. This makes it more difficult to ask for review while the branch is in progress, which is a valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. It's a bad idea to base work on a feature where the code is still being under review. Even if you keep all of the historical crap on the branch, to be preserved for ever, it's going to cause merge difficulties for people who base branches based on that patch which is under review. I do not understand this. See, usign topic branches for upstream code that does reversions and bug fix one off versions, I have never really encoutered extraordinary difficulties in merging. Admittedly, the most complex case I have is Emacs, and I merge in changes from HEAD and sometimes from the lexbind branch, and both these are under rapid development -- what merge problems have I been avoiding? So you really, REALLY, don't want people basing work on code which is still being developed, since it may be that the review may include, why don't you totally refactoring the code *THIS* way, which will end up breaking everyone who depends on your new function interface anyway. Well, a complete refactoring would cause me to clone off another branch, and restart there, abandoning the current branch, but my cases are far different for the kernel. Which is significant; we are not talking about a code base with the size, scope, and contributors like the kernel does; perhaps the ruls might well be different? So how to solve this problem? (a) Send patches via e-mail for review. This actually works better, because people can respond via e-mail much more easily than if it just shows up in a git repository. You can also send an explicit request for people to review the patch when it is sent via e-mail. (b) Put the patches on a git branch which is *guaranteed* to be constantly rewound, and is not to be used as a base for derived patches. By convention the 'pu' branch in the git (and e2fsprogs) source repository is declared to be one which is used only for people who want to test the latest bleeding edge code, but it should not be used as the basis of any derived or child branches. Hmm. OK, how about this picture: inline: branching.png This is my typical workflow. Most of the time, upstream changes flow down to topic branches and integration branches; and since I use arch, I do plain old merges. If I actually rebase any Topic branch for the occasional feed back to upstream, that would cause problems in the integration branch (do not merge and rebase in the same tree). My tentative solution is to clone Topic_A_3.0 in Topic_A_3_Prime, and rebase the new branch -- which seems deceptively simple. The fact that no one has proposed that as a solution makes me think that perhaps this is not as easy as I am making it out to be. I would really appreciate any comments on this bit. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. It's not a fatal issue, but in the long run, the code is more maintainable if the code revision history is clean. It's like having a few goto's in the code. Does that make the code unmaintainable? No. But it does make it worse. Or think about how much effort some of us spend to make the code gcc -Wall free of warnings. Does not doing it make the code fundamentally bad? No. Is it still worth doing? Many of us believe that it is worth doing, nevertheless. While I appreciate the analogy, I am not sure how valid it is. I lurk on the emacs development list, and pull from the HEAD of the development branch several times a week. Since this is the HEAD of development, things might break, so I look at changelogs. Having messy history, and revocations of changes do not seriously impact my review of what has changed. I have often heard people say that clean history makes things easier, but since I do not see much of a difficulty with unclean history, I am not sure I find this argument persuasive. Now, having bisecability could be useful (I have never used a bisect); I don't know what the effect of a version that does not compile or is otherwise buggy would have on the work flow. manoj -- Actually, what I'd like is a little toy spaceship!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966
Bug#468823: ITP: lxsession -- a lightweight X11 session manager
Package: wnpp Severity: wishlist Owner: Andrew Lee [EMAIL PROTECTED] * Package name: lxsession Version : 0.3 Upstream Author : Hong Jen Yee(PCMan) [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL) Programming Lang: (C) Description : a lightweight X11 session manager LXSession is a lightweight X11 session manager with fewer dependencies, designed for use with the LXDE(Lightweight X11 Desktop Environment). . It's desktop-independent and can be used with any window manager. . As session manager it remembers the applications in use when you logout, and restart the applications when you log back in. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468823: ITP: lxsession -- a lightweight X11 session manager
Hi, On Sun, Mar 02, 2008 at 01:19:50AM +0800, Andrew Lee wrote: Package: wnpp Severity: wishlist Owner: Andrew Lee [EMAIL PROTECTED] * Package name: lxsession Version : 0.3 Upstream Author : Hong Jen Yee(PCMan) [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL) Programming Lang: (C) Description : a lightweight X11 session manager LXSession is a lightweight X11 session manager with fewer dependencies, designed for use with the LXDE(Lightweight X11 Desktop Environment). . It's desktop-independent and can be used with any window manager. . As session manager it remembers the applications in use when you logout, and restart the applications when you log back in. What's the difference between this and xsm? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mailing list for cross-distributions collaboration
Hi, A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read at [0] (on the web) or [1] (as an mbox file). [0] http://www.lucas-nussbaum.net/distributions/ [1] http://www.lucas-nussbaum.net/distributions/distributions.mbox.gz Also, Freedesktop.org kindly agreed to host a mailing list to ease discussions between distributions, and act as a central point of contact. You can subscribe on [2], and post to [EMAIL PROTECTED] [2] http://lists.freedesktop.org/mailman/listinfo/distributions This mailing list is for people involved (or interested) in the development of distributions. Questions that are on-topic are both technical and social/organizational issues, like: - How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot? - How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4? - Do you use a system that gives a limited set of rights to new contributors? Off-topic stuff obviously include trolling about which distribution is the best one, or user support. Don't hesitate to forward this mail to all interested parties. Let's make this mailing list something useful together! -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the?HTTP/1.1 protocol
Le Saturday 01 March 2008 17:37:40 David Nusinow, vous avez écrit : Basically, a package has bugs because the maintainer or upstream is not reponsive/available/..., not because there are too much *choice*. Um. No. We have lots of people. We also have lots of software. If we lose some of the redundant software and keep the same number of people then we have more people to work on the software that requires attention. It's pretty simple. So, we basically *agree* that a lot of software makes more bugs. Whoa, that's *a* point. Now, unless we decide to, Debian is not meant to refuse any *new* package. Which means that the distribution will always grow, even without redundant software. All in all, yes sure, reducing choice will give a breath and reduce load, but clearly, it's only postponing the issue, and giving false answers to real issues. This is, not coincidentally, one of the many reasons why so many people flock to Ubuntu rather than Debian. Are you meaning to disqualify yourself with this kinds of trolls ? Ubuntu clearly concentrate on a core set of packages, and pulls out of debian the others. So I'd be delighted to see how ubuntu would handle this diversity, and have so many users without *our* diversity. Romain
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Saturday 01 March 2008 17:44:01 Thijs Kinkhorst, vous avez écrit : On Saturday 1 March 2008 17:20, Romain Beauxis wrote: It is also pointed out that there are central places, like security fixes, where having too many packages leads to too much work. Sure, but again, it's not related to choice, but to the overall size of the distribution. Here again, the solution is not less choice, but more people. It's unclear to me while the first solution is disqualified out of hand. I don't have a reason to believe that we will suddenly get lots more people out of nowhere (even besides ignoring the lower marginal benefit that every extra person adds). Hey, seems you're confusing the original issue. Indeed, here we have a potential maintainer proposing a new package, so it's exactly the converse: the package follows the new guy. So, yes sure, if we start crying about his very first package that's sure we won't get lots more people out of nowhere... Romain
Re: NMU - remove or just let be superceded
* Kevin Coyner | Should I remove it manually, or just let it go as the version | numbers will ensure that it will not be installed? Doesn't really matter: it will be rejected since there's a newer version in the archive, but it means you get a reject mail, so if you want to remove it, that's fine too. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On fredagen den 29 februari 2008, William Pitcock wrote: On Thu, 2008-02-28 at 18:47 -0600, Gunnar Wolf wrote: Even there, it looks very much like other very small webservers, such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, mini-httpd or thttpd. What does it do better than any of them? Or worse? Or different? Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. Package descriptions should stick to positive aspects of the package, and not try to draw comparisons towards other packages. IMO. You seem to think that being the maintainer of a package in Debian means marketing it among competing packages, trying to sell it to the user with fluffy sales talk. If so, you couldn't be more wrong. Being a maintainer means cooperating with other maintainers to deliver a free software distribution that is as good as possible as a whole. That means helping the user choose among similar packages by pointing out not only the strengths but also the limitations and weaknesses. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
Re: mass ITPs
Quoting Henrique de Moraes Holschuh ([EMAIL PROTECTED]): On Fri, 29 Feb 2008, Paul Wise wrote: Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? That would defeat a lot of the purpose of the ITPs (like looking at the descriptions, etc). I think we just have to deal with it, they are not as There is indeed no chace that a normal human can look at all descriptions of the gazillions of ITP that are currently flooding -devel (and I'm not only talking about Rafael ones here). There seems to be some crazyness about packaging new stuff these days. That would be fine.if only our existing packages were well maintained.which, for many of them is certainly not true. If someone cares to listen: when you think about ITPing each and every piece of FLOSS that pops around: think about *helping* people who maintain existing packages instead of adding even more noise to our noisy bunch of various crap^W software. signature.asc Description: Digital signature
Re: Bug#468823: ITP: lxsession -- a lightweight X11 session manager
David Nusinow wrote: What's the difference between this and xsm? It well-integrated with LXDE and other modern desktop environments, the difference between this and xsm are: * Removed the session dialog from xsm. * Use better configuration. * Provide a nice logout-dialog with the ability to shutdown/reboot/suspend/hibernate via HAL or gdm, and more Even though it's based on xsm, but they are quite different. Make a diff between xsm and lxsession for detail, if there is any doubt. Best regards, -Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468831: ITP: libdata-javascript-perl -- Dump perl data structures into JavaScript code
Package: wnpp Severity: wishlist Owner: Jaldhar H. Vyas [EMAIL PROTECTED] * Package name: libdata-javascript-perl Version : 1.11 Upstream Author : Jerrad Pierce [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Data-JavaScript/ * License : GPL + Artistic (Note: copyright info is actually missing. Will get clarification from author before uploading.) Programming Lang: Perl Description : Dump perl data structures into JavaScript code This module is mainly inteded for CGI programming, when a perl script generates a page with client side JavaScript code that needs access to structures created on the server. It works by creating one line of JavaScript code per datum. Therefore, structures cannot be created anonymously and need to be assigned to variables. However, this format enables dumping large structures. I am packaging this as a dependency of a future version of libcgi-application-plugins-perl) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468823: ITP: lxsession -- a lightweight X11 session manager
On Sun, Mar 02, 2008 at 02:10:36AM +0800, Andrew Lee wrote: David Nusinow wrote: What's the difference between this and xsm? It well-integrated with LXDE and other modern desktop environments, the difference between this and xsm are: * Removed the session dialog from xsm. * Use better configuration. * Provide a nice logout-dialog with the ability to shutdown/reboot/suspend/hibernate via HAL or gdm, and more Even though it's based on xsm, but they are quite different. Make a diff between xsm and lxsession for detail, if there is any doubt. Coolness. The HAL stuff in particular sounds really awesome. Would you mind putting some (or all) of this in the description for the package when you upload it? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mass ITPs
Le Saturday 01 March 2008 19:48:50 Christian Perrier, vous avez écrit : If someone cares to listen: when you think about ITPing each and every piece of FLOSS that pops around: think about *helping* people who maintain existing packages instead of adding even more noise to our noisy bunch of various crap^W software. Hey, reading you I figured out that all newcomers are required to have contributions in Debian, which means *new packages*. So, yes I understand your point, but perhaps it's also the symptom of a more important issue: initial contributions to Debian often mean preparing new packages. Shouldn't we think about other alternatives in order to enforce contributions besides creating packages ? Romain
Re: mass ITPs
On Sat, Mar 01, 2008 at 08:49:05PM +0100, Romain Beauxis wrote: I figured out that all newcomers are required to have contributions in Debian, which means *new packages*. Not at all. They must maintain at least one (but preferrably more) packages (if they want to do packaging). They may be team-maintained, and it is particularly suggested to them that they may adopt orphaned packages. In other words, browsing wnpp for RFH and O/RFA bugs is just as good as (and often better than) adding a new package. Shouldn't we think about other alternatives in order to enforce contributions besides creating packages ? If people want to do packaging for Debian, I think it is reasonable that they show contributions in that area. We don't actually require it for people who want to work on infrastructure or translations, for example. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: (user)tagging wnpp bugs
On Sat, 01 Mar 2008, Luca Brivio wrote: Any comments? What ‘user’ should we use? If nothing against comes up, I'm going to use such usertags as [EMAIL PROTECTED] and report (lots of) RFPs (and possibly some ITP!) for fields I am interested in. I'd suggest just picking a reasonable subset of the tags and using the [EMAIL PROTECTED] user so the tags are visible by default. [Well, after testing using your own user, of course.] Don Armstrong -- Leukocyte... I am your father. -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: mass ITPs
On 11311 March 1977, Romain Beauxis wrote: Hey, reading you I figured out that all newcomers are required to have contributions in Debian, which means *new packages*. No, it doesn't mean new packages. It means contributions. -- bye, Joerg A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). pgpJJZA6TztNY.pgp Description: PGP signature
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Fri, Feb 29, 2008 at 05:41:25AM -0600, William Pitcock wrote: Package descriptions should stick to positive aspects of the package, and not try to draw comparisons towards other packages. IMO. A package description is intended for the administrator to choose which of a set of alternatives to install. A comparison to others, or being open about possible limitations, are very helpful to make this decision. Use debtags for that. The description should describe the package (the program) to a user (system administrator) who has never met it before so that they have enough information to decide whether they want to install it. This description should not just be copied verbatim from the program's documentation. Policy 3.4 It seems to me as if you are trying to get people to justify the packages they want to work on. Yes, and that's very desirable. Telling people to go away because you don't want to QA their package is not desirable at all. Having a poorly QAed OS because not hurting people's feelings takes is more important than making sound technical decisions is less desirable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467249: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale
On Thu, Feb 28, 2008 at 10:10:32PM +, brian m. carlson wrote: On Thu, Feb 28, 2008 at 09:30:55PM +, Colin Watson wrote: On Thu, Feb 28, 2008 at 09:21:41PM +0100, Adam Borowski wrote: man-db really does have some special-casing here. Trust me. It was necessary at the time. There are a finite number of known aliases for the very small number of locales in question, and until it becomes unnecessary I will simply support those. (And I agree that it should go away, but can't easily just yet.) Is there some way to query what character set a locale uses? Yes, nl_langinfo (CODESET). If not, I think that man-db should default to UTF-8 (since that *is* the standard on Debian) and handle exceptions to that. Processing an ASCII manpage as UTF-8 is a no-op. And it's pretty easy to tell if something isn't valid UTF-8, and man-db can handle that as it normally would. Please review the changes that I made in man-db 2.5.0 and 2.5.1, which I think make this speculation unnecessary. AIUI, PostScript doesn't have UTF-8 support either, yet it seems to work just fine. Anyway, newer versions of groff have a conversion tool that maps UTF-8 (or any arbitrary character set) input into glyph names. But Debian's groff has been very heavily patched with support for kinsoku shori (prohibition character handling) and so we cannot simply update to a newer version. Believe me, if it were that easy, I'm sure Colin would have done it. Indeed so (I have tried before). I've had it with special-cased hacks to groff - I want either something that goes upstream, or else to stick with what we have until something *can* go upstream. I'm finished with nasty typographically-unsound workarounds. Are you working with Brian M. Carlson on this? He has been working on a solution acceptable to groff upstream, which is, frankly, the only way I want to go now. He has already made substantial progress with character class support. Please be aware that I have little time with school right now, so this may not be implemented soon. In fact, it may not be ready in time for lenny's release. I will sit down and work on it some more soon, but my time is limited. If people want more information on my plan of attack, please do let me know, and I'll be happy to share. Drat. Understood, though. I do follow the groff list (when my spam filters haven't decided that it's statistically all spam ...) and do hope to find time to build something useful on top of the work you've posted there already. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468820: ITP: soothsayer -- intelligent predictive text entry platform (tools and demos)
Michael Biebl wrote: Matteo Vescovi wrote: Package: wnpp Severity: wishlist Owner: Matteo Vescovi [EMAIL PROTECTED] * Package name: soothsayer Hi Matteo, please see http://lists.debian.org/debian-devel/2008/01/msg00368.html In short: You only file *one* ITP for the source package, not ITPs for every single binary package you build from the source package. Cheers, Michael Hi, I merged and retitled the ITPs. Sorry for the noise on the mailing list. Cheers, - Matteo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Hi, For people who are trying to figure out what my merging and branching workflow looks like, I have uploaded a recent picture for fvwm at: http://people.debian.org/~srivasta/fvwm.png I should warn you that this is a large image; and is known to crash iceweasel. I suggest downloading it and using gqview, and go to the 1:1 zoom, and pan around. Having done that, ask yourself if you really want to write a script that trolls through such a branch and merge history to automatically generate a stacked patch series. manoj -- Four be the things I'd have been better without: love, curiosity, freckles and doubt. -- Dorothy Parker 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: Buildd backlog and testing transition.
Le Sat, Mar 01, 2008 at 12:15:17PM +0100, Julien BLACHE a écrit : Charles Plessy [EMAIL PROTECTED] wrote: He doesn't have to use unstable. He can use pinning for this specific package. Sure, and he can also use dpkg -i. The question is: why should we ask him to make the effort? For the moment, the answer is: As a side effect trying to build ghc6 on MIPS, many (hundreds?) other packages are blocked from migrating to testing for more than a month. Clearly, in the conflict of interest between the ghc6 MIPS users, and the testing users on other arches, a choice has been made, of which I am unhappy. I ask: - Who is in charge for taking such a decision ? - Where can I appeal ? These broken buildds are like a broken car in the middle street. People would be happy to push it to the next car station, but if the driver says that he will not move his car until somebody will repair it, he can expect the people in the traffic jam to be annoyed. Stop whining. C'est celui qui le dit qui l'est. What do you expect when posting such sentence on this mailing list? Bon dimanche, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
On 2008-03-01, Charles Plessy [EMAIL PROTECTED] wrote: I ask: - Who is in charge for taking such a decision ? Release team - Where can I appeal ? Tech-ctte /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the?HTTP/1.1 protocol
On Sat, Mar 1, 2008 at 18:57:47 +0100, Romain Beauxis wrote: Now, unless we decide to, Debian is not meant to refuse any *new* package. Sure it is. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467249: man-db/groff and locales
On Fri, Feb 29, 2008 at 12:32:29AM +0100, Adam Borowski wrote: On Thu, Feb 28, 2008 at 10:10:32PM +, brian m. carlson wrote: On Thu, Feb 28, 2008 at 09:30:55PM +, Colin Watson wrote: man-db really does have some special-casing here. Trust me. It was necessary at the time. There are a finite number of known aliases for the very small number of locales in question, and until it becomes unnecessary I will simply support those. Of, course, encodings for _source_ pages are those we can't get away with. But for all intermediate steps, I don't see any reason to not go to a well-known encoding, do everything there and finally convert to whatever locale is set -- and you don't even need to name the charset there. Special-casing _output_ locales seems quite strange to me. /* An ugly special case is needed here. The utf8 device normally * takes ISO-8859-1 input. However, with the multibyte patch, when * recoding from CJK character sets it takes UTF-8 input instead. * This is evil, but there's not much that can be done about it * apart from waiting for groff 2.0. */ (And I agree that it should go away, but can't easily just yet.) Could you tell us what keeps us with all the old cruft? Sanity. I am not interested in making the groff package even more incredibly difficult to update to a new upstream in the future. Official groff does not yet support proper CJK typography. Until that is in place it is not a viable replacement. (I'm also really fed up of explaining this again and again. I think I'm fairly clearly active in man-db; could you please accept that I have my reasons beyond laziness, and look up what has been said on this topic over and over again in the past?) Is there some way to query what character set a locale uses? If not, I think that man-db should default to UTF-8 (since that *is* the standard on Debian) and handle exceptions to that. Processing an ASCII manpage as UTF-8 is a no-op. And it's pretty easy to tell if something isn't valid UTF-8, and man-db can handle that as it normally would. AOL. I agree with Brian 100%. As you already added code to detect if the source is valid UTF-8 or not, all that needs to be done is using UTF-8 instead of ISO-8859-1 as the intermediate format. There is a lot more to it than that or upstream would be recommending that already; the version of groff we are using does not have the internal capabilities that are needed (our changes are a band-aid at best). Reading this thread may be a helpful summary: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01378.html In short, I am not interested in doing this on top of our current groff package. I want to do it on top of a whole new upstream that actually has the features we need with an upstream maintainer prepared to support them (note that nobody has stepped forward to do any maintenance work on the Debian multibyte patch for years). Doing that without also forward-porting our patches for features such as kinsoku shori would introduce regressions. Forward-porting these patches hackily is incredibly difficult (I've tried). Forward-porting those patches in a way that is consistent with upstream's direction (i.e. reimplementing them) is essentially Brian's work. I see. So, in very short term, groff would be able to output PostScript only for limited locales. That's no regression. And on tty and html, which are 99.99% of uses of man, suddenly all bugs like man iso-8859-2, Kanji names in English manpages, regressions in KOI-8R (#424655) or no support for Indic scripts would dissappear overnight with a minimal patch. I would love to have these new features, but I want them on top of a sane, supportable upstream release. I am sick of the mess we have now and don't want to make it worse. I also want to actually have us contribute something useful to groff upstream beyond confused users showing up on their mailing list and having to be told that this is a weirdness of Debian's groff package. I am honestly not willing to support a backport of -K/preconv to our groff package, with all of the other Unicode support that should come along with it in order to do a good job. I also enjoy maintaining this stuff too much to resign. Therefore I must encourage you to help upstream with the last few pieces needed in order to get this all merged properly. Finally, I suspect you'll find that e.g. the specialised kerning code that's in Debian's groff for proper rendering of ASCII/EUC-JP boundaries will cause problems with generalised UTF-8 rendering unless properly forward-ported. I'm fairly sure there are more such examples; that's just the first I could find easily having been away from that particular code for a while. If you don't speak all the languages in question, you might not notice this kind of thing on casual inspection of the output. Typography involves more than just getting all the characters into
Re: How to cope with patches sanely
On Fri, Feb 29, 2008 at 09:30:16PM +0100, Florian Weimer wrote: * Ben Finney: It's no security risk to unpack a tarball, apply a patch to it via GNU 'patch', and examine the result. History should tell you that this is not true. 8-) I can even understand people who state that GNU tar should never be used to uncompress tarballs from untrusted sources, and we therefore do not need to provide security support for it, but this is going a bit too far for my taste. But my point really is: Please do do not use potential security issues as arguments. The overall situation is sufficiently bad that this can be used to prove *anything*. I think the difference between the occasional vulnerability in GNU tar and a system that is designed to operate by executing arbitrary marginally-trusted code is, erm, rather significant. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (user)tagging wnpp bugs
Thank you for your feedback... Alle 21:41, sab 1 marzo 2008, Don Armstrong ha scritto: If nothing against comes up, I'm going to use such usertags as [EMAIL PROTECTED] and report (lots of) RFPs (and possibly some ITP!) for fields I am interested in. I'd suggest just picking a reasonable subset of the tags I shall see, didn't even quickly screened for applicable tags, anyway I guess they will be a subset of debtags + a few wnpp-specific tags. We haven't yet created a wiki page. and using the [EMAIL PROTECTED] user so the tags are visible by default. I wasn't aware of this. It's fine to me. [Well, after testing using your own user, of course.] or maybe using [EMAIL PROTECTED] again. ;-) Cheers, -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)
On Sat, Mar 1, 2008 at 7:53 AM, Andreas Tille [EMAIL PROTECTED] wrote: Is there any reason why a Debian should spend resources to maintain things that are not good enough for Debian? Debian isn't being asked to do any such thing. I've been thinking about doing this for a long time, one of the points in the proposal I'd written was that DDs would be discouraged from participating since they should be working on supporting the official archive. For the not good enough _yet_ there is experimental. experimental relies on DDs to upload, ftpmasters would probably reject packages with no Maintainer field (or a blank one). experimental is not the right place for this. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, 29 Feb 2008, Mike Bird wrote: On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote: On Fri, 29 Feb 2008, Mike Bird wrote: I'm not a DD but I've been programming since 1963 when I was 7. Based on decades of software engineering experience, I would just like to remind you to USE THE FSCKING SOURCE!!! I am not sure this applies to dpkg, but in kernel land, the full reasoning behind even one-line trivial patches to some deep-magic areas are just plain impossible to understand without a ton of explanations in the log. Irrelevant. The size and complexity of dpkg are not in the same ballpark, county, state, country, or hemisphere as the kernel. So, every change in dpkg code is *always* completely obvious, and you never need any extra information that is not in a comment? Really? I am prepared to accept that as truth for a seasoned dpkg developer, but only if I hear it from all current active dpkg developers. Because even if a single one of them has found a (good) commit log to be valuable to understand something, that means you are wrong. And I am completely *sure* it would not be irrelevant for me were I debugging dpkg without a full, complete, dpkg-regular-developer level of understanding of the code. Or if I were trying to understand how dpkg works, so as to start working on dpkg, for that matter. Logs are not the source. No matter how much time you waste fiddling with them, they are really unimportant. Programmers Sorry, I don't agree with you. Logs are important. Especially if one member of the team quits, and another has to join in and find out exactly what was happening to the code at that point in time (as opposed to reading the code at that point in time, to know how it looked like). A log by this measure has temporary value during development of a new feature. Thereafter the value is negligable. Therefore by this measure Oh, not at all. Don't you at least look at the commit log comments for any line of code that just plain doesn't make sense to you should you find yourself in need to change that line of code or the code surrounding it? Properly written commit logs tell you what the programmer INTENDED TO DO when he commited a set of changes, and often also WHY he wanted to do it in a specific way. That in itself can be very valuable information if either some of it is not obvious, or if (surprise!) the programmer made a mistake in the code he commited, and it doesn't actually do what he intended it to! Of course, the commit log might be erroneous. In which case someone will end up wasting time making sure the code is correct even if it doesn't do what the commit logs says it should. That happens, too. And if it happens too often on your team, then yes, you would be better of without any commit logs at all. In other words, good commit logs aid debugging and maintainance when it is not being done by the one who wrote the code in the first place (and depending on how good his memory is, even for the one who wrote the code). it is not worth spending time prettifying logs for git merges of completed features. That is not for you to decide, that's for whomever will do the merge to decide. You can refuse to do any such prettifying (if anyone asks you to in the first place), but upstream is also in its right to do the prettifying themselves (since they clearly think it is that important!) or to just ignore your contributions, then. should be documented in a design document or noted in a comment. Comments have this very bad property of getting stale, which really is a damn pity, as comments are in the code and therefore extremely more likely to be read by someone trying to modify that area of the code. Logs are never stale, as they are only valid at one exact point in time and they are tied to a specific set of changes anyway. But they don't have the extreme advantage of locality that comments do. You need *both*, and you need to take good care of *both*. You may wish to have both logs and comments but you have not demonstrated any value to logs other than for WIP, nor any return on the investment of Ian's time to prettify logs for you. There is more than writing code, there is *maintaining* it. Which is far more important than writing code in the first place for every long-lived and important piece of infrastructure (like dpkg, like the kernel). If good commit logs and history are usefull for debugging and maintaining the code down the road, then they ARE important. And that has nothing to do with work-in-progress. Now, I am currently not going to bother to explain right now why commit logs are important when debugging code one is not intimately familiar with. Maybe later, if I have nothing better to do. But it has to do with it speeding up the debugging a great deal if you know what the code author wanted to do in the first place, and also helping you locate where the bug might be
Re: mass ITPs
On Sat, Mar 01, 2008 at 08:49:05PM +0100, Romain Beauxis [EMAIL PROTECTED] was heard to say: Le Saturday 01 March 2008 19:48:50 Christian Perrier, vous avez écrit : If someone cares to listen: when you think about ITPing each and every piece of FLOSS that pops around: think about *helping* people who maintain existing packages instead of adding even more noise to our noisy bunch of various crap^W software. Hey, reading you I figured out that all newcomers are required to have contributions in Debian, which means *new packages*. [EMAIL PROTECTED]:~$ aptitude search '~mDebian QA' | wc -l 489 Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openbox 3.4.6.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 09:09:55 +0100 Source: openbox Binary: openbox libobparser16 libobrender16 openbox-dev Architecture: source i386 Version: 3.4.6.1-1 Distribution: unstable Urgency: low Maintainer: Openbox Maintainers [EMAIL PROTECTED] Changed-By: Nico Golde [EMAIL PROTECTED] Description: libobparser16 - parsing library for openbox libobrender16 - rendering library for openbox themes openbox- standards compliant, fast, light-weight, extensible window manage openbox-dev - standards compliant, fast, light-weight, extensible window manage Changes: openbox (3.4.6.1-1) unstable; urgency=low . [Nico Golde] * New upstream version. * Switch to compat level 6 as it is the default now. . [Anibal Avelar] * Added the field Vcs-Svn field instead the Vcs-Git field instead. This fields should point to the control version for Debian package not to the upstream source code. * Modified the Vcs-Browser value to the correct site due to the same reason described above. * Updated the soname minor number to 0.4 version in libobparser16.install, libobrender16.install and openbox-dev.links Files: 57014770b83606ed3f87ea3c586af686 1068 x11 optional openbox_3.4.6.1-1.dsc c3a72d9fb956128cee7fd27ff19f 781848 x11 optional openbox_3.4.6.1.orig.tar.gz b432b84096a81be5f5e937879eb447d2 23828 x11 optional openbox_3.4.6.1-1.diff.gz 7e9301c7a1ee4b087e7d4173c7c2773a 267624 x11 optional openbox_3.4.6.1-1_i386.deb bbac95247037b7c63a63e69bc879a8d5 33820 libs optional libobparser16_3.4.6.1-1_i386.deb 14d70522b879e6a70a0ca41103e13590 61344 libs optional libobrender16_3.4.6.1-1_i386.deb d54a66e41146e68b62df29100fe920d1 69776 libdevel optional openbox-dev_3.4.6.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyRpBHYflSXNkfP8RAi91AKCCR+x01WMAwvwVZ6i9MVkdmLeZyQCfZTvQ +uWUy4eEvoU4TDCTwiiWMrk= =Pqgl -END PGP SIGNATURE- Accepted: libobparser16_3.4.6.1-1_i386.deb to pool/main/o/openbox/libobparser16_3.4.6.1-1_i386.deb libobrender16_3.4.6.1-1_i386.deb to pool/main/o/openbox/libobrender16_3.4.6.1-1_i386.deb openbox-dev_3.4.6.1-1_i386.deb to pool/main/o/openbox/openbox-dev_3.4.6.1-1_i386.deb openbox_3.4.6.1-1.diff.gz to pool/main/o/openbox/openbox_3.4.6.1-1.diff.gz openbox_3.4.6.1-1.dsc to pool/main/o/openbox/openbox_3.4.6.1-1.dsc openbox_3.4.6.1-1_i386.deb to pool/main/o/openbox/openbox_3.4.6.1-1_i386.deb openbox_3.4.6.1.orig.tar.gz to pool/main/o/openbox/openbox_3.4.6.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mailgraph 1.14-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 09:45:23 +0100 Source: mailgraph Binary: mailgraph Architecture: source all Version: 1.14-1 Distribution: unstable Urgency: medium Maintainer: Norbert Tretkowski [EMAIL PROTECTED] Changed-By: Norbert Tretkowski [EMAIL PROTECTED] Description: mailgraph - Mail statistics RRDtool frontend for Postfix Closes: 300796 433510 459311 468377 Changes: mailgraph (1.14-1) unstable; urgency=low . * New upstream release. (closes: #459311, #468377) + Add support for Exim. (closes: #300796) . mailgraph (1.13-1.1) unstable; urgency=medium . * Non-maintainer upload. * Fix Local changes to /etc/default/mailgraph are overwritten by using the current configuration in debian/config. (closes: #433510) Files: 33aff2c8faf1f78783d3296352245fb1 593 admin extra mailgraph_1.14-1.dsc 0f0ae91968ea7ae0c1d14985c560530b 22014 admin extra mailgraph_1.14.orig.tar.gz a8dda278927b56d504bbc7b4ecd005dd 11711 admin extra mailgraph_1.14-1.diff.gz 042c6341fb4834e4a4c563f321a7a730 24606 admin extra mailgraph_1.14-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyRxAr/RnCw96jQERAqjgAJwLAV/Fc08N4ulBsdrl4+WlRcWUnwCfUxWR /+EOftC0PD4DRmgby13JE10= =Hxde -END PGP SIGNATURE- Accepted: mailgraph_1.14-1.diff.gz to pool/main/m/mailgraph/mailgraph_1.14-1.diff.gz mailgraph_1.14-1.dsc to pool/main/m/mailgraph/mailgraph_1.14-1.dsc mailgraph_1.14-1_all.deb to pool/main/m/mailgraph/mailgraph_1.14-1_all.deb mailgraph_1.14.orig.tar.gz to pool/main/m/mailgraph/mailgraph_1.14.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-patch-grsecurity2 2.1.11~200802192340-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 07:54:46 + Source: linux-patch-grsecurity2 Binary: linux-patch-grsecurity2 Architecture: source all Version: 2.1.11~200802192340-1 Distribution: unstable Urgency: low Maintainer: Laszlo Boszormenyi (GCS) [EMAIL PROTECTED] Changed-By: Laszlo Boszormenyi (GCS) [EMAIL PROTECTED] Description: linux-patch-grsecurity2 - grsecurity kernel patch - new major upstream version Changes: linux-patch-grsecurity2 (2.1.11~200802192340-1) unstable; urgency=low . * New test upstream release. * Don't put PaX patch to kpatches as its kernel version clashes with GRSecurity. * Architecture independent package, don't depend binary on binary-arch . Files: 28cf351e0be8b6aaa9a40be10aecadc9 745 devel extra linux-patch-grsecurity2_2.1.11~200802192340-1.dsc 911d21f3a5eb0f3d06b1677400701b76 438294 devel extra linux-patch-grsecurity2_2.1.11~200802192340.orig.tar.gz 334acaa9aaf167b21b442801e751834d 18169 devel extra linux-patch-grsecurity2_2.1.11~200802192340-1.diff.gz c885c26448314479e4aacfbbddb06091 278558 devel extra linux-patch-grsecurity2_2.1.11~200802192340-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyRdnMDatjqUaT90RAr17AJ923+4S8402qVq2jOTIpDIUG9/2yQCfT/mM inSE/4+VBP/Q7FaNgOsBz1w= =w+ay -END PGP SIGNATURE- Accepted: linux-patch-grsecurity2_2.1.11~200802192340-1.diff.gz to pool/main/l/linux-patch-grsecurity2/linux-patch-grsecurity2_2.1.11~200802192340-1.diff.gz linux-patch-grsecurity2_2.1.11~200802192340-1.dsc to pool/main/l/linux-patch-grsecurity2/linux-patch-grsecurity2_2.1.11~200802192340-1.dsc linux-patch-grsecurity2_2.1.11~200802192340-1_all.deb to pool/main/l/linux-patch-grsecurity2/linux-patch-grsecurity2_2.1.11~200802192340-1_all.deb linux-patch-grsecurity2_2.1.11~200802192340.orig.tar.gz to pool/main/l/linux-patch-grsecurity2/linux-patch-grsecurity2_2.1.11~200802192340.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted emboss 5.0.0-5 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 11:46:26 +0900 Source: emboss Binary: emboss emboss-data emboss-doc emboss-lib libajax5 libajax5-dev libnucleus5 libnucleus5-dev Architecture: source i386 all Version: 5.0.0-5 Distribution: unstable Urgency: low Maintainer: Debian-Med Packaging Team [EMAIL PROTECTED] Changed-By: Charles Plessy [EMAIL PROTECTED] Description: emboss - The European Molecular Biology Open Software Suite emboss-data - Data files for the EMBOSS package emboss-doc - Documentation for EMBOSS emboss-lib - EMBOSS Libraries libajax5 - EMBOSS library for commands libajax5-dev - Development files for libajax libnucleus5 - EMBOSS library for molecular sequence analysis libnucleus5-dev - Development files for libajax Changes: emboss (5.0.0-5) unstable; urgency=low . * New bugfixes released upstream. - Fixes changed ID format in GCG databases. - Fixes reading from PIR databases. - Fixes a problem with O in protein sequences for pyrrolysine. - Fixes a problem in GENBANK output format. - Fixes a problem in reading protein sequences from Staden spin interface. - Fixes tokens that are longer than the maximum length. - debian/patches now uses the monolithic upstream patch instead of file-per-file fixes. You can find longer explanations in the header of debian/patches/patch-1-3. Files: 072b7893602d091799838aa58edc518b 1142 science optional emboss_5.0.0-5.dsc fa3363d7660766463f6a4f63ea6466b7 240876 science optional emboss_5.0.0-5.diff.gz 6f5f1c6192d0ed474bb20d24cea7d28f 800332 science optional emboss_5.0.0-5_i386.deb 1d29fe6bd238b0cc88c4637f7ee11773 657668 science optional emboss-data_5.0.0-5_all.deb 94cc04773a474d8a684f072fa2ea959c 4496902 doc optional emboss-doc_5.0.0-5_all.deb 33f25af38b897c3be07e25d51446b538 389150 libs optional emboss-lib_5.0.0-5_i386.deb 298703d62c39f1e11bd484d9fd13899d 683724 libs optional libajax5_5.0.0-5_i386.deb 79f44b9e38463ce3c124f451143104f3 806650 libdevel optional libajax5-dev_5.0.0-5_i386.deb f906fb007fe7c5e02ec53c96bb7a5275 179390 libs optional libnucleus5_5.0.0-5_i386.deb 2f3c9213f6d43675513cc921d3ff7843 196160 libdevel optional libnucleus5-dev_5.0.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyQu/dYl1krr+x/IRAk8pAJ4rpEH4gfTlprDLUWCH4JSu1It4MQCdHAb3 d/7ZXZZFe7DzbPR6Rnt3qDY= =lCKD -END PGP SIGNATURE- Accepted: emboss-data_5.0.0-5_all.deb to pool/main/e/emboss/emboss-data_5.0.0-5_all.deb emboss-doc_5.0.0-5_all.deb to pool/main/e/emboss/emboss-doc_5.0.0-5_all.deb emboss-lib_5.0.0-5_i386.deb to pool/main/e/emboss/emboss-lib_5.0.0-5_i386.deb emboss_5.0.0-5.diff.gz to pool/main/e/emboss/emboss_5.0.0-5.diff.gz emboss_5.0.0-5.dsc to pool/main/e/emboss/emboss_5.0.0-5.dsc emboss_5.0.0-5_i386.deb to pool/main/e/emboss/emboss_5.0.0-5_i386.deb libajax5-dev_5.0.0-5_i386.deb to pool/main/e/emboss/libajax5-dev_5.0.0-5_i386.deb libajax5_5.0.0-5_i386.deb to pool/main/e/emboss/libajax5_5.0.0-5_i386.deb libnucleus5-dev_5.0.0-5_i386.deb to pool/main/e/emboss/libnucleus5-dev_5.0.0-5_i386.deb libnucleus5_5.0.0-5_i386.deb to pool/main/e/emboss/libnucleus5_5.0.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fonttools 2.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 16:58:54 +0900 Source: fonttools Binary: fonttools Architecture: source i386 Version: 2.1-1 Distribution: unstable Urgency: low Maintainer: Paul Wise [EMAIL PROTECTED] Changed-By: Paul Wise [EMAIL PROTECTED] Description: fonttools - Converts OpenType and TrueType fonts to and from XML Closes: 434377 449785 468585 Changes: fonttools (2.1-1) unstable; urgency=low . * New upstream release - Fixes traceback on amd64 with DejaVuSans.ttf (Closes: #434377) - Drop 20_cjk_performance_improvement, 01_update_changelog, both have been applied upstream * Fix watch file so that it works with the release (Closes: #449785) * Drop unneeded dependency on python-xml (Closes: #468585) * Bump Standards-Version (no changes needed) Files: 26eb25c9e54b65091dcce59f90e99084 736 text optional fonttools_2.1-1.dsc 1626df56636867f6e1f87e7ef99768de 304336 text optional fonttools_2.1.orig.tar.gz ebe9e4754b5636e39d06072b8dd85774 6625 text optional fonttools_2.1-1.diff.gz b26968200b9f410fbb2f14366f20c824 299112 text optional fonttools_2.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyRFv5Sc9mGvjxCMRAtoIAKCDdnrd+kFuXGPGwOzp2q5+7/3J7gCdHMdi /EwohrrxbRLvDCtfFwXVwMo= =CIjB -END PGP SIGNATURE- Accepted: fonttools_2.1-1.diff.gz to pool/main/f/fonttools/fonttools_2.1-1.diff.gz fonttools_2.1-1.dsc to pool/main/f/fonttools/fonttools_2.1-1.dsc fonttools_2.1-1_i386.deb to pool/main/f/fonttools/fonttools_2.1-1_i386.deb fonttools_2.1.orig.tar.gz to pool/main/f/fonttools/fonttools_2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted scummvm 0.11.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 10:28:14 +0200 Source: scummvm Binary: scummvm Architecture: source i386 Version: 0.11.1-1 Distribution: unstable Urgency: low Maintainer: David Weinehall [EMAIL PROTECTED] Changed-By: David Weinehall [EMAIL PROTECTED] Description: scummvm- free implementation of LucasArts' SCUMM interpreter Changes: scummvm (0.11.1-1) unstable; urgency=low . * New upstream release * Install upstream NEWS file too Files: dfb1a7774e2e5cfe39e55282dab20f4b 751 games optional scummvm_0.11.1-1.dsc 0932f3cb1a488b37ba58dbfab063f7af 6722215 games optional scummvm_0.11.1.orig.tar.gz 6efe231bd321ed8436f4ab8ae472f2e4 6964 games optional scummvm_0.11.1-1.diff.gz ec62606c158e75218b3c315229003e30 2339884 games optional scummvm_0.11.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyRip0U6FJtxHyhYRApo0AJ44yuR/fF7P3Yl/egpizX3ij4vSaACfb1R4 tcyiouiZ1RBA55PeytxySYE= =vxRk -END PGP SIGNATURE- Accepted: scummvm_0.11.1-1.diff.gz to pool/main/s/scummvm/scummvm_0.11.1-1.diff.gz scummvm_0.11.1-1.dsc to pool/main/s/scummvm/scummvm_0.11.1-1.dsc scummvm_0.11.1-1_i386.deb to pool/main/s/scummvm/scummvm_0.11.1-1_i386.deb scummvm_0.11.1.orig.tar.gz to pool/main/s/scummvm/scummvm_0.11.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgetopt-declare-perl 1.11-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 10:14:06 +0100 Source: libgetopt-declare-perl Binary: libgetopt-declare-perl Architecture: source all Version: 1.11-2 Distribution: unstable Urgency: low Maintainer: Bart Martens [EMAIL PROTECTED] Changed-By: Bart Martens [EMAIL PROTECTED] Description: libgetopt-declare-perl - Getopt::Declare command line argument parser Closes: 467946 Changes: libgetopt-declare-perl (1.11-2) unstable; urgency=low . * debian/rules: Removed the removal of /usr/lib/perl5. Closes: #467946. * debian/control: Homepage, Standards-Version, and my e-mail address. Files: b6d162d727542d7e2c185ddd0c8bee59 675 perl optional libgetopt-declare-perl_1.11-2.dsc e01aeb2cf85aabcdfb998ead62613852 1806 perl optional libgetopt-declare-perl_1.11-2.diff.gz c2b1f3697b6e9918e3e31793d7e415f9 61662 perl optional libgetopt-declare-perl_1.11-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyR9UbMaawmho9B8RAmqnAKClNuxm5nUW+ckgsBuV46G2e8mYXwCdFeiw duh6f6kFcB/q1tTbBkBmBXE= =Z2vH -END PGP SIGNATURE- Accepted: libgetopt-declare-perl_1.11-2.diff.gz to pool/main/libg/libgetopt-declare-perl/libgetopt-declare-perl_1.11-2.diff.gz libgetopt-declare-perl_1.11-2.dsc to pool/main/libg/libgetopt-declare-perl/libgetopt-declare-perl_1.11-2.dsc libgetopt-declare-perl_1.11-2_all.deb to pool/main/libg/libgetopt-declare-perl/libgetopt-declare-perl_1.11-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted freetennis 0.4.8-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 10:24:27 +0100 Source: freetennis Binary: freetennis-common freetennis Architecture: source all amd64 Version: 0.4.8-4 Distribution: unstable Urgency: low Maintainer: Bart Martens [EMAIL PROTECTED] Changed-By: Bart Martens [EMAIL PROTECTED] Description: freetennis - Free Tennis - simulation game freetennis-common - Free Tennis - simulation game Closes: 433519 435435 Changes: freetennis (0.4.8-4) unstable; urgency=low . * debian/freetennis.8: Man page corrections. Closes: #433519. Patch by Andy Matteson [EMAIL PROTECTED], thanks. * debian/freetennis.desktop: Added .desktop file. Closes: #435435. Patch by William Lima [EMAIL PROTECTED], thanks. * Fixed debian-rules-ignores-make-clean-error. * Fixed package-section-games-but-contains-no-game. Files: 2a693dfe0fc48f80961eb103070a50f5 837 games optional freetennis_0.4.8-4.dsc 908aeee2a2d712aae1e79a648144b2f5 3785 games optional freetennis_0.4.8-4.diff.gz db000522f7d62afbf7a34a4ac173a3ce 6520460 games optional freetennis-common_0.4.8-4_all.deb 8386652ff6914d6c98f8fae3725bddbc 371598 games optional freetennis_0.4.8-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHySkNbMaawmho9B8RAuCfAJ9K8uMVSqFpDDM8aycbfNwxfZm9kACeNecr +wBqiYBuk3TWvErWETl+niU= =J/WU -END PGP SIGNATURE- Accepted: freetennis-common_0.4.8-4_all.deb to pool/main/f/freetennis/freetennis-common_0.4.8-4_all.deb freetennis_0.4.8-4.diff.gz to pool/main/f/freetennis/freetennis_0.4.8-4.diff.gz freetennis_0.4.8-4.dsc to pool/main/f/freetennis/freetennis_0.4.8-4.dsc freetennis_0.4.8-4_amd64.deb to pool/main/f/freetennis/freetennis_0.4.8-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted orage 4.5.12.2-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 11:10:04 +0100 Source: orage Binary: orage Architecture: source amd64 Version: 4.5.12.2-4 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers [EMAIL PROTECTED] Changed-By: Yves-Alexis Perez [EMAIL PROTECTED] Description: orage - Calendar for Xfce Desktop Environment Closes: 468488 Changes: orage (4.5.12.2-4) unstable; urgency=low . * debian/patches: - 01_tune-desktop-file.patch edited, add support for mime type text/calendar in xfcalendar.desktop. - 03_de.po-typo added, correct a typo in de translation.closes: #468488 Files: 5416032814a75634d45cef2ef4d56c27 1034 x11 optional orage_4.5.12.2-4.dsc 59fe9eedc48aebce9fa21f28ca292f8d 12063 x11 optional orage_4.5.12.2-4.diff.gz 3540d9daadbf7fd902733eb11b4cf216 1486360 x11 optional orage_4.5.12.2-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHySwaTUTAIMXAW64RAmfGAKCWecHNT1wpcsuCKC9XgiRyj/C3CwCfQOxW EgcBMAurDQ+OFA/naFwjD/M= =R4mW -END PGP SIGNATURE- Accepted: orage_4.5.12.2-4.diff.gz to pool/main/o/orage/orage_4.5.12.2-4.diff.gz orage_4.5.12.2-4.dsc to pool/main/o/orage/orage_4.5.12.2-4.dsc orage_4.5.12.2-4_amd64.deb to pool/main/o/orage/orage_4.5.12.2-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted directfb 1.0.1-8 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 10:46:17 +0100 Source: directfb Binary: libdirectfb-1.0-0 libdirectfb-1.0-0-udeb libdirectfb-bin libdirectfb-bin-udeb libdirectfb-extra libdirectfb-dev Architecture: source amd64 Version: 1.0.1-8 Distribution: unstable Urgency: low Maintainer: Fathi Boudra [EMAIL PROTECTED] Changed-By: Fathi Boudra [EMAIL PROTECTED] Description: libdirectfb-1.0-0 - direct frame buffer graphics - shared libraries libdirectfb-1.0-0-udeb - direct frame buffer graphics - shared libraries (udeb) libdirectfb-bin - direct frame buffer graphics - binaries libdirectfb-bin-udeb - direct frame buffer graphics - binaries (udeb) libdirectfb-dev - direct frame buffer graphics library - development files libdirectfb-extra - direct frame buffer graphics - extra providers Closes: 465402 465945 Changes: directfb (1.0.1-8) unstable; urgency=low . * Adopt the directfb suite of packages. Set maintainer to Debian DirectFB Team: Otavio Salvador, Luis Mondesi and myself.(Closes: #465402) * Exclude linux specific package to fix FTBFS on GNU/kFreeBSD due to unsatisfied Build-Depends on libts-dev. (Closes: #465945) Files: 857bf69773ac29d7115529e222d19584 1414 libs optional directfb_1.0.1-8.dsc 7fd18beb2c3b6fe0fdb2cee5c5f38d88 18799 libs optional directfb_1.0.1-8.diff.gz a24b31146df8223d2c95169302220816 1186350 libs optional libdirectfb-1.0-0_1.0.1-8_amd64.deb 44c913d7b4ece42f8125e8c612e53d88 390274 debian-installer optional libdirectfb-1.0-0-udeb_1.0.1-8_amd64.udeb 0bebd93525120815603615816c00ccb9 41292 libs optional libdirectfb-bin_1.0.1-8_amd64.deb 2edd01f425508f5af0815037d85b3550 5712 debian-installer optional libdirectfb-bin-udeb_1.0.1-8_amd64.udeb baee255e0df906b2e02a88c1854d277c 32412 libs optional libdirectfb-extra_1.0.1-8_amd64.deb d783ec071dc35989244f46677341c811 851164 libdevel optional libdirectfb-dev_1.0.1-8_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQCVAwUBR8kxqIz1NfZqpXL3AQKq6gP9FbT+Q6uzopqkSlI3oSXR7be+5G90k3ia 6wiWvCqlp3A0Duyeqhk/BMN1xYsMZEdgV8JgTsXIBOueCOaZ9Jn6kTDyTOu1cl+w VfQUORu5hCJk7XzALakDavQGypPF5nnApk9Kw6zZEAfm4XQpd+OhBXvxtSbHiRx8 YkrEC2OVe70= =ucJ5 -END PGP SIGNATURE- Accepted: directfb_1.0.1-8.diff.gz to pool/main/d/directfb/directfb_1.0.1-8.diff.gz directfb_1.0.1-8.dsc to pool/main/d/directfb/directfb_1.0.1-8.dsc libdirectfb-1.0-0-udeb_1.0.1-8_amd64.udeb to pool/main/d/directfb/libdirectfb-1.0-0-udeb_1.0.1-8_amd64.udeb libdirectfb-1.0-0_1.0.1-8_amd64.deb to pool/main/d/directfb/libdirectfb-1.0-0_1.0.1-8_amd64.deb libdirectfb-bin-udeb_1.0.1-8_amd64.udeb to pool/main/d/directfb/libdirectfb-bin-udeb_1.0.1-8_amd64.udeb libdirectfb-bin_1.0.1-8_amd64.deb to pool/main/d/directfb/libdirectfb-bin_1.0.1-8_amd64.deb libdirectfb-dev_1.0.1-8_amd64.deb to pool/main/d/directfb/libdirectfb-dev_1.0.1-8_amd64.deb libdirectfb-extra_1.0.1-8_amd64.deb to pool/main/d/directfb/libdirectfb-extra_1.0.1-8_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wcalc 2.3.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 18 Feb 2008 17:02:46 +0100 Source: wcalc Binary: wcalc Architecture: source i386 Version: 2.3.1-1 Distribution: unstable Urgency: low Maintainer: Daniele Sempione [EMAIL PROTECTED] Changed-By: Daniele Sempione [EMAIL PROTECTED] Description: wcalc - A flexible command-line scientific calculator Closes: 435751 Changes: wcalc (2.3.1-1) unstable; urgency=low . * New upstream release Closes: #435751 * Bump Standards-Version to 3.7.3 * Renamed Apps as Applications in debian/menu * Removed a not anymore useful line in debian/rules Files: c267598634a825fb5d6e0e4362629783 628 math optional wcalc_2.3.1-1.dsc f6b54fc789f4cd241a94453a4cd75dda 325787 math optional wcalc_2.3.1.orig.tar.gz 6d29788b6cd839a75113c4b2c8ab8457 3181 math optional wcalc_2.3.1-1.diff.gz 6cb4d7081b1be33fadd627d64197346f 127566 math optional wcalc_2.3.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyS5Tvdkzt4X+wX8RApVrAJwMS+8VPNnFe3J9RN0hGp5wL9MLugCeLaMm NK4osY/mzjP7Sx7c4KUkNVw= =jIyN -END PGP SIGNATURE- Accepted: wcalc_2.3.1-1.diff.gz to pool/main/w/wcalc/wcalc_2.3.1-1.diff.gz wcalc_2.3.1-1.dsc to pool/main/w/wcalc/wcalc_2.3.1-1.dsc wcalc_2.3.1-1_i386.deb to pool/main/w/wcalc/wcalc_2.3.1-1_i386.deb wcalc_2.3.1.orig.tar.gz to pool/main/w/wcalc/wcalc_2.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ghostscript 8.61.dfsg.1-1.1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 11:18:27 +0100 Source: ghostscript Binary: ghostscript gs gs-esp gs-gpl gs-aladdin gs-common ghostscript-x ghostscript-doc libgs8 libgs-dev Architecture: source all i386 Version: 8.61.dfsg.1-1.1 Distribution: unstable Urgency: high Maintainer: Masayuki Hatta (mhatta) [EMAIL PROTECTED] Changed-By: Nico Golde [EMAIL PROTECTED] Description: ghostscript - The GPL Ghostscript PostScript/PDF interpreter ghostscript-doc - The GPL Ghostscript PostScript/PDF interpreter - Documentation ghostscript-x - The GPL Ghostscript PostScript/PDF interpreter - X Display suppor gs - Transitional package gs-aladdin - Transitional package gs-common - Transitional package gs-esp - Transitional package gs-gpl - Transitional package libgs-dev - The Ghostscript PostScript Library - Development Files libgs8 - The Ghostscript PostScript/PDF interpreter Library Closes: 468190 Changes: ghostscript (8.61.dfsg.1-1.1) unstable; urgency=high . * Non-maintainer upload by security team. * Fix stack based buffer overflow in the zseticcspace() function possibly leading to arbitrary code exeuction via a crafted ps file. (31_CVE-2008-0411.dpatch; Closes: #468190). * Adjusting libgs shlibs file to match the new version number. Files: 4b13d5e051399481cc4f627a8e9a5e00 1075 text optional ghostscript_8.61.dfsg.1-1.1.dsc facf21877c387072d6c3a2942403b8c9 100431 text optional ghostscript_8.61.dfsg.1-1.1.diff.gz 06a4fba09a1ad3466271c7730c9049d8 26318 text extra gs_8.61.dfsg.1-1.1_all.deb deda1d324e052b036389be84920ed323 26320 text extra gs-esp_8.61.dfsg.1-1.1_all.deb aa6a52b47b97b16cc109ca3aff0a7bbd 26318 text extra gs-gpl_8.61.dfsg.1-1.1_all.deb e5ceb8c4993e3ea9a0123141dc3a6809 26320 text extra gs-aladdin_8.61.dfsg.1-1.1_all.deb cf5e7d220594453bf2208bd48d288b40 26326 text extra gs-common_8.61.dfsg.1-1.1_all.deb 5b8795861c2c1c3f58064f16ccd1eda3 2757942 doc optional ghostscript-doc_8.61.dfsg.1-1.1_all.deb 2ca343539641651e42c04f6b9cb13edd 794260 text optional ghostscript_8.61.dfsg.1-1.1_i386.deb 164952e1c8d85ca58cff776e893d69c9 58582 text optional ghostscript-x_8.61.dfsg.1-1.1_i386.deb ccdf6e61e0ce1ef563d0fd30f3dcd0e8 2193984 libs optional libgs8_8.61.dfsg.1-1.1_i386.deb a66592348519a92715d1c103872dd5c0 35042 libdevel optional libgs-dev_8.61.dfsg.1-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyTWTHYflSXNkfP8RAqMEAJoCrC8YH6kqlKzWBG32QyXfKbQ5xQCfVkqm eTg0nRXN5GXVRyHN4QHgksA= =rZKj -END PGP SIGNATURE- Accepted: ghostscript-doc_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/ghostscript-doc_8.61.dfsg.1-1.1_all.deb ghostscript-x_8.61.dfsg.1-1.1_i386.deb to pool/main/g/ghostscript/ghostscript-x_8.61.dfsg.1-1.1_i386.deb ghostscript_8.61.dfsg.1-1.1.diff.gz to pool/main/g/ghostscript/ghostscript_8.61.dfsg.1-1.1.diff.gz ghostscript_8.61.dfsg.1-1.1.dsc to pool/main/g/ghostscript/ghostscript_8.61.dfsg.1-1.1.dsc ghostscript_8.61.dfsg.1-1.1_i386.deb to pool/main/g/ghostscript/ghostscript_8.61.dfsg.1-1.1_i386.deb gs-aladdin_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/gs-aladdin_8.61.dfsg.1-1.1_all.deb gs-common_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/gs-common_8.61.dfsg.1-1.1_all.deb gs-esp_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/gs-esp_8.61.dfsg.1-1.1_all.deb gs-gpl_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/gs-gpl_8.61.dfsg.1-1.1_all.deb gs_8.61.dfsg.1-1.1_all.deb to pool/main/g/ghostscript/gs_8.61.dfsg.1-1.1_all.deb libgs-dev_8.61.dfsg.1-1.1_i386.deb to pool/main/g/ghostscript/libgs-dev_8.61.dfsg.1-1.1_i386.deb libgs8_8.61.dfsg.1-1.1_i386.deb to pool/main/g/ghostscript/libgs8_8.61.dfsg.1-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted leafnode 1.11.7.rc1-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 10:45:28 + Source: leafnode Binary: leafnode Architecture: source amd64 Version: 1.11.7.rc1-5 Distribution: unstable Urgency: low Maintainer: Mark Brown [EMAIL PROTECTED] Changed-By: Mark Brown [EMAIL PROTECTED] Description: leafnode - NNTP server for small sites Closes: 468210 Changes: leafnode (1.11.7.rc1-5) unstable; urgency=low . * Include Finnish translation of the debconf templates, kindly provided by Esko Arajärvi [EMAIL PROTECTED] (closes: #468210). Files: 454c395ab3c0d2d966551fc4acfa5cbe 593 news extra leafnode_1.11.7.rc1-5.dsc 4472208375a60b27273fb39f91628ae1 52368 news extra leafnode_1.11.7.rc1-5.diff.gz 3850529399da5d6b16fa01cf82233e3e 341440 news extra leafnode_1.11.7.rc1-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyTTVJ2Vo11xhU60RAmLkAJ9lITga38rRv7fXThMBbvYs3TmjnQCbBqu1 Y85ckMsC60KG0r/kc9xkZ4E= =rp9+ -END PGP SIGNATURE- Accepted: leafnode_1.11.7.rc1-5.diff.gz to pool/main/l/leafnode/leafnode_1.11.7.rc1-5.diff.gz leafnode_1.11.7.rc1-5.dsc to pool/main/l/leafnode/leafnode_1.11.7.rc1-5.dsc leafnode_1.11.7.rc1-5_amd64.deb to pool/main/l/leafnode/leafnode_1.11.7.rc1-5_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted snownews 1.5.7-8 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 12:14:39 +0100 Source: snownews Binary: snownews Architecture: source i386 Version: 1.5.7-8 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Nico Golde [EMAIL PROTECTED] Description: snownews - Text mode RSS newsreader Changes: snownews (1.5.7-8) unstable; urgency=low . * Orphaning this package and setting maintainer to QA group. * Bump standards version, no changes needed. * Bump compat level to 6 as it is default now. * Convert homepage tag to homepage control field. Files: a78e4b1ad86ebb144c0463689da1f315 664 net optional snownews_1.5.7-8.dsc 2f4a88315c9d0503ae9002206a2a9c0a 17129 net optional snownews_1.5.7-8.diff.gz 2edcf688bd17fdb9e3b19aa5c40ef311 138712 net optional snownews_1.5.7-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyTvhHYflSXNkfP8RArAuAKCiQH8Q/R8HZJ8+/4k8/A4ZQJayEgCfVQd2 akQ4CQoQKXo7WmDfaIJg6vs= =3K+v -END PGP SIGNATURE- Accepted: snownews_1.5.7-8.diff.gz to pool/main/s/snownews/snownews_1.5.7-8.diff.gz snownews_1.5.7-8.dsc to pool/main/s/snownews/snownews_1.5.7-8.dsc snownews_1.5.7-8_i386.deb to pool/main/s/snownews/snownews_1.5.7-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted findutils 4.3.13-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 12:34:04 +0100 Source: findutils Binary: findutils locate Architecture: source i386 Version: 4.3.13-1 Distribution: experimental Urgency: low Maintainer: Andreas Metzler [EMAIL PROTECTED] Changed-By: Andreas Metzler [EMAIL PROTECTED] Description: findutils - utilities for finding files--find, xargs locate - maintain and query an index of a directory tree Closes: 459570 460733 461585 Changes: findutils (4.3.13-1) experimental; urgency=low . * New upstream version. #22057: Actually rename the old locate database to the new one atomically, instead of just claiming the rename is atomic in a comment. Closes: #461585 #22056: -Xtime tests are off by one second (e.g. rm -f x; touch x; find x -mtime 0 should print x). Closes: #460733 * merge from 4.2.x: - Add Vcs-Svn, Vcs-Browser and Homepage control fields. - Try to preserve user changes of updatedb.conf on upgrading from findutils versions with included locate: If updatedb.conf is user modified and /etc/updatedb.findutils.cron.local does not yet exist, generate the latter from the former. Closes: #459570 * Upstream's documentation licensing has been fixed, update debian/copyright. Files: 1b658e94bf5f2f102b2f873a1c053b3c 840 utils required findutils_4.3.13-1.dsc 90ef3353f78c62eb8a3b2fb6c0127034 2054988 utils required findutils_4.3.13.orig.tar.gz 0215f4957e822637c8a4a06272d8548b 19074 utils required findutils_4.3.13-1.diff.gz 4e227b7ff40d55b30c4195a2cd6cda61 517188 utils required findutils_4.3.13-1_i386.deb fa7e446876c9ee13a336f5edd997b16a 147128 utils optional locate_4.3.13-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyU0CHTOcZYuNdmMRAlL2AJ9iTR9l2K0FTVEy8B3vNokK9t+FcACdGuX3 EtpqOSnmEVCHadDrwXu25rY= =bbH/ -END PGP SIGNATURE- Accepted: findutils_4.3.13-1.diff.gz to pool/main/f/findutils/findutils_4.3.13-1.diff.gz findutils_4.3.13-1.dsc to pool/main/f/findutils/findutils_4.3.13-1.dsc findutils_4.3.13-1_i386.deb to pool/main/f/findutils/findutils_4.3.13-1_i386.deb findutils_4.3.13.orig.tar.gz to pool/main/f/findutils/findutils_4.3.13.orig.tar.gz locate_4.3.13-1_i386.deb to pool/main/f/findutils/locate_4.3.13-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted thunar 0.9.0-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 13:29:40 +0100 Source: thunar Binary: libthunar-vfs-1-dev libthunar-vfs-1-2 thunar thunar-data Architecture: source all amd64 Version: 0.9.0-4 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers [EMAIL PROTECTED] Changed-By: Yves-Alexis Perez [EMAIL PROTECTED] Description: libthunar-vfs-1-2 - VFS abstraction used in thunar libthunar-vfs-1-dev - Development files for libthunar-vfs thunar - File Manager for Xfce thunar-data - Provides thunar documentation, icons and translations Closes: 434002 465803 Changes: thunar (0.9.0-4) unstable; urgency=low . * debian/patches: - 04_es-l10n-typo added.closes: #434002 - 05_thunar-vfs-nozombies added, prevents thunar and xfdesktop to spawn zombies. Thanks Jeremy Lal. closes: #465803 * debian/thunar.install: install .desktop files in thunar package. * debian/rules: remove .desktop files from thunar-data package. * debian/control: add proper conflicts against previous thunar-data. Files: 2a628c3d44973a18261e180238950a0c 1279 x11 optional thunar_0.9.0-4.dsc b7423a97ccff4d408a44b467943e1603 7931 x11 optional thunar_0.9.0-4.diff.gz e34a6c0a22a26d406e4e7357a90e3085 5728770 x11 optional thunar-data_0.9.0-4_all.deb 72a10a59bd17309061aebc3d5da43d43 18504 libdevel optional libthunar-vfs-1-dev_0.9.0-4_amd64.deb a8be541c9af6b231d5e9808fc88e42b8 164304 libs optional libthunar-vfs-1-2_0.9.0-4_amd64.deb 03d1ddd58a9416756d9c2f7e3531d0bb 244072 x11 optional thunar_0.9.0-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyU2lTUTAIMXAW64RApu1AJ9ltkp8R+G5Xii9/nuOUIxLwMlpCgCfe53a MFs/yFNb6UJz+Zlpyng78EA= =UXI5 -END PGP SIGNATURE- Accepted: libthunar-vfs-1-2_0.9.0-4_amd64.deb to pool/main/t/thunar/libthunar-vfs-1-2_0.9.0-4_amd64.deb libthunar-vfs-1-dev_0.9.0-4_amd64.deb to pool/main/t/thunar/libthunar-vfs-1-dev_0.9.0-4_amd64.deb thunar-data_0.9.0-4_all.deb to pool/main/t/thunar/thunar-data_0.9.0-4_all.deb thunar_0.9.0-4.diff.gz to pool/main/t/thunar/thunar_0.9.0-4.diff.gz thunar_0.9.0-4.dsc to pool/main/t/thunar/thunar_0.9.0-4.dsc thunar_0.9.0-4_amd64.deb to pool/main/t/thunar/thunar_0.9.0-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libbeagle 0.3.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 12:08:12 +0100 Source: libbeagle Binary: libbeagle1 libbeagle-dev python-beagle Architecture: source i386 Version: 0.3.0-3 Distribution: unstable Urgency: low Maintainer: Debian CLI Applications Team [EMAIL PROTECTED] Changed-By: Mirco Bauer [EMAIL PROTECTED] Description: libbeagle-dev - library for accessing beagle (C bindings) libbeagle1 - library for accessing beagle using C python-beagle - Python bindings for beagle Closes: 460657 463965 468756 Changes: libbeagle (0.3.0-3) unstable; urgency=low . [ Sebastian Dröge ] * debian/python-beagle.install: + Make the python module path python version independent to make it possible to change the default python version with a rebuild only. . [ Mirco Bauer ] * debian/control: + Lowered debhelper build-dependency to = 5, as we use python-support. + Added libglib2.0-dev and libxml2-dev dependencies to libbeagle-dev. (Closes: #468756) + Renamed Gaim references to Pidgin. (Closes: #463965) + Added XS-Python-Version and XB-Python-Version fields. + Changed section of python-beagle to python. * debian/rules debian/libbeagle-dev.docs + Ship examples/ in /usr/share/doc/libbeagle-dev/example/. (Closes: #460657) * debian/pyversions: + Removed, seems to be unused. Files: 7dc524bb8839d9b8618667c0442fb78f 1387 libs optional libbeagle_0.3.0-3.dsc 0e725b48396782cb06a022a1534c9c45 31368 libs optional libbeagle_0.3.0-3.diff.gz 8dca852892fee22036099ed34ea7c75e 47858 libs optional libbeagle1_0.3.0-3_i386.deb 451c9b26b4111767bdd60bd23cc7ad31 111058 libdevel optional libbeagle-dev_0.3.0-3_i386.deb da889506d44bd0eee4d4e9cb636099ce 33054 python optional python-beagle_0.3.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR8lMPXEn5avu+UbIAQLZoAgAovwBziszgrSRmwXwKieCQJqX/InYceJ7 c96S0FGyxP0btjV78Nrcgxa0ydcsfLgDbfbhloExyf0JBERp1sawopCUC/sVHVO8 olQOaO31RPyvxuCEqLzgBeshvbpoOhiH5jONQdIAT3mvloDzNG/yMiiJ9qhFBUPt /tvOAcVa4dw/3nUVwYBAK7oPonT1l6U5py9KAd8bm84kdPppOPpLx2PBzvXsjega WnFKbXJSj4GLSYr4a16/x95xx2o1zkd9lVrqOVgchLwT1qUXafJwDHlHc8bapNJy imZ8DTAl7a6wsTCm4ikLd2sbrJeVmm7x082pbRbWgrn+5WElbwmYDQ== =v2eG -END PGP SIGNATURE- Accepted: libbeagle-dev_0.3.0-3_i386.deb to pool/main/libb/libbeagle/libbeagle-dev_0.3.0-3_i386.deb libbeagle1_0.3.0-3_i386.deb to pool/main/libb/libbeagle/libbeagle1_0.3.0-3_i386.deb libbeagle_0.3.0-3.diff.gz to pool/main/libb/libbeagle/libbeagle_0.3.0-3.diff.gz libbeagle_0.3.0-3.dsc to pool/main/libb/libbeagle/libbeagle_0.3.0-3.dsc python-beagle_0.3.0-3_i386.deb to pool/main/libb/libbeagle/python-beagle_0.3.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pygments 0.9-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 13:37:39 +0100 Source: pygments Binary: python-pygments Architecture: source all Version: 0.9-3 Distribution: unstable Urgency: low Maintainer: Piotr Ożarowski [EMAIL PROTECTED] Changed-By: Piotr Ożarowski [EMAIL PROTECTED] Description: python-pygments - syntax highlighting package written in Python Closes: 468710 Changes: pygments (0.9-3) unstable; urgency=low . [ Sandro Tosi ] * debian/control - uniforming Vcs-Browser field . [ Piotr Ożarowski ] * Switch to python-support * Replace python-setuptools runtime dependency with new python-pkg-resources (closes: 468710) * Compress binary package with bzip2 * Strip the -1 from quilt's and setuptools' required build versions Files: 8453a5ce7c8822814f2eec9f042c69d1 1037 python optional pygments_0.9-3.dsc 790719e2f6f6f79f8ba8e9be12d41337 3430 python optional pygments_0.9-3.diff.gz b28363c42accbbc0b0ac6d203f98eb22 233800 python optional python-pygments_0.9-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVIlB01zfu119ZkRAgU9AKC3zNDeyOB8jP2iaHQ7VTF3NBk0DACgkC48 OXoHEnOGoNd6dUXl9nulTPU= =cnoO -END PGP SIGNATURE- Accepted: pygments_0.9-3.diff.gz to pool/main/p/pygments/pygments_0.9-3.diff.gz pygments_0.9-3.dsc to pool/main/p/pygments/pygments_0.9-3.dsc python-pygments_0.9-3_all.deb to pool/main/p/pygments/python-pygments_0.9-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dact 0.8.41-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 30 Jan 2008 23:25:52 -0200 Source: dact Binary: dact Architecture: source i386 Version: 0.8.41-4 Distribution: unstable Urgency: low Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Changed-By: Jose Carlos Medeiros [EMAIL PROTECTED] Description: dact - Multi-algorithm compression Changes: dact (0.8.41-4) unstable; urgency=low . * Bump Standards-Version: 3.7.3. * Updated Homepage header. * Added description in 01_makefile_no_modules.dpatch file. Files: 8f5b808d4400823bb8c47e28309a325a 705 utils optional dact_0.8.41-4.dsc b60c40674a2daa18b538bffdc66428b4 3874 utils optional dact_0.8.41-4.diff.gz e510971bbbd6e897fc81d00c3fc095d4 96730 utils optional dact_0.8.41-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVy+GKGxzw/lPdkRAu9YAJ9IwROX1nD+Dv+V5UbWZFLVCL5KCQCffMg2 cpC7QDZhOgHyinYGf2Nisc8= =lwJP -END PGP SIGNATURE- Accepted: dact_0.8.41-4.diff.gz to pool/main/d/dact/dact_0.8.41-4.diff.gz dact_0.8.41-4.dsc to pool/main/d/dact/dact_0.8.41-4.dsc dact_0.8.41-4_i386.deb to pool/main/d/dact/dact_0.8.41-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kamefu 0.1.1-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 31 Jan 2008 11:39:41 -0200 Source: kamefu Binary: kamefu kamefu-data libkamefu0 libkamefu-dev Architecture: source all i386 Version: 0.1.1-4 Distribution: unstable Urgency: low Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Changed-By: Jose Carlos Medeiros [EMAIL PROTECTED] Description: kamefu - KDE All Machine Emulator Frontend for Unix - binary files kamefu-data - Data files for Kamefu libkamefu-dev - Development headers for Kamefu libkamefu0 - Libraries for Kamefu Changes: kamefu (0.1.1-4) unstable; urgency=low . * Conforms to Standards version 3.7.3. * debian/control: Added Homepage header. * debian/control: Changed libkamefu-dev section to libdevel. Files: 2dc265053eccb0a5f1e7d7c38294f9e7 751 kde optional kamefu_0.1.1-4.dsc c2ce5f40b251cd823e05adf5c7f448f6 2812 kde optional kamefu_0.1.1-4.diff.gz a4f90afc4574111369ed658afb846ded 9230 kde optional kamefu-data_0.1.1-4_all.deb 564f6a9cfb4eedc731a2f9b885d9abbd 79788 kde optional kamefu_0.1.1-4_i386.deb 98a82c7f294de6c26e254ddffd67effa 251916 libs optional libkamefu0_0.1.1-4_i386.deb 2a8001b390203af3aaec0422bd45483e 16046 libdevel optional libkamefu-dev_0.1.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVzRGKGxzw/lPdkRAlWTAJ9kKXzwUueHRl7scWYPbo3jXYeTEgCeNqzb 2M2BR2hXP7KuS67+m5Db4XA= =WjUI -END PGP SIGNATURE- Accepted: kamefu-data_0.1.1-4_all.deb to pool/main/k/kamefu/kamefu-data_0.1.1-4_all.deb kamefu_0.1.1-4.diff.gz to pool/main/k/kamefu/kamefu_0.1.1-4.diff.gz kamefu_0.1.1-4.dsc to pool/main/k/kamefu/kamefu_0.1.1-4.dsc kamefu_0.1.1-4_i386.deb to pool/main/k/kamefu/kamefu_0.1.1-4_i386.deb libkamefu-dev_0.1.1-4_i386.deb to pool/main/k/kamefu/libkamefu-dev_0.1.1-4_i386.deb libkamefu0_0.1.1-4_i386.deb to pool/main/k/kamefu/libkamefu0_0.1.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bubblemon 2.0.9-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Jan 2008 19:18:40 -0200 Source: bubblemon Binary: bubblemon Architecture: source i386 Version: 2.0.9-1 Distribution: unstable Urgency: low Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Changed-By: Jose Carlos Medeiros [EMAIL PROTECTED] Description: bubblemon - Bubbling Load Monitoring GNOME Applet Closes: 158667 Changes: bubblemon (2.0.9-1) unstable; urgency=low . * New upstream release. (Closes: #158667) * debian/control: - Bump Standards-Version: 3.7.3. - Added Homepage header and removed old pseudo header. Files: 3b3495ba02cf8b452f4737f7879ae33e 910 gnome optional bubblemon_2.0.9-1.dsc 2b803da365def732cc43349ed8d1fc2c 249883 gnome optional bubblemon_2.0.9.orig.tar.gz fa3e6352abfefd709a4839a747d19772 28751 gnome optional bubblemon_2.0.9-1.diff.gz 525377717e1192713a8c13cdbfa0a36c 36550 gnome optional bubblemon_2.0.9-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVy5GKGxzw/lPdkRApimAJ0fRl6J9T4BhjYEZQfTncPstcr9JwCeLerr S3fjAVBVScF5ouyjV9KA/I4= =J+3D -END PGP SIGNATURE- Accepted: bubblemon_2.0.9-1.diff.gz to pool/main/b/bubblemon/bubblemon_2.0.9-1.diff.gz bubblemon_2.0.9-1.dsc to pool/main/b/bubblemon/bubblemon_2.0.9-1.dsc bubblemon_2.0.9-1_i386.deb to pool/main/b/bubblemon/bubblemon_2.0.9-1_i386.deb bubblemon_2.0.9.orig.tar.gz to pool/main/b/bubblemon/bubblemon_2.0.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gngb 20060309-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 31 Jan 2008 10:43:42 -0200 Source: gngb Binary: gngb Architecture: source i386 Version: 20060309-2 Distribution: unstable Urgency: low Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Changed-By: Jose Carlos Medeiros [EMAIL PROTECTED] Description: gngb - a Color Gameboy emulator Changes: gngb (20060309-2) unstable; urgency=low . * Conforms to Standards version 3.7.3. * debian/control: Added cdbs, autotools-dev, quilt build-dependences. * debian/rules: Converted to cdbs way. * debian/dirs: Removed usr/sbin. * debian/control: Added Homepage header. * debian/watch: Updated to version 3. Files: bf1ac1a3f43b240a9917afeba9eb9228 724 x11 optional gngb_20060309-2.dsc f84fefc15c1c540546740b1718d617ca 2846 x11 optional gngb_20060309-2.diff.gz 99a6d06e4fb75184eb7d65d87ba4ebb5 101474 x11 optional gngb_20060309-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVzLGKGxzw/lPdkRAqO9AKCDi229B3RnpzBGYj8z3W44Ptj9EwCggFcW qCdFQmrbeUYFalPKMaJOYVo= =E6nR -END PGP SIGNATURE- Accepted: gngb_20060309-2.diff.gz to pool/main/g/gngb/gngb_20060309-2.diff.gz gngb_20060309-2.dsc to pool/main/g/gngb/gngb_20060309-2.dsc gngb_20060309-2_i386.deb to pool/main/g/gngb/gngb_20060309-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted filerunner 2.5.1-19 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 30 Jan 2008 23:36:41 -0200 Source: filerunner Binary: filerunner Architecture: source i386 Version: 2.5.1-19 Distribution: unstable Urgency: low Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Changed-By: Jose Carlos Medeiros [EMAIL PROTECTED] Description: filerunner - X-Based FTP program file manager Changes: filerunner (2.5.1-19) unstable; urgency=low . * Bump Standards-Version: 3.7.3. * Added Homepage header. * Changed section of menu file. Files: d4bfc525f835976f7a0183f35a2ba595 708 net optional filerunner_2.5.1-19.dsc f45a2b15882e1f2023358aa9ace350a1 12061 net optional filerunner_2.5.1-19.diff.gz aaa1507f5cd1782938ff6ca7d43afba1 139614 net optional filerunner_2.5.1-19_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVzDGKGxzw/lPdkRAl0XAKCtSb3fmMgAQf+Hq6TtasvX5kj4AgCfTcvu PhNxlzQbD0EW5CsIGYRwq08= =Cfcr -END PGP SIGNATURE- Accepted: filerunner_2.5.1-19.diff.gz to pool/main/f/filerunner/filerunner_2.5.1-19.diff.gz filerunner_2.5.1-19.dsc to pool/main/f/filerunner/filerunner_2.5.1-19.dsc filerunner_2.5.1-19_i386.deb to pool/main/f/filerunner/filerunner_2.5.1-19_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sane-backends 1.0.19-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 14:11:29 +0100 Source: sane-backends Binary: sane-utils libsane libsane-dev libsane-dbg Architecture: source amd64 Version: 1.0.19-2 Distribution: unstable Urgency: low Maintainer: Julien BLACHE [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: libsane- API library for scanners libsane-dbg - API development library for scanners [debug symbols] libsane-dev - API development library for scanners [development files] sane-utils - API library for scanners -- utilities Closes: 426514 466540 468270 Changes: sane-backends (1.0.19-2) unstable; urgency=low . * debian/patches/02_pixma_update.dpatch: + Added; update pixma backend from CVS, adding support for - Pixma MP210, MP470, MP520, MP610, MultiPASS MP710 - MP140, MP220, MultiPASS MP740 (untested) - MP970 (experimental, untested) (closes: #468270). * debian/rules: + Generate and install HAL fdi file (closes: #466540). * debian/control: + Add update-inetd dependency for sane-utils. * debian/sane-utils.postinst, debian/sane-utils.postrm: + Add support for update-inetd (closes: #426514). * debian/sane-utils.README.Debian: + Document update-inetd usage. Files: 964c7ae574c73b940e52a1b042fc760f 948 graphics optional sane-backends_1.0.19-2.dsc 0295d76ad211d3af21b98f802d0ad59e 39431 graphics optional sane-backends_1.0.19-2.diff.gz 27d2ade28d75a296ecf3c8c27bf4458a 133292 graphics optional sane-utils_1.0.19-2_amd64.deb 550001d6491d74857d459396d42e8457 3611718 libs optional libsane_1.0.19-2_amd64.deb 9f098f88e6119ba70ff6fcb3cd0cb21b 3104210 libdevel optional libsane-dev_1.0.19-2_amd64.deb 66d40e4041f02c5a324a78aad49382e2 3562404 libdevel extra libsane-dbg_1.0.19-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVuGzWFP1/XWUWkRAlgsAKCgO79Fa3KgR0wDvh64T+IGvHP3wACeOOJ5 QxvNz9PGbSE7r16Ws4ixno0= =Lhcq -END PGP SIGNATURE- Accepted: libsane-dbg_1.0.19-2_amd64.deb to pool/main/s/sane-backends/libsane-dbg_1.0.19-2_amd64.deb libsane-dev_1.0.19-2_amd64.deb to pool/main/s/sane-backends/libsane-dev_1.0.19-2_amd64.deb libsane_1.0.19-2_amd64.deb to pool/main/s/sane-backends/libsane_1.0.19-2_amd64.deb sane-backends_1.0.19-2.diff.gz to pool/main/s/sane-backends/sane-backends_1.0.19-2.diff.gz sane-backends_1.0.19-2.dsc to pool/main/s/sane-backends/sane-backends_1.0.19-2.dsc sane-utils_1.0.19-2_amd64.deb to pool/main/s/sane-backends/sane-utils_1.0.19-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liborigin 20080225-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:04:11 +0100 Source: liborigin Binary: liborigin-dev liborigin0 opj2dat Architecture: source amd64 Version: 20080225-1 Distribution: unstable Urgency: low Maintainer: Fathi Boudra [EMAIL PROTECTED] Changed-By: Fathi Boudra [EMAIL PROTECTED] Description: liborigin-dev - library for reading OriginLab Origin project files (development) liborigin0 - library for reading OriginLab Origin project files (runtime) opj2dat- OriginLab Origin project files to data files converter Changes: liborigin (20080225-1) unstable; urgency=low . * New upstream release. * Remove gcc-4.3 patch. Merged upstream. * Add Vcs-Browser and Vcs-Svn fields. Files: 546d42ac6f029257e37227168d1d22e7 972 libs optional liborigin_20080225-1.dsc 182c736d389a3a16072c609d78997289 48848 libs optional liborigin_20080225.orig.tar.gz 3395be46c05d7c2f6fbe5cbcadec7995 3355 libs optional liborigin_20080225-1.diff.gz 2d16076c12051f6d2c3be58803af56c0 23734 libdevel optional liborigin-dev_20080225-1_amd64.deb 7ef69242af7ffd90d09402675c315a1d 76050 libs optional liborigin0_20080225-1_amd64.deb d4c21e3649719a22dd886e90a586cef8 10192 science optional opj2dat_20080225-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQCVAwUBR8llpoz1NfZqpXL3AQKE3wP/eAk79HGo0uN98anRkEBE0qWGwsD3SJyB ompCWEHoBbs6pRHrlPZsvTv+GXGeuh7Rvez8Vohb+GUkfNPzq/zgx0VRaJKrH8cE XSeoIrWlX7OhhJ2546sfSag1GLS88n0t7vQ9uFN0LgfAsiWyJJV7dQyuLlDcipHh nY4yJJjxIjA= =Liro -END PGP SIGNATURE- Accepted: liborigin-dev_20080225-1_amd64.deb to pool/main/libo/liborigin/liborigin-dev_20080225-1_amd64.deb liborigin0_20080225-1_amd64.deb to pool/main/libo/liborigin/liborigin0_20080225-1_amd64.deb liborigin_20080225-1.diff.gz to pool/main/libo/liborigin/liborigin_20080225-1.diff.gz liborigin_20080225-1.dsc to pool/main/libo/liborigin/liborigin_20080225-1.dsc liborigin_20080225.orig.tar.gz to pool/main/libo/liborigin/liborigin_20080225.orig.tar.gz opj2dat_20080225-1_amd64.deb to pool/main/libo/liborigin/opj2dat_20080225-1_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdebian-package-make-perl 0.03 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:26:27 +0100 Source: libdebian-package-make-perl Binary: libdebian-package-make-perl Architecture: source all Version: 0.03 Distribution: unstable Urgency: low Maintainer: Hilko Bengen [EMAIL PROTECTED] Changed-By: Hilko Bengen [EMAIL PROTECTED] Description: libdebian-package-make-perl - Perl modules for automatically generating Debian packages Changes: libdebian-package-make-perl (0.03) unstable; urgency=low . * Implemented separate handling of epoch, upstream_version, debian_revision * Fixed some of perlcritic's warnings (eval STRING, strictures, etc.) * Fixed error checking for parsing .chagnes file * Fixed warnings * Removed some dead code * Added first real tests. * Added antivir packaging script that uses on the antivir program's built-in update feature Files: dffa7840f4b7666304723c6b1c4ee608 704 perl optional libdebian-package-make-perl_0.03.dsc a99b30e7913b2dfdfc4b97a91af4bbeb 31661 perl optional libdebian-package-make-perl_0.03.tar.gz eb6335c5169d85e0362f0b983a00ffe0 37962 perl optional libdebian-package-make-perl_0.03_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyWnVUCgnLz/SlGgRAniHAKCqlhMgjqgQ6OspvFpy50KhyAHUaACeN6KR RRHqLUN/whm534D+WWROXi0= =dPdF -END PGP SIGNATURE- Accepted: libdebian-package-make-perl_0.03.dsc to pool/main/libd/libdebian-package-make-perl/libdebian-package-make-perl_0.03.dsc libdebian-package-make-perl_0.03.tar.gz to pool/main/libd/libdebian-package-make-perl/libdebian-package-make-perl_0.03.tar.gz libdebian-package-make-perl_0.03_all.deb to pool/main/libd/libdebian-package-make-perl/libdebian-package-make-perl_0.03_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mono-addins 0.3.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:35:24 +0100 Source: mono-addins Binary: libmono-addins0.2-cil libmono-addins-gui0.2-cil Architecture: source all Version: 0.3.1-1 Distribution: unstable Urgency: low Maintainer: Debian CLI Libraries Team [EMAIL PROTECTED] Changed-By: Mirco Bauer [EMAIL PROTECTED] Description: libmono-addins-gui0.2-cil - GTK# frontend library for Mono.Addins libmono-addins0.2-cil - addin framework for extensible CLI applications/libraries Closes: 464298 Changes: mono-addins (0.3.1-1) unstable; urgency=low . * New upstream release * debian/patches/fix_configure.ac.dpatch: + Removed leading ./ from paths, config.status is confused by that, fixing FTBFS. (Closes: #464298) * debian/patches/99_autoreconf.dpatch: + autoreconf needed for configure.ac change. * debian/watch: + Updated Files: 498e18c0c26df9d00851a82bb950d20a 1400 libs optional mono-addins_0.3.1-1.dsc 919132d43d3f3bedcc1044a0286010d1 234474 libs optional mono-addins_0.3.1.orig.tar.gz 469d3c1ea203a069156122764cdf28fa 9327 libs optional mono-addins_0.3.1-1.diff.gz 85971c2d9b2ebeec93cf2246dead245a 113532 libs optional libmono-addins0.2-cil_0.3.1-1_all.deb 944ff010fd1212174a880932710737da 43856 libs optional libmono-addins-gui0.2-cil_0.3.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR8lqTnEn5avu+UbIAQL2iAgAolRg8zXqGo8TVqZNzDMmNmjvDf3Iz3BK RpnFj8sgzH5S8X532kubb9WnqeOEfAfhcrrWe9x0ILndZ9zoaSXrWMHBEeWH3Ehg dzda+gTbCvXpJCItcyTfzSfXZKnDUa2wY0XoMCxvTXVog1HRUM0yc0lGI2F6Dita H+jv3KNx9nH43xCuZOmI8alqaBWUcY0+XJxPmi6fIg9bx0BoCB9w/gGPpF2i54yg MdHTgP7naT75vSjL4XYRq1XlgKpr0Q1jkrzqvZj2wjP0hxzX+K3k/Jtgb63ZMu39 PueW7C53HWkIxxSXuGMU2fRb6e1DBGUatD6lHkLUvmMfRjIKGEHCmA== =irXl -END PGP SIGNATURE- Accepted: libmono-addins-gui0.2-cil_0.3.1-1_all.deb to pool/main/m/mono-addins/libmono-addins-gui0.2-cil_0.3.1-1_all.deb libmono-addins0.2-cil_0.3.1-1_all.deb to pool/main/m/mono-addins/libmono-addins0.2-cil_0.3.1-1_all.deb mono-addins_0.3.1-1.diff.gz to pool/main/m/mono-addins/mono-addins_0.3.1-1.diff.gz mono-addins_0.3.1-1.dsc to pool/main/m/mono-addins/mono-addins_0.3.1-1.dsc mono-addins_0.3.1.orig.tar.gz to pool/main/m/mono-addins/mono-addins_0.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted git-buildpackage 0.4.19 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 14:22:20 +0100 Source: git-buildpackage Binary: git-buildpackage Architecture: source all Version: 0.4.19 Distribution: unstable Urgency: low Maintainer: Guido Guenther [EMAIL PROTECTED] Changed-By: Guido Guenther [EMAIL PROTECTED] Description: git-buildpackage - Suite to help with Debian packages in Git repositories Closes: 468675 Changes: git-buildpackage (0.4.19) unstable; urgency=low . * don't fail of the pristine-tar branch doesn't exist (Closes: #468675) Files: 42b5ac718819ab3b05f43132735461b1 714 devel optional git-buildpackage_0.4.19.dsc 65c3a1907f3d18a2260eec35f625f3a8 35453 devel optional git-buildpackage_0.4.19.tar.gz 545f83b3d5eb1b26302a5d02743c53dc 47054 devel optional git-buildpackage_0.4.19_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyVsWn88szT8+ZCYRAoiuAJ9B+XV7aqrfZa4zjYs5IwcNTES7dACeJFBJ JbA9i6mJQqhXh93Lk+24bWU= =Z63V -END PGP SIGNATURE- Accepted: git-buildpackage_0.4.19.dsc to pool/main/g/git-buildpackage/git-buildpackage_0.4.19.dsc git-buildpackage_0.4.19.tar.gz to pool/main/g/git-buildpackage/git-buildpackage_0.4.19.tar.gz git-buildpackage_0.4.19_all.deb to pool/main/g/git-buildpackage/git-buildpackage_0.4.19_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sane-frontends 1.0.14-6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:35:24 +0100 Source: sane-frontends Binary: sane Architecture: source amd64 Version: 1.0.14-6 Distribution: unstable Urgency: low Maintainer: Julien BLACHE [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: sane - scanner graphical frontends Closes: 466593 Changes: sane-frontends (1.0.14-6) unstable; urgency=low . * debian/patches/02_xcam_man_typo.dpatch: + Updated; more typo fixes (closes: #466593). * debian/control: + Bump Standards-Version to 3.7.3 (no changes). Files: 8bb9b75b470ed849e5d3bfea58dc2ed7 671 graphics optional sane-frontends_1.0.14-6.dsc 8bb5ce802bddb4b82965fe416d3c9929 9874 graphics optional sane-frontends_1.0.14-6.diff.gz b9575123e16e5ec986bfe9c3ba891c2e 117268 graphics optional sane_1.0.14-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyWowzWFP1/XWUWkRAhDVAKCYjbnEqIMCIdmRukoPe0Cj6kW4zgCeNL2k 2Ukk1L086QcGY5QX5tmhfKM= =V/2Y -END PGP SIGNATURE- Accepted: sane-frontends_1.0.14-6.diff.gz to pool/main/s/sane-frontends/sane-frontends_1.0.14-6.diff.gz sane-frontends_1.0.14-6.dsc to pool/main/s/sane-frontends/sane-frontends_1.0.14-6.dsc sane_1.0.14-6_amd64.deb to pool/main/s/sane-frontends/sane_1.0.14-6_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdate-convert-perl 0.16-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 14:38:36 + Source: libdate-convert-perl Binary: libdate-convert-perl Architecture: source all Version: 0.16-2 Distribution: unstable Urgency: low Maintainer: Stephen Gran [EMAIL PROTECTED] Changed-By: Stephen Gran [EMAIL PROTECTED] Description: libdate-convert-perl - Convert Between any two Calendrical Formats Closes: 467742 Changes: libdate-convert-perl (0.16-2) unstable; urgency=low . * Only attempt to rmdir if it's there (closes: #467742) * Update Standards Version to 3.7.3 (no changes) Files: 155b79c2bdf92afdd73796e5518ac88c 646 perl optional libdate-convert-perl_0.16-2.dsc ab1703ced419d2970421f83cdffa127f 1845 perl optional libdate-convert-perl_0.16-2.diff.gz 9e2a97af72a376be07daf39093e37726 19490 perl optional libdate-convert-perl_0.16-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyWqfSYIMHOpZA44RAuFxAKCzfXnqmwgcLBDvt532jmbqHZ5v7ACgtuRG C9uIdpEUU1Xe01F8tRVWjVk= =FbtA -END PGP SIGNATURE- Accepted: libdate-convert-perl_0.16-2.diff.gz to pool/main/libd/libdate-convert-perl/libdate-convert-perl_0.16-2.diff.gz libdate-convert-perl_0.16-2.dsc to pool/main/libd/libdate-convert-perl/libdate-convert-perl_0.16-2.dsc libdate-convert-perl_0.16-2_all.deb to pool/main/libd/libdate-convert-perl/libdate-convert-perl_0.16-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lua-gtk 0.8+20080301-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 14:01:42 +0100 Source: lua-gtk Binary: liblua5.1-gtk-0 liblua5.1-gtk-dev Architecture: source amd64 Version: 0.8+20080301-1 Distribution: experimental Urgency: low Maintainer: Enrico Tassi [EMAIL PROTECTED] Changed-By: Enrico Tassi [EMAIL PROTECTED] Description: liblua5.1-gtk-0 - gtk bindings for the lua language version 5.1 liblua5.1-gtk-dev - gtk development files for the lua language version 5.1 Changes: lua-gtk (0.8+20080301-1) experimental; urgency=low . * another snapshot that should fix sparc Files: b7b6eeab447ee6e1f259eee4a8145872 1027 interpreters optional lua-gtk_0.8+20080301-1.dsc cb5e4121538e8d0758416d6f0ab15244 285373 interpreters optional lua-gtk_0.8+20080301.orig.tar.gz d6a92ac6834feb3f79135bf52e038975 12433 interpreters optional lua-gtk_0.8+20080301-1.diff.gz b3469c790b9dad513eede7cec5e8a51b 182080 interpreters optional liblua5.1-gtk-0_0.8+20080301-1_amd64.deb 28e1afb9c9080a7f552134ad1022ec9d 211098 libdevel optional liblua5.1-gtk-dev_0.8+20080301-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyWww7kkcPgEj8vIRAni1AJ4n7eSVkv+9+w1itlcpGTaKezUK1ACguxjD 2dOxZ9rqVmISidWvk8wrPE4= =2evC -END PGP SIGNATURE- Accepted: liblua5.1-gtk-0_0.8+20080301-1_amd64.deb to pool/main/l/lua-gtk/liblua5.1-gtk-0_0.8+20080301-1_amd64.deb liblua5.1-gtk-dev_0.8+20080301-1_amd64.deb to pool/main/l/lua-gtk/liblua5.1-gtk-dev_0.8+20080301-1_amd64.deb lua-gtk_0.8+20080301-1.diff.gz to pool/main/l/lua-gtk/lua-gtk_0.8+20080301-1.diff.gz lua-gtk_0.8+20080301-1.dsc to pool/main/l/lua-gtk/lua-gtk_0.8+20080301-1.dsc lua-gtk_0.8+20080301.orig.tar.gz to pool/main/l/lua-gtk/lua-gtk_0.8+20080301.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sane-backends-extras 1.0.19.4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:57:24 +0100 Source: sane-backends-extras Binary: libsane-extras libsane-extras-dev libsane-extras-dbg Architecture: source amd64 Version: 1.0.19.4 Distribution: unstable Urgency: low Maintainer: Julien BLACHE [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: libsane-extras - API library for scanners -- extra backends libsane-extras-dbg - API library for scanners -- extra backends [debug symbols] libsane-extras-dev - API development library for scanners [development files] Changes: sane-backends-extras (1.0.19.4) unstable; urgency=low . * debian/libsane-extras.udev: + Update epkowa devices. * debian/libsane-extras.fdi: + Add HAL fdi file for libsane-extras. * debian/rules: + Install the HAL fdi file. + Do not create lib directory for epkowa proprietary libs on kfreebsd. + Do not call dh_installudev on kfreebsd. Files: d5796d6545a10e785fa330b6c1c430bc 651 graphics optional sane-backends-extras_1.0.19.4.dsc 34df21f35165272a7565ec0718ca72e7 717053 graphics optional sane-backends-extras_1.0.19.4.tar.gz 1f7c52f2772423d4ba751a9453b779c6 192008 libs optional libsane-extras_1.0.19.4_amd64.deb 8d7f9eaf279202abeb0752121e4c4123 177542 libdevel optional libsane-extras-dev_1.0.19.4_amd64.deb df34a29d071ae9248f2cbe864102f7ea 214730 libdevel extra libsane-extras-dbg_1.0.19.4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyW9hzWFP1/XWUWkRAmssAJ478Ld0svs1yb0cAFUvSfuXbPRb0QCgsu1s KICr7En8ft0Ra7Z7VEXckjI= =DsaV -END PGP SIGNATURE- Accepted: libsane-extras-dbg_1.0.19.4_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras-dbg_1.0.19.4_amd64.deb libsane-extras-dev_1.0.19.4_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras-dev_1.0.19.4_amd64.deb libsane-extras_1.0.19.4_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras_1.0.19.4_amd64.deb sane-backends-extras_1.0.19.4.dsc to pool/main/s/sane-backends-extras/sane-backends-extras_1.0.19.4.dsc sane-backends-extras_1.0.19.4.tar.gz to pool/main/s/sane-backends-extras/sane-backends-extras_1.0.19.4.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted taskjuggler 2.4.1~beta2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:45:37 +0100 Source: taskjuggler Binary: taskjuggler Architecture: source amd64 Version: 2.4.1~beta2-1 Distribution: unstable Urgency: low Maintainer: Fathi Boudra [EMAIL PROTECTED] Changed-By: Fathi Boudra [EMAIL PROTECTED] Description: taskjuggler - Project management application Changes: taskjuggler (2.4.1~beta2-1) unstable; urgency=low . * New upstream release. * Unbump compat/debhelper to 5. * Replace automake1.9 build dependency by automake. * Refrash patches. Files: c1c67e5cf69402a35a711b88e324cd2e 1143 kde optional taskjuggler_2.4.1~beta2-1.dsc 10eede56db8b3210fb99f99a8f3d3025 1578804 kde optional taskjuggler_2.4.1~beta2.orig.tar.gz d7dfec4e78e8ee7da496e07d3b8f53ee 248949 kde optional taskjuggler_2.4.1~beta2-1.diff.gz e51e1674635c504d2b5a724caf7c66c5 1361766 kde optional taskjuggler_2.4.1~beta2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQCVAwUBR8lw1oz1NfZqpXL3AQKkfQP+LAUpLwbu48vX5aM3VuiGAgAkplb7W/iW 8VKVJbDr0ssPyturuKOI3MqhcvK7mOrkp1+ejsFoGh0nQLpeHQx2Jh1MS7/9VyG6 OiUyRrIj975ru8sjTZrxkmJvP9W1HxgOuz3KhzTAj/8/rGg3hXw71Todlwy3nz6E 8rkoTyjJb08= =w+VS -END PGP SIGNATURE- Accepted: taskjuggler_2.4.1~beta2-1.diff.gz to pool/main/t/taskjuggler/taskjuggler_2.4.1~beta2-1.diff.gz taskjuggler_2.4.1~beta2-1.dsc to pool/main/t/taskjuggler/taskjuggler_2.4.1~beta2-1.dsc taskjuggler_2.4.1~beta2-1_amd64.deb to pool/main/t/taskjuggler/taskjuggler_2.4.1~beta2-1_amd64.deb taskjuggler_2.4.1~beta2.orig.tar.gz to pool/main/t/taskjuggler/taskjuggler_2.4.1~beta2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-m68hc1x 1:3.3.6+3.1+dfsg-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Feb 2008 10:33:22 + Source: gcc-m68hc1x Binary: gcc-m68hc1x Architecture: source amd64 Version: 1:3.3.6+3.1+dfsg-3 Distribution: unstable Urgency: low Maintainer: Arthur Loiret [EMAIL PROTECTED] Changed-By: Arthur Loiret [EMAIL PROTECTED] Description: gcc-m68hc1x - GNU C compiler for the Motorola 68HC11/12 processors Closes: 412608 Changes: gcc-m68hc1x (1:3.3.6+3.1+dfsg-3) unstable; urgency=low . * Adopting package. Closes: #412608 * Some packaging update. * XS-DM-Upload-Allowed: yes. Files: 388035e8541a561d264eaf9f6f3aaa34 757 devel extra gcc-m68hc1x_3.3.6+3.1+dfsg-3.dsc 8e58d7118ab1b7de10d1c92a491f3030 137352 devel extra gcc-m68hc1x_3.3.6+3.1+dfsg-3.diff.gz 8bca576daade6917b05578c4340ee85a 4522338 devel extra gcc-m68hc1x_3.3.6+3.1+dfsg-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyW9mw3ao2vG823MRAjBrAKCCAERfUEIMQunjVN2gZv+d1xOL4wCcDtLv QdXE2aKD5Q8SBDTb1rw5VjI= =E1Px -END PGP SIGNATURE- Accepted: gcc-m68hc1x_3.3.6+3.1+dfsg-3.diff.gz to pool/main/g/gcc-m68hc1x/gcc-m68hc1x_3.3.6+3.1+dfsg-3.diff.gz gcc-m68hc1x_3.3.6+3.1+dfsg-3.dsc to pool/main/g/gcc-m68hc1x/gcc-m68hc1x_3.3.6+3.1+dfsg-3.dsc gcc-m68hc1x_3.3.6+3.1+dfsg-3_amd64.deb to pool/main/g/gcc-m68hc1x/gcc-m68hc1x_3.3.6+3.1+dfsg-3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted realtimebattle 1.0.8-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Feb 2008 14:22:07 +0100 Source: realtimebattle Binary: realtimebattle realtimebattle-common Architecture: source all amd64 Version: 1.0.8-4 Distribution: unstable Urgency: low Maintainer: Rémi Vanicat [EMAIL PROTECTED] Changed-By: Rémi Vanicat [EMAIL PROTECTED] Description: realtimebattle - Programming game realtimebattle-common - Programming game Closes: 447700 455614 Changes: realtimebattle (1.0.8-4) unstable; urgency=low . * Going to Standards-Version: 3.7.3 * removing Uploader line * Adding severall #include for gcc-4.3 (Closes: #455614). * Removing warning about string constant * Use M_PI in place of M_PIL (closes: #447700) * Severall cleanup for lintian Files: bed59b980d5f7ffbafd20ce16c7b0d9e 850 games optional realtimebattle_1.0.8-4.dsc 7111dc20323285a9e89e6454942fde7b 25737 games optional realtimebattle_1.0.8-4.diff.gz 609ac4b5414e88664f87230e9bad3977 429736 games optional realtimebattle-common_1.0.8-4_all.deb ede8837c191f8bdc392babc59dfa3cbb 474312 games optional realtimebattle_1.0.8-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyW1RsOGY15BXtdMRArE2AJ43MtTtev3FFybnVV7F/RNyKli+mwCgg0so hak/FxymZGhO5SoyD2Hz3Lc= =HdKo -END PGP SIGNATURE- Accepted: realtimebattle-common_1.0.8-4_all.deb to pool/main/r/realtimebattle/realtimebattle-common_1.0.8-4_all.deb realtimebattle_1.0.8-4.diff.gz to pool/main/r/realtimebattle/realtimebattle_1.0.8-4.diff.gz realtimebattle_1.0.8-4.dsc to pool/main/r/realtimebattle/realtimebattle_1.0.8-4.dsc realtimebattle_1.0.8-4_amd64.deb to pool/main/r/realtimebattle/realtimebattle_1.0.8-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pychess 0.8-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 21:07:27 +0530 Source: pychess Binary: pychess Architecture: source all Version: 0.8-1 Distribution: unstable Urgency: low Maintainer: Varun Hiremath [EMAIL PROTECTED] Changed-By: Varun Hiremath [EMAIL PROTECTED] Description: pychess- chess graphical user interface for several chess engines Changes: pychess (0.8-1) unstable; urgency=low . * New upstream release * debian/patches: - remove amd64_hash.diff, merged upstream - remove pychess.desktop.diff, merged upstream Files: 1ec1c550ceec437637bf0f97af24a3b1 858 games optional pychess_0.8-1.dsc 1eb2f85388b7372f940f0ab60ffa7ab5 1106769 games optional pychess_0.8.orig.tar.gz 8296f8ba870bc31e04ef1d4bafac1eef 3232 games optional pychess_0.8-1.diff.gz 5af522588e37d1544e38f90f5720a4f2 989046 games optional pychess_0.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyXoFPEFSUMxFMZcRAnW2AKCt31wofJlL0OLBBa4vPz5QCuwI+ACdExdT Dirs13ESsoOuSSMaIaD5UPQ= =dsAR -END PGP SIGNATURE- Accepted: pychess_0.8-1.diff.gz to pool/main/p/pychess/pychess_0.8-1.diff.gz pychess_0.8-1.dsc to pool/main/p/pychess/pychess_0.8-1.dsc pychess_0.8-1_all.deb to pool/main/p/pychess/pychess_0.8-1_all.deb pychess_0.8.orig.tar.gz to pool/main/p/pychess/pychess_0.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted boinc 5.10.44-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 01 Mar 2008 15:07:05 +0100 Source: boinc Binary: boinc-client boinc-manager boinc-dev boinc-dbg Architecture: source i386 Version: 5.10.44-1 Distribution: unstable Urgency: low Maintainer: Debian BOINC Maintainers [EMAIL PROTECTED] Changed-By: Frank S. Thomas [EMAIL PROTECTED] Description: boinc-client - core client for the BOINC distributed computing infrastructure boinc-dbg - debugging symbols for BOINC binaries boinc-dev - development files to build applications for BOINC projects boinc-manager - GUI to control and monitor the BOINC core client Closes: 468187 Changes: boinc (5.10.44-1) unstable; urgency=low . [ Frank S. Thomas ] * New upstream release. - BOINC Manager: Clear all cached messages and resume auto-scrolling when connected host has changed (cp. r14813, r14817). (closes: #468187) Files: 504b852c3f1f41dee2abb213b7bbcbfd 1249 net optional boinc_5.10.44-1.dsc 8859bd8ee1bc8570f03431fc2aff5caa 9681757 net optional boinc_5.10.44.orig.tar.gz 8b92dade228abbfcb582f9a2f5e160bf 56030 net optional boinc_5.10.44-1.diff.gz 4f6deed5da935346d94d6dbba12f1118 346992 net optional boinc-client_5.10.44-1_i386.deb 4b82f9ed76ebb5332827a5d51171db28 1770006 x11 optional boinc-manager_5.10.44-1_i386.deb f58a1ee4bc4d087f2d49a147640c456c 391148 devel optional boinc-dev_5.10.44-1_i386.deb d0dfdadb208df1fa110492f9df0e4eb4 7064654 devel extra boinc-dbg_5.10.44-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyWrOft6HNdxCZCkRAlcVAJ48lBJecTHP1YydsOvoYiDhWIaTHwCff9Vg C21s002zgeK68Vw6vnmmRNI= =+EaQ -END PGP SIGNATURE- Accepted: boinc-client_5.10.44-1_i386.deb to pool/main/b/boinc/boinc-client_5.10.44-1_i386.deb boinc-dbg_5.10.44-1_i386.deb to pool/main/b/boinc/boinc-dbg_5.10.44-1_i386.deb boinc-dev_5.10.44-1_i386.deb to pool/main/b/boinc/boinc-dev_5.10.44-1_i386.deb boinc-manager_5.10.44-1_i386.deb to pool/main/b/boinc/boinc-manager_5.10.44-1_i386.deb boinc_5.10.44-1.diff.gz to pool/main/b/boinc/boinc_5.10.44-1.diff.gz boinc_5.10.44-1.dsc to pool/main/b/boinc/boinc_5.10.44-1.dsc boinc_5.10.44.orig.tar.gz to pool/main/b/boinc/boinc_5.10.44.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
