Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - need for sufficient ACKs
Hi Lucas, As you know I agree with you on most aspects. On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote: I find third-party reviews and ACKs a good way to reinforce the feeling that the orphaning is the right thing to do. Absolutely. Note that it's often users who detect unmaintained software. With the ACK-based process, it's possible for a user to initiate the process. Yes, the users help is welcome. For simple obvious cases, waiting for a month is a bit annoying when someone is willing and ready to take over maintenance. it's important to use contributors motivation while it's high. I agree to not demand a delay for the reason you gave. But anyway, I would not oppose adding something such as: If you followed all the steps above, waited for a month, did not receive enough ACKs, but nobody NACKed, you can still proceed. I join Steve L. with wanting a consensus, so the package can be orphaned only when there are sufficient ACKs. I expect the cc to debian-qa to draw sufficient attention from DDs, so I don't expect any problem with this. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026060942.gf10...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - without objection versus requiring ACKs
On Thu, Oct 25, 2012 at 09:06:34AM -0400, Scott Kitterman wrote: Why not start with a without objection standard and see how it works? The without objection approach would require a reasonable delay for people to raise objections (some say two months). The ACK/NACK approach allows to reach a consensus in a shorter time, so that for obvious cases the salvaging can proceed without pointless delay. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026061813.gg10...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
On Thu, Oct 25, 2012 at 02:50:46PM +0100, Ian Jackson wrote: I'm also not that keen on the idea that the outcome is to orphan the package. Orphaning the package it not the final outcome. The goal is to get packages salvaged. See the two activities explained here: http://lists.debian.org/debian-devel/2012/10/msg00261.html The salvager should surely be adding themselves as an Uploader. If the package is not orphaned, then the maintainer and salvager can agree on that. If the package is orphaned, the salvager can adopt the package (ITA). 3. Wait for objections For how long ? The proposal includes collecting ACKs so that any pointless delay can be skipped, resulting in the package being salvaged sooner. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026062506.gh10...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - getting orphaned packages marked as such
On Thu, Oct 25, 2012 at 04:20:43PM +0200, Thibaut Paumard wrote: If someone notices that a package is in need of greater attention, but cannot commit to attending it themselves, it's important that the packages is marked at least as needing help. I understand the entire point here is to mark packages which are effectively abandoned as orphaned, so that others can see them in the wnpp news for instance. It's certainly better if a new foster maintainer can be found for the package right away, but it should IMHO not be mandatory. Prospective maintainers, those that want to help Debian but don't know were to start, will be able to adopt an orphaned package, but not to salvage one in most cases. Take it as a three body encounter: - a package with no effective maintainer; - a developer who notices the problem; - a prospective maintainer. I fully agree with all the above with s/developer/person/. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026063112.gi10...@master.debian.org
[SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
Hi, I'm wondering, before a package will be orphaned is it possible/ needful the owner to ask for help or to express the reasons? Regards gnugr
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - only for obvious cases
On Thu, Oct 25, 2012 at 03:52:36PM +0100, Ian Jackson wrote: Whether a package is in need of greater attention is not a hard and fast objective thing. It's to a large part subjective. Perhaps the maintainer thinks it's more or less fine, or at least low enough priority that the problems are tolerable. I agree that not every case will be obvious. When a package has clearly not been maintained for several years, then it is easy to find three ACKs, so that the package can be marked as orphaned. When the maintainer thinks that the package is more or less fine and doesn't want to put the package up for adoption, then the ITO procedure should not forcibly orphan the package. The proposal written by Lucas is, in my opinion, sufficiently clear to address only the obvious cases. It's one thing to say this package is in need of attention which I am prepared to commit to providing. It's quite another to say this package is in need of attention but I'm not going to do anything other than say it's a problem. It is, in my opinion, also useful to identify problems even without solving the problems. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026063849.gj10...@master.debian.org
Bug#691479: ITP: pcalendar -- application to track women menstrual cycles
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: pcalendar Version: 3.3.0 Upstream Author: Mar'yan Rachynskyy mr...@users.sourceforge.net URL: http://linuxorg.sourceforge.net/ License: GPL-3+ Description: application to track women menstrual cycles Periodic Calendar is a GUI application which assists in women menstrual cycles tracking and fertility periods prediction. This information can be used as. supportive either for conception or contraception planning. . Periodic Calendar provides support for sympto-thermal method which has the highest reliability in fertility periods prediction. User can choose any subset of the. features to be used or even fall to the generic calendar method (which if used. alone is very unreliable)... . Periodic Calendar is not an equal substitute to the fertility planning consultants or doctors. Before using this application please talk to your doctor or read a good book on the subject. . THIS PROGRAM PREDICTIONS IN NO WAY CAN BE USED AS THE FINAL. THERE ARE NO PREDICTION METHODS WHICH PROVIDE 100% RELIABILITY. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210261735.21339.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: Gergely Nagy alger...@balabit.hu wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Whether a package is in need of greater attention is not a hard and fast objective thing. It's to a large part subjective. Perhaps the maintainer thinks it's more or less fine, or at least low enough priority that the problems are tolerable. Then the maintainer has many options, including but not limited to NACK-ing the ITO. One has a lot of possibilities even before it comes to filing an ITO. AIUI, with the current proposal, as long as three DDs think it should be orphaned, the maintainer's objection is irrelevant. I would send a NACK because the maintainer objects, and I trust other DDs subscribed to debian-qa to do the same. The ITO procedure is not meant to replace the TC handling conflicts. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026064655.gk10...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - liberal NMUs
On Thu, Oct 25, 2012 at 03:09:55PM -0400, Michael Gilbert wrote: 2. Salvager uploads liberal (10-day delayed) nmus as needed to bring the package into a better maintained state. Lucas' proposal discussed in this thread is about adding a lightweight procedure to mark obviously unmaintained packages as orphaned. If you want NMUs to be more liberal, then please write a proposal for modifying the NMU procedure and feel free to discuss it in a separate thread. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026065601.gl10...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - sponsoring
On Thu, Oct 25, 2012 at 10:05:40PM +, Jean-Michel Vourgère wrote: When fixing non important bugs, or improving the package quality, like switching to format 3 source, arranging the rules file, and so on, I fear it will be very difficult to find a sponsor for these nmus. Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these cases. After it's done, one can work on more radical changes, that are more likely to get sponsored. I find it sad to see patches hanging for years in the bug tracker. I fully agree with the above. I occasionally sponsor packages. I don't sponsor NMU packages when they contain changes that don't conform to the NMU procedure. I understand that it is difficult for non-DDs to salvage packages via NMUs. I prefer that an unmaintained package is simply orphaned, so that the non-DD can adopt the package with full maintainership. Much easier to sponsor. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026071211.gm10...@master.debian.org
Re: non-developer packages depending on gettext?
On Fri, 19 Oct 2012 23:20:39 +0700 Ivan Shmakov oneing...@gmail.com wrote: Neil Williams codeh...@debian.org writes: […] Check if the package contains a shell script which supports translated output strings — such packages should Depend: gettext-base rather than drop the dependency entirely. I've had a quick look at gnas and it does seem that this is a case where gettext-base is required, but not gettext. ACK, thanks for the information. To note is that Source: gnunet has contrib/report.sh, which calls gettext(1), but it doesn't seem to be propagated to any of the binaries currently depending on gettext. You've misunderstood the gettext packaging. $ dpkg -S `which gettext` gettext-base: /usr/bin/gettext So packages/scripts which call gettext should not depend on gettext but on gettext-base instead - that's the point. This little wrinkle (an executable not being packaged in the binary package of the same name) is probably the entire reason for why packages end up with the wrong dependency. It doesn't get picked up because, in most cases, it simply doesn't matter enough. Having gettext and gettext-base installed is rarely going to be an actual problem, it's merely an inconsistency. gettext should only be necessary for packages or tasks which *manipulate* PO files directly, rather than use the processed .mo files to generate translated output. So, Build-Depends: yes, Depends: probably a bug. gettext-base is only really needed when the package provides shell scripts with translated output because those evaluate the gettext process at runtime but that only requires gettext-base, not gettext. .. and that evaluation in shell scripts uses /usr/bin/gettext in an eval or similar but that still means a dependency on gettext-base *not* gettext. Could be worth filing a wishlist bug against lintian because it should be quite easy to spot. ? I see no easy way to discern between these three cases (the dependency is valid, depend on gettext-base instead, drop the dependency altogether.) 0: Manipulating PO files directly should only happen during package builds, so either the package is itself a build tool (like po4a) or the dependency goes into Build-Depends. 1: Depend on gettext-base but not gettext when the package calls /usr/bin/gettext, dgettext and/or ngettext directly (all from gettext-base) rather than the other executables in the gettext binary package which do stuff like manipulating or reporting on PO files. 2: Drop any dependency when no calls to gettext can be found in the source and it isn't a build tool. Languages other than shell have in-built ways of using the .mo file prepared through PO and gettext to output translated text at runtime. This has nothing to do with running gettext itself. Languages may also have their own packaging support for this, e.g. liblocale-gettext-perl (which itself uses the libc support, not gettext-base). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp0CrZvfDsdj.pgp Description: PGP signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek vor...@debian.org writes: No, it makes the process based on *consensus*, which is a minimum requirement. It also means that the salvager has to do more work. I expect the cc to debian-qa to draw sufficient DD's attention. And the ACKs are about agreeing on marking a package as orphaned. That's the easy part. The salvaging part goes via the existing ITA procedure. That's the hard part. Exactly. Anyone who can't be bothered to find N other DDs to agree with him that a package should be orphaned (for some value of N = 3 - as far as I'm concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering themselves a candidate for maintaining the package anyway. I am then unfit to maintain any package, since I would not be willing to do more than CC -qa@ by the time it comes to an ITO, to draw attention. If I get no answer to that, no acks, no nothing (and similar things did happen in the past, perhaps not on -qa, but I have mails on -devel@ and -release@ unanswered, or complained about months later after the fact), I would not want to go out of my way to find consensus. I take no replies (within a reasonable timeframe) as not caring, as silent agreement. By the time -qa@ is mailed, the salvager had to do enough visible work to draw attention to the eventual ITO, so mailing -qa@ should be enough, whether that gets the salvager any acks or not. In case of no acks, it is *NOT* the salvagers fault that noone cares, and therefore it is not the salvager who should be punished with more gruntwork, either. I don't really see the point of requiring consensus if there are *zero* replies to an ITO CC'd to -qa@ for, say, 2-3 weeks. On a similar note, the original proposal did not mention how much time needs to pass before the salvager can proceed, after getting a majority. THAT too, needs a timeout, and if it does, why would it hurt to bake in a worst-case scenario with no acks or nacks? (I can accept defaulting to no too, after a timeout, as long as there's one. I would find the result pointless and silly, but at least it puts an end to it, which the current proposal doesn't.) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haphy8ql@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On 10/26/2012 01:09 PM, Bart Martens wrote: I expect the cc to debian-qa to draw sufficient DD's attention. And the ACKs are about agreeing on marking a package as orphaned. That's the easy part. The salvaging part goes via the existing ITA procedure. That's the hard part. Regards, Bart Martens Could anyone explain what broken thing we are trying to fix? - Is the current process of orphaning broken? (if so: why?) - Is there too many hijacks? - Not enough salvage? And more importantly: - What do you expect the new procedure will do? What's the goal? I have re-read Lucas Nussbaum original post, and I didn't find any information about the above. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a45d3.8070...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Bart Martens ba...@debian.org writes: I think that sufficient DDs will review the ITOs. Note that most work is already done by the ITO submitter. Sponsoring a package at mentors (review other peoples work) is, in my opinion, much more work than reading an ITO and sending an ACK. On the other hand, ACKing an ITO is much more responsibility, becasue it's not only about a package, but about taking over a package too. No, it is not. See the two activities explained here: http://lists.debian.org/debian-devel/2012/10/msg00261.html It is still more responsibility than sponsoring, whether you orphan or take over the package, because you're not just introducing a new package or a new version as with sponsoring, you're not just doing an NMU, but you're taking away something from someone. This latter part is what - in my opinion - makes ACKing an ITO a much bigger thing than sponsoring or NMUs. An ITO will also contain quite a lot of info about previous attempts at updating the package - that's not simple to review either. It is less technical too, which can be off-putting to some. No, an ITO should just enumerate the reasons why the package should be marked as orphaned. And the reasons why the package should be orphaned overlaps quite a bit with previous attempts at getting the package fixed/updated/whatever by other means. If there were no previous attempts, then the package should not be considered for ITO. As said elsewhere in the thread, the process needs to be easy and efficient. Hunting ACKs is neither easy, nor efficient. The proposed text is quite easy, in my opinion. Indeed, it is. Partly because as far as I understand it, it only recommends a 3/1 majority, and does not demand it. That's perfectly fine. I guess it's a recommendation because it would go in developers-reference. That doesn't mean that it would be OK to randomly orphan packages ignoring the recommended procedure in developers-reference. I never said ignoring the recommended procedure. CC-ing -qa@ is a must, I never said otherwise. I merely said that *waiting* for ACK/NACK replies should have a timeout, and if no response arrives within a reasonable amount of time, we should default to allowing the salvager to proceed. That is all. Without the timeout, we have a hole in the system: how long do you have to wait for replies? When is majority reached? As soon as 3/0? What if that happens within 10 minutes, and a NACK would come on the 15th? If waiting for majority does have a timeout, what happens if there are no replies for one reason or the other? These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops, and default to yes in case of no replies, on the grounds that mistakes can be corrected, and we should be civilised enough to not flame the salvager to crisp if that happens (since it was us who failed to give him feedback in the first place - punishment shall be on us, not the salvager). -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d305y88b@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal
On Fri, Oct 26, 2012 at 04:12:03PM +0800, Thomas Goirand wrote: On 10/26/2012 01:09 PM, Bart Martens wrote: I expect the cc to debian-qa to draw sufficient DD's attention. And the ACKs are about agreeing on marking a package as orphaned. That's the easy part. The salvaging part goes via the existing ITA procedure. That's the hard part. Could anyone explain what broken thing we are trying to fix? - Is the current process of orphaning broken? (if so: why?) - Is there too many hijacks? - Not enough salvage? And more importantly: - What do you expect the new procedure will do? What's the goal? People interested in salvaging an unmaintained package are discouraged by the current procedures. The new procedure is meant to add a lightweight procedure to mark unmaintained packages as orphaned, so that anyone interested can adopt them without needless delay. Basically the goal is to increase speed in getting packages salvaged. I have re-read Lucas Nussbaum original post, and I didn't find any information about the above. Some aspects were discussed earlier in different threads than this one. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026090720.ga23...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - need for ACKs, default no orphaning
On Fri, Oct 26, 2012 at 09:59:16AM +0200, Gergely Nagy wrote: Bart Martens ba...@debian.org writes: I think that sufficient DDs will review the ITOs. Note that most work is already done by the ITO submitter. Sponsoring a package at mentors (review other peoples work) is, in my opinion, much more work than reading an ITO and sending an ACK. On the other hand, ACKing an ITO is much more responsibility, becasue it's not only about a package, but about taking over a package too. No, it is not. See the two activities explained here: http://lists.debian.org/debian-devel/2012/10/msg00261.html It is still more responsibility than sponsoring, whether you orphan or take over the package, because you're not just introducing a new package or a new version as with sponsoring, you're not just doing an NMU, but you're taking away something from someone. This latter part is what - in my opinion - makes ACKing an ITO a much bigger thing than sponsoring or NMUs. When a package has clearly not been maintained for years, then marking it as orphaned doesn't take away something from someone. I agree that there is some responsibility involved. But the work is easy. In obvious cases sufficient ACKs will be collected in no time. When there is doubt, a NACK is appropriate. I trust DDs to be responsible with this. An ITO will also contain quite a lot of info about previous attempts at updating the package - that's not simple to review either. It is less technical too, which can be off-putting to some. No, an ITO should just enumerate the reasons why the package should be marked as orphaned. And the reasons why the package should be orphaned overlaps quite a bit with previous attempts at getting the package fixed/updated/whatever by other means. If there were no previous attempts, then the package should not be considered for ITO. Marking a clearly unmaintained package as orphaned is useful regardless of previous attempts to update it. As said elsewhere in the thread, the process needs to be easy and efficient. Hunting ACKs is neither easy, nor efficient. The proposed text is quite easy, in my opinion. Indeed, it is. Partly because as far as I understand it, it only recommends a 3/1 majority, and does not demand it. That's perfectly fine. I guess it's a recommendation because it would go in developers-reference. That doesn't mean that it would be OK to randomly orphan packages ignoring the recommended procedure in developers-reference. I never said ignoring the recommended procedure. CC-ing -qa@ is a must, I never said otherwise. I merely said that *waiting* for ACK/NACK replies should have a timeout, and if no response arrives within a reasonable amount of time, we should default to allowing the salvager to proceed. That is all. I'm with Steve L. on this. Without sufficient ACKs, no orphaning. Without the timeout, we have a hole in the system: how long do you have to wait for replies? When is majority reached? As soon as 3/0? What if that happens within 10 minutes, and a NACK would come on the 15th? If waiting for majority does have a timeout, what happens if there are no replies for one reason or the other? Collecting ACKs is useful to avoid needless delay to wait for possible objections. It is, in my opinion, OK to conclude the ITO with three ACKs, without further delay. If nobody sends ACKs nor NACKs then something went probably wrong with the cc to debian-qa. These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops, I prefer no delay in the text, but I have no strong opinion on this. and default to yes in case of no replies, Without sufficient ACKs, no orphaning. My opinion on that is quite strong. on the grounds that mistakes can be corrected, and we should be civilised enough to not flame the salvager to crisp if that happens (since it was us who failed to give him feedback in the first place - punishment shall be on us, not the salvager). Of course, the maintainer can re-adopt his/her package during the time it is orphaned. But if someone else already has retitled the O to ITA, then in general that person should be allowed to continue. Of course, all involved parties can still talk and agree on something else. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026093548.gb23...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - no ACKs nor NACKs, timeout, defaulting to no
On Fri, Oct 26, 2012 at 09:48:18AM +0200, Gergely Nagy wrote: why would it hurt to bake in a worst-case scenario with no acks or nacks? (I can accept defaulting to no too, after a timeout, as long as there's one. I would find the result pointless and silly, but at least it puts an end to it, which the current proposal doesn't.) I would not object against including this in the text. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026094407.gc23...@master.debian.org
Re: Candidates for removal from testing (results)
On 2012-10-18 10:32, Niels Thykier wrote: Hi, [...] If the relevant RC bugs in the affected packages are not dealt with /before/ Friday the 26th of Oct., the packages will be removed from testing. Note that dealt with may also include downgrading a severity-inflated bug or fixing affected versions in the BTS. Britney has just finished removing the following 21 packages: ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma, lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg, phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui, sugar-chat-activity-0.86, sugar-log-activity-0.86, sugar-moon-activity, twidge, venkman The removed packages accounted for about 4.4% of all RC bugs left in testing[0]. [...] Should you need a bit more time than given, please do not hesitate to contact us. It is also easier for us if we can avoid having to reintroduce a removed package. [...] We got about 3 or 4, who took advantage of this offer. I also noticed two bug reports with a promise of a (N)MU in the report, which I left for now[1]. By my count 5 RC bugs got downgraded and about packages 14 got an upload to unstable (most of which have already been unblocked). ~Niels [0] According to [BTS-RC], there were 479 RC bugs concerning testing at 6 am UTC. Assume that each package only had 1 RC each, 21/479 ~~ 4.4% [BTS-RC] http://bugs.debian.org/release-critical/ [1] But I intend check up on them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a67f2.7010...@thykier.net
Re: Bug#691479: ITP: pcalendar -- application to track women menstrual cycles
Dmitry Smirnov writes: Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: pcalendar Version: 3.3.0 Upstream Author: Mar'yan Rachynskyy mr...@users.sourceforge.net URL: http://linuxorg.sourceforge.net/ License: GPL-3+ Description: application to track women menstrual cycles Periodic Calendar is a GUI application which assists in women menstrual cycles tracking and fertility periods prediction. This information can be used as. supportive either for conception or contraception planning. . Periodic Calendar provides support for sympto-thermal method which has the highest reliability in fertility periods prediction. User can choose any subset of the. features to be used or even fall to the generic calendar method (which if used. alone is very unreliable)... . Periodic Calendar is not an equal substitute to the fertility planning consultants or doctors. Before using this application please talk to your doctor or read a good book on the subject. . THIS PROGRAM PREDICTIONS IN NO WAY CAN BE USED AS THE FINAL. THERE ARE NO PREDICTION METHODS WHICH PROVIDE 100% RELIABILITY. Hi, this software is already packaged, (http://packages.qa.debian.org/p/pcalendar.html) -- Alberto -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haph5wif@eps142.cdf.udc.es
Re: Bug#691479: ITP: pcalendar -- application to track women menstrual cycles
Hi Alberto, Thanks for your reply. On Fri, 26 Oct 2012 21:59:52 Alberto Luaces wrote: Hi, this software is already packaged, (http://packages.qa.debian.org/p/pcalendar.html) Indeed it is, sorry for the noise. It was already revealed to me so I closed the ITP. I've searched for ovulation and menstruation using apt-cache search: that returned cycle and mencal but not pcalendar which I would have found if I could spell menstrual... Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210262217.10128.only...@member.fsf.org
GR: Orphaning another maintainer's packages
Hi, while Lucas did his best to summarize the outcome from the last thread in a fairly constructive and consensual way, it turned out that too many people have too many opinions here on this matter. Having clearly in mind, that seeking consensus by way of a General Resolution for something ending up in Developer's Reference is like breaking a fly on the wheel, I believe this is the only way out of this impasse which yields to any working solution. As it looks to me, I observe: *) we have consensus that we are in need of such a rule set - which ever it may be *) we have three orthogonally different ideas: a) Bart's approach which was reformulated and proposed by Lucas in this thread [1] b) Mine - which was based on timeout arithmetics [2] c) Michael Gilbert's approach to merge the concept of NMUs with orphaning packages [3] Among these, alternative a) seems to attract most responses and opinions, most agreeing in spirit and procedures, but disagreeing about one detail ... *) ... within approach a) the most heat seems to deal with the necessity to seek ACKs/NACKs for an intent to orphan of a package by peers. If we would exclude the paragraph about DD seconding we are also roughly there, what Sune proposed in [4] and - in spirit - seems to be most attractive alternative to the original proposal. Therefore, I consider seeking resolution by means of a GR proposing Lucas alternative [with minor formulation tweaks and after discussion of the actual text] (that is, proposal a).) without the DD seconding part, because I do not like that much, personally. Moreover, if we decided to go this way, I endorse anyone liking the DD seconding to formulate an amendment adding this or another requirement to the resolution statement. What do you think? Does this sound like a fair compromise everyone could live with? [1] https://lists.debian.org/debian-devel/2012/10/msg00469.html [2] https://lists.debian.org/debian-devel/2012/09/msg00654.html [3] https://lists.debian.org/debian-devel/2012/10/msg00524.html [4] https://lists.debian.org/debian-devel/2012/10/msg00473.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:46:41PM +0200, Arno Töll wrote: What do you think? Does this sound like a fair compromise everyone could live with? Voting is almost never a way to reach consensus. Rather, it acknowledges that consensus has not been reached and side-steps further constructive attempts to reach it. I'm positive we can have consensus on this issue. In fact, I think we're pretty close to it. I'm traveling, so can't elaborate in more detail on this matter. But I urge you to reconsider proposing a GR. It is a heavy weight tool, that should be used as a last resort. I don't think we're nowhere near the need of it in this specific case. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:54:19PM +0200, Stefano Zacchiroli wrote: I don't think we're nowhere near the need of it in this specific case. s/don't// obviously :) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026115516.ga10...@upsilon.cc
Re: GR: Orphaning another maintainer's packages
On 26.10.2012 13:54, Stefano Zacchiroli wrote: But I urge you to reconsider proposing a GR. It is a heavy weight tool, that should be used as a last resort. So far I agree. I didn't say I'll propose on - JFTR. I said I'll consider that and asked for opinions - like yours :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Discarding uploaded binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 02:13, Peter Miller a écrit : It may be possible to address both concerns in a different way. 1. Implement PPAs. The code is open source, get it working first, and enhance it later. 2. DDs and DMs upload source-only to their individual PPA(s). The PPA build farm builds the package on all the architectures Debian cares about. 3. When a DD or DM wants to place a package to testing or experimental, it is done as a *copy* from a PPA (no upload required). If the package in the PPA didn't build, no copy happens. This means folks who pay $$$ for uploads don't have to upload the binary package that is discarded. But it also means the package is known to build (on all architectures) before being copied into testing or experimental. The autobuilders will still see many failing builds. Perhaps even more, if you openly advertise them as a way to perform test builds. I don't see what you gain from it. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinjwAAoJEJOUU0jg3ChAUwUQAJCrR+y1wb8EebuJgW89DHAN PJkIGdB1w3M7opk+oYNybGa+vEM5/4KITDLJ1/ie/l5bauEJQHoJMEog0UoILK2H TLEO1xlbc89hK6NWwEmGnrH68yxytMJNcJszdlxAX+94S1WvDzuu8H9e3P/cVKlU xg7ZOYnI/G4CjFkRJExTdgJaQF9pz/l7MffztIAt/rDrmsowXStwlqyGAbeYlydL JBHMeM/CB0V+gIFjMmK/n34uv9oPxGU4H7hzsJaKW+A0j9anvf3n+SkW8bzvBk6f VvCmAnk8XDzdSCw7llqE0dt1M5ffnIAGUfSHbzdhplMGPYeuPpu/aB3/H4r30fpk 8jir2YWJholoG8ngk+Xr8Y+eTW26YJuutwlN3bKTETuUW9EOSsiYXnXlO0UNOEGu C4Y6xJKFbCOWStLjYj+lT843tY53xqNukTBBhfnWFd+SkajMQsJTElyiW1VvRBot lSaXtQ6pjMiPZp7oBgKHOvYZrCV7jikcqbBOojx8f8dQywpKiWmvJZyQCLY3UgSN rCS39TdSTPHDlW22KNW9F4AoQQdGxUcWC+Rw5PjQ+7G+ilKDC+7mMl1w6DXT49Af YB43+B1eZzoseQhbMQylWq2LmoYJWSgURlzzJtXalTPwyRg8qaO0qrjo2Wevu1jg +N7K43qPk3MMN8h/w0NA =N717 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a7938.7070...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 08:35, vangelis mouhtsis a écrit : Hi, I'm wondering, before a package will be orphaned is it possible/ needful the owner to ask for help or to express the reasons? Regards gnugr http://www.debian.org/devel/wnpp/ Look for RFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinm/AAoJEJOUU0jg3ChA09wQAIsS1aQf81ela8jA73azBwrN DoDxzYGyNQQBtv1X5h3S7lYvLk4mXLs+JnkDfrI4gzdsE/3j8yw8wA6c9YjLMnMo qqPZwZ6Pv1Cvv7CQ02qAJujbqjoftwOn6vCtIPPKLJ7gzJrFIDoAqhRfCjdLPwB3 hpR9wvi3P9kCvCWKZgCZTwOymFIM7Oeie07bVhI55MSC925msG5Bg5Iy77EjppIl LmwW3WWY+x7ut1nkwNjkhs6dHWGOKjPh1louetEmqEng97FXUCFS/WiTUEz3QN7D qxSIA4QkTnSHpbwY8zvt4jBOHT+PCfc8yQ2omjwoFK4YvgUiuFRSHFP1rueHSjSZ LSvM/n+Oaxw9wgpcmeDedTabk1bO9Dy2NcP+rQsICV0OimioxMqTeHT8wXW4mAAt mSbMuu393CxJ2xs2kBTRFCmWxqYJu6vTUEyZstc9W7ZdISBGGnYHMghcixtQejEM 5Zlv/oN6BQKMP9h0fk/Rmfx9HEaobqzvrXktd3vlLZOwdihyD38ZwaHB/YoTya7d Zaq8kcb1PRTDqM3j4hZE9ZmNzyB3JUuEWDiaBT/LOmIydXbPug3UBzvBb5ecJ0LG cYhnxLNPAExPXGwsAx6yid1YVnz44CquW4ou5Wdcs7qw1PRYPqCkXtvDA1kBopH+ jG1s2GLVU9UPgBE+VZiv =x9xl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a79bf.7080...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 08:46, Bart Martens a écrit : On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current proposal, as long as three DDs think it should be orphaned, the maintainer's objection is irrelevant. I would send a NACK because the maintainer objects, and I trust other DDs subscribed to debian-qa to do the same. The ITO procedure is not meant to replace the TC handling conflicts. So why not agree now that the maintainer can veto the process? Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinr/AAoJEJOUU0jg3ChAJ74P/3i8/IHIS1HN/IRdldsQUEa8 sJvW/hRd2iXrPmwLCkxP0ng0XmiG8GZ8JjYo7esYWbU2omgJhZ/XxlOKeePHQJfA RQ5ifYq1kZFZT+5xpkwqlhtQ+MBbTuMSRYmDsEgyjnwoEQGLrjCld/+Q4SJA5EQo DvGgFOd3gvz0SpJa8Tp9wDfr8bXezEJs8iTBiGCnihs4n+Qfhjc7aHrAEUenOzuh ZWnEmpbByF79jHYuor403Lu9TPwrCklVxZ69qKhSHJlDVTUDoC2H8MxZcLyJwYqJ KmmwQMYFi8mf210WPw/OpJ9mDYR+VbCWA4zFaoq91rFoxsmIVn0Z8upFFQVyr4fZ DnxKBxeOjBC25hb5301v67cZOYC6x+izfHY9oPHuzPCPkinybk1ak0KpsIX5vXTU jCy4xCt3Uu1RnJBl0f215RpyKxcGx8Nh67t0GjjyfP72ZrfM9LluwzZRGXyixCJU ujnZZZ5+VSzqsXGYAQW9UU1ME9ap4yLJ6jXYsX0AEuzF0y6XT7iHLQ2c3nHGWlgv fk7Gl7+23lxOs1VbWgbiHwhyRLp/F0BAD+eUjtnAYWGPFpFrp/FV6JkOosTmL4kM yUfBjTIhGlp9uPcYO9hikyRXkvp0P1lDE1GMe0Ng8gCUfymBFu6r5O3ENkZ2q2Ii B2UFYpy1as6N4BykeEr5 =2BdK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a7aff.3020...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - without objection versus requiring ACKs
Bart Martens ba...@debian.org wrote: On Thu, Oct 25, 2012 at 09:06:34AM -0400, Scott Kitterman wrote: Why not start with a without objection standard and see how it works? The without objection approach would require a reasonable delay for people to raise objections (some say two months). The ACK/NACK approach allows to reach a consensus in a shorter time, so that for obvious cases the salvaging can proceed without pointless delay. No. Changing 3:1 ACK/NACK to 3 (or some other number) ACKS and no objections imposes no such constraint. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/89ce141c-80d9-4e5f-b73b-2089677f2...@email.android.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
Bart Martens ba...@debian.org wrote: On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: Gergely Nagy alger...@balabit.hu wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Whether a package is in need of greater attention is not a hard and fast objective thing. It's to a large part subjective. Perhaps the maintainer thinks it's more or less fine, or at least low enough priority that the problems are tolerable. Then the maintainer has many options, including but not limited to NACK-ing the ITO. One has a lot of possibilities even before it comes to filing an ITO. AIUI, with the current proposal, as long as three DDs think it should be orphaned, the maintainer's objection is irrelevant. I would send a NACK because the maintainer objects, and I trust other DDs subscribed to debian-qa to do the same. The ITO procedure is not meant to replace the TC handling conflicts. But as written, it does. It should be changed. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/99822e4d-662e-4589-ae72-5a017906b...@email.android.com
Re: Discarding uploaded binary packages
On 26.10.2012 01:13, Peter Miller wrote: It may be possible to address both concerns in a different way. 1. Implement PPAs. The code is open source, get it working first, and enhance it later. 2. DDs and DMs upload source-only to their individual PPA(s). The PPA build farm builds the package on all the architectures Debian cares about. 3. When a DD or DM wants to place a package to testing or experimental, it is done as a *copy* from a PPA (no upload required). If the package in the PPA didn't build, no copy happens. s/testing/unstable/, presumably? It builds everywhere is only one criterion involved in testing migration; for all of the others, migration to testing from anywhere other than unstable doesn't really make sense. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8713c24579dac159d4024ca710485...@mail.adsl.funky-badger.org
Bugs filed in unexpected places
Hi all, The discussion about ITO made me think: wouldn't it make more sense to also have RFH, RFA, and O filled against the package itself and not wnpp? One has to be quite familiar with Debian to check wnpp for RFH, RFA or O. Maybe having these bugs in the face of people interested in the package (i.e. on the package's bug page) can help attract contributions. Additionally for some packages it might make sense to remove them from testing and raise the severity of the O bug to serious to signal that the package should not be included in the next release unless someone is willing to commit to maintain it. An immediate solution would probably be to 'affects package' so the bugs at least shows up on the package's bug page. Maybe the BTS could/should do this automatically? One a somewhat related note, I also notice confusion is created by the removal bugs being filed against ftp.debian.org. When people not familiar with Debian are looking into why a package has been removed they look at the (archived) package's bugs. Not a biggie, but might help users or prospective ITPers (e.g. if the removal reasons still apply). Not sure if 'affects' can help here. I'm guessing the current procedures were created because at the time the BTS did not have the 'affects package' feature. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Russ Allbery r...@debian.org writes: Michael Gilbert michael.s.gilb...@gmail.com writes: On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote: Okay, well, I guess I return to my previous statement, then. I don't think your proposed solution will work for the more common cases. I respect your opinion, so I'm just curious which part do you believe won't work in common cases? It's just applying existing NMU rules with a little more liberalism to increase activity in under-maintained packages, so I personally can't see where it would break down. Well, that's what I was trying to get at: I think your method puts too many barriers in the way of someone who wants to take over an effectively abandoned package. It also requires *more* skill than adopting the package would otherwise, since you have to be good enough at Debian packaging to make minimal chnages within some arbitrary packaging scheme. In other words, it requires as much or more skill than doing NMUs, whereas adopting a traditionally orphaned package is much easier. Very much agree. I am much more likely to work on a neglected package if I can use the tools that I'm familiar with from my own packages. The prospect of having to reverse engineer the packaging before I can make any useful changes is very discouraging. I am *not* a DD, so I think I'm qualified to say that if the goal of the proposal is to attract new contributors to help with existing packages, being allowed to change the packaging style is crucial. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uglcqzq@inspiron.ap.columbia.edu
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote: Le 26/10/2012 08:46, Bart Martens a écrit : On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current proposal, as long as three DDs think it should be orphaned, the maintainer's objection is irrelevant. I would send a NACK because the maintainer objects, and I trust other DDs subscribed to debian-qa to do the same. The ITO procedure is not meant to replace the TC handling conflicts. So why not agree now that the maintainer can veto the process? Because this would raise the question how long should we wait for the maintainer to object or to remain silent. In obvious cases, for example when the package has clearly not been maintained for years, then three ACKs from DDs should be sufficient to orphan the package, so that the package can be salvaged quickly, without pointless delay. In less obvious cases, for example when the maintainer objects, I trust the DDs to send NACKs to the ITO, so that the package is not orphaned forcibly. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026134025.ga17...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Friday, October 26, 2012 01:40:26 PM Bart Martens wrote: On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote: Le 26/10/2012 08:46, Bart Martens a écrit : On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current proposal, as long as three DDs think it should be orphaned, the maintainer's objection is irrelevant. I would send a NACK because the maintainer objects, and I trust other DDs subscribed to debian-qa to do the same. The ITO procedure is not meant to replace the TC handling conflicts. So why not agree now that the maintainer can veto the process? Because this would raise the question how long should we wait for the maintainer to object or to remain silent. In obvious cases, for example when the package has clearly not been maintained for years, then three ACKs from DDs should be sufficient to orphan the package, so that the package can be salvaged quickly, without pointless delay. In less obvious cases, for example when the maintainer objects, I trust the DDs to send NACKs to the ITO, so that the package is not orphaned forcibly. It seems like an obvious bug in the proposal that I don't understand the resistance to fixing. Rather than trust is won't be a problem, why not fix the bug and change it to if there are NACKs, it's a dispute for the tech ctte? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5609089.6aMmCRQnhL@scott-latitude-e6320
Re: Bugs filed in unexpected places
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 15:24, Andrei POPESCU a écrit : Hi all, The discussion about ITO made me think: wouldn't it make more sense to also have RFH, RFA, and O filled against the package itself and not wnpp? One has to be quite familiar with Debian to check wnpp for RFH, RFA or O. Maybe having these bugs in the face of people interested in the package (i.e. on the package's bug page) can help attract contributions. Hi, it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: problems The current maintainer is looking for someone who can take over maintenance of this package. If you are interested in this package, please consider taking it over. Alternatively you may want to be co-maintainer in order to help the actual maintainer. Please see bug number #532093 for more information. I don't see a reason to move it away from wnpp: its great to have a central place for that information, but I agree it is useful to have the info forwarded to other places (such as the PTS, and perhaps the package's own bug page). Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQipI7AAoJEJOUU0jg3ChA5O8P/iu9wJ6hZneEmuW9wHBckxpe 3LdgUnWmjQNM/ZDmgtwnGZa1MW8aoHyx6lQIRJl18whiDlLSIWESX2iNdn2jiw/j 7/3DAhTevEeYDVmuItXxWj43GLit/dogSKNP4K4Qwx0/OpGoG4oQ4MxI7DQPJiM9 /JdgeW2yKh8K0D4HbsZ+9pC9Y/3c8yzAZHhNepmYFtQLK3IvQ1WPey9UdMTiO57Z hboowwrN0CAn6aBcRDtqZPDMwuupH6r82+0N12KxGEP1PoGsA1+peQekObVN1OTN jqzq5Ns4aaSeZBHo5PdYfCv0TiLjFFu/6w6cgZm/0AGlHmL/retDBG3nS/52OC4J zM8Y9L8h3g4/2dL8C6cr0aTyZ94AWpFUNDGZl5VB4+E0GY3woIFoGkgrbrGwYycr iTjOTJhrFgzqA+z2rQix1Wt9bFkgwpi5/VzsEytkzBEfEDWN70OzdbGTvBTRqU0/ IraAzshSH660aNlaSbMpv1McyNij6sy7OcVLXJbahXrNvGnnrTWup2AC81LVYhuk MLLt+36mWTgH+e/aolfc/C+amisHrXLweU/ScBctJYgYLoPPN0eWA0G7zxzxoe+b a+8LzY4lctfHiMbUQZhPeMX0K184QFsYL9werx9qoIQxWohqHmi5Vknu8usm+CNF Sr81+OAxieG4CnaQa93S =6H/Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a923b.5020...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - full maintainer without restrictions
On Fri, Oct 26, 2012 at 09:17:13AM -0400, Nikolaus Rath wrote: Russ Allbery r...@debian.org writes: Well, that's what I was trying to get at: I think your method puts too many barriers in the way of someone who wants to take over an effectively abandoned package. It also requires *more* skill than adopting the package would otherwise, since you have to be good enough at Debian packaging to make minimal chnages within some arbitrary packaging scheme. In other words, it requires as much or more skill than doing NMUs, whereas adopting a traditionally orphaned package is much easier. Very much agree. I am much more likely to work on a neglected package if I can use the tools that I'm familiar with from my own packages. The prospect of having to reverse engineer the packaging before I can make any useful changes is very discouraging. I am *not* a DD, so I think I'm qualified to say that if the goal of the proposal is to attract new contributors to help with existing packages, being allowed to change the packaging style is crucial. I strongly agree with what Russ Allbery and Nikolaus Rath wrote above. When a package is clearly not maintained, then it should be orphaned, so that a new contributor can become full package maintainer without any restrictions on the allowed changes. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026135454.gb17...@master.debian.org
Re: non-developer packages depending on gettext?
Neil Williams codeh...@debian.org writes: Ivan Shmakov oneing...@gmail.com wrote: Neil Williams codeh...@debian.org writes: […] To note is that Source: gnunet has contrib/report.sh, which calls gettext(1), but it doesn't seem to be propagated to any of the binaries currently depending on gettext. You've misunderstood the gettext packaging. $ dpkg -S `which gettext` gettext-base: /usr/bin/gettext So packages/scripts which call gettext should not depend on gettext but on gettext-base instead — that's the point. The point is that I haven't checked for gettext(1) the first time I've examined the gnunet source package. So, even though I was sure that the dependency on gettext was unwarranted, I didn't actually rule out gettext-base. […] Could be worth filing a wishlist bug against lintian because it should be quite easy to spot. ? I see no easy way to discern between these three cases (the dependency is valid, depend on gettext-base instead, drop the dependency altogether.) 0: Manipulating PO files directly should only happen during package builds, so either the package is itself a build tool (like po4a) or the dependency goes into Build-Depends. I understand the logic. What I can't understand is how to implement it as a lintian check. (There isn't really a “this package is a build tool” flag. There're Tags:, but they may be misleading; consider, e. g., gnuplot bearing suite::gnu.) 1: Depend on gettext-base but not gettext when the package calls /usr/bin/gettext, dgettext and/or ngettext directly (all from gettext-base) rather than the other executables in the gettext binary package which do stuff like manipulating or reporting on PO files. I don't see an easy way to check for calls to gettext(1), etc., either. Certainly, we can grep the source, but how reliably (and specific) would that be for a lintian check? 2: Drop any dependency when no calls to gettext can be found in the source and it isn't a build tool. Languages other than shell have in-built ways of using the .mo file prepared through PO and gettext to output translated text at runtime. This has nothing to do with running gettext itself. Languages may also have their own packaging support for this, e. g. liblocale-gettext-perl (which itself uses the libc support, not gettext-base). So, at least we could safely warn about a dependency on gettext-base for a package containing no Shell scripts. Still, it doesn't seem to rule out a dependency on gettext. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86sj91z3vg@gray.siamics.net
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Russ Allbery writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages): I think orphaned packages are one of our best opportunities to attract new developers, rather than serving as an additional obligation for existing developers. [etc.] Thanks for that excellent analysis. You have convinced me that the salvaging process should countenance orphaning packages, as well as (or perhaps instead of) allowing a different maintainer to take them over. I still think that the right standard is no objection rather than collecting some explicit number of acks. In particular I don't think any number of acks ought to override a nack from the existing maintainer. And if we're allowing any single nack to stop it, then I don't see what requiring ack(s) buys us. It would force the salvager to make explicit their criticisms of the package and hence the maintainer. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20618.41869.34617.514...@chiark.greenend.org.uk
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
Bart Martens writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay): On Thu, Oct 25, 2012 at 02:50:46PM +0100, Ian Jackson wrote: 3. Wait for objections For how long ? The proposal includes collecting ACKs so that any pointless delay can be skipped, resulting in the package being salvaged sooner. I was thinking some weeks. I do think this delay is essential, not pointless. It is there to allow a maintainer who wishes to resist the orphaning to do so. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20618.42165.454144.292...@chiark.greenend.org.uk
Re: Bugs filed in unexpected places
* Thibaut Paumard thib...@debian.org [121026 15:54]: I don't see a reason to move it away from wnpp: its great to have a central place for that information, but I agree it is useful to have the info forwarded to other places (such as the PTS, and perhaps the package's own bug page). Having a central page to show all of them is nice. Having them in one pseudo page is not really the optimal solution for that. (I usually only look for http://www.debian.org/devel/wnpp/work_needing instead because https://bugs.debian.org/wnpp is just too slow.) Putting it to the package's data is a much more logical place, easier to find, harder to miss. Better collect the data to show them in some central place also instead. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026160646.ga29...@client.brlink.eu
Re: Candidates for removal from testing (results)
Great stuff, thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026160652.GC20294@debian
Re: Bugs filed in unexpected places
On Vi, 26 oct 12, 15:38:03, Thibaut Paumard wrote: it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: problems How many non-DDs/DMs do you think are aware of the PTS? My guess is: not that many. IMVHO the BTS is much more visible, especially to users who do take the time to report bugs. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Bugs filed in unexpected places
On Fri, Oct 26, 2012 at 07:39:52PM +0300, Andrei POPESCU wrote: On Vi, 26 oct 12, 15:38:03, Thibaut Paumard wrote: it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: problems How many non-DDs/DMs do you think are aware of the PTS? My guess is: not that many. IMVHO the BTS is much more visible, especially to users who do take the time to report bugs. How about how many non-DDs/DMs are aware of wnpp, versus the processed result of it (http://www.debian.org/devel/wnpp - which is not the same as b.d.o/wnpp, and could be auto-generated from e.g. a usertag or top-level tag just as easily as from b.d.o/wnpp) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026175244.GA22021@debian
Re: Bugs filed in unexpected places
On Fri, Oct 26, 2012 at 03:38:03PM +0200, Thibaut Paumard wrote: Le 26/10/2012 15:24, Andrei POPESCU a écrit : The discussion about ITO made me think: wouldn't it make more sense to also have RFH, RFA, and O filled against the package itself and not wnpp? One has to be quite familiar with Debian to check wnpp for RFH, RFA or O. Maybe having these bugs in the face of people interested in the package (i.e. on the package's bug page) can help attract contributions. it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: problems The current maintainer is looking for someone who can take over maintenance of this package. If you are interested in this package, please consider taking it over. Alternatively you may want to be co-maintainer in order to help the actual maintainer. Please see bug number #532093 for more information. I don't see a reason to move it away from wnpp: its great to have a central place for that information, but I agree it is useful to have the info forwarded to other places (such as the PTS, and perhaps the package's own bug page). Instead of parsing a wnpp bug title, with potential errors, have a more formal data model and tag RFH/RFA/O.. with a dedicated wnpp tag ? This way, you can : - easily get the list of wnpp bugs - easily see a package has a wnpp bugs - get rid of all the parsing needed by PTS, wnpp-alert, UDD, etc. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026180527.ga30...@glenfiddich.mraw.org
Re: Bugs filed in unexpected places
On Fri, 26 Oct 2012, Andrei POPESCU wrote: An immediate solution would probably be to 'affects package' so the bugs at least shows up on the package's bug page. Maybe the BTS could/should do this automatically? Doing affects automatically isn't really something that the BTS itself should do,[1] but it's trivial for anyone to script something to do this. wnpp bugs should be filed against wnpp or debian-mentors and marked as affecting the package they are involved with. Don Armstrong -- 6: I'm human. I have a thousand flaws. I break down. I get up or I don't get up. I get lost. I make the same mistakes over and over. I have scars and wounds. Sometimes when I can't bear them anymore, I drink. You can't fix me. You can't fix any of us. You can't make us perfect. -- The Prisoner (2009 Miniseries) _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121026181216.gl11...@rzlab.ucr.edu
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: I think this is where language is important. In my opinion, the term adoption will continue to mean taking on full responsibility for a package as its new maintainer. The term salvage, in my opinion, we can define as a process for becoming a co-maintainer on a package with a long-term possibility of becoming its maintainer. This is an unhelpful redefinition of the term. The term salvage was introduced to *mean* orphaning/adopting a package when the maintainer is no longer fulfilling their responsibilities. Why do we need two different terms defined as the exact same thing? In other words, if both salvaging and orphaning mean the same thing, then what's the point of salvaging? In my opinion salvaging (under the above definition) is something that would be able to happen a lot sooner than orphaning because it is initial a co-mainainter process, rather than a maintainer replacement process. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNYTDBqy6do+=flacn+srnvzfhosbbj3inou4qdad5...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal
On 10/26/2012 05:07 PM, Bart Martens wrote: People interested in salvaging an unmaintained package are discouraged by the current procedures. The new procedure is meant to add a lightweight procedure to mark unmaintained packages as orphaned, so that anyone interested can adopt them without needless delay. Basically the goal is to increase speed in getting packages salvaged. Thanks, this is much more clear now. After more thoughts, I probably agree such a proposal. Probably, Steve Langasek is right in that it shouldn't be such a big deal to find few DDs to vote for the salvaging... And if I understand well, this procedure is *on top* of what we have currently for orphaning anyway (eg: QA team orphaning MIA maintainers, and the tech. commity), right? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508ae1de.4080...@debian.org
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 7:46 AM, Arno Töll wrote: *) we have consensus that we are in need of such a rule set - which ever it may be *) we have three orthogonally different ideas: a) Bart's approach which was reformulated and proposed by Lucas in this thread [1] b) Mine - which was based on timeout arithmetics [2] c) Michael Gilbert's approach to merge the concept of NMUs with orphaning packages [3] My proposal has nothing to say about orphaning itself, and explicitly leaves it untouched. Mine can be considered a more flexible co-maintainer process that importantly can be started far before orphaning becomes a package's last resort. It also seeks to handle the hard cases whereas a) and b) explicitly state that they're avoiding that problem altogether. Anyway, I and seemingly many others don't like the bureaucracy of a) and b), especially since there is already a common-law 4*7*24*3600 rule in existence that would probably get applied more often if it were actual devref-law. Finally, if a) and b) aren't meant to do something about the original issue, the hard maintainership questions, then what's the point? Why do we need more bureaucracy when we already have a common-law solution? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNx1O0d0uQ9pLNgA=4z7ljslbssoqgcsolxjsg_4sr...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react
On Fri, 26 Oct 2012 16:56:02 Bart Martens wrote: On Fri, Oct 26, 2012 at 08:06:57AM +1100, Dmitry Smirnov wrote: If bug was unanswered for let's say two months the package is free to orphan Some prefer no delay, some prefer one month, some prefer two months. I originally wanted one month, but I got convinced by others to drop the delay. For merely orphaning minimising delay is not too important because if there is an active maintainer ready to adopt the package it is a salvaging procedure. For example if package is not maintained for years we can certainly wait for a month or two before orphaning even though there may be no need to wait that long. Now my opinion is that I trust the DDs reviewing the ITO to judge the package's situation before sending an ACK or NACK. One possible judgement on an ITO can be NACK until 2 months have passed or the maintainer has agreed to orphan the package. Another possible judgement on an ITO can be ACK because this package has clearly not been maintained for years, so please proceed without further delay. I'm convinced that acknowledging is ambiguous and unnecessary. First, what do you expect DDs to acknowledge -- the fact that package needs attention (this should be obvious already) or their approval of salvager? Assuming they're not familiar with salvager's work getting and acknowledgement might be as hard as finding a sponsor. Also this will rely on developers constantly reviewing ITA requests in other people's packages. Most certainly this will increase delay and the complexity of the procedure which might work only for popular packages with high visibility. I think in usual case we can expect no response for salvaging requests. Also without timed delay acknowledgements may be very unfair if few DDs voted for salvaging and therefore salvager got a green light without waiting for possible objections. Michael Gilbert's proposal to start salvaging with NMUs makes more sense as it allows to proceed gently and demonstrate motivation and willingness to work on the package. From non-DD prospective couple of successful NMUs will confirm salvaging intent and capacity better than random ACKs. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210270747.48293.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Sat, 27 Oct 2012 00:40:26 Bart Martens wrote: So why not agree now that the maintainer can veto the process? Because this would raise the question how long should we wait for the maintainer to object or to remain silent. In obvious cases, for example when the package has clearly not been maintained for years, then three ACKs from DDs should be sufficient to orphan the package, so that the package can be salvaged quickly, without pointless delay. In less obvious cases, for example when the maintainer objects, I trust the DDs to send NACKs to the ITO, so that the package is not orphaned forcibly. I recognise fundamental injustice here. If you expect ACKs then objections should be allowed as well but there might be unlikely situation when salvaging proceed after few ACKs without waiting for any further objections. I fear of conflicts it may create. Any form of agreement require fair amount of time for all parties to respond. If the matter cannot wait one can use NMU during transition of package ownership. This is in harmony with what Michael Gilbert proposed. In clear case when waiting is impossible without hurting the package state, DDs can take over without delays and take responsibility for future issues with maintainer. In any case we want salvaging to be documented in corresponding bug report. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210270800.17329.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Sat, 27 Oct 2012 01:51:57 Ian Jackson wrote: I still think that the right standard is no objection rather than collecting some explicit number of acks. In particular I don't think any number of acks ought to override a nack from the existing maintainer. Indeed. I think lack of enough acknowledgements can make process even slower. Acknowledgements will require developers to judge on other developer's intentions and I'm not sure wherever ACKs meant to approve the fact that salvaging is needed or to approve salvager and express trust to her/his capacities as maintainer. Probably not many people will find this role attractive so we can expect a lack of acknowledgements. And if we're allowing any single nack to stop it, then I don't see what requiring ack(s) buys us. It would force the salvager to make explicit their criticisms of the package and hence the maintainer. I'm sure salvaging intent can be neutral or positive. It is merely a declaration of intent to help maintaining a package. When original maintainer is responding it is effectively a co-maintainership offer. Only when maintainer is not responding it becomes de-facto a declaration of adoption intent (ITA) so perhaps word savlaging is not perfect to express the idea. There is nothing to suggest that salvager has to express any criticism. As far as I can remember some adoption experiences of mine I was sincerely grateful to previous maintainers for their work. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210270839.54287.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote: On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: I think this is where language is important. In my opinion, the term adoption will continue to mean taking on full responsibility for a package as its new maintainer. The term salvage, in my opinion, we can define as a process for becoming a co-maintainer on a package with a long-term possibility of becoming its maintainer. This is an unhelpful redefinition of the term. The term salvage was introduced to *mean* orphaning/adopting a package when the maintainer is no longer fulfilling their responsibilities. Why do we need two different terms defined as the exact same thing? In other words, if both salvaging and orphaning mean the same thing, then what's the point of salvaging? They don't mean the same thing. Maintainers orphan their own packages; adopters adopt orphaned (or RFAed) packages. Salvaging is the process of identifying packages that *should* be orphaned in the *absence* of the maintainer. In my opinion salvaging (under the above definition) is something that would be able to happen a lot sooner than orphaning because it is initial a co-mainainter process, rather than a maintainer replacement process. Comaintenance is irrelevant to the question at hand. -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek vor...@debian.org wrote: On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote: On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: I think this is where language is important. In my opinion, the term adoption will continue to mean taking on full responsibility for a package as its new maintainer. The term salvage, in my opinion, we can define as a process for becoming a co-maintainer on a package with a long-term possibility of becoming its maintainer. This is an unhelpful redefinition of the term. The term salvage was introduced to *mean* orphaning/adopting a package when the maintainer is no longer fulfilling their responsibilities. Why do we need two different terms defined as the exact same thing? In other words, if both salvaging and orphaning mean the same thing, then what's the point of salvaging? They don't mean the same thing. Maintainers orphan their own packages; adopters adopt orphaned (or RFAed) packages. Salvaging is the process of identifying packages that *should* be orphaned in the *absence* of the maintainer. We already orphan packages without the maintainer's consent, and it's already called orphaning. Salvaging is still undefined; until we come to consensus on its definition. Some vague notion of the idea was started at debconf, and we should be willing to be open to discussing the best definition that achieves the most optimum result. If we limit the scope of our thinking, then we box ourselves into a much smaller and likely less optimum set of solutions. So let's keep the term's definition open for debate. In my opinion salvaging (under the above definition) is something that would be able to happen a lot sooner than orphaning because it is initial a co-mainainter process, rather than a maintainer replacement process. Comaintenance is irrelevant to the question at hand. Again, co-maintenance is a proposed solution to the question at hand, so it is quite apropos to the discussion. There is now vast evidence within the archive that co-maintained packages tend to be much healthier than strongly maintained ones. This adds an additional avenue for becoming a co-maintainer while injecting health into often neglected parts of the archive. Wrapping up, I'd like to state my concern about how we continue to allow a certain culture of strong voices to effectively limit the scope of discussions. This isn't how a meritocracy should work. I've developed a solution, shown that it works, and now I would like to document it to make it available to help others as a guide in similar situations. Criticism from those that haven't demonstrated their own solutions should fail in a real meritocracy. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MN+uaGrAsSvPjs5bMt_ty4FBr=fsh+6++03jo-wnrr...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote: We already orphan packages without the maintainer's consent, and it's already called orphaning. Salvaging is still undefined No, it is not. The definition was clear from the first use of the term. Stop trying to redefine it. So let's keep the term's definition open for debate. Or, find something useful to do with yourself instead. -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
suggestion
When will there be in debian installer for Debian and wubi as Ubuntu? Attentively Ricardo Obando, from Chile.
Re: suggestion
Take a look: http://goodbye-microsoft.com/ Cheers! On Fri, Oct 26, 2012 at 7:29 PM, Ricardo Obando ricardo.kyu...@hotmail.comwrote: When will there be in debian installer for Debian and wubi as Ubuntu? Attentively Ricardo Obando, from Chile. -- William Vera | bi...@billy.mx Systems Engineer / Consultant IT / Sysadmin PGP Key: 1024D/F5CC22A4 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 8:19 PM, Steve Langasek wrote: On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote: We already orphan packages without the maintainer's consent, and it's already called orphaning. Salvaging is still undefined No, it is not. The definition was clear from the first use of the term. Stop trying to redefine it. So let's keep the term's definition open for debate. Or, find something useful to do with yourself instead. This is an unkind insult. I am defending my dissertation on Monday, so I have more than enough to do right now. That's something quite important to me, and I am taking time away from that to make a passionate case for something else that I believe in. I've also spent a reasonable amount of time on Debian over the past few weeks, but I prefer humility, so I won't drone on about that. Anyway, deployment of an abusive ad hominem is generally seen as a concession of the argument to the opposing side of the discussion, so I think that puts a rather sour note and an end to this particularly unproductive sub-thread. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MM+SgEwoJ2frbt7N=6vpffkxrto84o8st822oxx3p-...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Hi Zack, On Tue, Oct 23, 2012 at 11:19:34PM +0200, Stefano Zacchiroli wrote: On Tue, Oct 23, 2012 at 05:19:37PM +, Sune Vuorela wrote: 1) report a bug 'should this package be orphaned?' against the package with a more or less defalut templated text and a serious severity 2) sleep 4*7*24*3600 3) if bug silent, orphan it (and maybe adopt it) According to the interpretation I suggested in [1], this is actually the degenerate case of the proposal that is being discusses. If no-one ACKs --- which IMHO is what would happen by default anyhow in quite a number of cases --- and if the interested person chooses to sleep 4*7*24*3600, your point (3) will be the natural conclusion. [1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html Otherwise stated, the proposal is *exactly* what you're proposing, plus some consensus-based best practice to deal with the missing else branch of your point (3). I'm convinced that else branch will be quite uncommon (unless mandated, see below), and that ACKs/NACKs are just a different way of putting what already happens when we discuss on a mailing list the salvation of a package. But you could either have the unsupervised if branch, or what Steve suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html i.e. maintainers explicitly looking for ACKs to support their action as a requirement to complete the procedure. It has its merits (e.g. a surefire extra review layer). But if you consider ACKs as votes, as Scott put it, and you see that as bad, you won't accept this. So, can people comment on Steve's proposal? Similarly, Steve: can you comment on the criticism of voting on packages, why don't you see it as a problem? Voting implies that the majority rules. I am certainly not in favor of any sort of voting mechanism where we tally those in favor and those against orphaning the package. The standard I expect to see applied here is *consensus*, not voting. A lone voice in the wilderness, with no one saying either yay or nay, is not a consensus. 20 DDs saying the package should be orphaned, and the maintainer saying it shouldn't (or some other DD saying it shouldn't), is not a consensus. We should not need a heavyweight process here at all. It seems that some of the participants in this discussion are unaware that some of us are subscribed to debian-qa specifically *for* dealing with questions of unmaintained packages (MIA, salvaging, or coordination of QA uploads). The only real requirements for such a process are: - Make an appropriate effort to notify the maintainer of your concern - Make the rest of Debian aware of your plans in the designated public forum - Get some (small) number of your peers to agree via public review that this is the correct course of action for the package in question - Wait a reasonable amount of time for objections - If consensus is not reached, refer to the TC And if my frustration is showing through in this thread, it's because *I am not proposing a new process*. This was the process that was used for *years* via debian-qa. But, evidently because this process was never adequately codified in the developer's reference, here we are now having a long, drawn-out discussion not only about reinventing the wheel but also about what we should define a wheel to be, and entertaining solutions in search of a problem from people who have never used that existing and proven process. It is not going to be hard to get the necessary handful of acks when following an appropriate process, nor is it hard to wait a fixed period to give time for any nacks to arrive before taking action on a package to be salvaged. A package salvage is NOT an urgent matter, ever. Urgent matters should be dealt with by NMU. Salvaging is for longer-term questions of maintainership, and where maintainership is concerned we should be duly respectful of the existing maintainer's committment to Debian instead of enacting a buggy process that allows for a maintainer to come back from a vacation/hospital stay/computer outage to find her package has been rewritten without so much as a thank you. If you really intend to commit to maintaining the package for the foreseeable future, you can bloody well sit on your hands for a month and wait for the maintainer to react first. So in sum, I'm broadly in favor of Lucas's patch, except: - A single nack is evidence of a lack of consensus. If consensus can't be achieved, it should be referred to the TC instead of making a political mess of things for the rest of the project. - There does need to be a mandatory minimum waiting period. This process is going to be seen as blessed via the devref; we should not be blessing a process with an obvious bug that permits abuse by a DD and three of her friends pulling off a hostile takeover of a package before anybody has a chance to say no. Even though such an act *can* be appealed to the TC, we
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 09:58:54PM +0100, Ben Hutchings wrote: On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote: [...] All the pings in the world won't help if you are sending them via a path that discards them. I know several large US ISPs that automatically reject what they consider SPAM without the customer's knowledge. If the sender of the ping is on a SPAM list for one of them, the ping will never get to the maintainer, and *no one* will know. (From personal experience I can tell you mail from the Debian list addresses does get caught in these SPAM filters and no, the ISPs won't change the policy.) Given that Debian lists are 'open' and haven't always had good spam filtering, it is not too surprising that they are sometimes treated as spam sources. In general, anything that needs to reach the maintainer(s) of a specific package should not be sent to the maintainer address, not to some general mailing list. (The maintainer address may itself be a mailing list, but if the maintainer(s) no longer read mail sent to it then that's a further reason to orphan/salvage the package!) I strongly recommend that such mails always be sent via the BTS. This ensures that the mail follows the same path as bug mail, and avoids getting tripped up on filtering bugs that don't actually impact the maintainers ability to carry out their responsibilities as maintainer. I.e.: maintainers don't have a responsibility to reply to private mails. They do have a responsibility to act on bug reports. So if you send it via the BTS, and the maintainer claims afterwards that they didn't receive the mail, it's clear where the responsibility lies. -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote: On 10/25/2012 02:48 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote: I remember when I started a thread about 6 months ago, willing to take over maintainership of a clearly unmaintained package (since then, all other packages of this maintainer have been orphaned...). It (unwillingly) created a huge thread about when and when not taking over a maintainer, with some of the thread participant having no clue what so ever if the old maintainer was still alive or not. Do you also remember WHY it created a huge thread? It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS ASSENT. What? Could you explain what I did? Silence from who? The old maintainer? Other DDs reading the list? So, if nobody objects within the next following 2 or 3 days, and if Jack doesn't show up and oppose to this procedure, we'll do that. https://lists.debian.org/debian-devel/2012/05/msg01362.html That's equating silence with assent. Perhaps that wasn't what you intended, but that is what you said, and that was a factor in the resulting blow-up. -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote: So in sum, I'm broadly in favor of Lucas's patch, except: - A single nack is evidence of a lack of consensus. If consensus can't be achieved, it should be referred to the TC instead of making a political mess of things for the rest of the project. I fully agree with that. - There does need to be a mandatory minimum waiting period. This process is going to be seen as blessed via the devref; we should not be blessing a process with an obvious bug that permits abuse by a DD and three of her friends pulling off a hostile takeover of a package before anybody has a chance to say no. Even though such an act *can* be appealed to the TC, we shouldn't put ourselves in the situation that it has to be. I won't object to adding a mandatory minimum waiting period, although in some obvious cases it will lead to a pointless delay. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121027041826.ga5...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek wrote: On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote: On 10/25/2012 02:48 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote: I remember when I started a thread about 6 months ago, willing to take over maintainership of a clearly unmaintained package (since then, all other packages of this maintainer have been orphaned...). It (unwillingly) created a huge thread about when and when not taking over a maintainer, with some of the thread participant having no clue what so ever if the old maintainer was still alive or not. Do you also remember WHY it created a huge thread? It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS ASSENT. This claim seems to be false. What? Could you explain what I did? Silence from who? The old maintainer? Other DDs reading the list? So, if nobody objects within the next following 2 or 3 days, and if Jack doesn't show up and oppose to this procedure, we'll do that. https://lists.debian.org/debian-devel/2012/05/msg01362.html That's equating silence with assent. Perhaps that wasn't what you intended, but that is what you said, and that was a factor in the resulting blow-up. The mail also talked about we and us (eg: the PKG-PHP Pear team). That implies he already had the support of someone else, and they could have sent ACKs if needed (but there was no need to, as he wanted to know whether anyone opposed; the number of me toos didn't matter). None of the mails starting the discussion questioned whether the number of people in favor was sufficient. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1351312739.10719.19.camel@glyph.nonexistent.invalid
Accepted xpra 0.7.1+dfsg-1~exp0 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 24 Oct 2012 10:54:25 +1100 Source: xpra Binary: xpra python-wimpiggy Architecture: source amd64 Version: 0.7.1+dfsg-1~exp0 Distribution: experimental Urgency: low Maintainer: Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org Changed-By: Dmitry Smirnov only...@member.fsf.org Description: python-wimpiggy - library for writing window managers, using GTK+ xpra - tool to detach/reattach running X programs Changes: xpra (0.7.1+dfsg-1~exp0) experimental; urgency=low . * New upstream release. Checksums-Sha1: 451286790d041c5deb8ce66b471134723c5d42b2 2313 xpra_0.7.1+dfsg-1~exp0.dsc 52db8d2890160f387287d5c4f02b944a1983bb86 431808 xpra_0.7.1+dfsg.orig.tar.xz 480177a5bacb6011831266e1e87f91e28d0f5650 12300 xpra_0.7.1+dfsg-1~exp0.debian.tar.xz 80932e32f151fbea843c040adedb393b2e67 237576 xpra_0.7.1+dfsg-1~exp0_amd64.deb 2ddeeb9874d748c7acea3b95241f213a51ef0789 177190 python-wimpiggy_0.7.1+dfsg-1~exp0_amd64.deb Checksums-Sha256: 65f8ad159578ed3d4f45e2e6fcaaa7aec28d8369f1035b7a632ebb4fa18c5b89 2313 xpra_0.7.1+dfsg-1~exp0.dsc 1a328f1ae2ca1b48ff25efcd7d6b2c9d7306e9ce7cc4f37de8df1c166c8df9c1 431808 xpra_0.7.1+dfsg.orig.tar.xz e758adc6026e21e635737b3277f8d34114b8b48011fb42f33507d87a6891f4b7 12300 xpra_0.7.1+dfsg-1~exp0.debian.tar.xz e90c40535daa41d5104b721a2675e9ba0e2d11f3af055c8767ae9e52a8e92fbe 237576 xpra_0.7.1+dfsg-1~exp0_amd64.deb 9585954cc2e5df3e663b2c109d50467f2cae073dd1e46e19d305d7f760395dc8 177190 python-wimpiggy_0.7.1+dfsg-1~exp0_amd64.deb Files: cf6838027f57f87baaa497e3be924b0a 2313 x11 optional xpra_0.7.1+dfsg-1~exp0.dsc a2d2abc2bd96da05081bc9a4b24fcda5 431808 x11 optional xpra_0.7.1+dfsg.orig.tar.xz dc3888de4941e74079e4a18f65398676 12300 x11 optional xpra_0.7.1+dfsg-1~exp0.debian.tar.xz a6dbca8ea591e11792efe4f59aa66086 237576 x11 optional xpra_0.7.1+dfsg-1~exp0_amd64.deb 122ad019a975bd45f51c7eda33614a10 177190 python optional python-wimpiggy_0.7.1+dfsg-1~exp0_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQhzYCAAoJEFK2u9lTlo0b00AP/jHYD4X7osD0wIiMMUOOpdww 1AQAiwmBDx1tPHoxkSFz9gOAgji1CXNKSZWUbsDY8AplauIMpwNR0PnQOZ7Rsh3E VnIMdQd66uYDRFncEc/95EDJ7seAroQX71U205drTmBJM0T+ypydhrU2rFDqCV4D 7fsOkv0M+A1TCxFpIMsPOL1usrw6s+qQwo/6QRfgtlrcCczzzZ0Bh67ZeLBR2voH bkhrhrmV3OHrnzYMnk1rVW3mr6LoMDK8viH5kM6y7zw+iFHvqWC3nhgipCnS8zaC VHnR2nEeH3nG/ryUGPGwnvYZ8ZI5CxdHZbRADFE9Tz6GpFHbPlr/M6ILL0Uxoe60 aFGxqiLyIDQjfHeyzxWDdGLc3VtEn7AgmyT+Al8GRgMVZxWoJKS9Xpp4vs79FNwI E+ijP/MvbdfyQ89RBRsrBiXoDvEqIGZN9s2cxgyWODZ7T3TjsRc9mwoYKxLKEf3n ppx6hJLOuKuYJIEXYN3NPtG8HcPR6tMuZgiu4S/0WnsGUjiLb3WPFNE/Voof6mJS sMHVnuv6TRaCDGLaDgnJGNyTz0pBoxEwqSNz7coSQ/IXAWmHAkzuAfJzA5ls9Rm6 3VhD8IRdmU/uBnC2QBp00xRkunwgx4nVcPOuj+hF78LErmKvqHLa24DUQ2D4hG8g WsWEPKCjOIiiRjZuagvo =FAMd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trdi1-0004rl...@franck.debian.org
Accepted ettercap 1:0.7.5-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 08:44:51 +0100 Source: ettercap Binary: ettercap-common ettercap-text-only ettercap-graphical Architecture: source amd64 Version: 1:0.7.5-2 Distribution: unstable Urgency: low Maintainer: Barak A. Pearlmutter b...@debian.org Changed-By: Barak A. Pearlmutter b...@debian.org Description: ettercap-common - Multipurpose sniffer/interceptor/logger for switched LAN ettercap-graphical - Ettercap GUI-enabled executable ettercap-text-only - Ettercap console-mode executable Changes: ettercap (1:0.7.5-2) unstable; urgency=low . * build dependency on ghostscript for ps2pdf, used by cmake scripts to convert man pages to pdf; not included in the Debian packages. Checksums-Sha1: f29d0511fed7a20df802a6fa2b23fb1f8565e5f9 1602 ettercap_0.7.5-2.dsc e838977e7760f83d7aa3c769fb96cbb658e7786f 30604 ettercap_0.7.5-2.debian.tar.gz 6a7c6af4ae39b0b7a92c6075bdf053cc76a17d3f 393176 ettercap-common_0.7.5-2_amd64.deb 75be02af9945b6f6279c96c4db34269adcfb74d7 183188 ettercap-text-only_0.7.5-2_amd64.deb 93e1a8d90c098d51db94476bce7986cb2bda3a88 235892 ettercap-graphical_0.7.5-2_amd64.deb Checksums-Sha256: 141946c78aedacd57eb1f100e6baec9a20523507902ac92da90feaa8f9129059 1602 ettercap_0.7.5-2.dsc eebc9160d1eeab42e6c28dc5c21589f797430d9bb8a2fd1bdabd2e42c904e7e5 30604 ettercap_0.7.5-2.debian.tar.gz 0550876f09d74bbe933575f404d0e5ad6afbda95d97c27c07328c4cda9053c01 393176 ettercap-common_0.7.5-2_amd64.deb 6914a8cbf747750c442a52bef77a6f8892cc97c50ea8afdc05af0ab40186a7ac 183188 ettercap-text-only_0.7.5-2_amd64.deb 88aee6d617980aeea6d1a885cc7b99cade864dbab0e3133cf3a9b068a7e4f87a 235892 ettercap-graphical_0.7.5-2_amd64.deb Files: bc716322e78e5a2b3981c4efd158ba6e 1602 net optional ettercap_0.7.5-2.dsc cef28de72f59a640dec805f86222f5c0 30604 net optional ettercap_0.7.5-2.debian.tar.gz d827c72037c3393a9cb197b0b65956fb 393176 net optional ettercap-common_0.7.5-2_amd64.deb 65f9a628eba18ff0c09c9591898070d5 183188 net optional ettercap-text-only_0.7.5-2_amd64.deb 61041de7a3e0b6dc65e691bf93da8cad 235892 net optional ettercap-graphical_0.7.5-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCKQBUACgkQLz4Gnv7CP7K4YwCeOmHMVvq9isRw+RbtKN0hXihM QF8An344Sg/YAjMkEKAvsvcZNZsSTdd6 =bwgN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trfzp-0001aa...@franck.debian.org
Accepted exim4 4.80-5.1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 25 Oct 2012 20:11:11 +0200 Source: exim4 Binary: exim4-base exim4-config exim4-daemon-light exim4 exim4-daemon-heavy exim4-daemon-custom eximon4 exim4-dbg exim4-daemon-light-dbg exim4-daemon-heavy-dbg exim4-daemon-custom-dbg exim4-dev Architecture: source amd64 all Version: 4.80-5.1 Distribution: unstable Urgency: high Maintainer: Exim4 Maintainers pkg-exim4-maintain...@lists.alioth.debian.org Changed-By: Nico Golde n...@debian.org Description: exim4 - metapackage to ease Exim MTA (v4) installation exim4-base - support files for all Exim MTA (v4) packages exim4-config - configuration for the Exim MTA (v4) exim4-daemon-custom - custom Exim MTA (v4) daemon with locally set features exim4-daemon-custom-dbg - debugging symbols for the Exim MTA (v4) packages exim4-daemon-heavy - Exim MTA (v4) daemon with extended features, including exiscan-ac exim4-daemon-heavy-dbg - debugging symbols for the Exim MTA heavy daemon exim4-daemon-light - lightweight Exim MTA (v4) daemon exim4-daemon-light-dbg - debugging symbols for the Exim MTA light daemon exim4-dbg - debugging symbols for the Exim MTA (utilities) exim4-dev - header files for the Exim MTA (v4) packages eximon4- monitor application for the Exim MTA (v4) (X11 interface) Changes: exim4 (4.80-5.1) unstable; urgency=high . * Non-maintainer upload by the Security Team. * CVE-2012-5671: Fix heap-based buffer overflow in DKIM handling. Checksums-Sha1: 8de896a104c94c100ba92f8c9bb0700cb33c5fb1 2160 exim4_4.80-5.1.dsc 597b39c222862df2f1540c9347cb8fa7f8621a0a 578843 exim4_4.80-5.1.debian.tar.gz 322bd7fd9519815e272ef8448bdfff73d534991f 1040124 exim4-base_4.80-5.1_amd64.deb fad7d6b50b993b807d1bec659fa775a81e125079 211942 eximon4_4.80-5.1_amd64.deb 8d376b593bc897c484726d1873af0fa970e3f27d 655394 exim4-daemon-light_4.80-5.1_amd64.deb 68c42dc9cb990223d6f1c5056156541e8f628ee9 715300 exim4-daemon-heavy_4.80-5.1_amd64.deb d50dd5b3d284ec7af18ae7fc292865163b8153b7 1246150 exim4-daemon-light-dbg_4.80-5.1_amd64.deb 1c2bf5700b8067e3b97135d24e63ee7ee0346347 1397360 exim4-daemon-heavy-dbg_4.80-5.1_amd64.deb 4f81e1dec180daad6d553547ff2a6151425a0256 451166 exim4-dbg_4.80-5.1_amd64.deb 14343c798ee7907665471f07407118c402a9c595 173628 exim4-dev_4.80-5.1_amd64.deb 3a6c77ff81dc71ba0d8d0fc45fed2bfddf3cbacf 477464 exim4-config_4.80-5.1_all.deb 963eb92d051f31d44158ad5dadff8fd4bd14f8ad 7782 exim4_4.80-5.1_all.deb Checksums-Sha256: a7267232534c09399e1536eb1bc57f5e49e9f14b05d03f803be14e27c46f87c6 2160 exim4_4.80-5.1.dsc 786f5ca03eb615aa38a927cbda2de8fd3250db465180cc16f1ab9a6df53ef354 578843 exim4_4.80-5.1.debian.tar.gz 6efb35917b3c00713ea5cbdd4e98706c99f833e6ce3016214f6cdf53fc74aa2d 1040124 exim4-base_4.80-5.1_amd64.deb bbca8753d8b7a8ea18adfd7b583b1723156924f20ef3b5ddcf2c3a5f46e76bf7 211942 eximon4_4.80-5.1_amd64.deb 97f86e4bc79f8daa33d904d82c30ca40d2e2125b286e8f242c88f243934ff33c 655394 exim4-daemon-light_4.80-5.1_amd64.deb cea5ed9a36a809a1db0870947c7a0546bfda59296440197b6ec6268a0b271a93 715300 exim4-daemon-heavy_4.80-5.1_amd64.deb 12d5e48488d546e5bca1bc3f42aa332965fceda900cef8668a6fd626af42567b 1246150 exim4-daemon-light-dbg_4.80-5.1_amd64.deb 9257d0fafc8df3f0a7e3f1973c5d8d133b7d66ebad08a51a8c1179a2f4a1f85e 1397360 exim4-daemon-heavy-dbg_4.80-5.1_amd64.deb 52fc67217c966a5c6af93396e1c3230f758357860f1d6b2806d259553b7f8561 451166 exim4-dbg_4.80-5.1_amd64.deb 51891b57e3be86505d7b979f23a15e25f05f312095bcbbcabb43d9d29aeb7b5f 173628 exim4-dev_4.80-5.1_amd64.deb 9cc0e0b1c6216fc1ab5af60fefe498af785023c534c697cf85dd5b9b45af50ba 477464 exim4-config_4.80-5.1_all.deb 0580e3857e65e3785c59a3dfc29c3f19b473ddfb5f1e9b00b35bd6ff7f8a1e49 7782 exim4_4.80-5.1_all.deb Files: 57b9b669a1f72986f00cf44fd1cfd615 2160 mail standard exim4_4.80-5.1.dsc 0b87e83f1d95fe02841e98c240698c50 578843 mail standard exim4_4.80-5.1.debian.tar.gz dedc4c9579b68fddd1c0ec8d8ca0c85b 1040124 mail standard exim4-base_4.80-5.1_amd64.deb 46ae32ac9383ef1bf010ce5182c6c804 211942 mail optional eximon4_4.80-5.1_amd64.deb e3aec4280643d2dcf30371134bb516a3 655394 mail standard exim4-daemon-light_4.80-5.1_amd64.deb 6ecbfc85b69439a45d7cdcf1dfeffdbf 715300 mail optional exim4-daemon-heavy_4.80-5.1_amd64.deb d24e150f01dab595bc7d7fee60e3bbe1 1246150 debug extra exim4-daemon-light-dbg_4.80-5.1_amd64.deb b64368a0bb37d6e27328da383405c1d5 1397360 debug extra exim4-daemon-heavy-dbg_4.80-5.1_amd64.deb 71b87448049ff139e15962190e56527f 451166 debug extra exim4-dbg_4.80-5.1_amd64.deb 125c481fa3dfcedb1f63880eaa092a20 173628 mail extra exim4-dev_4.80-5.1_amd64.deb 8daf4244867312022ac93aaba7cf24a4 477464 mail standard exim4-config_4.80-5.1_all.deb ed300663df80aad3ec7bdf5499da6981 7782 mail standard exim4_4.80-5.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCJgjcACgkQHYflSXNkfP9AXwCgk5AFWBjQU7d9pU/RsNAN+hXW tgIAn0h+XEXEFMx3OkbetRKYEu8qWQ8q =Q+CH -END PGP
Accepted flvmeta 1.1.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 02 Oct 2012 14:32:00 +0700 Source: flvmeta Binary: flvmeta Architecture: source amd64 Version: 1.1.0-1 Distribution: experimental Urgency: low Maintainer: Neutron Soutmun neo.neut...@gmail.com Changed-By: Neutron Soutmun neo.neut...@gmail.com Description: flvmeta- Metadata injector for FLV video files Changes: flvmeta (1.1.0-1) experimental; urgency=low . * Imported Upstream version 1.1.0 * Upstream change main development repository to github * debian/control, debian/copyright: - Update Homepage, Source, to flvmeta github repository. * debian/watch: - Watching the tarball release via githubredir.d.n * debian/copyright: - Update the copyright format to 1.0, no changes needed. * Switch to cmake build system * debian/compat: Bump compat level to 9. * debian/control: - Bump Standards-Version to 3.9.4, no changes needed. - Drop autotools-dev, check, dh-autoreconf, pkg-config from build-deps as they are no longer needed by the cmake build system. - Add cmake to build-deps. * debian/rules: - Force to use cmake build system as it was requested from upstream. (Upstream has a plan to discontinue support autotools build system) * debian/patches/90-cmake-use-system-libyaml.patch: Add patch. * Use upstream manpage * debian/control: - Add pandoc to build-deps. * debian/manpages, debian/flvmeta.1: - Drop, superseded by upstream autogenerated manpage by pandoc * Install README.md * Add patch to fix spelling error in manpage * debian/patches/99-fix-spelling-error-in-manpage.patch: - Fix spelling error in manpage Checksums-Sha1: b490983093f6fffd3df52e1d627fc8cfa8fdb401 1853 flvmeta_1.1.0-1.dsc a76088371500b3d17063754979185c6faefdeeb7 138139 flvmeta_1.1.0.orig.tar.gz bb53e69c5392d39fef0e805f54755bcfce464f09 4141 flvmeta_1.1.0-1.debian.tar.gz 07f5fecae991b59203bd69500de183dcf420d056 52210 flvmeta_1.1.0-1_amd64.deb Checksums-Sha256: daa3f513ff31157281891f27337e8c976412a29d251770c2463301d1202d96d9 1853 flvmeta_1.1.0-1.dsc 55bcb9d7be7a40984428d2bb43b4e4e4289306653640424db60ddc5016683fff 138139 flvmeta_1.1.0.orig.tar.gz 15af533cd96c51bbc991c6dfa09359c791ff490eb02c6f31bfe8e61370e4d63d 4141 flvmeta_1.1.0-1.debian.tar.gz 7040f9defa4895802683cdfcb96c261e1e5f5eedcf8d0ed22443526d778d73b1 52210 flvmeta_1.1.0-1_amd64.deb Files: ea366898cfaea8e03a5fe16c31969eb3 1853 video extra flvmeta_1.1.0-1.dsc 6e5ed56cab8bd50330939e0763a6964e 138139 video extra flvmeta_1.1.0.orig.tar.gz be3d41660382058f2ec6fdb16c66b795 4141 video extra flvmeta_1.1.0-1.debian.tar.gz cc7ddeb31be7ecbe13c6185d114ef4a9 52210 video extra flvmeta_1.1.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQij5pAAoJEKLrrtG2+QJBI7QP+wUhzoe9Cwfa9vmUm+t6x6Ft fHdpClGgpzY8LjjuH4pUWCY/lPpnK/i22OqHbtXRmGYHtVsDTTYJo8arJdFOVXua di5QdNDOBdHEOpAzKvNz3BYM8UQZYfSBwybn75NiACdvopHLlb5ix7EiGIkf02kw /p+m7M67AqUEDYJ58zGxKAKK140BsABiRpCZutTsTYpPqy99sOrCxaZoglyJowYL 1ag14lw8+xhmviJj5TCewkocAdQYOeoDyNZgf89eNDDlanuqG9960rx05v8ugkNH uEY1JwzH4cqQ6jR+i5f2DVASypclvKIsSMhlkiE/Y4H3E2wXuHHGAd+FkC3ZR42p 3d5BmY43HoG8pFvLPe8sls21Davzry/t7qcUR3DWTivAh/XdXX9gQtcPmFaU5zoP 1uH1fiy5g29I6qYke7v3oIOHJo01OzUR6xtcfNhAsURS3RDFeidOwkbXoqW2u8HS RycqstaKSbfqYyz2IPCeGabDDDBKy6sPbtD4ntcwkigTsEpyh4isGZYlmAXMpjQu cZsmTPMr8XrgZWS6Wl2fxe66esf74YIchdV+C7aDDm0UXOq2qNILdX8UYCD910qK +LtdNiGxSLHQjLzme+X3pq7zfJs851VfMubEqc8U9SdbBgFgwJISaAd0+oRBqzXd QwR4cOQxo9+18w21ui15 =ZXYO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trfay-0001fu...@franck.debian.org
Accepted nvidia-settings 304.60-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 10:09:56 +0200 Source: nvidia-settings Binary: nvidia-settings libxnvctrl0 libxnvctrl-dev Architecture: source amd64 Version: 304.60-1 Distribution: unstable Urgency: low Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org Changed-By: Andreas Beckmann deb...@abeckmann.de Description: libxnvctrl-dev - NV-CONTROL X extension (development files) libxnvctrl0 - NV-CONTROL X extension (runtime library) nvidia-settings - Tool for configuring the NVIDIA graphics driver Changes: nvidia-settings (304.60-1) unstable; urgency=low . * New upstream release 304.60. - Updated nvidia-settings to report Dedicated GPU Memory (i.e., the memory dedicated exclusively to the GPU) and Total GPU Memory (i.e., Dedicated GPU Memory plus any TurboCache(TM)-accessible system memory) separately on the GPU information page. - Added reporting of the current utilization of Dedicated GPU Memory to the GPU information page of nvidia-settings. * New upstream release 304.51. - Fixed a bug that sometimes caused the display layout area of the nvidia-settings control panel to be laid out incorrectly. Checksums-Sha1: 3f1522a0577a56db88a090b8b6b1a1208fbe0cbe 2347 nvidia-settings_304.60-1.dsc 658fbca094e0e44701335d89a5f2d684275c449f 1479772 nvidia-settings_304.60.orig.tar.bz2 1ed940886ed21899d8705dcce1fae32d65910298 14995 nvidia-settings_304.60-1.debian.tar.gz 58b0b90d72da47f2ffe61f3be9dbd75f3ecb7800 830610 nvidia-settings_304.60-1_amd64.deb 39c01c7ce51ada9b51164677899ea976db3abb89 16580 libxnvctrl0_304.60-1_amd64.deb 5451b01dbdcfa470efb23597778176e66e444f53 95100 libxnvctrl-dev_304.60-1_amd64.deb Checksums-Sha256: 5caa0ad23744555e0d6e46d25565efd4b6294403ea52b7c2e999a4aa26d34584 2347 nvidia-settings_304.60-1.dsc 96f0f984d2d4e37c3e492476c3506283f5666d952ae94ddc79d7e16b047a9b36 1479772 nvidia-settings_304.60.orig.tar.bz2 202123502247e62605a45530a429d06bb3f2c17c2f4b5ddc785791ae81a25bc0 14995 nvidia-settings_304.60-1.debian.tar.gz 7ad34e78c255a82dcb177365bb917e667bb87f7e342bd63c7dc7d898626593b3 830610 nvidia-settings_304.60-1_amd64.deb d317efbc1321564a7e936e6aa94da5d3a98126fb4ffbaf54f042116d72a06f18 16580 libxnvctrl0_304.60-1_amd64.deb d0bddff2c3bca7c523e335ff62fe560159b94b8fd28b98df4a3122bede4a328b 95100 libxnvctrl-dev_304.60-1_amd64.deb Files: 917021d040ad19b95b056df17be89ac8 2347 contrib/x11 optional nvidia-settings_304.60-1.dsc de3692394b3038696004dbf5d741c55b 1479772 contrib/x11 optional nvidia-settings_304.60.orig.tar.bz2 0fefde8788672d9f5021fe0b0981c6f8 14995 contrib/x11 optional nvidia-settings_304.60-1.debian.tar.gz 879252e4a5905a56bbcf15cddcc80033 830610 contrib/x11 optional nvidia-settings_304.60-1_amd64.deb 80eacd1a2c4f394354304e642f62c858 16580 contrib/libs optional libxnvctrl0_304.60-1_amd64.deb 09dc59b284a8bb2d215253990fc7dbf6 95100 contrib/libdevel optional libxnvctrl-dev_304.60-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQikagAAoJEF+zP5NZ6e0Izw0P/jFNdhBgOYjbLRTRn4FnYDog HtsFHb/kWs0g7hQIoj75V3pCmnDg2lM9g5Fozdu8LXKlguc1sEDl88CrEsctJ28x dNp5yuCCwtuuUN9o3ds9Amm5OQtpYbuZlIBBX0k8Mu+tJtsy+IKwDx3YCtm+I6M8 IF5LHm4QdsHto72IBZTQnpwnvhIk0eKR72sLVQM7BPm0OznFLa531xd9mKrsc0it FlXfi/z6j2n737Mn+9cu773rrCl/XWBbQdetzCFp0ON16WYihI9sjjwkoxHbXI54 fvo3+eoUBE1hOJ4RBOy1Csa42Q9xAoBWBWESg3/F3jUu1RID/vZwvHVzxG0kNxfT jbUAQLBG1fAmp7lN2Hb+GNEqD3rK8sFbg6Jf9Mhgs8XmaEzawDuxkwcoNjTU1xS5 LPX5d25Czr5GMzOyvNFMHrR2SAua1V5866xG4PAO8p7Uxbq7M5OtvmZoAjo3L+pz qIWsP2EtE4ZPE8B9ZNmJlBPKHfmXSJeJrybQNB+nUJt90m3+50gOfXC5BiJgiUCU z0wFvusurB0QK1E3TD48s0BogDoca8Cb0Swx1wQTv+iPX4aqUWRNtY1kTh83Qxxp ufVE4khiK65wPChWWxTwJ6TrK/vrSPkTwb/i3oi8RpUX7j0hfHieG1O7fnK53ux4 0u1JG+MLI6ZwM/FOquwg =oubS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trfb6-0001m3...@franck.debian.org
Accepted scite 3.2.3-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 24 Oct 2012 19:54:43 +0200 Source: scite Binary: scite Architecture: source amd64 Version: 3.2.3-1 Distribution: experimental Urgency: low Maintainer: Michael Vogt m...@debian.org Changed-By: Antonio Valentino antonio.valent...@tiscali.it Description: scite - Lightweight GTK-based Programming Editor Closes: 654959 683743 Changes: scite (3.2.3-1) experimental; urgency=low . * new upstream release (closes: #683743) * updated watch file * standard version bumped to 3.9.3 * buld against GTK3 instead of GTK2 (closes: #654959) * use gnomeprefix instead of prefix in override_dh_auto_install in oreder to allow correct installation of the desktop file * install scite manpage * drop disable_background_save.patch (applied upstream) Checksums-Sha1: 3a9a8f72a336c5ea83b491f308db82789c221307 1154 scite_3.2.3-1.dsc 63445e3fe8b0c2ec00a85923e097f987dcaa06d6 2053250 scite_3.2.3.orig.tar.gz 4cba9671ddf3d104ff55ef59d7408ae753733900 15677 scite_3.2.3-1.debian.tar.gz 99d1594994d1edc7e5baae740f8f375b22a6980a 1289018 scite_3.2.3-1_amd64.deb Checksums-Sha256: 298192c923d4de83e72b59af360308732cd0f8324cbd7119e97a178582368b23 1154 scite_3.2.3-1.dsc d0d324a5e420ff96db6cd1c6eeac23b6f4c046e7545e73c4625ab2add90e4a65 2053250 scite_3.2.3.orig.tar.gz 146bdefb5294a20db8a5e2f1b9a4a089906871a0f06dae160cc597345bc84d1a 15677 scite_3.2.3-1.debian.tar.gz 1c63c32e90b5040ab0b9baf293410786eac8ae4a4d7d8afea5393ea50266e2ec 1289018 scite_3.2.3-1_amd64.deb Files: 967f9c9523577512809ad87adcd1031f 1154 editors optional scite_3.2.3-1.dsc 1d02734ea2fcc3551ac62c5ae6a274b2 2053250 editors optional scite_3.2.3.orig.tar.gz 3595e325077930e8c7e06991d9db6ec8 15677 editors optional scite_3.2.3-1.debian.tar.gz 53205f18a7163749a75f60a2ffd61e28 1289018 editors optional scite_3.2.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCKQJAACgkQliSD4VZixzSeLwCgk11yr0AODdBtgJwLhM++ICOo lgAAmQGA63DZGtD7uUkMJMQ+waV4nVix =4fqU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trfen-0002ey...@franck.debian.org
Accepted netcfg 1.99 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 11:11:53 +0200 Source: netcfg Binary: netcfg netcfg-static Architecture: source amd64 Version: 1.99 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Philipp Kern pk...@debian.org Description: netcfg - Configure the network (udeb) netcfg-static - Configure a static network (udeb) Closes: 606636 690330 Changes: netcfg (1.99) unstable; urgency=low . [ Philipp Kern ] * netcfg.c (main): Remove a local definition of hostname. (Closes: #690330) * Override the hostname found via DHCP or DNS with the preseeded value of the new variable netcfg/hostname, if set. Patch by Floris Bos. (Closes: #606636) * Add myself to uploaders. . [ Updated translations ] * Amharic (am.po) by Tegegne Tefera * Asturian (ast.po) by Mikel González * Welsh (cy.po) by Dafydd Tomos * Esperanto (eo.po) by Felipe Castro * Spanish (es.po) by Javier Fernández-Sanguino * Galician (gl.po) by Jorge Barreiro * Kannada (kn.po) by Prabodh * Serbian (sr.po) by Karolina Kalic * Tamil (ta.po) by Dr.T.Vasudevan * Ukrainian (uk.po) by Yuri Chornoivan Checksums-Sha1: 55a47b7cd65096717206b9b39426bb7bc7783350 1518 netcfg_1.99.dsc 98d4e679c9b3480202ee1c127eda776e60e5eab3 748696 netcfg_1.99.tar.gz dca3eb05661026b41de4ef43f2e59bf053a64312 419386 netcfg_1.99_amd64.udeb b6881915852d035e4f58e66d175b72b958d96e85 329518 netcfg-static_1.99_amd64.udeb Checksums-Sha256: ae993da0a66add191dd2f9157fd8b63c2da89b7217b93d65357d304951d75789 1518 netcfg_1.99.dsc e0fdf2fb607ae7b2f7088fef0f25906aa709be01fd264af737e044f24ec14f56 748696 netcfg_1.99.tar.gz d9104607381ee49356dd5e66a9b69abcabd789b3de4c509063f0e426f0788178 419386 netcfg_1.99_amd64.udeb f2b12a51a0074a157686389ea754cb0afc613b77db55943de7ecfe03d0f17cdc 329518 netcfg-static_1.99_amd64.udeb Files: 29a58a7b9975d0dd1d2758cae1b019ee 1518 debian-installer optional netcfg_1.99.dsc 4d42fc6ce25d2d63699ba07c6c6e8e5e 748696 debian-installer optional netcfg_1.99.tar.gz 357b9cd2ab2bb8a0a4212005bc1b5086 419386 debian-installer optional netcfg_1.99_amd64.udeb 0ea55ac1779f938d04b13fc252638841 329518 debian-installer optional netcfg-static_1.99_amd64.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQilP5AAoJEERuJUU10FbsqccH/jasqQWvkAk8OvDScbhtLyB0 da+97levmxSP1qy5H6sIpmDDD5KOpamK/GjY38UeM8/o++fa1EoxPwHc+WG3CMiy hkX7urMRUP9YrwIq5loFcuWpy2Dv2ozldGMgn99dxZleivEjhUDrTLvr6kIl5PqZ sBxfyiQXSpOJTdPMLdET6ji+muLRCtNz5FT8ECtGgW2BJRFT1eCIIQZOtU6N6+g8 ktpdGSaEDiIK+IC3pmnv9D+Qw4MOxljvBEeRheh6nQv6EZdsEzAELj3mr3Jm9VhG RmuU7BxSpFQYLk/iq6YMGZNiRaXKSR6z+iiwJ4yUilUP1zTqFGAA1H62mLc2GM0= =3yDy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trg3b-0007cu...@franck.debian.org
Accepted php5 5.4.4-8 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 25 Oct 2012 13:23:08 +0200 Source: php5 Binary: php5 php5-common libapache2-mod-php5 libapache2-mod-php5filter php5-cgi php5-cli php5-fpm libphp5-embed php5-dev php5-dbg php-pear php5-curl php5-enchant php5-gd php5-gmp php5-imap php5-interbase php5-intl php5-ldap php5-mcrypt php5-mysql php5-mysqlnd php5-odbc php5-pgsql php5-pspell php5-recode php5-snmp php5-sqlite php5-sybase php5-tidy php5-xmlrpc php5-xsl Architecture: source amd64 all Version: 5.4.4-8 Distribution: unstable Urgency: low Maintainer: Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: libapache2-mod-php5 - server-side, HTML-embedded scripting language (Apache 2 module) libapache2-mod-php5filter - server-side, HTML-embedded scripting language (apache 2 filter mo libphp5-embed - HTML-embedded scripting language (Embedded SAPI library) php-pear - PEAR - PHP Extension and Application Repository php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-enchant - Enchant module for php5 php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) php5-gd- GD module for php5 php5-gmp - GMP module for php5 php5-imap - IMAP module for php5 php5-interbase - interbase/firebird module for php5 php5-intl - internationalisation module for php5 php5-ldap - LDAP module for php5 php5-mcrypt - MCrypt module for php5 php5-mysql - MySQL module for php5 php5-mysqlnd - MySQL module for php5 (Native Driver) php5-odbc - ODBC module for php5 php5-pgsql - PostgreSQL module for php5 php5-pspell - pspell module for php5 php5-recode - recode module for php5 php5-snmp - SNMP module for php5 php5-sqlite - SQLite module for php5 php5-sybase - Sybase / MS SQL Server module for php5 php5-tidy - tidy module for php5 php5-xmlrpc - XML-RPC module for php5 php5-xsl - XSL module for php5 Closes: 687031 690173 690413 Changes: php5 (5.4.4-8) unstable; urgency=low . * Remove IfModule to always interpret PHP if the module is enabled (Closes: #690413) * Fix extended DES crypt() when salt != 9 (Closes: #687031) * Fix libphp5-embed linking (Closes: #690173): + Expose all installed (and not built time) SAPIs via php-config --php-sapis + Add /usr/lib/php5 to php-config --ldflags output to allow linking with libphp5.so + Remove useless libtool file in libphp5-embed * Add new lintian-overrides for libphp5-embed Checksums-Sha1: 407552a2a48c87e337a844eff98dee8238e2b092 3706 php5_5.4.4-8.dsc 95f806fa8434703fac9cbef5dc4e187b0f3f1423 194801 php5_5.4.4-8.diff.gz e9f2f1d90204572a405b106e56ebccd583709152 586004 php5-common_5.4.4-8_amd64.deb 5e7cd2ddc4d208ca4115f3ec2327b84808eaad9d 2663970 libapache2-mod-php5_5.4.4-8_amd64.deb 007975c5093c1c622666d2a43e1b75e5d5d7d885 2662646 libapache2-mod-php5filter_5.4.4-8_amd64.deb 953dc62f7586a1593d7216833c13ff0161ff837b 5098328 php5-cgi_5.4.4-8_amd64.deb fbd69f0185b7bc1dfd2426952479aa332b4cd3af 2556514 php5-cli_5.4.4-8_amd64.deb 4f2bf4aabd33be401317b21538a6dcfa6f3ad90e 2588054 php5-fpm_5.4.4-8_amd64.deb cfb5bb0ea42a82c6b84206a546693281f945375d 2660914 libphp5-embed_5.4.4-8_amd64.deb a50d726bb647eb58aed44d351f3a54ec9541e166 497872 php5-dev_5.4.4-8_amd64.deb 09a4526c89af975038384f7af1af6c7fd7209aae 15955740 php5-dbg_5.4.4-8_amd64.deb f2e11b2e89f678b0afed6c77b5e25e269fff2d95 29074 php5-curl_5.4.4-8_amd64.deb 4e7e59f40895b419ad1f48fbf9cde6216de829c6 9918 php5-enchant_5.4.4-8_amd64.deb 45e1da3e3958e221263693e0348099762853d35f 35690 php5-gd_5.4.4-8_amd64.deb 83899554ac2d7f2a383478bd014b5016a81c3da7 17152 php5-gmp_5.4.4-8_amd64.deb 49515b1bd09f999f35fb1e913d44f00a1320377e 35594 php5-imap_5.4.4-8_amd64.deb d9be968fe01fb601bf290c3c104c6d090762c5ec 49588 php5-interbase_5.4.4-8_amd64.deb fa7db45127836deee6b4994c9ed1bdb46bbd2d65 71956 php5-intl_5.4.4-8_amd64.deb bb1319ce53fc16e78fdd1b0a6d66e20058ff91c6 21752 php5-ldap_5.4.4-8_amd64.deb 80ab31aa709b4a4ab83549084d971a62a5e0df94 16074 php5-mcrypt_5.4.4-8_amd64.deb 9534f317432e60a14f97afa53f6807810ebdf440 80852 php5-mysql_5.4.4-8_amd64.deb 0c7c6b24b1df0d2d1fcc0f318e779672809585eb 162366 php5-mysqlnd_5.4.4-8_amd64.deb 40d1cda1c09a086afc9db65b19b22e1048804e2a 36640 php5-odbc_5.4.4-8_amd64.deb 8128f9b23ef3677087d45dd5edad7200e327654d 61434 php5-pgsql_5.4.4-8_amd64.deb 6b1d86127a44529eb7130a46afa1fc484bb20745 php5-pspell_5.4.4-8_amd64.deb d2621c36ccddfd0ec4585780f81f625e577f2c10 5188 php5-recode_5.4.4-8_amd64.deb 8722a78dfab5a085a332fd4f72ece0c40c512fe0 21798 php5-snmp_5.4.4-8_amd64.deb
Accepted tor 0.2.3.24-rc-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 07:34:37 UTC Source: tor Binary: tor tor-dbg tor-geoipdb Architecture: source all amd64 Version: 0.2.3.24-rc-1 Distribution: unstable Urgency: high Maintainer: Peter Palfrader wea...@debian.org Changed-By: Peter Palfrader wea...@debian.org Description: tor- anonymizing overlay network for TCP tor-dbg- debugging symbols for Tor tor-geoipdb - GeoIP database for Tor Checksums-Sha1: df8508193c298689c6d9e16ee338829c9ae84166 1683 tor_0.2.3.24-rc-1.dsc c84b79a837e32e94aad31071b8c0cba5fde60b8f 3187711 tor_0.2.3.24-rc.orig.tar.gz 3468e78f62ebe13543431a5263cf3a96f4bacf90 34389 tor_0.2.3.24-rc-1.diff.gz 51397957ea4db28e5932393d90694a3c322c2f23 1450402 tor-geoipdb_0.2.3.24-rc-1_all.deb 384f2bb7d23eaab049a2f4a26c979bfb48138b13 1193886 tor_0.2.3.24-rc-1_amd64.deb 4a6977077ee4605a0d1e83c34a46d691d5e838ab 94722 tor-dbg_0.2.3.24-rc-1_amd64.deb Checksums-Sha256: ef98bf23c728c86ff6ab5f9641287f79998d638f1a0944d7c7a3720dce35050a 1683 tor_0.2.3.24-rc-1.dsc 6ac663f32e4d36e633672cafdd43d691d4e0b6f14a2344fe4e016cc3dbbd6019 3187711 tor_0.2.3.24-rc.orig.tar.gz 5b4cbf919358e66dfe20d9a6d99321b9522e41cc6f48452f91700384a74dfa40 34389 tor_0.2.3.24-rc-1.diff.gz 4796d67dd4ef035e3df10bfd8dd82f479d2c544b22f61405e0de9e28d0d7d13f 1450402 tor-geoipdb_0.2.3.24-rc-1_all.deb be45fe721d0b1dfd3f57d63177a7ab3f55bb030501dfc59b09985e2be029a06f 1193886 tor_0.2.3.24-rc-1_amd64.deb d5f29539aaff9eb5a84950bec1f7fed30c21ee4f65599fb41ee5e09abc099d25 94722 tor-dbg_0.2.3.24-rc-1_amd64.deb Changes: tor (0.2.3.24-rc-1) unstable; urgency=high . * New upstream version: - Fix a group of remotely triggerable assertion failures related to incorrect link protocol negotiation. Found, diagnosed, and fixed by some guy from France. Fix for CVE-2012-2250; bugfix on 0.2.3.6-alpha. - Fix a denial of service attack by which any directory authority could crash all the others, or by which a single v2 directory authority could crash everybody downloading v2 directory information. Fixes bug 7191; bugfix on 0.2.0.10-alpha. - and more. Files: fe0fd012a4c30d870aceee6e22271a59 1683 net optional tor_0.2.3.24-rc-1.dsc 6c46aee248eb72d954e3ba4ba53d5599 3187711 net optional tor_0.2.3.24-rc.orig.tar.gz 37bb28a9402b97514d46e3a912b591c3 34389 net optional tor_0.2.3.24-rc-1.diff.gz 9ec79c7d9e7175b7778749e8b639dc64 1450402 net extra tor-geoipdb_0.2.3.24-rc-1_all.deb 315dd899960e39e00ad9d2cde377b426 1193886 net optional tor_0.2.3.24-rc-1_amd64.deb d75000ae07391c8d4944eba1aced298b 94722 debug extra tor-dbg_0.2.3.24-rc-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJQilbfAAoJEDTSCgbh3sV3MzMIAIhTweBDDyhpSUMCqj/V4Jcy iwAV0mDp2wSGXu42kBW8nL6G9FIm0Sa/B8vlubRIv3RYhQRlsLGAa5ttP7mY/YbO OxR2Aso6TYFkjkLKiV850Ig+Cz6J9gFSHb589vaCHbKG9v7/zxy5e26qx6VGR+UD 35tRiTzNKapWUMsyhr5jfXKVKKH4DjdRKcMHoGykq4mzUHcgNjQGkSjX/+RmPuHh ekVw8R3WfN0esKJFmkI8+f620o8HybpkpCNO8h+ofpgUM9O5zN+y0l78FJQ4Zktv 571NXTouvYzik0NJxN9SM4zVJfHP9CwovUt2oObE4I/mcBD7r/aRNIBGQ3LBWXA= =oJ4A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trgjf-00069f...@franck.debian.org
Accepted tor 0.2.4.5-alpha-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 08:31:08 UTC Source: tor Binary: tor tor-dbg tor-geoipdb Architecture: source all amd64 Version: 0.2.4.5-alpha-1 Distribution: experimental Urgency: high Maintainer: Peter Palfrader wea...@debian.org Changed-By: Peter Palfrader wea...@debian.org Description: tor- anonymizing overlay network for TCP tor-dbg- debugging symbols for Tor tor-geoipdb - GeoIP database for Tor Checksums-Sha1: 4861fe505ed1052b63f77a89f15d10e78b9306f6 1697 tor_0.2.4.5-alpha-1.dsc f92c86baa3f825c214be8a4dedea1e53d455da00 3198310 tor_0.2.4.5-alpha.orig.tar.gz 7aa4e85b86ec43b1e60340a098f209abf9540896 34262 tor_0.2.4.5-alpha-1.diff.gz 71847dfeb9083c512b9e2b0f52098dae84090fc7 1455672 tor-geoipdb_0.2.4.5-alpha-1_all.deb d0285028ce500c6bcb0f11e8a77592ccbe922341 1261988 tor_0.2.4.5-alpha-1_amd64.deb d3ea6f0a680dfd0af529aa4e2ba03035cd31d0c6 102268 tor-dbg_0.2.4.5-alpha-1_amd64.deb Checksums-Sha256: 6a720e535679ba88dc6eb3c87dbac46810ce68807f393e5e35d6728e4d21d557 1697 tor_0.2.4.5-alpha-1.dsc 1b4399b8ee036849b5837253696dde90d8ba17bd3596905a47d3e7b07cb8ca7e 3198310 tor_0.2.4.5-alpha.orig.tar.gz f534e2e2cd5241ce233b9a9afc911bf05bd1a84ceb521a650eba57b01651b670 34262 tor_0.2.4.5-alpha-1.diff.gz 352cbd87a2db68f793244f624d7d467a3e81e264fef2c8e68bc263c721341231 1455672 tor-geoipdb_0.2.4.5-alpha-1_all.deb 6d7a7a644422202f1585b8600ba57176c32ac45188f04eb1611f4c9155e47067 1261988 tor_0.2.4.5-alpha-1_amd64.deb ca21d0572912ceb95256e0ce160d094924b3ef00557cb4acb31618606750c009 102268 tor-dbg_0.2.4.5-alpha-1_amd64.deb Changes: tor (0.2.4.5-alpha-1) experimental; urgency=high . * New upstream version: - Fix a group of remotely triggerable assertion failures related to incorrect link protocol negotiation. Found, diagnosed, and fixed by some guy from France. Fix for CVE-2012-2250; bugfix on 0.2.3.6-alpha. - Fix a denial of service attack by which any directory authority could crash all the others, or by which a single v2 directory authority could crash everybody downloading v2 directory information. Fixes bug 7191; bugfix on 0.2.0.10-alpha. - and more. Files: ba53fc6695974745be3a79da3d187bf5 1697 net optional tor_0.2.4.5-alpha-1.dsc 015b022d85d619c471de238d28c59671 3198310 net optional tor_0.2.4.5-alpha.orig.tar.gz 85ed7a94550d8809f491cd4dccd3a0f2 34262 net optional tor_0.2.4.5-alpha-1.diff.gz 8356104f82f02f95491f8c86157fc147 1455672 net extra tor-geoipdb_0.2.4.5-alpha-1_all.deb 5706c44e44bfa30085e871b4d66cef20 1261988 net optional tor_0.2.4.5-alpha-1_amd64.deb b47a55013f5bf15c6ca33d68a924cce9 102268 debug extra tor-dbg_0.2.4.5-alpha-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJQiljFAAoJEDTSCgbh3sV3DnQH/RhYmvzaAE+I/NU+Rwe69tSD AqTdmySUyr0wIvk7mWFcPwkXAeT1Eu5nTTTfnH5t5K3yTyYKWBNMQaPDtkEP1T/5 ctlMLzSt2TDrH36Sw+Sf5PoIjdg9KNoGQVn3uMpRnLh6Nf+Ydd6Qa/hmY0C5tnFy HZVb47btW+qBmUulfLpjaOZDmBCzvRznLQOAavfzYqz4s+/w9ir9GVkSgZjz8hGH mZ16SmKfRHvFO++Bp0hS60oyXgzbRTcMm3DLg30vbbn/A7+sp+6XEgeJv7SMUszm 0xpOUjLLRis8Q1xUQ2z5flrXLCpBC0uJdiDEw0Cy/U20SArZWDIKkPCMUUzjhWI= =pidR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trgwq-0003i2...@franck.debian.org
Accepted fglrx-driver 1:12.10-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 26 Oct 2012 12:38:15 +0200
Source: fglrx-driver
Binary: fglrx-driver libfglrx libfglrx-amdxvba1 libxvbaw-dev libgl1-fglrx-glx
fglrx-glx fglrx-glx-ia32 libfglrx-ia32 fglrx-modules-dkms fglrx-source
fglrx-control fglrx-atieventsd amd-opencl-icd amd-libopencl1 amd-opencl-dev
amd-clinfo
Architecture: source amd64
Version: 1:12.10-1
Distribution: experimental
Urgency: low
Maintainer: Fglrx packaging team pkg-fglrx-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann deb...@abeckmann.de
Description:
amd-clinfo - AMD OpenCL info utility
amd-libopencl1 - AMD OpenCL library
amd-opencl-dev - AMD OpenCL development files
amd-opencl-icd - AMD OpenCL ICD${fglrx:VariantDescSuffix}
fglrx-atieventsd - external events daemon for the non-free ATI/AMD RadeonHD
display
fglrx-control - control panel for the non-free ATI/AMD RadeonHD display
driver${f
fglrx-driver - non-free ATI/AMD RadeonHD display
driver${fglrx:VariantDescSuffix
fglrx-glx - transitional package, use libgl1-${fglrx}-glx
fglrx-glx-ia32 - please switch to multiarch libgl1-fglrx-glx:i386
fglrx-modules-dkms - dkms module source for the non-free ATI/AMD RadeonHD
display driv
fglrx-source - kernel module source for the non-free ATI/AMD RadeonHD display
dr
libfglrx - non-free ATI/AMD RadeonHD display driver (runtime libraries)${fgl
libfglrx-amdxvba1 - AMD XvBA (X-Video Bitstream Acceleration) runtime
libraries${fglr
libfglrx-ia32 - please switch to multiarch libfglrx:i386
libgl1-fglrx-glx - proprietary libGL for the non-free ATI/AMD RadeonHD display
drive
libxvbaw-dev - AMD XvBA (X-Video Bitstream Acceleration) development
files${fglr
Changes:
fglrx-driver (1:12.10-1) experimental; urgency=low
.
* New upstream release 12-10 (2012-10-22) (9.002).
* debian/watch, debian/rules: Adjust for new upstream release naming scheme.
Checksums-Sha1:
f086eee77a19d7787f95fe77b26cd8a9235b2300 3137 fglrx-driver_12.10-1.dsc
f0a76ebdc520cd3bc12e1d5483f49050580b2924 76490384
fglrx-driver_12.10.orig.tar.xz
8ffd793e7da8576aea80549a4cf947c9c2be5e16 132829
fglrx-driver_12.10-1.debian.tar.gz
f8fb511ab30a579cd86ba56b3bc429e8c2f2f736 5278482 fglrx-driver_12.10-1_amd64.deb
dba29ee6c44ea718e793c04daf9d228303b6563a 9041000 libfglrx_12.10-1_amd64.deb
8bebc080bc42f26e533424f5f0d7184e506960a5 2164678
libfglrx-amdxvba1_12.10-1_amd64.deb
835573d916defad57caacf38aeea8311605157c2 38326 libxvbaw-dev_12.10-1_amd64.deb
c43bfdc16bd05f878a27f8edab281b24437e16cc 187956
libgl1-fglrx-glx_12.10-1_amd64.deb
f395ad099413bb8b3b0ad4ce58a215bfa5f18cfb 33528 fglrx-glx_12.10-1_amd64.deb
5c5ba614bddd285711f723d65a30251e03854e26 33924 fglrx-glx-ia32_12.10-1_amd64.deb
47f3a55e27cb9514f38fe4ec06256dd418b08bc4 33628 libfglrx-ia32_12.10-1_amd64.deb
deb221115d81fdb24594f1019064ef599dcde47c 1141298
fglrx-modules-dkms_12.10-1_amd64.deb
d63311150111f32b3b193a76570fc462e5d14dbe 1516656 fglrx-source_12.10-1_amd64.deb
f39101cd7b65d97365c4bdd9d7c7d6b185e5ff3e 4091416
fglrx-control_12.10-1_amd64.deb
ba6a3f9a9f80579ecd1dceacc6312661a55930c9 140474
fglrx-atieventsd_12.10-1_amd64.deb
203f48fbb6b59a780b95a752fdf02584fc0048c5 10655270
amd-opencl-icd_12.10-1_amd64.deb
188bac030a4d1ee0d5e6a82e67e3db49c35765b3 40714 amd-libopencl1_12.10-1_amd64.deb
c3dedf8737d1d08952c8cb11c556ae82dfe11b02 33814 amd-opencl-dev_12.10-1_amd64.deb
5c6ca09942e5b98bc34ebad69f82815e60fa41f3 170878 amd-clinfo_12.10-1_amd64.deb
Checksums-Sha256:
452943ace500d7925172ddaee3af8fcf7b27b26bcceafa6c6789ad77419eab6c 3137
fglrx-driver_12.10-1.dsc
07e57f954fbbdedd9b7d65e84b3a7343a33d99b0ff933e2d26b9b24db74da9bb 76490384
fglrx-driver_12.10.orig.tar.xz
63d25b29d569691011a14ae9eba4ab44d1b5d6fad4ca960d7b24c544cf570ee1 132829
fglrx-driver_12.10-1.debian.tar.gz
9695a121f9bb9a393ef7afaa25b950461c400f391e60240da0ffa7352bba6744 5278482
fglrx-driver_12.10-1_amd64.deb
627b8549654236e9270b23478a797892b3646b9269d8b927c9d6ab55fc8f4bae 9041000
libfglrx_12.10-1_amd64.deb
3bea1b2d45112c6619efcbcd6647ab973c03e1ca0a7db5777c1f7d36116a 2164678
libfglrx-amdxvba1_12.10-1_amd64.deb
ca229162b7266724b685f6b772ce3e0967e2114c8442652303de1d284cb83783 38326
libxvbaw-dev_12.10-1_amd64.deb
6c75041f250c59cdb70c481f8dcc6482acfce5d283d4bee35bd2f7f6b6baf136 187956
libgl1-fglrx-glx_12.10-1_amd64.deb
9aa70ee14fe2d0e111b9d859b3c5ce60651a30977d38b8d1371d79dfb99a4669 33528
fglrx-glx_12.10-1_amd64.deb
ea559c33d5d7061c1750ee91323691b5928c1d1a052d24db7f6538dce8ac8cd4 33924
fglrx-glx-ia32_12.10-1_amd64.deb
943334af271672f5ac1713bbdf4d3566d78470e32ef195290c2f0fb24131bce4 33628
libfglrx-ia32_12.10-1_amd64.deb
7c364f1e2f92c214dcdb35d02419525fbe0a140393cacee85923412155f3b604 1141298
fglrx-modules-dkms_12.10-1_amd64.deb
6e2388a17d09646e139c57e1a6ac5aa35b75764537650702dbd96d4e69ba9c60 1516656
fglrx-source_12.10-1_amd64.deb
e301555a52ef61add3c07ebd262a81fa9a92a8714dd8451c8bed5c91ee31e3f6 4091416
fglrx-control_12.10-1_amd64.deb
Accepted libcaptcha-recaptcha-perl 0.97-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 06:25:21 +0200 Source: libcaptcha-recaptcha-perl Binary: libcaptcha-recaptcha-perl Architecture: source all Version: 0.97-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Xavier Guimard x.guim...@free.fr Description: libcaptcha-recaptcha-perl - perl implementation of the reCAPTCHA API Changes: libcaptcha-recaptcha-perl (0.97-1) unstable; urgency=low . [ Ansgar Burchardt ] * debian/control: Convert Vcs-* fields to Git. . [ Xavier Guimard ] * New upstream version * Bump Standards-Version to 3.9.4 * Add myself to uploaders * Convert to CopyrightFormat 1.0 Checksums-Sha1: 9c5a70159e6d5cbc81a3e673b33dfe09132365ba 2248 libcaptcha-recaptcha-perl_0.97-1.dsc e17f8039ee6c21c720bca22828a17b050f4fb874 9311 libcaptcha-recaptcha-perl_0.97.orig.tar.gz 543bdae96fd9887f771abdf6d530f81d9df288aa 2508 libcaptcha-recaptcha-perl_0.97-1.debian.tar.gz 23cd7a39adfa3e0dedbaf127227a09330e6f1060 13802 libcaptcha-recaptcha-perl_0.97-1_all.deb Checksums-Sha256: 204050e50d1331bde4793313496290cd456a8b273bf1048c4703128c0130392d 2248 libcaptcha-recaptcha-perl_0.97-1.dsc 988b10b1ef89045f153f12fccd0b298fb6a239a54c769ca7ad264a9510f4c289 9311 libcaptcha-recaptcha-perl_0.97.orig.tar.gz e117273509016009ff78b0015bd369d5c70cc701bc119aa6dea2cd4a75ed0eb1 2508 libcaptcha-recaptcha-perl_0.97-1.debian.tar.gz 860249411c16feed6b519e07b316c1f7472283e1458a4717b00bf7f7b1892df2 13802 libcaptcha-recaptcha-perl_0.97-1_all.deb Files: da2b23d5d7406af37ce0801dcc231dc8 2248 perl optional libcaptcha-recaptcha-perl_0.97-1.dsc 0e8d3edfc5b580d99fca2bffeb7ef948 9311 perl optional libcaptcha-recaptcha-perl_0.97.orig.tar.gz 21436026a3e82c118f4b3bacfa4b5ca1 2508 perl optional libcaptcha-recaptcha-perl_0.97-1.debian.tar.gz cd54bb1f757bba82b9b3ca54a2adf9b8 13802 perl optional libcaptcha-recaptcha-perl_0.97-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQinBlAAoJELs6aAGGSaoGZ/AP/2TeufWKmlpTckNYKLvwEGP8 k6WNbgYvg4LGJ5Pl64479raEQyHCDT/rFlBRfZiGLSvz32c/iQ3+MknqD0LeVFPZ NtSjqBXJdyxRP/6I+bf2aDqLrD+W3x+6xAmK7eJWTbmbVbbE0mDipSLeRFAksokr VR7Z+0J8CmdZAe5KtcgYnXyAx0NaCyZ3Bc7kfbL2htcV/QU13i61EL4dp3FimIWt dV3J9ZtyMqnznAGiV/KmzOXXNOnvm/0fHu3Cg6z++IXKQUrlY6L4t5GHMhrEIt38 WmXv/LWwA4jxwAqsm+4Ps14vfrOQTIXcAybFJsNqNTI6yf13JvvSLd1M77lPj7E2 LEaqygo92xN7rZqN0HAcdt8GNzteIPaKanPBHQYdUr19iNdoJvf3xFIW57HoHEl/ Uho3F5f/LyBo1rb97kpmp310kj7Tp4CEL2QPrjcF6oTRMtOGEjue8Wg04Clb9ZUu 3tiw2E7bMyZUyxOHiHMN1vmgqaac8vWhn3RlQ9iKhhod01IG0XhDcfsrgfLSk1Dq 6J4uKxYxrHpWeRZFudp7Dhu6tmT9YTlp6jav7EnTs79bRmsQdK+5q4Uuc7I+h4Hk Hh/4cL3veb8zV4Jv4YkSDObaYTbBvurEJAm8o5U2aEL1WcNsCXeRT47riZFsGNko Bb1hoWLt/zgD0FOeZNtp =RlL4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trhur-0005ik...@franck.debian.org
Accepted request-tracker4 4.0.7-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 23 Oct 2012 10:58:58 +0100 Source: request-tracker4 Binary: request-tracker4 rt4-clients rt4-fcgi rt4-apache2 rt4-db-postgresql rt4-db-mysql rt4-db-sqlite Architecture: source all Version: 4.0.7-2 Distribution: unstable Urgency: high Maintainer: Debian Request Tracker Group pkg-request-tracker-maintain...@lists.alioth.debian.org Changed-By: Dominic Hargreaves d...@earth.li Description: request-tracker4 - extensible trouble-ticket tracking system rt4-apache2 - Apache 2 specific files for request-tracker4 rt4-clients - mail gateway and command-line interface to request-tracker4 rt4-db-mysql - MySQL database backend for request-tracker4 rt4-db-postgresql - PostgreSQL database backend for request-tracker4 rt4-db-sqlite - SQLite database backend for request-tracker4 rt4-fcgi - External FastCGI support for request-tracker4 Changes: request-tracker4 (4.0.7-2) unstable; urgency=high . * Multiple security fixes for: - Email header injection attack (CVE-2012-4730) - Missing rights checking for Articles (CVE-2012-4731) - CSRF protection allows attack on bookmarks (CVE-2012-4732) - Confused deputy attack for non-logged-in users (CVE-2012-4734) - Multiple message signing/encryption attacks related to GnuPG (CVE-2012-4735) - Arbitrary command-line argument injection to GnuPG (CVE-2012-4884) Checksums-Sha1: 71226e0b899eeae700ddcdb34a22a2c80e617a0f 2112 request-tracker4_4.0.7-2.dsc c28f76b5d17213d0f776216ce7f62c55dbc49955 75914 request-tracker4_4.0.7-2.debian.tar.gz 31823074a6892202a9d45eafb0f288a3d001c1b8 3953688 request-tracker4_4.0.7-2_all.deb 78e3aa9dc3f2499a9da414e9019cd28bdc0fb3d4 46748 rt4-clients_4.0.7-2_all.deb eb296465f3aae947f527012f47e5974fbf7e558e 10362 rt4-fcgi_4.0.7-2_all.deb 665393994478301720b365769f9447aa56408102 9296 rt4-apache2_4.0.7-2_all.deb 19ca465a3f5ea2e39a508b997a5903ea42be4821 8494 rt4-db-postgresql_4.0.7-2_all.deb 9ec217d8b044a0b90c71a47cb33df609e6673234 8492 rt4-db-mysql_4.0.7-2_all.deb 17392667dd4e2a42a9454187eb2e75b5a8f1ae1d 8584 rt4-db-sqlite_4.0.7-2_all.deb Checksums-Sha256: 8e99958aac1af7aa34eb2a18042c2c4051a4efa1b68a5dc59eb631c2369a7fe5 2112 request-tracker4_4.0.7-2.dsc d49a6167534fcce11df414ace0147d78071cc0bef969693368daa3683eb7b95d 75914 request-tracker4_4.0.7-2.debian.tar.gz 830cd75336df1437353c1194d2c67ad8cbbb18da7cc3b49ef666ad516010 3953688 request-tracker4_4.0.7-2_all.deb 68e55a175e618cda4b71ad5c083a25bbd6f9dac35874c8798603297f3246e108 46748 rt4-clients_4.0.7-2_all.deb 8ee372fab6d734e49917a78c418845c19f880778012eecd2a33b9478d298227c 10362 rt4-fcgi_4.0.7-2_all.deb 3f09d7762ff344293d9fc8280f6f7aa8df5a15a841a6fd9107da97700100824f 9296 rt4-apache2_4.0.7-2_all.deb ece062cd343b38a42abd1d8e2299a7374a96d2203fa75ec99b5af7ec9fb934e7 8494 rt4-db-postgresql_4.0.7-2_all.deb d3526ca10f5f0d38436f9254350760e47f1a7b16572245e453e32379de1186a0 8492 rt4-db-mysql_4.0.7-2_all.deb c011195e23e6305698833d745d19a62fa8bbb3d733fa55e449f6867dcb9422dc 8584 rt4-db-sqlite_4.0.7-2_all.deb Files: dfbebe07b2e4d12e5bc0a3f73b2fb36c 2112 misc optional request-tracker4_4.0.7-2.dsc f16ee6865a2d101a44839e23ab53e32d 75914 misc optional request-tracker4_4.0.7-2.debian.tar.gz 96b07e389e1bf86b875ad6cf18556e4b 3953688 misc optional request-tracker4_4.0.7-2_all.deb 708971283aa7418974a572f918b21c22 46748 misc optional rt4-clients_4.0.7-2_all.deb 132e35852f9e8d85228dce2e0e6a8c90 10362 misc optional rt4-fcgi_4.0.7-2_all.deb 9f38a6b2328464e29d82da4fb20cacaa 9296 misc optional rt4-apache2_4.0.7-2_all.deb bd1650224a9e0f98da5a5eb0647ca5a3 8494 misc optional rt4-db-postgresql_4.0.7-2_all.deb 8a87cd7e3021369e28d26027dc4dd0de 8492 misc optional rt4-db-mysql_4.0.7-2_all.deb 152479fa6707a154fec30433b9ace630 8584 misc optional rt4-db-sqlite_4.0.7-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQhmvxYzuFKFF44qURAgwfAJ9K9NJcJGPS9YrX2ECQu836+kjr/gCfRvMP H9dUN5sB2Cbm9XNo4LHYmE4= =jQY0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trhvo-0005xw...@franck.debian.org
Accepted r-base 2.15.2-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 06:17:58 -0500 Source: r-base Binary: r-base r-base-core r-base-dev r-mathlib r-base-html r-doc-pdf r-doc-html r-doc-info r-recommended r-base-core-dbg Architecture: source i386 all Version: 2.15.2-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel e...@debian.org Changed-By: Dirk Eddelbuettel e...@debian.org Description: r-base - GNU R statistical computation and graphics system r-base-core - GNU R core of statistical computation and graphics system r-base-core-dbg - GNU R debug symbols for statistical comp. language and environmen r-base-dev - GNU R installation of auxiliary GNU R packages r-base-html - GNU R html docs for statistical computing system functions r-doc-html - GNU R html manuals for statistical computing system r-doc-info - GNU R info manuals statistical computing system r-doc-pdf - GNU R pdf manuals for statistical computing system r-mathlib - GNU R standalone mathematics library r-recommended - GNU R collection of recommended packages [metapackage] Changes: r-base (2.15.2-1) unstable; urgency=low . * New upstream release . * src/library/tools/R/install.R: Pass perl = TRUE parameter to sub() function when defining SHLIB_* macros to work-around an erroneus string replacement which causes build failures on arm* architectures but make the change conditonal on actually being on arm*. Checksums-Sha1: c2ae77a0124ff8df582b26d5d7c1979d5a8deb7f 2085 r-base_2.15.2-1.dsc c80da687d66ee88d1e34fc1ae5c1bd525f9513dd 24338934 r-base_2.15.2.orig.tar.gz 47faed634b80afca6f9511954dc509bddc45fb67 86835 r-base_2.15.2-1.diff.gz 1160e1cb488321364778008f18c4b5e03f7d1e35 20637984 r-base-core_2.15.2-1_i386.deb f2f120d4f7bed085a9b4a91a02b78e5f8ec069ee 625056 r-mathlib_2.15.2-1_i386.deb 3d5135bec3875c9b08b9df4f369942718e250ca9 3407828 r-base-core-dbg_2.15.2-1_i386.deb 71f91f914ee0a6dd27192b26d1c6cc0531838d70 36836 r-base_2.15.2-1_all.deb eb17fa693ca96a086b91fe64d52d8470e3a7ac13 3892 r-base-dev_2.15.2-1_all.deb b0389de74d0af674c6be3e7c7660d6e09e95e180 90370 r-base-html_2.15.2-1_all.deb 106743cff15b0940c6f2ff899dce587e5df832a4 8464374 r-doc-pdf_2.15.2-1_all.deb 5d995866927220cf1fff702a5a02e89ec373630f 640296 r-doc-html_2.15.2-1_all.deb 315b886dc8bb7495e0be7a47c2086dc07eacfbb0 545576 r-doc-info_2.15.2-1_all.deb 872d5f4b72c7e9da694c28caba9c2e524d15e717 2682 r-recommended_2.15.2-1_all.deb Checksums-Sha256: 5abce35ce2724a785c40ca87a34615415200dff41003963255951548382236b1 2085 r-base_2.15.2-1.dsc 292837ae259b7668509b8a5d4ec8be0aa50c327cfe7a534bac419b4ca766d66d 24338934 r-base_2.15.2.orig.tar.gz 1bb136d50927e559f90e4e8d6795128d1e1071e9a2cab967410a6a0890ff2eaf 86835 r-base_2.15.2-1.diff.gz e1766670434a6ee474554315427510d75022e32cd3a79078a8a2e0b15eba1072 20637984 r-base-core_2.15.2-1_i386.deb f459c708e8bac5863d325fc4c605000b79f57697b9bafbd2413b93f4b58e81be 625056 r-mathlib_2.15.2-1_i386.deb 37225beaa5899ab7e905cec1302d93987de055ca8f6a54d09115f3ce5a295b79 3407828 r-base-core-dbg_2.15.2-1_i386.deb a70ea7d01dc5c899eb89938d8da99e8967d650cb619fe204fc5c177893d96cf1 36836 r-base_2.15.2-1_all.deb b57ff96ba50375bc3d46e12ed4366007ec37782dda7aa4f38891435907786afe 3892 r-base-dev_2.15.2-1_all.deb 09442e5da13d991018f1672e2475c2cfb5901ba18cc9ec5ca53afbeabfbcbc7d 90370 r-base-html_2.15.2-1_all.deb c89f193032dcf67fafab8009975ddd9c65d4a3783da73179046f25728117 8464374 r-doc-pdf_2.15.2-1_all.deb 0ffb80a6f297ab9cea3f8bf728a9a9066b477cb04ed2607bae84dece9c55bf58 640296 r-doc-html_2.15.2-1_all.deb f10b21a5b38766d9aa26bee863b483c4688671ac778c6398a562024375f2b9ef 545576 r-doc-info_2.15.2-1_all.deb f28e1064d220e9bc01be8577a7cb7d3750db53289637413eb8766819792df13a 2682 r-recommended_2.15.2-1_all.deb Files: a4d181541408f133c02ca20e1fef508c 2085 gnu-r optional r-base_2.15.2-1.dsc 346d16bab26fcae15e53755be8a69b00 24338934 gnu-r optional r-base_2.15.2.orig.tar.gz 6883c52aa7ac617f34d9466df725b17f 86835 gnu-r optional r-base_2.15.2-1.diff.gz c3a73d058461982e381ab0265bf19677 20637984 gnu-r optional r-base-core_2.15.2-1_i386.deb 1ac6afff41d2677303f823945723a543 625056 gnu-r optional r-mathlib_2.15.2-1_i386.deb fcbea01691d93a7b2a862a4fb71c95c2 3407828 debug extra r-base-core-dbg_2.15.2-1_i386.deb c27eed7338c138d634460bfca62ca6bd 36836 gnu-r optional r-base_2.15.2-1_all.deb e34f02b2da329734524c77f0bd1765e2 3892 gnu-r optional r-base-dev_2.15.2-1_all.deb 1e473c20903abfaa8b624dcb814a3bb8 90370 doc extra r-base-html_2.15.2-1_all.deb 44ae226f42a75e752c50db3e17c017d8 8464374 doc optional r-doc-pdf_2.15.2-1_all.deb a967f60289eca03609f20258fe02fbd3 640296 doc optional r-doc-html_2.15.2-1_all.deb d1159924fc1673d29259cc87f8439b63 545576 doc optional r-doc-info_2.15.2-1_all.deb 143516dd7e6e5001d269cd80864ae12a 2682 gnu-r optional r-recommended_2.15.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux)
Accepted ettercap 1:0.7.5-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 12:45:37 +0100 Source: ettercap Binary: ettercap-common ettercap-text-only ettercap-graphical Architecture: source amd64 Version: 1:0.7.5-3 Distribution: unstable Urgency: low Maintainer: Barak A. Pearlmutter b...@debian.org Changed-By: Barak A. Pearlmutter b...@debian.org Description: ettercap-common - Multipurpose sniffer/interceptor/logger for switched LAN ettercap-graphical - Ettercap GUI-enabled executable ettercap-text-only - Ettercap console-mode executable Closes: 691478 Changes: ettercap (1:0.7.5-3) unstable; urgency=low . * put back version in conflicts with ettercap (closes: #691478) Checksums-Sha1: a68463a306be4d255cb117dfd89438654c41a8b5 1602 ettercap_0.7.5-3.dsc e6c2dc352400b305db6be3713af012ae0e78c235 30630 ettercap_0.7.5-3.debian.tar.gz 958c81ff736ae76beb0e91430729a904792c18c2 393234 ettercap-common_0.7.5-3_amd64.deb 5456be28bcbcb4e95e24d9034b740427eabcba60 183192 ettercap-text-only_0.7.5-3_amd64.deb 9675802edfb050e1d3cd4711bf9147f0c1920a3a 235888 ettercap-graphical_0.7.5-3_amd64.deb Checksums-Sha256: e64a7c67c95a444ff1a961cd54fb1075890c1b64ebe4e784f1734c7cf920 1602 ettercap_0.7.5-3.dsc fa1fbe13d71e35bd7dd8dfcfacabedc610efed3cb198372e83425b830c4eb8e2 30630 ettercap_0.7.5-3.debian.tar.gz 4153573655ec16a25ea2eb3262d4f052754bfdd7ef5e3edb9f5d216cb389cff8 393234 ettercap-common_0.7.5-3_amd64.deb 513165249a775f536eb52c26c5dc65f53029ca5eb61e827d1da224ffbe34fcd9 183192 ettercap-text-only_0.7.5-3_amd64.deb 0dcaaab680c2ba6fae8a3fe4bdc6fe29322ad73b063fa9109ddd2584891805c0 235888 ettercap-graphical_0.7.5-3_amd64.deb Files: 896c13fc6e30c6a2613c2a3e2a843481 1602 net optional ettercap_0.7.5-3.dsc 75ae4260979d6aa33dc45464d234137f 30630 net optional ettercap_0.7.5-3.debian.tar.gz c9a1650c791984adc89a90f26f5a61a6 393234 net optional ettercap-common_0.7.5-3_amd64.deb 5cc61890b95f35ffc7996740feb80729 183192 net optional ettercap-text-only_0.7.5-3_amd64.deb ef87542b02ce1ec462f242eefeb33250 235888 net optional ettercap-graphical_0.7.5-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCKeEYACgkQLz4Gnv7CP7K9mwCeIadsshuNFUVZv9Cz/nt1aNIo bsgAoI7CqCEGbveGJXaK9g58LdNtaD6+ =jQxc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tricu-0007co...@franck.debian.org
Accepted pcsc-lite 1.8.6-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 24 Oct 2012 13:58:56 +0200 Source: pcsc-lite Binary: pcscd libpcsclite-dev libpcsclite-dbg libpcsclite1 Architecture: source amd64 Version: 1.8.6-3 Distribution: unstable Urgency: low Maintainer: Ludovic Rousseau rouss...@debian.org Changed-By: Ludovic Rousseau rouss...@debian.org Description: libpcsclite-dbg - Middleware to access a smart card using PC/SC (debugging symbols) libpcsclite-dev - Middleware to access a smart card using PC/SC (development files) libpcsclite1 - Middleware to access a smart card using PC/SC (library) pcscd - Middleware to access a smart card using PC/SC (daemon side) Changes: pcsc-lite (1.8.6-3) unstable; urgency=low . * debian/libpcsclite1.symbols: update the versioning to exact (or more realistic) values. See Debian bug #690074 Checksums-Sha1: 534a2d7a9187fbff6820c3adffb7d397fca9cc65 1493 pcsc-lite_1.8.6-3.dsc 85ecdce8c90f45a4118bcbd6c3af87556807fe01 15664 pcsc-lite_1.8.6-3.debian.tar.gz 66a0b634210e01eb5b8ec611e2c8af4914bdb44c 97964 pcscd_1.8.6-3_amd64.deb 5fd9ceb7585446854f5371762832980a04a8cb2f 75958 libpcsclite-dev_1.8.6-3_amd64.deb 965ac83db781cded524a79360c39aa1b964c7d67 215796 libpcsclite-dbg_1.8.6-3_amd64.deb ff54d33175bef722ae35c1b0215ef5041e9fac79 57432 libpcsclite1_1.8.6-3_amd64.deb Checksums-Sha256: 78d16e259ab8264fd00e76570c21974a2e07b0172c3b10ce7007e18693b8431e 1493 pcsc-lite_1.8.6-3.dsc 6beda09707375aeba0adb01064a2ff726adca3641c193528f7425b04a929ef2d 15664 pcsc-lite_1.8.6-3.debian.tar.gz 0ea8027c4a752727e3fdcfdc61a850b75d385b416edaecd8af6d6737a837912d 97964 pcscd_1.8.6-3_amd64.deb 4c5afa939c8e0479b759b70099c5c3f437d7088e463391a28322e9fb1fbd1b0f 75958 libpcsclite-dev_1.8.6-3_amd64.deb d34dd9a64f65b55524944ad0e275ba62ff4258f714f84716ad3143dc0bbe1f7b 215796 libpcsclite-dbg_1.8.6-3_amd64.deb b11db2875ee2f51b831325f41a03fa93fd2b43d34889dc171fbb139ddd6e69b5 57432 libpcsclite1_1.8.6-3_amd64.deb Files: e1ed0ac7595fd7de4f901d73a9e4284d 1493 misc optional pcsc-lite_1.8.6-3.dsc 6034edbe9f32ed1c1539abd1ae5b9431 15664 misc optional pcsc-lite_1.8.6-3.debian.tar.gz 6e896d4e23e30038534fbfcba6e22848 97964 misc optional pcscd_1.8.6-3_amd64.deb 5ff04476bf5ea39ead75c39c154b5140 75958 libdevel optional libpcsclite-dev_1.8.6-3_amd64.deb 7d0adbabde6899ed30e54ea744340571 215796 debug extra libpcsclite-dbg_1.8.6-3_amd64.deb 2971f419d8075ed133d2fa27b125b3eb 57432 libs optional libpcsclite1_1.8.6-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCKeVUACgkQP0qKj+B/HPlPEgCfRVK95/0aAw5tGG+ns0yPdk8v ZQgAn2xORcE30ztRKfM+g5c64NAghL5l =zBgY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trich-0007lh...@franck.debian.org
Accepted texstudio 2.3+debian-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 20 Oct 2012 12:21:07 +0200 Source: texstudio Binary: texstudio texstudio-dbg Architecture: source i386 Version: 2.3+debian-4 Distribution: unstable Urgency: low Maintainer: Tom Jampen t...@cryptography.ch Changed-By: Tom Jampen t...@cryptography.ch Description: texstudio - Latex Editor texstudio-dbg - Latex Editor (debug) Closes: 688558 Changes: texstudio (2.3+debian-4) unstable; urgency=low . * Adding patch to prevent needless latex run when no bib-files are referenced (Closes: #688558). * Adding patch to set the default value of automatically run 'latex, bibtex, latex' if bib-files were changed to disabled. * Adding patch to make 'pdflatex, viewpdf' the default quick build option. * Adding patch to prevent the config file from growing by unnecessary whitespace. * Adding patch to disable the riddle asked when accessing advanced configuration options. Checksums-Sha1: e92bd1d492950c20a8cfb5da4be26ce676cd923d 1221 texstudio_2.3+debian-4.dsc 7d58dc6bd57a5501157e50f9019e781e4f548789 7792 texstudio_2.3+debian-4.debian.tar.xz a7febbc58ba9dc67e9564beda06d2cf2f685ca07 3885978 texstudio_2.3+debian-4_i386.deb 2c3845442d1cc8ecfb2588448a801dc835f16b8e 20474816 texstudio-dbg_2.3+debian-4_i386.deb Checksums-Sha256: 22c7f41cd26e2673b5533c8199c5e4fe5310976203140a29a4116e7535db1727 1221 texstudio_2.3+debian-4.dsc 5230cde9ae6a1c0e5f05fbfac5d4d513f2d434d1328431eca9d25377f9eac881 7792 texstudio_2.3+debian-4.debian.tar.xz e6d113ea96e38d059686b1d774099b7f65bc497d329624a101176f4d4f546bee 3885978 texstudio_2.3+debian-4_i386.deb 7a8455d95b22cda0e46016adeb730c1a8d653ae92d9c38828fc81f1f4a192d69 20474816 texstudio-dbg_2.3+debian-4_i386.deb Files: 1b1022ab0728605be4a7b1a28fb54ad9 1221 editors optional texstudio_2.3+debian-4.dsc c72b1e96d6a47bfc138a2af263d8128c 7792 editors optional texstudio_2.3+debian-4.debian.tar.xz 31a58850ee53c5747d99f0c87d5106b0 3885978 editors optional texstudio_2.3+debian-4_i386.deb 4041ab875c64bb4427f4381720db369b 20474816 debug extra texstudio-dbg_2.3+debian-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlCKeycACgkQ+C5cwEsrK55o0gCg40JCK0jkBXYEne/ocpU+xhJ9 fmsAoIQoCS2LvFy03aBKAqHMgrIcKslO =aPdd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tricp-0007qk...@franck.debian.org
Accepted cyrus-imapd-2.4 2.4.16-2 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 24 Oct 2012 18:50:42 +0200 Source: cyrus-imapd-2.4 Binary: cyrus-common-2.4 cyrus-doc-2.4 cyrus-imapd-2.4 cyrus-pop3d-2.4 cyrus-admin-2.4 cyrus-murder-2.4 cyrus-replication-2.4 cyrus-nntpd-2.4 cyrus-clients-2.4 cyrus-dev-2.4 cyrus-common libcyrus-imap-perl24 cyrus-clients cyrus-imapd cyrus-pop3d cyrus-admin cyrus-murder cyrus-replication cyrus-nntpd cyrus-doc cyrus-dev libcyrus-imap-perl cyrus-common-2.2 cyrus-doc-2.2 cyrus-imapd-2.2 cyrus-pop3d-2.2 cyrus-admin-2.2 cyrus-murder-2.2 cyrus-nntpd-2.2 cyrus-clients-2.2 cyrus-dev-2.2 libcyrus-imap-perl22 Architecture: source amd64 all Version: 2.4.16-2 Distribution: unstable Urgency: low Maintainer: Debian Cyrus Team pkg-cyrus-imapd-debian-de...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: cyrus-admin - Cyrus mail system - administration tools (metapackage) cyrus-admin-2.2 - Transitional package for cyrus-admin-2.4 cyrus-admin-2.4 - Cyrus mail system - administration tools cyrus-clients - Cyrus mail system - test clients (metapackage) cyrus-clients-2.2 - Transitional package for cyrus-clients-2.4 cyrus-clients-2.4 - Cyrus mail system - test clients cyrus-common - Cyrus mail system - common files cyrus-common-2.2 - Transitional package for cyrus-common-2.4 cyrus-common-2.4 - Cyrus mail system - common files cyrus-dev - Cyrus mail system - developer files (metapackage) cyrus-dev-2.2 - Transitional package for cyrus-dev-2.4 cyrus-dev-2.4 - Cyrus mail system - developer files cyrus-doc - Cyrus mail system - documentation files (metapackage) cyrus-doc-2.2 - Transitional package for cyrus-doc-2.4 cyrus-doc-2.4 - Cyrus mail system - documentation files cyrus-imapd - Cyrus mail system - IMAP support (metapackage) cyrus-imapd-2.2 - Transitional package for cyrus-imapd-2.4 cyrus-imapd-2.4 - Cyrus mail system - IMAP support cyrus-murder - Cyrus mail system - proxies and aggregator (metapackage) cyrus-murder-2.2 - Transitional package for cyrus-murder-2.4 cyrus-murder-2.4 - Cyrus mail system - proxies and aggregator cyrus-nntpd - Cyrus mail system - NNTP support (metapackage) cyrus-nntpd-2.2 - Transitional package for cyrus-nntpd-2.4 cyrus-nntpd-2.4 - Cyrus mail system - NNTP support cyrus-pop3d - Cyrus mail system - POP3 support (metapackage) cyrus-pop3d-2.2 - Transitional package for cyrus-pop3d-2.4 cyrus-pop3d-2.4 - Cyrus mail system - POP3 support cyrus-replication - Cyrus mail system - replication (metapackage) cyrus-replication-2.4 - Cyrus mail system - replication libcyrus-imap-perl - Interface to Cyrus imap client imclient library (metapackage) libcyrus-imap-perl22 - Transitional package for libcyrus-imap-perl24 libcyrus-imap-perl24 - Interface to Cyrus imap client imclient library Closes: 690147 Changes: cyrus-imapd-2.4 (2.4.16-2) unstable; urgency=low . [ Gregor Herrman ] * Add postinst scripts for all transitional packages to handle the directory to symlink transition of their docdirs. (Closes: #690147) Checksums-Sha1: a4dabfc6e98807a20bbb94213be303915f1ca51a 3371 cyrus-imapd-2.4_2.4.16-2.dsc 1275d46549f847aebffe3316631dd87f152b644a 120066 cyrus-imapd-2.4_2.4.16-2.debian.tar.gz e784355b555c02b4cd532b041243b4cc819e593c 9481698 cyrus-common-2.4_2.4.16-2_amd64.deb 3e1b2de975e99c7ef34a27e7978e3025902c7076 286790 cyrus-doc-2.4_2.4.16-2_all.deb 32a774e994e521ed20c18fa5bd743bf5f50c556f 1093844 cyrus-imapd-2.4_2.4.16-2_amd64.deb cdd4bc5cb742adecdab9d4d1d27850635596f5c9 26 cyrus-pop3d-2.4_2.4.16-2_amd64.deb 32231c07f278c3742604202b02e80e21e78c3274 116646 cyrus-admin-2.4_2.4.16-2_all.deb 92a4b266752409fb6737ee9025672a2d711901ab 1471740 cyrus-murder-2.4_2.4.16-2_amd64.deb 270008acbf5abef8213cdf24b271af50f83eef0d 1311630 cyrus-replication-2.4_2.4.16-2_amd64.deb eb5974cfb80fb44f544851a80827d4d1201b61c0 697604 cyrus-nntpd-2.4_2.4.16-2_amd64.deb bed043df7a60cb9aeec3b996fbfa72f50c8a14a5 178386 cyrus-clients-2.4_2.4.16-2_amd64.deb 22f1ad342166dbac5c81c97b3d53db7b1288b895 283784 cyrus-dev-2.4_2.4.16-2_amd64.deb 9f92167155d81d8481d779b3dae5031260616b77 142256 cyrus-common_2.4.16-2_all.deb ea88fbd5bee07c503987e1b328953827a243be04 180314 libcyrus-imap-perl24_2.4.16-2_amd64.deb 6d853c87d33028763c754fe0d87f29d46098ff1b 928 cyrus-clients_2.4.16-2_all.deb 980de0bf6665daf892ca843745922230f43593a6 922 cyrus-imapd_2.4.16-2_all.deb 01ed6c23fc1037e5ee203649abd9ee2f6abf9ee9 926 cyrus-pop3d_2.4.16-2_all.deb 9065c2fddab07617f4469aaee726ecb5a3b50237 926 cyrus-admin_2.4.16-2_all.deb a167c987feb8fd9ecf22d872ded3ba10e5793730 930 cyrus-murder_2.4.16-2_all.deb db74bb1316df898eb5eb8c4d2a85ed31101c9e77 926 cyrus-replication_2.4.16-2_all.deb afbc3a078700a9c3b3219547ddc33ef0fd198126 926 cyrus-nntpd_2.4.16-2_all.deb 73a95c41298218bd938b9ccedadae4b66223e3bd 926 cyrus-doc_2.4.16-2_all.deb 68445c69a74d808f909e0494695b3b94673cfb0e 928 cyrus-dev_2.4.16-2_all.deb cc5dd0e7f73e0a6150713e1ef4c2aa74a23443da 942
Accepted cyrus-sasl2 2.1.25.dfsg1-6 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 14:06:11 +0200 Source: cyrus-sasl2 Binary: sasl2-bin cyrus-sasl2-doc libsasl2-2 libsasl2-modules libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql libsasl2-modules-gssapi-mit libsasl2-dev libsasl2-modules-gssapi-heimdal cyrus-sasl2-dbg cyrus-sasl2-mit-dbg cyrus-sasl2-heimdal-dbg Architecture: source amd64 all Version: 2.1.25.dfsg1-6 Distribution: unstable Urgency: low Maintainer: Debian Cyrus SASL Team pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: cyrus-sasl2-dbg - Cyrus SASL - debugging symbols cyrus-sasl2-doc - Cyrus SASL - documentation cyrus-sasl2-heimdal-dbg - Cyrus SASL - debugging symbols for Heimdal modules cyrus-sasl2-mit-dbg - Cyrus SASL - debugging symbols for MIT modules libsasl2-2 - Cyrus SASL - authentication abstraction library libsasl2-dev - Cyrus SASL - development files for authentication abstraction lib libsasl2-modules - Cyrus SASL - pluggable authentication modules libsasl2-modules-gssapi-heimdal - Pluggable Authentication Modules for SASL (GSSAPI) libsasl2-modules-gssapi-mit - Cyrus SASL - pluggable authentication modules (GSSAPI) libsasl2-modules-ldap - Cyrus SASL - pluggable authentication modules (LDAP) libsasl2-modules-otp - Cyrus SASL - pluggable authentication modules (OTP) libsasl2-modules-sql - Cyrus SASL - pluggable authentication modules (SQL) sasl2-bin - Cyrus SASL - administration programs for SASL users database Closes: 683555 Changes: cyrus-sasl2 (2.1.25.dfsg1-6) unstable; urgency=low . * Fix failures when the host have broken hostname (Closes: #683555) Checksums-Sha1: 83af1ed55dc5696f54cb9eefd016340dd4974d7b 2556 cyrus-sasl2_2.1.25.dfsg1-6.dsc df77b23168185bdec5fc88d527b315a59f4878d6 106438 cyrus-sasl2_2.1.25.dfsg1-6.debian.tar.gz 482a6dafed06cba33980c1ef2dbdf3c9b25c246f 187392 sasl2-bin_2.1.25.dfsg1-6_amd64.deb 34e284bf9e2e58f1d52a826f680be7631599cd92 114184 cyrus-sasl2-doc_2.1.25.dfsg1-6_all.deb 62e696bdfa8a09498be522dec4358407b6f08c69 120370 libsasl2-2_2.1.25.dfsg1-6_amd64.deb b4cb743b9eea23cc993cedf910fd1901a407 115882 libsasl2-modules_2.1.25.dfsg1-6_amd64.deb 507a933b273345bcba92ed18d40157164fa49cb9 64378 libsasl2-modules-ldap_2.1.25.dfsg1-6_amd64.deb 02734fa65342ad9bb2a225b229f9a824be0f075a 88730 libsasl2-modules-otp_2.1.25.dfsg1-6_amd64.deb d6a7c849926369e64af534277a95d848db5ee3a1 67704 libsasl2-modules-sql_2.1.25.dfsg1-6_amd64.deb b6c8ed13779dfa3ea3d7e0336c9c64283dfe8e6f 100200 libsasl2-modules-gssapi-mit_2.1.25.dfsg1-6_amd64.deb c819b0d1f4ad361fcbf286c0c181a497ac8b147c 360532 libsasl2-dev_2.1.25.dfsg1-6_amd64.deb 84eeeb3ab8faf9e153cd10776c22b7a935298cd0 69332 libsasl2-modules-gssapi-heimdal_2.1.25.dfsg1-6_amd64.deb cc5fa0c6bbb8a32d2716aad7a0ecda9b5a0d1d78 880914 cyrus-sasl2-dbg_2.1.25.dfsg1-6_amd64.deb e264e32c80cc08884feae4037c5db6abbfeef55c 89032 cyrus-sasl2-mit-dbg_2.1.25.dfsg1-6_amd64.deb 45cde31eb711a493f5ca7c19d211de64ffc9a659 89526 cyrus-sasl2-heimdal-dbg_2.1.25.dfsg1-6_amd64.deb Checksums-Sha256: 7f3383eda5e2548798a0b21484e3d2846dce1b89a38c04717608c0b612ec12e9 2556 cyrus-sasl2_2.1.25.dfsg1-6.dsc 468f4cabb6f12cb2670a4def639557c5cf7bc9c66a655a73031bd21233900cc2 106438 cyrus-sasl2_2.1.25.dfsg1-6.debian.tar.gz 7749b2a2e6f589a91f3bf8df940d1c0c1a2dc72df5d92f50f1a65309853a49b5 187392 sasl2-bin_2.1.25.dfsg1-6_amd64.deb 62bc96b3c36cc2180f06d8af1e04186298c566d403ad70ee3f38bd2dd82831ed 114184 cyrus-sasl2-doc_2.1.25.dfsg1-6_all.deb 676f66987921d98c7819196c18e50f13e04b914f710405278029b1afe3656db2 120370 libsasl2-2_2.1.25.dfsg1-6_amd64.deb 482ebbeaece41bcba4b177fa25f186143f2bf89cf8ac63faf92d7fe0bd9e34e9 115882 libsasl2-modules_2.1.25.dfsg1-6_amd64.deb 5210da9b50e43d530728cb3cf82c3ab074cf99caf7152b037ccedd7f3d1967bb 64378 libsasl2-modules-ldap_2.1.25.dfsg1-6_amd64.deb f3088de192415eb4a20ad1a6845e7239171e4209dc87ee1c6e6b2d9a44d51ec6 88730 libsasl2-modules-otp_2.1.25.dfsg1-6_amd64.deb 8839652731d89efe1aaa351ca71ffe2c63777d9b391988f0bb75ea60d897dd0c 67704 libsasl2-modules-sql_2.1.25.dfsg1-6_amd64.deb 34beb3d9845561ea66d0d415f0f9ffe9dc37841ae1f87f14102959d173af80b7 100200 libsasl2-modules-gssapi-mit_2.1.25.dfsg1-6_amd64.deb 7f0597fdca8cba2e0fef03857dab8c284904c8c98e47acc2ff3ce85044eaf528 360532 libsasl2-dev_2.1.25.dfsg1-6_amd64.deb a0f86e280a232cb424569a3c4d8f7f1078eef1299eeb72a877ba67b2691f2147 69332 libsasl2-modules-gssapi-heimdal_2.1.25.dfsg1-6_amd64.deb daf2a740761e15d71999725a7005d411d127d65a0cdb59fd853120f4c7c7a2f7 880914 cyrus-sasl2-dbg_2.1.25.dfsg1-6_amd64.deb b7009d9c8e0badc07e0d9eb4d2d1c4cb50e4ba2c363b4979e54bfcca9db8441b 89032 cyrus-sasl2-mit-dbg_2.1.25.dfsg1-6_amd64.deb ff53a6d0fea07ed668dd7e67fd553d5bd61648347893d649b50634009382a043 89526 cyrus-sasl2-heimdal-dbg_2.1.25.dfsg1-6_amd64.deb Files: 3f543d9e131b7643032ccdecfa52f75f 2556 libs standard cyrus-sasl2_2.1.25.dfsg1-6.dsc 30231ab9094a3a28d015bf5b9fac9129
Accepted php5 5.4.8-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 25 Oct 2012 16:05:34 +0200 Source: php5 Binary: php5 php5-common libapache2-mod-php5 libapache2-mod-php5filter php5-cgi php5-cli php5-fpm libphp5-embed php5-dev php5-dbg php-pear php5-curl php5-enchant php5-gd php5-gmp php5-imap php5-interbase php5-intl php5-ldap php5-mcrypt php5-mysql php5-mysqlnd php5-odbc php5-pgsql php5-pspell php5-recode php5-snmp php5-sqlite php5-sybase php5-tidy php5-xmlrpc php5-xsl Architecture: source amd64 all Version: 5.4.8-1 Distribution: experimental Urgency: low Maintainer: Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: libapache2-mod-php5 - server-side, HTML-embedded scripting language (Apache 2 module) libapache2-mod-php5filter - server-side, HTML-embedded scripting language (apache 2 filter mo libphp5-embed - HTML-embedded scripting language (Embedded SAPI library) php-pear - PEAR - PHP Extension and Application Repository php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-enchant - Enchant module for php5 php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) php5-gd- GD module for php5 php5-gmp - GMP module for php5 php5-imap - IMAP module for php5 php5-interbase - interbase/firebird module for php5 php5-intl - internationalisation module for php5 php5-ldap - LDAP module for php5 php5-mcrypt - MCrypt module for php5 php5-mysql - MySQL module for php5 php5-mysqlnd - MySQL module for php5 (Native Driver) php5-odbc - ODBC module for php5 php5-pgsql - PostgreSQL module for php5 php5-pspell - pspell module for php5 php5-recode - recode module for php5 php5-snmp - SNMP module for php5 php5-sqlite - SQLite module for php5 php5-sybase - Sybase / MS SQL Server module for php5 php5-tidy - tidy module for php5 php5-xmlrpc - XML-RPC module for php5 php5-xsl - XSL module for php5 Closes: 683415 687307 Changes: php5 (5.4.8-1) experimental; urgency=low . * Imported Upstream version 5.4.8 + Update patches for new release * Remove IfModule to always interpret PHP if the module is enabled * Fix extended DES crypt when salt != 9 * Fix libphp5-embed linking: + Expose all installed (and not built time) SAPIs via php-config --php-sapis + Add /usr/lib/php5 to php-config --ldflags output to allow linking with libphp5.so * Add new lintian-overrides for libphp5-embed * Add logrotate script for php5-fpm (Closes: #683415) * Add more warning text about new php5_cgi apache2 module (Closes: #687307) * Add Breaks: php5-suhosin so people don't try to use it with PHP 5.4 Checksums-Sha1: 3b639e3a7cb0229689ff4f75bf1d2a3476a7d73f 3471 php5_5.4.8-1.dsc 45512ad465eb8a13710ceb937b60f02cfa9908c8 15317282 php5_5.4.8-1.tar.gz 83916c05fac0be290d4d9bfe0bc3a8b39a1068e2 592354 php5-common_5.4.8-1_amd64.deb 11010bf38b7fa09e6e69dfa8bc3ef33c0c1ca9a8 2672094 libapache2-mod-php5_5.4.8-1_amd64.deb d981563c53a9f622a23f7a0e8c22db7d0ade685e 2670558 libapache2-mod-php5filter_5.4.8-1_amd64.deb ad34a46062df43ce39e277503047b8b1ea11d4a0 5111060 php5-cgi_5.4.8-1_amd64.deb 94a475393b2e669b2cb39e3dc0ecb504b09c680d 2561744 php5-cli_5.4.8-1_amd64.deb 895bdecf232191e9933bf65ea6229ae07baa4eda 2595690 php5-fpm_5.4.8-1_amd64.deb e99224da8d200189f0ad190e3898874dcfffb589 2669646 libphp5-embed_5.4.8-1_amd64.deb 8a36c1fe5ba31412c082d9be3d0cc583a16d5adb 498386 php5-dev_5.4.8-1_amd64.deb b139250758711d05c01673964b541e94cfe9dbb4 16001790 php5-dbg_5.4.8-1_amd64.deb 7673fbc3ec002ed993da4b0a68cf5809b798dd07 29180 php5-curl_5.4.8-1_amd64.deb e0f0e92a94954353c7f2ebcec9549da6075070c0 9928 php5-enchant_5.4.8-1_amd64.deb fa2ae77611b7a7fcaa8dc05ca89220537284b8ac 35692 php5-gd_5.4.8-1_amd64.deb a5ce37e8f01e4e567eac552ca265cdf6d3cb2f7b 17148 php5-gmp_5.4.8-1_amd64.deb e17c0c9bb4d24e443eb3348aa4e39a515a6f3522 35588 php5-imap_5.4.8-1_amd64.deb 2898576d8cb7a50e023effd9ac3ef2750bf72b0c 49592 php5-interbase_5.4.8-1_amd64.deb 5816237d03727bde65bf6e0c9e88d3c5d3ff96dd 72716 php5-intl_5.4.8-1_amd64.deb c918ca51e1176f90635633b5ef600f1ccad2c97e 21750 php5-ldap_5.4.8-1_amd64.deb 53b3fc84b7fe00346a9e0a27ef1705d21f229294 16066 php5-mcrypt_5.4.8-1_amd64.deb d244e8c8d1e24056d41bb0f460eeb46ecc681f43 80848 php5-mysql_5.4.8-1_amd64.deb 54f779a739e26dbee3db4b8f0ac6f689ec1c1e0a 163540 php5-mysqlnd_5.4.8-1_amd64.deb d5a7794704db743781d1da416c38c62c5aafa5cc 36660 php5-odbc_5.4.8-1_amd64.deb 8476fcff565750d53c5657ca78c577e248e0e9af 61426 php5-pgsql_5.4.8-1_amd64.deb 972fbe777f04d5133d9962f4c4f7536b677e8dd8 php5-pspell_5.4.8-1_amd64.deb
Accepted freedoom 0.8~beta1-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 26 Oct 2012 08:08:25 +0100
Source: freedoom
Binary: freedm freedoom
Architecture: source all
Version: 0.8~beta1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Jon Dowland j...@debian.org
Description:
freedm - multiplayer-oriented maps for Doom
freedoom - free game files for the 3D game DOOM
Closes: 691399
Changes:
freedoom (0.8~beta1-1) unstable; urgency=low
.
[ Fabian Greffrath ]
* Add myself to Uploaders.
* Imported Upstream version 0.8~beta1. Closes: #691399.
* Do not install empty usr/share/games/{doom,freedoom} directories.
* Mangle the upstream version in debian/watch,
they use minus instead of tilde to indicate beta versions.
* Convert to 3.0 (quilt) source format.
* Convert debian/rules to dh7 style, bump debhelper compat to 9,
simplify things a bit.
* Change versioned Conflicts to Breaks.
* Run wrap-and-sort -asb.
* Compress binary packages with xz.
.
[ Jon Dowland ]
* Initial parallel build support (much more work needed)
* Bump standards version. Changes:
* fold Build-Depends-Indep into Build-Depends (not needed for
Architecture: all)
Checksums-Sha1:
93254a7e772b29675e28bd731cd57acfffdef73c 2067 freedoom_0.8~beta1-1.dsc
b2ce09b4bfe8df3c99979138e2ecb6f146324d72 15830881
freedoom_0.8~beta1.orig.tar.gz
5a201d73ce3764a2aa3564b1e61a9a5ab1ece782 6053
freedoom_0.8~beta1-1.debian.tar.gz
d565dc227bb8c982b076d625e0ac908389842391 4320408 freedm_0.8~beta1-1_all.deb
c711668336a72746eb40eb501b564ef3f14f0481 6860110 freedoom_0.8~beta1-1_all.deb
Checksums-Sha256:
1c017a4192765c9a22fea37392b72533d61fda4bfae32b0f022a1e6a035cf728 2067
freedoom_0.8~beta1-1.dsc
b901ecafd1fd7bfeca443f87db6f695077002ee51df22afe7bcd50a64eef4faf 15830881
freedoom_0.8~beta1.orig.tar.gz
c3990e8bc3fc7a553458d6dd408082d783693c622d9755d81420d8a9f878990b 6053
freedoom_0.8~beta1-1.debian.tar.gz
51bc88fa657706d3a0e2417ace4bbff9976b2233ef6061b70e5bbde378dcdcc1 4320408
freedm_0.8~beta1-1_all.deb
91295f336d4828720010615a0bc267457211e45434f5b99d8535ff736337668b 6860110
freedoom_0.8~beta1-1_all.deb
Files:
d735f304d569fa0d146b73c90c5a061d 2067 games optional freedoom_0.8~beta1-1.dsc
e567dfbbcdb5b07a6247c73829e1bf0d 15830881 games optional
freedoom_0.8~beta1.orig.tar.gz
79095fae6778fb2bc328bfd668104234 6053 games optional
freedoom_0.8~beta1-1.debian.tar.gz
44fbfd4a250a3cca65dcbc73670e272d 4320408 games optional
freedm_0.8~beta1-1_all.deb
bf90c3ab0673c857757e72df30862f02 6860110 games optional
freedoom_0.8~beta1-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQioz7AAoJEAkHQJYGF7AP/3i9R24ysJymGXG+c0OFH6Q3
TZKYMZZGnRhrIsez5uW4pCEXR5W9r9b0O89qJQ+w6gEIaq0+xBAtzyavd9xB6yG9
x/+Z2LQw63qAwIKr7PPBAeww9pYZHQ1v9iD/zeEyQPdzmoSEHQR16fg4L1A9pu8h
19gnpfTsvIFI4Gn+IYvP/j1z4Al4MPxudJxe23PN/72OSDP9QWAqiLR/DsAZYtMC
D5OFO86p0wUgRly6KX2q4HuW88eclr4kgmza/yFv1RYdocz9KK4hbkjYDbYSto4+
02+31VsGQ2IOLT4S9WvMb6Wi7qDQo+6dsaC93nWMuSh9790eApVheaA9ygF+AjX/
yoysgtK/T1s+2LYNC/256ICUkCVeYfHO1qkxC9ELi9/UupRCPFrUsSMNvrUXj6N3
jrjGZoE1B+cLM92q2lAJM/7O3DE618ESo9lfv01Kta+PtlzzaQky0K4s1EZ8f/Ww
gxaRuufBHCDOZBYVs0o5dt/hS3S5LuDafPap06ivzS/ateZpPYkIhtY3epMZmOLu
lbuBfj1AOUvtHX/mRZ9dA+UINBfJppVaEANe7IxFJnY2jM8rciW6HUy0Ckk4kejd
H7COQHcfzNh0lca4iJw/psz7Zpe1ecffT9Y5TKuUAFvesOJ1c7RjO96cgkBFUs53
G/a5A6IzbpjxpSmwI33Z
=BoAN
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1trk1l-0005df...@franck.debian.org
Accepted glibc-doc-reference 2.16-0experimental1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 14:03:26 +0100 Source: glibc-doc-reference Binary: glibc-doc-reference Architecture: all source Version: 2.16-0experimental1 Distribution: experimental Urgency: low Maintainer: GNU Libc Maintainers debian-gl...@lists.debian.org Changed-By: Adam Conrad adcon...@0c3.net Description: glibc-doc-reference - GNU C Library: Documentation Changes: glibc-doc-reference (2.16-0experimental1) experimental; urgency=low . * New upstream version: - Revert to Makefile and libc-texinfo.sh from 2.13 (with some tweaks), as the 2.16 versions are rather sad out-of-tree. - Create a version.texi with the upstream version, as this would normally be generated by the glibc build when in-tree. Checksums-Sha1: abecea48e6400a9345129d7678219842bd79c433 1480 glibc-doc-reference_2.16-0experimental1.dsc e7e8cf3bbee70a2e2dc18723f20f15335b503c6f 775395 glibc-doc-reference_2.16.orig.tar.gz 260a3311b98e54058e3c9f27c67e6beafe77fafa 16668 glibc-doc-reference_2.16-0experimental1.diff.gz b0ca745300a83dadc426248395a39900fd1830c3 5313160 glibc-doc-reference_2.16-0experimental1_all.deb Checksums-Sha256: 687c3e39a61a1a6ac01785eb9174ce12afb3140f0ea796e5f3654118fc3017b1 1480 glibc-doc-reference_2.16-0experimental1.dsc 89e261dacfa3f1916d9b7e8f1217b4cadf3768d79760fbff691696dee1d540fc 775395 glibc-doc-reference_2.16.orig.tar.gz adad06998c6179001ced1ae4362b9f3409b061d4665ac9f55055c6672345a90e 16668 glibc-doc-reference_2.16-0experimental1.diff.gz 9c6305fda4ebcc87eb802ea949b98edafa721339ef04f2166345852ae2f66543 5313160 glibc-doc-reference_2.16-0experimental1_all.deb Files: fbb12fa58a1a3118f1cc16c4d7fa4f52 1480 non-free/doc optional glibc-doc-reference_2.16-0experimental1.dsc 76f2034ae917691110a6a0f3aed626e3 775395 non-free/doc optional glibc-doc-reference_2.16.orig.tar.gz 34e56d5630aebc5a4df9d567bc6a7506 16668 non-free/doc optional glibc-doc-reference_2.16-0experimental1.diff.gz 21bb513e369e0f2edf7db9d2f07301bd 5313160 non-free/doc optional glibc-doc-reference_2.16-0experimental1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCKrbAACgkQvjztR8bOoMmPsgCgnzjlMFWzAzi9RUrjb5qI1wxu nKoAoOUwcXDRmpdp9iXY9Kt40j76EV0h =4Bsh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trm8g-0007f6...@franck.debian.org
Accepted eglibc 2.13-36 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 14:28:06 + Source: eglibc Binary: libc-bin libc-dev-bin glibc-doc eglibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-prof libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-prof libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-prof libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-prof libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-s390x libc6-dev-s390x libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libc6-loongson2f libnss-dns-udeb libnss-files-udeb Architecture: source all amd64 Version: 2.13-36 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno aure...@debian.org Changed-By: Aurelien Jarno aure...@debian.org Description: eglibc-source - Embedded GNU C Library: sources glibc-doc - Embedded GNU C Library: Documentation libc-bin - Embedded GNU C Library: Binaries libc-dev-bin - Embedded GNU C Library: Development binaries libc0.1- Embedded GNU C Library: Shared libraries libc0.1-dbg - Embedded GNU C Library: detached debugging symbols libc0.1-dev - Embedded GNU C Library: Development Libraries and Header Files libc0.1-dev-i386 - Embedded GNU C Library: 32bit development libraries for AMD64 libc0.1-i386 - Embedded GNU C Library: 32bit shared libraries for AMD64 libc0.1-i686 - Embedded GNU C Library: Shared libraries [i686 optimized] libc0.1-pic - Embedded GNU C Library: PIC archive library libc0.1-prof - Embedded GNU C Library: Profiling Libraries libc0.1-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb) libc0.3- Embedded GNU C Library: Shared libraries libc0.3-dbg - Embedded GNU C Library: detached debugging symbols libc0.3-dev - Embedded GNU C Library: Development Libraries and Header Files libc0.3-i686 - Embedded GNU C Library: Shared libraries [i686 optimized] libc0.3-pic - Embedded GNU C Library: PIC archive library libc0.3-prof - Embedded GNU C Library: Profiling Libraries libc0.3-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb) libc0.3-xen - Embedded GNU C Library: Shared libraries [Xen version] libc6 - Embedded GNU C Library: Shared libraries libc6-amd64 - Embedded GNU C Library: 64bit Shared libraries for AMD64 libc6-dbg - Embedded GNU C Library: detached debugging symbols libc6-dev - Embedded GNU C Library: Development Libraries and Header Files libc6-dev-amd64 - Embedded GNU C Library: 64bit Development Libraries for AMD64 libc6-dev-i386 - Embedded GNU C Library: 32-bit development libraries for AMD64 libc6-dev-mips64 - Embedded GNU C Library: 64bit Development Libraries for MIPS64 libc6-dev-mipsn32 - Embedded GNU C Library: n32 Development Libraries for MIPS64 libc6-dev-powerpc - Embedded GNU C Library: 32bit powerpc development libraries for p libc6-dev-ppc64 - Embedded GNU C Library: 64bit Development Libraries for PowerPC64 libc6-dev-s390 - Embedded GNU C Library: 32bit Development Libraries for IBM zSeri libc6-dev-s390x - Embedded GNU C Library: 64bit Development Libraries for IBM zSeri libc6-dev-sparc64 - Embedded GNU C Library: 64bit Development Libraries for UltraSPAR libc6-i386 - Embedded GNU C Library: 32-bit shared libraries for AMD64 libc6-i686 - Embedded GNU C Library: Shared libraries [i686 optimized] libc6-loongson2f - Embedded GNU C Library: Shared libraries (Loongson 2F optimized) libc6-mips64 - Embedded GNU C Library: 64bit Shared libraries for MIPS64 libc6-mipsn32 - Embedded GNU C Library: n32 Shared libraries for MIPS64 libc6-pic - Embedded GNU C Library: PIC archive library libc6-powerpc - Embedded GNU C Library: 32bit powerpc shared libraries for ppc64 libc6-ppc64 - Embedded GNU C Library: 64bit Shared libraries for PowerPC64 libc6-prof - Embedded GNU C Library: Profiling Libraries libc6-s390 - Embedded GNU C Library: 32bit Shared libraries for IBM zSeries libc6-s390x - Embedded GNU C Library: 64bit Shared libraries for IBM zSeries libc6-sparc64 - Embedded GNU C Library: 64bit Shared libraries for UltraSPARC libc6-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb) libc6-xen - Embedded GNU C Library: Shared libraries [Xen version] libc6.1- Embedded GNU C Library: Shared libraries libc6.1-alphaev67 - Embedded GNU C Library: Shared libraries (EV67 optimized) libc6.1-dbg - Embedded GNU C Library: detached debugging symbols libc6.1-dev - Embedded GNU C Library: Development Libraries and Header Files libc6.1-pic - Embedded GNU C Library: PIC archive library libc6.1-prof - Embedded GNU C Library: Profiling Libraries libc6.1-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb) libnss-dns-udeb
Accepted gnome-settings-daemon 3.4.2+git20120925.a4c817-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 19:04:37 +0200 Source: gnome-settings-daemon Binary: gnome-settings-daemon gnome-settings-daemon-dev Architecture: source amd64 Version: 3.4.2+git20120925.a4c817-2 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Changed-By: Josselin Mouette j...@debian.org Description: gnome-settings-daemon - daemon handling the GNOME session settings gnome-settings-daemon-dev - Headers for building applications communicating with gnome-settin Closes: 687978 Changes: gnome-settings-daemon (3.4.2+git20120925.a4c817-2) unstable; urgency=low . * Pull upstream fixes for the print-notifications plugin: + 01_print_proxy.patch: don’t create an unused GDBusProxy. + 02_print_init.patch: delay CUPS initialization. + 03_print_async.patch: test asynchronously whether the CUPS server actually works. Closes: #687978. * 11_numlock_loop.patch: patch from Andrew Potter to fix infinite loop triggered by switching the numlock status. * gnome-settings-daemon.gsettings-override: dropped, NumLock saving is back to work now. Checksums-Sha1: d3fd2e427d8576c157458ccb9cb0718343693d21 2537 gnome-settings-daemon_3.4.2+git20120925.a4c817-2.dsc 63b33ef7f03e285515f4263e3be48d8c690bc41c 34250 gnome-settings-daemon_3.4.2+git20120925.a4c817-2.debian.tar.gz 04a2bea5619974b4f0d2775550a064b36d322d7f 926626 gnome-settings-daemon_3.4.2+git20120925.a4c817-2_amd64.deb 959650aad87579088650f0eeb778a2252fd2a442 69060 gnome-settings-daemon-dev_3.4.2+git20120925.a4c817-2_amd64.deb Checksums-Sha256: 24196aa1b4efc01e4b846d49af66744692d40ae054f2b6a918e4a2100e8a3c8e 2537 gnome-settings-daemon_3.4.2+git20120925.a4c817-2.dsc 07d2a9e2057945b0339a6f18543f7fad2d54bca151635eb9c171ee1773c39230 34250 gnome-settings-daemon_3.4.2+git20120925.a4c817-2.debian.tar.gz 7426783508ad4aed3390258824dd513bf2611bbb78ec25007a9923c9bf073d3f 926626 gnome-settings-daemon_3.4.2+git20120925.a4c817-2_amd64.deb 1c79185926f0230c7e3243f239e4ee469bd5e3b16bf6d7cda039807bcfbc4634 69060 gnome-settings-daemon-dev_3.4.2+git20120925.a4c817-2_amd64.deb Files: a817fe47532b2a86deebd7809a54cc59 2537 gnome optional gnome-settings-daemon_3.4.2+git20120925.a4c817-2.dsc cd0feb1c5312729d1c974729d7096644 34250 gnome optional gnome-settings-daemon_3.4.2+git20120925.a4c817-2.debian.tar.gz 83c8892423a03c733a917d7457b94b0f 926626 gnome optional gnome-settings-daemon_3.4.2+git20120925.a4c817-2_amd64.deb 585f8aeab941ac34e817eb700c703cbd 69060 libdevel optional gnome-settings-daemon-dev_3.4.2+git20120925.a4c817-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQisfErSla4ddfhTMRAm8ZAKDapu3vuPgfdeQTnG+ymDpzBwAUuQCdHGtr MEkkCEPCXM0Hx8sbv9k0eug= =EYIT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trnn5-0002bz...@franck.debian.org
Accepted rpart 4.0-1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 26 Oct 2012 12:39:21 -0500 Source: rpart Binary: r-cran-rpart Architecture: source i386 Version: 4.0-1-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel e...@debian.org Changed-By: Dirk Eddelbuettel e...@debian.org Description: r-cran-rpart - GNU R package for recursive partitioning and regression trees Changes: rpart (4.0-1-1) unstable; urgency=low . * New upstream release Checksums-Sha1: fef286e9d5ef2d9c817c8e0729a19c40a38ed6aa 1037 rpart_4.0-1-1.dsc 27ced0800bb4bb07beb865f200ca459abc032bf1 269815 rpart_4.0-1.orig.tar.gz 1e666c3f4e9f2086c93a5ca7a2b4b81293470c68 3312 rpart_4.0-1-1.diff.gz 62f91d5deda35996b4c3566dbc3737266221e840 362302 r-cran-rpart_4.0-1-1_i386.deb Checksums-Sha256: b6288af528eda48c3db3f5f630bed2a7711900d395fc06afd61c621f0be5 1037 rpart_4.0-1-1.dsc 3e39c25b24f11c469fe309e2c5b7ac3aacdbcf4cb1cbaace024afa51f60c5ac7 269815 rpart_4.0-1.orig.tar.gz 4ed832cbcff664a95c23f488b85d88f53093ee4be4aa8e7ee6b4baddb53b8b96 3312 rpart_4.0-1-1.diff.gz c24ead2a02697ff831847d9c9b759059352edd94b19e8cf70e6301e6b14e8a3c 362302 r-cran-rpart_4.0-1-1_i386.deb Files: 90a1ab11264f00eee692dd36e51b42ef 1037 gnu-r optional rpart_4.0-1-1.dsc 2f2f6c2271d38739960142b300f49e9d 269815 gnu-r optional rpart_4.0-1.orig.tar.gz f504568c2e795e27d3a4890b36166f34 3312 gnu-r optional rpart_4.0-1-1.diff.gz fc2476dc7a7514b7a452503715f6152c 362302 gnu-r optional r-cran-rpart_4.0-1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFQist/CZSR95Gw07cRApFWAKCHEeZvUe0utGQHm+l0Yqtg61sntQCgl43O cibnnF6OVzklRacmsYqbU2g= =kEh7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tro0k-0005yj...@franck.debian.org
Accepted meta-gnome3 1:3.4+5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 26 Oct 2012 19:53:42 +0200
Source: meta-gnome3
Binary: gnome-core gnome gnome-desktop-environment gnome-platform-devel
gnome-core-devel gnome-devel gnome-dbg gnome-api-docs
Architecture: source all amd64
Version: 1:3.4+5
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers
pkg-gnome-maintain...@lists.alioth.debian.org
Changed-By: Josselin Mouette j...@debian.org
Description:
gnome - Full GNOME Desktop Environment, with extra components
gnome-api-docs - API reference documentation for the GNOME libraries
gnome-core - GNOME Desktop Environment -- essential components
gnome-core-devel - GNOME Desktop Environment -- development components
gnome-dbg - debugging symbols for the GNOME desktop environment
gnome-desktop-environment - The GNOME Desktop Environment - transitional
package
gnome-devel - GNOME Desktop Environment -- development tools
gnome-platform-devel - GNOME development platform
Changes:
meta-gnome3 (1:3.4+5) unstable; urgency=low
.
* Remove unneeded Suggests.
* Move gnome-boxes to Suggests, it’s not ready for prime-time.
* Add dependencies to libreoffice-{writer,calc,impress} because
libreoffice-gnome doesn’t install any actual module.
* Only suggest iceweasel-l10n-all because stupid iceweasel will ask to
remove all installed extensions (including language packs) upon
upgrades. So long for full i18n out of the box.
* Add caribou-antler so that the fallback session has on-screen
keyboard too.
Checksums-Sha1:
5d67320a3bc8b08f25722758b4e3a508d11f7a34 1535 meta-gnome3_3.4+5.dsc
b90187610d3ed32fa8a42ed46918469c1c5a70ec 26206 meta-gnome3_3.4+5.tar.gz
9865c5ce5471411ddae4ad8ca9bd627728cf98c9 19714
gnome-desktop-environment_3.4+5_all.deb
19514370fd78cb167f6374fc82e963645cb9267a 19760 gnome-devel_3.4+5_all.deb
a595a82eab1ccec8f3e97d975c3fcfac41dcb6fc 19906 gnome-api-docs_3.4+5_all.deb
e7593fff4dd704bb3f3515c5b737a059fa8f1eb5 21192 gnome-core_3.4+5_amd64.deb
2f0a4e1bb2fa82de5e84a14c7f360c47b8813839 21166 gnome_3.4+5_amd64.deb
7b95950dd06993aa0192ccc0d680cb260cdc2d34 19946
gnome-platform-devel_3.4+5_amd64.deb
75ac8441e2caefef9e74ef9f0958f51561a22813 20460 gnome-core-devel_3.4+5_amd64.deb
4228e0a9bad69a0689d6f68206ef5984c3dbceff 19784 gnome-dbg_3.4+5_amd64.deb
Checksums-Sha256:
9619e9ffe6d7f756e252accb426f236ff6231597bfa0bff12dd56ddfb49865b7 1535
meta-gnome3_3.4+5.dsc
4b9c32f81d37b7f9ddeddbafe3065b3482fe8a825f68b1dc921ceaa838fa63bb 26206
meta-gnome3_3.4+5.tar.gz
2790826fdba1585c38ca10183a61370086ca0c1670c8d06eb2d10895c1a82705 19714
gnome-desktop-environment_3.4+5_all.deb
0488807be3b2730c4a1ff8a8085ca986bb23d79889fc940ab23abdd678180602 19760
gnome-devel_3.4+5_all.deb
946392aa8486b484192a259583449c3ae59f73d5f17c2ff976665d21a189ddc1 19906
gnome-api-docs_3.4+5_all.deb
9b71651718d859681be1846d64e54af97221701658a0ba49b0f71b8fb42781f2 21192
gnome-core_3.4+5_amd64.deb
6ad0413c524632cd38719ab96b224a6303112185448396e2f1efc09ec96ab1c8 21166
gnome_3.4+5_amd64.deb
f8ada1f72aae94917365b2e452cdf73dcb7f463d904ae199fccb7b1c9d115c8a 19946
gnome-platform-devel_3.4+5_amd64.deb
f2e70e28e1f5635f7ac5d867de4fb1a53aa9fc8831e93b168b361bc35f52b1ce 20460
gnome-core-devel_3.4+5_amd64.deb
6cba20bd5c672bcc1ea625ba643767d17f56e60e2b9726ef36a617dc63a99b66 19784
gnome-dbg_3.4+5_amd64.deb
Files:
ce705cafe86359a8dd3d6a13613faa97 1535 metapackages optional
meta-gnome3_3.4+5.dsc
bfaa40ca07413b5c08085dd104e248e4 26206 metapackages optional
meta-gnome3_3.4+5.tar.gz
5bcdfc56c1c52d71e4ce954d4c947474 19714 oldlibs extra
gnome-desktop-environment_3.4+5_all.deb
cd9f188deef8f2f24d75a02ff175eb8e 19760 devel optional gnome-devel_3.4+5_all.deb
5437dc25b736e8e095529b1d4cf287df 19906 doc optional
gnome-api-docs_3.4+5_all.deb
f71d9b9082453df5799ed6486e8fe1b7 21192 metapackages optional
gnome-core_3.4+5_amd64.deb
c286429f443b528a1a2ebf8c72e70e36 21166 metapackages optional
gnome_3.4+5_amd64.deb
1f62ff9e6ee4a28593734bb31c860def 19946 devel optional
gnome-platform-devel_3.4+5_amd64.deb
2bd7b13f41b9a289b6b0659aeb2557c2 20460 devel optional
gnome-core-devel_3.4+5_amd64.deb
11d19b9309d1119f2f40a1cd008b1067 19784 debug extra gnome-dbg_3.4+5_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iD8DBQFQis6srSla4ddfhTMRAt+FAJ9XWBMj+3uin+TLxEWGDcGAquwR7ACaA2ch
5bxDC06cM1KNS/VLrbD7KJo=
=5pKt
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1troeq-00015r...@franck.debian.org
Accepted iceape 2.7.10-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 16:38:17 +0200 Source: iceape Binary: iceape iceape-browser iceape-dbg iceape-chatzilla iceape-l10n-all iceape-l10n-be iceape-l10n-ca iceape-l10n-cs iceape-l10n-de iceape-l10n-en-gb iceape-l10n-es-ar iceape-l10n-es-es iceape-l10n-fi iceape-l10n-fr iceape-l10n-gl iceape-l10n-hu iceape-l10n-it iceape-l10n-ja iceape-l10n-lt iceape-l10n-nb-no iceape-l10n-nl iceape-l10n-pl iceape-l10n-pt-pt iceape-l10n-ru iceape-l10n-sk iceape-l10n-sv-se iceape-l10n-tr iceape-l10n-zh-cn Architecture: source amd64 all Version: 2.7.10-1 Distribution: unstable Urgency: high Maintainer: Maintainers of Mozilla-related packages pkg-mozilla-maintain...@lists.alioth.debian.org Changed-By: Mike Hommey gland...@debian.org Description: iceape - The Iceape Internet Suite iceape-browser - Transitional package to iceape iceape-chatzilla - Iceape Chatzilla IRC client iceape-dbg - Debugging symbols for the Iceape Internet Suite iceape-l10n-all - All language packages for Iceape (meta) iceape-l10n-be - Belarusian language package for Iceape iceape-l10n-ca - Catalan language package for Iceape iceape-l10n-cs - Czech language package for Iceape iceape-l10n-de - German language package for Iceape iceape-l10n-en-gb - English (United Kingdom) language package for Iceape iceape-l10n-es-ar - Spanish (Argentina) language package for Iceape iceape-l10n-es-es - Spanish (Spain) language package for Iceape iceape-l10n-fi - Finnish language package for Iceape iceape-l10n-fr - French language package for Iceape iceape-l10n-gl - Galician language package for Iceape iceape-l10n-hu - Hungarian language package for Iceape iceape-l10n-it - Italian language package for Iceape iceape-l10n-ja - Japanese language package for Iceape iceape-l10n-lt - Lithuanian language package for Iceape iceape-l10n-nb-no - Norwegian Bokmål (Norway) language package for Iceape iceape-l10n-nl - Dutch language package for Iceape iceape-l10n-pl - Polish language package for Iceape iceape-l10n-pt-pt - Portuguese (Portugal) language package for Iceape iceape-l10n-ru - Russian language package for Iceape iceape-l10n-sk - Slovak language package for Iceape iceape-l10n-sv-se - Swedish (Sweden) language package for Iceape iceape-l10n-tr - Turkish language package for Iceape iceape-l10n-zh-cn - Chinese (China) language package for Iceape Changes: iceape (2.7.10-1) unstable; urgency=high . * New manually-made upstream release. * Fixes for mfsa2012-90, also known as CVE-2012-4194 and CVE-2012-4196. Checksums-Sha1: 00a5f0983c3a35702301713f843baa744532e638 10627 iceape_2.7.10-1.dsc d1923db06d4a6d73e7bf9f1f6eef76230a5aca4b 22970 iceape_2.7.10.orig-compare-locales.tar.bz2 ca8dbcd8160af41c216a6389d82806ea888453dc 543478 iceape_2.7.10.orig-l10n-be.tar.bz2 a9e8a37148248b2d741b763826228bf04feacd5b 680417 iceape_2.7.10.orig-l10n-ca.tar.bz2 2f230e2dec18e34cd4809a2ca1b309e71a9fdb3e 667563 iceape_2.7.10.orig-l10n-cs.tar.bz2 7ec9d21d790488572a56d7fbebcc65b632778537 720102 iceape_2.7.10.orig-l10n-de.tar.bz2 5da828ede9f809360508318ac73e1b85db37183b 543935 iceape_2.7.10.orig-l10n-en-GB.tar.bz2 88f37ee99834a9d8e7108e2631abea6695ef90bf 653390 iceape_2.7.10.orig-l10n-es-AR.tar.bz2 9ee07ace4d3888f9618ff35360b27d144b32ac1e 601192 iceape_2.7.10.orig-l10n-es-ES.tar.bz2 5a3311386557c7973b24309b5b6fb8d52ad549e2 668711 iceape_2.7.10.orig-l10n-fi.tar.bz2 8024251eabfda551b1ca4b0bd5a404091a4c3126 1043456 iceape_2.7.10.orig-l10n-fr.tar.bz2 490693a16c8e1daf1f8833ebb68b94100bd3fed7 614176 iceape_2.7.10.orig-l10n-gl.tar.bz2 96f66135811d807fbe7cf37bd0b5c1e805e4d673 1274241 iceape_2.7.10.orig-l10n-hu.tar.bz2 2a175f44bc20e0756cec45ee049afe63494b940b 573909 iceape_2.7.10.orig-l10n-it.tar.bz2 2e355985e643b30d56bcc93de548e16432d11571 921424 iceape_2.7.10.orig-l10n-ja.tar.bz2 e09411b221f96e4d564299893831150ef4ab4293 998215 iceape_2.7.10.orig-l10n-lt.tar.bz2 2c46ad21d81f4c4fa92fce213a9c8f222445cc34 657453 iceape_2.7.10.orig-l10n-nb-NO.tar.bz2 5ba7d67a5adceb29a1accb71f05d578c354c2772 1264502 iceape_2.7.10.orig-l10n-nl.tar.bz2 8e89eb1f919cc0bbcdef9cd60a698b54f3099892 1745956 iceape_2.7.10.orig-l10n-pl.tar.bz2 fd739a202f38cf48368ca24da28bf4fa8b83bf35 921508 iceape_2.7.10.orig-l10n-pt-PT.tar.bz2 29f0a0b6bcfb16fc90e09950d86450fcb024d9a3 1145461 iceape_2.7.10.orig-l10n-ru.tar.bz2 81030386cc7f3bbdff30638a2d19589cf82535f4 1613328 iceape_2.7.10.orig-l10n-sk.tar.bz2 ff7a21cd704469bffe8fcea556338835864c81dd 1041398 iceape_2.7.10.orig-l10n-sv-SE.tar.bz2 bf77bb0805e5bb6be73d428053a7faa6c55c7705 658669 iceape_2.7.10.orig-l10n-tr.tar.bz2 6912bc0b5484bc245bd74d45c3bb3916e1eb6a9d 607655 iceape_2.7.10.orig-l10n-zh-CN.tar.bz2 d0f51750c208eb5d68d72a02a8ce9ab0ac40baa8 93938322 iceape_2.7.10.orig.tar.bz2 e858b9f539689a0e5e5a2a2184af953f33da11bf 242599 iceape_2.7.10-1.debian.tar.gz e4373007e2480a908a83d281b802b96c865ba92c 19923558 iceape_2.7.10-1_amd64.deb
Accepted drupal7 7.14-1.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 19 Oct 2012 13:08:29 -0500 Source: drupal7 Binary: drupal7 Architecture: source all Version: 7.14-1.1 Distribution: unstable Urgency: low Maintainer: Luigi Gangitano lu...@debian.org Changed-By: Gunnar Wolf gw...@debian.org Description: drupal7- fully-featured content management framework Changes: drupal7 (7.14-1.1) unstable; urgency=low . * Non-maintainer upload. * Incorporated the fix for SA-CORE-2012-003 (the full diff between 7.15 and 7.16) Checksums-Sha1: a94a30f0432a580ffeb3d5351172445e1fed546d 1829 drupal7_7.14-1.1.dsc 339ae0634ac330cc9295ee8c441a33e4b8a3484b 191330 drupal7_7.14-1.1.debian.tar.gz fdb7a65f80d531d24f3e540b02194c43cb5316cf 3174850 drupal7_7.14-1.1_all.deb Checksums-Sha256: ab2f5067e93233a799d0af7ce48f6501535f0536f763b0b60453a24d336eeaed 1829 drupal7_7.14-1.1.dsc 15a1d299f772c730516a597ad5b700502f58ae615538f0560496b6d0af327a30 191330 drupal7_7.14-1.1.debian.tar.gz 73c825d1059f5266052fc954717e91cd33c8355df5a2bd19d37a099a28859aa7 3174850 drupal7_7.14-1.1_all.deb Files: 56147b8bd093443b48c9253b290a2fbb 1829 web extra drupal7_7.14-1.1.dsc c6f546c61eb8c8cd011feed2e3427381 191330 web extra drupal7_7.14-1.1.debian.tar.gz 65cbf31badcba33ff3b88ee4dcf07a4c 3174850 web extra drupal7_7.14-1.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQgZnuAAoJEGc6A+TB25IfAwwQAIOKEh5TiRuhDrj/kxUEG/ba R0dAs2j8lhjHi2IetxslKxsHutGNw/7sE1FbgIglBr1OHS3hzGKbpLT5NzkKA/qi /w5Uh8X9VafG2LTAOEN6ZV9NrwcVPizpfVHyVOy5xwg6y2LwhKlSTPVfK3FLcsJH F6JvtJKOvFZPD2yXSbAujdJgV2/V6wrsFt1odZE3dHp4hSn94++yxe4UCwfYkXPV jA1kJkvqoTu1aXfb+NdPvRGrKnOcfbImia0DqWdJYOIo1WshSXrFTKW7+HhRzIW6 YjNW+KOFXTSVIDuY4x/N7W0+n45XQNdrQ7nDOOGL/1tixzOhsup4ZTFRHg/1PQO/ LvZpUSP6oNNIMVaew2i5A40kirEWZGp9vmPwyzSv1P+vpumBCj24U5WrTIo9I3Hi XCZONFG/et8t/41m3ov+WJ32+8+Mgt/agOqp7v3m0rwesm+OXnaWkccLji4g2nGm OHwt2nUUJp0LYocZML2GXBi52qmo3F9dXBEsVAR2SIhkH1dxZMcNyMiNNXYI4URJ u0CS4ih38TFQNc+wDkeWo/xukOfr1stWyn0I2BnpImJEN7UGLqnPmYWkzkRj3sCz a9+Ml7BPZwtRA2LtdO1yknO6nldDzN9NJ9Tfp0t1NBkv5jpInAYnGx9hSyZZPJYx H4jhIZuTus6v3G4Wrbmc =DNdr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trown-0003ed...@franck.debian.org
Accepted apt-show-versions 0.20 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Fri, 26 Oct 2012 20:59:14 +0200 Source: apt-show-versions Binary: apt-show-versions Architecture: source all Version: 0.20 Distribution: unstable Urgency: low Maintainer: Christoph Martin christoph.mar...@uni-mainz.de Changed-By: Christoph Martin christoph.mar...@uni-mainz.de Description: apt-show-versions - lists available package versions with distribution Closes: 689681 Changes: apt-show-versions (0.20) unstable; urgency=low . * fix race condition in parallel build mode. (Closes: #689681) * add stable-updates testing-proposed-updates and testing-updates to list of official suites Checksums-Sha1: 5b46f79575e071cefcc0df00bce7ac24b65aeed7 982 apt-show-versions_0.20.dsc ed321630772d9ec99575ba680d38e25aade96b91 32699 apt-show-versions_0.20.tar.gz d37d71e74ae638c7361c2aadfcdda81628351a77 34856 apt-show-versions_0.20_all.deb Checksums-Sha256: 9c95c8dacf0ad36467327147f7ee704fdf28ba6189f3d7e9a546a1626725a0db 982 apt-show-versions_0.20.dsc 43fc0e860b7e2bd7b9f89e8228aceff58b0299fd81e2190c578e0a0e4e02a520 32699 apt-show-versions_0.20.tar.gz fc614c9bb1199376a0421c18ceea2dd2324448c36985ae00dc6e6e06dedfaef4 34856 apt-show-versions_0.20_all.deb Files: 123220edb58aab4f6b5100f2fd146c27 982 admin optional apt-show-versions_0.20.dsc 70830e34bf7481e6f223d75e6ee9fe7e 32699 admin optional apt-show-versions_0.20.tar.gz 924409fe0e488bf1bb0c09d1440c5a3f 34856 admin optional apt-show-versions_0.20_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAlCK5VYACgkQgeVih7XOVJcICgCffZXg42+7iVqy9WIFTN8yp/cb wRIAnindakztQRrxOJUsNa+55xqkcmtd =wjVz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trpso-0001iq...@franck.debian.org
Accepted libgnupg-interface-perl 0.46-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 26 Oct 2012 21:41:43 +0200 Source: libgnupg-interface-perl Binary: libgnupg-interface-perl Architecture: source all Version: 0.46-1 Distribution: experimental Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Salvatore Bonaccorso car...@debian.org Description: libgnupg-interface-perl - Perl interface to GnuPG Changes: libgnupg-interface-perl (0.46-1) experimental; urgency=low . [ intrigeri ] * Email change: intrigeri - intrig...@debian.org . [ Salvatore Bonaccorso ] * Imported Upstream version 0.46 * Update debian/copyright file. Update format to copyright-format 1.0 as released together with Debian policy 3.9.3. Update Upstream-Contact to Alex Vandiver ale...@cpan.org and update comment on license. Update copyright years for bundled copy of Module::Install. Update copyright years for debian/* packaging. * Bump Standards-Version to 3.9.4 * Refresh Make-get_secret_keys-and-get_public_keys-methods-wor.patch patch Checksums-Sha1: 65862d0a508c77b502b1af2e6f8a0751219c2ec3 2290 libgnupg-interface-perl_0.46-1.dsc 0d084507f2c09eca158c3948e35567d69fff768c 67892 libgnupg-interface-perl_0.46.orig.tar.gz 55e3c9172ad5cc299f9663fee57a2644d88372ad 5418 libgnupg-interface-perl_0.46-1.debian.tar.gz 6d72369f8b99235bd5d0b1d1186e19e678875f32 74190 libgnupg-interface-perl_0.46-1_all.deb Checksums-Sha256: 20dd1f64f88199147e680b26b094e30180080514ae3eb83cbee14b08dc99e6f3 2290 libgnupg-interface-perl_0.46-1.dsc c0d2fbb762a4045008e11db7614585165591df1f384fe01510f95e922e39930e 67892 libgnupg-interface-perl_0.46.orig.tar.gz 8f76a4d46e2bb19d852b765027c3e7967a4a9b7006abab1eea4151c9230a627b 5418 libgnupg-interface-perl_0.46-1.debian.tar.gz 57f0b8ac91871900e2a30b2567b4dc1b3d91894c4949d7f43f0069d3f7a5093c 74190 libgnupg-interface-perl_0.46-1_all.deb Files: 4dbd409c374530fc27f92a5eb4315f18 2290 perl optional libgnupg-interface-perl_0.46-1.dsc 16339800f127c51a34188a0bf7103219 67892 perl optional libgnupg-interface-perl_0.46.orig.tar.gz 434e2c3cd8a93be321ba34919cde1927 5418 perl optional libgnupg-interface-perl_0.46-1.debian.tar.gz ce38fe2cee250a282dfbe4415a578f60 74190 perl optional libgnupg-interface-perl_0.46-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQiuf9AAoJEHidbwV/2GP+S2AP/1a3e9L7eBkaISZioZ9DW1Mi BxzFZB/fsfC0Ws1TaB4qvJjOa//xpfJFaf9AUPIC9hJ1U+JyugrUeD+9LSXNcJtM 4TEzZjYzKhlOz0cEmgL+1v4AwqHL7cF0ql8eZqGatgK+cogZ+wQAJqiH3AjBvFve KtToeEC0lSJF8JU0ehius3nZUUjJlkEAVRA3dahgjGM1pJREcU4VDTdaQw12pGHU eTrTwJvlttApbIyAQ6xsfoIW1ufJH6/run+VF6IW1zCXQApdLPMA4iUM0QlZyc/I VvKSd34QfC1S0cb2Lhk1aJhhfG8QJop3y2ZVT9MchUg4gWgNsBBIfwZU4+BnhCKD 0QprhfA1qzPbvdLbp3ajSaPETEmGBDqvLhtZB41MAslFimBonVrs8TwmGv1QOH6h d9uavsbIe18Nlytyz3GPo7If1aY+zA4tkLziUpdBFFnpccsAXbdaNSILRUUuFi10 0w70Lzt9gpzy95L1PXNOdk9prDyQduR/wKUDMOIEIxB7zGybLyJcdJ/N9MThsezf rkq3K8NWCvg9TNfmenYoJ38OXU9rmTYJpESvZ65U1E/O/yEfCMZwpgyhFmpQ7/Ds /nnYInUqK9q4exFgaf6S1X13zAsuW6Xi670zukl5QB8lqsru9Y+ebgtRLGMGXB0z /v5zAen34ABPK4T6EU2o =GJJ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trpsv-0001py...@franck.debian.org
Accepted network-manager 0.9.6.4-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 22:54:01 +0200 Source: network-manager Binary: network-manager network-manager-dev libnm-glib4 libnm-glib-dev libnm-glib-vpn1 libnm-glib-vpn-dev libnm-util2 libnm-util-dev network-manager-dbg gir1.2-networkmanager-1.0 Architecture: source amd64 Version: 0.9.6.4-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: gir1.2-networkmanager-1.0 - GObject introspection data for NetworkManager libnm-glib-dev - network management framework (GLib interface) libnm-glib-vpn-dev - network management framework (GLib interface) libnm-glib-vpn1 - network management framework (GLib VPN shared library) libnm-glib4 - network management framework (GLib shared library) libnm-util-dev - network management framework (development files) libnm-util2 - network management framework (shared library) network-manager - network management framework (daemon and userspace tools) network-manager-dbg - network management framework (debugging symbols) network-manager-dev - network management framework (development files) Changes: network-manager (0.9.6.4-1) experimental; urgency=low . * New upstream release. * Update symbols file for libnm-glib. Checksums-Sha1: 81e1f7b25ec9c9c47a6ee5e5707263fd55a2055d 2971 network-manager_0.9.6.4-1.dsc e2c89a8a0e17ce872922be91841dc7c15d1c05ec 1968564 network-manager_0.9.6.4.orig.tar.xz 12384cb7b43b70787f669d07de327432d6d29638 32204 network-manager_0.9.6.4-1.debian.tar.gz 7e166bca67e495efec514b071a8a51765bc75dd5 908510 network-manager_0.9.6.4-1_amd64.deb b5a89cd20925008e6ec604a60b2d226efa223f68 275234 network-manager-dev_0.9.6.4-1_amd64.deb 4516c3fc8c861addaeb93ad54ddfac036bbd15db 297804 libnm-glib4_0.9.6.4-1_amd64.deb 9975ba5060b1b556633f1f944352c10c900332a0 400838 libnm-glib-dev_0.9.6.4-1_amd64.deb 4859d844b7842fee48732705908a626996a24fb3 239498 libnm-glib-vpn1_0.9.6.4-1_amd64.deb 1fce46fd97f9e6974e6be7d419eb71405e5b733d 231542 libnm-glib-vpn-dev_0.9.6.4-1_amd64.deb 386c45f244dc03122396c62f9a3d53a6cbd3ca9d 333140 libnm-util2_0.9.6.4-1_amd64.deb 2c5b9b7b81189a292b4181f3237cda50f336c160 380342 libnm-util-dev_0.9.6.4-1_amd64.deb c42e1829a04b08dae4fae3728df0baa7ad4a37ff 1793558 network-manager-dbg_0.9.6.4-1_amd64.deb b3b25d7765ce6ae57e5691a21e97b1b14a9062e4 259146 gir1.2-networkmanager-1.0_0.9.6.4-1_amd64.deb Checksums-Sha256: 55603ce21158ad6d97416402bdb647e61b55a00e02fc7100eb55620e9e3ded81 2971 network-manager_0.9.6.4-1.dsc 511b411e055d187bc8f26c519fdb3e55e07fc40d4adecbbec623c0249380a7eb 1968564 network-manager_0.9.6.4.orig.tar.xz f24c6ad80145ddc95b51dd51db4e38af74325c9b62ab3624968179cf022b0ae8 32204 network-manager_0.9.6.4-1.debian.tar.gz 37d70b099d90820b49a005f0b227cee9179e05b610b320e9cf460eb7d77fcdbe 908510 network-manager_0.9.6.4-1_amd64.deb 9695e0d47e0a89fdc7306e39f17ef0b67ef1a12d939ceab0569f39907c5c5b85 275234 network-manager-dev_0.9.6.4-1_amd64.deb 3554231364a3ad8e50e7fd71c57646aebebd21934c674397fd40b5d8097d3c2c 297804 libnm-glib4_0.9.6.4-1_amd64.deb 8a1ee8b5c343386e26fec99ef3e6c8e5826e2367272a3806b1b89d44b5978295 400838 libnm-glib-dev_0.9.6.4-1_amd64.deb 061417a1019fdbbafb78657bbcdacc2a7c3397864ce24c9da35e5b56614fba15 239498 libnm-glib-vpn1_0.9.6.4-1_amd64.deb 6fe5d6a180820c3c503b896124920f0ca729154dcc99fcfa4a5d34e523dbe9b2 231542 libnm-glib-vpn-dev_0.9.6.4-1_amd64.deb 7c32c3712e4eac6f7fe341efdb7058ad2122f0d43e52447d99764fd200e16530 333140 libnm-util2_0.9.6.4-1_amd64.deb 70a30508b4fb4d361b93dc3c5cd53d71ebb0fb9ea98863ac07e8b2f92438684a 380342 libnm-util-dev_0.9.6.4-1_amd64.deb 8d1668fcdadb59fccfea1005299bf332d281b35181cf2cbb7b9b65f06879ef64 1793558 network-manager-dbg_0.9.6.4-1_amd64.deb 031d21bf9c60eb54899ba441074cbe64a00a7c5a8b7312127212a88f7a1777ac 259146 gir1.2-networkmanager-1.0_0.9.6.4-1_amd64.deb Files: c3d2ceaa55b508429d13f690a5409877 2971 net optional network-manager_0.9.6.4-1.dsc 54ca5200edeb5155086ced43d00b0cad 1968564 net optional network-manager_0.9.6.4.orig.tar.xz 291508a59bb6b1a169f1bbe29f61750a 32204 net optional network-manager_0.9.6.4-1.debian.tar.gz 3ea825934db9451a63369e363fb149f8 908510 net optional network-manager_0.9.6.4-1_amd64.deb 907791da91c4548f1d0fa8559c81126e 275234 devel optional network-manager-dev_0.9.6.4-1_amd64.deb a0ef8ebb5d6435a2a9cc04f37e6148c1 297804 libs optional libnm-glib4_0.9.6.4-1_amd64.deb 8352290802d02d5b3b9d2a19616924ae 400838 libdevel optional libnm-glib-dev_0.9.6.4-1_amd64.deb 8df0e22a165598d62b68f267535d96f0 239498 libs optional libnm-glib-vpn1_0.9.6.4-1_amd64.deb 4903d4a9e02d7b3c0c961a9746c9a285 231542 libdevel optional libnm-glib-vpn-dev_0.9.6.4-1_amd64.deb 56f6cd111fb73edb9f55957de20a6a4d 333140 libs optional libnm-util2_0.9.6.4-1_amd64.deb d66caaf7017b65c4cd6833edd60d2e3b 380342 libdevel optional libnm-util-dev_0.9.6.4-1_amd64.deb
Accepted network-manager-applet 0.9.6.4-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 22:50:15 +0200 Source: network-manager-applet Binary: network-manager-gnome libnm-gtk0 libnm-gtk-common libnm-gtk-dev Architecture: source amd64 all Version: 0.9.6.4-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: libnm-gtk-common - library for wireless and mobile dialogs - common files libnm-gtk-dev - library for wireless and mobile dialogs - development files libnm-gtk0 - library for wireless and mobile dialogs network-manager-gnome - network management framework (GNOME frontend) Changes: network-manager-applet (0.9.6.4-1) experimental; urgency=low . * New upstream release. * Use --list-missing to show uninstalled files. * Update symbols file for libnm-gtk. Checksums-Sha1: db47745e9b7a9a363c8ea5e9f657d07825d03d2b 2639 network-manager-applet_0.9.6.4-1.dsc 43a20facad43738dd631875f74c90fb36035dc2e 1140868 network-manager-applet_0.9.6.4.orig.tar.xz f86e4354727da9d034ab3e0d966175845c895be7 11036 network-manager-applet_0.9.6.4-1.debian.tar.gz 68f32e0c80c1f4a35343121104ef49590b3a3db1 844392 network-manager-gnome_0.9.6.4-1_amd64.deb 0ce3673737bc4a8e07a780123ca0f5c90abe31c7 107734 libnm-gtk0_0.9.6.4-1_amd64.deb d200798f04786fb95b40f1783094582d2ac3ded1 56828 libnm-gtk-common_0.9.6.4-1_all.deb 5dfd4e960eb64042815b2fb256ff0bcb95c2f4ed 57736 libnm-gtk-dev_0.9.6.4-1_amd64.deb Checksums-Sha256: 5c814e0ff21d10971f506141e4a13ffcc226683e3664ae273fdcfc8b544aae9e 2639 network-manager-applet_0.9.6.4-1.dsc ae5667b165f0f83244ec76c42f17553ec2169f5250e144904994497137374141 1140868 network-manager-applet_0.9.6.4.orig.tar.xz 112590ca997dd6252006480c54a85f2c3c3f129cd26aaae7f4096ebe51788bbe 11036 network-manager-applet_0.9.6.4-1.debian.tar.gz a4144e992e98ab8627a5f7f9d4fdd12ff8327d2c58faa4b30ea19fb2e2922022 844392 network-manager-gnome_0.9.6.4-1_amd64.deb 18f18499d2a479a64e178c9557dd4d92c5fbb5afebe82836d62f796fcba8896b 107734 libnm-gtk0_0.9.6.4-1_amd64.deb 0f4f9b5cd89d039f0ce4eafb9dfb1e3b45925a77d8f572aabc63c3fde14a923b 56828 libnm-gtk-common_0.9.6.4-1_all.deb 25a3d0d55814863494e5f69765a00fdf8de4bf9d7ac537ff1c4ac219fa9e66e9 57736 libnm-gtk-dev_0.9.6.4-1_amd64.deb Files: 6d6a5f3c0b3351505f2b519f5fd63b26 2639 gnome optional network-manager-applet_0.9.6.4-1.dsc 8750d83a1151f5f9b0edd2ffcd4e8fc6 1140868 gnome optional network-manager-applet_0.9.6.4.orig.tar.xz 53fc495c66360d83c3e489141ef1acbe 11036 gnome optional network-manager-applet_0.9.6.4-1.debian.tar.gz 257a5f6143aed6e697a170fe1ad7046b 844392 gnome optional network-manager-gnome_0.9.6.4-1_amd64.deb d7534621706d0d5b2b2c39e517af1dd3 107734 libs optional libnm-gtk0_0.9.6.4-1_amd64.deb 4b99339136a7a92e855e72bf037d9170 56828 libs optional libnm-gtk-common_0.9.6.4-1_all.deb c99266bf69beb5c38a295af82005062d 57736 libdevel optional libnm-gtk-dev_0.9.6.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQivrNAAoJEGrh3w1gjyLc0PwP/2DQbcxurDu58JDqRvRUmgUa 37HFFQjKAKwnXiZDeXNaN8XKXAaroSswGgu3T/atHH7IxYFkXutCqzZ6npvjpNJb QKcy2cdosL/+XtS4f70mnVKqxFO2TaowRzNLRjyiA9tjRYvzqHT7jhN5O7SlfGVY oMb5MOr9wdgw7vogpf/pddx/naVJ10gtu5K05NlhhiACVt9zt7rCVvM/zxxXl/zw Wx+x7o/tY8zemJRDzVM3K7S9CM61zBezICy0r79JEzbLNoZFXpwy53WX4f2rvB+y EtGdIDMQ4dzANs7hQe09UeodtB6p9uPc8Tcf5biMRvKH3KRzvpJtyPucv2PwxQOq c9QBX2SBWBKrlLth1whkroLauCOEj0rLESbYwSjgGxO0VIxDuLBaojOmqjZCGmfK 81ey8Ppy/fE8WtNIAvp+Dtubq7r2yED5gaq57RAgtaXvSjeQDzWqhbdCTKGEg9Pq Rytdy/r5O4PvkOWWfVgHsw6IR+QPYNOI9jlGDKq6MENMTJUwqN0LIje3j8xPv65G erGFgW8tktJLKV9km3ab5PM92rs1hLTrhF+LBr4iX6DzJlgLCJCJ93ZNLzqZEazc F6e8WMgZVcmrpVIWCAg8doINjr/BDxNHxeRkccLIEZ6GV/I/U4MezyspGzq6yqXc 7R1tkCzXK6T/Nv2JyIVa =N1np -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trrwo-00081w...@franck.debian.org
Accepted network-manager-openvpn 0.9.6.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 27 Oct 2012 00:04:11 +0200 Source: network-manager-openvpn Binary: network-manager-openvpn network-manager-openvpn-gnome Architecture: source amd64 Version: 0.9.6.0-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: network-manager-openvpn - network management framework (OpenVPN plugin core) network-manager-openvpn-gnome - network management framework (OpenVPN plugin GNOME GUI) Changes: network-manager-openvpn (0.9.6.0-1) experimental; urgency=low . * New upstream release. * Bump Build-Depends on libnm-*-dev and network-manager-dev to (= 0.9.6). Checksums-Sha1: 86e4d1cf7b8f58fc4579b8f90f7bf12155b3257f 2425 network-manager-openvpn_0.9.6.0-1.dsc c5e3366dfac13497c1649a4337b72f9270491a2c 375324 network-manager-openvpn_0.9.6.0.orig.tar.xz e31fd0bd113d9cafae43d217a57bfb5652451fea 4863 network-manager-openvpn_0.9.6.0-1.debian.tar.gz 7c75c2173a56cf05ca4041df9d9eaea1d5bbb46e 32668 network-manager-openvpn_0.9.6.0-1_amd64.deb d93e7a9aae9bd5d6b97a481cd939b3d2683a9206 193916 network-manager-openvpn-gnome_0.9.6.0-1_amd64.deb Checksums-Sha256: d6993a3a05f6ec476cf30dd3094b9c2e4a81f9389317db22088f2c3ecd0a0890 2425 network-manager-openvpn_0.9.6.0-1.dsc 8fb88705793399574b3de2af93f87b63c0eae342d549a1c79bc59f6a1fad87a3 375324 network-manager-openvpn_0.9.6.0.orig.tar.xz ac18de01fe04bd6d0ff5edfd7c3614d3a0f363460bfe1d47f214f7722ff91779 4863 network-manager-openvpn_0.9.6.0-1.debian.tar.gz 0a5fe41984a0acd5d792c1b96b02d12a5b84746880665155a9bef6fa89de89e8 32668 network-manager-openvpn_0.9.6.0-1_amd64.deb 14556435e59859afd653915b4c2fa5dcc5f72df80521f6a5aeb7bfc0e083e121 193916 network-manager-openvpn-gnome_0.9.6.0-1_amd64.deb Files: 23e5c9e4f13f19b1dd9771df24bb7548 2425 net optional network-manager-openvpn_0.9.6.0-1.dsc c4c11aae895f5967d36f3dc7a24046b2 375324 net optional network-manager-openvpn_0.9.6.0.orig.tar.xz 44d8e296691b3bdf4c8102915038edef 4863 net optional network-manager-openvpn_0.9.6.0-1.debian.tar.gz 28430f572cba766b1dd29957ce12f990 32668 net optional network-manager-openvpn_0.9.6.0-1_amd64.deb d2ad1fc5ed5d9e9c36fb98d1f90e863b 193916 net optional network-manager-openvpn-gnome_0.9.6.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQiwmWAAoJEGrh3w1gjyLcw0cQAJ8RwOYSz2uAH/ufaya1D625 yvBQ0TicnGus3nMfQy92trz70b6koz2xn1b8o+06PB9/yUfp9PrKFhd9y0DKHERU iLc3dWinKopWOQ+OElfn4hWDrrbcRGnuKVj12kyBfSvXlFGVQiUnzU22AaDBG3yv 6F1NqmkKDxNr7fKm5lV7F1dZH38G5dsOZJJ1oiCagsHSZ5v0wMD1AD46BaAfVHia T78g3pTmALmsbrq7jBgTsUU2oXRVzQp+LBIsGpv14l6eBlRh6+8OlQkQMG4PRXx+ OwI7ubvYXsb8h6V2nCquP91GciZrQBHkwhLIoKQznWjsvw2PtzJUoK14VxeqRt3w jxzj+aUjoM/wJoU8DZOyrG82o0REx8xDwhRMeOZKeHFzP0cd1sFCBJPpdLyzKCBF s5kk3ASEdqpj8+xJRIJBGtOELoqoMHkseHujmzFICJFXFmIGNz40zlLuQnUvACmL C159yvRF5uX1vdNpstFp6obiM4ln0k71LuMmRNkY5MEuZ3DcMk1upcwK/9sSr9v8 iFv0d2xXLGgZyirW8kqzRynKRfRViBt2XEbTlYfNht7Hj/+RLWaTjqzCQ6cmwhM9 oG5nXBncEXN7urNoDdJcdtSBdTvfk1U3sjlduf3i0QxNF7UtC7zK3/pClJNGSTcY q7T7j6AzETTdf8G6WtcB =93qK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trsdx-00025p...@franck.debian.org
Accepted network-manager-pptp 0.9.6.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 27 Oct 2012 00:16:16 +0200 Source: network-manager-pptp Binary: network-manager-pptp network-manager-pptp-gnome Architecture: source amd64 Version: 0.9.6.0-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: network-manager-pptp - network management framework (PPTP plugin core) network-manager-pptp-gnome - network management framework (PPTP plugin GNOME GUI) Changes: network-manager-pptp (0.9.6.0-1) experimental; urgency=low . * New upstream release. * Remove Enrico Tassi from Uploaders on his request. Thank you Enrico for your work! * Bump Build-Depends on libnm-*-dev and network-manager-dev to (= 0.9.6). * Use --list-missing to show uninstalled files. Checksums-Sha1: ce6db5bc01b6b87fbdc7f95e7502cd48fc562cda 2406 network-manager-pptp_0.9.6.0-1.dsc dfe78fa3eb034d1af35c08b6ddb89af60eb26bee 347188 network-manager-pptp_0.9.6.0.orig.tar.xz a8ff864ee8cf8c3ccf53233de8bd00ba442dd89c 6501 network-manager-pptp_0.9.6.0-1.debian.tar.gz 5ffcd34af6ae6d5ea5248097b53497dce351f919 28868 network-manager-pptp_0.9.6.0-1_amd64.deb c64ef05b665bb2d54a4b88a977890d43485881c0 137810 network-manager-pptp-gnome_0.9.6.0-1_amd64.deb Checksums-Sha256: 2ecdddb5113f487cfe4af958304b76e4c684dba16553cd677a8aaa2e6d31d81a 2406 network-manager-pptp_0.9.6.0-1.dsc a84cbbf24827229e3dd3611bbde191398275c3b7ecd03913047197644f27a2b4 347188 network-manager-pptp_0.9.6.0.orig.tar.xz 238d9e19b470806b5f9b84a49c2c5ba1b0d7ec7694628165844782af7ee7ce1e 6501 network-manager-pptp_0.9.6.0-1.debian.tar.gz da86cfa615128d0acbe1ea72757ff6e6599d086fff992dcc942910ad13f2c59f 28868 network-manager-pptp_0.9.6.0-1_amd64.deb 5eeb92c27b9b8bac3e02fa01ff417cb0882c1569a67db06956980c59b0436983 137810 network-manager-pptp-gnome_0.9.6.0-1_amd64.deb Files: 2df6b33a02481b903f5c0fef4096f59e 2406 net optional network-manager-pptp_0.9.6.0-1.dsc 30ff4312ca86f7ae0c78896a9af221ea 347188 net optional network-manager-pptp_0.9.6.0.orig.tar.xz be7dd1c8039a75f474f5fcf8a169a97c 6501 net optional network-manager-pptp_0.9.6.0-1.debian.tar.gz 369c3246d7329bd40f4c73fed7bf 28868 net optional network-manager-pptp_0.9.6.0-1_amd64.deb e4c663f77d59d702ecc304e1f67fdc7e 137810 net optional network-manager-pptp-gnome_0.9.6.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQiwwDAAoJEGrh3w1gjyLcpZsP/i1MhhsG1RYFlv6pFpX1Tvnw DCwWo7Wd7yM/9dZWKUKLyYJ2Fubm3F9RCfyq66jsXGrwFWOFXJw/PjgIBb3T8yvY AWMvMsoi1I0hvI8zQXB+JQ9tp1eNzKJkJWlSENSqY93w54dxRCbIfUlJpOnxhGJD 5yu282ac0Ie0ifM/IQ2sH2fltEu+Ab/JYv8/wWwaSFnwv8eJx3SrWD56ow4pamv3 KHdV3JiuApMAosNO1KK3AE7yfObQ5qIH+TeYCUcFd7uUu3z88lvzs/3PyoN51cq5 C/EPy6HdmMh/Q7UpmjkuOQa6en2fVu9+NlTBsoHV0I6/EYR5aFkytTFXQH5CBiya 7E87pduNLrVIG+5ES3KCLDrb3BnRaVxahpHcPbTs0MT39l9JO+f8WRkJCSBW/jlh 3ixcUd1AZK+zFYBR9r4RvatYE46I4YrGlOkQpDjpEkilMKBpNGUXpk1gJ2r3ueNc 4OH29MyavSMccgJy4MFDp2bdPiUYTv89lL/a3zjhrREloXFGB07/SnZMoFztJMsf QV2vCo28YOL4tRf3j2BHOwA/M2rpOYkY1X/A/VO8ulIaFafm8oRoa0Nhl9ukP7Wc WVlZJSZhxxw+D9tXznUcQUqQu31SXQkLSNFXI4S+t1tbWje0dkYSy8lO5FpohG7/ RDBeH4uIjBS88XW8JN7p =SH2o -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trssi-00089s...@franck.debian.org
Accepted fife 0.3.3+r3-1.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 24 Oct 2012 21:15:06 +0200 Source: fife Binary: python-fife Architecture: source amd64 Version: 0.3.3+r3-1.1 Distribution: unstable Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Anton Gladky gladky.an...@gmail.com Description: python-fife - FIFE is a multi-platform isometric game engine Closes: 690370 Changes: fife (0.3.3+r3-1.1) unstable; urgency=low . * Non-maintainer upload. * Add engine/core/util/utf8/utf8* to copyright file (Closes: #690370) * Use packaged version of Glee-library to fix lintian embedded-library autoreject tag. Checksums-Sha1: 2a3ee9862697b793fbebc81c19522fe4142d7393 2238 fife_0.3.3+r3-1.1.dsc fd7dac234326634993b35f43da9452d7ede61f84 7400 fife_0.3.3+r3-1.1.debian.tar.xz e34e62de3d23fa4798c11ecc7f283eda255317ba 4115610 python-fife_0.3.3+r3-1.1_amd64.deb Checksums-Sha256: 1aaf30754688945e5e1664e712820b357f427835860e356f476a0bbced04841c 2238 fife_0.3.3+r3-1.1.dsc ffc9a361ec0fce90fae714ce0d3cf84b831f596b93d3fbb2d0f66afe67f813b5 7400 fife_0.3.3+r3-1.1.debian.tar.xz f9a69c0609795b989e5eb5ce41ee8345d1b01b1a3f017037d1c27ee2604cd849 4115610 python-fife_0.3.3+r3-1.1_amd64.deb Files: ccf386d2ef830ad5b29427b22feca7c4 2238 libdevel optional fife_0.3.3+r3-1.1.dsc f58313be8de9710dcb80cffb67e014f9 7400 libdevel optional fife_0.3.3+r3-1.1.debian.tar.xz c3a264495ccc3daf7135c2f331852829 4115610 python optional python-fife_0.3.3+r3-1.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQiuonAAoJEEkIatPr4vMf6UAQAJIv7tGZ8ZW/8UZaXZjbVbBf UUfDxcWHoS1+KVQgrKVoz1hJWF/0DglqMScBkn/mds9uCOM/s+Qj4qrf9jFOcVvI GwmcIUE37IQHqn5d8Tr5YI24QJG4Z36ucHVmTmX0Zu0RQN3M4jaEs5xnqFTm4+1m 55L6AS/OIl0wJXaybjikntu1Mprow1T9KicvK0miGluza6C6Atx5bJ3SIswNlJg3 Fy/snZNFj6y/nSEN4mdFtsKiso779hwBzRVUFKBZAkNTLUoPoTNixS//ZP3idZCy wzdlPJuhxxe6HqOKceWhZm5qxRkKNHkba64+ly6a48IzkjcD4lqnAc+q3dVnJGV3 +fIzStunkf4xSUanrcVR4km0yCf5/FJsrWkZ7MiGAA2fP50S8eJPwDGquaj6r98y 2+44rMBd1l9vxdbqEC5G+YKxcizry/QQRWIby7Y+Z7AoOVwWM+UTIO7ax12elGUH dwSpupee+K3vVyyzd9i/j1Phsby0z81NGRpa4oUArPF4EKph89HHfmWy1tCvvxpj pcow6heq0aPNVHbr1uA+zbQUTVAZqiCX2p4oMpQ+lVR/wjHmXAl7S3XbGSjOriOP 0Hd9QDN7tx8S/Umd18GygAu6EJulYDUHHVkhGDWeas/ImY6QpbFiUifCrMaMyAzY HnuCODJxWps25vWfhncW =2aRN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trsgf-0003ai...@franck.debian.org
Accepted network-manager-vpnc 0.9.6.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 27 Oct 2012 00:20:41 +0200 Source: network-manager-vpnc Binary: network-manager-vpnc network-manager-vpnc-gnome Architecture: source amd64 Version: 0.9.6.0-1 Distribution: experimental Urgency: low Maintainer: Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org Changed-By: Michael Biebl bi...@debian.org Description: network-manager-vpnc - network management framework (VPNC plugin core) network-manager-vpnc-gnome - network management framework (VPNC plugin GNOME GUI) Changes: network-manager-vpnc (0.9.6.0-1) experimental; urgency=low . * New upstream release. * Bump Build-Depends on libnm-*-dev and network-manager-dev to (= 0.9.6). * Use --list-missing to show uninstalled files. Checksums-Sha1: 10b39457f51ae138185d47859fb96658cdfcc522 2386 network-manager-vpnc_0.9.6.0-1.dsc 06a45e6bc418fc315e3206b67a1eaca9c9e98e03 342580 network-manager-vpnc_0.9.6.0.orig.tar.xz 1d2a148831ac45c3cb963e5833e3ae5805028b36 4925 network-manager-vpnc_0.9.6.0-1.debian.tar.gz 8d848f16a42b3e2cdd357317a4bf9da5265916b9 27374 network-manager-vpnc_0.9.6.0-1_amd64.deb 0c2d83e13a5a862c137495480892b5fa8818985f 144724 network-manager-vpnc-gnome_0.9.6.0-1_amd64.deb Checksums-Sha256: 547dae549f26d468fa7c1ee422da0292be48cc808c27fc9e8012fb1a0e23a170 2386 network-manager-vpnc_0.9.6.0-1.dsc 6c8e35862330e17ee8f4dc44b1ac47470da703e436d339c7b3e2dac7d1b148a2 342580 network-manager-vpnc_0.9.6.0.orig.tar.xz 5bcaa0976d65e3e37760f7818f4ba22b09f6d095fca0bb15702e58c413d6bdcf 4925 network-manager-vpnc_0.9.6.0-1.debian.tar.gz 5c19cbf537d668167c01461174cb1630940bb1b4f54720d6172b6d89fcfda168 27374 network-manager-vpnc_0.9.6.0-1_amd64.deb 3a05d913d246ca0cf97a787153fb1d4dde2abc9c1b943179689d96293b201f8f 144724 network-manager-vpnc-gnome_0.9.6.0-1_amd64.deb Files: c5429a05f937b77fc285cc06d5981077 2386 net optional network-manager-vpnc_0.9.6.0-1.dsc 5ab836d732a532b474f9b579e3a7a0cf 342580 net optional network-manager-vpnc_0.9.6.0.orig.tar.xz b4da6f0ae8ff880d918ec53f424caa9b 4925 net optional network-manager-vpnc_0.9.6.0-1.debian.tar.gz 6a8a46af359a62a35341063878b26753 27374 net optional network-manager-vpnc_0.9.6.0-1_amd64.deb aae8d16af949e14538fd9b03908f6b95 144724 net optional network-manager-vpnc-gnome_0.9.6.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQixF4AAoJEGrh3w1gjyLceJ0P/jE8wa+zTzXCAMxHzWJke5MN rwfU1Zuw6a71vlSmW2yCBosFlpe4QFgYg/4hiPDurjjNfxxA2qWWGBTEqF9fGx4R UM0HZBs8QfGllKSj5dOGb6fIoBeZsQCEVE2GniTC37uknSmGEehFPNZPBFbLiNKq 1tf5V7eg5jc/AuHfFmOmgycNlqBUDmUcBP/8/M9igFcs/g5wmZyKULtZ0BswwbhC yujLG4JdNvSx3dB871UHPxEXzz+FhlXwHKSjEnGFWqXRoYtMR8eCwqtYjWrpWdI+ R6Ovf+51uhxhFMuXPILntM4LLe8elIF0oAiJQKBrv/08MGO4y+18TaCSQc0/Omom y2CYkmK/W0RUJkFS+I429xd2RYHU/xEANwsGYYd7EgxX2LrGMJqupN/W4BtlWRfo soKldmnAt8nlJEQy+bQ3z09RL54mnL0PfdLvYVoWquBnaaQZJrYnb/S7+wJ66Kf3 F7Xhmsvl7KUyKEBeXL6jcFYkTcZ9L5WjcIBCwDgnc0Jh1EU7928Bbf5NacJDyq/A aRK27jQfIHsLI5A4P+gMQFnJWjnjVxtHiSvg/2O4RKrrmasztlEflgn1AZHRXQZ3 /FAueGCO225OVMH9cj9ca+GjGfG24TGgUSqMwmKifctABuTbzP8ofFD5mUiww7wP n6PM1K7KnhKoEOIDCJTY =T30E -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trsv8-0007g0...@franck.debian.org
Accepted asterisk-chan-capi 1.1.6-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 27 Oct 2012 09:56:11 +1100 Source: asterisk-chan-capi Binary: asterisk-chan-capi Architecture: source amd64 Version: 1.1.6-1 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team pkg-voip-maintain...@lists.alioth.debian.org Changed-By: Mark Purcell m...@debian.org Description: asterisk-chan-capi - Common ISDN API 2.0 implementation for Asterisk Closes: 625020 631269 Changes: asterisk-chan-capi (1.1.6-1) unstable; urgency=low . * New upstream release - Fixes needs migration to asterisk 1.8 (Closes: #631269, #625020) . [ Tzafrir Cohen ] * Switch from dpatch to dpkg v3. * Add myself as uploader. * Switch packaging to dh. * Require a slightly newer debhelper (= 7.0.50~) for dh overrides. . [ Mark Purcell ] * debian/compat - 9 * Cleanout debian/rules Checksums-Sha1: 7627013ca47d80bff967b24941530d793899493e 1549 asterisk-chan-capi_1.1.6-1.dsc d35bbe7f798dc1fda3dd1eebad811227cbf21894 266783 asterisk-chan-capi_1.1.6.orig.tar.gz 04d16ea236290d455407ebcd148b2cc1562c729d 5737 asterisk-chan-capi_1.1.6-1.debian.tar.gz fe5c2977ff173ce09103de666ca53c16f9baed7c 159294 asterisk-chan-capi_1.1.6-1_amd64.deb Checksums-Sha256: 6e4c060ed67edd0f7e69e4b22f03a4279c7cb60baf51b3c19769a6a355e057f8 1549 asterisk-chan-capi_1.1.6-1.dsc 3e15a925fe57152f97457fac8a0a3e4b1deaaa2f1660d357823e9a3df3937cd7 266783 asterisk-chan-capi_1.1.6.orig.tar.gz d0b2a6b08f40b8c3cc3fafc9221491f6266dbb99b859796e2566b09ba4da3a0f 5737 asterisk-chan-capi_1.1.6-1.debian.tar.gz b95d464122dc50103569297a239f5c7d1d7b4c643fb58523ea43b414ef1346c9 159294 asterisk-chan-capi_1.1.6-1_amd64.deb Files: 74bff9babb263f410ddf8a35897db2e5 1549 comm optional asterisk-chan-capi_1.1.6-1.dsc 562a797065d261a82a36eb2492474445 266783 comm optional asterisk-chan-capi_1.1.6.orig.tar.gz 29f5cf9079bbbc52fb264ad004335a52 5737 comm optional asterisk-chan-capi_1.1.6-1.debian.tar.gz 41f7b93f566fa3488ba34383e909cb1b 159294 comm optional asterisk-chan-capi_1.1.6-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCLFooACgkQoCzanz0IthJkswCeImO1jFYSIjlvv9hKpqHFEJQJ x8UAnjpYO1snO4+YYogp+bt1c0tP7/JT =C58C -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trt9d-0002vj...@franck.debian.org
Accepted haskell-dbus 0.10.3-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 26 Oct 2012 18:53:05 -0400 Source: haskell-dbus Binary: libghc-dbus-dev libghc-dbus-prof libghc-dbus-doc Architecture: source all i386 Version: 0.10.3-1 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: Joey Hess jo...@debian.org Description: libghc-dbus-dev - Haskell implementation of D-Bus libghc-dbus-doc - Haskell implementation of D-Bus; documentation libghc-dbus-prof - Haskell implementation of D-Bus; profiling libraries Changes: haskell-dbus (0.10.3-1) unstable; urgency=low . * New upstream release, fixing a FD leak. Checksums-Sha1: 5ae8948c7342891f7c42dd849301a289aeef0171 3013 haskell-dbus_0.10.3-1.dsc d7bf5094d67e6ba326daea45302a8cad0569dac9 62260 haskell-dbus_0.10.3.orig.tar.xz fbde308d2cd6eef63d31ca17575da3395c7afdd5 2183 haskell-dbus_0.10.3-1.debian.tar.gz fd46fbfc95037f4cdd4e2261873e1cb749b5f675 168864 libghc-dbus-doc_0.10.3-1_all.deb 3e28debf9ff362bf077346f79f35573b0c58a8c2 850918 libghc-dbus-dev_0.10.3-1_i386.deb 96fd5573b9ee0677a2f39d1c676a7367271f770d 842926 libghc-dbus-prof_0.10.3-1_i386.deb Checksums-Sha256: 12b4db0f4d461629d94f50b509ea587a787c4b33f4970dfbc83a90c08570858b 3013 haskell-dbus_0.10.3-1.dsc 5cfd2fb4408033d718f5ae659d43aaf6a1b1653e52ce40c6434ef5ef05bf21b0 62260 haskell-dbus_0.10.3.orig.tar.xz df731acbca1054c81935e871b2038c768ff683b5d9c1d7a00a4d4fd0440af93e 2183 haskell-dbus_0.10.3-1.debian.tar.gz 46c1f7912d9b4357aae1ee1134adaa9df90bd187956143c8f280f9428da8d099 168864 libghc-dbus-doc_0.10.3-1_all.deb 025925489af440b3defdf6c2c3d0e6fbff2a04e008c1f553dde02fad706349b4 850918 libghc-dbus-dev_0.10.3-1_i386.deb f4d00800c92481e24622f3392015ffda7c543ac41c0218432d2190fb475be374 842926 libghc-dbus-prof_0.10.3-1_i386.deb Files: f432d9883a6906b56eb646f1b06421b2 3013 haskell optional haskell-dbus_0.10.3-1.dsc 5c06df440d953ee3be98480e92b3f383 62260 haskell optional haskell-dbus_0.10.3.orig.tar.xz 9e209237fc167cf4e1e479aa16f90a70 2183 haskell optional haskell-dbus_0.10.3-1.debian.tar.gz 6318c8654bac8f143ac8a9600335fd7a 168864 doc optional libghc-dbus-doc_0.10.3-1_all.deb 90aaa94d878fe07c3a03e5a29693d638 850918 haskell optional libghc-dbus-dev_0.10.3-1_i386.deb d57d5a386810a07022fc0c9a11ef995f 842926 haskell optional libghc-dbus-prof_0.10.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUBUIsXVMkQ2SIlEuPHAQiC6g/8CpBSj8PkRAqPYaw20YstluqGjtcp9LY4 2JXN11s6ST2uJgbTIanRGM7noO2Mz8aaaF8AOU4IqtCK/44mg7MXPhcPJOwT+HTS 1EYRo371PD3N8KoHpGc8eV+xE2SDTwbk1exLX1RqwSg5G8y3SQ4ZyjjiHZ0BmZcp ELAJBS0QZ0dHhAPNKu+0TbD1ZOH5ynvPm6j7nF5RovNX+YFp3pAMr0nqABACRuud 0i3NSBlGLpJrH+3OePPjaFYH+HkgUpEQiBdhNQVCX6Di5vGdQbrWYIxduUuJhR8Z xSJk5Uftot5I3bVajnc7dy1fL8+iMFfo1eV2LbwnYaX3280jq7OlHwKHU3QF/ikN zsCRe4zfzizkOHFdARXmoAPOYGV03Se6n3ADZ/dIw38I4QkD/hrxM6KJIarDamHV +oR1vtju2+JcMXdG5sWLQpAFoskHBKGsKttSt1YPszWhTi+h5c3YalyyshILNzw+ UlWPQ+/1fpswgcMGtChfGsVmE3PJBdT/3oAEbjqjOqjgekSmgr8VN9JqCc6HqsO/ sNmzyQtbr6pwiC/ydNFdI/SODqENGbE/si/AEAgMlWZO8pvqGQ6wDoY4zqDI1/nV oEUlESKvBUcfxX5ECmbvhbgaUFYfYgK/pZUfvPVmRdTixnANDlJ2PkllsnKVcMbP CSlyJupMJFo= =ELSU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1trtob-000638...@franck.debian.org
