Re: Proposal: let’s have a GR about the init system
Funny thing, the people who are undermining the Debian processes most loudly are not even Debian Developers and thus they are not bound by them. I am tired of this recurring flamewar, please stop it and let the tech-ctte do their job. This is not a democracy any more, but the loudiestcracy. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server On 26. 10. 2013, at 0:10, Christoph Anton Mitterer cales...@scientia.net wrote: On Sat, 2013-10-26 at 00:36 +0300, Uoti Urpala wrote: I don't think the technical experience would be that much of an issue, but I do see being employed by Canonical as a very substantial conflict of interest. IIRC Canonical has made an official statement that they will keep supporting Upstart and believe in it. This is a fairly visible company choice. Your work environment has at least at some level an official policy that Upstart should be considered better than systemd. Ubuntu still wants to keep using Upstart, but if Debian chooses systemd, Ubuntu will likely also need to admit that Upstart failed and plan for a switch. If your vote decides that Debian will choose systemd, and as a result upstreams conclusively drop any support for Upstart while Ubuntu still wants to keep using it, do you believe this will not have any negative consequences for your career at Canonical? I consider this the biggest question about the conflict of interest, more than direct you must vote this way pressure from your employer. I would see it the same way... it's not only a question whether objective ruling would be made, but also whether it could bring our tech-ctte members into troubles when they decide (i.e. against upstream). And another issue: If e.g. tech-ctte (with some Canonical employees in it) now decides in favour of upstart... then we'll see forever people who challenge the neutrality and objectiveness of such decision. The best would probably be, if people who are either - directly involved in the development of any of the discussed init-systems (in the sense of playing a bigger part) - who work for a company which is pushing the respective system (RedHat, Canonical) or - who maintain the respective package in Debian should abstain from the decision, but just provide their technical input and arguments. Cheers, Chris.
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
On Sat, Oct 26, 2013 at 06:57:50AM +0100, Colin Watson wrote: The usefulness of supporting --as-needed isn't because of Ubuntu. It's because switching --as-needed on across the board I think it would be better send all our upstreams patches for their build systems than to work around all the bugs in them. Lets be honest here, IIRC any use of --as-needed is a workaround for over-inflated DT_NEEDED and fixing those upstream benefits the wider free software community, which we pledged in Social Contract item 2. Linking in the correct order is not a workaround; it's being correct. Sufficiently portable upstreams already get it right since at least some traditional Unix systems already required linking in the correct order, so this is not a new thing. ... or when linking with static libs. I obviously have no objection to sending link-order patches upstream, but realistically this sort of thing only gets fixed across the board if driven by distributions, and the sensible way to track how far we've got is to fix it in the distribution. Not to mention dead upstreams. Does anyone have some estimates about how many packages have dead upstreams? -- WBR, wRAR signature.asc Description: Digital signature
Re: Proposal: s have a GR about the init system
On Saturday, October 26, 2013 07:57:50 Uoti Urpala wrote: Scott Kitterman wrote: Unless there's some kind of disclosure policy for everyone involved in the any technical discussion around Debian, CTTE decisions are quite distinct from any technical discussion. I think it's silly to claim Steve and Colin are inherently unable to separate what's good for Debian from what's good for Canonical. This is just one more symptom of irrational anti- Ubuntu/Canonical bias I see from some people in Debian and I encourage Steven and Colin not to give in to it. A conflict of interest is not the same as claiming the people involved are inherently unable to distinguish different interests. And I'd say this is a very obvious case of conflict of interest - their employer has an official stance, and the decision also has a direct impact on that employer. I do not see what reason you would have to label such concerns silly or symptoms of irrational bias unless you reject the whole concept of conflict of interest and say such concerns are always silly anywhere. Is that your view? I am no longer willing to assume that Steve Langasek would act in good faith in evaluating init systems; he has posted false claims about systemd too many times for me to believe they would all be honest mistakes, and has posted what has clearly been deliberate FUD. This independently of and in addition to any conflict of interest. If someone has engaged in actions that cause you to think their decision making is suspect (I'm not saying either way here, it's your opinion, not mine) that's fair, IMO. Holding their employer against them based on no evidence that there is an actual problem is not. The most important thing in the absence of an actual problem is to shine a light on the potential. That's been done and I think that's enough. I don't have anything against Colin Watson, and have nothing in particular to complain about in his reply concerning the conflict of interest. But I don't think there really is much he could even theoretically say to fully remove concerns about the conflict. That there is a conflict of interest is not a statement about him in person; it's a statement about the situation. No matter what gets decided, some people aren't going to like it and will complain. Personally, I don't think there's more than one sane choice for Jessie anyway: 1. Init systems in Debian MUST provided compatibility with sysvinit scripts. 2. Packages needing an init MUST provide a sysvinit script and may provide native init scripts also for alternative systems. 3. For the various CD #1 options, there can be different default init scripts Something like that. Anyone who thinks their pet sysvinit alternate is going to destroy all opposition and become the one true init for Jessie is dreaming. I think the important thing is making a decision on what init system Debian will use in the future. Details of the transition are then secondary. I wouldn't expect every trace of sysvinit scripts to disappear before next release (unless it takes a long enough time...). I don't see what would be the point of CD #1 options for different inits. Is that really a serious suggestion? I haven't thought about it deeply, but we've already got different CD #1's for different DEs. If there is support for multiple inits in the Debian archive, there's no reason why all of them would have to use the same one. I haven't thought about it in detail, but it strikes me as much less far fetched than thinking Jessie will ship with a single init system other than sysvinit. 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/6321481.z8tQd60ckK@scott-latitude-e6320
Re: Proposal: s have a GR about the init system
On Sat, Oct 26, 2013 at 07:57:50AM +0300, Uoti Urpala wrote: I don't have anything against Colin Watson, and have nothing in particular to complain about in his reply concerning the conflict of interest. But I don't think there really is much he could even theoretically say to fully remove concerns about the conflict. That there is a conflict of interest is not a statement about him in person; it's a statement about the situation. At present I feel I have a well-known and declared interest, but not a conflicting one, for reasons previously stated. I'll recuse myself if that changes or if my colleagues on the TC feel I should (as I mentioned, I previously sought advice on this from the TC chair and he didn't think it was necessary). I don't see what would be the point of CD #1 options for different inits. Is that really a serious suggestion? I don't know whether I yet agree with this, but I can see where it's coming from, given that GNOME has tighter integration into one init system than other desktop systems do. -- Colin Watson [cjwat...@debian.org] -- 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/20131026062258.ga6...@riva.ucam.org
Re: [debian-mysql] MySQL.. no.. _I_ need your help!
I would like to help in some capacity. Would working in a chrooted environment or would one need a fully fledged os? On Fri, Oct 25, 2013 at 5:32 PM, Clint Byrum spam...@debian.org wrote: Greetings earthlings, As some of you may know, I've been doing the bulk of the package maintenance on the mysql package for a while now. It started as part of my day job with Canonical, but since leaving Canonical it has been more a labor of love for Debian. I have love for other things too, such as my children, and seeing the sun shine every once in a while. Thus, I have found almost no time for packaging MySQL for Debian. I am asking you, the Debian developers, to step up and help. I am basically unable to contribute more than an hour a month now. There is a new round of secret CVE bugs to fix, and some old bugs that need to be handled. I think my October hour is about to be available, so I might be able to address those, but after that, if I don't get any more help, I'm done. What can you do to help? - Raise your hand and say you'll help - Perhaps help us do this right (I suspect I should have an RFH bug) - Join #debian-mysql on OFTC - Join the alioth team and request svn access - Triage bugs (src:mysql-5.5 and for oldstable src:mysql-5.1) - Help package the latest patch releases from Oracle - Help with MariaDB (James Page and Otto, thanks for doing this btw!) - Help us migrate to git Now, all of that said, please do not just pick up the package and run off and do a bunch of things without first letting us know you're doing it. There are people quietly working on some long term interesting things and you may be duplicating or diverging heavily from their work. ___ pkg-mysql-maint mailing list pkg-mysql-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint -- Jonathan Aquilina
Re: Proposal: s have a GR about the init system
On Sat, 26 Oct 2013 07:57:50 +0300 Uoti Urpala uoti.urp...@pp1.inet.fi wrote: I am no longer willing to assume that Steve Langasek would act in good faith in evaluating init systems; he has posted false claims about systemd too many times for me to believe they would all be honest mistakes, and has posted what has clearly been deliberate FUD. This independently of and in addition to any conflict of interest. I don't see how that is relevant to the project. AFAICT you are not directly involved in Debian and would have no vote if this did go to a GR, neither are you involved in packaging systemd for Debian. https://nm.debian.org/public/people https://alioth.debian.org/project/memberlist.php?group_id=100797 http://ftp-master.metadata.debian.org/changelogs/main/s/systemd/unstable_changelog Whether or not the project has confidence in the Technical Committee has nothing to do with your opinions, which are blatantly biased. If there are people inside Debian (i.e. people who would have a vote in a Debian GR or who are actively involved in packaging) who have no confidence in the Debian Technical Committee to come to a fair decision for the benefit of all of Debian then I would be concerned. That random people not involved in Debian have prejudged individual members is of no concern. No matter what gets decided, some people aren't going to like it and will complain. True, but it's the people doing the work in Debian who matter in respect of this decision. That is where the resolution of this problem must take place - the opinions of those not doing any of the work, ultimately, count for nothing. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Proposal: let’s have a GR about the init system
On Fri, Oct 25, 2013 at 02:03:38PM +, Thorsten Glaser wrote: Let’s GR it. No. I think I've already argued in the past against this idea on -devel, possibly even in reply to you, Thorsten. As I can't find my post back then, let me reiterate. GRs should be used for societal and policy[*] decisions. Using GRs for *technical* decision is stupid. We really need to stop thinking that every single member of the Debian project, just because he/she is a DD, has a clue on every single technical matter that go on in the project. And note that proving you have a clue on something in Debian is pretty easy: just work actively on that matter, being the maintainer of related packages, or having a verifiable flow of working patches against them, etc. [*] in a broad sense, not related to the document called Debian Policy On one hand, the belief that every DD is technically omniscient is the reason why we still have so many pointlessly heated debates on this mailing list. We would have way less of those if we let only people who have a clue debate specific matters. Unfortunately, many of us seem to be too arrogant to realize they, in fact, don't have a clue. On the other hand, if we stop believing that every single DD is technically omniscient, we would realize how foolish is to use GRs to vote on technical matters. Doing so results in taking important technical decisions essentially randomly. Based on popularity of the various options, trends, vocality of the supporting groups, etc. That's not what Debian is or should be about. Note that the *possibility* of taking technical decisions by GRs is important, as it provides a balance of powers within the project, but we should always do everything in our power to avoid doing that. The decisions about the init system (both which are the supported ones? and which is the default one?) clearly belong to the tech-ctte at this point. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former 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: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)
On Thu, Oct 24, 2013 at 11:00:42PM +0900, Norbert Preining wrote: On Do, 24 Okt 2013, Charles Plessy wrote: at this point, I would like to point at a very important part of the revised code of conduct that Wouter is proposing: Assume good faith. On Do, 24 Okt 2013, Adam Borowski wrote: My apologies, I overreacted. Oh holy s...sunshine (I have to be careful, otherwise I will be ostracised again) ... now that useless political correctness is taking over again. Just remember that if someone is offended it doesn't mean they are right. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- 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/20131026082804.GO358@tal
Bug#727754: New security-aware-resolver virtual package.
Package: debian-policy Version: 3.9.4 Severity: wishlist Le Thu, Oct 24, 2013 at 09:28:32AM +0200, Ondřej Surý a écrit : Hi James, since the authoritative-name-server idea was rejected by the list, I was going to propose alternative: security-aware-resolver The definition from RFC4033: Security-Aware Resolver: An entity acting in the role of a resolver (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and is capable of using the RR types and message header bits defined in this document set to provide DNSSEC services. Dear all, are there Debian Developers seconding or objecting to this new virtual package name ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131026084441.gj17...@falafel.plessy.net
Re: Proposal: let’s have a GR about the init system
* Uoti Urpala uoti.urp...@pp1.inet.fi [2013-10-25 18:27]: Steve Langasek has been consistently posting dishonest FUD against systemd. Maybe you could explain that as excessive zeal following from valid technical considerations, but I'd consider that an excessively charitable interpretation for a member of a body that is supposed to have public trust. Care to back your accusation. If you don't like his backed arguements, come up with something better but declaring them dishonest FUD against systemd because you favor systemd and he does not is plain wrong imo. Yours Martin -- 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/20131026084646.gy15...@anguilla.debian.or.at
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote: In response to the recent threads, I'd like to ask the tech-ctte to please vote on and decide on the default init system for Debian. I agree. I don't think that many substantial new arguments are going to be brought by waiting more on this topic. And it is clear that we have reached a point where not having clear guidance is severely hurting the project. On 25/10/13 at 16:40 +, Thorsten Glaser wrote: I’d still say, let’s just GR about it. Prepare one now, then have some time to cool down before the vote period. I think that it would be a failure of the Debian project if we had to have a GR about such a technical decision. I think that we need to trust that the Technical Committee will make the right decision. A GR about this will likely result in splitting and hurting the project even more. On 25/10/13 at 14:43 -0400, Paul Tagliamonte wrote: And, since I've been informed that this was basically a contentless bug, I'd like to frame the technical half of the question better: Whereas: * the init system / pid 1 is a bit of software that multiple packages provide * the choice of init system also dictates which types of init scripts package maintainers write and maintain * the situation in which packages depend on a feature of systemd that's not dependent on pid 1 being systemd (such as dbus shutdown, or using logind) being run without systemd as pid1 is *not* something the systemd maintainers will support (fairly) is getting *more* common, and has been introduced into a major package (GNOME) It is requested that the tech-ctte make a decision as to the init system Debian shall use as the default, and make a judgement call on where the efforts to resolve this situation shall go (patching *around* the lack of systemd, or patching software to use systemd) I believe this is within the ctte's jurisdiction, given 6.1 section 2. I think that there are two different questions: 1) Could you clarify which init system(s) must be supported by packages involved during system startup (daemons, etc.) and low-level services? [ the answer to that question would likely result into a update of the Debian Policy, section 9.3 and 9.11 ] [ Note that most daemons will likely still have to support sysvinit in jessie, in order to handle partial upgrades. ] 2) sysvinit is currently Essential: yes, which causes it to be installed by default by the installer. Should sysvinit stay Essential? If not, should another init system be Essential? If not, how should this be addressed in the debian installer? Lucas signature.asc Description: Digital signature
Bug#727757: ITP: ruby-mizuho -- Mizuho documentation formatting tool
Package: wnpp Severity: wishlist Owner: Felix Geyer fge...@debian.org * Package name: ruby-mizuho Version : 0.9.19 Upstream Author : Hongli Lai * URL : https://github.com/FooBarWidget/mizuho * License : Expat Programming Lang: Ruby Description : Mizuho documentation formatting tool Mizuho is a documentation formatting tool, best suited for small to medium-sized documentation. Mizuho converts Asciidoc input files into nicely outputted HTML, possibly one file per chapter. Multiple templates are supported, so you can write your own. -- 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/20131026093028.30989.26333.reportbug@localhost6.localdomain6
Bug#727759: ITP: websocket-client -- WebSocket client library for python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: websocket-client Version : 0.12.0 Upstream Author : liris liris...@gmail.com * URL : https://github.com/liris/websocket-client * License : LGPL-2.1+ Programming Lang: Python Description : WebSocket client library for python websocket-client provides a low-level, synchronous API providing WebSocket client functionality to Python programs. It conforms to the WebSocket specification as standardized by the IETF in RFC 6455. . WebSocket is a protocol providing full-duplex communication channels over TCP, mostly used in Web browsers. This module is a test dependency for moksha.hub. It will be packaged under the DPMT umbrella, and the binary package will be called python-websocket as per the Debian Python Policy. -- 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/20131026094406.6017.11840.report...@darboux.home.olasd.eu
gnucash dependencies (was Re: Proposal: switch default desktop to xfce)
On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote: I have Gnucash installed and it depends on udisks, trust me I have absolutely no need for udisks or polkit, so don't be so sure (I am not saying that I am sure that he is not). gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks How do you suggest this was fixed? (There's an explanation for the libgnom2-0 → gvfs dependency in #550479). -- 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/20131026100204.ga32...@bryant.redmars.org
Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)
On 26/10/13 12:02, Jonathan Dowland wrote: On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote: I have Gnucash installed and it depends on udisks, trust me I have absolutely no need for udisks or polkit, so don't be so sure (I am not saying that I am sure that he is not). gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks How do you suggest this was fixed? (There's an explanation for the libgnom2-0 → gvfs dependency in #550479). libgnome2 is long deprecated, port gnucash away from it! Emilio -- 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/526ba171.6000...@debian.org
Re: Proposal: let’s have a GR about the init system
Zack wrote: Note that the *possibility* of taking technical decisions by GRs is important, as it provides a balance of powers within the project, but we should always do everything in our power to avoid doing that. The decisions about the init system (both which are the supported ones? and which is the default one?) clearly belong to the tech-ctte at this point. Agreed 100%. Let's see what they have to say. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/e1va1ll-0003ty...@mail.einval.com
Re: Proposal: switch default desktop to xfce
[Please don't top post on this mailing list!] On Thu, Oct 24, 2013 at 06:45:02PM +0200, Zlatan Todoric wrote: And just bashing GNOME DE for systemd and GNOME Classic is not good enough point because probably the largest user base of Debian user use GNOME. That is because it is installed by default! (unless you explicitly opt-out.) -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- 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/20131026112612.GR358@tal
Re: Proposal: switch default desktop to xfce
On Fri, 25 Oct 2013 14:58:34 -0700 Nikolaus Rath nikol...@rath.org wrote: Neil Williams codeh...@debian.org writes: If someone comes up with good reasons to consider systemd on it's own merit, I'm willing to consider it. With the current approach of a fait-accompli systemd is part of the GNOME dependency chain, so tough then I am quite happy to dismiss systemd as an option simply because of this insane top-down dependency. systemd simply cannot be a viable choice if it has to be forced down people's throats like this. Please reconsider this. If I wrote a little GUI calculator and made it depend on e.g. upstart, would that also make upstart unsuitable as a default init system because of the resulting insane top-down dependency? Yes. It is the tight coupling between desktop and init which is precisely the problem. *IF* the chosen init system is already the default, then by all means use the features provided. Desktop components cannot dictate how the rest of the system operates. The desktop is optional. Adding a desktop to a running system must not require a change of init, just as it cannot require a change of kernel or perl interpreter. I get to choose how I enable or disable mounting drives and other niceties which would require root access, not the desktop. Equally, user switching is something I've never considered useful, so that's easily omitted too. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)
Le samedi 26 octobre 2013 à 13:03 +0200, Emilio Pozuelo Monfort a écrit : On 26/10/13 12:02, Jonathan Dowland wrote: On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote: I have Gnucash installed and it depends on udisks, trust me I have absolutely no need for udisks or polkit, so don't be so sure (I am not saying that I am sure that he is not). gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks How do you suggest this was fixed? (There's an explanation for the libgnom2-0 → gvfs dependency in #550479). libgnome2 is long deprecated, port gnucash away from it! This is already done in the current development release (in experimental). -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Re: Proposal: switch default desktop to xfce
On 26 Oct 2013, at 13:00, Neil Williams codeh...@debian.org wrote: Desktop components cannot dictate how the rest of the system operates. The gnome folks are free to do what they please. They don't answer to us and your repeated assertions that they're crossing a line just shine a light on your own hubris. Here, we decide what happens *in Debian*. -- 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/1438a3ea-7b25-4727-9dc7-905bedb02...@debian.org
Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)
On Sat, Oct 26, 2013 at 12:02:00AM +0100, Kevin Chadwick wrote: I'm fed up with repeated attempts to force components on the rest of the system, but that's mostly a fault of Gnome's upstream There seems to be a trend emanating from packages involving RedHat devs. I actually went to the RedHat site a few weeks ago to try and get some sort of oversight on this but there seemed to be no appropriate contact point (bookmarked). There are various maintainers+developers who would love to see GNOME support Wayland and nothing more. This due to code complexity and test matrix (too many different options and it becomes difficult to test things). And we do do continuous integration, plus I had to deal with the bugs caused by the introduction of Wayland support. Various of above mentioned maintainers/developers are sponsored by Red Hat. I say sponsored because they pretty much do what they think is good. I have not seen any corporate agenda (I also fail to understand why we have so many of them). Anyway, they just don't want code complexity. The *main* reason that GNOME will keep Wayland + X compatibility for a long time, thus introducing more bugs and slowing down full Wayland support, is the same GNOME release team person who urged to support Wayland. He's sponsored by Red Hat. In brief: The person mainly responsible for allowing people to rely on our X support for a much longer time is one of those Red Hat people. Not sure if you like Wayland or not, but something to keep in mind, if it wasn't up to this Red Hat person, X support would be die much more quickly. And this decision is not made due to forcing, it is to due supporting one thing well, not multiple things a bit with various degrees of testing and buggyness. -- Regards, Olav -- 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/20131026131723.gj29...@bkor.dhs.org
Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)
Quoting Emilio Pozuelo Monfort (2013-10-26 13:03:13) On 26/10/13 12:02, Jonathan Dowland wrote: On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote: I have Gnucash installed and it depends on udisks, trust me I have absolutely no need for udisks or polkit, so don't be so sure (I am not saying that I am sure that he is not). gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks How do you suggest this was fixed? (There's an explanation for the libgnom2-0 → gvfs dependency in #550479). libgnome2 is long deprecated, port gnucash away from it! If that's the case, I believe the library should be moved to oldlibs: Please consider file a bugreport suggesting that to the package maintainer. (not filing bugreport about that myself, as I only know the issue from above post). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: gnucash dependencies (was Re: Proposal: switch default desktop to xfce)
On 26/10/13 16:38, Jonas Smedegaard wrote: Quoting Emilio Pozuelo Monfort (2013-10-26 13:03:13) On 26/10/13 12:02, Jonathan Dowland wrote: On Sat, Oct 26, 2013 at 12:19:53AM +0100, Kevin Chadwick wrote: I have Gnucash installed and it depends on udisks, trust me I have absolutely no need for udisks or polkit, so don't be so sure (I am not saying that I am sure that he is not). gnucash → libgnome2-0 → gvfs → gvfs-daemons → libgdu0 → udisks How do you suggest this was fixed? (There's an explanation for the libgnom2-0 → gvfs dependency in #550479). libgnome2 is long deprecated, port gnucash away from it! If that's the case, I believe the library should be moved to oldlibs: Please consider file a bugreport suggesting that to the package maintainer. Done in svn: libgnome (2.32.1-5) UNRELEASED; urgency=low * debian/control.in: + Move to section oldlibs. -- Emilio Pozuelo Monfort po...@debian.org Sat, 26 Oct 2013 16:54:53 +0200 -- 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/526bd801.8020...@debian.org
Re: MySQL.. no.. _I_ need your help!
Clint - perhaps you and I can talk about this in Hong Kong? -- 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/5f7ce033-3ae0-4c17-8356-a31015a72...@patg.net
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 11:44:48PM +0100, Steve McIntyre wrote: Andy Cater wrote: I think it would be a good idea to have the netinst have an additional option to select desktop easily including the option for command line only, no graphical desktop as default. We already have that option right now - in fact, you can deselect the graphical desktop task readily tasksel from any of the installation media and just get a simple command line system. Or are you specifically asking for such an option directly on the isolinux/grub installer boot screen? That wouldbe my preference - a tasksel change for no desktop KDE GNOME LXDE XFCE etc. for the netinst - default being no desktop - ideal for a minimum install. snip Yes, it can. It should contain enough of the packages needed to be able to support all 4 of the recognised DEs. However, at current rates it won't take long for them to outgrow the 4GB of space available! Now that USB sticks at 16/32GB are (relatively) cheap - it is actually a much better bet to install the Blu-Ray .iso image in the same way :) Thanks for reading, All the best - hope to get myself sorted to come to the mini-Debconf in November - see you then, AndyC -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/20131026150853.ga4...@galactic.demon.co.uk
Re: Proposal: let’s have a GR about the init system
On Sat, Oct 26, 2013 at 4:00 AM, Stefano Zacchiroli z...@debian.org wrote: On one hand, the belief that every DD is technically omniscient is the reason why we still have so many pointlessly heated debates on this mailing list. We would have way less of those if we let only people who have a clue debate specific matters. Unfortunately, many of us seem to be too arrogant to realize they, in fact, don't have a clue. On the other hand, if we stop believing that every single DD is technically omniscient, we would realize how foolish is to use GRs to vote on technical matters. Doing so results in taking important technical decisions essentially randomly. Based on popularity of the various options, trends, vocality of the supporting groups, etc. That's not what Debian is or should be about. I've been trying very hard to not get involved in this, but I feel the need to poke my head up to give this a very strong +1. For the same reason the chances of me uploading the kernel approach zero, there's no reason I need to vote on the init system. In fact, by the tone of the discussions we've had on the topic I have very little confidence in a GR leading to a decision being made on technical merits. It's time to let the tech-ctte do their constitutionally mandated job. Thanks, -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- 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/CAL6k_AwEaeCzAKTtmjHCYXAJoOTYNXLoWrEAZB7Y1_==bxq...@mail.gmail.com
Re: Proposal: let’s have a GR about the init system
On Fri, Oct 25, 2013 at 07:09:45PM +0300, Uoti Urpala wrote: Steve Langasek has been consistently posting dishonest FUD against systemd. Maybe you could explain that as excessive zeal following from valid technical considerations, but I'd consider that an excessively charitable interpretation for a member of a body that is supposed to have public trust. Steve *has* public trust. There are very few people around here that contributed to Debian more than he did. If you don't feel he has public trust, then you know nothing about Debian, and you are for sure not in a position to criticize the decisions he may take as technical committee member. Ditto for Colin and the other members of the board, that are there for a reason. In case you don't know, that reason is not being champions of trolling on -devel. Who are you? Who pays your bills? -- Enrico Tassi -- 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/20131026153000.GA10501@birba.invalid
Re: Proposal: switch default desktop to xfce
On 26 Oct 2013, at 16:08, Andrew M.A. Cater amaca...@galactic.demon.co.uk wrote: That wouldbe my preference - a tasksel change for no desktop KDE GNOME LXDE XFCE etc. for the netinst - default being no desktop - ideal for a minimum install. I don't understand how that would work: I presume you don't mean an isolinux option that changed the meaning of Debian desktop environment to no desktop. I think the boot options make the situation more complicated. Why not have a selection of tasks XFCE desktop environment (default) LXDE desktop environment GNOME desktop environment KDE desktop environment Where the debian recommended is suffixed as I've indicated above, and to get no desktop, you deselect them all. My main concern about this would be the task selection screen having too many options. In which case the desktop questions could all have their own screen. -- 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/485d0ad4-e982-4902-9f70-719daf1b3...@debian.org
Re: Proposal: let’s have a GR about the init system
On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote: GRs should be used for societal and policy[*] decisions. Using GRs for *technical* decision is stupid. Is it for sure that this (and I guess it's mostly about upstart vs. systemd is *only* a technical question? - Apparently both are much more capable than sysvinit - Apparently you can do most things of a modern init system with both Sure there are many detailed questions like e.g. systemd doing some (IMHO useless integrity protection on logs, which AFAIK upstrart hasn't anything similar)... but that's IMHO rather a matter of taste. IMHO there is quite some big political point in the whole question, namely which of the both fractions one wants to support. - Canonical/*buntu - RedHat and (what seems to be) the rest of the world It's also a question wheter Debian will at least politically be tied even more to Canonical/*buntu - and I guess no one can claim that there wouldn't be sucht ties (already by having many Canonical workers being DDs,too)[0]. I wouldn't see many technical arguments that speak strongly really in favour of one or the other, perhaps: - Against systemd speaks that it's uncertain on whether there will be a solution in the end for the non-Linux UNIX flavours - which I think Debian should support for ethical and philosophical reasons. Admittedly I have no idea how the situation is there wrt upstart. - For systemd speaks, that it seems most of the rest of the world is focusing on it (many kernel developers, the wayland guys, etc.). Does upstart receive the same attention here? Could that mean much effort or even problems for Debian in the end, if it decides for upstream? Cheers, Chris. [0] And note that I neither said these ties would be good nor bad. smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: let’s have a GR about the init system
On Sat, Oct 26, 2013 at 04:37:55PM +0200, Christoph Anton Mitterer wrote: [...] non-Linux UNIX flavours - which I think Debian should support for ethical and philosophical reasons. Uh-oh. -- WBR, wRAR signature.asc Description: Digital signature
Re: Proposal: let’s have a GR about the init system
Hi, Christoph Anton Mitterer cales...@scientia.net writes: On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote: GRs should be used for societal and policy[*] decisions. Using GRs for *technical* decision is stupid. Is it for sure that this (and I guess it's mostly about upstart vs. systemd is *only* a technical question? - Apparently both are much more capable than sysvinit - Apparently you can do most things of a modern init system with both Sure there are many detailed questions like e.g. systemd doing some (IMHO useless integrity protection on logs, which AFAIK upstrart hasn't anything similar)... but that's IMHO rather a matter of taste. systemd doing more is quite relevant for this decision as far as I understand the discussion: unlike upstart, systemd is not just an init replacement, but offers additional services like journald or logind. These provide useful functionality and parts of them would be needed even when using upstart (logind was mentioned). So deciding for upstart means providing these services via some other means, such as writing a replacement, forking an old version of systemd's logind, or convincing systemd upstream to provide a logind that works together with upstart. I am not sure how much work this will be, esp. should additional modules be required later. Also the tight integration into systemd allows to provide some really nice features. From trying out systemd for a bit, I found systemctl status quite impressive. I don't know if upstart has something comparable. For just the init part, I'm not sure how large the differences between the systems are. Systemd seems to provide more features, upstart tries to be small and simple. Ansgar -- 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/87ppqs10dr@eisei.43-1.org
Jessie release goal: DNSSEC as default recursive resolver
Hi, I'd find it very nice if we had, by default, DNSSEC resolving in Debian, at least in the default configuration (whatever that means). By this, I mean that any non-experienced user would just install (or upgrade to) Jessie, start a web browser (Chormium, Iceweasel, etc.: take your pick...), and have DNSSEC resolving just working. Of course, we'd have this also for non-browser applications as a consequence if it's implemented (I'm thinking about stuff like curl, wget), though to me, the browser part is the most important. If this means installing a recursive DNS resolver by default (unbound pops to my mind, since it has the feature by default), I'd say be it, though probably that is more of an open question, and an implementation details. I personally wouldn't mind at all if the Debian default configuration would by-pass whatever ISP are providing, since we've seen this broken in multiple cases (so many that I don't think it's even necessary to use an example to illustrate that fact here...). If I'm not mistaking (please correct me), Fedora has the feature, and it's been a long time they do. FreeBSD as well (they have unbound in the default installer). OpenBSD also removed bind and switched to unbound (or at least is planning on doing it, I'm not sure). Debian shouldn't be left behind. Probably this is too narrow for a release goal, or it is too late to raise this topic, though I would find it very nice if we had the feature, which is why I'm raising this topic. Thoughts welcome. Thomas Goirand (zigo) P.S: I wont have time to get involve in this, though I don't think that there is so much work involved, is it? -- 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/526be8e3.9000...@debian.org
Re: Proposal: let’s have a GR about the init system
On Sat, Oct 26, 2013, at 16:37, Christoph Anton Mitterer wrote: On Sat, 2013-10-26 at 10:00 +0200, Stefano Zacchiroli wrote: GRs should be used for societal and policy[*] decisions. Using GRs for *technical* decision is stupid. Is it for sure that this (and I guess it's mostly about upstart vs. systemd is *only* a technical question? Several Debian Developers has voiced that this is the technical question. Could you please stop commenting and suggesting how we should run Debian project? I think we can handle well even without your contributions. It would be much appreciated if we can stop this useless thread now. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- 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/1382804321.26653.38912417.5718b...@webmail.messagingengine.com
Re: Jessie release goal: DNSSEC as default recursive resolver
Thomas Goirand z...@debian.org writes: If this means installing a recursive DNS resolver by default (unbound pops to my mind, since it has the feature by default), I'd say be it, though probably that is more of an open question, and an implementation details. I personally wouldn't mind at all if the Debian default configuration would by-pass whatever ISP are providing, since we've seen this broken in multiple cases (so many that I don't think it's even necessary to use an example to illustrate that fact here...). One has to be careful about this, since quite a few installations are on unroutable IP addresses that can't do direct DNS queries to the DNS roots. Even if a system is installed via the network installer, that may be with the goal of eventually moving it into a private network. If your primary DNS resolver doesn't reply due to inability to reach the root DNS servers, it tends to cause all sorts of weird slowness and issues that are hard for the average user to understand or track down, even if you have other DNS servers listed as secondary resolvers. The safe default is still to rely on the organizational DNS resolvers as provided by DHCP or local manual configuration. I'm definitely in favor of improved DNSSEC support, but I think it's going to need to be something that people can optionally install if we're trying to provide it by bypassing local DNS infrastructure. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fvro0zs0@windlord.stanford.edu
Re: Proposal: switch init system to systemd or upstart
On Sat, 2013-10-26 at 08:34 +0300, Uoti Urpala wrote: Brian May wrote: As much as I would like to see systemd as the default in Debian (and have switched to it on my Desktops), I see two show stopper issues: * Needs to work (somehow) with other applications (including not in Debian) that need to manage cgroups. In Debian this would include lxc. My understanding is that the _kernel_ side wants to change the cgroup API, and this means that at least in the long term current cgroup-using applications will need to change in any case (possibly by using systemd APIs instead). [...] Your understanding seems to be incomplete. There are two architectural problems with the current cgroups API: (1) the multiple types of cgroups form separate hierarchies, which can result in effective conflicts between different cgroup controllers (2) when the cgroupfs is manipulated by multiple tasks, this results in unpleasant race conditions for userland. I think there is agreement in the kernel community that (1) should be fixed by requiring all cgroups to fit into a single hierarchy. There is not yet agreement as to whether (2) should be fixed by (a) putting a single daemon (presumably pid 1) in charge of cgroupfs and having other userland programs make requests to that daemon, or (b) improving the API to make the race conditions avoidable, so control over sub-trees can be safely delegated. There was a discussion of these problems at the Kernel Summit on Thursday and I hope to see a more detailed report in LWN within the next few days. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Re: Proposal: switch default desktop to xfce
Of course, the gnome default makes adding gnome to the plot not currently useful. One nice side benefit of at least temporarily switching the default desktop to xfce would be that if a lot of people wanted gnome, rather than just picking it as the default, we'd see that reflected in the popcon data. I saw a general survey possibly on techrepublic that alleged reasonable data collection methods (though I don't recall how the data was collected) suggesting that xfce was very close or overtaken Gnome now and KDE was the most widely used desktop. On those grounds I would therefore advocate KDE as default, however I am not fond of the lack of modularity of KDE, whereas with xfce it is a primary goal making users able to shape their debian for whatever general usage easily and fast is fast on fast systems too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/770901.95358...@smtp135.mail.ir2.yahoo.com
Pro-Action against dependency hell
What can be done to prevent rather than reacting to dependency hell all the time. Some developers obviously get it and yet others seem to pro-actively work in the other direction. There was a time when it was said that this problem was finally heading in the right direction. There is an example that I am not clear on in terms of build dependencies too as oppose to runtime dependencies. epdfview depends on libqt evince pulls in the whole of QT adding ages to the build time. Speaking to a guy on a QT stand at an exhibition he said that he had not heard of evince but seemed to think that evince must be using QT wrongly. Installing systemd does not magically switch your init system. It doesn't *right now*, but from [0] I conclude that it would very much like to do so and so possibly, in the future, will. It would be rediculous if chattr +ias /sbin/init needed to be set before installing systemd. Of course a better option would be if major contributors were fighting and not contributing to dependency hell. It really irks how inconsiderate to others time upstream has shown itself to be when they already have the knowledge to do it right in the first place. It makes me wonder who educated them. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/105179.95358...@smtp135.mail.ir2.yahoo.com
Re: Propose Release Goals (delayed ;) - xz compression
Off list. Thanks! Richard
Re: Proposal: switch default desktop to xfce
On Sat, Oct 26, 2013 at 04:41:00PM +0100, Jonathan Dowland wrote: On 26 Oct 2013, at 16:08, Andrew M.A. Cater amaca...@galactic.demon.co.uk wrote: That wouldbe my preference - a tasksel change for no desktop KDE GNOME LXDE XFCE etc. for the netinst - default being no desktop - ideal for a minimum install. This is for the netinst - so something that will install a minimum system from the network and is 400M at the moment. I don't understand how that would work: I presume you don't mean an isolinux option that changed the meaning of Debian desktop environment to no desktop. I think the boot options make the situation more complicated. Why not have a selection of tasks No, that is pretty much what I mean: it would be useful to have no desktop installed by default. If you select - Install a desktop environment then you get to select which one you want: if that changes init choices / software choices to pull in the appropriate DE package list before your first boot into the new system. Then if someone says - I need to install a DE because I forgot to install a DE at initial install time - one command is needed - something like dpkg-reconfigure desktop-environment -plow should do it. XFCE desktop environment (default) LXDE desktop environment GNOME desktop environment KDE desktop environment Where the debian recommended is suffixed as I've indicated above, and to get no desktop, you deselect them all. My main concern about this would be the task selection screen having too many options. In which case the desktop questions could all have their own screen. Yes - a desktop selection should probably have its own screen - that way you can add any number of DEs you need. AndyC -- 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/20131026164339.ga5...@galactic.demon.co.uk
Re: systemd effectively mandatory now due to GNOME
On Wed, 2013-10-23 at 23:42 +0200, Svante Signell wrote: On Wed, 2013-10-23 at 23:06 +0200, John Paul Adrian Glaubitz wrote: And does this cause any problems actually? Does your system no longer boot properly using sysvinit when systemd is installed? Well, gdm3 does not start for a new installation, probably caused by systemd(-logind). I had to use xfce4 instead as desktop for now, see also bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724731 s/xfce4/lightdm+xfce/ bug 724731 not solved yet:( -- 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/1382804913.4094.2.camel@PackardBell-PC
Re: let's split the systemd binary package
Session tracking includes suspending/hibernating, because logind has a mechanism to let apps delay suspend, which is necessary for things like closing the inherent race condition in lock the screensaver when we suspend... oh, oops, it didn't get scheduled until after we resumed, so the old screen contents are still visible for a moment when you open your laptop. xlock /usr/sbin/pm-suspend That is the flexible way of doing that specific thing with a few ifs or config checks where needed. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/251878.95358...@smtp135.mail.ir2.yahoo.com
Re: Proposal: let’s have a GR about the init system
Steve Langasek has been consistently posting dishonest FUD against systemd. Maybe you could explain that as excessive zeal following from valid technical considerations, but I'd consider that an excessively charitable interpretation for a member of a body that is supposed to have public trust. Please be specific if you ever use the word FUD again as I have it used against myself when the details of what I have stated have simply not been understood or omitted through weariness and it is perfectly possible that varying user requirements simply lead to opposing positions, which is normally a huge and unparalleled strength of UNIX in catering to both when it's tried and tested principles are adhered to. For the record when reading this it occured to me that Steve was being far more reasonable and meritable than you. perhaps the words 'FUD' and 'modern' should be banned as non technical arguments on this list. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/823544.95358...@smtp135.mail.ir2.yahoo.com
Re: Proposal: let’s have a GR about the init system
I recommend one more option, nicknamed rotten tomatoes, that basically says that this GR should never have been proposed. And even more so not listened to for a few reasons. Little has changed since the last discussion that I feel came to a reasonable current standing with an overview possibly from Thorsten. Allowing unforgivable and inconsiderate possibly purposeful upstream decisions to improve the chances of migration with potential future black mailing fall out to come from the non-negotiable systemd camp can only encourage dispicable behaviour and send the wrong message and one that is far more important not to send than not sending Gnome dropped because of systemd message which would actually have some justification. I feel a consensus to never talk about systemd migration when systemd or dependencies cause problems should be made and to do so only when a high level decision is made that it is the right time to decide whether to switch or stay with the current init has been made and on a general what init system is best process rather than thread change. If anyone deviates simply tell them that any general discussion not relating to a particular problem is off agenda currently. I wish not to get involved but worry about what will happen if I don't and so would be glad if all can agree to simply replying to any attempts for the time being with something like. '/SBIN/INIT MIGRATION OR NOT IS CURRENTLY BEING CONSIDERED AND NOT OPEN FOR DISCUSSION CURRENTLY' -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/298796.95358...@smtp135.mail.ir2.yahoo.com
Re: systemd effectively mandatory now due to GNOME
But that alone is not an argument against introducing new technologies. One just has to be careful in what is done. Not against new technologies in general but if you are talking about something which you expect every Linux user to use (when actually they can't in deep embedded etc.) then yes they are hugely valid concerns unless you want to reduce the applicability of Linux of course. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/814012.95358...@smtp135.mail.ir2.yahoo.com
Re: Proposal: switch init system to systemd or upstart
My understanding is that the _kernel_ side wants to change the cgroup API, and this means that at least in the long term current cgroup-using applications will need to change in any case (possibly by using systemd APIs instead). I'm not familiar with the specific case of lxc, but I really doubt systemd would make it unusable. Generally anything must already work with systemd to be usable on several major distros, so it should be a reasonably safe assumption that things will work. Generally the Linux kernel bends over backwards to avoid this breakage and I know there is already some compatibility layer so please refrain from commenting if you are this unsure or it is another controversial and undecided topic such as Google requiring it. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/401821.95358...@smtp135.mail.ir2.yahoo.com
Re: Proposal: let’s have a GR about the init system
systemd doing more is quite relevant for this decision as far as I understand the discussion: unlike upstart, systemd is not just an init replacement, but offers additional services like journald or logind. I don't mean to be rude but please read up on systemd and see the pros of cons such as on LWN.net comments or any distro mailing list as many are tired of systemd discussion and this wide ranging and much of the stolen/borrowed/existing functionality is what many don't want mandated on all systems by default for various reasons. You can have it if you want it through installation you shouldn't have to have it in memory etc. and optionally not use it. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/293633.76504...@smtp132.mail.ir2.yahoo.com
Re: Jessie release goal: DNSSEC as default recursive resolver
If I'm not mistaking (please correct me), Fedora has the feature, and it's been a long time they do. FreeBSD as well (they have unbound in the default installer). OpenBSD also removed bind and switched to unbound (or at least is planning on doing it, I'm not sure). Debian shouldn't be left behind. OpenBSD has it's own resolver with a tcp only option, unbound is in base as a default off cache option due to the decision that bind's upstream was making some odd decisions, bad coding and creating work and nsd was saner in the vast majority of cases anyway. I believe the reliability (DOS) issues that DNSSEC imposes coupled with the low level of adoption would make it very unlikely that DNSSEC would be enabled for certainly default resolving on OpenBSD without DNSCURVE protection or some significant DNSSEC re-development. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/999192.15566...@smtp140.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote: I think that there are two different questions: 1) Could you clarify which init system(s) must be supported by packages involved during system startup (daemons, etc.) and low-level services? [ the answer to that question would likely result into a update of the Debian Policy, section 9.3 and 9.11 ] [ Note that most daemons will likely still have to support sysvinit in jessie, in order to handle partial upgrades. ] 2) sysvinit is currently Essential: yes, which causes it to be installed by default by the installer. Should sysvinit stay Essential? If not, should another init system be Essential? If not, how should this be addressed in the debian installer? I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. Likewise, the Essential: yes bit on the sysvinit package will be in effect for a full release cycle regardless of what init system we choose, so it needs to become a metapackage that depends on an ORed list of possible implementations in order for us to make any change in jessie. The real question before the TC is simply: what should the default init system be for jessie? The rest are technical details that can be straightforwardly worked out once we have a decision on the direction. -- 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: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek vor...@debian.org writes: I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. That isn't obvious to me. We have, in the past, allowed upgrades to require a preliminary upgrade of one or more packages. The udev transition comes to mind. We *could* do the same thing here and require an init upgrade as a pre-upgrade step when going from wheezy to jessie, alongside a dependency on systemd or upstart (added by debhelper, for example) for all packages providing startup configuration but not an init script. I'm not saying that's necessarily a good option, but it is an option that we should discuss. Also, we will eventually have to decide whether to drop the requirement that packages provide sysvinit-compatible init scripts. Even if we agree on a requirement to do so for jessie, we could drop that requirement for jessie+1 (and indeed will want to if we choose any init system other than sysvinit or all of the above, given that most of the benefits of either upstart or systemd from a packaging perspective will only be seen when we take that step). We could always defer that decision until jessie+1, but that's the decision with the most impact on kFreeBSD and Hurd, and if I were them, I'd want to know whether that's the eventual project direction or not as soon as possible so that I have as much time as possible to decide on my next steps. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ob6cylfl@windlord.stanford.edu
Re: Jessie release goal: DNSSEC as default recursive resolver
On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote: I believe the reliability (DOS) issues that DNSSEC imposes coupled with Please, not this again. If you say DNSSEC DOS issue, you must state all the other issues that DNS has. the low level of adoption It's certainly more adopted than IPv6 and we do support IPv6. would make it very unlikely that DNSSEC would be enabled for certainly default resolving on OpenBSD without DNSCURVE protection or some significant DNSSEC re-development. How is the DNSSEC adoption by OpenBSD relevant to Debian decisions? O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- 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/1382809758.15230.38938129.3733e...@webmail.messagingengine.com
Re: Jessie release goal: DNSSEC as default recursive resolver
Hi Russ, On Sat, Oct 26, 2013, at 18:20, Russ Allbery wrote: Thomas Goirand z...@debian.org writes: If this means installing a recursive DNS resolver by default (unbound pops to my mind, since it has the feature by default), I'd say be it, though probably that is more of an open question, and an implementation details. I personally wouldn't mind at all if the Debian default configuration would by-pass whatever ISP are providing, since we've seen this broken in multiple cases (so many that I don't think it's even necessary to use an example to illustrate that fact here...). One has to be careful about this, since quite a few installations are on unroutable IP addresses that can't do direct DNS queries to the DNS roots. Even if a system is installed via the network installer, that may be with the goal of eventually moving it into a private network. If your primary DNS resolver doesn't reply due to inability to reach the root DNS servers, it tends to cause all sorts of weird slowness and issues that are hard for the average user to understand or track down, even if you have other DNS servers listed as secondary resolvers. The safe default is still to rely on the organizational DNS resolvers as provided by DHCP or local manual configuration. we can adopt dnssec-trigger (https://www.nlnetlabs.nl/projects/dnssec-trigger/) for such scenarios. I'm definitely in favor of improved DNSSEC support, but I think it's going to need to be something that people can optionally install if we're trying to provide it by bypassing local DNS infrastructure. I still think that the Debian should be a technology leader. Conservative, but technology leader. And DNSSEC adoption would help the case. Also the DSA has already enabled DANE (DNSSEC validated TLS certs) on Debian's MTAs, the postfix 2.11 will have DANE support. I think this goal is very reasonable and I thank Thomas for proposing it. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- 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/1382809952.16288.38938833.72fff...@webmail.messagingengine.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. That isn't obvious to me. We have, in the past, allowed upgrades to require a preliminary upgrade of one or more packages. The udev transition comes to mind. udev transitions have always happened under duress. We should do better than this where we reasonably can. (In the udev case, we had no choice but to require a risky lockstep upgrade of the kernel and udev, because maintaining udev compatibility with older kernels would have required an excessive amount of new work.) We *could* do the same thing here and require an init upgrade as a pre-upgrade step when going from wheezy to jessie, alongside a dependency on systemd or upstart (added by debhelper, for example) for all packages providing startup configuration but not an init script. I'm not saying that's necessarily a good option, but it is an option that we should discuss. Ok, point taken. We *could* decide that something other than sysvinit was now the new least common denominator for jessie, and using dependencies ensure a smooth upgrade (i.e., this still wouldn't be the udev problem). I think that would be a surprisingly bold change for Debian to make in the space of a single release cycle, when up to now we collectively have very little experience running either systemd or upstart in production on Debian, and we don't as yet have a resolution for compatibility with non-Linux ports. Also, we will eventually have to decide whether to drop the requirement that packages provide sysvinit-compatible init scripts. Even if we agree on a requirement to do so for jessie, we could drop that requirement for jessie+1 (and indeed will want to if we choose any init system other than sysvinit or all of the above, given that most of the benefits of either upstart or systemd from a packaging perspective will only be seen when we take that step). We could always defer that decision until jessie+1, but that's the decision with the most impact on kFreeBSD and Hurd, and if I were them, I'd want to know whether that's the eventual project direction or not as soon as possible so that I have as much time as possible to decide on my next steps. Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; my point was that I don't expect this to be something we change in policy for this cycle as part of the TC decision. -- 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: Proposal: let’s have a GR about the init system
On 10/26/2013 10:37 PM, Christoph Anton Mitterer wrote: - Against systemd speaks that it's uncertain on whether there will be a solution in the end for the non-Linux UNIX flavours - which I think Debian should support for ethical and philosophical reasons. Admittedly I have no idea how the situation is there wrt upstart. If neither Upstart or Systemd works for these non-Linux ports, then there's OpenRC. Which is why I worked on it (and I did this, mainly because of ethical and philosophical reasons as you put it). It wouldn't hurt to have more help on it... Cheers, Thomas Goirand (zigo) -- 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/526c1027.3070...@debian.org
Re: Jessie release goal: DNSSEC as default recursive resolver
On Oct 26, Thomas Goirand z...@debian.org wrote: I'd find it very nice if we had, by default, DNSSEC resolving in Debian, at least in the default configuration (whatever that means). By this, I agree with the general principle, but I do not think that a recursive resolver should be installed by default on every system. This would violate a lot of reasonable expectations... Probably this is too narrow for a release goal, or it is too late to raise this topic, though I would find it very nice if we had the feature, which is why I'm raising this topic. Thoughts welcome. It would help if you can describe exactly what is missing to achieve this goal. -- ciao, Marco signature.asc Description: Digital signature
Re: Bits from the Release Team (Jessie freeze info)
Hi, On Mittwoch, 23. Oktober 2013, Stewart Smith wrote: Jenkins can have slaves on remote hosts, via SSH. It runs a small java app there, so as long as the arch has a JVM then you're pretty right. that JVM is not even needed, just schedule jobs via ssh and be done. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Proposal: switch default desktop to xfce
On Sat, 2013-10-26 at 00:00 +0100, Kevin Chadwick wrote: Pros: * CD#1 will work again without size worries * Smaller, simpler desktop * Works well/better on all supported kernels (?) * Does not depend on replacing init * Users can pick and choose components and drop down the size significantly such as for debian embedded or security reasons as it is designed to be modular and follow the unix philosophy. This really pinpoints the whole problem: What happened to the Unix philosophy, with freedom of choice? If you want a locked-in OS, with no choices, choose Mac* or Windows*. This question is really getting out of hand: We are talking Unix system freedom here, with all that follows with it :) Please, freedom of choice, and (preferably free) software! -- 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/1382816708.4094.9.camel@PackardBell-PC
Re: Proposal: switch default desktop to xfce
On Oct 26, Svante Signell svante.sign...@gmail.com wrote: This really pinpoints the whole problem: What happened to the Unix philosophy, with freedom of choice? We killed it for good in 2008: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: let’s have a GR about the init system
On Oct 26, Thomas Goirand z...@debian.org wrote: If neither Upstart or Systemd works for these non-Linux ports, then there's OpenRC. Which is why I worked on it (and I did this, mainly because of ethical and philosophical reasons as you put it). It wouldn't hurt to have more help on it... Having all packages implement the configuration for a second init system just to support a few hundreds of users is not really a reasonable solution. Not just for the time wasted, but also because nobody would test this. -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: switch default desktop to xfce
Hi there! On Sat, 26 Oct 2013 08:08:53 -0700, Andrew M.A. Cater wrote: On Fri, Oct 25, 2013 at 11:44:48PM +0100, Steve McIntyre wrote: Yes, it can. It should contain enough of the packages needed to be able to support all 4 of the recognised DEs. However, at current rates it won't take long for them to outgrow the 4GB of space available! Now that USB sticks at 16/32GB are (relatively) cheap - it is actually a much better bet to install the Blu-Ray .iso image in the same way :) A small note: does anyone consider that there are still people on not-so-fast Internet connections? I am still on a consumer 5000/500kbps ADSL at home and on a professional 4000/512kbps at one of the company I work for. And it seems that where I am now (visiting a friend) is even worse: = $ wget http://cdimage.debian.org/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso --2013-10-26 13:23:12-- http://cdimage.debian.org/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso Resolving cdimage.debian.org (cdimage.debian.org)... 130.239.18.163, 130.239.18.173, 2001:6b0:e:2018::173, ... Connecting to cdimage.debian.org (cdimage.debian.org)|130.239.18.163|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://gemmei.acc.umu.se/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso [following] --2013-10-26 13:23:13-- http://gemmei.acc.umu.se/debian-cd/7.2.0/amd64/iso-dvd/debian-7.2.0-amd64-DVD-1.iso Resolving gemmei.acc.umu.se (gemmei.acc.umu.se)... 130.239.18.137, 2001:6b0:e:2018::137 Connecting to gemmei.acc.umu.se (gemmei.acc.umu.se)|130.239.18.137|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3934945280 (3.7G) [application/x-iso9660-image] Saving to: ‘debian-7.2.0-amd64-DVD-1.iso’ 0% [ ] 410,076 107KB/s eta 8h 55m ^C = I am full in favor of dropping CDs, but not with the reasoning that no one use them anymore. Despite I usually prefer the netinst multi-arch *CD*, I always have the default CD1 in my laptop bag, it could be useful to install Debian with no Internet connection at all (maybe I am a bit too old in this regard). Thx, bye, Gismo / Luca signature.asc Description: PGP signature
Re: let's split the systemd binary package
* Simon McVittie: Session tracking includes suspending/hibernating, because logind has a mechanism to let apps delay suspend, which is necessary for things like closing the inherent race condition in lock the screensaver when we suspend... oh, oops, it didn't get scheduled until after we resumed, so the old screen contents are still visible for a moment when you open your laptop. Has this finally been fixed? Locking and suspend is not synchronized in GNOME 3.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/87y55faii2@mid.deneb.enyo.de
Bug#727795: ITP: node-raw-body -- Request body length validation supporting streams - module for Node.js
Package: wnpp Severity: wishlist Owner: Jérémy Lal kapo...@melix.org * Package name: node-raw-body Version : 0.0.3 Upstream Author : Jonathan Ong m...@jongleberry.com * URL : https://github.com/stream-utils/raw-body * License : Expat Programming Lang: JavaScript Description : Request body length validation supporting streams - module for Node.js This module gets the entire buffer of a stream and validates its length against an expected length. A limit can also be set, preventing memory exhaustion. It is useful for parsing request bodies. . Node.js is an event-based server-side javascript engine. -- 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/20131026204154.19830.69472.reportbug@imac.chaumes
Re: Bits from the Release Team (Jessie freeze info)
Hi, (I was not able to find the debian-ports list on lists.debian.org (so I subscribed via email) did I just miss it?) Quoting Steven Chamberlain (2013-10-23 22:04:59) I had a play with the 'botch' tool (see description[1]) for determining build order when bootstrapping an architecture. botch author here. Just stumbled upon this already a few day old email in my inbox :) To start off with it determines a minimum required set of packages - you'd normally cross-compile those from another system. This set (see attached example list for kfreebsd-amd64 wheezy) looks to me like what constitutes the 'toolchain'. This minimum set of packages which has to be cross compiled (because no binary package of the target architecture exists at this point) is what we call the minimal native build system (the name is misleading as disjunct dependencies make different choices of this set possible). Currently it is not possible to present a correct selection of source packages which have to be cross compiled to produce the minimal build system. What we currently do is to just do: grep-dctrl -X \( -FPackage build-essential --or -FPackage debhelper --or -FEssential yes) and assume that the resulting list of packages (the one you attached to your last email) is cross compilable from nothing. This is of course not the case in practice but a formal analysis is not possible yet. This is because multiarch annotations are missing in some packages and because of the problem of how to handle source packages directly depending on gcc, g++, binutils etc in the cross compilation case. While the first one is easy to fix there doesnt exist a solution for the second one yet. Build profiles would be able to solve the second problem. Until these two issues are fixed we will not be able to get an algorithmic answer to the question of what constitutes the minimum required set of packages. On the other hand wookey did lots of ubuntu crossing and identified that with just (I think it was) a dozen modified packages (reducing their build dependencies to break cross build dependency cycles) he was able to cross build all of these packages: http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html So while an automated analysis is not possible right now, it also does not seem to be necessary to have this automated. Having the to-be-crossed selection of packages retrieved automatically becomes more interesting as more source packages are known to be cross-compilable including all their required recursive build dependencies. The list will be different for each port, and change over time. This example included freebsd-libs, freebsd-utils and kfreebsd-kernel-headers but of course others won't. Thanks for trying out botch for kfreebsd :) AIUI those packages should be able to rebuild each of themselves without any other dependencies. Should but unfortunately they are not :( In fact, to nativel rebuild the minimal build system for amd64 (just essential:yes + build-essential + debhelper) one needs to be able to compile 383 source packages (excluding the source packages in the minimal build system itself). This is as of debconf13 when I last ran those scripts. You can look at the numbers here as well: http://mister-muffin.de/bootstrap/stats/ These 383 source packages include ugly ones like iceweasel, nautilus, webkit, network-manager, mysql, kde4libs which as you can imagine draw in half of what makes a modern desktop system and thus might naively have been dismissed as non-essential for the bootstrapping purpose at all. But of course this list will be different between arches. I think doing that regularly would be a good health check for a port's toolchain. Probably these packages would be the focus of the reproducible-builds project, at least from a security point-of-view. Any differences in output of subsequent builds are of interest, and would potentially reveal when significant changes or bugs were introduced too. Being able to use botch to automatically bootstrap all arches from scratch has always been one of botch's goals. Unfortunately the build profile discussion is holding up the implementation of this in practice but guillem promised to look into this for dpkg 1.17.2. cheers, josch -- 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/20131026213931.16796.6@hoothoot
Re: Bits from the Release Team (Jessie freeze info)
Johannes Schauer j.scha...@email.de (2013-10-26): (I was not able to find the debian-ports list on lists.debian.org (so I subscribed via email) did I just miss it?) Dead list: http://lists.debian.org/debian-ports/ AFAICT it's now an alias for all debian-$port lists. Mraw, KiBi. signature.asc Description: Digital signature
Re: Proposal: let’s have a GR about the init system
On 25/10/13 16:28, Russ Allbery wrote: Fully supporting an init system means, among other things, writing or generating native configuration files for that init system so that we can take full (or at least fuller) advantage of its capabilities. We're currently not doing that for anything other than sysvinit. For what it's worth, quite a few packages already ship native systemd and/or Upstart jobs alongside their sysvinit scripts, which are used in preference to the sysvinit scripts: # systemd units on my laptop that are generated internally by systemd # when it reads a sysvinit script (or LSB init script as it # calls them) % systemctl list-units | grep LSB | wc -l 36 # systemd units on my laptop that are really systemd units, # only counting .service files (its closest equivalent of init # scripts) and not counting systemd's equivalents of the initscripts # package, or daemons from src:systemd % systemctl list-units | grep -v 'LSB\|systemd-' | grep '\.service' | wc -l 28 # Upstart jobs on my laptop % ls /etc/init/ | wc -l 17 I keep meaning to write native systemd units for my pkg-games packages, but they're still in the LSB category at the moment. S -- 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/526c3be5.9020...@debian.org
Bug#727797: ITP: node-fresh -- Check freshness of HTTP request and response headers - Node.js module
Package: wnpp Severity: wishlist Owner: Jérémy Lal kapo...@melix.org * Package name: node-fresh Version : 0.2.0 Upstream Author : TJ Holowaychuk t...@vision-media.ca * URL : https://github.com/visionmedia/node-fresh * License : Expat Programming Lang: JavaScript Description : Check freshness of HTTP request and response headers - Node.js module This module checks HTTP If-Modified-Since, If-None-Match, Cache-Control request headers, as well as Last-Modified, Etag response headers to determine if the client requesting the resource has a stale or fresh cache. . Node.js is an event-based server-side javascript engine. -- 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/20131026220336.27946.49137.reportbug@imac.chaumes
Re: let's split the systemd binary package
On 26/10/13 21:23, Florian Weimer wrote: Session tracking includes suspending/hibernating, because logind has a mechanism to let apps delay suspend, which is necessary for things like closing the inherent race condition in lock the screensaver when we suspend... oh, oops, it didn't get scheduled until after we resumed, so the old screen contents are still visible for a moment when you open your laptop. Has this finally been fixed? Locking and suspend is not synchronized in GNOME 3.8. My understanding is that this was finally fixed in the GNOME 3.8 cycle: if you have GNOME Shell 3.8 and logind, and something suspends *via logind* (including hotkeys, lid-close events and Shell itself), suspend will be delayed until either the Shell has locked the screen, or some reasonably long timeout has elapsed. I could be wrong there, though. If a privileged process suspends not-via-logind (direct use of kernel interfaces, and perhaps also pm-suspend), then logind doesn't have the opportunity to enforce that locking. Also, I'm not sure whether gnome-screensaver, as used in fallback/flashback/whatever it's called this week, participates in that locking mechanism. S -- 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/526c3fd8.3070...@debian.org
Bug#727798: ITP: node-range-parser -- HTTP Range header parser - Node.js module
Package: wnpp Severity: wishlist Owner: Jérémy Lal kapo...@melix.org * Package name: node-range-parser Version : 0.0.4 Upstream Author : TJ Holowaychuk t...@vision-media.ca * URL : https://github.com/visionmedia/node-range-parser * License : Expat Programming Lang: JavaScript Description : HTTP Range header parser - Node.js module This module parses the HTTP Range header, relative to a given length, the length being a file size in most applications. . Node.js is an event-based server-side javascript engine. -- 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/20131026230345.9116.68890.reportbug@imac.chaumes
Re: Bits from the Release Team (Jessie freeze info)
Johannes Schauer wrote: Until these two issues are fixed we will not be able to get an algorithmic answer to the question of what constitutes the minimum required set of packages. There is also the complication of what I will call non-key self building compilers. fpc is an example These are not needed to bootstrap the core of debian but if one wants to bootstrap all of debian they will need to be built. Since the only way to build them is with themselves they cannot be bootstrapped natively even with the help of build profiles. So the only way to bootstrap them is to either cross-build them or start with a binary from upstream. -- 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/526c4c1c.3060...@p10link.net
Re: Proposal: switch default desktop to xfce
On Oct 26, Luca Capello l...@pca.it wrote: A small note: does anyone consider that there are still people on not-so-fast Internet connections? Yes: unless they need to install multiple computers (unusual, I think) and do not know how to share the downloaded packages among them, then netinstall is the most efficient choice in this scenario. I used to do this with 56k modems... -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: let’s have a GR about the init system
On Sat, Oct 26, 2013 at 11:02:13PM +0100, Simon McVittie wrote: # systemd units on my laptop that are generated internally by systemd # when it reads a sysvinit script (or LSB init script as it # calls them) % systemctl list-units | grep LSB | wc -l That's only currently loaded units, i.e. probably the ones which are/were running, without --all. # systemd units on my laptop that are really systemd units, # only counting .service files (its closest equivalent of init # scripts) and not counting systemd's equivalents of the initscripts # package, or daemons from src:systemd % systemctl list-units | grep -v 'LSB\|systemd-' | grep '\.service' | wc -l 28 Also it's better to say systemctl list-units -t service --no-legend --all then grep by type. Yours nitpicky, Zbyszek -- 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/20131026233712.gm28...@in.waw.pl
Re: Proposal: s have a GR about the init system
On Saturday, October 26, 2013 10:45:55 Charles Plessy wrote: Conflict of interest is not a judgement on a person. It is a judgement about a situation, and a recommendation on how systematically react, without making exceptions. Le Fri, Oct 25, 2013 at 10:31:32PM -0400, Scott Kitterman a écrit : It's one thing to say there's a potential bias that people should be aware of (as Russ did). It's quite another to say that a tech-ctte vote in which they participate is illegitimate is another. This only comes up because we know who they are employed by and what their interest is. Many people in Debian are employed to do different things related to Debian that aren't disclosed. Unless there's some kind of disclosure policy for everyone involved in the any technical discussion around Debian, I think it's silly to claim Steve and Colin are inherently unable to separate what's good for Debian from what's good for Canonical. This is just one more symptom of irrational anti- Ubuntu/Canonical bias I see from some people in Debian and I encourage Steven and Colin not to give in to it. Le Sat, Oct 26, 2013 at 07:55:00AM +0100, Neil Williams a écrit : If there are people inside Debian (i.e. people who would have a vote in a Debian GR or who are actively involved in packaging) who have no confidence in the Debian Technical Committee to come to a fair decision for the benefit of all of Debian then I would be concerned. That random people not involved in Debian have prejudged individual members is of no concern. Hi all, the reason why the reaction to a conflict of interest should be automatic is that it protects the people: their honesty is not put in question. They do not have to justify it or to convince others, they just automatically refrain from voting, regardless how themselves or others are confident that they would vote without bias. It also protects the comittee itself, by completely nullifying the question from the very start. I strongly recommend that the three current and former employees of Canonical refrain from voting: not only because of the current circumstances, but also to make the case for the time a different conflict of interest will happen. We should not consider that we can have a relaxed attitude now and that we will do the right time at that time, this is wishful thinging. If we do not keep high standards now, it will be hard to have high standards then, because the same arguments will come again, that the mere idea that somebody can be biased is insulting to that person, etc... Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131026234959.ga14...@falafel.plessy.net
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
On Sat, Oct 26, 2013 at 1:57 PM, Colin Watson wrote: Linking in the correct order is not a workaround; it's being correct. I wasn't talking about link-order stuff but about dependency inflation; binaries linking against libraries that aren't used by the binaries linking against them. IIRC this is the purpose of --as-needed and what it works around. To clarify further, I think --as-needed should be the default in GCC upstream, not just in Ubuntu or elsewhere. Debian should not make it the default before upstream do. Until it becomes the default in GCC upstream, Debian should send patches to remove dependency inflation from upstream build systems. If the linker generates errors then we will be forced to send patches but if the linker just warns then we would have to rely on the buildd log scanner reporting these issues to maintainers via the PTS. Hopefully our upstreams will eventually start using the new GCC and begin fixing these issues on their own. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6G-r-prrxL=L1DY6-Q+OCjj=cwjkys2y26rxh2r09k...@mail.gmail.com
Re: Pro-Action against dependency hell
On Sat, Oct 26, 2013 at 11:54 PM, Kevin Chadwick wrote: epdfview depends on libqt epdfview has been removed from Debian but it never depended on Qt, always GTK+: http://bugs.debian.org/710550 http://packages.debian.org/source/stable/epdfview evince pulls in the whole of QT adding ages to the build time. None of the build logs here mention anything to do with Qt, since evince only uses GTK+/GNOME related technologies. https://buildd.debian.org/status/package.php?p=evince It would be rediculous if chattr +ias /sbin/init needed to be set before installing systemd. It isn't needed because the systemd package does not include that pathname: http://packages.debian.org/sid/amd64/systemd/filelist -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6G0HooOjKxb5AWSv71FQZ63nQ3_=p7w4zbepaw6mx5...@mail.gmail.com
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
Paul Wise p...@debian.org writes: I wasn't talking about link-order stuff but about dependency inflation; binaries linking against libraries that aren't used by the binaries linking against them. IIRC this is the purpose of --as-needed and what it works around. To clarify further, I think --as-needed should be the default in GCC upstream, not just in Ubuntu or elsewhere. Debian should not make it the default before upstream do. Until it becomes the default in GCC upstream, Debian should send patches to remove dependency inflation from upstream build systems. Good luck with that. I haven't been able to get rid of some dependency inflation even in packages for which I'm upstream. In some cases (such as a shared library package that also contains binaries linked against that shared library but which don't need to be linked with the dependencies of the shared library), the only way to do so is to stop using Libtool completely, which I'm not willing to do. Even when it is possible, it often requires a complete rewrite of the upstream Autoconf machinery that makes it considerably more complex, and upstream is going to rightfully ask why?. And I don't think we have a good answer. If the linker generates errors then we will be forced to send patches but if the linker just warns then we would have to rely on the buildd log scanner reporting these issues to maintainers via the PTS. Hopefully our upstreams will eventually start using the new GCC and begin fixing these issues on their own. They will for link order, since that's important. They won't for dependency inflation, because it's a lot of work for no obvious gain, particularly when --as-needed exists. I used to feel the way that you did and tried to patch the software that I packaged, and finally realized I was just being masochistic. I switched over to --as-needed for packages like gnubg and the intense relief I felt was the wall that I stopped beating my head against. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87iowjwj85@windlord.stanford.edu
Re: Proposal: switch default desktop to xfce
Neil Williams codeh...@debian.org writes: Please reconsider this. If I wrote a little GUI calculator and made it depend on e.g. upstart, would that also make upstart unsuitable as a default init system because of the resulting insane top-down dependency? Yes. Aeh, are you sure? I think you missed my point. I'm not involved with any init system, nor a Debian developer, yet by developing some random app and having it depend on a specific init system, I could (according to you) make that init system unsuitable for Debian? That doesn't make any sense at all. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- 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/87r4b7xtif@vostro.rath.org
Accepted mailnag 0.5.2-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 25 Oct 2013 23:19:50 -0700 Source: mailnag Binary: mailnag Architecture: source all Version: 0.5.2-2 Distribution: unstable Urgency: low Maintainer: Vincent Cheng vincentc1...@gmail.com Changed-By: Vincent Cheng vincentc1...@gmail.com Description: mailnag- mail notification daemon for GNOME 3 Closes: 722243 Changes: mailnag (0.5.2-2) unstable; urgency=low . * Add debian/patches/libnotify_api_compat.patch: fix failure to check mail due to API changes in libnotify 0.7.6. (Closes: #722243) * Bump dependency on gir1.2-notify-0.7 to (= 0.7.6). Checksums-Sha1: a287adfb89e2bd04b6d3596855517c44f14ea190 1875 mailnag_0.5.2-2.dsc 36725ca9b1bf592d1b56df753043605cb6bbaa3c 5572 mailnag_0.5.2-2.debian.tar.gz 3a08f9db61cf28016e3da663c1e250696444f94c 74472 mailnag_0.5.2-2_all.deb Checksums-Sha256: f050189f9e59908d92f6ca1bc54e71fee240ff2e96f9dbb5996286c99c8e4cd7 1875 mailnag_0.5.2-2.dsc 28597d8a5b42f5ccf70763be6c297efb479795805a33f53aa3ef20a9fe4c65d4 5572 mailnag_0.5.2-2.debian.tar.gz c6ecb4784a8ea6c382310c3ac31619234428efd781c911a1d93dada22bd836a7 74472 mailnag_0.5.2-2_all.deb Files: 1b4c91041e70a6317ef4d5fa51ef581b 1875 gnome optional mailnag_0.5.2-2.dsc 23d310f4a743f7a74cfc70f4f4ace916 5572 gnome optional mailnag_0.5.2-2.debian.tar.gz 781d0b497af1159abc47b4aa57483280 74472 gnome optional mailnag_0.5.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSa2LNAAoJEI7tzBuqHzL/SX8QANyeT8A3k5EUUg2EzRHDDj1I DC1b5G8qcdCTEhEYx+k5uDN5KO/tG4UU46U84qyDzOJbhzm5uDu64zBzd79p4TPh /a6X+WSwLumhSkanO+ovO93vkDQzRsVooGgMdn97pzRu/xia8/S7T4ecyfITFuHq TTSM/2rE3QPxVkXtQKLRdJ62mBi6iD1ifFXnF2n3BhK44P1jBTfDWjg04pGfXrNI kc9nKXv0BD1u5PFpyDFqpYQ5c90bINLmlFdM4/EJwFOMervjFwdhVTPHblikxLk2 X4hwWBqu1Goi0e0SOPM0bf+mBqlCuMt5daAej7jZG8RFciQOmHiR6HrYbreRK58d J6Rj/mca7Hbl4Ib5QjNyxANibk6k/HBMunynpO8QVAbXCZJajY3XU1yzcCYqiAcN wcZtnH7rEdDVQnpRxmnq9WYYYeY/vuMfdY5XGzC8F2hJ23rTPt0PMBT5JZn1nm8i /2v6NOmFnQ/whWiIZU9hvQncsOKtTFbp78OyDRjJhxKpLA0GVHufrESlqwssuupp IfJBJEf/dYjrAIt5eDRC339V44wrZUca/P7x8vFW7Bs4M9gOUg3C2KKmXowM9JS2 BBz5yzl8+jaxoU82VkFeZJv7a1EqEr6Q98S0TmvUs3AjKcFzDiEmJyVCtWC+K2mw ZduAJVGL2bFYlRWNRs6e =LmOv -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/e1vzxfv-0003jy...@franck.debian.org
Accepted polipo 1.0.4.1-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 12:35:24 +0800 Source: polipo Binary: polipo Architecture: source i386 Version: 1.0.4.1-4 Distribution: unstable Urgency: low Maintainer: Rolf Leggewie f...@rolf.leggewie.biz Changed-By: Rolf Leggewie f...@rolf.leggewie.biz Description: polipo - lightweight, caching web proxy Closes: 292992 Changes: polipo (1.0.4.1-4) unstable; urgency=low . * provide sample configs as examples instead of installing them to /etc * Log to syslog by default. Closes: #292992, LP: #1055390. Checksums-Sha1: 402f0fe9f3db4e18105dfd61a1843f7d2fd5995f 1901 polipo_1.0.4.1-4.dsc c94245aeb4164a6dced77bfa15377c6a5954d90e 14924 polipo_1.0.4.1-4.debian.tar.gz d4c71e9c236e72665fb36cec1da076285c7243f3 173850 polipo_1.0.4.1-4_i386.deb Checksums-Sha256: 64563dda454e1dd899434465757f7fb78bd4e5277344dc2da5546a08368edacf 1901 polipo_1.0.4.1-4.dsc f1554732dd32f464b8645f3ae8273ca28f618c74d6f7fb3578b7df690245d400 14924 polipo_1.0.4.1-4.debian.tar.gz 4c963aaf19327164c06476359e079bddbf60bb062b59b9cd3c403ac3a0fa90f3 173850 polipo_1.0.4.1-4_i386.deb Files: ae52d29e13815f46f81bfdcab30b51aa 1901 web optional polipo_1.0.4.1-4.dsc 6374767a92c5af4a6ea8947bea9a0a4d 14924 web optional polipo_1.0.4.1-4.debian.tar.gz e3f292f20da7a7ee4de79db4f0c2c86c 173850 web optional polipo_1.0.4.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSa2W2AAoJEJSEK8huURwxGOsP/008t4x1Fk76CSD7t4xqlPD2 bdlR/nTiqsyhC7legF+ksHtTANtooEZaiLKkpN73PoZmTbsluZkUVIA9XEN6MFjN yCt0hJsatjoX7YGcY9SsrNxI19AN/KtwNnAHgHvof3uhCSQF0IrbQCdO360NF0YE BEDlTDobNcCtvpyLs+Qr5wNQj8E8+UpTBALOVFNxHnCou4HD0aCr+G0TDbWOmI2M 14EqigngxHm9m5xIk43dkD0ZkF8lw/QPIdRKIuCxoC5z0z4gx2wSBHoH9NvKra0V otZqC8jSPgGiJnhivS8aikmdR9LH+3Whrxsa1aRlfhXhbnoJuGDi59fHjQdtR74a q7QoMGx0htXvzyqB/V3jqNQrtbTjAWS998bLQTk1/dSjk/F3i0VXE9PkH1EUloGY tNqUOgw6Apeq4tQFqs8C4iuZk7Qc2HjyFRrU3ruAheJCleO7NfSBpBNVHPkXXyTK /hBbjQkNA7jthLlKAUwQ5meDL33gojgieGAImcVbkrN2weRianiDY2amMDvD/aEh nAaOMOH1S7hx0Lf/f8Y2zYqZgui7pUz/kYtJlvK6jXEDuxZUuPAV3w9NT0ZxrzH+ VIT0LG4eHNKSBNva0KAoRmKAJtwQqmeSA+VwruYDLCwiXTgCT9s/rqaW6aVCjqZK ektMwm4Iq7l8SvaWR5uL =9c1Z -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/e1vzxuh-0007cq...@franck.debian.org
Accepted libperl-critic-perl 1.120-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 26 Oct 2013 08:42:05 +0200 Source: libperl-critic-perl Binary: libperl-critic-perl Architecture: source all Version: 1.120-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Salvatore Bonaccorso car...@debian.org Description: libperl-critic-perl - Perl module to critique code for best practices Changes: libperl-critic-perl (1.120-1) unstable; urgency=low . * Imported Upstream version 1.120 Checksums-Sha1: a5de6c041b87cc09ab49059515ba03373b559b4d 2777 libperl-critic-perl_1.120-1.dsc fbb9fced6d5cf8b65ea1fb260cbc7030f33fc094 646517 libperl-critic-perl_1.120.orig.tar.gz 905c920203be6705a28d5ea869d965778091843e 9002 libperl-critic-perl_1.120-1.debian.tar.gz 1da44aa4c9f0685f75de4bce9ae29ed4978c52d0 830408 libperl-critic-perl_1.120-1_all.deb Checksums-Sha256: 70a0bbe5459ced1e542bc792e10bee861c082bbe94d9979f6131290f68d7a09d 2777 libperl-critic-perl_1.120-1.dsc 7cee0df9cfeafaaba24ba46f4d00256a2ca2fad2a4b6fb8a60c6fd47a75e2fee 646517 libperl-critic-perl_1.120.orig.tar.gz f6293feafffed24a410b9f75bd62149fe19e932ebab44a11cc7b30a84b888cce 9002 libperl-critic-perl_1.120-1.debian.tar.gz 653269ef700d3e551928ea02f22378e1899532a9df3e37f7acacbcd4d41c3cba 830408 libperl-critic-perl_1.120-1_all.deb Files: 1cd264bd53452c3f944c125e4013f5b1 2777 perl optional libperl-critic-perl_1.120-1.dsc 4faa7c55f94b2068770d6f41f3a1cc6f 646517 perl optional libperl-critic-perl_1.120.orig.tar.gz 28be77cfe5e6899df3b7efb2f1d2ec74 9002 perl optional libperl-critic-perl_1.120-1.debian.tar.gz ef3300075450781b845cf59a5048b92c 830408 perl optional libperl-critic-perl_1.120-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCgAGBQJSa2VvAAoJEAVMuPMTQ89ERFYP/j3T8ETNMYHt5VXtkNq1sRbR 3d/czpoQVIafOxijtQi7BNYr106Bj9N0FguG54lCHscLVPF0TWC3FFWN6qcSfElh YIWNzGp/+UALHhKkfpHTouShm0stafP2ObqnCVj66cbXCT/aQ+gBdtczJRdkl0Fr nZ63ZoU4vRH9vtoD4jrpJ8U2VI2Z74vHR6ayuk7cAmgg+eE7UAfElGK4CVRjx5P7 hJlPOHskEmDBs5UuVEMAJwFyzpla1ctuhbbnKXhJVnNjNoxHl8BQ5HZ9NITP7ENi QWcITiXhDwHaWfTItSxLXu5JII+RYclbGi5tizHO4V/Z9Zdkhavi2iunwiduYuza HFKF7UGICiGm479hmToasnVmCLrjjGjpYYlXJxwUSMJAoYwpYGfHGFHCqAbscWRi ANuc67hT8rBxe9F+ciVJrBPTgH9d/P6dIj6XgEKe/xrM95jvNkIFTSO2mLhz0rQX 98gYlWbWAkTLF2OMqYr8uDeq8js1i8Ue5lgKQ5mqXlOu0X9sUQew0FfoeamV11dX gqPf5roHdGrfDUfaikB7Romm2Jtk0ERALEtI2ZQES24XeHJGYCBA/T8cVZ7KfDJp tR58y/Q28uACmRdwSm/M9MF9kvdfQ9N+qC1R0Ye+lIy1M9T1d23MP3uSmT7RrwhJ ekEV33wEp30d0pgWKjlR =nlrU -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/e1vzxua-00079v...@franck.debian.org
Accepted julia 0.2.0~rc2+dfsg-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 04:33:44 + Source: julia Binary: julia julia-doc julia-dbg Architecture: source amd64 all Version: 0.2.0~rc2+dfsg-1 Distribution: experimental Urgency: low Maintainer: Debian Julia Team pkg-julia-de...@lists.alioth.debian.org Changed-By: Sébastien Villemot sebast...@debian.org Description: julia - high-performance programming language for technical computing julia-dbg - high-performance programming language for technical computing julia-doc - high-performance programming language for technical computing (do Changes: julia (0.2.0~rc2+dfsg-1) experimental; urgency=low . * New upstream release candidate * Link dynamically against LLVM, this seems to now work correctly Checksums-Sha1: 1f6afd581dc4b5a410f64b866bbf3e7db7b48333 2317 julia_0.2.0~rc2+dfsg-1.dsc 67db4edd8015064d975c37c6f64a0393a05eaaa7 2456744 julia_0.2.0~rc2+dfsg.orig.tar.xz 23719f66a05961676c2671ff2b956a201bae03b6 27747 julia_0.2.0~rc2+dfsg-1.debian.tar.gz a1365c595cc6758a551f378bcc6b1b141f48cb84 1958292 julia_0.2.0~rc2+dfsg-1_amd64.deb f8e9eb029179ba506f9bce850cdc57aa2487740f 439808 julia-doc_0.2.0~rc2+dfsg-1_all.deb aa7fb93bb09186504e9f93e038d674ed25d34ac2 1830284 julia-dbg_0.2.0~rc2+dfsg-1_amd64.deb Checksums-Sha256: b206b12da93efabc0c9cbb4659feea0a35a0f3576d2f2e49b58268e02250d7e0 2317 julia_0.2.0~rc2+dfsg-1.dsc 91a99d03f509b8219ff5c8236e094f9a22332e56c5d729194308db6e958254f9 2456744 julia_0.2.0~rc2+dfsg.orig.tar.xz ac3f98749b84481c272afefd68e322ec33ec60ffa292ba4fc2d54affde7decc4 27747 julia_0.2.0~rc2+dfsg-1.debian.tar.gz 2f314e1f3f02438b75eb34983873008ad5719ab3da13ad3ebae4a3f72b00796c 1958292 julia_0.2.0~rc2+dfsg-1_amd64.deb 011362c885bb0aca34e981db5aa40f8ed245afb9f3f23c7f994a370940e3b02b 439808 julia-doc_0.2.0~rc2+dfsg-1_all.deb 59209ef2fb240ebbd225dbe8aeeeda2be3d13b1655c0b61cafdb105ed5dda1c9 1830284 julia-dbg_0.2.0~rc2+dfsg-1_amd64.deb Files: e9979e3e568377e1cf5ddd69d8a7883d 2317 science extra julia_0.2.0~rc2+dfsg-1.dsc c55d5b5d6237fcdfdf7aeef76153dab3 2456744 science extra julia_0.2.0~rc2+dfsg.orig.tar.xz 9f893ca8589d7cdba4a04a646bf384a7 27747 science extra julia_0.2.0~rc2+dfsg-1.debian.tar.gz 28cc23bf643eb516a7726e9bc2e67620 1958292 science extra julia_0.2.0~rc2+dfsg-1_amd64.deb ff99af9e41683a53a5fd94b1946548ee 439808 doc extra julia-doc_0.2.0~rc2+dfsg-1_all.deb 170a47a65d8a026db4a6e388244d14e9 1830284 debug extra julia-dbg_0.2.0~rc2+dfsg-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSa2VUAAoJECzs6TUOzr5KxGcQAKaYj0G5vdc1FTpvy89guoZf /nquZRIlwNZLoL3qeWULq/8cOKSYZm31wzgI3CaeCYTSbXEZMUKLPZwa1X7WDOZf BNivjPETQlckzpxYA1IypyhlMf7XHx3nHX+d/zzFHWea24eYS+ELsPJU3s2tbgwY J0mSG6liHI1QTZhrOmut8cjAY/4jihzK9GMakgPIfecUN/9HjkXAPWJcc/z8309j gDv5CG1ywmcOXthPuKThEL69n7CSDb3GtKveiZ4CtssNgXhoDnJ0AbBDcBuT79FR atOY+Xq5x3Ie10p6NhIbagLk3dGWxPnAAlUDLMUCWQCm9MvT9j/z9AAkeG8M8glH YBdJg4kkERnsyY9LjXq6ru2HOm8Kb3g9tbv8lOLKpOb/yoemrxM+ZCWreHYZk0EM eKfuiIGjuO6WqRj6XWIR7mVZDIcRilDpPfxuAxtpU6Ge/RCS4RSYJE/ZuTj0ru2b 7CERBryVOFaNZ37KAaJ1TUMUjMTXJ9AOZGkVT8Wq7KLvI3NdFScPQljtmLIbY9jQ ZGhuVdkrTMte/feueFESUxxL6ioMPd44Kn+0ENVnMzcGHroEq6UrH6TKeE2W0E0G 9DpjWtx37BSBsSFrLL4Hd+LOactU42oWVXXtiqJuXghOG6uk9ERXmkfXvR2Iz5d9 Uf4hKD4egJHNGFUvwDft =eEUc -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/e1vzxur-00077o...@franck.debian.org
Accepted exim4 4.82~rc5-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 26 Oct 2013 08:50:58 +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 i386 all Version: 4.82~rc5-1 Distribution: experimental Urgency: low Maintainer: Exim4 Maintainers pkg-exim4-maintain...@lists.alioth.debian.org Changed-By: Andreas Metzler ametz...@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.82~rc5-1) experimental; urgency=low . * New upstream version. Checksums-Sha1: 0ae78780b7aefe74c13881b8fd08318b82c12b40 2854 exim4_4.82~rc5-1.dsc ca5dac1ec201198abc552b871d59fbfd93136a8d 1723209 exim4_4.82~rc5.orig.tar.bz2 0b3045fd11e92f7aba145dffbec17434b5b4587c 575477 exim4_4.82~rc5-1.debian.tar.gz 66ea7c912cd9117519d89bdf54e7b217673757f4 1028374 exim4-base_4.82~rc5-1_i386.deb 4923a925a6cb2a83952b5700d97f78ff0dc0919b 207952 eximon4_4.82~rc5-1_i386.deb 6b8753b43f7849558018332dd4c9047a3c58da45 568650 exim4-daemon-light_4.82~rc5-1_i386.deb a0dfcc0a451f5922711547d5d0061290a356e48d 614738 exim4-daemon-heavy_4.82~rc5-1_i386.deb a2d36f9c4f203a653674e148c3251fce9bbc41f7 918320 exim4-daemon-light-dbg_4.82~rc5-1_i386.deb 34d9003bfb72c838820893694f24966a8143c81d 1030590 exim4-daemon-heavy-dbg_4.82~rc5-1_i386.deb bf28044e442d4200eade35f86c93591cadf828bc 342360 exim4-dbg_4.82~rc5-1_i386.deb 383024017eacff692540dee8a8ff12e5aaa5f48f 179348 exim4-dev_4.82~rc5-1_i386.deb 5662d7230fa306d3f959f54ad0283767bc85214b 461522 exim4-config_4.82~rc5-1_all.deb f549848b73ec13f2add004c427677b4a6c77c0fd 7856 exim4_4.82~rc5-1_all.deb Checksums-Sha256: 498f829edc0318f4fae49b4104aa39d40a3ce98b36b2c76a0604910c5e66f228 2854 exim4_4.82~rc5-1.dsc 242fb17bd69b828b0bb5d3b907def6b4447750ceb92e5360d93dd83c4779e7ec 1723209 exim4_4.82~rc5.orig.tar.bz2 20d751a9d524a9c83d651ac72113b98503937d0923b4d3e86b115e4c7a15ed07 575477 exim4_4.82~rc5-1.debian.tar.gz 7d976e5a135b1f4549cf9b8edf3b0b2617729a8fa065247041f42d93a7ac838b 1028374 exim4-base_4.82~rc5-1_i386.deb daf1e88d8d17cc7b78c25b856f9a81a47e35a96d7fbcd14fa431cf69c61c05eb 207952 eximon4_4.82~rc5-1_i386.deb 2964763f1b87bf9cde4e6924a7e027688aa444d967e8426ca1a69bb3d23aeaa0 568650 exim4-daemon-light_4.82~rc5-1_i386.deb 6a1abbb5eb0446efb4b72509ab1be94949eaedef4f94ec8c44d271f44f69 614738 exim4-daemon-heavy_4.82~rc5-1_i386.deb dcd58b3b35ac12180a61b429a8b42a36af5ce6b5c9114100830b22ad271a284e 918320 exim4-daemon-light-dbg_4.82~rc5-1_i386.deb e616b96bf41937007380957a5a90b63b4efcd9beda902c4ac6974c6ae6da0b3b 1030590 exim4-daemon-heavy-dbg_4.82~rc5-1_i386.deb 63cdbc472e1e35086b259197a9a2b22bf4866082992dab1be4b8acac97980454 342360 exim4-dbg_4.82~rc5-1_i386.deb 57f09559d1bbfa8403fd77bd0f3a69ba52a637329a65ec5b4e4db918da1925ed 179348 exim4-dev_4.82~rc5-1_i386.deb b1f177f1d31595caec6eeb189afb35ec676855f5fe771ba5e5dbe7f4f1ccbba9 461522 exim4-config_4.82~rc5-1_all.deb 133bb80456dad1d17d04b6069ea820011d9cced901ed40bf0f3e494b40021df0 7856 exim4_4.82~rc5-1_all.deb Files: e4956190ebe4eefcf16a2a42b2e2e2e0 2854 mail standard exim4_4.82~rc5-1.dsc 836478fada4b679bef572517ff1b85b6 1723209 mail standard exim4_4.82~rc5.orig.tar.bz2 1b8d1c402b39fd0cc8b878f480c835fe 575477 mail standard exim4_4.82~rc5-1.debian.tar.gz 73c4ebdb4ec8048f4d08ac9cb9fa2feb 1028374 mail standard exim4-base_4.82~rc5-1_i386.deb 82a5ccb7e7ef5b3648e20d59c9120ed7 207952 mail optional eximon4_4.82~rc5-1_i386.deb 0d0555a6056160249c3cd1b912bf41a5 568650 mail standard exim4-daemon-light_4.82~rc5-1_i386.deb 41cefa697e68de8b484ba6fb979efb66 614738 mail optional exim4-daemon-heavy_4.82~rc5-1_i386.deb 0e93593dddc73759c0f8780e22a4b164 918320 debug extra exim4-daemon-light-dbg_4.82~rc5-1_i386.deb f6509cfda92d38adce5a0bbbf0b0264b 1030590 debug extra exim4-daemon-heavy-dbg_4.82~rc5-1_i386.deb d45b607541b450e4359a20fe9150034f 342360 debug extra exim4-dbg_4.82~rc5-1_i386.deb 3d31f62dece641053ab5e1fdc19c4bfa 179348 mail extra exim4-dev_4.82~rc5-1_i386.deb 480e8a8e2628876d791421aaf738c723 461522 mail standard exim4-config_4.82~rc5-1_all.deb
Accepted ttt 1.7-3.4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 17 Oct 2013 10:40:42 +0400 Source: ttt Binary: ttt tttview tttprobe Architecture: source amd64 Version: 1.7-3.4 Distribution: unstable Urgency: low Maintainer: Thomas Scheffczyk thomas.scheffc...@verwaltung.uni-mainz.de Changed-By: Sergei Golovan sgolo...@debian.org Description: ttt- Standalone program for local traffic-monitoring tttprobe - Probe to collect traffic-data and send it to a viewer tttview- Graphical viewer for remote captured traffic-data Closes: 724135 Changes: ttt (1.7-3.4) unstable; urgency=low . * Non-maintainer upload. * Build with Tcl/Tk 8.5 to fix FTBFS with newer BLT package. Closes: #724135. Checksums-Sha1: 090ee7952223f47d5bfebb51f19c25373ba2175e 1102 ttt_1.7-3.4.dsc c628b8587490403f23c9960ccf341cce3c715650 32925 ttt_1.7-3.4.diff.gz ec25ddf309a165aef534007afb56bdaf2f8157bf 375812 ttt_1.7-3.4_amd64.deb fbf6ab5b7c09f1249be65c53ceab6c4ae5db5589 373980 tttview_1.7-3.4_amd64.deb ed4cddb0328c8d2d278d24be20ef356c9c170b28 22348 tttprobe_1.7-3.4_amd64.deb Checksums-Sha256: 7bfb0274a7d890bb90f64b24172c12244b4adc845a975dae3471efda9202b850 1102 ttt_1.7-3.4.dsc 3bbcbabfc0b25690ab8548f0f0cd5dfcec6bbc64d625108e3a8f50f875f3c683 32925 ttt_1.7-3.4.diff.gz 7eb2cc483fa3298eea1aff7087d33d2ffdc06e1e2537178d1b860062ae8bf263 375812 ttt_1.7-3.4_amd64.deb eb9b0374dc367b7c62b87511ad4c8163c5c1435602769825b2d836b22664cfe8 373980 tttview_1.7-3.4_amd64.deb 994721abf9b19de5f2a02067c1a4b801d71da4efc79f1c1a394ace2be649c0ce 22348 tttprobe_1.7-3.4_amd64.deb Files: a65002ee6ecd586fb001f84094113938 1102 net optional ttt_1.7-3.4.dsc 08acb6d7bddbba258601d13b5b49a449 32925 net optional ttt_1.7-3.4.diff.gz f1adca2a70e83814eed7385bf57d66e0 375812 net optional ttt_1.7-3.4_amd64.deb c84784b797a9860cdcc3e9f1493dbc3b 373980 net optional tttview_1.7-3.4_amd64.deb 40aa043d55d799d85c232703351b505a 22348 net optional tttprobe_1.7-3.4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFSa325IcdH02pGEFIRAoRJAKCEpINf8aT8tcmgC2Rmcd8WFwnfmACgla1j u3FwAZYVBgSFeRgRAo3mMR0= =NrKN -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/e1vzzn5-0007gz...@franck.debian.org
Accepted ergo 3.3.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 11:05:49 +0200 Source: ergo Binary: ergo Architecture: source amd64 Version: 3.3.1-2 Distribution: unstable Urgency: low Maintainer: Michael Banck mba...@debian.org Changed-By: Michael Banck mba...@debian.org Description: ergo - Quantum chemistry program for large-scale calculations Changes: ergo (3.3.1-2) unstable; urgency=low . * debian/patches/integrals_hermite_mips.patch: New patch, fixes a FTBFS error on mips/mipsel by undefining the R3000 identifier which is already defined on those architectures, by Jurica Stanojkovic. Checksums-Sha1: 544a91b4b6f0b29dafedad35a6ea8e72ee70c4d5 1302 ergo_3.3.1-2.dsc 4b56598d5f773f9a6b83a3de9d0c7e01826a9496 3446 ergo_3.3.1-2.debian.tar.gz 4d31e62c70fa8e5cc9506e726bec2f43acc15d46 1246872 ergo_3.3.1-2_amd64.deb Checksums-Sha256: 3d5a22873a8961528c5ee20a74eb517d2c2bcc9dfdbac0afd921e2c74d524b59 1302 ergo_3.3.1-2.dsc 54bb1279525bb316490457c8543eede5e92f3e04f106e0a272a778530b94027d 3446 ergo_3.3.1-2.debian.tar.gz 903db39228bfff6e9fccf87a3fffa2a93fe7f2020adfc3c103f7cd50329adf1e 1246872 ergo_3.3.1-2_amd64.deb Files: dcbf1a556557f8d3690d1557cc9aedf7 1302 science optional ergo_3.3.1-2.dsc 4fb851ab6372c724975dbc58072bc6be 3446 science optional ergo_3.3.1-2.debian.tar.gz 3c733bb9a0c1c9aea3f6834e7d6955e3 1246872 science optional ergo_3.3.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJrk8QACgkQmHaJYZ7RAb+gcgCfegTqjlhA7UcoDS9IJcg9bIUL jIAAnA3XJpd0c4BAmq9Kei3nD1z83QQm =Azl3 -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/e1va0x5-0006bt...@franck.debian.org
Accepted fonts-smc 5.0.1-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 15:43:45 +0530 Source: fonts-smc Binary: fonts-smc fonts-mlym-udeb Architecture: source all Version: 5.0.1-5 Distribution: unstable Urgency: low Maintainer: Debian-IN Team debian-in-work...@lists.alioth.debian.org Changed-By: Vasudev Kamath kamathvasu...@gmail.com Description: fonts-mlym-udeb - Free fonts for Malayalam language (udeb) (udeb) fonts-smc - Various TrueType fonts for Malayalam Language Closes: 726081 Changes: fonts-smc (5.0.1-5) unstable; urgency=low . * Remove the obsolete conffiles using dpkg-maintscript-helpers. Closes: bug#726081, Thanks to Paul Wise. Checksums-Sha1: 1b6e4cc09c51dd9db126e490815f053dada0f150 2004 fonts-smc_5.0.1-5.dsc 37520241cb5ff3e542b053042cb127c97f2c035a 3370 fonts-smc_5.0.1-5.debian.tar.gz 9746bf879af9ec60d5f72b41f5609382931d41f0 800772 fonts-smc_5.0.1-5_all.deb 707eeea05929e5ccb13371ca81f8fd4d9839e787 259444 fonts-mlym-udeb_5.0.1-5_all.udeb Checksums-Sha256: 7b4e36678bf8a61adb57e55ac395ec77019e3bef4cde322d2f833fb19652ab1b 2004 fonts-smc_5.0.1-5.dsc 1af377e05bc042b1100eca596855b0603e8d8c97081097c83768ae279587ab52 3370 fonts-smc_5.0.1-5.debian.tar.gz 27ec8fcf583490c65314fe39c4e13a9daac5bc644b968462b25ab13aca79bc77 800772 fonts-smc_5.0.1-5_all.deb fff72edef16015cd9bdc6106fd9c3ed2d935446d14d9909d9852cf8e2ba86db3 259444 fonts-mlym-udeb_5.0.1-5_all.udeb Files: fc66f5d5b77798d6b1ae753b0e4605a8 2004 fonts optional fonts-smc_5.0.1-5.dsc 5cdfd8085e7f2a561aa67cbbaa6d8a17 3370 fonts optional fonts-smc_5.0.1-5.debian.tar.gz 40491e6d7e0462de176329c7fd61d0b5 800772 fonts optional fonts-smc_5.0.1-5_all.deb 4c47de2591d4d319554756be7f6daf8e 259444 debian-installer optional fonts-mlym-udeb_5.0.1-5_all.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSa5ZYAAoJEGyPdK6HcAt+S5AP/j1/qgjHzoFDxF/26k9mV2Wc mZvsAd3I+PxmXLpo8m0JZPQjk3hPdR08e32mi0lvXhEF4ep95LtMomY77ZuA0X1D AZVO9xvyP6a4LzFbOqdt9Vk4lOmzKo1rnO+2Zdwu95nu0YoQrGa5em/RMX10cD5Z A7Dv7wXLQafq4wVQtnI2d5A2f8rXJ/FnqGOxkVvlti0pVTn/3QVHvOP5pfGfD7CI Z43uuwEHjbi+Y9COTW4Gz1c7a326XC86KOqjK3WjUBZ3gtv1A+kTdew27+biiBCo J95bvQpMsaV9U+jmUbRd0sK/64OCAXtethEM92h7W6+8LinQ1MZHutJs9YJZS5hk YBP+/A9PhuSdwfkRFWNp7TMSlejbsiq7kj2kfHgq1tPNEwSMaKTssh2G+PWQ9TB2 9eDaQKZ6Ova+CWM03JLlTMux6sZg+VpSeKSPY+MhNo8p6bUw/+5Y2VvS3FgZdCwf m/SFMWEuWLIzcSNJEJH2bqYRfUOISoge9zdHTJb6d/3ebEySDAJ42hpzX3nkwv5Z u/CdCxUYw7XyKbfwMM4qQ4S4RyvUyPr5i2p1RsU0L9F++RH/y8guSm/0KGKMO5To wXUginJCkttk0ffdx/nvbqDQfrAi+k81jKyWniGPBjcmvyD2kcJzyCtDnvtzhed2 vQEGURk5CCQZtY0M0UlZ =+rLo -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/e1va1bm-0004kg...@franck.debian.org
Accepted sombok 2.3.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 26 Oct 2013 11:07:22 + Source: sombok Binary: libsombok-dev libsombok3 Architecture: source amd64 Version: 2.3.1-2 Distribution: unstable Urgency: low Maintainer: Emmanuel Bouthenot kol...@debian.org Changed-By: Emmanuel Bouthenot kol...@debian.org Description: libsombok-dev - Unicode Text Segmentation library (development files) libsombok3 - Unicode Text Segmentation library Closes: 727246 Changes: sombok (2.3.1-2) unstable; urgency=low . * Add a symbols file. Thanks to Matthias Klose for the patch (Closes: #727246) Checksums-Sha1: 66860b03f2688dbc6fa114008af73bfb82714c2d 1975 sombok_2.3.1-2.dsc d6af6398d92ec12e706e97274a7737c5cf901c4f 4400 sombok_2.3.1-2.debian.tar.gz 2b542fa3e1f3c02a3c0bb9116dbe276ed18e9094 78378 libsombok-dev_2.3.1-2_amd64.deb e9a16bd713f43e2def82d5308cee3a30c4d891ae 30282 libsombok3_2.3.1-2_amd64.deb Checksums-Sha256: 8301d88adf60429975169d7856436b1b842683f77a6d1d76bbae02e97315e988 1975 sombok_2.3.1-2.dsc 733f9edd2da2cd5f17aa3f57c91ce8d868967e792d343d7c913f237713664e68 4400 sombok_2.3.1-2.debian.tar.gz 129a96ec8a8343c425ef1735346916d290becdc7b15e2089b42551233c6828f8 78378 libsombok-dev_2.3.1-2_amd64.deb 1bcc1ea993decb82123a3d41edafe29d5ee5b9f272bd9c090c63cb1736169635 30282 libsombok3_2.3.1-2_amd64.deb Files: 33327037c9034ce1cc20b0164e3f2d2d 1975 libs optional sombok_2.3.1-2.dsc 4dd59111372f218e4019b91729d5d7c8 4400 libs optional sombok_2.3.1-2.debian.tar.gz 9fbbfa8a15939a9e48aa5fdabfd562df 78378 libdevel optional libsombok-dev_2.3.1-2_amd64.deb 5488d8e4ab252dd6f015b02fbef20b4a 30282 libs optional libsombok3_2.3.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCgAGBQJSa6fjAAoJEEsHdyOSnULDIq0P/0RJZITBYkMSgedOc3iE9VyG mASfVHqbciC4/kJ5oHPCa0FWC4byBNYMaCHwuNhoSesmwVCw4Khmc+w8s01d2wuv muZNWMTYh6gdm5TtWVnmJakwy0QbVEzrc+beLaqZEZvkn9dgV5mX+c/zzX18bvBP DhTw1ob0mdH4w3tsuEMro54Jx1eGqAML8ZNrQxF+jljPvLgTrn80ogZ9fbSzXdIh zPoOL13GU0z/8p4nHuo2EOVWTAD/rZah/e6NCk5Rn+6GvzT+VbX+D2yxVkUp11rW wWO7Kkf30sR/pIAHpnJtPzO0f/YZZpLB1Ki7+xGHqpayZRfN8cmU9plTsDNUUhno TbHK5J5k4dIq+yGpj1o5mz12/bTd7KHzL8v1XAfTjuma7GyeqIq2I6uNslxyeFb2 jA79lwVHtm/lFhvHYOGyI2h0KSj6tBNDxC2cFBxQYUczIjI4Jn3bzdar+awOQPAS QFj7AECl1iv1qR7Bq4D8vw9+BEOa5jMHTTriEO1Ntnz/102Z5xSpx500+oiK41gZ iCBc6eNx/ZMhRblLKG+5W727HoXUFmb6eJt6hXqwETWNzN/j1+32SLt3zCYKppsX oWAAy/zfk6iovQYhY6DgguT56ushfBhPJz3TmZSN/PrlW1a2G0Al2d8FPxs24lE3 F+beN4BS8LvG5lfNo3Op =xmoX -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/e1va2mm-0007sm...@franck.debian.org
Accepted folks 0.9.5-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 14:02:09 +0200 Source: folks Binary: libfolks25 libfolks-dev libfolks-dbg folks-common gir1.2-folks-0.6 libfolks-telepathy25 libfolks-telepathy-dev libfolks-eds25 libfolks-eds-dev libfolks-eds-dbg libfolks-telepathy-dbg folks-tools Architecture: source amd64 all Version: 0.9.5-1 Distribution: experimental Urgency: low Maintainer: Debian Telepathy maintainers pkg-telepathy-maintain...@lists.alioth.debian.org Changed-By: Sjoerd Simons sjo...@debian.org Description: folks-common - library to aggregates people into metacontacts (common files) folks-tools - Telepathy backend for libfolks - database and import tools gir1.2-folks-0.6 - library to aggregates people into metacontacts - GObject-Introspe libfolks-dbg - library to aggregates people into metacontact - debugging symbols libfolks-dev - library to aggregates people into metacontact - development files libfolks-eds-dbg - Evolution-data-server backend for libfolks - debugging symbols libfolks-eds-dev - Evolution-data-server backend for libfolks - development files libfolks-eds25 - Evolution-data-server backend for libfolks libfolks-telepathy-dbg - Telepathy backend for libfolks - debugging symbols libfolks-telepathy-dev - Telepathy backend for libfolks - development files libfolks-telepathy25 - Telepathy backend for libfolks libfolks25 - library to aggregates people into metacontacts Changes: folks (0.9.5-1) experimental; urgency=low . * New upstream release * Update build-depends * d/p/Generate-backends-GIR-files-using-valac-rather.patch + Added. Fix build (From upstream git) * Install all introspection files * debian/libfolks25.symbols: Updated Checksums-Sha1: 3d201fca0c84e54940f076813b56df2af7419cfa 2433 folks_0.9.5-1.dsc 040f00ec411df8865db9be2a09310dcf87cfd968 1685956 folks_0.9.5.orig.tar.xz 8f70bf91cdb18328c6b585a4491ba995e5824f2f 11926 folks_0.9.5-1.debian.tar.gz 02e0ef11eb4472a374e4510b7a9ae037d4a455b6 411496 libfolks25_0.9.5-1_amd64.deb c35eef21da71a9d61b01dd2a7bd3196962962ab4 296248 libfolks-dev_0.9.5-1_amd64.deb e823545e2ba15e918ae1229a7df541bf9cd883be 866824 libfolks-dbg_0.9.5-1_amd64.deb 9eef7fc18906a7ade03119441c2c8ac60644b0ce 379178 folks-common_0.9.5-1_all.deb 7ad7b8b636532c401e87676b8bc9e8ca494025d6 282968 gir1.2-folks-0.6_0.9.5-1_amd64.deb f9c02421b07efb51b9362600a746d006eb802613 332730 libfolks-telepathy25_0.9.5-1_amd64.deb 60207f6ba5d116f909f05d493d865e56c8cb7761 271892 libfolks-telepathy-dev_0.9.5-1_amd64.deb cd3fe1c77611ce460134e25e1105979d92ada3dc 334300 libfolks-eds25_0.9.5-1_amd64.deb 95cd4464a369d95bc4fa487b2e1e8b7164e9252c 272336 libfolks-eds-dev_0.9.5-1_amd64.deb 17271cb85937dd9610114c61c3e5a6e4ee5e93cc 520338 libfolks-eds-dbg_0.9.5-1_amd64.deb 1f1ec82f3b36661d0fca62851bd996dee14daf03 505156 libfolks-telepathy-dbg_0.9.5-1_amd64.deb 3a8b9352b5662e9522e0f1e71c3d180f65b912b7 311876 folks-tools_0.9.5-1_amd64.deb Checksums-Sha256: 526304e1f7179f380be2f764a12fb14b9cbb1cb46d3d48756aa4ba7e9c9ae68c 2433 folks_0.9.5-1.dsc 924c440f16a8c9b0d0d832588fa77a1553fa2a5d2659c4c7d3178a7ef4af 1685956 folks_0.9.5.orig.tar.xz a2567f4b830aa6ed7734ebe06951685f8fa1b88ca85e082af737effac24be9d6 11926 folks_0.9.5-1.debian.tar.gz bd78610cdba56eac3b5643473d93569acfee3ba1546a25a293ca5ce87eb02459 411496 libfolks25_0.9.5-1_amd64.deb 7057abacee75d47eed06a5b3f0bd814235ab548a3780fe845dbb077e093143ee 296248 libfolks-dev_0.9.5-1_amd64.deb 8d0ff5efce1af93e696b2e0b60fe38c5cf66d319605be2a7ff14f03c42face7d 866824 libfolks-dbg_0.9.5-1_amd64.deb dafe999188bc3d257bd025afcb8295ed11a464abc2d0bd334fd4c903db10a001 379178 folks-common_0.9.5-1_all.deb b5392d7ccfb57ff76ad3ef85e8887e7a7e6b2afef9d6256c9505aec69fe8caf0 282968 gir1.2-folks-0.6_0.9.5-1_amd64.deb 4a0a2b6b4b0261a848e81653ba2a49f0a91dc4f3c62ace9a2d8c1cff0d23485b 332730 libfolks-telepathy25_0.9.5-1_amd64.deb 39b584f85df4aed7f650161d773395c2e7e3bee32e874396824eb95dc93224b8 271892 libfolks-telepathy-dev_0.9.5-1_amd64.deb e34a1de5d3b9f1008255ba8e51199f999184878fc43fcef775f4e63532a6cf88 334300 libfolks-eds25_0.9.5-1_amd64.deb 72aed6056e185600fa0a2c680fe9a59917b85d6af5d8ff4cb25fb66f5805fbf4 272336 libfolks-eds-dev_0.9.5-1_amd64.deb ae8f9b22e9fcf2e53b3fa898b1578b9ba48ec11fe70aee349d1f60c4c09b1fee 520338 libfolks-eds-dbg_0.9.5-1_amd64.deb c6f8a19240ddd8c3caccec31c10abb7c98b8d18f4f69af1d7997eac7e3f29559 505156 libfolks-telepathy-dbg_0.9.5-1_amd64.deb 0859386d456d0c6f745bfbf30d5d732115f1a9e1eb2ccb7c2c48878f25bcdb3d 311876 folks-tools_0.9.5-1_amd64.deb Files: 8ab386a786b3ac97a099d32d75802d04 2433 libs optional folks_0.9.5-1.dsc 6faaf2c4de0e0863a5272f19837c693e 1685956 libs optional folks_0.9.5.orig.tar.xz 6ee6b610110f850e47be1853900f5700 11926 libs optional folks_0.9.5-1.debian.tar.gz 39135e091e8b154727c8eb867c76eaf9 411496 libs optional libfolks25_0.9.5-1_amd64.deb 943b319cde119f2987c51f0202db8af8 296248 libdevel optional
Accepted bitstormlite 0.2q-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 14:13:48 +0200 Source: bitstormlite Binary: bitstormlite Architecture: source amd64 Version: 0.2q-4 Distribution: unstable Urgency: low Maintainer: Andrea Veri a...@debian.org Changed-By: Andrea Veri a...@debian.org Description: bitstormlite - BitTorrent Client based on C++/Gtk+2.0 Closes: 727332 Changes: bitstormlite (0.2q-4) unstable; urgency=low . * debian/control: - Add a B-D on autotools-dev. * debian/rules: - Add '--with autotools_dev' call to prevent a FTBFS on arm64 (Closes: #727332) Checksums-Sha1: afc2f7a62025dda6527fc27513fc46a139a9699a 1797 bitstormlite_0.2q-4.dsc 7f3e714aa5eff25235805b53be2c55c701e072c0 4102 bitstormlite_0.2q-4.debian.tar.gz ec8fae6081c9f18648e77658486cdebc6d32caf8 81888 bitstormlite_0.2q-4_amd64.deb Checksums-Sha256: 65d10f97999b31ae407c50ccfc7bf6a6e0df2a8e4324b8ad52a48c7eedca455d 1797 bitstormlite_0.2q-4.dsc 5c1bdef5bf78d5a020e4d97fbf7de36884a7a563e4286e7080f0ca810b32d980 4102 bitstormlite_0.2q-4.debian.tar.gz a977919c4b90bf43ba105a4cb8697a0e7ee31b2e82cf9268de51cedd0d6d2e61 81888 bitstormlite_0.2q-4_amd64.deb Files: 9685752b820f2861c339fad9413ff851 1797 net optional bitstormlite_0.2q-4.dsc 50cb8267b64d4ac37bfea7690cceb548 4102 net optional bitstormlite_0.2q-4.debian.tar.gz 2581330eb3b57f7ccf1ceac46fdd33ea 81888 net optional bitstormlite_0.2q-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSa7cpAAoJELCi8amz5hIsW20QAKOtwVYddadqewkGh/8OIJ9m Nkpq/wPrN3E3v60UpdjVYvQQ6rtA4cyR/Y0hJtWt7eO+Esl/LRt0M3MEaHAxjWjO vmOR7J0fub5GLjc/4SNcP/Ql20CmpTU9UopHT4Pls50eMLHIyhhp7BB1b4CQmWpc jRMtRnWX5L3DPbYfBWWFMKS0tSDWzYv2VjZl0/IuN33iWqJ4EPvK+3k0fUb6mKOk Db9shQvRNLAKw4ktvWrY2N0xvt/bdOlXxKUTfIKOiGQTLuBiPVkkTIpnwaG5ptid nP46dFgh3zuXBkWrn/7N/NV8WRGcnn/mgizY8AzsQN8jTNVLHAdgt9xDj3bOHCWD a3LHF0GS20MGPwTpAa6UoT0ptgJAgGjqrK2n7Ux0J+FwyIcZqJvBssQR5zwamVOq njGpevMUwi3bOzqzBZ5meO76+eIgmn/E2unfOp1oeBToIORSIgg2sY4EvU99LlvV 21PFXi6TSgoIh70VfTl2XJcfEwwCjwsEVulXYM8UZBFpUlYlvOm59C+fFadJkb0Z fUN3f5FrM/xhEGKKq1vI3MWKtV+/z/LdpNGiFHssVIkriBM4+lyZ/C+ZIeZnx6KQ W9RrVigt9UH/FLcCULBBAnygIP2nkDkUjWa/mk0fQMKK8OCQKK0jOlceYyT0L5M3 wjGFgwVYRHaCh1WMtNHc =nijn -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/e1va3i1-0001cs...@franck.debian.org
Accepted agg 2.5+dfsg1-9 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 14:18:09 +0200 Source: agg Binary: libagg-dev Architecture: source amd64 Version: 2.5+dfsg1-9 Distribution: unstable Urgency: low Maintainer: Andrea Veri a...@debian.org Changed-By: Andrea Veri a...@debian.org Description: libagg-dev - AntiGrain Geometry graphical toolkit (development files) Closes: 724347 Changes: agg (2.5+dfsg1-9) unstable; urgency=low . * Build-Depend on automake1.11, seems agg is still building fine with this automake release. (Closes: #724347) Checksums-Sha1: a21a867d4d43c91b48fec78f3d87e50578663266 1780 agg_2.5+dfsg1-9.dsc 37b5f2e25d79e332438a23e20313c6b90142db01 6669 agg_2.5+dfsg1-9.debian.tar.gz b51cddc02fffcde9e7093d534ce0272ee3048d69 282470 libagg-dev_2.5+dfsg1-9_amd64.deb Checksums-Sha256: 9dc690fffecf0f26c13a4867e70df83b9a204ca1e0151b12b083ca4304f8111d 1780 agg_2.5+dfsg1-9.dsc 6c33cfedf75a83559a538c6c5cfea98bf4ae12e24462ed242256cff33a07da63 6669 agg_2.5+dfsg1-9.debian.tar.gz ae5b5d225957e0c149b97789f3c02cfc72cf6861a6caed64c478b39abf62b8b3 282470 libagg-dev_2.5+dfsg1-9_amd64.deb Files: f4004c48aa4eb9e5d311de7c13459da8 1780 libs optional agg_2.5+dfsg1-9.dsc cbfa51abd76de39393cef124a3dd2671 6669 libs optional agg_2.5+dfsg1-9.debian.tar.gz 712895fb2e97fa698da7dcb93140f995 282470 libdevel optional libagg-dev_2.5+dfsg1-9_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSa7cAAAoJELCi8amz5hIsa8wP/3wK6Wh5I5MS3kzJPbsNj6dh pLbMtwKSaBLa3NRONXJ5JxnOZxrWLr+nq7M7aIuIBLGh7DLEaUXYyuQ2Z/5HQT5I aqAqKcKvIKjyDO8ni57smnA+TlatZFnxuCcDF/NOTXRQeHiwPoMK07mqKBkeNKtv +vO5kxlp3SYJ246e5ehHAuwpav3wFjHQskvu9GuZ4XgakrADAW+rIph2WhUqhLwi 6uqO9IMt4mHWfTDu7G5kq4KtBKSpfvPdNWuSZ7z/7QmkBlD2xs06IWqsT2TcCxeC D0CQaX5PNE1X4XpMHnktqq//erm5OdNxvy/LZI55FJoJfd9vIbkfUYVTLh92hdZB gr7mc7ZR2kPBezNo0NMHURLuVjnT741vXS9O81qTCkrKEpu+6UBBKs/htJmtLlj1 ti9+DKPuZsluRsB7RcjSzwWlgC95Uc9YFkKawDtw4XPT1qS58lMyL73Jie4keR6w XlcAp21tG/iYT6Y0UTl0GwSS7cMBuQOlwsY/REEV4E0n/mZxPUFSVQEgoznCINwc xAPWWMBa26ihYC4w+H2Soi/ebTe9NI6H5VXi1GsDrZJJ6fs4anVNW49a8iPGp1dY R27949teEhSdsrfPLcst7x3VGrQE9HFKF62wnM0WLvN9zOZoJvPMR7JkPsnxt3Mr xTkbA/u8pKpWhhkBRDTS =XQV+ -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/e1va3hv-0001a4...@franck.debian.org
Accepted gnutls28 3.2.5-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 26 Oct 2013 14:40:05 +0200 Source: gnutls28 Binary: libgnutls28-dev libgnutls28 libgnutls28-dbg gnutls-bin gnutls-doc guile-gnutls libgnutlsxx28 libgnutls-xssl0 libgnutls-openssl27 Architecture: source i386 all Version: 3.2.5-1 Distribution: experimental Urgency: low Maintainer: Debian GnuTLS Maintainers pkg-gnutls-ma...@lists.alioth.debian.org Changed-By: Andreas Metzler ametz...@debian.org Description: gnutls-bin - GNU TLS library - commandline utilities gnutls-doc - GNU TLS library - documentation and examples guile-gnutls - GNU TLS library - GNU Guile bindings libgnutls-openssl27 - GNU TLS library - OpenSSL wrapper libgnutls-xssl0 - GNU TLS library - XSSL API runtime library libgnutls28 - GNU TLS library - main runtime library libgnutls28-dbg - GNU TLS library - debugger symbols libgnutls28-dev - GNU TLS library - development files libgnutlsxx28 - GNU TLS library - C++ runtime library Closes: 726971 Changes: gnutls28 (3.2.5-1) experimental; urgency=low . * New upstream version. + Bump shlibs. * Ship examples/examples.h which is needed for building examples/*.c. Also add ex-cxx.cpp, while we are at it. (Thanks, Daniel Kahn Gillmor) Closes: #726971 Checksums-Sha1: 9c6f7c517da9da2fc12ec8ad682315761625afdb 2719 gnutls28_3.2.5-1.dsc 088eee3297d036754414f40ae49ef9ea9e83c679 4987156 gnutls28_3.2.5.orig.tar.xz bd20c9eb74d831e27883ca822ae2bcc712760781 31257 gnutls28_3.2.5-1.debian.tar.gz cd2bc0611418d402fdf5c9718cc67646b81e26a3 587842 libgnutls28-dev_3.2.5-1_i386.deb e8b72e6181591d237f719e0cc2e19ddbd2598024 610052 libgnutls28_3.2.5-1_i386.deb 8798391bedfbff0978af717656ed162646267dcf 2058396 libgnutls28-dbg_3.2.5-1_i386.deb bd78ab1031015f0cb170244671a560aba7549a51 266858 gnutls-bin_3.2.5-1_i386.deb 7b0cd14e86ae62c5110943112c37950e994b02a7 3372856 gnutls-doc_3.2.5-1_all.deb 8404f1933b5bdc7ee82528ae070c98001c96c94d 165418 guile-gnutls_3.2.5-1_i386.deb 021a3e2f02db6a8b1d6402abda5dd9c736541b38 15304 libgnutlsxx28_3.2.5-1_i386.deb ec00343a16157ab20f6147789d4ef68555bece8f 14028 libgnutls-xssl0_3.2.5-1_i386.deb 1e7507418616ad940878d6a6b9ebce113b3d4b86 134782 libgnutls-openssl27_3.2.5-1_i386.deb Checksums-Sha256: 5f22572faf2b5bbb17aaa23d5b03d1e57bb4626a6b4397cd903e98e2c90cf6a0 2719 gnutls28_3.2.5-1.dsc c6fbcdcd32b2f38cca3bbfa10759556d66f4795ac6e6e50503f2ee5c08c081b7 4987156 gnutls28_3.2.5.orig.tar.xz 292430f089da321f72c0d6abc22971b9ede7da03ce387fa575976ebf84931c83 31257 gnutls28_3.2.5-1.debian.tar.gz 40dca618f9a11be22d0cca91baad5131da0b377fd3196be9f81732d30168124e 587842 libgnutls28-dev_3.2.5-1_i386.deb acc6af3f309dd298d321a962c4272932d741f53dbe351178cdd8f3af7d8479e3 610052 libgnutls28_3.2.5-1_i386.deb 6c4cb774cc832f72043d261ab2dd5fcf35b8ff57d218972221897fcb6fb5ecbc 2058396 libgnutls28-dbg_3.2.5-1_i386.deb baa2aa511803d1a46d3da223d3f1ff4a1f6873c5a1d7fee5a35818cf5a2aec29 266858 gnutls-bin_3.2.5-1_i386.deb 214019b08909f0b0996fc4eea260b3a079694b69e539cbd8b361eb9ccf3bc676 3372856 gnutls-doc_3.2.5-1_all.deb 32a95684938187fc2fe677a7b94d6d4e2c5cae9e8f4f3ce1026fdce48626b4fa 165418 guile-gnutls_3.2.5-1_i386.deb 86786b1d61fdff33e9243b24f30e286efc7af4fd2379179c5806a16711f2e31e 15304 libgnutlsxx28_3.2.5-1_i386.deb 59593d5408f128898db3c753213e7383aaf8e7d0930a2f6c74f32f20854c37c9 14028 libgnutls-xssl0_3.2.5-1_i386.deb 495278301489e6f34f69e59a2ee66873e071b6b7dee627c8d8f8ddb3ddc31fb4 134782 libgnutls-openssl27_3.2.5-1_i386.deb Files: 20356a04408cd28cf3dbf7dcba5a8ce9 2719 libs optional gnutls28_3.2.5-1.dsc c7c367ee06f7f05ddb1e36a444a142ed 4987156 libs optional gnutls28_3.2.5.orig.tar.xz eaea50759871ca1deba8a6d90f9a6907 31257 libs optional gnutls28_3.2.5-1.debian.tar.gz 703fd3668a87a55e9dc198066b83c82f 587842 libdevel optional libgnutls28-dev_3.2.5-1_i386.deb 753fca8aa6131ee033e59fefcfccb766 610052 libs standard libgnutls28_3.2.5-1_i386.deb 4392a9dd0ef233b2bb892af40302704e 2058396 debug extra libgnutls28-dbg_3.2.5-1_i386.deb 55b7825783165f89121c44a3c1fcfb73 266858 net optional gnutls-bin_3.2.5-1_i386.deb d60346d13f2d3fae543fd75c7834945c 3372856 doc optional gnutls-doc_3.2.5-1_all.deb 363a02729d39ffe69a2139f6fb044980 165418 lisp optional guile-gnutls_3.2.5-1_i386.deb 430e233740abd0769bf146e1845e916e 15304 libs extra libgnutlsxx28_3.2.5-1_i386.deb c4224226f2d9d2883647a0c16579bafa 14028 libs extra libgnutls-xssl0_3.2.5-1_i386.deb 8830a775f0638a6ddf5093c159f8b2a4 134782 libs standard libgnutls-openssl27_3.2.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJSa7ndAAoJEKVPAYVDghSEu2gP/2Bf/Kc6M1uLU0EQUNrHeUTm IjPR2OK5vDbTodpEVq6gz6pqb9yxSyWZaLnCZfKGtCz7CB6fO256ON3ypRD5XqSJ Z4k+DWsXz/2dXKeQItZ1N685Gl50LDpvEecIqN7IuQ7E9J2tFh1DsIrwzK9m68be 6+PZfahMd1rxofy+89Ih6Mvoujn+uccO+fGQCOH6PHi4W3vu35eBY1mABduqbMkk sag/M5OJWZOjSP0xaJwdxq4DHbILx+H8y5U6NzhrfbD/tMHl5bfqrH3GH4J6z7iz ZCmtdZwJphT4WXPODdUT2ifO+fDhW+7Gq7iCEbTwqf8pPj+PsS0iPjNmCz9wddKl
Accepted rsync 3.1.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 30 Sep 2013 17:19:55 +0200 Source: rsync Binary: rsync Architecture: source amd64 Version: 3.1.0-1 Distribution: unstable Urgency: low Maintainer: Paul Slootman p...@debian.org Changed-By: Paul Slootman p...@debian.org Description: rsync - fast, versatile, remote (and local) file-copying tool Changes: rsync (3.1.0-1) unstable; urgency=low . * new upstream release. * Bumped Standards-Version to 3.9.4.0 (no change necessary). * Patches cast--1-size_t.diff, delete-delay.diff, manpages.GPL.diff, partial-timestamp.diff, progress-cursor-pos.diff, rsyncd.conf.5.comment.diff no longer needed (integrated into upstream source). Checksums-Sha1: 774598634b491ee6763a5734c77acdfa8bdc666d 1014 rsync_3.1.0-1.dsc eb58ab04bcb6293da76b83f58327c038b23fcba3 883901 rsync_3.1.0.orig.tar.gz f5ee6145e7643c9bf55111aa3a4957455b93f170 17946 rsync_3.1.0-1.diff.gz 90c062db281677a1c6e2a67d8f7982bc2024e165 374082 rsync_3.1.0-1_amd64.deb Checksums-Sha256: 063a6ecf5241b8413c124db23440e13e19aad5fb93c6ad52778f92979efd05b6 1014 rsync_3.1.0-1.dsc 81ca23f77fc9b957eb9845a6024f41af0ff0c619b7f38576887c63fa38e2394e 883901 rsync_3.1.0.orig.tar.gz 271248d5876803f884ce6ca29d8ae4993028edd68c8da6d373325af924a46efc 17946 rsync_3.1.0-1.diff.gz 80d455827da87d1b0a2168562555807b400b3552f38c3711e83095d3e7771e22 374082 rsync_3.1.0-1_amd64.deb Files: 62fad0b47b7cda74eafdd625bd54bb18 1014 net optional rsync_3.1.0-1.dsc 3be148772a33224771a8d4d2a028b132 883901 net optional rsync_3.1.0.orig.tar.gz c2051d0959df2e7bf20119b19ca176d7 17946 net optional rsync_3.1.0-1.diff.gz 4f4deaa4b9734a70e0c03d15937b7eb9 374082 net optional rsync_3.1.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFSSZgvutvvqbTW3hMRAg1iAJ9gtJaQ+5j3i/d6qGPvLwbz3phEpgCfSu9e kz7UK5OUknCEQ00fDEmN/yw= =Nj9f -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/e1va3lp-0008ue...@franck.debian.org
Accepted python-cups 1.9.63-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 04 Sep 2013 08:17:55 +1000 Source: python-cups Binary: python-cups Architecture: source amd64 Version: 1.9.63-1 Distribution: unstable Urgency: low Maintainer: Otavio Salvador ota...@debian.org Changed-By: Jackson Doak nosk...@ubuntu.com Description: python-cups - Python bindings for CUPS Changes: python-cups (1.9.63-1) unstable; urgency=low . * Team Upload [ Jackson Doak ] * New upstream release * Make debian/copyright debian machine readable format Checksums-Sha1: d557dd58b24d284895879fec7cb0c18442514b97 1771 python-cups_1.9.63-1.dsc 9d00572c1b33d0a8cb3d3df5d2cca7c421267596 53004 python-cups_1.9.63.orig.tar.bz2 a38c2432b92c53dc54ca356c9bd73c9e0540a62a 3959 python-cups_1.9.63-1.debian.tar.gz 5808b32533a131805c536bc22d577e3d4de5db0f 61222 python-cups_1.9.63-1_amd64.deb Checksums-Sha256: d54e41a0b878804d9267ee57b75db0863a99521a0c9aca672cef0b7a582d7759 1771 python-cups_1.9.63-1.dsc 82fa731a34afe30206bd2a8f4b2ee6a317d8da62a73aa1a2e837b9a217acf797 53004 python-cups_1.9.63.orig.tar.bz2 818897ef7db853afa069d9d41272042f13ad8587030f1d576e451ca5b86d1d00 3959 python-cups_1.9.63-1.debian.tar.gz ff39537c2824621de824e1b2b9d35dc7fd0516a75f60688407968de9d6844d09 61222 python-cups_1.9.63-1_amd64.deb Files: cd74a16b2000900829b1619595952484 1771 python optional python-cups_1.9.63-1.dsc cdee3ef87ac68d435c8ea04384563d15 53004 python optional python-cups_1.9.63.orig.tar.bz2 d69f8983b16ff0a5eab68f7b419e1332 3959 python optional python-cups_1.9.63-1.debian.tar.gz 42715e467c2996c5571c2f0cf1b8c9e1 61222 python optional python-cups_1.9.63-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBCAAGBQJSa8BRAAoJEB/FiR66sEPV16QH/2nb5WJPw1xY4JjlXHKS+UWM uymQUHtFMKqFZcbN9OPyZmk+5s340HneTvcn++ufZtejrskshz4w8bmmUx4fW2E6 2Vk9JP1viw4/rqhS4B/3KTpFdDzZCI8KWUTF0r4DF3O+ry32kozYvKzqRoJNRfbZ yQslk+E05RZFHctE/MQ+FdfzhsrVLlcjK0kTa6o3PXXXDLiziUCyCfaFUheAKYZK Tr9kq8pYgsso01x9pgcwVwdpAZ/EJ4jD1exBMNMHoZ3s1iEcRUUhEUjXzaEnp/EZ Zzg4lVlk7O5W6/UuZ2dUpidkHyqaTc2CjY6XfozKRuy2JaywffCW1f/DzHhMCkg= =SS3w -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/e1va3zu-00038i...@franck.debian.org
Accepted node-topcube 0.2.0+ds1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 14:29:48 +0200 Source: node-topcube Binary: node-topcube Architecture: source amd64 Version: 0.2.0+ds1-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers pkg-javascript-de...@lists.alioth.debian.org Changed-By: Jérémy Lal kapo...@melix.org Description: node-topcube - spawn a child webkit window from Node.js Closes: 719406 Changes: node-topcube (0.2.0+ds1-1) unstable; urgency=low . * Upstream update * Build using node-gyp (Closes: #719406) * dh 9 for hardening * Standards-Version 3.9.4 * Canonicalize Vcs fields * Remove unneeded patch * Install topcube in /usr/bin and provide manpage Checksums-Sha1: e7c940fef36df721f399ca967f71acbe68ba592f 2073 node-topcube_0.2.0+ds1-1.dsc 911f8144b503e8cbbbe6329c2a35eccd1f06655c 5969 node-topcube_0.2.0+ds1.orig.tar.gz 44dcd4294986eeb1c61043c58de1d8b54a046d13 3306 node-topcube_0.2.0+ds1-1.debian.tar.gz 7f5c081a328179ec2a21213f0b5a06b460cf320c 9410 node-topcube_0.2.0+ds1-1_amd64.deb Checksums-Sha256: 6f637640065fc85ff37147b861787b8e06336efb01673f49d352dbc67dd7f084 2073 node-topcube_0.2.0+ds1-1.dsc 5a7097d534eaf0dab1a7325eef66085ac97ca6372cb53df2f411c4bbebf3e26b 5969 node-topcube_0.2.0+ds1.orig.tar.gz 78570ed1038756c352f4c9c3f5d74fc0ba8250247b66d1e4111bd9d7a1e6de94 3306 node-topcube_0.2.0+ds1-1.debian.tar.gz fb640eeb6f9a75711031c3fc9680e66034c9a3c76a839e05462b703fc41d2fab 9410 node-topcube_0.2.0+ds1-1_amd64.deb Files: f3d7529089914d5822b895b223e2450d 2073 web extra node-topcube_0.2.0+ds1-1.dsc e22f2eaaebe7f6f4877625bc65425472 5969 web extra node-topcube_0.2.0+ds1.orig.tar.gz f34a3799b33cd89bd3b794a27821163d 3306 web extra node-topcube_0.2.0+ds1-1.debian.tar.gz 174b63403a3da6468d532fa3a510fd23 9410 web extra node-topcube_0.2.0+ds1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSa7/jAAoJEGYRwF7dOfN07MwP/2zPFIV+C/clIskgUws0krtJ l98QofZQAk1HmaS+dVwxU2WSaB9JSv+RzyQQ72BfXOvi7Job19z/MnAOhtoRhP6X +sTsPXT6Sg+flpaW/mRcDxYJe9+6aCdvZR/ODUUdW7QBKuB7XaeBjR3adQO737Dt 8l6/wdtdIDNt1Wl7hN5EnVXl80ywd/5qY5uULnrCF+Dl+ZmFBs6SKaNJfT4f2+I2 AROIThoe/fFKfY39V0s7rPQjRfESGOvSNKMstpEH+zEsF1eu8EohZW12fp2vtVLy VtLkzdLRHnGsrWxn9gjaYjKDBW3OcUZKW5cY5x7rpbizeiC4tlAc3qPkZhG8vXSv VZRTs4MxHixQDIvpxCgopfa17mAQD/UcoHMEGDT13zoWycAlRnsLGo6W2QM0EgW0 LSgT4C7T9bfViEfGOJvlHcJwXUm2fboW0L/0r2ACiGufwGhdwsGTcfYNyZKpxws8 cOmxm6CxTzZZS/vO3tPtGGn4S9Vc3Hb6MuUL7Fiew7dojtJtMY2sl84KjZ3YY0fd NQLAbNabMTupVoY0Ebuuh+x5Zzu1uhzFNfWfgMOhcEOTJU51GOhJ/7mJFZVRp5Kq vH4J1ul6uqH52LGC1Z7NLCTwupiyHpKt3JJkNsENG5tEe+a4ZIziMdBBtah7E8+6 lgKj9vMCW0AJIwXrpI66 =m5gR -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/e1va3zn-00035j...@franck.debian.org
Accepted system-config-printer 1.4.3-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 14:58:35 +0200 Source: system-config-printer Binary: system-config-printer python-cupshelpers system-config-printer-udev Architecture: source all amd64 Version: 1.4.3-1 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Changed-By: Laurent Bigonville bi...@debian.org Description: python-cupshelpers - Python utility modules around the CUPS printing system system-config-printer - graphical interface to configure the printing system system-config-printer-udev - Utilities to detect and configure printers automatically Closes: 593219 718263 725882 727556 Changes: system-config-printer (1.4.3-1) unstable; urgency=low . * New upstream release (Closes: #727556) - Fix some Unicode-related issues (Closes: #718263, #725882) * d/p/0006-use-paper-size-default-in-etc-papersize.patch: Detect paper size using /etc/papersize if it's available, thanks to the Ubuntu guys (Closes: #593219) * d/p/0007-scp-dbus-service-fix-dbus-signature-typo.patch: Fix typo in a D-Bus method signature (Taken from Ubuntu, thanks) Checksums-Sha1: 0903976a80c84d30095346bc8900828b6c5e5f12 2191 system-config-printer_1.4.3-1.dsc 436866bf54e497436fb7ccc37ef7dcb3cecd1f8b 892132 system-config-printer_1.4.3.orig.tar.xz 79c0faa4b33c75fa057cb27be0064fa1192aa04a 12244 system-config-printer_1.4.3-1.debian.tar.gz e7139028d431f6390145d9c1fae575163fc25743 715866 system-config-printer_1.4.3-1_all.deb 8e131be966b5e3ffae83d5b5b1c05232f307fd99 104766 python-cupshelpers_1.4.3-1_all.deb c59a914f0b272f73b4a420704fab72836b4bbbf6 90372 system-config-printer-udev_1.4.3-1_amd64.deb Checksums-Sha256: a8ed850ba8976f6f45450c54f35333af994e9d32313bebd48522bbd8b67d4db0 2191 system-config-printer_1.4.3-1.dsc c14bb1b75929ccf31267da8cf774bed923c4ea3eb0deddcc255221c0b8844c0f 892132 system-config-printer_1.4.3.orig.tar.xz c3c6ef4ad07d0194dd53f0caaa6e242bdeb715afa7638b5ec11707c82070dff6 12244 system-config-printer_1.4.3-1.debian.tar.gz ea013f4dc98c1c78a4c060d30a91177031dabbc67067c6d5f33cecd7f68e7164 715866 system-config-printer_1.4.3-1_all.deb a1ff5c9b9c12ee2811cee9d8e0b12714f4a809de97078815172ca435d02e393d 104766 python-cupshelpers_1.4.3-1_all.deb beb34cdbbff2101fa1dc23114b28f12307f37016f41e22aa0ebb1926fc083621 90372 system-config-printer-udev_1.4.3-1_amd64.deb Files: 5700c417a459e5becd64e25d96c0b69e 2191 gnome optional system-config-printer_1.4.3-1.dsc 99e251bfd281526fb6ea109b3e2bace3 892132 gnome optional system-config-printer_1.4.3.orig.tar.xz da83d813e4c7c96adb28e03f68dded4d 12244 gnome optional system-config-printer_1.4.3-1.debian.tar.gz 6488d73c40424c2058f8b88de46df761 715866 gnome optional system-config-printer_1.4.3-1_all.deb bfea24c4576288f2d230b0b33d7556a8 104766 python optional python-cupshelpers_1.4.3-1_all.deb 633834273d21ce115e5176bdc125b468 90372 gnome optional system-config-printer-udev_1.4.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBCAAGBQJSa8KgAAoJEB/FiR66sEPVeGIIAKUEeyOjbAL9TtHS8hjkPHTt 70YptgpVxAmvnU9jQgQbVK+YQGNQaMKa0/+h0Ley5BEtS44AiZHP0N+NCPCN4jYX ve2vBnraia/NvMGOueVWZxk3P49a9YCgK6vhwYIUI7+tHRkDb5b3KWnIDBfoSi6O LV25uGOmFjS5wFFbxR4tjOLLa+WKNxuvv8K+VQYzhrc5A2HfmRRylsnn2UKxKcyr IXvi4mZeXhy0OEf1ta0HmudcDxwyasEHTzxAXKfqenlHV+ZHO9f/xCXNjZWuXiuA hAgk/XHiUPhlKLx4ciXg4qwsyL3P3mVElOzF2AyYDEH0Th9iGwFmKxZ5aqHwZeI= =+sKo -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/e1va406-0003dg...@franck.debian.org
Accepted mpi-defaults 1.0.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 13:35:29 + Source: mpi-defaults Binary: mpi-default-dev mpi-default-bin Architecture: source amd64 Version: 1.0.2 Distribution: unstable Urgency: low Maintainer: Debian Science Team debian-science-maintain...@lists.alioth.debian.org Changed-By: Sébastien Villemot sebast...@debian.org Description: mpi-default-bin - Standard MPI runtime programs (metapackage) mpi-default-dev - Standard MPI development files (metapackage) Changes: mpi-defaults (1.0.2) unstable; urgency=low . * Team upload * Fix the logic of debian/rules: it was broken by the renaming of mpich2 to mpich in the alternatives system * Update all dependencies to the new libmpich-dev and mpich packages (instead of the transitional packages libmpich2-dev and mpich2) * Replace MPICH2 by MPICH in package descriptions * Use canonical URLs in Vcs-* fields Checksums-Sha1: 9d5064ef7bec5e058f9547b29fe3d8511d7b64b0 2228 mpi-defaults_1.0.2.dsc 19c32a06feab8a08224abc3df45ea3732bee4ac9 3462 mpi-defaults_1.0.2.tar.gz 84a0bc90b3ab5c74ab8fc0351a3da10b0cb36546 3690 mpi-default-dev_1.0.2_amd64.deb 5226182f54cdd0a23a5a1852aee97d062321665c 3098 mpi-default-bin_1.0.2_amd64.deb Checksums-Sha256: d944280ba445a0bd022d0c3eecc9abae48f5de3c474e6091e6f35fcda46f99bc 2228 mpi-defaults_1.0.2.dsc ce13947b0d73fc0e74b31ecb37026955a21cafe7c09ec3dbe106b5ed901756c3 3462 mpi-defaults_1.0.2.tar.gz f4ed2b451ed4e33359afb762c6bdfba88056f609f7c85a85f92b15eba1e45348 3690 mpi-default-dev_1.0.2_amd64.deb 66005881534f9bc25f6462ef1507fffada760defe7718d0e61a3a1a6aec07852 3098 mpi-default-bin_1.0.2_amd64.deb Files: 2c69674e5b1e90e2a46eb4c798960dca 2228 devel extra mpi-defaults_1.0.2.dsc 67ba14be290c01d82104e4b417a9caea 3462 devel extra mpi-defaults_1.0.2.tar.gz 5a23ff8bed37fa1b7cca961704eb950a 3690 libdevel extra mpi-default-dev_1.0.2_amd64.deb 033b2eb20c3240591a2fe806c1ef3819 3098 net extra mpi-default-bin_1.0.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSa8ZbAAoJECzs6TUOzr5K8PkQAKjMH3W+bABmkl0gFxGzmO60 7SfY2Qfbtrv2PmAElPiST2vXQABj+e4/+T9qm9G5ZAo6ibcgTL3q0K8bzDZbUwrd 0u7C7Cs/08qEUc7Z27tZ265d1kpigKovic4PbyyRhe/spoRDIAmBfG89IdpZlNX4 Y7TZP4ZmHLXG1kORKQegdIlkA3WcBbkQaPw87f+QMF3MxjZwvvjNRz8G9bL4P4oN SgEqj61c1iyLnszZEV03C18gdS3LgkBqU5PDhmozJRxwA3OY4f6k9jEaPp6jX00J SnwfPu2bZNR0VkkUZ44WIGYSIMOxMEJ4FSRplVvHf8Wa+5r+2MQAD6M5+VgrHQFZ Es82VGRQx0vsyocM7nVRdOmatvoBNAA38k0WPMaEIksvvGfF7XQVJOz7RPW+CbJA DyyVZoAiTIhZ0T8OawmWgl/fPjacZmiO27hBqDXZgdbz7ku1tMh6OR8ZSYinHSw3 gSHzF44X6oH8SKp7ax09tCT36rj3Awk7n4gFl1HhNB3XRnAizPGrSy07DUCAkSzb UG1avEfIHZF05YcwxfhcOJ96ZY9Y1mwb5Csr8JmWnsUYGvrmw2ZAs6Ir4R1kdK7a 7l+4w9qJSnm468tXZsVGLUqEy1R2go11oDnkBz3Lz6e2MpAagpQeO5O1Hpg9ziC3 Y07Df05OeXRs4BRWryg5 =t5UJ -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/e1va4ek-0006cz...@franck.debian.org
Accepted ufsutils 8.2-4 (source kfreebsd-amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 14:43:08 +0200 Source: ufsutils Binary: ufsutils ufsutils-udeb Architecture: source kfreebsd-amd64 Version: 8.2-4 Distribution: unstable Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-...@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: ufsutils - UFS filesystems utilities ufsutils-udeb - stripped-down versions of ufsutils, for debian-installer (udeb) Changes: ufsutils (8.2-4) unstable; urgency=low . [ Robert Millan ] * Import 00_portable_berase.patch from upstream trunk. Refresh all patches. . [ Guillem Jover ] * Add build-indep and build-arch debian/rules targets: - Rename build to build-arch and install to install-arch. * Now using Standards-Version 3.9.4. * Switch to canonical Vcs URLs. * Remove packaging history from debian/copyright. * Switch to the libbsd-overlay. - Remove sys/endian.h local header now provided by libbsd. * Add install and install-indep targets for consistency. * Add -Werror=implicit-function-declaration to build flags. * Remove unneeded debian/ufsutils.dirs file. * Reword warning about not enabling _FILE_OFFSET_BITS=64 on GNU/kFreeBSD, fix typos, and remove repeated text. * Switch to use the upstream build system. Add a Build-Depends on freebsd-buildutils for pmake. * Do not require root on the clean target. * Use «dpkg-parsechangelog -S» instead of sed-filtering the output. * Only use the local sys partial headers hierarchy on non-kFreeBSD systems. * Remove myself from Uploaders. Checksums-Sha1: b60b06e75ebefb319bc8b51aa1c0538fab940c20 1435 ufsutils_8.2-4.dsc dc5ff38173da4d676ba9efcf5a420e9d25f1a870 20413 ufsutils_8.2-4.debian.tar.gz 209b721d1fadac0b6209640ad5a24011cf7f 128174 ufsutils_8.2-4_kfreebsd-amd64.deb 32ebf7ea23c32b2ad46256460d01b7c007045583 72040 ufsutils-udeb_8.2-4_kfreebsd-amd64.udeb Checksums-Sha256: 27ea7f1f5398e928f59f3b6ec5afecd51f7464b2e8ae529a2f2883cc8c050193 1435 ufsutils_8.2-4.dsc 79fe50284dfc454696a9b8e5f8666550c59c775a439ebe9c3bcb1971034bbd39 20413 ufsutils_8.2-4.debian.tar.gz 3d2aa96055bc3f687a112a614ad7da4a94c203da510270aaab327e86d34fa62d 128174 ufsutils_8.2-4_kfreebsd-amd64.deb b74914b55c64fcc75f517220451a346781e3eb6b687fd1c46de3632ddbadb4d9 72040 ufsutils-udeb_8.2-4_kfreebsd-amd64.udeb Files: ccf2cd4f76176321ad6871d6eb3232ae 1435 utils optional ufsutils_8.2-4.dsc 067eb2ffd85fdf4518ae3840ceb4 20413 utils optional ufsutils_8.2-4.debian.tar.gz ecf4b06816a748e3b99a7d9b3b4ac3ac 128174 utils optional ufsutils_8.2-4_kfreebsd-amd64.deb 72c5723d9e25d90ca08774a7567ebdab 72040 debian-installer optional ufsutils-udeb_8.2-4_kfreebsd-amd64.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/kFreeBSD) iEYEARECAAYFAlJruY4ACgkQC19io6rUCv/WNwCfWmV75pFKC1SpST2LCi9MXevq KtcAn2mM0NRIGfIIjY+XbqdhsaU2haYi =CPWu -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/e1va4ev-0006jz...@franck.debian.org
Accepted freebsd-glue 0.1.12 (source kfreebsd-amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 16:09:29 +0200 Source: freebsd-glue Binary: freebsd-glue Architecture: source kfreebsd-amd64 Version: 0.1.12 Distribution: unstable Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-...@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: freebsd-glue - Emulate a FreeBSD build environment Closes: 726970 Changes: freebsd-glue (0.1.12) unstable; urgency=low . * Fix improper allocation in funopen(). (Closes: #726970) * Add _PATH_UFSSUSPEND. * Add arc4random_stir() prototype (for libbsd). * Work around broken macro argument in TAILQ_FOREACH_REVERSE_SAFE Checksums-Sha1: 2b85c145e3c1ea835e3d3de85ded045e78c58060 1027 freebsd-glue_0.1.12.dsc e1605643fec48f5aa4ad70be3d61433b85967b74 37817 freebsd-glue_0.1.12.tar.gz a1ed55721dc2bd0f847b753846ca43464aa113c4 33364 freebsd-glue_0.1.12_kfreebsd-amd64.deb Checksums-Sha256: 4d7a82d32cecce2400c600b2c3ad715141f23e61145673c3a209444dc268e6ae 1027 freebsd-glue_0.1.12.dsc d21baac51f44e9d2d6aa6dea8b6208a7bf46ae199f9dcfd14019f1a8205ae3e4 37817 freebsd-glue_0.1.12.tar.gz 99f76861d036c313004917dcb826fd08e4503fdec53064011167bc92b674428b 33364 freebsd-glue_0.1.12_kfreebsd-amd64.deb Files: f9e465362b42a00c9f5707e1d9a3f85a 1027 devel extra freebsd-glue_0.1.12.dsc 5e07af44ff0d3899b8d4fabb55e2389f 37817 devel extra freebsd-glue_0.1.12.tar.gz 3771aa6361682d1cae64f13846df1781 33364 devel extra freebsd-glue_0.1.12_kfreebsd-amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/kFreeBSD) iEYEARECAAYFAlJrzTwACgkQC19io6rUCv/h1wCdE6VP95f52N2Cls9jAXGH/plA ey4AnjVTLOas0V9UUsFIYG+rHUAXDy3I =lGZd -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/e1va5dd-0008kf...@franck.debian.org
Accepted gcr 3.10.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 16:48:53 +0200 Source: gcr Binary: gcr libgck-1-dev libgck-1-doc libgck-1-0 gir1.2-gck-1 libgcr-3-dev libgcr-3-doc libgcr-3-1 libgcr-base-3-1 libgcr-ui-3-1 libgcr-3-common gir1.2-gcr-3 Architecture: source all amd64 Version: 3.10.1-1 Distribution: experimental Urgency: low Maintainer: Josselin Mouette j...@debian.org Changed-By: Sjoerd Simons sjo...@debian.org Description: gcr- GNOME crypto services (daemon and tools) gir1.2-gck-1 - GObject introspection data for the GCK library gir1.2-gcr-3 - GObject introspection data for the GCR library libgck-1-0 - Glib wrapper library for PKCS#11 - runtime libgck-1-dev - GLib wrapper library for PKCS#11 - development libgck-1-doc - GLib wrapper library for PKCS#11 - documentation libgcr-3-1 - Library for Crypto UI related task - transitional package libgcr-3-common - Library for Crypto UI related tasks - common files libgcr-3-dev - Library for Crypto UI related tasks - development libgcr-3-doc - Library for Crypto UI related tasks - documentation libgcr-base-3-1 - Library for Crypto related tasks libgcr-ui-3-1 - Library for Crypto UI related tasks Changes: gcr (3.10.1-1) experimental; urgency=low . * New upstream release * d/p/0001-fix-build-error-with-Werror-format-security.patch + Dropped, fixed upstream * Enable vala bindings Checksums-Sha1: d62c10a9ddb135cf6b0933187fd5a20b1adce4d2 2404 gcr_3.10.1-1.dsc ebd8a0f894aaa66e6f57c1e99e143bada007fe8a 1402524 gcr_3.10.1.orig.tar.xz fd49a398e91c2c3861e6d953c60acf6ef8fe3abd 21099 gcr_3.10.1-1.debian.tar.gz 59c6eca365b61e48032321e655cb53a58cb60bda 195456 libgck-1-doc_3.10.1-1_all.deb 1098e3eb936a916fdaa736f556d3e42e3d091590 273156 libgcr-3-doc_3.10.1-1_all.deb 2435322202756eb91344268716a23c3bbc5a4ea9 146286 libgcr-3-common_3.10.1-1_all.deb a5ffd3f5cc8e6deeae74f8e798df6cb154f7c31a 342136 gcr_3.10.1-1_amd64.deb c2427f2de5a63410303adbe7e71c42110f94ca6e 180030 libgck-1-dev_3.10.1-1_amd64.deb d84814501810bffb90862bb8d293653ce25c941c 215504 libgck-1-0_3.10.1-1_amd64.deb ebd2c6598dd22cb32c5144de1662a48f81297353 152076 gir1.2-gck-1_3.10.1-1_amd64.deb c3f26a0db9955feae0e09c066464bf40200345a8 193656 libgcr-3-dev_3.10.1-1_amd64.deb 573cd4d12be86525bd2690576df7572e6e137753 144754 libgcr-3-1_3.10.1-1_amd64.deb 844a3880d9e7350ddf7ed8aad106023f9cfaba0f 323860 libgcr-base-3-1_3.10.1-1_amd64.deb 92af3ac35ac7fcf2bad0bfb9b99b068dd40802dc 278660 libgcr-ui-3-1_3.10.1-1_amd64.deb 9b548611df88417a10c35d992a079f2d1c10a7da 156498 gir1.2-gcr-3_3.10.1-1_amd64.deb Checksums-Sha256: e3d5cdc896e1e26bc80d860d6f561d5e603455005345b82404c0f23af8faa838 2404 gcr_3.10.1-1.dsc 006f4f5a54be00418346f28eac2b53f3e640e9c6aa389808cf846f861438645b 1402524 gcr_3.10.1.orig.tar.xz 54cc34db92a6d2fc3cddce15e08fb21629ec81d1536d1581f98304cee1fca4a8 21099 gcr_3.10.1-1.debian.tar.gz 363190e0638f8833a2861612754dcad5a4cfd9041dc1f5f392d704b0acd7b238 195456 libgck-1-doc_3.10.1-1_all.deb b82ecd9c61dc10464ffb8a2a9ba8d4bdd66fb6d725f2519731503c55da6b33de 273156 libgcr-3-doc_3.10.1-1_all.deb 3a2b0f1e50701d9e3ebf2b96b370fed9ece068932466313b686d232fa849a2f7 146286 libgcr-3-common_3.10.1-1_all.deb 78e5cecd8275ef99c83f9e9ce019d561f6ce90275861d35ee3300b05938eb9a5 342136 gcr_3.10.1-1_amd64.deb 846baa33c49e54c68d91b29f6d30f355a7d000b06340335a338c2bd7622f6cd8 180030 libgck-1-dev_3.10.1-1_amd64.deb a07af980ae26be45d960fafbf2f9fc0a575ee81d927efe9957d39db1e7190f02 215504 libgck-1-0_3.10.1-1_amd64.deb b6d3674be099bebf5a02cd89a50d2e912837d3f5279a56759df52e2889b7e63a 152076 gir1.2-gck-1_3.10.1-1_amd64.deb 9e0f2bcf85c6804168720cb57e29a4c671c306c57096a98db10aef101d8291a9 193656 libgcr-3-dev_3.10.1-1_amd64.deb 7c55c54d1a38aec1ac370087a099b58df226db81eb082565e8e90963681b91e9 144754 libgcr-3-1_3.10.1-1_amd64.deb 2d76da84119dee5d39f3257c35c76d52a9c2b37d221d4057b70a5b5a87603cef 323860 libgcr-base-3-1_3.10.1-1_amd64.deb 305c34490d653144cb66f695463a5b3bf21b5cee86f6e7dd953ef6a50eacdb42 278660 libgcr-ui-3-1_3.10.1-1_amd64.deb 5b81ee0f823559c58769a2e2d37c850646100b8773f0d480f329aadf6580fbfc 156498 gir1.2-gcr-3_3.10.1-1_amd64.deb Files: bc81b793fcc667aeef26dee991655d59 2404 gnome optional gcr_3.10.1-1.dsc 68c0b5d7202ac598942616d2e3a1b089 1402524 gnome optional gcr_3.10.1.orig.tar.xz fb64513b8f7db72c39ac8b3fa95721ff 21099 gnome optional gcr_3.10.1-1.debian.tar.gz 6400f6b382acb3f41da344a629e8b2cb 195456 doc optional libgck-1-doc_3.10.1-1_all.deb bea49088b96992c4371cb40bd258906a 273156 doc optional libgcr-3-doc_3.10.1-1_all.deb 5bc165b362d0002831bf4b4dcf703af0 146286 libs optional libgcr-3-common_3.10.1-1_all.deb fd200c00acc07569299ad6bd2f35e820 342136 gnome optional gcr_3.10.1-1_amd64.deb 579359587f29176dd62ae1dc7c6e3da3 180030 libdevel optional libgck-1-dev_3.10.1-1_amd64.deb 42bca6a05d55fc2c637db3710fb144ec 215504 libs optional libgck-1-0_3.10.1-1_amd64.deb 974d2e719ab7b73b57d9538ca5958718 152076 introspection optional
Accepted gnome-session 3.8.4-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 16:12:19 +0200 Source: gnome-session Binary: gnome-session gnome-session-bin gnome-session-common Architecture: source all amd64 Version: 3.8.4-3 Distribution: unstable Urgency: medium Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Changed-By: Emilio Pozuelo Monfort po...@debian.org Description: gnome-session - GNOME Session Manager - GNOME 3 session gnome-session-bin - GNOME Session Manager - Minimal runtime gnome-session-common - GNOME Session Manager - common files Closes: 726498 Changes: gnome-session (3.8.4-3) unstable; urgency=medium . * debian/control.in: +Break gdm3 3.8. Closes: #726498. Checksums-Sha1: f8d2d6c1fd4827ae9cffc6e330648c1ee06e98e5 2030 gnome-session_3.8.4-3.dsc 1fac846271b71832c41fa6f55a751d90a7d2c56f 61727 gnome-session_3.8.4-3.debian.tar.gz bac1907a1c4caa8fe89bec70c4c6d950382e25fe 184712 gnome-session_3.8.4-3_all.deb ebc1c7c9a0677714a98bfd016984ccc834f9b68d 344526 gnome-session-common_3.8.4-3_all.deb f282bc68735380235a9e76654fd06caf3d2b13c9 273418 gnome-session-bin_3.8.4-3_amd64.deb Checksums-Sha256: 2384eb6232e6ca30cd8502d91a47dab6e22fe16c1d8ede18f63ceb1219ebe660 2030 gnome-session_3.8.4-3.dsc 48aea85e29f05b7203ccf0ac9a4c9b6e93542775fc16513665459a2d47e73aa8 61727 gnome-session_3.8.4-3.debian.tar.gz 486d22b3add71569a2c4b33a69777593b5e6471dbe64414898c7d366dd5f 184712 gnome-session_3.8.4-3_all.deb 309090d92f47a229b2b745c9dbe287f83be97fe20679641929c5e155fea71419 344526 gnome-session-common_3.8.4-3_all.deb 1322e49c909ec89827d882f4a7537b00ef06236092cd3e18882a298b349b92c8 273418 gnome-session-bin_3.8.4-3_amd64.deb Files: a353d0c555fde116bdb69b395920bc1b 2030 gnome optional gnome-session_3.8.4-3.dsc 766e7905c21ce807527e51c89dbcfada 61727 gnome optional gnome-session_3.8.4-3.debian.tar.gz 84c35564e579321a3e15d8ed0d9ba6e3 184712 gnome optional gnome-session_3.8.4-3_all.deb f90297ecc068283ad2f2288ee09cf186 344526 gnome optional gnome-session-common_3.8.4-3_all.deb 356e1effd8a71005d3f877c055ac258f 273418 gnome optional gnome-session-bin_3.8.4-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJrz88ACgkQhTV17EoIsv7fwACdG8u/xzuYPTxfgEfcAoK9BEeE 4A8AoIknMeUERE3K5AiaqHNtK0aE6bFq =D0DF -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/e1va5e6-dk...@franck.debian.org
Accepted goffice 0.10.8-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 22:19:01 +1100 Source: goffice Binary: libgoffice-0.10-dev libgoffice-dbg libgoffice-0.10-10 libgoffice-0.10-10-common gir1.2-goffice-0.10 libgoffice-0.10-doc Architecture: source amd64 all Version: 0.10.8-1 Distribution: unstable Urgency: low Maintainer: Dmitry Smirnov only...@debian.org Changed-By: Dmitry Smirnov only...@debian.org Description: gir1.2-goffice-0.10 - GObject introspection data for the GOffice library libgoffice-0.10-10 - Document centric objects library - runtime files libgoffice-0.10-10-common - Document centric objects library - common files libgoffice-0.10-dev - Document centric objects library - development files libgoffice-0.10-doc - Document centric objects library - documentation libgoffice-dbg - Document centric objects library - debugging files Changes: goffice (0.10.8-1) unstable; urgency=low . * New upstream release [October 2013]. Checksums-Sha1: 0961bb7a4d01914df0296ffca5b02f3a4406a4c8 2562 goffice_0.10.8-1.dsc a9cc2da4e666884de846f3c47e7314ef6d368d58 2205528 goffice_0.10.8.orig.tar.xz 49f279b837e76ac412840124467b61a2a2f8e11e 19568 goffice_0.10.8-1.debian.tar.xz d1668c7ce7e5024bd5cb3d01e4de61e2f753b5e7 969726 libgoffice-0.10-dev_0.10.8-1_amd64.deb 604dbd2da017968204e41811b864b597e52cdab8 2520034 libgoffice-dbg_0.10.8-1_amd64.deb 7b786d17441bfacb4dba34dff82773407a998f1a 1605338 libgoffice-0.10-10_0.10.8-1_amd64.deb 773707808c6ff8a829df6253897b7860a4bf9209 719434 libgoffice-0.10-10-common_0.10.8-1_all.deb ecec321689eb5547ce7d3b5ade40fddf0d304635 223092 gir1.2-goffice-0.10_0.10.8-1_amd64.deb c32c1a4677208665dae8905967f99f09a952b7d9 395218 libgoffice-0.10-doc_0.10.8-1_all.deb Checksums-Sha256: dcf2eb1098062c7d9c958e575a2ec3f7da4c0f94dcac5837d2a8e048a1d2b623 2562 goffice_0.10.8-1.dsc 11964b907b03dede6d8d8a1a4ae2d5727ffbe8d7bab5c92dec586acb616e807c 2205528 goffice_0.10.8.orig.tar.xz c3a1f6f86bb2468c138e99d3b85f8ff59481aa259e5092e926ea683f382ec665 19568 goffice_0.10.8-1.debian.tar.xz 4779373eded6d651b260602df75d243f3d983c23b4038c763a24674e68deb1d2 969726 libgoffice-0.10-dev_0.10.8-1_amd64.deb ce49674f33e172a7202caa110b50dcf9b230d1e3aa0ef2186d8eee0d00c2f55f 2520034 libgoffice-dbg_0.10.8-1_amd64.deb 910fe619c5b53e22096540c730ad36dd0c75edde1dd3392793eeccbecb87141e 1605338 libgoffice-0.10-10_0.10.8-1_amd64.deb f7b186d2de4dd482d81aa6bc80f7365a217bceebbc05788a75bbc8e7f6368521 719434 libgoffice-0.10-10-common_0.10.8-1_all.deb dd480fddf68d62e46694830cda1e110ebb50753117c4cb87e26f42ad3889163c 223092 gir1.2-goffice-0.10_0.10.8-1_amd64.deb 2bda2f52ae4138857ce4a2fa453c80f20777e1cc25d129e3f4125011a874f8b3 395218 libgoffice-0.10-doc_0.10.8-1_all.deb Files: 74ce197c2922a3ae8f75481ca0631f36 2562 libs optional goffice_0.10.8-1.dsc 12364d1b386bc8b15ae046b847528f6c 2205528 libs optional goffice_0.10.8.orig.tar.xz f91865ee2e10a59b4f90e51f2febf00f 19568 libs optional goffice_0.10.8-1.debian.tar.xz 342c749242031d224389e771a242b54d 969726 libdevel optional libgoffice-0.10-dev_0.10.8-1_amd64.deb 09bcf84c882d3facb96b340a1b7dac54 2520034 debug extra libgoffice-dbg_0.10.8-1_amd64.deb 77bddd178cae6bc161d762554b9205ae 1605338 libs optional libgoffice-0.10-10_0.10.8-1_amd64.deb c3b5955cc8ddb4d510bebc8ecc6dbad4 719434 libs optional libgoffice-0.10-10-common_0.10.8-1_all.deb 0d5ea355dc648a6327a3fa560b6dd2a4 223092 introspection optional gir1.2-goffice-0.10_0.10.8-1_amd64.deb c42d23747c746054e460a6872d4d5eed 395218 doc optional libgoffice-0.10-doc_0.10.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSa9VKAAoJEFK2u9lTlo0bopsQAJhmYbVkW5LMOHfL9pCbj42U OpgWA1oaE6U9E/YycydMaFuqgzJ56YY1Ohexo/+4AK1dAoNYXCyqbrzCIeNDcTg7 ODEv85wM2SBQweZnA0OHYwBpdKj4YpijA2KeO1dZi/P2AxfzrAnF0Uj8gUQcrjlV XlEDK79Xg+8HXTkXcNQVQdBs76FfN5voAaU4rKVEPVQ6kCVu8yGAi2hHrpsybxzq Oaiq9kaN0Ker8FkgTsjjeSmmDOnw4JwT4Ttvl/e4C2Qw37tUR+bG4aKioubYieTx 72+6PDi97Ub9BXZcVTutRiDlgONe7FHxdur7AKXRDNuupCMQCpbej3L1g3S4ScOi XFD3Jj+wL6jEQTCf7WxmQKrADU5scXPj6T06FegGN3PxCvYHCdYDKywHt3HphbXE jLP/KMZ6gupWUEZtRFyRQwNtj1kvpP/+Srb7Tsehpf2mMKoa3tOOwijEhZnSLGV4 NUQTF55vBrXRhj0snDCgzB+GpFYGJYAH3ih7GWPI/iPxFUrUKefgxm+WN7ttblDf JEPNgxAOs5BwdqU+L8YGwwjpU/uZ2Du757FTGICTxJvcFIIj+qnBVAq3nm3IVIh6 KBHQfdcFmdgUjo3vpv50BdrpfXY91HoWd/peFdmmcE/A047gfdo1bIyPDKZCXoBw Vtri4W2TyexIKHYOKop5 =2xR6 -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/e1va5eb-pr...@franck.debian.org
Accepted passportjs 0.1.17-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 Oct 2013 16:51:13 +0200 Source: passportjs Binary: node-passport Architecture: source all Version: 0.1.17-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers pkg-javascript-de...@lists.alioth.debian.org Changed-By: Jérémy Lal kapo...@melix.org Description: node-passport - simple, unobtrusive authentication system for Node.js Changes: passportjs (0.1.17-1) unstable; urgency=low . * Upstream update * Standards-Version 3.9.4 * Update 1001 patch to match current practice. Forward upstream * Add 2001 patch to get rid of dependency on node-pause * Keep tree when installing * Build-Depends nodejs, so it is available where installable * Rename license from MIT to Expat Checksums-Sha1: eb3436687b369512c600405fd837701a88e54405 1988 passportjs_0.1.17-1.dsc bbdd6572dd728549c09e389f7dbc88553388b08d 20393 passportjs_0.1.17.orig.tar.gz 03e46947a72fd971025f4edfc5ee60461779a92a 3216 passportjs_0.1.17-1.debian.tar.gz a37a40dfa37e7859b5ad872b861bbb819dca223e 13110 node-passport_0.1.17-1_all.deb Checksums-Sha256: ef231e70ddf82d7b175d603643bb54b154e94b2ba7d4a0c54a53129ddc1c8f75 1988 passportjs_0.1.17-1.dsc 9ef78802a125937b2682be4fdd0fe292e8ce6c4accf0fbbf2a3689c5db527e72 20393 passportjs_0.1.17.orig.tar.gz baf9a10364911f3fffaee5da214058c7047de6ab11b94fe84996ca79cad3c171 3216 passportjs_0.1.17-1.debian.tar.gz c1d2ae984b1015e32bbc9a36a989ab32f73fa572d602cf59fbc20ae16fcfb8dd 13110 node-passport_0.1.17-1_all.deb Files: 005c99bf3baa99bc82ed581c6741a3e9 1988 web extra passportjs_0.1.17-1.dsc 3276a540f34fa72dddfefa3c8f6fb223 20393 web extra passportjs_0.1.17.orig.tar.gz c889553af27fcf893db38631369d0c35 3216 web extra passportjs_0.1.17-1.debian.tar.gz edc0fe067376c171cd70ebe7a8d8f364 13110 web extra node-passport_0.1.17-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSa9lLAAoJEGYRwF7dOfN0jG0QAIrQefBmk7SPPIfj47MgK636 d+Z7ljSJglCeoJnRlBAvhjMlj2R6TfQ1KjzBCjCJQR6bM+/r4e2J5diuOWJclOp8 ux52rd5W0JT/Q1TE3jjhdIPCeEMexiq8vjeJ8BdjXCaZVtGBLxZ4Mp+ropyO5cya Nax8F4GQ3kK9EN+dKfrD0TWu2eZvl5l+fgGCEvdy90sF8B2HklrP/Pq3Z0p1Xzgy 7Vh8qw2+4q4GpuluUIdh1967Gi2A3mifpb/NGtteq1WH5FQMjSSSxF1/KMxsfF5T nIMwdGu/d6bZmbmiUGiPooqwtvAKRgfwg5cazWDDriQq9KIsPLlNjUED2zB3+HRO yhCd639pvl1LJ5+vZS12pe6O3Jb5NqjuUfoVpLkMC/TkDh5dRgTRxJfROm/lYQg6 u3jlkxHfhRT0Uo+PlecWzUuOJ/IwlNoBr36QyDktDoQ43zw9eLFBHyuIJiAHXMcg AIqPNRUK7xembkQkXp77VZndivEPYHxSX7kXW8vvh4x4VHOD3qanrdF5WhRXZlkz ug36ZNhogMMuICs3dfJHEiqgszbVdiavqqxgC6Y+QMGGvx9v6uTUV+TlRXtwumQI FgRgL4WuMc8HYUy/XLcBOhQkJZtF1nx/ThiDzhDkSNYRHlsPyE2Tvs2dIRSGNIno O+aSRO+pguHl8SOh3ugp =6z0Q -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/e1va5fi-b7...@franck.debian.org
Accepted zsh 5.0.2-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 26 Oct 2013 15:09:56 +0200 Source: zsh Binary: zsh zsh-common zsh-doc zsh-static zsh-dev zsh-dbg zsh-beta zsh-beta-doc Architecture: source all amd64 Version: 5.0.2-6 Distribution: unstable Urgency: low Maintainer: Debian Zsh Maintainers pkg-zsh-de...@lists.alioth.debian.org Changed-By: Axel Beckert a...@debian.org Description: zsh- shell with lots of features zsh-beta - transitional package to zsh zsh-beta-doc - transitional package to zsh-doc zsh-common - architecture independent files for Zsh zsh-dbg- shell with lots of features (debugging symbols) zsh-dev- shell with lots of features (development files) zsh-doc- zsh documentation - info/HTML format zsh-static - shell with lots of features (static link) Changes: zsh (5.0.2-6) unstable; urgency=low . * [57d31fe2] Replace patch to search for usable tty by patch to use /dev/null for -c test. Suggested on zsh-workers by Bart Schaefer. Checksums-Sha1: afaaa8dbf48f84ed576315869f7a8a2344c383d8 1850 zsh_5.0.2-6.dsc 8b255fe41802a3b1abb7f25d15da815bd274a959 73470 zsh_5.0.2-6.debian.tar.gz 0b40b413266a98a301c5f272990716adf2c5d9d2 2959180 zsh-common_5.0.2-6_all.deb e6955beb00aff94a6f7a712e92ff2a311eab9d5f 2398602 zsh-doc_5.0.2-6_all.deb d9f11dd50a5331c57a77e03ad64ca4bc85372986 1434 zsh-beta_5.0.2-6_all.deb a3437df79a92d26a7864d1d6148980a854752f39 1104 zsh-beta-doc_5.0.2-6_all.deb f99e77b5498bb1cdfc12fcb35552d3aee54e3f49 606286 zsh_5.0.2-6_amd64.deb 43d78ae7322b47ab68d750e7b80097f23a4e26e8 890052 zsh-static_5.0.2-6_amd64.deb d70f5846ccc6349c1246f78f18bbba3325225c8d 46974 zsh-dev_5.0.2-6_amd64.deb 17186111d9a7801e707c6d2af2d3c0b2e57f07fe 1501724 zsh-dbg_5.0.2-6_amd64.deb Checksums-Sha256: 63b827291b31d7f1f9414e2ab4a9fc5b4334b1e5c8a63c4c20b48c8c977e2142 1850 zsh_5.0.2-6.dsc 688ad1fdb0e345fb472f23485a3d06e54875adc4ef724f4b7c7d8362cd89e05c 73470 zsh_5.0.2-6.debian.tar.gz 1988fa3adb1f9c54d6e507d0ebacbb4c0e71780f5524ac1928cdbd8e2dd37763 2959180 zsh-common_5.0.2-6_all.deb 2a68796e674556f14e03ee6254d7c460b79cdbf03f7a6b69cba61e7b18ca1763 2398602 zsh-doc_5.0.2-6_all.deb f5a6d80239105255a7bdec5677ab2562ade4ccc90b130adc2ed22ecf7a19868d 1434 zsh-beta_5.0.2-6_all.deb 0d414e39813eacf03536f4d84bbbe0c41402d367cbf18916390896ee0c4f9977 1104 zsh-beta-doc_5.0.2-6_all.deb f1d0e50b3122b270b11b0e033f527f4a0089b8a10ba4c4e5468efe058903c487 606286 zsh_5.0.2-6_amd64.deb 33a4448472409a895403e22fd6f46831abd51cd35345f7f2bada556f6f807fe2 890052 zsh-static_5.0.2-6_amd64.deb 360ae9cda4da19c39b4810e61b57b753411c10f7221bc821823f6271d3e3c9ab 46974 zsh-dev_5.0.2-6_amd64.deb 96f22dc02f40e2bf6d4ce048ba9a7a7bfd537cfda6974bcb166fb271c8605a8a 1501724 zsh-dbg_5.0.2-6_amd64.deb Files: b8e6d2109b706c4c8f5d71d448792d6a 1850 shells optional zsh_5.0.2-6.dsc c40aa69f3456309c8f069d85295825b3 73470 shells optional zsh_5.0.2-6.debian.tar.gz ba93a455af1393007ee245dd4202549a 2959180 shells optional zsh-common_5.0.2-6_all.deb e53018e7c2ba213c80e2382c14f7eb0c 2398602 doc optional zsh-doc_5.0.2-6_all.deb 42a6b05662f3466d846cea21e0435b11 1434 oldlibs extra zsh-beta_5.0.2-6_all.deb 86d215b6dc42fffe0a214549a1bc9692 1104 oldlibs extra zsh-beta-doc_5.0.2-6_all.deb b288a460b2e7fec695091dad43536dbc 606286 shells optional zsh_5.0.2-6_amd64.deb 0d29ce3ea0ed1eba49154ba8f62cea46 890052 shells optional zsh-static_5.0.2-6_amd64.deb e0080a889684ed1f291b3ee87ae99be5 46974 libdevel optional zsh-dev_5.0.2-6_amd64.deb 9790f4503ae80aa1e330d883b57e1ed6 1501724 debug extra zsh-dbg_5.0.2-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJrw44ACgkQwJ4diZWTDt5gcgCfU02OUnBd9MNzmMdNM2A9aUqS lAwAn2zkkf+0WMVHgF7DoL3SD0NOvUHw =KdcY -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/e1va5gu-0001aa...@franck.debian.org
