Re: Maildir vs. mbox in Debian
On Jo, 29 nov 12, 11:35:44, Ivan Shmakov wrote: What are the estimates? And wouldn't it be better to use some kind of a specialized search engine if searching is deemed “crucial”? I guess that it may render the difference between the formats somewhat irrelevant. Something like notmuch for example. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#694698: ITP: ruby-libwebsocket -- Universal Ruby library to handle WebSocket protocol
Package: wnpp Severity: wishlist Owner: Vipin Nair swv...@gmail.com * Package name: ruby-libwebsocket Version : 0.1.7.1 Upstream Author : Bernard Potocki bernard.poto...@imanel.org * URL : https://github.com/imanel/libwebsocket * License : MIT/X Programming Lang: Ruby Description : Universal Ruby library to handle WebSocket protocol -- 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/20121129100947.24567.21110.reportbug@localhost
Bug#694709: ITP: ruby-weblibsocket -- Universal Ruby library to handle WebSocket protocol
Package: wnpp Severity: wishlist Owner: Vipin Nair swv...@gmail.com * Package name: ruby-weblibsocket Version : 0.7.1-1 Upstream Author : Bernard Potocki bernard.poto...@imanel.org * URL : http://github.com/imanel/libwebsocket * License : MIT/X Programming Lang: Ruby Description : Universal Ruby library to handle WebSocket protocol -- 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/20121129104903.25556.79943.reportbug@localhost
Re: the right bug severity in case of data corruption
On Thu, 2012-11-29 at 08:23 +0100, Paul Gevers wrote: Icedove 10.0.10 (Wheezy, no custom configuration on that front) here. Thunderbird is prone to the issue... and there are only few cases where it doesn't occur... Have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=808450 especially my comment 25, which shows some cases where the issue would not happen with TB. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: the right bug severity in case of data corruption
On 2012-11-29 01:50:55 +0100, Christoph Anton Mitterer wrote: It's like a serious flaw would have been found in gzip and people would say... oh don't complain... there's already the much better/newer bzip2 or xz. There's a major difference. mbox is buggy by design. Even though mboxrd attempts to fix some problems, there are still MUA's that would show the added in the body (one problem is that they can't detect reliably which mbox format is used). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129140420.gc5...@xvii.vinc17.org
Re: Maildir vs. mbox in Debian
On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote: But it also has disadvantages to the mbox formats which may be crucial for some people: - wasting a lot of storage, which can be significant even if you use small file systems block sizes... This is a problem with the file system, not with maildir. Here's an example of file system (though not for Unix) that was partly optimized to avoid these block size problems: http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt (just for the pleasure of citing mail from 1990 :) Now, I would say that in general, the wasted space is small compared to large attachments. And if you have only text and care about disk space, you should consider a compressed format, not pure mbox. - full text search will typically be slower, as one has to open/close many files This depends. I index my archive mailbox with mairix, and with mairix, it is better to use maildir as a search result is built with symlinks instead of copying the individual mail messages. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129142033.gd5...@xvii.vinc17.org
Re: Really, about udev, not init sytsems
On Sun, Nov 25, 2012 at 04:03:21PM +0100, John Paul Adrian Glaubitz wrote: On Sun, Nov 25, 2012 at 10:52:58PM +0800, Thomas Goirand wrote: On 11/25/2012 01:30 AM, John Paul Adrian Glaubitz wrote: Why? Why would you want to rip such low-level stuff apart? Well, isn't it the opposite thing that is happening? Such low-level stuff are being merged (with systemd+udev merge), they were separated projects before. So, I'd rather ask you: why would you want such low-level stuff to merge, since some others like it separated (like for example, to be able to have the choice of replacing one or another)? Well, systemd and udev are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. udev and pulseaudio are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Internet explorer and Windows are developed by the same company. Both interact very closely and integration of the two was the natural consequence. I'm not sure I agree with any of those arguments. Yes, it makes it more difficult to use udev with a different init system, but again most people don't care [citation needed] as long as the init system they have works reliable. And since udev is Linux-only anyway, I don't see a problem merging it with a Linux-only init system. You're basing that statement on the premise that everyone agrees switching the init system to systemd is fine, and that therefore merging udev and systemd isn't a problem. This is false. First, there are those among us who dislike systemd, for various reasons. The fact that this thread exists, should prove that. Second, there are distributions (like Ubuntu) who don't seem to have any long- or near-term plans to move to systemd. Making them use systemd just so they can continue to use udev seems fairly problematic. If it's so important to be able to choose such a low-level component as the init system, why aren't people demanding that you can choose different kernel stacks of choice? For example OSS4 instead of ALSA or the old Firewire stack instead of the new one? Back when OSS was the only in-kernel option on Linux (2.4 and before, IIRC), ALSA was developed alongside the kernel. Eventually it got merged, as _an alternative_ inside the kernel. It's only fairly recent that OSS support was dropped -- even if that's happened at all, of which I'm not sure (and I don't care enough to check). If you're going to merge udev and systemd, then suddenly such choice becomes much more difficult. That's the problem here: that a technical choice, which may or may not be the best (I really don't care at this point) is forced upon people who don't care about those who disagree with them. udev took quite some time to be accepted by the community too, but now it's probably fair to say that it has been. To try to couple that to systemd sounds like a bad form of systemd advocacy to me. Oh well, we'll see what the future brings, I suppose. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121129142102.ga...@grep.be
Re: the right bug severity in case of data corruption
On 2012-11-29 01:39:57 +0100, Christoph Anton Mitterer wrote: On Wed, 2012-11-28 at 16:01 +0100, Vincent Lefevre wrote: Even users of mboxo shouldn't even have a problem because in your message the F of the From line is encoded in quoted-printable: | =46rom blahhityblah Fri Jul 8 12:08:34 2011 | From foobarbaz Fri Jul 8 12:08:34 2011 | From quux Fri Jul 8 12:08:34 2011 But this is something that just some friendly MUAs do... it's in no way imposed by any standard to this kind of clever quoting I know, but I was just saying that Adam's test (of the recipients' mail system) was useless because his MUA (Mutt) avoids the problem of having an unencoded From line. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129142424.ge5...@xvii.vinc17.org
Re: Really, about udev, not init sytsems
On Sun, Nov 25, 2012 at 06:49:45PM +0100, John Paul Adrian Glaubitz wrote: On Mon, Nov 26, 2012 at 01:08:31AM +0800, Thomas Goirand wrote: Now, I may add, I have no will to discuss it with you anyway, after reading you impose on my your partitioning scheme, and would like me to use my computer the way *YOU* think is best. That is, by the way, the same attitude systemd upstream has. Yes, you can do with *YOUR* computer whatever you want. You can paint it pink and attach nice flower stickers onto it. But that doesn't mean upstream or distribution developers always have to keep their software in the most flexible way so it would fit everybody. It's simply not feasible and wastes time and efforts sometimes. Possibly. Now if someone wants to fork the particular bits of upstream software so making use of a separate /usr is still possible, even if you think it's totally useless, are you going to stop them. That's what this thread is about, really. It's pointless to put so much effort to support every single use case. Why aren't we all using Windows, then? [...] -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121129142421.gb...@grep.be
Re: Really, about udev, not init sytsems
On Sun, Nov 25, 2012 at 08:02:20PM +0100, John Paul Adrian Glaubitz wrote: On Mon, Nov 26, 2012 at 02:12:23AM +0800, Thomas Goirand wrote: P.S: By the way, there's still an ongoing m68k porting effort. Please respect this work as well. I've been a vivid Amiga user since 1991* and I still love these machines and I am supporting the efforts to get Debian back onto m68k. Yet, I do not think this should happen at all costs. There haven't been no new 68k processors for years, have there? http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF the most recent processor you can find there was released in January 2012. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121129142840.gc...@grep.be
Re: Maildir vs. mbox in Debian
On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote: On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote: But it also has disadvantages to the mbox formats which may be crucial for some people: - wasting a lot of storage, which can be significant even if you use small file systems block sizes... This is a problem with the file system, not with maildir. Well I don't think you can say that so easily... or at least not in practise... cause all the major filesystems seem to have this problem. Even if you use Reiser3 - which has anyway issues - that packed mode has it's other drawbacks... http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt (just for the pleasure of citing mail from 1990 :) :D Now, I would say that in general, the wasted space is small compared to large attachments. And if you have only text and care about disk space, you should consider a compressed format, not pure mbox. Well it's not that small: http://dovecot.org/pipermail/dovecot/2012-October/069130.html This depends. I index my archive mailbox with mairix, and with mairix, it is better to use maildir as a search result is built with symlinks instead of copying the individual mail messages. Do these tools (mairix, notmuch, etc.) also help with real full text search? I just though they'd index some stuff. Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 03:30:47PM +0100, Christoph Anton Mitterer wrote: Do these tools (mairix, notmuch, etc.) also help with real full text search? I just though they'd index some stuff. I can't speak for mairix, etc., but notmuch can handle full text search. To quote from notmuch-search-terms(7), The search terms can consist of free-form text (and quoted phrases) which will match all messages that contain all of the given terms/phrases in the body, the subject, or any of the sender or recipient headers. Ryan -- |_)|_/ Ryan Kavanagh | GnuPG key | \| \ http://ryanak.ca/ | 4A11C97A -- 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/20121129143706.gh32...@upsilon.ryanak.ca
Re: Really, about udev, not init sytsems
On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote: Well, systemd and udev are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. udev and pulseaudio are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Internet explorer and Windows are developed by the same company. Both interact very closely and integration of the two was the natural consequence. I'm not sure I agree with any of those arguments. Ok, I should have added that both udev and systemd are also very closely related. So there are certainly benefits of merging the code. As I already mentioned somewhere else, FreeBSD has the same approach with their kernel and the basic userland. Doesn't the FreeBSD source even include some games? Yes, it makes it more difficult to use udev with a different init system, but again most people don't care [citation needed] Well, it's obvious, isn't it? I mean, I am talking about the average joe. I didn't hear anyone complain when Apple switched to launchd in 10.4 and I have really never ever people arguing about what init daemon is the best until systemd came up. I can't get rid of the impression that the rejection of systemd is solely based on technical merits. as long as the init system they have works reliable. And since udev is Linux-only anyway, I don't see a problem merging it with a Linux-only init system. You're basing that statement on the premise that everyone agrees switching the init system to systemd is fine, and that therefore merging udev and systemd isn't a problem. This is false. First, there are those among us who dislike systemd, for various reasons. The fact that this thread exists, should prove that. Again, I am constantly asking here what these reasons might be and yet people always come with strawman arguments. I mean, seriously we had the discussion that systemd is a bad design because it uses the same configuration file syntax as Windows ini files or XDG .desktop files, adding the statement that these are too difficult to parse. The only valid argument I have seen so far against systemd is the fact that it doesn't support non-Linux kernels. But this is true for upstart as well. Plus, there are already efforts to get a systemd-unit-file-to-sysvinit converter running. So, the BSD and Hurd fans are not completely left outside. There is other stuff in Debian as well which won't work on these kernels after all (like udevd). Second, there are distributions (like Ubuntu) who don't seem to have any long- or near-term plans to move to systemd. Making them use systemd just so they can continue to use udev seems fairly problematic. Well, but I would say Ubuntu is to be blamed here. As opposed to upstart, systemd has many supporters and contributors in the industry (Intel, ProFusion, SuSE, RedHat) while upstart is virtually only actively developed by Canonical if am I not mistaken. Plus, you have to sign a contributor's agreement with Canonical which leaves a bad taste in my mouth. That shouldn't be the case with true free software, should it? If it's so important to be able to choose such a low-level component as the init system, why aren't people demanding that you can choose different kernel stacks of choice? For example OSS4 instead of ALSA or the old Firewire stack instead of the new one? Back when OSS was the only in-kernel option on Linux (2.4 and before, IIRC), ALSA was developed alongside the kernel. Eventually it got merged, as _an alternative_ inside the kernel. It's only fairly recent that OSS support was dropped -- even if that's happened at all, of which I'm not sure (and I don't care enough to check). Yes, but ALSA was so quickly adopted that very shortly after no one really cared about OSS anymore. I was rather surprised that it took so long to be completely abandoned. It was virtually only there to support sound cards which had no ALSA drivers yet, didn't it? If you're going to merge udev and systemd, then suddenly such choice becomes much more difficult. That's the problem here: that a technical choice, which may or may not be the best (I really don't care at this point) is forced upon people who don't care about those who disagree with them. Sure, I don't disagree on this point. But again, don't you think it makes sense to got into that direction when the adoption rate of a certain software is high? I mean, just look at the popcon numbers for systemd vs upstart: http://qa.debian.org/popcon-graph.php?packages=systemd http://qa.debian.org/popcon-graph.php?packages=upstart udev took quite some time to be accepted by the community too, but now it's probably fair to say that it has
Re: the right bug severity in case of mbox formats
On 2012-11-29 01:49:55 +0100, Christoph Anton Mitterer wrote: On Wed, 2012-11-28 at 22:06 +, Darren Salt wrote: It would make sense to have that enabled by default, and to ensure that all software in Debian which produces MIME quoted-printable does this, or at least can do this. I agree... but let me add a few notes: 1) Most programs I know of (at least Evolution, haven't checked mutt yet) that do this =46rom encoding do it completely wrong... why? Just quoting (regexp) ^From (.*)$ lines to =46rom \1 is obviously not enough. One also needs to quote ^(*)From (.*)$ lines to =3E\1From \2... otherwise clients could again wrongfully unquote such lines... MUA's should not attempt to remove these quotes *unless* they know there are using mboxrd. So, I don't see any problem with the current behavior. Note: the F encoding may be necessary because mboxo generation corrupts the mail body (and it is done by the sender just in case the recipient uses mboxo, in order to avoid a corruption at this side). But there is no corruption with mboxrd. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129144257.gf5...@xvii.vinc17.org
Bug#694724: ITP: libb64 -- base64 encoding/decoding library
Package: wnpp Severity: wishlist Owner: Jakub Wilk jw...@debian.org * Package name: libb64 Version : 1.2 Upstream Author : Chris Venter chris.ven...@gmail.com * URL : http://libb64.sourceforge.net/ * License : none (the code has been placed in the public domain) Programming Lang: C, C++ Description : base64 encoding/decoding library libb64 is a library of ANSI C routines for fast encoding/decoding data into and from a base64-encoded format. C++ wrappers are included. -- Jakub Wilk -- 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/20121129144246.ga...@jwilk.net
Re: Canonical pushes upstart into user session - systemd developer complains
On Mon, Nov 26, 2012 at 05:00:14PM +0100, Vincent Lefevre wrote: On 2012-11-26 07:27:08 +0900, Norbert Preining wrote: Ever heard of grep, sed, awk, all these nice things that make your life happy. These tools are broken when dealing with multibyte characters. No they're not. For instance, with: foo = aéb a grep 'a.b' file will find nothing in the C locale. But it will in a UTF8 locale, or in an ISO-8859-1 locale, for instance. In a C locale, the é character simply does not exist, so you can't enter it. If you entered it in a UTF8 locale and then switched to a C locale to try to parse it, that can't work. It'd be like if you said foobar/foo, and then complained to the author of your XML parser that it doesn't understand what's going on. No please - I don't mind the key = value in group config format, that is readable, usefull, easy to edit. I disagree about readable, except on small files. For instance, in the default .subversion/config file, the group names are lost among the comments. The default .subversion/config file is a piece of documentation, not a configuration file. I agree that there's far too much noise in there. However, that's not a flaw of the format, it's a flaw of the subversion default config file. And this format is also easy to break without noticing the breakage. That claim is true for any structured file format, including XML. Everything but XML. *EVERYTHING*. This is your opinion. I disagree. XML is nice for things like validation and complex operations. XML is easy (easier) to edit if you use the right tools. XML is great for the things it was made for, but it's not a very useful configuration file format. XML requires far too much noise to be put in the config file for that. In addition, your implicit claim that it's difficult to validate ini-style configuration files, or to do complex operations on them, is just false. There are plenty of libraries to parse .ini files, too, for instance. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121129144635.gd...@grep.be
Re: Really, about udev, not init sytsems (was: Gentoo guys starting a fork of udev)
+++ John Paul Adrian Glaubitz [2012-11-24 18:30 +0100]: On Sat, Nov 24, 2012 at 06:03:02PM +0100, Toni Mueller wrote: On Sat, Nov 24, 2012 at 05:15:25PM +0100, John Paul Adrian Glaubitz wrote: If both Ubuntu and Gentoo would just go with the rest of the community and accept systemd, we wouldn't have to bother whether udev runs without systemd or not. I would highly prefer a system where I can take small bites if I want to, and where components are as portable as possible Why? Why would you want to rip such low-level stuff apart? It seriously doesn't make any sense unless you need a highly-customized setup, for embedded applications, for example. Right. Exactly. You have a very 'desktoppy' view of the world. Embedded people have been using different init systems for years, and sometimes running without udev entirely, and different device-configuration schemes. This stuff matters, and making bigger monolithic pieces is, in general, not helpful. When you have something such low-level, you're best off with taking the best solution which is clearly systemd I don't think everyone agrees that this is at all clear. I'm sorry for the harsh tone, but it's really something that annoys me, people constantly complaining about systemd but never really coming up with good arguments why something as low-level as systemd/udev should be replacable in the first place. 95% of the users don't care and just want something that's reliable. 95% of _desktop_ users, which is a tiny fraction of _linux_ users. Your perspective is highly skewed. Linux is a very wide ecosystem, with many many use cases. Who are you to tell all those people that they are wrong to want/need to use udev without systemd, or indeed use something other than systemd for their init process? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20121129145155.gm9...@stoneboat.aleph1.co.uk
Re: Really, about udev, not init sytsems
Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit : Now if someone wants to fork the particular bits of upstream software so making use of a separate /usr is still possible, even if you think it's totally useless, are you going to stop them. Wouter, I think higher of you than someone who’d bring again the /usr argument which has already been debunked to death. There are valid arguments for forking udev, but /usr support is not one of them; we will just move /usr mounting to the initrd if it cannot be mounted later. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1354201085.30332.2.camel@tomoyo
Re: Maildir vs. mbox in Debian
On 2012-11-29 15:30:47 +0100, Christoph Anton Mitterer wrote: On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote: Now, I would say that in general, the wasted space is small compared to large attachments. And if you have only text and care about disk space, you should consider a compressed format, not pure mbox. Well it's not that small: http://dovecot.org/pipermail/dovecot/2012-October/069130.html So, around 10% on this example. Not really significant. If these 10% are a problem, I would also consider other means, such as compressing the mailbox (one can gain 50% or more) and/or removing useless headers. This depends. I index my archive mailbox with mairix, and with mairix, it is better to use maildir as a search result is built with symlinks instead of copying the individual mail messages. Do these tools (mairix, notmuch, etc.) also help with real full text search? I just though they'd index some stuff. If by real full text, you mean a sequence of words, a solution is to search one or two meaningful words with mairix (this should be very fast), then do a full search on the resulting mailbox (which should be small enough). This might also be scripted... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129150527.gg5...@xvii.vinc17.org
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 03:20:34PM +0100, Vincent Lefevre wrote: On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote: But it also has disadvantages to the mbox formats which may be crucial for some people: - wasting a lot of storage, which can be significant even if you use small file systems block sizes... This is a problem with the file system, not with maildir. Here's an example of file system (though not for Unix) that was partly optimized to avoid these block size problems: http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252efmt.txt (just for the pleasure of citing mail from 1990 :) Now, I would say that in general, the wasted space is small compared to large attachments. And if you have only text and care about disk space, you should consider a compressed format, not pure mbox. *cough* btrfs -ocompress=lzo. Small files are packed inline in metadata blocks, and you get compression you wanted. Using lzo is faster than no compression for most loads, adding negligible cost for incompressible data (especially if not all cores are at 100% usage). -- How to squander your resources: those silly Swedes have a sauce named hovmästarsås, the best thing ever to put on cheese, yet they waste it solely on mere salmon. -- 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/20121129151625.ga20...@angband.pl
Re: Canonical pushes upstart into user session - systemd developer complains
On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote: On Mon, Nov 26, 2012 at 05:00:14PM +0100, Vincent Lefevre wrote: On 2012-11-26 07:27:08 +0900, Norbert Preining wrote: Ever heard of grep, sed, awk, all these nice things that make your life happy. These tools are broken when dealing with multibyte characters. No they're not. For instance, with: foo = aéb a grep 'a.b' file will find nothing in the C locale. But it will in a UTF8 locale, Unfortunately the C locale is the only really portable one. or in an ISO-8859-1 locale, for instance. In a C locale, the é character simply does not exist, so you can't enter it. The config file may have been generated under some locale (or in an application where locales are ignored or can be ignored, say GNU Emacs), but scripts may run in other locales, in particular C for more portability. If you entered it in a UTF8 locale and then switched to a C locale to try to parse it, that can't work. There's no such problem with XML, where the encoding of the documents are handled internally and locales do not matter. So, one can handle XML whatever the environment. Let's get back to XML? The default .subversion/config file is a piece of documentation, not a configuration file. I agree that there's far too much noise in there. However, that's not a flaw of the format, it's a flaw of the subversion default config file. But comments may be useful, and again, there's no such problem with XML. XML tools can hide comments and so on. So, you have config and the documentation at the same place, which is fine. And this format is also easy to break without noticing the breakage. That claim is true for any structured file format, including XML. Less likely with XML, because of validation (you have well-formedness checking in standard, without anything special to write). This is from my experience. Everything but XML. *EVERYTHING*. This is your opinion. I disagree. XML is nice for things like validation and complex operations. XML is easy (easier) to edit if you use the right tools. XML is great for the things it was made for, but it's not a very useful configuration file format. XML requires far too much noise to be put in the config file for that. This verbosity, or redundancy (I wouldn't call that noise), is useful to avoid some form of undetected breakage. That's a choice. In addition, your implicit claim that it's difficult to validate ini-style configuration files, or to do complex operations on them, is just false. There are plenty of libraries to parse .ini files, too, for instance. And interfaces in various programming languages? And command-line tools? The advantage of XML is that it is more common. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129152303.gh5...@xvii.vinc17.org
Re: the right bug severity in case of data corruption
On 2012-11-29 06:43:06 +, Ian Campbell wrote: On Wed, 2012-11-28 at 16:06 -0500, Nikolaus Rath wrote: Darren Salt lists...@moreofthesa.me.uk writes: (Oops. Failed first time.) Having just viewed the raw text of my message (as sent), there's one other little wrinkle which I already knew but had failed to consider and which makes testing of this useless: gpg handles any 'From ' lines itself in a reversible manner, using '- ' as the prefix. The following SHOULD be 0, 1, and 2 levels of quoting, first to last. From blahhityblah Fri Jul 8 12:08:34 2011 From foobarbaz Fri Jul 8 12:08:34 2011 From quux Fri Jul 8 12:08:34 2011 This is looking different here, Me too Me too. but I am not using any mbox* at all... Me neither, AFAIK. I'm using Exim, with procmail delivering into Maildir and Courier imap to read it. The MISCELLANEOUS section of procmail(1) makes me wonder if this might be procmail's doing. At the very least the conditions where it will do From encoding are too complex for me to grok at this time of day ;-) Definitely neither procmail, nor postfix: I've sent a mail to myself with a From (not using QP -- checked that) at the beginning of the line, and everything was fine. The problem may come from the mailing-list software. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129152924.gj5...@xvii.vinc17.org
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 04:16:25PM +0100, Adam Borowski wrote: *cough* btrfs -ocompress=lzo. Small files are packed inline in metadata blocks, and you get compression you wanted. It's nice to see more features from '93 Windows NT implemented for Linux at last. -- WBR, wRAR signature.asc Description: Digital signature
Re: Maildir vs. mbox in Debian
On 2012-11-29 16:16:25 +0100, Adam Borowski wrote: *cough* btrfs -ocompress=lzo. Small files are packed inline in metadata blocks, and you get compression you wanted. Using lzo is faster than no compression for most loads, adding negligible cost for incompressible data (especially if not all cores are at 100% usage). Great! Nice to know. This should be the default in Debian. :) -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129153233.gk5...@xvii.vinc17.org
Re: Canonical pushes upstart into user session - systemd developer complains
On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote: The default .subversion/config file is a piece of documentation, not a configuration file. I agree that there's far too much noise in there. However, that's not a flaw of the format, it's a flaw of the subversion default config file. But comments may be useful, and again, there's no such problem with XML. XML tools can hide comments and so on. So, you have config and the documentation at the same place, which is fine. Imagine a .ini tool that can fold #-comments. -- WBR, wRAR signature.asc Description: Digital signature
Re: Canonical pushes upstart into user session - systemd developer complains
On 2012-11-29 21:33:37 +0600, Andrey Rahmatullin wrote: On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote: The default .subversion/config file is a piece of documentation, not a configuration file. I agree that there's far too much noise in there. However, that's not a flaw of the format, it's a flaw of the subversion default config file. But comments may be useful, and again, there's no such problem with XML. XML tools can hide comments and so on. So, you have config and the documentation at the same place, which is fine. Imagine a .ini tool that can fold #-comments. Yes. But remember that the detractors of XML say that you need tools to handle it in a nice way. BTW, about the readability: ini format: [section1] key1=val1 key2=val2 [section2] foo=bar XML format: root section1 key1val1/key1 key2val2/key2 /section1 section2 foobar/foo /section2 /root It is more verbose, but I find it as readable (if you have characters that normally need to be escaped, you can still use CDATA sections, which is a way to keep the readability). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121129154407.gl5...@xvii.vinc17.org
Re: Really, about udev, not init sytsems |Subject: Re: Really, about udev
Dear Adrian On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote: Again, I am constantly asking here what these reasons might be and yet people always come with strawman arguments. I mean, seriously we had the discussion that systemd is a bad design because it uses the same configuration file syntax as Windows ini files or XDG .desktop files, adding the statement that these are too difficult to parse. The only valid argument I have seen so far against systemd is the fact that it doesn't support non-Linux kernels. But this is true for upstart as well. Plus, there are already efforts to get a systemd-unit-file-to-sysvinit converter running. So, the BSD and Hurd fans are not completely left outside. There is other stuff in Debian as well which won't work on these kernels after all (like udevd). I have tried systemd but as it does not support the Debian extensions to cryptsetup (namely the crypttab keyscript parameter) it is not a valuable alternative for me - sysvinit and upstart btw do support them, I did not yet get the chance to try openrc (and yes this is a Debian specific feature nontheless present since long time so I argue that people are using it and will also continue to do so). I guess this means that either the Debian systemd maintainer may need to handle this in some way (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862) or the Debian users will have to decide how to deal with this matter. Kind regards Harald Jenny -- 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/20121129155835.gb2...@harald-has.a-little-linux-box.at
Re: Canonical pushes upstart into user session - systemd developer complains
On Thu, Nov 29, 2012 at 7:23 AM, Vincent Lefevre vinc...@vinc17.net wrote: And interfaces in various programming languages? http://docs.python.org/2/library/configparser.html http://search.cpan.org/~shlomif/Config-IniFiles-2.78/lib/Config/IniFiles.pm https://rubygems.org/gems/inifile http://ini4j.sourceforge.net/ https://github.com/2ion/ini.lua https://code.google.com/p/inih/ https://github.com/shockie/node-iniparser http://php.net/manual/en/function.parse-ini-file.php http://www.codeproject.com/Articles/10809/A-Small-Class-to-Read-INI-File http://www.boost.org/doc/libs/1_45_0/doc/html/property_tree.html http://doc.qt.digia.com/qt/qsettings.html And command-line tools? An editor with syntax highlighting? Other than that, I don't know of any, but do you really need it with ini? For a specific purpose, you could probably whip something up pretty fast with one of the libraries... The advantage of XML is that it is more common. [citation needed] ini is pretty darn common... I would guess that they might be about the same. Cheers, Kelly Clowers -- 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/CAFoWM=_wgjpuuekj+g23x--g3njffpjwmybotk+e_-wtyrm...@mail.gmail.com
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 04:32:33PM +0100, Vincent Lefevre wrote: On 2012-11-29 16:16:25 +0100, Adam Borowski wrote: *cough* btrfs -ocompress=lzo. Small files are packed inline in metadata blocks, and you get compression you wanted. Using lzo is faster than no compression for most loads, adding negligible cost for incompressible data (especially if not all cores are at 100% usage). Great! Nice to know. This should be the default in Debian. :) Not while dpkg calls fsync() every, approximately, 0.1 bits written. Btrfs has transactions one could use to wrap around a whole dpkg operation, avoiding fsync entirely -- at the cost of having filesystem specific code. But for now you can even think of btrfs only if either you're on stable and don't mind upgrades taking forever, or you use eatmydata. The latter is actually safe if you use btrfs snapshots and revert if power fails during a dpkg run, but sadly, it currently requires quite a bit of manual work, especially to build an appropriate filesystem layout. A machine that's primarily a mail server could use btrfs for the filesystem that holds the mail, of course. Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/ qemu, btrfs is pretty fast. -- How to squander your resources: those silly Swedes have a sauce named hovmästarsås, the best thing ever to put on cheese, yet they waste it solely on mere salmon. -- 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/20121129165206.ga23...@angband.pl
Re: Really, about udev, not init sytsems
On 11/29/2012 10:58 PM, Josselin Mouette wrote: There are valid arguments for forking udev, but /usr support is not one of them; we will just move /usr mounting to the initrd if it cannot be mounted later. On the Debian side of things, you are probably right, since using an initrd is ok in (nearly?) all situations. However, you are running Gentoo and rebuild your kernel, why would you bother with such thing as kernel modules and initrd? The thing is, many (most? all?) Gentoo user, as far as I understand (I'm not a Gentoo user), do not use kernel modules at all. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50b79371.4020...@debian.org
Re: Canonical pushes upstart into user session - systemd developer complains
Kelly Clowers, 2012-11-29 08:37:19 -0800 : [...] And command-line tools? An editor with syntax highlighting? Other than that, I don't know of any, but do you really need it with ini? For a specific purpose, you could probably whip something up pretty fast with one of the libraries... For reading a value, there's confget(1). A tool to *set* a value in an *.ini file is three lines of Python that can be inlined in a shell script (it's been mentioned elsewhere in this thread). Roland. -- Roland Mas Qui trop embrasse rate son train. -- 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/87wqx4pcr2@polymir.internal.placard.fr.eu.org
Re: Canonical pushes upstart into user session - systemd developer complains
On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote: On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote: But it will in a UTF8 locale, Unfortunately the C locale is the only really portable one. Debian's glibc has C.UTF-8 always available these days. or in an ISO-8859-1 locale, for instance. In a C locale, the é character simply does not exist, so you can't enter it. The config file may have been generated under some locale (or in an application where locales are ignored or can be ignored, say GNU Emacs), but scripts may run in other locales, in particular C for more portability. It's high time to kill ancient encodings. They're a maintenance burden, and also, GUIs stopped paying even lip service to non-UTF8 quite some time ago. There's some discussion in #603914, although it has been derailed by minutiae of behaviour of LC_CTYPE=C, which are mostly irrelevant for getting rid of ISO-8859 and friends. Besides, even today, if someone has a config file in an encoding other than the one currently selected, that's an user error. Here XML trying to support that is a downside rather than upside. -- How to squander your resources: those silly Swedes have a sauce named hovmästarsås, the best thing ever to put on cheese, yet they waste it solely on mere salmon. -- 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/20121129170805.gb23...@angband.pl
Re: Really, about udev, not init sytsems |Subject: Re: Really, about udev
Hi Harald, On Thu, Nov 29, 2012 at 04:58:35PM +0100, Harald Jenny wrote: I have tried systemd but as it does not support the Debian extensions to cryptsetup (namely the crypttab keyscript parameter) it is not a valuable alternative for me - sysvinit and upstart btw do support them, I did not yet get the chance to try openrc (and yes this is a Debian specific feature nontheless present since long time so I argue that people are using it and will also continue to do so). I guess this means that either the Debian systemd maintainer may need to handle this in some way (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862) or the Debian users will have to decide how to deal with this matter. Thank you! This is actually a true valid point which I personally would accept as an argument against systemd. Without looking into the details, this seems to be something that can be fixed by a new upload, doesn't it? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129171214.ga20...@physik.fu-berlin.de
Re: Really, about udev, not init sytsems
On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote: However, you are running Gentoo and rebuild your kernel, why would you bother with such thing as kernel modules and initrd? The thing is, many (most? all?) Gentoo user, as far as I understand (I'm not a Gentoo user), do not use kernel modules at all. In that situation, you'd be posting to gentoo-dev. -- 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/20121129171831.GB3605@debian
Re: Really, about udev, not init sytsems
2012/11/29 Wouter Verhelst wou...@debian.org: glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Please, *DONT* :-) I've tired of this crap on illumos -- 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/CALL-Q8xMeDSUHaLw=dtkub3p4cy3k-afzpza16ztblfl7kb...@mail.gmail.com
Re: Really, about udev, not init sytsems
On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote: Plus, you have to sign a contributor's agreement with Canonical which leaves a bad taste in my mouth. That shouldn't be the case with true free software, should it? In an ideal world maybe it shouldn't, but in truth it is for both open source and free software. As project leader of a GNU project, with copyrights owned by the FSF, I am required to obtain copyright assignments from contributors, which some folks feel are more onerous than contributor agreements. Open source projects like Python require contributor agreements for core developers, and this is not an uncommon requirement. We can argue about specific contribution legal documents and policies (although hopefully, not here ;) but not about whether they are a reality in today's FLOSS world. Cheers, -Barry signature.asc Description: PGP signature
Re: Really, ...
* John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de [121129 18:12]: This is actually a true valid point which I personally would accept as an argument against systemd. Without looking into the details, this seems to be something that can be fixed by a new upload, doesn't it? Almost any actual specific problem can be fixed with a new upload. Any reason given to believe that there will be problems left or that remaining problems will have a bigger impact are not probable with actual problems (because any actual problem usually can be fixed, or claimed to be a non-problem). I think noone claims that systemd would not be the superior design in a world where there is bug-free, perfect software prepared to handle every possible situation it will be thrown into. As our world has not yet seen bug-free software handling every single situation the authors did not think about properly, the expectation of what happens if one runs into a not-yet fixed bug is an important issue for many people. Free software has always been a way to avoid being helplessly at the mercy of some software. So handing over the basics of your computer to a much more complex system can be quite frightening for many people around here. Claiming that it will work for everyone and that anyone not being able to name a problem existing now has no arguments does not help. It only makes sure people are reassured that systemd is not for them. Combine that with vocal demands that it should be the only allowed init process in a short time frame makes sure that there is a big opposition (which will look for you like it has no arguments, as no real arguments against systemd are accepted.) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121129192240.ga16...@client.brlink.eu
procenv and buildd environments
The procenv utility [1], which provides information on the environment it runs in, is now available in Debian Sid [2] and Ubuntu Raring [3]. As part of its package build, 'make check' gets run which does the following: (1) Dumps information on the C pre-processor, compiler and linker. (2) Runs procenv itself. Step (1) is an aid to (2) in case it should fail. (2) is useful since it: - Helps to ensure the package works as expected once installed [*]. - Is a good check that procenv can handle 'odd' environments such as those provided by chroots (which are unusual in that their libc version often does not align with the provided kernel version). The readily accessible build logs for procenv itself ([4], [5], [6]) may in some circumstances help with FTBFS and test failure issues with _other_ packages since they provide an insight into the environment in which a package is built. Using the build logs, informative analysis can be performed: - See the environment a buildd provides. - Compare a 'normal' environment with a buildd-provided one. - Compare a Debian buildd environment to an Ubuntu one. There are other examples and ideas in the initial blog post and the man page. [*] - Note that procenv also has DEP-8 support such that the autopkgtest-provided environment can also be inspected [7]. The plan is to also enable Ubuntu PPA builds, again for comparative purposes. If anyone is interested in adding additional features to procenv, see the TODO and please let me know. Kind regards, James. [1] - https://launchpad.net/procenv [2] - http://packages.debian.org/sid/procenv [3] - http://packages.ubuntu.com/raring/procenv [4] - https://buildd.debian.org/status/package.php?p=procenvsuite=sid [5] - http://buildd.debian-ports.org/status/package.php?p=procenv [6] - https://launchpad.net/ubuntu/+source/procenv (expand version 'twistie' for build logs) [7] - https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-procenv/ -- James Hunt http://upstart.ubuntu.com/cookbook http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf -- 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/50b7b837.2080...@ubuntu.com
Re: Really, about udev, not init sytsems
On 11/30/2012 01:18 AM, Jon Dowland wrote: On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote: However, you are running Gentoo and rebuild your kernel, why would you bother with such thing as kernel modules and initrd? The thing is, many (most? all?) Gentoo user, as far as I understand (I'm not a Gentoo user), do not use kernel modules at all. In that situation, you'd be posting to gentoo-dev. We can ignore what happens to other downstreams of udev, however I don't think that's a good idea to do so. What makes you reasonably believe that if we had a Debian specific issue, it would be considered by actual udev upstream, and not publicly exposed? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50b7ba3f.2040...@debian.org
Re: Really, about udev, not init sytsems
On Thu, Nov 29, 2012 at 03:28:40PM +0100, Wouter Verhelst wrote: http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF the most recent processor you can find there was released in January 2012. Yeah, someone else posted this information already. How much are these instruction set compatible with the classical m68k processors? Would we be able to have an m68k port of Debian which runs both on the original m68k CPUs and the ColdFire series? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129195147.ga21...@physik.fu-berlin.de
Re: Really, about udev, not init sytsems
On Fri, Nov 30, 2012 at 03:40:47AM +0800, Thomas Goirand wrote: We can ignore what happens to other downstreams of udev, however I don't think that's a good idea to do so. Why bother other downstreams if they don't complain? I find it rather intrusive to post on the lists of other downstreams, trying to convince them that a particular choice of upstream was bad. I think the proper way should be to wait until the topic actually comes up itself among the other downstreams. As I said before, even the best upstream cannot always cover every single use case and you can turn it any way you want, Gentoo is definitely a very special and uncommon use case, so I can somehow understand that upstream cannot cover that. But again, you're free to fork the code and do whatever you want. You shouldn't just run around everywhere and try to convince the other downstreams that your particular use case is the one that has to be honored. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129195723.gb21...@physik.fu-berlin.de
Re: Really, ...
On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote: I think noone claims that systemd would not be the superior design in a world where there is bug-free, perfect software prepared to handle every possible situation it will be thrown into. Yes, but this is valid for any other software design. But I think systemd *does* a very good job in trying to cover every possible usecase because it was actually designed with modern hard- and software environments in mind, like embedded or big servers which weren't simply existant back when the original System V Init design was conceived. As our world has not yet seen bug-free software handling every single situation the authors did not think about properly, the expectation of what happens if one runs into a not-yet fixed bug is an important issue for many people. Absolutely. But again, this is true for any software and this is *especially* true for old designs which couldn't cover certain setups which simply didn't exist back then. You know the famous quote: 640 kB ought to be enough! Free software has always been a way to avoid being helplessly at the mercy of some software. So handing over the basics of your computer to a much more complex system can be quite frightening for many people around here. Yes, I see your point. But again, what I said before, how many people are actually digging into such low-level code? Someone who is jumping into kernel or plumberland development always has to have a certain background knowledge. It requires more skills and experience as opposed to writing desktop applications or smart phone apps. But do you really think that we should keep every part of the system brain-dead simple that everyone understands at the cost of reliablity and performance? I mean, how many people do actually really understand how the FireWire stack in the kernel works and is designed, how many people understand the underlyings of gcc and so on? I see your argument about keeping stuff simple, but again, if you want to be able to solve more complex tasks with your computer, the software on it itself has to become more complex. It's almost as if we should never add features to the kernel because it becomes too complex for newbies. I'm very sure Linus would flip everyone off who comes with this certain mindset. Claiming that it will work for everyone and that anyone not being able to name a problem existing now has no arguments does not help. Do System V Init or Upstart work in EVERY single use case? Do you know that systemd actually works much better with systems which have high load or are shared among many users (because it allows ressource control by using cgroups). You're putting the arguments the wrong way around. It is the old System V Init which actually covers only a very limited use case while systemd offers a much more flexible design, ranging from embedded stuff up to very big machines. It only makes sure people are reassured that systemd is not for them. Combine that with vocal demands that it should be the only allowed init process in a short time frame makes sure that there is a big opposition (which will look for you like it has no arguments, as no real arguments against systemd are accepted.) Yes, I do accept vocals against systemd, but only if these are actually valid arguments. Because I want software development to be driven on technical merits and not on sympathies against or for certain people neither the stance to reject any modern developments. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129201402.gc21...@physik.fu-berlin.de
Re: Really, ...
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Yes, I do accept vocals against systemd, but only if these are actually valid arguments. Because I want software development to be driven on technical merits and not on sympathies against or for certain people neither the stance to reject any modern developments. Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. But to the extent that we have to pick winners and losers (and, to be clear, I think it's premature to do that for init systems), I for one will always advocate taking social considerations into account as well as technical considerations. In the long term, they often matter more than the initial technical design. -- 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/87obigdutn@windlord.stanford.edu
Re: Canonical pushes upstart into user session - systemd developer complains
Vincent Lefevre vinc...@vinc17.net writes: It is more verbose, but I find it as readable (if you have characters that normally need to be escaped, you can still use CDATA sections, which is a way to keep the readability). So to keep everyone equally happy, we need: config ![CDATA[ [section1] key1=val1 key2=val2 key3=♬♫♩♩♫ [section2] foo=bar ]] /config Structure _and_ readability. -- Stig Sandbeck Mathisen -- 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/87wqx4dult@dagon.fnord.no
Re: Canonical pushes upstart into user session - systemd developer complains
On Thu, Nov 29, 2012 at 09:25:50PM +0100, Stig Sandbeck Mathisen wrote: Vincent Lefevre vinc...@vinc17.net writes: It is more verbose, but I find it as readable (if you have characters that normally need to be escaped, you can still use CDATA sections, which is a way to keep the readability). So to keep everyone equally happy, we need: config ![CDATA[ [section1] key1=val1 key2=val2 key3=♬♫♩♩♫ [section2] foo=bar ]] /config Structure _and_ readability. I wonder what the effect is of setting key3 to ♬♫♩♩♫ :D :D. Hilse fra Berlin! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129203902.gd21...@physik.fu-berlin.de
Re: Really, ...
* John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de [121129 21:14]: On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote: As our world has not yet seen bug-free software handling every single situation the authors did not think about properly, the expectation of what happens if one runs into a not-yet fixed bug is an important issue for many people. Absolutely. But again, this is true for any software and this is *especially* true for old designs which couldn't cover certain setups which simply didn't exist back then. But you have to understand that you put something that only does promises against something that exists. Something that exists means that people have experiences with it, now how it behaves, know how to debug it and now how to make it work again when it breaks. On the other side is systemd which has not yet been available in a single Debian release and could not yet prove itself anywhere. So if it would be proposed as some more init system to support or a cool new stuff to experiment with it, you would not get that much emotional reactions. But as people demanded making it the only available system before it could prove itself and while all most people know is that it is quite a different design which wants to solve all the problems at the same time (which often enough means it creates more problems than it solves) and that it has ties which other projects people have had no good experiences with (for enough people pulse-audio is a synonym of my sound is not working) you should have a different reaction than ridiculing people not wanting to bet their future on it. You know the famous quote: 640 kB ought to be enough! But I also know which happened to the 80286, which offered quite a lot more memory and many nice things like fine grained memory proection: It only looked nice on the paper but (with some noble exceptions) was just not worth the hassle, so that people prefered to stay with a 1 MB limit for many years to come. Yes, I see your point. But again, what I said before, how many people are actually digging into such low-level code? Someone who is jumping into kernel or plumberland development always has to have a certain background knowledge. It requires more skills and experience as opposed to writing desktop applications or smart phone apps. This is exactly the mindset that scares people away from systemd. An application that does not behave is no big problem. One can easily ditch it and replace it withanother. One has all the bells and whistles of your full desktop available while you debug it. It's all quite well understood. If your init system does not work -- and one day it will not work, there is no way that can be avoided, there is no perfect bug-free software out there and especially when the task is to cope with all possible hardware and their little quirks and timing problems, all the different combinations of services and daemons out there and so on -- you are set back much more. So if you end up in a situation like that, what do you do as user? Some will say oh, it does not work. Let's try to reinstall the machine and if that does not help let's try another distribution. Perhaps the next release in two years will work. Or perhaps what I wanted to do is not that important, so I will just not do that. But for many people that would not be a solution but the absolute nightmare. Being at the mercy of the computer; not being able to decide what your machine does and what not; being totally powerless and dependent on whether someone has decided that what you want to do makes sense or not. So being a more complex thing means it must be easier. Easier to understand what it does. Easier to understand why something does not work. Easier to fix it once it breaks. But do you really think that we should keep every part of the system brain-dead simple that everyone understands at the cost of reliablity and performance? Do you really not understand why people think that? And what does reliability mean if it can stop working and I can do nothing against that at all? I see your argument about keeping stuff simple, but again, if you want to be able to solve more complex tasks with your computer, the software on it itself has to become more complex. Strangely the complexity of the solution has seldom been related to the complexity of the problem and always been the opposite of reliablity in the past. So this is merely a false assertion. Claiming that it will work for everyone and that anyone not being able to name a problem existing now has no arguments does not help. Do System V Init or Upstart work in EVERY single use case? Actually, all my experiences with upstart has been when it does not work. And then it was always a pain to work with. So in my experience System V Init is quite superior to Upstart. And the big advantage of System V Init is that everyone can diagnose and fix it. Everyone knows how to add some echo
Re: Canonical pushes upstart into user session - systemd developer complains
On Thu, Nov 29, 2012 at 09:25:50PM +0100, Stig Sandbeck Mathisen wrote:
Vincent Lefevre vinc...@vinc17.net writes:
It is more verbose, but I find it as readable (if you have characters
that normally need to be escaped, you can still use CDATA sections,
which is a way to keep the readability).
So to keep everyone equally happy, we need:
config
![CDATA[
[section1]
key1=val1
key2=val2
key3=♬♫♩♩♫
[section2]
foo=bar
]]
/config
Structure _and_ readability.
Should be more like:
- item: |
config
![CDATA[
[section1]
key1=val1
key2=val2
[section2]
foo={bar: baz}
]]
/config
Structure, readability *and* flexibility.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
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/20121129213830.ga13...@decadent.org.uk
Re: debian-devel-digest Digest V2012 #1259
Sent from my HTC - Reply message - From: debian-devel-digest-requ...@lists.debian.org To: debian-devel-dig...@lists.debian.org Subject: debian-devel-digest Digest V2012 #1259 Date: Fri, Nov 30, 2012 4:47 AM 2012/11/29 Wouter Verhelst wou...@debian.org: glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Please, *DONT* :-) I've tired of this crap on illumos
Re: Canonical pushes upstart into user session - systemd developer complains
❦ 29 novembre 2012 17:58 CET, Roland Mas lola...@debian.org : And command-line tools? An editor with syntax highlighting? Other than that, I don't know of any, but do you really need it with ini? For a specific purpose, you could probably whip something up pretty fast with one of the libraries... For reading a value, there's confget(1). A tool to *set* a value in an *.ini file is three lines of Python that can be inlined in a shell script (it's been mentioned elsewhere in this thread). Or something like Augeas. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan Plauger) pgprG7b6MxLvc.pgp Description: PGP signature
Re: Really, ...
Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Yes, I do accept vocals against systemd, but only if these are actually valid arguments. Because I want software development to be driven on technical merits and not on sympathies against or for certain people neither the stance to reject any modern developments. Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. Systemd does much better than its competitors as a social activity. Neither OpenRC nor Upstart (with its highly questionable form of contributor agreement) can match systemd. You shouldn't confuse the existence of a group of vocal naysayers as the lack of a thriving community. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. I question the usefulness of this approach for init systems. Yes, developers do need a degree of familiarity to evaluate the merits of the systems. But personalized init systems don't make much sense; everyone deciding what works best for *them* is not a good approach. And when talking about a larger number of people and how well things work in their personal use in practice (as opposed to more in-depth technical evaluation), what matters is largely the amount of effort spent on polishing the most typical cases. Sysvinit has worked well for a significant number of people; but that's not because it wouldn't suck, but because a lot of effort has been used to paper over the problems. But to the extent that we have to pick winners and losers (and, to be clear, I think it's premature to do that for init systems), I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? -- 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/1354230001.1887.16.camel@glyph.nonexistent.invalid
Re: Really, ...
Uoti Urpala uoti.urp...@pp1.inet.fi writes: Russ Allbery wrote: Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. Systemd does much better than its competitors as a social activity. Neither OpenRC nor Upstart (with its highly questionable form of contributor agreement) can match systemd. You shouldn't confuse the existence of a group of vocal naysayers as the lack of a thriving community. You've made your opinion quite clear. Message received. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. I question the usefulness of this approach for init systems. No one is expecting you to help, so your statement that you don't think this activity is useful is just noise. One of the features of free software is that there is no need to concern onself with the (presumably billions) of people who *don't* want to work on something. Only the people who *do* want to work on something matter, provided that they include the resources to do the minimum amount of work required to coordinate this sort of flexibility. If we were asking everyone maintaining Debian packages to do something proactive to provide this flexibility, that would be another matter, but so far that's not been necessary. The work is largely isolated to those people who want to work on it, which makes the opinions of people who don't want to work on it uninteresting. Even if we all decided that systemd was the one and only one way to go, we would *still* have to develop init system flexibility in the archive in order to handle the transition. So we are *far* from any lost resources in the effort we're putting into this, and it's completely premature to pick a winner. I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I don't see any need to have a firm answer to that question at this time. The point is less about the amount of evidence required and much more about the fact that there's no reason to make this decision unless and until we actually need to as a project. We're not at that point. At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. -- 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/87zk20asr3@windlord.stanford.edu
Re: Really, ...
Hello! Uoti Urpala has written on Friday, 30 November, at 1:00: [...] I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I should thank you all, John Paul Adrian Glaubitz, and Uoti Urpala. I was wondered before if I should give systemd a try. Thank you very much, you've convinced me and now I know - I never ever have to give it even a small chance on any of my Debian systems. Thank you again. Andriy. -- 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/20121129233753.ga8...@rep.kiev.ua
Re: Really, ...
Andrej N. Gritsenko and...@rep.kiev.ua writes: Uoti Urpala has written on Friday, 30 November, at 1:00: [...] I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I should thank you all, John Paul Adrian Glaubitz, and Uoti Urpala. I was wondered before if I should give systemd a try. Thank you very much, you've convinced me and now I know - I never ever have to give it even a small chance on any of my Debian systems. So, I just laid into Uoti about this, and I should probably be symmetric. This isn't useful *either*. The whole point is that *we don't need to decide this right now*. The people who repeatedly advocate systemd on debian-devel are not representative of the whole development community. I suspect most of them aren't even *part* of the systemd development community. Rather, this is all further sign of a particular social problem in free software, namely the tendency to attach oneself to projects (whether that be vim vs. Emacs, GNOME vs. KDE, or systemd vs. upstart) as if they were sports teams, and then start behaving with all the public composure and mutual understanding of drunk football fans. Let's try to avoid that on *all* sides. It's just software. And software changes over time, and sometimes becomes much better (or much worse) than it is right now. It also forks and remerges, and the development community often changes radically. See, for example, glibc. This is, btw, *exactly* why I personally tend to switch desktop environments every couple of years. It's a lot easier to not villify a whole project when one has used it for a bit and can see that it has pluses and minuses, just like everything else. -- 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/87txs8asaz@windlord.stanford.edu
Re: Really, ...
On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote: No one is expecting you to help, so your statement that you don't think this activity is useful is just noise. One of the features of free software is that there is no need to concern onself with the (presumably billions) of people who *don't* want to work on something. Only the people who *do* want to work on something matter, provided that they include the resources to do the minimum amount of work required to coordinate this sort of flexibility. Correct. But if it means when a minority of people have a vastly different opinion on a certain matter and this opinion means extra work and redundancies, I think this is something that should not be persued. If we were asking everyone maintaining Debian packages to do something proactive to provide this flexibility, that would be another matter, but so far that's not been necessary. The work is largely isolated to those people who want to work on it, which makes the opinions of people who don't want to work on it uninteresting. Well, the choice of init system can have a huge impact on lots of packages. If we decide to use either systemd or upstart by default, we should ship all daemons with the appropriate unit/upstart files to make the most of these sysvinit replacements. Even if we all decided that systemd was the one and only one way to go, we would *still* have to develop init system flexibility in the archive in order to handle the transition. So we are *far* from any lost resources in the effort we're putting into this, and it's completely premature to pick a winner. As far as I know, at least ArchLinux and Fedora already made the full transition. According to a befriended Arch user I talked to today, their old rc system is completely defunct now. I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I don't see any need to have a firm answer to that question at this time. The point is less about the amount of evidence required and much more about the fact that there's no reason to make this decision unless and until we actually need to as a project. We're not at that point. Well, on the other hand, it's not a good thing to postpone this decision forever. Mandriva, openSuSE, Fedora, Arch, Frugalware and Mageia already made the full transition while we're still arguing over it. systemd also has by far more contributors than any other init system, so I think it's a sane decision to adopt the system which has the highest popularity and momentum. This will guarantee that *most* of our users will be happy (we can't satisfy everyone anyway) and the upstream code will always be maintained. At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. And for me, the most annoying thing is the neverending circlejerk of systemd bashing on a non-technical basis. If anyone of these people would really take the time to read into the design rationales of the available init systems (upstart, systemd, sysvinit, openrc), look at the popularity and the amount of contributors, the decision would be far easier to make. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121129234932.ga29...@physik.fu-berlin.de
Re: Really, about udev, not init sytsems
On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote: On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote: Well, systemd and udev are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. udev and pulseaudio are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Internet explorer and Windows are developed by the same company. Both interact very closely and integration of the two was the natural consequence. I'm not sure I agree with any of those arguments. Ok, I should have added that both udev and systemd are also very closely related. So there are certainly benefits of merging the code. Until their source repositories were combined, there was little close relation between the two. They might be more related now that they exist in the same git repo, but I remain highly sceptical of the technical and other benefits of this merge. A tool which is fundamentally geared to creating device nodes and other tasks related to that need not be tightly-coupled with /any/ init system. Even /with/ the merge, they still aren't that coupled, except to force them to appear so. Yes, it makes it more difficult to use udev with a different init system, but again most people don't care [citation needed] Well, it's obvious, isn't it? I mean, I am talking about the average joe. I didn't hear anyone complain when Apple switched to launchd in 10.4 and I have really never ever people arguing about what init daemon is the best until systemd came up. I can't get rid of the impression that the rejection of systemd is solely based on technical merits. Let's make one thing clear here. The argument about which system is the best or has the most features or is most modern, or whatever, is pointless. The Debian GNU/Linux system is used in many different ways, for many different purposes. There is not, and can never be, a one size fits all init system. file-rc, s6, sysvinit, upstart, systemd, and others all have their uses. None of them are suitable for all use cases, and each have use cases for which they are the optimal solution. The most important consideration is having an operating system which can meet the needs of our userbase. Retaining the flexibility to change init systems to suit those varied needs is a key part of this. Forcing our users to use the One True Init is not helpful, and reduces the flexibility and usefulness of the system, as well as hindering future development. Well, but I would say Ubuntu is to be blamed here. As opposed to upstart, systemd has many supporters and contributors in the industry (Intel, ProFusion, SuSE, RedHat) while upstart is virtually only actively developed by Canonical if am I not mistaken. Plus, you have to sign a contributor's agreement with Canonical which leaves a bad taste in my mouth. That shouldn't be the case with true free software, should it? Enough. None of this rubbish has anything at all to do with Debian. You've taken your fanboyish advocacy of systemd to a ridiculous extreme over the last week or so. Please tone it down. Nothing done in Debian has anything to do with any of the above companies, and if anything, having all those supporters and contributors attempt to ram systemd down our throats whether we like it or not counts against it rather than for it. Sure, I don't disagree on this point. But again, don't you think it makes sense to got into that direction when the adoption rate of a certain software is high? I mean, just look at the popcon numbers for systemd vs upstart: The popularity of the systems is meaningless. Neither are the default. upstart only became functional this last week. None of this has any bearing on anything. udev took quite some time to be accepted by the community too, but now it's probably fair to say that it has been. To try to couple that to systemd sounds like a bad form of systemd advocacy to me. Yes, I agree it leaves a bad taste for sure. But again, I am not so sure if we really need to be able to choose our init system. I mean, do we have this discussion over mdev vs udev? Or even devfs? Yes on all counts. Look very hard at what Wookey wrote. It's really quite important. Being able to swap out and replace the different low level components of our system is critical. These are just userspace components, not kernel interfaces. Replacing them should be relatively simple. If the new udev fork works, why /wouldn't/ we want to adopt it? It would have a friendlier upstream, it would be buildable without unwanted extra stuff, and it would have better future prospects. And it wouldn't be maintained by
Re: Really, ...
On Thu, Nov 29, 2012 at 03:43:48PM -0800, Russ Allbery wrote: The people who repeatedly advocate systemd on debian-devel are not representative of the whole development community. I suspect most of them aren't even *part* of the systemd development community. No. But I am using systemd both at home and work now and it solved many headaches I had before. I don't have to worry about messing with /etc/default anymore to enable/disable daemons, I don't even have to worry how to do that when using a different distribution. It works the same on Fedora, Arch, Debian, openSuSE, every distribution that uses systemd. I also don't have to worry about daemons dying unsupervised daemons, not noticing it until someone knocks at the door of the IT department to complain. Gone are the headaches we had with autofs only working 70% of the time or the /home NFS simply not being mounted on some machines after startup. I can quickly figure out why my system takes longer than usual too boot and I will immediately see when and why daemon xyz was restarted. Seriously, this is not based on religion, this is based purely on technical merits and good experiences with systemd. Rather, this is all further sign of a particular social problem in free software, namely the tendency to attach oneself to projects (whether that be vim vs. Emacs, GNOME vs. KDE, or systemd vs. upstart) as if they were sports teams, and then start behaving with all the public composure and mutual understanding of drunk football fans. Yes, there are these wars on actual software applications and these will definetely never stop, simply because the choice of a preferred editor or desktop is highly subjective. As for stuff in the plumberland, you don't see it most of the time, you just want it to be there and work reliably. And the concept and design of systemd has been already proven to be very reliable. Apple switched to the design (launchd) in 2004 in MacOS X and successfully uses it on any iOS device (iPhone, iPad, iPod touch) they're shipping. I never heard of any problems with regard to launchd. Let's try to avoid that on *all* sides. It's just software. And software changes over time, and sometimes becomes much better (or much worse) than it is right now. It also forks and remerges, and the development community often changes radically. See, for example, glibc. Absolutely true. And this is actually why I don't understand so many people get so emotional when it comes to software like systemd or Pulse-Audio. This is, btw, *exactly* why I personally tend to switch desktop environments every couple of years. It's a lot easier to not villify a whole project when one has used it for a bit and can see that it has pluses and minuses, just like everything else. I rather do that because I get bored from time to time, want to help find bugs in other desktops or I simply want to explore new stuff, to make sure I still have the best experience I can get. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/2012113433.gb29...@physik.fu-berlin.de
Re: Really, ...
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote: At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. And for me, the most annoying thing is the neverending circlejerk of systemd bashing on a non-technical basis. This is something that you're all (collectively) enabling via your behavior of constantly repeating the same arguments. Someone has to stop. Preferrably everyone at once. If anyone of these people would really take the time to read into the design rationales of the available init systems (upstart, systemd, sysvinit, openrc), look at the popularity and the amount of contributors, the decision would be far easier to make. This is the key point: WE ARE NOT GOING TO MAKE A DECISION RIGHT NOW. We simply are not. It doesn't matter how many messages you write to debian-devel, what arguments you muster, and what evidence you have: this decision will not be made right at this moment, in the middle of a release freeze, prior to completing the Policy work for even testing a migration to systemd. It's absolutely impossible that any firm decision will be made at any time before the wheezy release is complete. I think it's rather unlikely until we have a clear policy for how people should add systemd support in their packages and those package maintainers who chose to do so have started to enable it. (I think we're actually fairly close to such a policy, but it's not formalized yet.) Therefore, every time you continue to argue about this on debian-devel, the *only* thing that you are accomplishing is to feed what you accurately describe as a never-ending circlejerk, by providing it with more material, more ammunition, more fodder for the discussion to continue and continue and continue. This is all equally true of the people who hate systemd. It would also be true of the people who advocate upstart or OpenRC, except you'll notice that they've largely stopped discussing the topic except when they can't stop themselves from rebutting some specific technical point. That's wise. It's worthy of emulation. Please, let's *stop talking about this*, apart from the much more specific, straightforward, and *useful* discussion of what further work is required to enable those who wish to do so to run systemd as their init process in Debian. -- 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/87obigarbv@windlord.stanford.edu
Re: Really, ...
On Thu, Nov 29, 2012 at 04:04:52PM -0800, Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On Thu, Nov 29, 2012 at 03:34:08PM -0800, Russ Allbery wrote: At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. And for me, the most annoying thing is the neverending circlejerk of systemd bashing on a non-technical basis. This is something that you're all (collectively) enabling via your behavior of constantly repeating the same arguments. Someone has to stop. Preferrably everyone at once. Why should my chain of arguments change? If it constantly changed all the time, it would mean I'm not really having any arguments but I just want to win the discussion. This is not my point, I'm just trying to explain the sceptics that most of their fears are simply unjustified. If anyone of these people would really take the time to read into the design rationales of the available init systems (upstart, systemd, sysvinit, openrc), look at the popularity and the amount of contributors, the decision would be far easier to make. This is the key point: WE ARE NOT GOING TO MAKE A DECISION RIGHT NOW. We simply are not. It doesn't matter how many messages you write to debian-devel, what arguments you muster, and what evidence you have: this decision will not be made right at this moment, in the middle of a release freeze, prior to completing the Policy work for even testing a migration to systemd. Hey, you don't need to be yelling at me, I didn't kick off the discussion. I am perfectly fine with the current situation. And you don't need to enlighten me on the release policy, I am very much aware that we're in freeze. At no point did I say we have to decide something now. I merely said that we certainly shouldn't wait forever. Again, I didn't bring up the discussion, so please don't focus on me. It's absolutely impossible that any firm decision will be made at any time before the wheezy release is complete. I think it's rather unlikely until we have a clear policy for how people should add systemd support in their packages and those package maintainers who chose to do so have started to enable it. (I think we're actually fairly close to such a policy, but it's not formalized yet.) Yes, I am aware of the situation. Therefore, every time you continue to argue about this on debian-devel, the *only* thing that you are accomplishing is to feed what you accurately describe as a never-ending circlejerk, by providing it with more material, more ammunition, more fodder for the discussion to continue and continue and continue. This is all equally true of the people who hate systemd. Phew, I already feared I would have to take all the blame :). It would also be true of the people who advocate upstart or OpenRC, except you'll notice that they've largely stopped discussing the topic except when they can't stop themselves from rebutting some specific technical point. That's wise. It's worthy of emulation. I don't think there are particular people to blame. The unwillingness to stop discussing the topic comes from both sides. But as long as we treat each other respectfully, I still think it's ok to be discussed. It's not that I am not willing to learn. I'm always willing to give in with my argumentation if someone actually comes up with valid counterarguments (with what Harald Jenny said, for example). Please, let's *stop talking about this*, apart from the much more specific, straightforward, and *useful* discussion of what further work is required to enable those who wish to do so to run systemd as their init process in Debian. Sure, I would love to switch the topic :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121130002017.ga23...@physik.fu-berlin.de
Re: Really, ...
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On Thu, Nov 29, 2012 at 04:04:52PM -0800, Russ Allbery wrote: This is something that you're all (collectively) enabling via your behavior of constantly repeating the same arguments. Someone has to stop. Preferrably everyone at once. Why should my chain of arguments change? I don't want you to change your chain of arguments. I want you to stop repeating them constantly in debian-devel, thus prompting the people who disagree with you to constantly repeat *their* arguments, thus prompting you to constantly repeat *your* arguments, thus prompting me to want to reach through my computer screen and strangle all of you. :) This is not my point, I'm just trying to explain the sceptics that most of their fears are simply unjustified. Give up. Seriously. We've been having this conversation for, what, two years now? You're not saying anything that anyone hasn't already heard before. Words aren't going to convince anyone; everyone has a hardened position at this point who is going to form an opinion at all. And convincing people isn't required for any effective progress. Again, I didn't bring up the discussion, so please don't focus on me. I'm not, really. I originally replied to Uoti, and I've also replied to someone else on the other side of the argument. I'm only making these points in response to you because you're the one who replied. They're equally applicable to everyone on the systemd side of the discussion, and most of them are applicable to the anti-systemd side as well. I don't think there are particular people to blame. The unwillingness to stop discussing the topic comes from both sides. I agree with this. But as long as we treat each other respectfully, I still think it's ok to be discussed. Well, I'm not a list owner and am not going to declare it not okay in some sort of formal way, but as a personal contributor and reader to debian-devel, I am down on my knees here begging you to please stop discussing it. This discussion keeps taking over debian-devel and making the whole thing annoying and frustrating to read, and doesn't seem to be accomplishing anything at all. I really think this is a case where personal experience is going to speak louder than any possible argument, which is why I think the next step is to make it simple and documented to switch init systems and see how it works. You'll notice, for example, that Steve posted to his blog, and hence to Planet Debian, how to do this for upstart, and people are starting to experiment with systemd similarly. The next step is to start getting *voluntary* native coverage for either or both of upstart or systemd (or OpenRC, for that matter) from those package maintainers who feel like adding support. I, for one, plan on doing this for at least some of my packages for *both* upstart and systemd after the freeze is over, provided that there are simple, easy-to-follow instructions somewhere for how to write the appropriate configuration files. -- 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/878v9kapx6@windlord.stanford.edu
Re: Really, ...
Hello! John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04: Absolutely true. And this is actually why I don't understand so many people get so emotional when it comes to software like systemd or Pulse-Audio. Well, without any emotions. In last 2 years I've installed Ubuntu and Debian systems 7 times. 3 times sound just haven't worked. 2 times sound worked unstable from beginning. 1 time sound worked but I've got complain after a month that it sometimes ceases to work so they had to reboot the system. All those systems were fixed by deinstalling Pulse-Audio. Only on one laptop Pulse-Audio worked (unfortunately it has been stolen shortly so I cannot tell now if it worked stable). What I suppose to think about Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is the best, I will never trust you, I'm sorry but experience tells me just otherwise. With best regards. Andriy. -- 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/20121130004105.ga23...@rep.kiev.ua
Work-needing packages report for Nov 30, 2012
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 497 (new: 15) Total number of packages offered up for adoption: 138 (new: 0) Total number of packages requested help for: 64 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bio2jack (#694603), orphaned yesterday Description: oss/alsa to jack porting lib - development files Installations reported by Popcon: 131 glrr (#694115), orphaned 5 days ago Installations reported by Popcon: 72 glrr-widgets (#694116), orphaned 5 days ago Installations reported by Popcon: 57 gplcver (#694118), orphaned 5 days ago Installations reported by Popcon: 305 gsetroot (#694604), orphaned yesterday Description: a C/Gtk-based front-end for Esetroot Installations reported by Popcon: 125 idesk (#694605), orphaned yesterday Description: Program to show icons on the desktop Installations reported by Popcon: 344 langscan (#694120), orphaned 5 days ago Installations reported by Popcon: 37 libfam-ruby (#694566), orphaned 2 days ago Description: Ruby Extension for the FAM C library Installations reported by Popcon: 14 libimlib2-ruby (#694567), orphaned 2 days ago Description: Ruby Extension for the Imlib2 C library Installations reported by Popcon: 19 mousetrap (#694606), orphaned yesterday Description: A simple game of ball chasing Installations reported by Popcon: 54 njam (#694607), orphaned yesterday Description: pacman-like game with multiplayer support Installations reported by Popcon: 165 tomoe (#694117), orphaned 5 days ago Installations reported by Popcon: 11 vdesk (#694608), orphaned yesterday Description: manages virtual desktops for minimal window managers Installations reported by Popcon: 45 xzoom (#694609), orphaned yesterday Description: magnify part of X display, with real-time updates Installations reported by Popcon: 273 zatacka (#694610), orphaned yesterday Description: Arcade multiplayer game like nibbles Installations reported by Popcon: 62 482 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 138 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1032 days ago Description: maintenance tools for a Xapian index of Debian packages Installations reported by Popcon: 59703 asymptote (#517342), requested 1371 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 3878 athcool (#278442), requested 2956 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 69 balsa (#642906), requested 431 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 784 bastille (#592137), requested 845 days ago Description: Security hardening tool Installations reported by Popcon: 201 cardstories (#624100), requested 584 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 9 chromium-browser (#583826), requested 914 days ago Description: Chromium browser Installations reported by Popcon: 11025 cloud-init (#693094), requested 17 days ago Description: configuration and customization of cloud instances Installations reported by Popcon: 5 debtags (#567954), requested 1032 days ago Description: Enables support for package tags Installations reported by Popcon: 2521 doc-central (#566364), requested 1041 days ago Description: web-based documentation browser Installations reported by Popcon: 205 fbcat (#565156), requested 1051 days ago Description: framebuffer grabber Installations reported by Popcon: 152 flightgear (#487388), requested 1622 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 845 freeipmi (#628062), requested 553 days ago Description: GNU implementation of the IPMI protocol Installations reported by Popcon: 2052 gnat-4.4 (#539633), requested 1689 days ago Description: backport bug fixes from trunk (GCC 4.5) Installations reported by Popcon: 2122 gnat-gps (#496905),
Re: Really, about udev, not init sytsems
On Thu, Nov 29, 2012 at 11:51:12PM +, Roger Leigh wrote: On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote: On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote: Well, systemd and udev are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. udev and pulseaudio are developed by the same developers. Both daemons interact very closely and integration of the sources was the natural consequence. glibc and the kernel is developed by the same group of companies. Both interact very closely and integration of the sources was the natural consequence. Internet explorer and Windows are developed by the same company. Both interact very closely and integration of the two was the natural consequence. I'm not sure I agree with any of those arguments. Ok, I should have added that both udev and systemd are also very closely related. So there are certainly benefits of merging the code. Until their source repositories were combined, there was little close relation between the two. They might be more related now that they exist in the same git repo, but I remain highly sceptical of the technical and other benefits of this merge. A tool which is fundamentally geared to creating device nodes and other tasks related to that need not be tightly-coupled with /any/ init system. [...] That's what udev *was*, originally. Now it's a daemon that performs more or less arbitrary actions when various events are reported by the kernel. Which is more or less what a modern init system does, only restricted to a particular type of event. It makes a fair bit of sense to integrate all the events that may trigger service changes, without spawning a shell to pass each of the device events across. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20121130005146.gb13...@decadent.org.uk
Re: Canonical pushes upstart into user session - systemd developer complains
On 2012-11-29 18:08:05 +0100, Adam Borowski wrote: On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote: On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote: But it will in a UTF8 locale, Unfortunately the C locale is the only really portable one. Debian's glibc has C.UTF-8 always available these days. This seems to be Debian only, and not for the current stable. This is not OK for portable applications... until C.UTF-8 is made standard and widely adopted. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121130005612.gm5...@xvii.vinc17.org
Re: Canonical pushes upstart into user session - systemd developer complains
On 2012-11-29 21:25:50 +0100, Stig Sandbeck Mathisen wrote: So to keep everyone equally happy, we need: config ![CDATA[ [section1] key1=val1 key2=val2 key3=♬♫♩♩♫ [section2] foo=bar ]] /config Structure _and_ readability. No, you don't have the structure from the XML point of view. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121130005851.gn5...@xvii.vinc17.org
Re: Canonical pushes upstart into user session - systemd developer complains
On 2012-11-29 08:37:19 -0800, Kelly Clowers wrote: On Thu, Nov 29, 2012 at 7:23 AM, Vincent Lefevre vinc...@vinc17.net wrote: And interfaces in various programming languages? http://search.cpan.org/~shlomif/Config-IniFiles-2.78/lib/Config/IniFiles.pm At least for Perl, I can't see anything related to validation. BTW, how do you do nested blocks in .ini files? And command-line tools? An editor with syntax highlighting? No, I mean the equivalent of xmlstarlet, e.g. to extract / change values... The advantage of XML is that it is more common. [citation needed] ini is pretty darn common... I would guess that they might be about the same. XML is not just used for config files... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20121130011804.go5...@xvii.vinc17.org
Re: Really, ...
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Russ Allbery wrote: Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. Systemd does much better than its competitors as a social activity. Neither OpenRC nor Upstart (with its highly questionable form of contributor agreement) can match systemd. You shouldn't confuse the existence of a group of vocal naysayers as the lack of a thriving community. You've made your opinion quite clear. Message received. I think there are enough ways to measure things objectively that it's more than just my personal opinion. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. I question the usefulness of this approach for init systems. No one is expecting you to help, so your statement that you don't think this activity is useful is just noise. Would you expect anyone who thinks such activity is not useful to help with it? This would seem to lead to the absurd conclusion that expressing a negative view/evaluation of anything would always be just noise, regardless of technical arguments or anything else. I would consider the metadiscussion of what is an appropriate way to test/choose init systems to be meaningful. Even if it were not immediately relevant to practice, that wouldn't make it just noise. One of the features of free software is that there is no need to concern onself with the (presumably billions) of people who *don't* want to work on something. Only the people who *do* want to work on something matter, provided that they include the resources to do the minimum amount of work required to coordinate this sort of flexibility. This would be more applicable if I had been telling you exactly how you should go about adding support for init systems other than systemd. But I didn't. I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I don't see any need to have a firm answer to that question at this time. The point is less about the amount of evidence required and much more about the fact that there's no reason to make this decision unless and until we actually need to as a project. We're not at that point. There's no need for Debian to make a formal decision that will be set in stone no matter what. But what you said was that it would be premature to pick winners and losers for init systems. I don't consider it premature to pick systemd as a winner; there's a difference between keeping your options open and claiming that they're all still equal. You don't need to make a _final_ decision yet. But that does not mean it would be premature to say that it seems pretty clear what the decision should be. At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. This thread was started by an anti-systemd poster, not people advocating it. I don't see any justification for you to focus your blame on systemd *supporters*. Since you wrote this in a reply to me, I assume you meant that people advocating it to apply to me at least to some degree. The primary reason I wrote my original reply is that you made a misleading comparison between qmail (lack of working community) and systemd (working community, outsiders who complain). I can't see how you could claim that you're not significantly more guilty yourself of useless posting (or whatever your exact complaint is) than I am. -- 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/1354237847.1887.48.camel@glyph.nonexistent.invalid
Re: Really, ...
Uoti Urpala uoti.urp...@pp1.inet.fi writes: Would you expect anyone who thinks such activity is not useful to help with it? This would seem to lead to the absurd conclusion that expressing a negative view/evaluation of anything would always be just noise, regardless of technical arguments or anything else. If they haven't heard the evaluation, then it may be useful information for them. Once you've already communicated the evaluation and established that they don't agree with you, then yes, this is exactly true. This is a major feature of free software. It doesn't matter how many people think what you're doing is a bad idea as long as you don't need their help. You can go off and try it anyway. Usually, if it's a bad idea, that will become obvious anyway, and you may learn something in the process. Sometimes, it will turn out that you're right and other people are wrong. Either way, it's generally much more fun than arguing about it incessantly. It's just like a vim user going on about how horrible Emacs is. No one cares. The Emacs developers are going to keep developing on Emacs because they like Emacs. The vim developers are going to keep working on vim because they like vim. There are only a few places where there's any point in debating which one is better: when making a recommendation to a brand new user who has never tried either, and when for some reason we have to pick a winner. Believe me, if we get to a point where we need to pick a winner for init systems, you'll know, and it will be impossible to miss the discussion. Everyone will have plenty of chances to make all their arguments. As a bonus, they'll even be arguments that are current at that time and will be able to take into account anything that changes between now and then! And if we never do have to pick a winner, bonus! There's another big argument we will have avoided. There's no need for Debian to make a formal decision that will be set in stone no matter what. But what you said was that it would be premature to pick winners and losers for init systems. I don't consider it premature to pick systemd as a winner; there's a difference between keeping your options open and claiming that they're all still equal. Yes, it's been obvious for months that you think there's enough data to make a decision right now. But we're still not going to, and that isn't going to change just because you've stated your opinion for the 51st time. This thread was started by an anti-systemd poster, not people advocating it. I don't see any justification for you to focus your blame on systemd *supporters*. Consider it defocused and spread about widely. Really, I don't care who's been worse. I would like everyone to stop engaging in this pointless bickering. Since you wrote this in a reply to me, I assume you meant that people advocating it to apply to me at least to some degree. The primary reason I wrote my original reply is that you made a misleading comparison between qmail (lack of working community) and systemd (working community, outsiders who complain). You misread my message. I didn't compare qmail directly to systemd. I was using qmail among others to make a general argument against the position that social factors do not matter when choosing software. Given your reply, you apparently agree but find the social factors in this case debatable. That's fine; I find them debatable too, and am not interested in debating them with you (largely because I haven't formed a strong opinion). Apparently we're both vehemently agreeing that social factors are important, making this yet another pointless digression. -- 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/87sj7ram4s@windlord.stanford.edu
Re: Really, ...
Andrej N. Gritsenko wrote: John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04: Absolutely true. And this is actually why I don't understand so many people get so emotional when it comes to software like systemd or Pulse-Audio. Well, without any emotions. In last 2 years I've installed Ubuntu and Debian systems 7 times. 3 times sound just haven't worked. 2 times sound worked unstable from beginning. 1 time sound worked but I've got complain after a month that it sometimes ceases to work so they had to reboot the system. All those systems were fixed by deinstalling Pulse-Audio. Only on one laptop Pulse-Audio worked (unfortunately it has been stolen shortly so I cannot tell now if it worked stable). What I suppose to think about Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is the best, I will never trust you, I'm sorry but experience tells me just otherwise. I've looked at PulseAudio myself recently due to issues users reported with it. My view is that it's quite buggy, but there isn't much reason to blame Lennart for that, while creating the project does show sound technical judgment. On a general level, a high-level sound system like PulseAudio is necessary for general desktop use. I mostly use raw ALSA for my own playback, but that doesn't mean it would be fine as the default solution. From what I've seen of the PulseAudio code, it seems OK on a general level (I haven't looked at that much of it, but enough to debug a few different issues). Such a daemon was/is required, the general design looks OK, and nobody else has done better. So I think overall it should be taken to show that Lennart does know what he's doing. (The design is not perfect though - especially I think the client-side API could be easier to use without hurting functionality.) The people who claim just not using PulseAudio would be a fine alternative overall (on distribution level, rather than as a alternative working for certain users) don't know what they're talking about. However, current PulseAudio is still quite buggy. But I wouldn't place too much of the blame for that on Lennart (other than him not dedicating more of his time to polishing it). AFAIK he hasn't been involved much in its development for the last couple of years. And his past involvement is unlikely to be the explanation for not having better development later; other similar audio work doesn't seem to attract that many developers either - in fact some of the issues affecting PulseAudio users are due to problems at lower levels of the audio stack. -- 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/1354241767.1887.76.camel@glyph.nonexistent.invalid
Re: Really, ...
On 30/11/2012 10:16, Uoti Urpala wrote: Andrej N. Gritsenko wrote: John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04: Absolutely true. And this is actually why I don't understand so many people get so emotional when it comes to software like systemd or Pulse-Audio. Well, without any emotions. In last 2 years I've installed Ubuntu and Debian systems 7 times. 3 times sound just haven't worked. 2 times sound worked unstable from beginning. 1 time sound worked but I've got complain after a month that it sometimes ceases to work so they had to reboot the system. All those systems were fixed by deinstalling Pulse-Audio. Only on one laptop Pulse-Audio worked (unfortunately it has been stolen shortly so I cannot tell now if it worked stable). What I suppose to think about Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is the best, I will never trust you, I'm sorry but experience tells me just otherwise. I've looked at PulseAudio myself recently due to issues users reported with it. My view is that it's quite buggy, but there isn't much reason to blame Lennart for that, while creating the project does show sound technical judgment. On a general level, a high-level sound system like PulseAudio is necessary for general desktop use. I mostly use raw ALSA for my own playback, but that doesn't mean it would be fine as the default solution. From what I've seen of the PulseAudio code, it seems OK on a general level (I haven't looked at that much of it, but enough to debug a few different issues). Such a daemon was/is required, the general design looks OK, and nobody else has done better. So I think overall it should be taken to show that Lennart does know what he's doing. (The design is not perfect though - especially I think the client-side API could be easier to use without hurting functionality.) The people who claim just not using PulseAudio would be a fine alternative overall (on distribution level, rather than as a alternative working for certain users) don't know what they're talking about. However, current PulseAudio is still quite buggy. But I wouldn't place too much of the blame for that on Lennart (other than him not dedicating more of his time to polishing it). AFAIK he hasn't been involved much in its development for the last couple of years. And his past involvement is unlikely to be the explanation for not having better development later; other similar audio work doesn't seem to attract that many developers either - in fact some of the issues affecting PulseAudio users are due to problems at lower levels of the audio stack. Is it, really? I haven't noticed any major issues with Pulseaudio in the past couple of years running Ubuntu. That and sound has worked out of the box with all the Ubuntu and Fedora systems I've installed in the past couple of months. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Really, ...
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Would you expect anyone who thinks such activity is not useful to help with it? This would seem to lead to the absurd conclusion that expressing a negative view/evaluation of anything would always be just noise, regardless of technical arguments or anything else. If they haven't heard the evaluation, then it may be useful information for them. Once you've already communicated the evaluation and established that they don't agree with you, then yes, this is exactly true. I'm pretty sure I haven't said anything similar about methods of comparing init systems before. Note that I did not say it's not worth comparing because it's obvious that systemd would win anyway (that's probably true, but it's something that _has_ been said before). I talked about the limitations of such an approach without reference to any particular systems being tested. It's just like a vim user going on about how horrible Emacs is. No one cares. The Emacs developers are going to keep developing on Emacs because I criticized a proposed method to compare vim and Emacs. Not vim or Emacs. There's no need for Debian to make a formal decision that will be set in stone no matter what. But what you said was that it would be premature to pick winners and losers for init systems. I don't consider it premature to pick systemd as a winner; there's a difference between keeping your options open and claiming that they're all still equal. Yes, it's been obvious for months that you think there's enough data to make a decision right now. But we're still not going to, and that isn't going to change just because you've stated your opinion for the 51st time. Just to make it clear, I'm not arguing that Debian should make a formal decision right now. What I said was about technical evaluation, not formal decision-making. And here claiming that it's premature to make a technical evaluation is itself a claim about the situation, not a neutral position (saying that you haven't yet reached an evaluation yourself is a neutral position; saying that making an evaluation is premature is not). Since you wrote this in a reply to me, I assume you meant that people advocating it to apply to me at least to some degree. The primary reason I wrote my original reply is that you made a misleading comparison between qmail (lack of working community) and systemd (working community, outsiders who complain). You misread my message. I didn't compare qmail directly to systemd. I was using qmail among others to make a general argument against the position that social factors do not matter when choosing software. I think the message you replied to had little to do with a position that social factors do not matter when choosing software, especially social factors relevant to maintaining a development community as your reply talked about. It was about the relevance of there being outsiders who complain. So maybe I read your message differently than how you intended it - but I think that was pretty natural if your intent was replying to something that hadn't actually been said. -- 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/1354246066.1887.107.camel@glyph.nonexistent.invalid
Re: Really, ...
Chow Loong Jin wrote: On 30/11/2012 10:16, Uoti Urpala wrote: However, current PulseAudio is still quite buggy. But I wouldn't place Is it, really? I haven't noticed any major issues with Pulseaudio in the past couple of years running Ubuntu. That and sound has worked out of the box with all the Ubuntu and Fedora systems I've installed in the past couple of months. I looked into it because there had been complaints about issues related to PulseAudio from users, and I was able to quickly find and analyze several bugs with no prior familiarity with the code. I do consider myself better than an usual developer, and could probably find some bugs in most projects, but I think that's still pretty strong evidence against current PulseAudio being polished code. Here's an example of one of the nastier bugs: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=29f064aa3d3a83e275361aad3f9e7efdc84b8ad0 I first sent a patch fixing that bug. A PulseAudio developer then posted an alternative approach to fixing the issue a month later. Then nothing happened for 2.5 more months until the fix was finally committed. So I think bug fixing for known bugs is not working particularly efficiently either. -- 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/1354247198.1887.117.camel@glyph.nonexistent.invalid
Re: Maildir vs. mbox in Debian
On Thu, Nov 29, 2012 at 05:52:06PM +0100, Adam Borowski wrote: Outside of dpkg, sqlite in non-WAL mode, other databases and virtualbox/ qemu, btrfs is pretty fast. That may be true, but it glosses over how awful performance is on those workloads on btrfs. A single Berkeley DB transaction can literally take minutes. btrfs in its default configuration is completely unusable for any system that uses databases *at all*, which is essentially everything but tiny embedded systems. I won't even use it on /tmp. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Accepted webissues 1.0.4-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 08:55:03 +0100 Source: webissues Binary: webissues webissues-dbg Architecture: source amd64 Version: 1.0.4-1 Distribution: experimental Urgency: low Maintainer: Patrick Matthäi pmatth...@debian.org Changed-By: Patrick Matthäi pmatth...@debian.org Description: webissues - network system supporting team collaboration webissues-dbg - network system supporting team collaboration (dbg symbols) Changes: webissues (1.0.4-1) experimental; urgency=low . * New upstream release. * Bump Standards-Version to 3.9.4 (no changes needed). * Switch to xz compression and add a Pre-Depends on dpkg. Checksums-Sha1: 79485af750ef20d84a5fdec6254a6fd2ac92c6d1 1810 webissues_1.0.4-1.dsc 7c5f7da8c784b81178a1517d886a632179b37f2b 3292819 webissues_1.0.4.orig.tar.bz2 910ca17757cb630ae4951a184dd335f8a25b1657 7595 webissues_1.0.4-1.debian.tar.gz 97bc302f54ad46fc88a90ba8690789815571fa1c 2240156 webissues_1.0.4-1_amd64.deb d608b1134869e30b3e0b8cf94732a832c2a977fd 3470480 webissues-dbg_1.0.4-1_amd64.deb Checksums-Sha256: fd4f962d62947ec213e20f424c3a378b5c996922443344d9f4c09c4849ddebc5 1810 webissues_1.0.4-1.dsc c3ee591e3a1e719c3f78d2e08ca3115c340830fef02fc4d744c3cde62ec4e384 3292819 webissues_1.0.4.orig.tar.bz2 9f0a9f471c5cb3447f4975f91d1e35bf79aefaa4af0556834323bbae123fc5df 7595 webissues_1.0.4-1.debian.tar.gz d0cf2aad737babf7c480e5fa7636a629842bc32ea49b809660079dff0053e9b9 2240156 webissues_1.0.4-1_amd64.deb 6af5152694f92e5050beeeda56a7707b54cb68fda6100154bacd5abc41021aa8 3470480 webissues-dbg_1.0.4-1_amd64.deb Files: 83682f1bab03c73e6c267bd7968df337 1810 x11 optional webissues_1.0.4-1.dsc be6baccbf049c56759c4a963a4d8a20e 3292819 x11 optional webissues_1.0.4.orig.tar.bz2 9ad06f1c70cb602ebe943af4cb78aec4 7595 x11 optional webissues_1.0.4-1.debian.tar.gz e9878afe87ee56708a782c66043af188 2240156 x11 optional webissues_1.0.4-1_amd64.deb 318fb75b2dc6d8485ac2eb99becb8051 3470480 debug extra webissues-dbg_1.0.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQtxY/AAoJEBLZsEqQy9jkQ8sP/ijBNP8GIeeb2JsWeHJaoNfl Ffgewg+jo101shXdaiT13EjRtQRSr7O1BZdSGHwrt1PUZvSIcLWZNBjoJRiyPn6q 02fDl5tpVW15gz/Bg6+32rIpylGEny2lUvXCoCK/wUAtsJDmASEmBrTSo3XGfGEZ mK154IxDMxq361FzJbUn3pc89oXjeiLZ0NEcvfjA+zvpUbZvRrsq1Cb1t9YbsU5O r8LuVno6+kwwKLKCa3PaegM+sdfhq5mHWJhihVyuMlrE/ndFNdNSTAP+scb1wRxS FSiF4oyM3fAdJkkMus/W3rveShMa+l+IBkgu+siVahZMNv5JITlUgIKN8i5rgU2M r+RtsBxjW01PJ4c51HWeBK0eA5WMrmRw23xU2Y4EZDMfJIAVqiWawvw0sf+pKlQU JRmlvoU0Bunu610BGDbihPaq/DCtEmrf153FORY740XjB6sdzZO/ZxGcIctBME6z aUMA7K+q3R3b1ieb/9fkyVRfGyfC9yilTrBgyWguDPpp53pt0WcUUhfd1RweTWwE 1wShujbnFS0YH2Rh1hoO7q+GSCLtEOnaFyd8b6GJl35fA15V6kHEt5FOWBXEwaem n22aPvdjW3ooKbJaoCIwvyT/0mrGB5BiwuTI4L9b0b/5WM6DmmccMNIM6OxOhF0Q KKLCU0XjioIbIwRdoK2C =4RdF -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/e1tdznc-0003cl...@franck.debian.org
Accepted php5 5.4.9-2 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 08:48:24 +0100 Source: php5 Binary: php5 php5-common libapache2-mod-php5 libapache2-mod-php5filter php5-cgi php5-cli php5-fpm libphp5-embed php5-dev php5-dbg php-pear php5-curl php5-enchant php5-gd php5-gmp php5-imap php5-interbase php5-intl php5-ldap php5-mcrypt php5-mysql php5-mysqlnd php5-odbc php5-pgsql php5-pspell php5-recode php5-snmp php5-sqlite php5-sybase php5-tidy php5-xmlrpc php5-xsl Architecture: source amd64 all Version: 5.4.9-2 Distribution: experimental Urgency: low Maintainer: Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: libapache2-mod-php5 - server-side, HTML-embedded scripting language (Apache 2 module) libapache2-mod-php5filter - server-side, HTML-embedded scripting language (apache 2 filter mo libphp5-embed - HTML-embedded scripting language (Embedded SAPI library) php-pear - PEAR - PHP Extension and Application Repository php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-enchant - Enchant module for php5 php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) php5-gd- GD module for php5 php5-gmp - GMP module for php5 php5-imap - IMAP module for php5 php5-interbase - interbase/firebird module for php5 php5-intl - internationalisation module for php5 php5-ldap - LDAP module for php5 php5-mcrypt - MCrypt module for php5 php5-mysql - MySQL module for php5 php5-mysqlnd - MySQL module for php5 (Native Driver) php5-odbc - ODBC module for php5 php5-pgsql - PostgreSQL module for php5 php5-pspell - pspell module for php5 php5-recode - recode module for php5 php5-snmp - SNMP module for php5 php5-sqlite - SQLite module for php5 php5-sybase - Sybase / MS SQL Server module for php5 php5-tidy - tidy module for php5 php5-xmlrpc - XML-RPC module for php5 php5-xsl - XSL module for php5 Changes: php5 (5.4.9-2) experimental; urgency=low . * Introduce new (hopefully slightly smarter) way of not deleting still used session files Checksums-Sha1: 4e77f803df9353866e81002860cb20aedd96049b 3722 php5_5.4.9-2.dsc e84fc337ff4ee1bb943fa65efff7851d8f537681 147454 php5_5.4.9-2.debian.tar.gz 2b57fc1795abc7a4a8dc31953496b27ba16eafaa 594538 php5-common_5.4.9-2_amd64.deb f3d77e73bf088909306721ea4ebde8a9d7408439 2672606 libapache2-mod-php5_5.4.9-2_amd64.deb 31c263ac9466bb89458d6f5ae2f57d67eb8d5726 2671000 libapache2-mod-php5filter_5.4.9-2_amd64.deb 07c78320fda7ce5b1c46b1f98c562d92595c2911 5111788 php5-cgi_5.4.9-2_amd64.deb 1b70b73f731285897b4526efdcd79abf70f4a190 2561934 php5-cli_5.4.9-2_amd64.deb 512689a25c572967d6f5f056ab5d64bff4cda316 2596212 php5-fpm_5.4.9-2_amd64.deb 30330b94aadc8734fa63dfb93242c73be0464016 2668972 libphp5-embed_5.4.9-2_amd64.deb ad5701f55c3c88b0b7d1ae1f1906177803d6d9f6 498366 php5-dev_5.4.9-2_amd64.deb 1fa8398942f13abfb0c2d63e3c92fb9ace7cd872 16004624 php5-dbg_5.4.9-2_amd64.deb ade5c8d9b18e4aa992b588bf560c7e514cd9d4b5 29294 php5-curl_5.4.9-2_amd64.deb 4eebf0dcf9eea26a4532f59549c76d5b7c4a8042 9932 php5-enchant_5.4.9-2_amd64.deb 2ac6371eb3b2fbc1d0d04cc6dd95c7c667287bfa 35698 php5-gd_5.4.9-2_amd64.deb 50a4b6a6882e761bb485b6bbbaa35b5d7d67b49a 17150 php5-gmp_5.4.9-2_amd64.deb 70980c84b0444ff989f3aeca077c97082bf578e3 35592 php5-imap_5.4.9-2_amd64.deb 21bf37cd19f41e7b23ff270992fa4e44aab24943 49598 php5-interbase_5.4.9-2_amd64.deb ceabd2ede81daa3940ceafa35084e0f613e5637a 72722 php5-intl_5.4.9-2_amd64.deb ac477c98f28ec768f278222a414f3bc45f3e1ba0 21748 php5-ldap_5.4.9-2_amd64.deb 8aa12d0ca98bfecb5ccc00be56209567b228bd86 16068 php5-mcrypt_5.4.9-2_amd64.deb 177497bdc3a23efc45d4ab3d9f8382494e2cd659 80870 php5-mysql_5.4.9-2_amd64.deb b5016f3d07b2e054869afbcd9aad2168ecaa4bcb 163510 php5-mysqlnd_5.4.9-2_amd64.deb 2eb1846f6f40b15d5368075b3e98bf829c5dc85a 36672 php5-odbc_5.4.9-2_amd64.deb c5c0253909902b9c9a163766aa0c614fe81e3a1b 61548 php5-pgsql_5.4.9-2_amd64.deb 2ae3f65cf586d2d655bf5d78715dfe5cecd0aba8 8890 php5-pspell_5.4.9-2_amd64.deb 92028b6ee10943394cd066a0dee857a2d75b8212 5184 php5-recode_5.4.9-2_amd64.deb 9ad6da212cbebcbe5a885774712b7f1752728fab 21800 php5-snmp_5.4.9-2_amd64.deb b4d51b31a8ce547a57b0179672e7c008e1ceb06b 30440 php5-sqlite_5.4.9-2_amd64.deb 9556327e7c41cfd5bbed0daf2c20253b20d31164 28176 php5-sybase_5.4.9-2_amd64.deb b0fa10ca621254d67f6a8b36980c31938cb31b1a 19586 php5-tidy_5.4.9-2_amd64.deb 6c21171ea45ee74e719f006361224ce3a37600d9 36282 php5-xmlrpc_5.4.9-2_amd64.deb 057208d484291def1702372d0e9f469b34027524 15408 php5-xsl_5.4.9-2_amd64.deb b4e92399ca09e66f9c07b3c377a83730b2dd4007
Accepted erlang-cowboy 0.6.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 01:23:54 +0900 Source: erlang-cowboy Binary: erlang-cowboy Architecture: source amd64 Version: 0.6.1-2 Distribution: unstable Urgency: low Maintainer: LeoFS maintainers team pkg-leofs-de...@lists.alioth.debian.org Changed-By: Nobuhiro Iwamatsu iwama...@debian.org Description: erlang-cowboy - Cowboy is a small, fast and modular HTTP server written in Erlang Changes: erlang-cowboy (0.6.1-2) unstable; urgency=low . * Update debian/control. - Fix Homepage field. - Add erlang-proper-dev to Build-Depends. * Update debian/rules. - Add override_dh_auto_test target. - Add override_dh_auto_clean target. * Add patches. - Fix build with installed rebar package. - Fix test error by dependency of make. Checksums-Sha1: 85f5a1e7b258e65db43d797c85c377f470df81df 2138 erlang-cowboy_0.6.1-2.dsc c76ffbb94af6590cdb8db196d3441f30d9a9f79a 6807 erlang-cowboy_0.6.1-2.debian.tar.gz fc2d59d39781cb779ece2ac803261915d5bcd884 247190 erlang-cowboy_0.6.1-2_amd64.deb Checksums-Sha256: 2a48f53aa76212619c114e86588a3a8a328bcbe244f001885aae7fab0d4fc86d 2138 erlang-cowboy_0.6.1-2.dsc c91c6e224d109034aa01afa9c49a486ffc708907d8cfad6332eb853bcbcb1c3e 6807 erlang-cowboy_0.6.1-2.debian.tar.gz 5e11683f44cda109caec64839541a44f597fa45928a696568c3216011a9f 247190 erlang-cowboy_0.6.1-2_amd64.deb Files: 042ba6fc5d1fef6c353c627b6a648c7d 2138 devel optional erlang-cowboy_0.6.1-2.dsc 766470dcdbf7e3e2febe17d78707c990 6807 devel optional erlang-cowboy_0.6.1-2.debian.tar.gz 6092cebd07505c82d4326946352fb299 247190 devel optional erlang-cowboy_0.6.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQtvWGAAoJEDIkf7tArR+mFF4P/R8IG/mNpfKnVJloE/t5mEWB Sg67jLooTF/cP0yopvQ0cN4yE8x8qJdd0guij9f0/vwsuJpFJ5A7rM2oUGSylu9d z1+M03zQZRiVMdQNTwTYeECT8B7hc5MG1MKUFoxWwZLA8iFJjiKLM8Kj13UCliFo DIhhObbRm9EsjzWNsEB0Wm/oG1TY2yo8XT/IIuTJ29mJWccPHp+uPa5G/KLRBsDf 7d98rsu/Xdkhvd9DEUorI7MeNS0uVxI6ZXnNbHlnHksAk5l/0Bs7qqEDVkzGkxiy HeE1E01fZc4kc2t5blI8cXRVuyOTivD/9+1cOoKXNSNKFUafI70iyCWlNhSN/7Ld 91nwtM/86+Gb2ZJ4RZqN9jGXRulQ0w5L+hxVGc1FdJgej+TBe1EzEyQFAC79OzCn 1zSjUJKDqB41DIwWoRCVG5AkUVBwc7AmWh5xKGPLFfgEn97TFel5DGCX0ysDKeNn 9/f94FG85DAqdShXeTWk/IFx+rbNyL+lH2we/5WhgWk4f5AYx2vuS22Jq3bmMUR9 NpytSynWU11QSnnP1sjlal405THTICP0rf6jXfMyEerBV4U8WCGopyYvIZrRXo0q Zi6dCSg5q9uab/WD56a8ewFtXflCqnfewvphrnfn14mf1awv3/KlVL2KuawOJKzf jStbe37ofJ6UbLtng6c2 =05tf -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/e1te0fm-0005rr...@franck.debian.org
Accepted libapache2-mod-fcgid 1:2.3.6-1.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 18 Nov 2012 18:33:32 +0100 Source: libapache2-mod-fcgid Binary: libapache2-mod-fcgid libapache2-mod-fcgid-dbg Architecture: source amd64 Version: 1:2.3.6-1.2 Distribution: unstable Urgency: low Maintainer: Tatsuki Sugiura s...@nemui.org Changed-By: Tobias Frost t...@coldtobi.de Description: libapache2-mod-fcgid - an alternative module compat with mod_fastcgi libapache2-mod-fcgid-dbg - debugging symbols for mod_fcgid Closes: 691929 Changes: libapache2-mod-fcgid (1:2.3.6-1.2) unstable; urgency=low . * Non-maintainer upload. * Fix mod_fcgid: requests with chunked encoding have no body available to FCGI backend: Applied upstream patch (Closes: #691929) Checksums-Sha1: 9a0afbc606afa5751440136e3d5e85b721d79906 1993 libapache2-mod-fcgid_2.3.6-1.2.dsc e4f37309b3a1df1348dd26f37aea8ebab05eec17 6176 libapache2-mod-fcgid_2.3.6-1.2.diff.gz 0e982098cd843f9150dde2d80aad3f8503920ca0 74704 libapache2-mod-fcgid_2.3.6-1.2_amd64.deb c759c0f564bc62acba40d3373b122f2e29e379a2 13960 libapache2-mod-fcgid-dbg_2.3.6-1.2_amd64.deb Checksums-Sha256: fc94ef91c2addef809ea874e245dc5f0085219f9a72d42e368d3ea524565aec1 1993 libapache2-mod-fcgid_2.3.6-1.2.dsc da8abd17ad837867b6f34be3c4b95c363c6e749b0ebfa7e65a7a7642659d49c2 6176 libapache2-mod-fcgid_2.3.6-1.2.diff.gz 5300781460bb01d9d79875beb803d82237571a61d97195fdbc3bf9639f3d76e3 74704 libapache2-mod-fcgid_2.3.6-1.2_amd64.deb 4f297fa78ebe3b362a2300bf91c45c910bdbd3982f54d1498f8316138cdbce39 13960 libapache2-mod-fcgid-dbg_2.3.6-1.2_amd64.deb Files: 2f08d9e77f0b59fc0bb27367167384fb 1993 httpd optional libapache2-mod-fcgid_2.3.6-1.2.dsc 2e8ea83fde22351b03160eaafaf1bc5e 6176 httpd optional libapache2-mod-fcgid_2.3.6-1.2.diff.gz 2375cb3618dd93c15a1bbbd468d04b75 74704 httpd optional libapache2-mod-fcgid_2.3.6-1.2_amd64.deb 40ae4781e6cd216dbd4b455c23695984 13960 debug extra libapache2-mod-fcgid-dbg_2.3.6-1.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQqfjGAAoJEBLZsEqQy9jkAtUP/3rvMdMn9tVS8xbf5TOWfLA3 3SBypGz9ZtAFH3CGxLdpogd5dnpO9o3V/G6cjxkv0Tre5H0GMiQvu5ZH32MxaTbZ A9/AVCC8ZlKK2Cd82ylKSiEF7KnvqOOWnSPkvesoY35ikyFO5fuUm5AgWSkN8YQO SrMoT2spJ8XzZFR2eG7x7YFTpGxYdvQNzDDYnd+0X9502rLKl9lQueuJiHnNyi0q fqDhWv8rZR+xlgzYppLFG9QlCPjNlfoXakQWiiALCr6cAlojcNOwmrRL3zlLL6uB 1IFs4B+rvrGGb51no5XFygxmod09dRSTuh4ld0GGUTIwD3LlvcUVNIpewnXeD6Kj 7gFZ++QuzzRp0LaamORCBIy/cXQUryD2koO+e3QlEXr6wRmZCHN8pjOvajAkx84D Bdhkc4r5c+QX/I3vz7u4Btp5JBYsuLqCKWH0h5MvMYwtXcclePUKem88+xQlypNa c/wpvCSP7yn572GuhH3YAtv0Zem6EWaP0Cc7tQeZyRzOZkKbb+Vzb7qsySW69FAg OAbeBdAZBE59sBdVpFr9Nq7IwzhJNQTdauRI6D/TcB8VQ3e0KK9nERTBDp56s8Si J52+uxCxd/R5AwP7lrhO6cr9mrnme4Xl6Tz2TyrGHFhR2SiptEfy2KlclRlFYSkk Xle3rl5XNwbVgzh2iBVn =Wvrl -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/e1te0x2-0005ml...@franck.debian.org
Accepted midori 0.4.3+dfsg-0.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Nov 2012 17:33:35 +0900 Source: midori Binary: midori midori-dbg Architecture: source amd64 Version: 0.4.3+dfsg-0.1 Distribution: unstable Urgency: low Maintainer: Ryan Niebur r...@debian.org Changed-By: Koichi Akabe vbkaise...@gmail.com Description: midori - fast, lightweight graphical web browser midori-dbg - fast, lightweight graphical web browser (debug symbols) Closes: 645191 Changes: midori (0.4.3+dfsg-0.1) unstable; urgency=low . * Non-maintainer upload * Repack to extract waf script (Closes: 645191) * debian/waf-unpack - add to describe how to extract waf script * debian/rules - add get-orig-source target Checksums-Sha1: d6d6716bb7590bbc3fdb5c0d89a6f8cc4eec82c2 2385 midori_0.4.3+dfsg-0.1.dsc e79c87460f2eb97ee00133bdc5ee223b95dd1d59 911965 midori_0.4.3+dfsg.orig.tar.bz2 c1f77289c1525a4147f49020d0e564a40602a4ca 15596 midori_0.4.3+dfsg-0.1.debian.tar.gz 9ba60ab8c3b74496b7ffa8f43560845ebb43b556 1166896 midori_0.4.3+dfsg-0.1_amd64.deb 2f1a19ea9026d8136c7fda4666173520a74dd022 1318666 midori-dbg_0.4.3+dfsg-0.1_amd64.deb Checksums-Sha256: 1eee39df9b4723a234579cd2be4ccc8055743e627fc004998d5b15e45bd7b7aa 2385 midori_0.4.3+dfsg-0.1.dsc 601580c112a1bf7b9c0b51c46a44399f7a335b434275b2567acdcfdc6c35cd9c 911965 midori_0.4.3+dfsg.orig.tar.bz2 288ec7f92d77ff5e7f01f8fc4ec5c19a6e4dbb7c48777d578f178c064fa0 15596 midori_0.4.3+dfsg-0.1.debian.tar.gz 86a9aa321fe4546b6d5ea5dbc399657f4085f02124479fed876b2502877d1877 1166896 midori_0.4.3+dfsg-0.1_amd64.deb 8674ff8caf01aff1cc8ad5f35c7ea3b2e4cc0d81586d82d37d1b298c25e7945c 1318666 midori-dbg_0.4.3+dfsg-0.1_amd64.deb Files: 256b4825eda065b49618b5d4fcb82d2f 2385 web optional midori_0.4.3+dfsg-0.1.dsc f54f51e87a9d5bbbd341d33d6fcac12d 911965 web optional midori_0.4.3+dfsg.orig.tar.bz2 ae76ec40a98d3a096a0c8751220f99a4 15596 web optional midori_0.4.3+dfsg-0.1.debian.tar.gz 231528d629519ee14fc03da29ef6b583 1166896 web optional midori_0.4.3+dfsg-0.1_amd64.deb 760ddf993cf2b9994308e167aa5b6a2f 1318666 debug extra midori-dbg_0.4.3+dfsg-0.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQsJh+AAoJEHg5YZ3UOWaOI0sQAIat3AcU0iapKOb5qgqP8QH/ Ped7jqZDQX9Nyns5smkxBR88So1JosgtnyYmsxGOFbb4nsvi1is1A8DcLuAJ5epP gRGJ+iu5oJxSShy/Br/SUMfPLpxxyXRj/1WYe+wxFjfiWvtXDnUgLO7ldljZ7iox 5ZPQP/KJ0YMbIJtXIScL0VIYsDM+8CpSMcXpPE7uznfyDTDUHltL53zVS3n32ZNw JR/fXZhHZfHvlDdLnmx5bkkvbYWZcYm2SQrkLkliJYGb+Qq43Ptx8YnGO4jzoUh4 gAfH0ZZ7cK1/qdvdkRSQQvU+xSNsJJhByfo6QIHp2/+4RIvYY0iE/Kvja9zrUscI yKRzQtcbrAq1gyZNkF+C6KNZIJ+TujaPu/bFdo+X1dvH7mzj89lMgxMwfpEtyXaa 2Z9d8E8UCivgGGSu+A6bDRaVVj7W5GA7O0NwB9m8nR394rShuompMB6l2MSvPHI1 ERN+eA9fGnLDSPtO4X2eicUIauMasSOMByusPys7VoV5+J8TdI/WFlmqgE9OuIci TgCMKu2TVrPZpXJppe9b5N24FD8Wa5OJYdU5nCMPluZdmlQOJSXuP+w/mWzDdxYJ xXpcuBCBDk9jlmMJa08m0mmva9qP01k+raymb8obmNHr4r6FmVKq/vLBSufAjjzS BYcmlSM+WkAjbIVVCsea =CT01 -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/e1te1bu-0001uw...@franck.debian.org
Accepted procenv 0.15-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2012 20:44:41 + Source: procenv Binary: procenv Architecture: source amd64 Version: 0.15-1 Distribution: unstable Urgency: low Maintainer: James Hunt james.h...@ubuntu.com Changed-By: James Hunt james.h...@ubuntu.com Description: procenv- Utility to show process environment Closes: 694627 Changes: procenv (0.15-1) unstable; urgency=low . * New upstream release that includes fixes to tolerate clock resolution query failures seen on Hurd (Closes: #694627). . procenv (0.14-1) unstable; urgency=low . * New upstream release. . procenv (0.13-2) unstable; urgency=low . * debian/tests/make_check: Removed as not required since autopkgtest already runs 'make check' automatically via dh_auto_test as part of its setup phase before the DEP-8 tests are run. * debian/tests/run_installed: test added to run the installed version of procenv. * debian/tests/control: Removed everything aside from specification of new run_installed test. . procenv (0.13-1) unstable; urgency=low . * New upstream release. . procenv (0.12-2) unstable; urgency=low . * Added DEP-8 autopkgtest support. Checksums-Sha1: 124dc5a03a1ec82f90f4b87269d4bdc7ca827a9d 1759 procenv_0.15-1.dsc bd3a9d8786209243935860165797611034f29b50 206537 procenv_0.15.orig.tar.gz 7370af2892d2144030f48d56077b27fe5ea7887b 2809 procenv_0.15-1.debian.tar.gz 02e195e4780b254c393a1c78ecdcf17e5826c1ba 36706 procenv_0.15-1_amd64.deb Checksums-Sha256: ef06c1bc6bb8cf68d956dd89bcf9588b7a9d6bf3a561c3f4ed1cacd07ab64680 1759 procenv_0.15-1.dsc eba6f5aa0dcc8de7d5543096bcb66a83d2f84cc10b462a77b0b98d714f10ebf3 206537 procenv_0.15.orig.tar.gz 598b8d427e437ceea689b33a0cf34e5d08cc5592a127a8fbf807598066bc46d5 2809 procenv_0.15-1.debian.tar.gz 66d0b9505644c5480b236d243486b6dacb7a55cfbddab2891e43ebf3da52b67e 36706 procenv_0.15-1_amd64.deb Files: 5c9d3f1ddc5a38c65710d1ef41879688 1759 utils optional procenv_0.15-1.dsc 9fc42241a348f4033de0e498499f8dbc 206537 utils optional procenv_0.15.orig.tar.gz d31310af4f9a7aa65dfc079231f47ddf 2809 utils optional procenv_0.15-1.debian.tar.gz 09dc236d50689dfb60d739c17f036afc 36706 utils optional procenv_0.15-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJQtzPXAAoJEIh7YGGLPBaub6sQAK3aFzRuDNIj0q5WUk2orb/7 HuTgNtgnvTbKR9rddzDR+ZLC70TvZoSXdXa0qD6lnK1bHd7Cx8Sc5AoUmZrGhRZc FIQHL2D8+YDnJxO7tN3jbMxAmq9S0g4zHPb3dINqOanjwe4Lh8lRFWEUEqPvAKeu /Awt2u3IkrjGeAbruYrT1Jh96yY0cpjdRN0L+lY1L1fi/eHq4hKzNt1lnZsglXlw QhejAtp8l0PcbZ0MuMXOaGSi1W0Uh6u08j15e4+hedPLyMCYFW1KH5YoVadG++qY Y03Tw1xmFTndztPEprrtfQVwmGKUTfYcLwK0C7+ODyB7yKeEFdo3zBANhK8zwtpc 4Evw318TAda+EutQoTAWQfRtfw+wwjo+zBXpdp0zb+dF2zIgDiIjZMzQgKzcE8cr 2/ZBcPua3vU92PNtGBSxD+hXe8MFh9RjzdVp0kuSGqllByk25hS7OgF7Od1Vr5nh +O9mc7S8dImhc4iwTkTRslhEYHGXol0A4/rD5GoSc1loJOptGU5betYWK5kG9vDJ ePyEUf+znvoDLfcqVzEGzrTjU/5x06bpKMpRE+L9w0doHQi82RGXCOyy5lS3oR33 9lz/zyO7gz9QG/+iUWRs4U5YPqWhcy/3mSEPjVmPYpNGaX4rvmO1QLsqRiROdXB4 TEWldISxPJpyk3Fqw09H =1z4D -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/e1te1bz-0001yl...@franck.debian.org
Accepted cups-filters 1.0.25-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2012 20:14:07 +0100 Source: cups-filters Binary: libcupsfilters1 libfontembed1 cups-filters libcupsfilters-dev libfontembed-dev Architecture: source amd64 Version: 1.0.25-1 Distribution: experimental Urgency: low Maintainer: Debian CUPS Maintainers pkg-cups-de...@lists.alioth.debian.org Changed-By: Till Kamppeter till.kamppe...@gmail.com Description: cups-filters - OpenPrinting CUPS Filters libcupsfilters-dev - OpenPrinting CUPS Filters - Development files for the library libcupsfilters1 - OpenPrinting CUPS Filters - Shared library libfontembed-dev - OpenPrinting CUPS Filters - Development files for font embed libr libfontembed1 - OpenPrinting CUPS Filters - Font Embed Shared library Changes: cups-filters (1.0.25-1) experimental; urgency=low . * New upstream release - urftopdf: Newly added filter to convert the URF format which (at least some) iOS apps send when printing via AirPrint (Upstream bug #1076). - pdftopdf: pdfautorotate functionality has been patched directly into pdftopdf (LP: #1040037, Upstream bug #1080). - pdftopdf: mirror produced only empty pages (XObjects not there). - pdftopdf: Fixed segfault on page-ranges=1-2147483647 (from cups). - pdftopdf: Fixed collate filler insertion. - texttopdf: Fixed deficient string escaping (Upstream bug #1071). - serial backend: Added check for sys/ioctl.h to configure.ac (Upstream bug #1069). * debian/patches/texttopdf-fix-deficient-string-escaping.patch: Removed fix backported from upstream. * debian/rules: Added DEB_DH_FIXPERMS_ARGS := -Xusr/lib/cups/backend to not correct the permissions of CUPS backends (LP: #1076786). Checksums-Sha1: ac9cc24ad29e2d1b111b3bbd5a6abc287171a9c5 2636 cups-filters_1.0.25-1.dsc be8a9bc94f11725d6a0a4afd5814d4334d8fda96 1150349 cups-filters_1.0.25.orig.tar.bz2 fa413dcfb9959c95ece546324c3bc3db5f3d333f 41298 cups-filters_1.0.25-1.debian.tar.gz f56a48a567ca510d922a9ce3def6df3819b243fc 83668 libcupsfilters1_1.0.25-1_amd64.deb d0751d959e7f910e5175360dcf11471051c69e5a 57318 libfontembed1_1.0.25-1_amd64.deb e15f6f9f7a0277c0af4e98d9ba5fbbb603af3bc8 365320 cups-filters_1.0.25-1_amd64.deb cd808d521fc9f37414f2565f4d2aa39694883810 93764 libcupsfilters-dev_1.0.25-1_amd64.deb 76e69a91a8352d0dce724d74153372614ee09e0b 62634 libfontembed-dev_1.0.25-1_amd64.deb Checksums-Sha256: ec2b80442cd0a0bfb1fc12e041fa49a504ae9e7cf4a633ad80b0f923183b3132 2636 cups-filters_1.0.25-1.dsc 5908f3c20095d07045074c347149e7b43f99b402f454dc942c86cc1ebe04fdab 1150349 cups-filters_1.0.25.orig.tar.bz2 70ae849cc819e94d511b89c6578b8438486077d7e588441dc88380d1ab8d 41298 cups-filters_1.0.25-1.debian.tar.gz 0140dbfbd3cc8d553dcd81b15daeb5181d3fc88014144e0be935349ba893288d 83668 libcupsfilters1_1.0.25-1_amd64.deb 5bc99c8e69b1a1cf5fcf013bb8448247e5d18ae7b578aed2120437a13c79190e 57318 libfontembed1_1.0.25-1_amd64.deb 9446392e3ff696cdd1f2090ca455474182ce06c88116146085f4a1d37969ec79 365320 cups-filters_1.0.25-1_amd64.deb bd79b338d5b618f12b52b9b75aabc3c8b9995fda59c3c9297d0f0dfc6a005786 93764 libcupsfilters-dev_1.0.25-1_amd64.deb 826065a57e6e682d6c0a2c22ab1edd40029d95c5fa76abb86ed9d5db70196dfe 62634 libfontembed-dev_1.0.25-1_amd64.deb Files: c40e8b36d15b9a599dddb742a6b52dca 2636 net optional cups-filters_1.0.25-1.dsc 695c168f9dd4591196ccde8ffacd054b 1150349 net optional cups-filters_1.0.25.orig.tar.bz2 254f36a435738ce3bd05e6863e878a6d 41298 net optional cups-filters_1.0.25-1.debian.tar.gz 309caf74ed97670c2f8ce06defaf945c 83668 libs optional libcupsfilters1_1.0.25-1_amd64.deb 1c527e9736eed428bdf20d5ca482a89e 57318 libs optional libfontembed1_1.0.25-1_amd64.deb d2cd4fb2a3ea5189c08f5404775f1bd9 365320 net optional cups-filters_1.0.25-1_amd64.deb 7441bc2fb421ab44635c909913147d2c 93764 libdevel optional libcupsfilters-dev_1.0.25-1_amd64.deb aad9094430d6ec7f7b08f3959c451759 62634 libdevel optional libfontembed-dev_1.0.25-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJQt0ZFAAoJEPmIJawmtHuf6FYP/1FA8gQdgBcA55TEmLfU89zk FBMKKI242DioyfE5ohXZkLlbXgzZ1sRUgIHkkimtBZznm6WsrLB9tLJf33BWdUyb rc03YbJkYZP+wTluIPR6TVOMeA2abtwhJRoNUfnnT2jevMX6VcI0PAcnAkN/OwcY u26e68UeQoXfpNJwmiGVW1jo+OWnSJnRkX7DpuAsJPLyJPkbZVVG05Wwf7iMQdEX bucI/BRAKKjtxfAwNBDzVpcwOqqSoqKot2zvMBVJyUav3UZ7Z8Nz5ny4pByvsr8A KCfNhUVnlDOuvuOQzAe0QYEOQY9QOriXUxKWORdfhiRCrPxUZUnlACK15a4GQkNW vA7DEnbrQZhiItD/R7KoeBB8Tx0mGp53UsfiAO4Ri4lE0kZKNYLXEeMKvDqZZfjG Eny61VhKl8PSOwE00Ns1eNkUGzTu0yM9RNA2OKk9Gqatu9DLsa9mU4QK8nzPeuzH SHnca0X94Pt+iz9msdajVYOmwozoz9GEHfEl4iTclF1zEmZMehemrj6emSCVvQmt gURtbKiacboBmhhvoGp+GwawJzA0WaEuifpNO0UGfcirgJWVOCzxMy+uKyhWWh6w x9GxVIZa2aqQqWPsSnwebig8fmm2KaTsZj9lA/7BlzSLgosNIuJ/OnmHpgDxtrR/ tam6r95CTHBCJAgeqWLT =dAhl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of
Accepted herold 6.0.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 13:00:52 +0100 Source: herold Binary: herold Architecture: source all Version: 6.0.3-1 Distribution: unstable Urgency: low Maintainer: Debian XML/SGML Group debian-xml-sgml-p...@lists.alioth.debian.org Changed-By: Mathieu Malaterre ma...@debian.org Description: herold - HTML to DocBook XML conversion Closes: 689309 691170 692543 692544 692545 692547 692741 692756 693214 Changes: herold (6.0.3-1) unstable; urgency=low . * New upstream. Closes: #692544 * option --logging-level was removed. Closes: #691170 * preserve lang attribute. Closes: #692543 * Fix herold help output. Closes: #692545 * pdftohtml support (detect-trapped-br=false to revert). Closes: #692741 * Fix invalid XML element. Closes: #693214 * Remove d/p/antencoding.patch, applied upstream * man page is provided. Closes: #689309 * Fix herold.home location. Closes: #692547 * Support section element. Closes: #692756 Checksums-Sha1: 6c817dfcb2e75c10be77de4ff2ea4cdeb1334953 2129 herold_6.0.3-1.dsc e86da044f8d13c76be646f97ea6f85558966282f 202700 herold_6.0.3.orig.tar.gz 79e75e740d209277f31f50c0760eded51197f20d 16177 herold_6.0.3-1.debian.tar.gz ca3f28e61570ce9b37251ba5ebea395415deade2 459316 herold_6.0.3-1_all.deb Checksums-Sha256: 095435019500a1c3bc74f98f0cc35b90960b28461e2035deb38be6149fd1bd53 2129 herold_6.0.3-1.dsc 8abfaa4fb560f38d09d6d8bbdc37e1a0a62bd668a68a810c6d76a3d4a26d57af 202700 herold_6.0.3.orig.tar.gz cf47b9198ab3927719844d6b18fa98a9449c0f8b9e036aa381e7fe90fda34fd0 16177 herold_6.0.3-1.debian.tar.gz 7e1ee759750baea9e6e8d480e4893c640019624775def603ce73313b719c6922 459316 herold_6.0.3-1_all.deb Files: bd0e2e9a0c5be03ce2b199de769a8066 2129 java optional herold_6.0.3-1.dsc 32835ab1b73ea6286ab5d15f0e0649c0 202700 java optional herold_6.0.3.orig.tar.gz 80c668b907f5ef3a3ecfbc5ebd00618c 16177 java optional herold_6.0.3-1.debian.tar.gz 321b81267cf0b698340eb8da4f21a693 459316 java optional herold_6.0.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJQt1o6AAoJEAFx4YKK4JNFif8P/2djOkbC/tK/h5oKh9fWHPkz QEzOMHm+SD6jsPdaY6mgwHgKGjzcc6oucc+dJwxtHnFiXTRH8wQH9G05z2t0pI0N 5yZT4zTlARvyoKXcb3WiyKuzWDg63niyKuBXdZ4ULUl+FYx7M1rKCl4An7fJTh17 nlZZsJdvSOohFKyix7ZhsFisU2RZX/AscSNsAVd2p/Z/sX7iHWHsetyVVu1099wj cB+1jvP7iXgW+cwqZxY8Olo8ZIGj/9FduSEZj0KRZXqP9RRYrsD3+47+jkb53rLx PARc3kdvEaxAmnKf+bbNJZyphfz8R0zduMBBe09C5kuEBNM7fQQtm/IktI6Nm15c NTd3Skg17tL3BYlzF16BLLsz/n/a6UY3ufyECwCzPv5uvNx4CApc15kmlN1/IGx/ SbSA105TlDQludA8xA9qKxjeNsFLJM80R8QchpZUs9nwFK50uRr+adWvFjv4WaYz 3XqY9ZPbSoND85Wq4pcAnmC/T52+UxL9eOm027AvSYvm1KG930UAD/xkR/DE099N +UxoqDhcFzg65JuTC8GtSufKYndIKRfc9SW75QfCB2APEF394Z+yDn3jfyLCNWw5 7CrA53QoBjb2wKLgnXpKr3LVGCXMoHKLpMjf89RtVcxz/hwE2zvYpYC3CsI8xlkr YH6oS4RoQg5Ne4raU8m+ =VocK -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/e1te3l7-00088d...@franck.debian.org
Accepted mesa 8.0.5-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2012 22:09:14 +0100 Source: mesa Binary: libgl1-mesa-swx11 libgl1-mesa-swx11-dbg libgl1-mesa-swx11-i686 libgl1-mesa-swx11-dev libxatracker1 libxatracker1-dbg libxatracker-dev libgbm1 libgbm1-dbg libgbm-dev libegl1-mesa libegl1-mesa-dbg libegl1-mesa-dev libegl1-mesa-drivers libegl1-mesa-drivers-dbg libopenvg1-mesa libopenvg1-mesa-dbg libopenvg1-mesa-dev libgles1-mesa libgles1-mesa-dbg libgles1-mesa-dev libgles2-mesa libgles2-mesa-dbg libgles2-mesa-dev libglapi-mesa libglapi-mesa-dbg libgl1-mesa-glx libgl1-mesa-glx-dbg libgl1-mesa-dri libgl1-mesa-dri-dbg libgl1-mesa-dri-experimental libgl1-mesa-dri-experimental-dbg libgl1-mesa-dev mesa-common-dev libosmesa6 libosmesa6-dev libglu1-mesa libglu1-mesa-dev Architecture: source amd64 Version: 8.0.5-2 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force debia...@lists.debian.org Changed-By: Julien Cristau jcris...@debian.org Description: libegl1-mesa - free implementation of the EGL API -- runtime libegl1-mesa-dbg - free implementation of the EGL API -- debugging symbols libegl1-mesa-dev - free implementation of the EGL API -- development files libegl1-mesa-drivers - free implementation of the EGL API -- hardware drivers libegl1-mesa-drivers-dbg - free implementation of the EGL API -- driver debugging symbols libgbm-dev - generic buffer management API -- development files libgbm1- generic buffer management API -- runtime libgbm1-dbg - generic buffer management API -- debugging symbols libgl1-mesa-dev - free implementation of the OpenGL API -- GLX development files libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules libgl1-mesa-dri-experimental - free implementation of the OpenGL API -- Extra DRI modules libgl1-mesa-dri-experimental-dbg - Debugging symbols for the experimental Mesa DRI modules libgl1-mesa-glx - free implementation of the OpenGL API -- GLX runtime libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime libgl1-mesa-swx11 - free implementation of the OpenGL API -- runtime libgl1-mesa-swx11-dbg - free implementation of the OpenGL API -- debugging symbols libgl1-mesa-swx11-dev - free implementation of the OpenGL API -- development files libgl1-mesa-swx11-i686 - Mesa OpenGL runtime [i686 optimized] libglapi-mesa - free implementation of the GL API -- shared library libglapi-mesa-dbg - free implementation of the GL API -- debugging symbols libgles1-mesa - free implementation of the OpenGL|ES 1.x API -- runtime libgles1-mesa-dbg - free implementation of the OpenGL|ES 1.x API -- debugging symbols libgles1-mesa-dev - free implementation of the OpenGL|ES 1.x API -- development files libgles2-mesa - free implementation of the OpenGL|ES 2.x API -- runtime libgles2-mesa-dbg - free implementation of the OpenGL|ES 2.x API -- debugging symbols libgles2-mesa-dev - free implementation of the OpenGL|ES 2.x API -- development files libglu1-mesa - Mesa OpenGL utility library (GLU) libglu1-mesa-dev - Mesa OpenGL utility library -- development files libopenvg1-mesa - free implementation of the OpenVG API -- runtime libopenvg1-mesa-dbg - free implementation of the OpenVG API -- debugging symbols libopenvg1-mesa-dev - free implementation of the OpenVG API -- development files libosmesa6 - Mesa Off-screen rendering extension libosmesa6-dev - Mesa Off-screen rendering extension -- development files libxatracker-dev - X acceleration library -- development files libxatracker1 - X acceleration library -- runtime libxatracker1-dbg - X acceleration library -- debugging symbols mesa-common-dev - Developer documentation for Mesa Changes: mesa (8.0.5-2) unstable; urgency=low . * Fix regression in 8.0.5 (spurious GL_INVALID_ENUM errors): mesa: test for GL_EXT_framebuffer_sRGB in glPopAttrib(). Thanks to Simon Chopin for the report. Checksums-Sha1: 83913ce0528736a1aca8874e00106ea95f0c28f7 4423 mesa_8.0.5-2.dsc 1d4cdf011d2fe0db7a5427a9315b30e4c2a0abe8 59829 mesa_8.0.5-2.diff.gz ed68c63f9207b2b1e617a755c84d9319ca35bdd0 954180 libgl1-mesa-swx11_8.0.5-2_amd64.deb 6c29d37030d10d1254ef0fb66e48490b53775f13 2908282 libgl1-mesa-swx11-dbg_8.0.5-2_amd64.deb 3f12a11362eb24b5ca6f3e230ee8b9262b9fa1de 1107566 libgl1-mesa-swx11-dev_8.0.5-2_amd64.deb 16947d20197aa94555e84a82f59967d91e6dcec8 2922082 libxatracker1_8.0.5-2_amd64.deb 859795e7fb9a9181441650c8b7965b899f1c91f7 1439014 libxatracker1-dbg_8.0.5-2_amd64.deb caa2287b89bbfb59adf097a97d27c207a0ce5148 35078 libxatracker-dev_8.0.5-2_amd64.deb 505c8f0ffb129be9beb55921177712ef2cb8c51f 9787230 libgbm1_8.0.5-2_amd64.deb 4b1a28b9d7f88494ae0c424bd086669fe869bca4 4310968 libgbm1-dbg_8.0.5-2_amd64.deb dbdec40828738ab39197ce8cb963b37580874c23 33548 libgbm-dev_8.0.5-2_amd64.deb c416555aea8a358d2876c3c55d609ae535a6d086 78576 libegl1-mesa_8.0.5-2_amd64.deb
Accepted im-config 0.19~pre1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 00:14:56 +0900 Source: im-config Binary: im-config Architecture: source all Version: 0.19~pre1 Distribution: experimental Urgency: low Maintainer: Osamu Aoki os...@debian.org Changed-By: Osamu Aoki os...@debian.org Description: im-config - Input method configuration framework Closes: 694446 Changes: im-config (0.19~pre1) experimental; urgency=low . * Fix for programs stared by dbus by moving exporting of environment variables earlier. Closes: #694446 Checksums-Sha1: 4bacc553af5991b07f4abba07a582a8cf82fb308 897 im-config_0.19~pre1.dsc d2fba9c6ac13402762fdeb5473cde46536848ca4 32629 im-config_0.19~pre1.tar.gz 151c62814432d8e04753cfb01f0520c511db8feb 36228 im-config_0.19~pre1_all.deb Checksums-Sha256: 751c84a69643d5ba0ff11845353a3dbb1a7fcfbfe76c0cd8ad2ef905d72940fe 897 im-config_0.19~pre1.dsc a24f44ead89f35b27d13fac977a0a0ff80865ef6d1ab0e607ccb78a42f83b34e 32629 im-config_0.19~pre1.tar.gz a756e6a00b88848ddf36f9d0c8a78034564f8052e92c43e06088d53cc005a318 36228 im-config_0.19~pre1_all.deb Files: c03b1f5935f16cb767a88fd477c9057a 897 x11 optional im-config_0.19~pre1.dsc 7dce6858846e8c2fdbe4e812cac62f67 32629 x11 optional im-config_0.19~pre1.tar.gz 04d55ec809146a56746e11bc404e3604 36228 x11 optional im-config_0.19~pre1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlC3ZswACgkQ6A/EwagGHzKNawCeI0MHkXsMeqlDsyilT4DlRjvm KSYAnAzoMHe+UVThWRnJR2qKX8lmL83a =1a2t -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/e1te5on-0007vc...@franck.debian.org
Accepted trafficserver 3.3.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 22:13:55 +0800 Source: trafficserver Binary: trafficserver trafficserver-dev Architecture: source amd64 Version: 3.3.0-1 Distribution: experimental Urgency: low Maintainer: Arno Töll a...@debian.org Changed-By: Aron Xu a...@debian.org Description: trafficserver - fast, scalable and extensible HTTP/1.1 compliant caching proxy se trafficserver-dev - Apache Traffic Server Software Developers Kit (SDK) Changes: trafficserver (3.3.0-1) experimental; urgency=low . * Upload upstream development release to experimental. Checksums-Sha1: 7a72e6954255fd3a82b4dcc3889817ecb85dde15 1872 trafficserver_3.3.0-1.dsc eba3f36faf356b1535874fbe5313d508968c6f56 2674573 trafficserver_3.3.0.orig.tar.bz2 73aa94d46ef56051143657386dbc299bfe725656 16922 trafficserver_3.3.0-1.debian.tar.gz e2546a4b38cd40bad9397c6fc3b32ad1712e1eff 3803096 trafficserver_3.3.0-1_amd64.deb 2949978051ed557b6b64c7d26e3f86b5b4b781a5 434978 trafficserver-dev_3.3.0-1_amd64.deb Checksums-Sha256: b2a5b16e749584d9fc660cbac45a98661307a3d95bdab1353ef7923e779d8e82 1872 trafficserver_3.3.0-1.dsc 6d967abd04778aa5dcadb17455095f9540da7df2dad5e725a233d56404a29261 2674573 trafficserver_3.3.0.orig.tar.bz2 287f519c1a9af85b03732e9490a4c540fc4bbede16aecbdf875ceaddaf177fe0 16922 trafficserver_3.3.0-1.debian.tar.gz 7b42dc693b867ce7558c4bb2dc2510fe5c762069e991b2e850964ac3b6daabbe 3803096 trafficserver_3.3.0-1_amd64.deb cc9eb7d8706d3e5a39f5c8eaec64776bee1698820be67acbb5a35eec43d0c413 434978 trafficserver-dev_3.3.0-1_amd64.deb Files: a9d0b51fa9db99a3f9c78c9e3493dd28 1872 web extra trafficserver_3.3.0-1.dsc f7093a419f5f4a9a7da360076747 2674573 web extra trafficserver_3.3.0.orig.tar.bz2 062eed27a75c7a647efea173d2e489b5 16922 web extra trafficserver_3.3.0-1.debian.tar.gz 1b68b172f2cc5f41ed96ce6d7ecb5d9c 3803096 web extra trafficserver_3.3.0-1_amd64.deb 35ce460157f1adcda12da878b3865df1 434978 web extra trafficserver-dev_3.3.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQt3KuAAoJEIAhAkTu07wNulgH/0Ahl+wyXDEja3U1yMA8+N3q trjreoHHvzgAx+GOtzZ4m0OTyAQoFOI+APp7ol5Y03+Aaw8TJ5fBaLO1MVnZdsRL 06MmO6ydwWZ8UNq4UFdCBXdHoKxbd7VO+upvCvhvxHPBbFgUMTNyYPySfhlm7Iqk pGgfjFGzFSp6CSvu8tpkN0dotmmY0Ynteb1fN5+PkZlNHbpmHY7REoP0JjkMiMfx tvkw8H2PocxgbDAScw7AHkDKtBI766obZwaBVdmyxOyBLgghSG/US+AYJy4M2olI 35LWiludAZ1Mh0bS87qtVDAd5okfaMecqe3Zk3yY+x5O5COXyGfnJWV8LkoS7nU= =fs8B -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/e1te5sd-gi...@franck.debian.org
Accepted python-django-social-auth 0.7.10-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 15:56:19 +0100 Source: python-django-social-auth Binary: python-django-social-auth Architecture: source all Version: 0.7.10-1 Distribution: experimental Urgency: low Maintainer: Janos Guljas ja...@debian.org Changed-By: Janos Guljas ja...@debian.org Description: python-django-social-auth - Django social authentication made simple Closes: 694647 Changes: python-django-social-auth (0.7.10-1) experimental; urgency=low . * New upstream release. (Closes: #694647) * debian/control - Bump standards version to 3.9.4. - Update description. - Remove version from python-all Build-Dependency. - Raise debhelper dependency to 9. - Change my email address. * debian/compat - Raise debhelper compatibility level to 9. * debian/copyright - Update copyright years. - Change my email address. Checksums-Sha1: de6e4ac2c2dc04321774d1121db5824d10cd6f7f 2194 python-django-social-auth_0.7.10-1.dsc 139b928db4d422837fe14f23e384db1d492a8373 53577 python-django-social-auth_0.7.10.orig.tar.gz 0db15e701d7298d01f55de9ef8213a14c2de6cdc 2844 python-django-social-auth_0.7.10-1.debian.tar.gz 2c3f25293356759f42385aab3aad6ab5976fabcb 58776 python-django-social-auth_0.7.10-1_all.deb Checksums-Sha256: 4441eee9c99e2f992663e017794581f75dcc0843c0fca6d363ad7bfd464e49a0 2194 python-django-social-auth_0.7.10-1.dsc 1ce0911af179f72810752cec48dadd0d2747ca89b775b5005012ba89dd98dc62 53577 python-django-social-auth_0.7.10.orig.tar.gz aff042332c4cc5441efbc05e5fab4efc9a21297dbbb76a51fe1e17da3e937f37 2844 python-django-social-auth_0.7.10-1.debian.tar.gz e3fa53a8988791b3bc91ce2423a6cd4abf6430687df8fa57a48c74650294a215 58776 python-django-social-auth_0.7.10-1_all.deb Files: 5e58b1d349f23d28635ccc3ba71f22e9 2194 python extra python-django-social-auth_0.7.10-1.dsc 67c6673270bd63b910a475dfc614211a 53577 python extra python-django-social-auth_0.7.10.orig.tar.gz 3ec483839db09c5e53ac310d82c2a4ac 2844 python extra python-django-social-auth_0.7.10-1.debian.tar.gz 5aa11b06c02569ed2d19c0354a96d071 58776 python extra python-django-social-auth_0.7.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt3j+AAoJEJ5QnJPSbfnT7rEP/j1lIclVyzawQ9FJRo7UOmw8 KHjk2uET8RutDAJAue3Hco731rOrzVouvsf2+KMxGnpsuwiZV8btJDkB4nrAZqli kYEicAz/mCh2ZmE/xEFSzBPZRcE9uS9QT+/X8Nq775GYtBYxWHDF7SmKxiRVlppj S8KI1r+2XUUgkQR5K9EAsjhp8lkKtVzdb3cPsrs4P/GoaO/RAWZA0UXTvRJ8X3JD kPKWdPF4UPb39Msfv2jrcRsdBYL7ACOY6BBXaQ+Q0XXUhK922MdSbEKohVugJIpZ gvWQdiHyPdelJ0ySI14gAWx+W30kM53bOKmVZWLxFCDDcsdZSurd4U0q3za7m2nB dYZ5zhCN827k0/NP+ZNJumcNxVtxhNchX1GBFQWVfFrs4JCVvNcpqN/dWvKiyrX8 Fwi8ZVhW344KgBQdRmpM4SeI3LxUF++QETFJFhwmYaWWsMPctAQqbtHPz+t6YGz1 36Vizev1cDa96T4XqSaXQnSFJZkp42oS+wuTFTBGErdfm56GjAsmqeQixx3cs2Ca XKKwyByXM2hUFkVmnhvNGD0QS6s2FarhIauPJ9TvjJqHMB1HCuUbR7tIhz7b/cgw ALa3BqOZm8GmLLy2IR8xRnXWj/WHOMAZsVHWQaYeuoo+4g63XZJIpUVIvA0fJDjP encVpsmHb4MZA3/IpwQg =gXCu -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/e1te5s5-0007vb...@franck.debian.org
Accepted mdp 3.3+git6-g7bbd889-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 21 Nov 2012 10:19:15 +0100 Source: mdp Binary: python-mdp python3-mdp Architecture: source all Version: 3.3+git6-g7bbd889-1 Distribution: experimental Urgency: low Maintainer: Tiziano Zito opossumn...@gmail.com Changed-By: Tiziano Zito opossumn...@gmail.com Description: python-mdp - Modular toolkit for Data Processing python3-mdp - Modular toolkit for Data Processing Changes: mdp (3.3+git6-g7bbd889-1) experimental; urgency=low . * New upstream git snapshot * Introduce coarse_limit to trigger switching to fine_g before reaching target limit * Upload sponsored by Yaroslav Halchenko Checksums-Sha1: ae49ad9dad85403d0798b311ae27e206b429a013 1499 mdp_3.3+git6-g7bbd889-1.dsc a909979a77bb80ed4a96d51596033fe15ecf1365 473471 mdp_3.3+git6-g7bbd889.orig.tar.gz 7a67c79f41c7abb861f9757f08296d1209ef93a4 5424 mdp_3.3+git6-g7bbd889-1.debian.tar.gz ce1f64a4272a2a38abf8937511ab098d2ed4802a 483914 python-mdp_3.3+git6-g7bbd889-1_all.deb b1e1fdbbb66c929acf18c2eb5a8db4893f1f1789 472296 python3-mdp_3.3+git6-g7bbd889-1_all.deb Checksums-Sha256: c083c265128820665485c00716482171e7f1d862f3a2b1346982de50e705bc24 1499 mdp_3.3+git6-g7bbd889-1.dsc 2b7b47a62e3141e79fb3cc4ec9184c8a5c5aad90e571fab8aacd726c86444b53 473471 mdp_3.3+git6-g7bbd889.orig.tar.gz 8ed2ddab1eb170ddebd16b06210afde203cf49861f39e50272c3d02d2ee0574a 5424 mdp_3.3+git6-g7bbd889-1.debian.tar.gz 14da8e3e1ac506f16b7b566a389cb0097115ecc66617304170d4d21a351482f7 483914 python-mdp_3.3+git6-g7bbd889-1_all.deb 423bf2c021544510b8ab8e14b4f6e7b33d300cf03ab12ee73aa5314b202fb40c 472296 python3-mdp_3.3+git6-g7bbd889-1_all.deb Files: b8984bedf963c9f14adcc2660ce5d38c 1499 python optional mdp_3.3+git6-g7bbd889-1.dsc 4d6c4163960a031875ff9e216c44bcf7 473471 python optional mdp_3.3+git6-g7bbd889.orig.tar.gz c940bbbef554d5f371762889e73d 5424 python optional mdp_3.3+git6-g7bbd889-1.debian.tar.gz 42cbf5cd7d5cff375cc2911a719671da 483914 python optional python-mdp_3.3+git6-g7bbd889-1_all.deb 73c8451a1d2bbc52281de835deb8f43b 472296 python optional python3-mdp_3.3+git6-g7bbd889-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlC3hVAACgkQjRFFY3XAJMg+LwCgh60QgI3DfysxuaWkjyyVZrGn APEAn3qiCZlVTwWuEgYCddQQ4HfMBOTm =cElu -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/e1te6zj-0007gp...@franck.debian.org
Accepted mediawiki-extensions 3.0 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Format: 1.8 Date: Thu, 29 Nov 2012 16:55:02 +0100 Source: mediawiki-extensions Binary: mediawiki-extensions-base mediawiki-extensions-geshi mediawiki-extensions-ldapauth mediawiki-extensions-openid mediawiki-extensions-confirmedit mediawiki-extensions-collection mediawiki-extensions-graphviz mediawiki-extensions Architecture: source all Version: 3.0 Distribution: experimental Urgency: low Maintainer: Mediawiki Maintenance Team pkg-mediawiki-de...@lists.alioth.debian.org Changed-By: Thorsten Glaser t...@mirbsd.de Description: mediawiki-extensions - Extensions for MediaWiki -- Meta package mediawiki-extensions-base - Extensions for MediaWiki -- Base package mediawiki-extensions-collection - Extensions for MediaWiki -- Collection extension mediawiki-extensions-confirmedit - Extensions for MediaWiki -- ConfirmEdit extension mediawiki-extensions-geshi - Extensions for MediaWiki -- SyntaxHighlight_GeSHi extension mediawiki-extensions-graphviz - Extensions for MediaWiki -- GraphViz extension mediawiki-extensions-ldapauth - Extensions for MediaWiki -- LdapAuthentication extension mediawiki-extensions-openid - Extensions for MediaWiki -- OpenID extension Closes: 694114 Changes: mediawiki-extensions (3.0) experimental; urgency=low . * Apply upstream commit 9ccef963bc825075db6d6b6458bdfde1ebcab6d1 to possibly fix $wgLDAPAuthAttribute in LDAP Auth (Closes: #694114) Checksums-Sha1: c57eee1c7d0ef09b6650bb84a6ec9021ae2d7263 2325 mediawiki-extensions_3.0.dsc 26eb2e76c5d2191f1a6048f0043488cf3c2f801d 1643061 mediawiki-extensions_3.0.tar.gz 012577af7b8ff231b961c3ff755324455861c20d 829038 mediawiki-extensions-base_3.0_all.deb 28530a1a558318918eefb641083963965ab6376b 33588 mediawiki-extensions-geshi_3.0_all.deb fe626a3e40bbcdf7bd7208623a1f10c343d04bbb 26546 mediawiki-extensions-ldapauth_3.0_all.deb 9b101e9f99f16e40fae08b174ebdc4680f63f2bb 197020 mediawiki-extensions-openid_3.0_all.deb d4165fd8a8e5bff4a691703e05b4717476f78e51 246368 mediawiki-extensions-confirmedit_3.0_all.deb 7a3b128ac47f4b55919031742bf33ea9cfdb187a 332480 mediawiki-extensions-collection_3.0_all.deb 08da93e0c76406d04db67c0397eae0d2961e9832 16724 mediawiki-extensions-graphviz_3.0_all.deb 7d8f4851ef2f9b41906997139ba206aad63352b1 7142 mediawiki-extensions_3.0_all.deb Checksums-Sha256: 5257458bcba8174080516b5fb156c096d3976a43f6fe3977c84b161937639ebc 2325 mediawiki-extensions_3.0.dsc 02f93bd653986086ae6a787b9b4c71b849513db88528eb7a084ba24067976d14 1643061 mediawiki-extensions_3.0.tar.gz 8fcfa5750b303e5040222db7d055d65ecd81ef23041423dddc4ffdecfc7e401f 829038 mediawiki-extensions-base_3.0_all.deb ddfe529c741e98da753665963622a7893034e572f498bfa61385c4eb6249814f 33588 mediawiki-extensions-geshi_3.0_all.deb bc9feb0d9134213dca65a5cd3928fc7e53ecf8dcb16b51b614d1b607a79bbcff 26546 mediawiki-extensions-ldapauth_3.0_all.deb 6d84daeae8eef793c2856d1defb127f2aac8dc447570777db9500178ad18201c 197020 mediawiki-extensions-openid_3.0_all.deb d270863f0d58e402aeb46065694713fa4fdf9f8e7e7cc9bf24b990dbf2451566 246368 mediawiki-extensions-confirmedit_3.0_all.deb ed84eadc7baa059ad4ba026c0691f9e7b7437f5f1601079735e8f987ed153774 332480 mediawiki-extensions-collection_3.0_all.deb 0d011f9ea1194c0b1d75cf8c552d7fbe6471652b0e92a45b4ffe50592d942fa7 16724 mediawiki-extensions-graphviz_3.0_all.deb 89892f908ffd56c56da3b181b942c59c54ab031e4957c7e7f81675e157ce7b4f 7142 mediawiki-extensions_3.0_all.deb Files: a8d7768656148cc98c0cf979cab1caf8 2325 web optional mediawiki-extensions_3.0.dsc e8993c3eac763ce0e3a43099a2336d28 1643061 web optional mediawiki-extensions_3.0.tar.gz ac8bb1c510e9cc4cbf3d55449438e5f3 829038 web optional mediawiki-extensions-base_3.0_all.deb cef20b66fc8b7a44f5b2e7149774a43b 33588 web optional mediawiki-extensions-geshi_3.0_all.deb 322f3f37b7e3dd308c1f4e761755dc10 26546 web optional mediawiki-extensions-ldapauth_3.0_all.deb 35c3042f661294bad4dba26ede7c4132 197020 web optional mediawiki-extensions-openid_3.0_all.deb a572a0b9570da4185b6376a6b7f36b8e 246368 web optional mediawiki-extensions-confirmedit_3.0_all.deb 8bb278f8335c6e2fc544af10d9407305 332480 web optional mediawiki-extensions-collection_3.0_all.deb 3e191d729387c5ac9ad7acea7ce1bdb0 16724 web optional mediawiki-extensions-graphviz_3.0_all.deb da379cae1d0163828c3c6ac70611ffd7 7142 web optional mediawiki-extensions_3.0_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MirBSD) iQIcBAEBCQAGBQJQt4aQAAoJEHa1NLLpkAfgcDYP/iFxJKC1K2Hq8tfBnHKQ+ozV O6XRn+Gpvcyf4LsrtgGFpXpC2UNyGoYqPTmTUBk1D+eJ6JPfX1rU6BBhL115XG1n D29IvXVqQ3OSP1s52/FbwhKlKI2TQs56ugctUhpp3/ivknRpp2mW2HtcL1iVVgIE /lLvxBKyDMdbmr2a2XmNPnrreNzKbjP6X/6bT9qe4NMl0WFgjQYpVq3QFUkRjytl GYVjHz8vAJuSwWNf8rIy3juB/o8dWKeheJb2hW+ubWDNw5UV2Fv8Jhj03VMne8ns /gYBzYDW8DHxL0bUq03SlO/v7RvrR646BTLbqr91laY9zZNgtsSFl3QghLpIaWcZ okj6KcpUFCXCdKFspmKoiI8ngc+qwQetA68otXISoQj8y8+aau08YyXkVL9uFVin
Accepted libaudio-mixer-perl 0.7-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Nov 2012 15:56:10 +0100 Source: libaudio-mixer-perl Binary: libaudio-mixer-perl Architecture: source amd64 Version: 0.7-4 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Jonas Genannt jonas.gena...@capi2name.de Description: libaudio-mixer-perl - perl extension for Sound Mixer control Closes: 687356 Changes: libaudio-mixer-perl (0.7-4) unstable; urgency=low . * Change Maintainer to Perl Pkg Group * Refreshed debian/ with dh-make-perl * d/control: fix spelling error (Closes: #687356) * d/control: added note, only working with OSS Checksums-Sha1: 7f654d60ef4612c45f4c65e48e485b44847edce7 2051 libaudio-mixer-perl_0.7-4.dsc 739daf97eedb7809da77203992e728b19d399c01 2172 libaudio-mixer-perl_0.7-4.debian.tar.gz 5e4323b8ee95a27c7e8a84744dcec1bd4fe5a059 16464 libaudio-mixer-perl_0.7-4_amd64.deb Checksums-Sha256: 32c7b44ca06dd40e97f92acb81d56aa02bbd35194345090386c4cf4a0495f2d0 2051 libaudio-mixer-perl_0.7-4.dsc 885f68c10361603b292aab154e0d1c2b47cd4e2248bba4946a2212f49c325ed5 2172 libaudio-mixer-perl_0.7-4.debian.tar.gz 4e0a525e2218e775881b0ddebe16e51a02eb8b816e713a5811d4f6e38ea294cb 16464 libaudio-mixer-perl_0.7-4_amd64.deb Files: 12ca485021a4158b1005b9c5175096dd 2051 perl optional libaudio-mixer-perl_0.7-4.dsc ce7fa74ea55c7554db72f3b5bc9bf56d 2172 perl optional libaudio-mixer-perl_0.7-4.debian.tar.gz 3e845dc5fe9cfab28b22db62ad81387e 16464 perl optional libaudio-mixer-perl_0.7-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt4r7AAoJELs6aAGGSaoGKiMP/2Ptburlp4wERUFiG8neHDcw TwjiugW8CYg+qI0bgtnWqi6o2/tt0EHYX7SYDsdoAWKitZH3S+eCY6NcI66T+fbg Z4pqVYgw68L+fmq3dS+hoZ5WZTT0pU5nBwdNuYcwLk34E7Zk91NCSL4rCNsl/vYW us2TjG0VTH4/USYgxCfnyjTPdO399z/q8GOAGePz0JPdZQJooNmJvKoCQq0IHTx2 WrGQyTFSDsb38UkK5jC9Um5WkEc1KJ+OxBPH8Rgj8ZFTfs5firMPMWTuBDdnyz8i sZJeRAg7J60jXRb6uX+EWYSmTcNAaI93qSHeoJY2zR7YqZyeWUd86K11U28dEAgC gPA2mbtp+6h+yhfb2LjPKxtH8+S+YEENlIsX2HiCPc8fnqjLlr53tnMCA1KQgfmE ZCIXG7ZBOse0N2cckg/1EG74Br7UVq9pUtH4u7cASvTt/aGj+IZ5l9k3KNVLYrWt KHsAAJVu/BaGIppwsz1SYS9Tb58Wuvn7ayJYDMH3FeFm0R9BGc1Cj7nuf0QbdwkN Sw9gRQj+2ia8W8vpWHfxWwS7I6VG8ijSxcXyB5gy1b0p/VZJdJcm5YCBS6OAXi9q ufxUb2G2eHALWhzeBqYuTS1vEDhBWHrhOBOapDVvm/JkAa2OJafXUwCE/89BOf3R O4+xNkZDzZjXogou0C0L =tvbS -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/e1te72i-0005zw...@franck.debian.org
Accepted libpod-markdown-perl 1.322000-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 27 Nov 2012 22:59:16 +0100 Source: libpod-markdown-perl Binary: libpod-markdown-perl Architecture: source all Version: 1.322000-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Florian Schlichting fschl...@zedat.fu-berlin.de Description: libpod-markdown-perl - module to convert POD to the Markdown file format Changes: libpod-markdown-perl (1.322000-1) unstable; urgency=low . [ Nathan Handler ] * Email change: Nathan Handler - nhand...@debian.org. . [ Florian Schlichting ] * Imported Upstream version 1.322000. Checksums-Sha1: 1bec47a941a123abfe7f7599f7488a3f3de1cd0a 2227 libpod-markdown-perl_1.322000-1.dsc 83d93f5ce300e8e67210bd72ded52fbea9d4865b 27763 libpod-markdown-perl_1.322000.orig.tar.gz 07c0d1fd0eb86d1ebef78360a81292dfac3ef09d 2839 libpod-markdown-perl_1.322000-1.debian.tar.gz e1c022ad05c0cd011364749382054d54595a8d8f 17974 libpod-markdown-perl_1.322000-1_all.deb Checksums-Sha256: 83bee1508cfe7f14d2cb3d4c1a26604d2f24c0f7fa42b6c36ac302753b29cb8d 2227 libpod-markdown-perl_1.322000-1.dsc 375091d89d9662b0c41bedad391927d6904d05f740e1bb689b494b4b35e979f7 27763 libpod-markdown-perl_1.322000.orig.tar.gz 191b976c3b3392653c88e682bde94268eae6958d86c1418cf839ae85c351b5e0 2839 libpod-markdown-perl_1.322000-1.debian.tar.gz f81d608e0b27e897e099f3199095229b687914db296bb44ad9cf01da94eb6728 17974 libpod-markdown-perl_1.322000-1_all.deb Files: 76864d8724eae791e73937615a6ec801 2227 perl optional libpod-markdown-perl_1.322000-1.dsc f53d49154627afd90323ee273824173e 27763 perl optional libpod-markdown-perl_1.322000.orig.tar.gz 7bf71b91fd5f508adea859d0f21e8c6a 2839 perl optional libpod-markdown-perl_1.322000-1.debian.tar.gz 421e85a3fa1c1e8d74ad9c81e216bad9 17974 perl optional libpod-markdown-perl_1.322000-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt4vxAAoJELs6aAGGSaoGutQP/1bBqnXHCLxA0LcC1OiMoytv aaoVNvZSNFN20BWQVUDWbvNGDLf8qh2u6D6XIEw2JuiuHJQRjRoTqB3/pTjfSVR3 ffPFHAjDJArCBDHbzayPbm8lz7LYWWQbMyg2VcM5psTMdw8LjkIAmQMIXFI9LzIL j/z1Vy40r6T4fPZ0T64V2SbWQQZF4pdr7jjieQrkvLrOHiQwI5QUS+TdrzL32+qO E50qLRbRGJtYRhk+P/RrIjEu4aSBSCCFzlsM0eHBs5qrQxHWbpA8a5o3PH+APQWz awNyd+0CmOBrbJtTVfF+aE2VAwdbqMBZiGsKtsTPyDHKjVWsOes2jtFvjG4bFJVk iybKe1QUClbiQdl+tgLc9lmB1gWKMIOo6qACG6cFKZVvRFCcqx00tDZ+1iP6CvWm 7c8D4LHBvMxM/FPi02M87jMUJSnMHCwnDk1yTteFKAO7KjSEOXEk9cKGelggmFIi skM7uUa9zOjZsQ7WhKLU573A5O3H9cZNo77RR7Yv1bX6aFKNbmP/ohgZkVYn4Z5t da5N2ZzsrHKa+V7uzhFuPCJd/p1Ipsogom1ZqmKi6iiWHMs3BlA2FNe4YicV5jUy L7WizzGvlq57b4rl14oAA8eGrZdi1eVkQZ7uMddlEP5Z3SPvNMpxPRi8t9ih6SC6 33Lqm42qqeSpFw/dXF1X =KkKl -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/e1te72n-00062l...@franck.debian.org
Accepted libtext-csv-xs-perl 0.93-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2012 06:12:21 +0100 Source: libtext-csv-xs-perl Binary: libtext-csv-xs-perl Architecture: source amd64 Version: 0.93-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Xavier Guimard x.guim...@free.fr Description: libtext-csv-xs-perl - Perl C/XS module to process Comma-Separated Value files Changes: libtext-csv-xs-perl (0.93-1) unstable; urgency=low . * New upstream version * Add little patch that change tests to really check Encode.pm version Checksums-Sha1: 7a5aa97e8bea13cdc4a267195f9f3f9cff7e71a7 2505 libtext-csv-xs-perl_0.93-1.dsc 94ca492e34b120861cb1e134a8658fa7ff9ed197 120579 libtext-csv-xs-perl_0.93.orig.tar.gz 70bfa70bc267d856f42d89615ee07961f4093101 6948 libtext-csv-xs-perl_0.93-1.debian.tar.xz f532ea3e164e2346a03745aa7990d7ab64449081 72524 libtext-csv-xs-perl_0.93-1_amd64.deb Checksums-Sha256: 19805419ef20dd20c7296ec03c69b00c31a828df3984b2bde101f3e6e84619fd 2505 libtext-csv-xs-perl_0.93-1.dsc d39056eb4edf78162873d8a6e4f76174218dbb6e34743e3465c3ef4b09ffcb7f 120579 libtext-csv-xs-perl_0.93.orig.tar.gz 891921ac4a33c83d4905eacb196e553f67f853065b11f6b5da1764c58c63c711 6948 libtext-csv-xs-perl_0.93-1.debian.tar.xz bccd64c938dfe11e248cbc8b1c8531534f01ebca646bf4656705fd196e25cfab 72524 libtext-csv-xs-perl_0.93-1_amd64.deb Files: ca1efce358b2ad6c47edb0dde6412a4c 2505 perl optional libtext-csv-xs-perl_0.93-1.dsc bdf64d6f151741e6f526f92a79b48e06 120579 perl optional libtext-csv-xs-perl_0.93.orig.tar.gz 64f5e7ff5b66a12f695722071880e2ac 6948 perl optional libtext-csv-xs-perl_0.93-1.debian.tar.xz 95a4164156b18b467e3fc832007cba33 72524 perl optional libtext-csv-xs-perl_0.93-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt4zfAAoJELs6aAGGSaoGyUkP+wUgd3EdxR7kJ++WeL4qYDVk 3j3APhL9QnB7cJ9p67+b7lZt5PLzj2Y1SrnW3yRbAY+92oqjUclB2OZbZq29H0f+ slFpdbzP2WI8SRDxneoTW1on1pnfLukj1e7cL3U/inkXUcztM4vtxxEjgZyb43He 3OuV8SBIBXGd8ytcsdbrdwwDekawtQeqT/yLJk4FokM2Xj0hbtMqZubBRPLH60yx qm3dsFDRknZehTFn4Trw4SpiSAfjr3WWdm6EZr91k48HkJ9c5qUXT6ZuZ/fPre1m H1hnvfNtG6wlVHsmVO02Q0IqIKMVJq/NquT1rU02Z3p22QkRhQDNb2FQ9w+2U3d3 +Vv2ddLSGoyTVvNB0JZ5cZLQ2WR6kfSlpj6g4DHz1FN/Ing7uywljA2XKSfParo5 RpxEG1LlPE3p4S4XRm7BtSffFnyCXzPVK5uPmQ003vxNShTwjn36UlSc+F2AfvxR vXQf6ZdH2hgoArr6ybyHNBjrY9GsQCarb1zy2rW1Nq0JeaXrz2rIBC1ioaW9GLhW raOAwtTy8orJbrw8L0AERbvnfwxNOffB7D2XaZ6f0DAg8uwFRXW/3Bm8djkZbX1e iv+10JwG2pSrGLdGZtDMnKRr6/RA1CZvu4sC2JAvd9t4Qcg6MU+5Pgj1Spn+PR/D r/ypUEqtJsCqeWE29lB1 =oZUD -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/e1te72s-00065o...@franck.debian.org
Accepted libautobox-perl 2.76-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 23 Nov 2012 06:25:52 +0100
Source: libautobox-perl
Binary: libautobox-perl
Architecture: source amd64
Version: 2.76-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Xavier Guimard x.guim...@free.fr
Description:
libautobox-perl - Perl pragma for method calls on native types
Changes:
libautobox-perl (2.76-1) unstable; urgency=low
.
[ Ansgar Burchardt ]
* debian/control: Convert Vcs-* fields to Git.
.
[ Angel Abad ]
* Email change: Angel Abad - an...@debian.org
.
[ gregor herrmann ]
* debian/control: update {versioned,alternative} (build) dependencies.
.
[ Xavier Guimard ]
* Imported Upstream version 2.76
* Bump Standards-Version to 3.9.4
* Update copyright (years and format)
* Use debhelper 9.20120312
* Add lintian-overrides to remove false-positive lintian report
Checksums-Sha1:
aabb7c922fb4e07abdc98e821ef3a9e93bca7058 2107 libautobox-perl_2.76-1.dsc
6045a5f7375c2f27d967a3cfc9bb5665816a7621 74105 libautobox-perl_2.76.orig.tar.gz
50c4b1ac1ee2eb10266415c5e48a55e705294eab 2505
libautobox-perl_2.76-1.debian.tar.gz
5990770ae9082373dccfd8460c86a786d01c38f9 32020 libautobox-perl_2.76-1_amd64.deb
Checksums-Sha256:
bdb9f98135f450a8dd060a4b40265dec200256780b6ac43d5a0c6317aab16abb 2107
libautobox-perl_2.76-1.dsc
4d3cc8189b98d0bd18c83a6d39140398b19e269c305aa1a80d9a8d3c0663a566 74105
libautobox-perl_2.76.orig.tar.gz
4fdb48d1fe0990a6e2475fc84ab04584bfc61db4f721a5d2c3d10b7417fa24a5 2505
libautobox-perl_2.76-1.debian.tar.gz
65b49473f0a9f08aecaeb62d7e6e258fdccb8ea090d57eb5e477313db575e337 32020
libautobox-perl_2.76-1_amd64.deb
Files:
c3a6b5beba27dd42305821c036155676 2107 perl optional libautobox-perl_2.76-1.dsc
5585c43340f3bd084cbfd79e394dee26 74105 perl optional
libautobox-perl_2.76.orig.tar.gz
37bc963a92b599e9310cceb587e3a2d6 2505 perl optional
libautobox-perl_2.76-1.debian.tar.gz
a367132723335b80b726eabc71354ef3 32020 perl optional
libautobox-perl_2.76-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQt5AzAAoJELs6aAGGSaoGl0AQALyFFfwqB+IQnnCAac5nlXnn
L+vOYeRbYOU06s6YbA/bc/ka1ZRui4ZuVX4sqCjrttbjzwWHQGihZ5hVqSbIuCR7
RwBnfuv4g0BDkZGAD6NEl5Ro4xBnI1Ujmus/+gIm4fWWvfTTM8nf2X72s2XBxica
bjjz0lUarjywH2Ea62ZnBJV4S3hrKOjHi2ygHA+fel0AiBw6rDYaL+ez/bM3gclt
wRvXYqjUTMeILJJuibDUFr/XuFaDlwz+HzFwcL68vsTWJTpw/c7+r8Im5OXBipVv
Wv7bbk1vKEP2iZV01zOdRn66Pv4f2Jpa/ck1g6gc1mtI0EYYuXnv2+L/bwt6lY+4
AKLGCFcDtwLVIRCcNtzqGhMmLM1HitvXWzKiozUkObIOUoXqdJD6QyIQBaZnSbcK
yRHt94vZwchpPwJ/Qt5eIpNiZVhpRM9PRq+zpfGyTkI0SWCzkc+yh053zl9nUlim
Kl7B2MWTvWS6SpBzrqf5GOgkI+EBAf62EL+Yb0DZ/BTUoW7av8aPkNcCbOPHLEyo
jfZakpMUM6Z96EVJyMYKd7k4zj4zwQtwN76ocqrxg2i9HU7B35DkhTRDo75kEuPb
uIDn6C555tdiPg9D8xgMLHPujJi784SmI5R6Kg4VKtFfClfjHIm5RKs1Q+NIkPhj
5g7y2dW3OtVhQmpaMjlJ
=q+0f
-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/e1te7gp-00011d...@franck.debian.org
Accepted libclass-xsaccessor-perl 1.16-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Nov 2012 15:16:42 +0100 Source: libclass-xsaccessor-perl Binary: libclass-xsaccessor-perl Architecture: source amd64 Version: 1.16-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Xavier Guimard x.guim...@free.fr Description: libclass-xsaccessor-perl - Perl module providing fast XS accessors Changes: libclass-xsaccessor-perl (1.16-1) unstable; urgency=low . [ gregor herrmann ] * Unify sameperl substvar generation across packages. . [ Nicholas Bamber ] * Updated debian/copyright * Raised compat level and debhelper version to 9 . [ Xavier Guimard ] * New upstream release * Bump Standards-Version to 3.9.4 * Add lintian-overrides to remove hardening warning * Update debian/copyright (years) Checksums-Sha1: 159b6aab4018fd5db49a5d91069bf14749344c2a 2294 libclass-xsaccessor-perl_1.16-1.dsc 7b1f44522ca504376e259094d8c20e5e76ddd056 81459 libclass-xsaccessor-perl_1.16.orig.tar.gz 6c97ccc1d2b55bbe26591bd7da458d0ca04ca23b 3327 libclass-xsaccessor-perl_1.16-1.debian.tar.gz 22eec47a81755b1d8873d5ed6a51a57bc3008e7a 44846 libclass-xsaccessor-perl_1.16-1_amd64.deb Checksums-Sha256: 8deada184947ef750e57ea26b858a4e69b0cd42779af9828817bc8e5e7c5c4e5 2294 libclass-xsaccessor-perl_1.16-1.dsc e56da77445d1cf2f2f2112f5f34922027c6c658785cc0388289578ad67e257fa 81459 libclass-xsaccessor-perl_1.16.orig.tar.gz 1fa44328c82b1a908b111ed1de7fff5a5fd61385993ec4b70837015ad975c851 3327 libclass-xsaccessor-perl_1.16-1.debian.tar.gz abc06558bd12670f6114f953a149717bab6fafd6b4e9a34ef02ad85619662470 44846 libclass-xsaccessor-perl_1.16-1_amd64.deb Files: 2ffdb4cb85f1171e0b4ae0691c81de84 2294 perl optional libclass-xsaccessor-perl_1.16-1.dsc 990ec14dda99ff01a32f64708b1ce15f 81459 perl optional libclass-xsaccessor-perl_1.16.orig.tar.gz be03c00730982a6dfa69c3a6312fc0e2 3327 perl optional libclass-xsaccessor-perl_1.16-1.debian.tar.gz d64924f2bc5320e15c99edfa9b49adee 44846 perl optional libclass-xsaccessor-perl_1.16-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt46+AAoJELs6aAGGSaoG0GUP/i70fiZHOBcJ3oCdtMqgALa/ ooP1f4jan8UI2F2JKoH8FtQ1NFOa/iUm90JduwNi7K1oqckfz6WYkNn/5wi6bQnX /Qz2S0FNarN/ebA8nfyhOdxL3GugbqACjnaCZp+gvnZenZC+sGlx7lWd9nBZP2E0 46vgNOEbCbPN90qVC3CHIn4hD+ysKBNxGVqEcUKd/9E+QWfWmRgIMcBWiSUtKnj2 vKntKtfK6j90BacCnbli91IFTiQ5HaoVH8ISJFxj0M69csF4+NKocYrBTFvi6v7Z JglHfapl9N3Yc2UMl5tBQ5y8/9PDiT740cAnBt53pBXqF/Env/MB9dbZGm1w5E4Q bc0UBiNi+8bb4I2B9z/JMt5f45EvNdiay1N3IZdt44Zq3RCtPTDLrNXSU7qD6nQN I+7PGWvr+qEBNUhQynyNjUperxbk5x1ciyAgR7Y6XqEMEwjaQLpSAo3JtF4zMxyS SyPs799Jy7hFiSMDFkb8kt3hvoEStliNd76654jHaqQO3iM9C8knRmZf5cdIShea iLuesu4WHZAKY70B9ZdlDLD4vriU7U5hWnNn7vnyeKFb+8W8kLuMFylXfDC06oKQ 3MKF65JSvf/+U5qFX52ITSAWFJQm6UiwEvJHs95gwHPGEZ//RVCdbIABZWRbSzsV h/vTwF4cICwZtC6htEeV =8sk/ -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/e1te7gu-00014f...@franck.debian.org
Accepted libcql-parser-perl 1.12-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Nov 2012 18:46:25 +0100 Source: libcql-parser-perl Binary: libcql-parser-perl Architecture: source all Version: 1.12-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Xavier Guimard x.guim...@free.fr Description: libcql-parser-perl - Common Query Language parser Changes: libcql-parser-perl (1.12-1) unstable; urgency=low . [ Xavier Guimard ] * New upstream version * Remove debian/patches/manpage_spelling.patch (now included in upstream) * Bump Standards-Version to 3.9.4 * Update debian/copyright (format and Module::Install copyright) Checksums-Sha1: 410164b42027cddf4cbe5e6839baa0dbd47c527d 2196 libcql-parser-perl_1.12-1.dsc c3282decf684407acfab02d46a2c575a4ef6c72a 39432 libcql-parser-perl_1.12.orig.tar.gz 50e461cb67605ef65b8a70bab31e7a326852e12b 1699 libcql-parser-perl_1.12-1.debian.tar.gz 31a121a92e931fc86487e8eab7db99c493ab1ce2 50924 libcql-parser-perl_1.12-1_all.deb Checksums-Sha256: c85bb7ebca3fb7559a2e47f5a5f8ee20910e7196809958bf646b6ebcb0f42eff 2196 libcql-parser-perl_1.12-1.dsc 8dabac238451dda289295bff40c69b91ad8d1ad48b7ca46162d785ae5e3e4d71 39432 libcql-parser-perl_1.12.orig.tar.gz 53964ae092b9d623ea7c738518c339fa6eea7883f1a9a3e5ef4f5801976e9614 1699 libcql-parser-perl_1.12-1.debian.tar.gz 522d0e1a515a5d82ba583dd679dc7cae74d469e4dc122786c0f76eabf6041ad6 50924 libcql-parser-perl_1.12-1_all.deb Files: 455453ea8567fa95c6920d133b965a2e 2196 perl optional libcql-parser-perl_1.12-1.dsc 51101eec70646bda06de940dc698fbe0 39432 perl optional libcql-parser-perl_1.12.orig.tar.gz aa407413f6ac80b7d36c9b155df10221 1699 perl optional libcql-parser-perl_1.12-1.debian.tar.gz a29a7bdc2f4de62c6f0f0eeba9ef0d36 50924 perl optional libcql-parser-perl_1.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt42lAAoJELs6aAGGSaoGgREP/iq16Cd+89+5e5QR2p5yR7HL BMjTucwVCIDByfnSYSIPPapoC7TCRD3Yxvbv+fYQHfHEnWfBGxiT2xlLjsTpwruR xJP0mPli/+xwGGr6I6WJzqBDq6a9DBNVk7EMvKVObs4ggayDGQWN4UYpAVtFzxCd 8fJ9x7WIZCQcea7+2TjQav4bmrNgi0ziK7fxSLAQGGZx6xII2qPrrU1qhQEHAZqe NZmfdk6wXR7KX68A3fhLN4T579WrYg0zJJpXOUh0DSfy8sS0Vmf/I6f0aeTrIuZw AY6BuMp/vWAnGzJPZ1AV7UIh266BXZ2aDW7gBTWE8C2whyw3PMfF+y3+q9aKN5rC M1QIU8UYJK14/s13K6xYRkQCq8nYhyZ8khVgBcfnqNQZt9dMQnkwWycbbyEvhkA7 tmsqrFV6TVtqChANG5ix5PF6JjmCZ/byHVch72T6mH38apUZzfSzdUtQz3EEo3NG 3czlv9hfITmKXl3KAcrKVI7do5fvSc92MZoPfIpQvrrntSdAckTZgUe4fIWSCy6M 22ics9kAuv+cXBmZykVxGwRidpOup4nIvAv0uOPg+NUfIC9wQzOvngtFUkrNRPno r8JT6P5UzrpPSCMVHzaLdd+ESjQYX5JChZ9ySZ3sZT8s6MdpYIqL5+YuU7jll2Us 2QE5oObmZF6yTtscUJsU =BMRq -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/e1te7gz-00017o...@franck.debian.org
Accepted mountall 2.45 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2012 22:07:18 -0800 Source: mountall Binary: mountall Architecture: source amd64 Version: 2.45 Distribution: unstable Urgency: low Maintainer: Steve Langasek vor...@debian.org Changed-By: Steve Langasek steve.langa...@ubuntu.com Description: mountall - filesystem mounting tool Changes: mountall (2.45) unstable; urgency=low . [ Serge Hallyn ] * mounted-dev.conf: leave consoles alone in a lxc or libvirt container (LP: #1075717) Checksums-Sha1: 5c966c06ac59c5ebad011f951181401b708efb74 1737 mountall_2.45.dsc fc075964564fb57000473a1840458c507d7230f9 634238 mountall_2.45.tar.gz 4a151f46690df5054e533d25f58fd229aa2d127e 81244 mountall_2.45_amd64.deb Checksums-Sha256: 0bd5072a2627408f5fa59ab8e43c15cb1bf9752dcc98e3df103010d2b653397b 1737 mountall_2.45.dsc fe2f47ef72edc41d09c64f7aaec05b2308381478ad0464a7069fcc9c98a4 634238 mountall_2.45.tar.gz 8d054a60764ff4baab1f5111421f647a640f39dc75257252e87b9c3bd652c907 81244 mountall_2.45_amd64.deb Files: cc95441f2221dc5a79896126c48e6699 1737 admin required mountall_2.45.dsc 305e2c0065343b5c93b2562a18b07e80 634238 admin required mountall_2.45.tar.gz 70a83041e4e5980c399a192021e841b0 81244 admin required mountall_2.45_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJQt5WXAAoJEFaNMPMhshM9h20P/R4GBX00kre+DaMM9Y5SKuoJ 9cDQW2aHYAb1mkiDvMG6Tz7Tl4Y3cd7RGskSZcoo4w8VZu1F52vwP5hLfv5mIWyV ASjHKT/qnzHw4Kd6OcDOVwoWN93F/iv4W5JDR05afFAqyPS5xHPc65J78Jb5fn9d 8nMXi3lNu9hFixof5DymlItjmd4o3q8xBRS05Ee4XglJpGPT+JO+qLSAGXNdB2zt 1kNzLCsFU5kWjLkOqusC2383gftiwkwpwWBzjEV24rlzkdk1kgvoLD3k0MUUEz8r oJlWqKqlS3KJFBPX9QGdGpXp8+lQGaTDMAJJELREQ62vWlg+V1rh4chIjKNhO15F Ft7Y7Lk69GUsiTmJ3+V7v1oCjQaST5De4n7jAtPIPPoHzGheVluDtsr/8wL/VrgR lxVLRE1Z9dwgT2d5jT3eRjaBHHPQgIPQwCtztLhYk6u4DXNls8/r8AKDO9oVG2z3 BxGGXUvjlcB0FE7M/o3aEgIr8kBpsVVe5z5uyiipw8K1Hrpk6l6PcljMkbxqYab5 gzZH5eMQyo9C1rwTxT5NY8e/5fPzjBBAN20+FsX8E0p33J2e5KJeyEs+KHh945Gb XoRYHC+j77KXWp8VsYVRbqQdVFZ5OxVqGZY7ivb89TZWDwOiprRJU5wCDAwJZ3Uy pj7jrBWlI+Cib2syZ0D7 =siB7 -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/e1te7ke-0001ae...@franck.debian.org
Accepted libvisio 0.0.22-1 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 18:53:47 +0100 Source: libvisio Binary: libvisio-dev libvisio-doc libvisio-0.0-0 libvisio-tools Architecture: source amd64 all Version: 0.0.22-1 Distribution: experimental Urgency: low Maintainer: Rene Engelhard r...@debian.org Changed-By: Rene Engelhard r...@debian.org Description: libvisio-0.0-0 - library for parsing the visio file structure libvisio-dev - library for parsing the visio file structure -- development libvisio-doc - library for parsing the visio file structure -- documentatio libvisio-tools - library for parsing the visio file structure -- tools Changes: libvisio (0.0.22-1) experimental; urgency=low . * New upstream release Checksums-Sha1: ebd9fe4acebed562e4d8e334b0f9904b47022a93 1964 libvisio_0.0.22-1.dsc cb20956daec744d77bfb3670ca8cac5ac46552b5 478662 libvisio_0.0.22.orig.tar.bz2 f20a9be25f5bf0cf3ed1d802ca67b76a2d6aa9a7 2362 libvisio_0.0.22-1.debian.tar.gz aa48301e7a0af33d1c09ffbb5367397e96c63eea 49126 libvisio-dev_0.0.22-1_amd64.deb b8ac534654d5d6783e79016a90c2509a572faf35 863312 libvisio-doc_0.0.22-1_all.deb c38aad4e5acab700b5301e7477148aeff53a2ddb 323426 libvisio-0.0-0_0.0.22-1_amd64.deb d601fb82a79a784d0673d3b6baf9483ab3f15a66 62410 libvisio-tools_0.0.22-1_amd64.deb Checksums-Sha256: ecc8c597a30ad4a764e570313cd84cc800465427f060250fc44679f7fff660a4 1964 libvisio_0.0.22-1.dsc f1ca2d800b8652bcef14930df3a38f0253c0a22dce36193ae9ecd1122bed65f7 478662 libvisio_0.0.22.orig.tar.bz2 5d0627a00c98f0fd77761326596420403cf6041db2f0cc184eefae716040841f 2362 libvisio_0.0.22-1.debian.tar.gz b91f6abf84437490a4ef18651afc5a85ba1f34b27962128f66b8a57f105ff8db 49126 libvisio-dev_0.0.22-1_amd64.deb a403f6c3f5fa598fbe50a7d430470cb7a36ba923ee3a00d0cb6cf8978924bbd2 863312 libvisio-doc_0.0.22-1_all.deb b76f90aacf90a8f1416f5a8fd25ba17614aec7b62375cbae5ac197ed8d7fe0eb 323426 libvisio-0.0-0_0.0.22-1_amd64.deb b6a028442dbc6dd9f331ff9beab773986682e9e169ac894eeec37a05e9c19c24 62410 libvisio-tools_0.0.22-1_amd64.deb Files: 3d69586295a2555a28a5b86509e07734 1964 libs optional libvisio_0.0.22-1.dsc 2f36f1e75e57fef34f4fc27d2a2e3481 478662 libs optional libvisio_0.0.22.orig.tar.bz2 91420a0faf2bb43bc213ee13ee4e9d30 2362 libs optional libvisio_0.0.22-1.debian.tar.gz 7f8a496c67ee77db202117701d099cca 49126 libdevel optional libvisio-dev_0.0.22-1_amd64.deb ffb6f9f3bf703d2ef419b2054cc36f05 863312 doc optional libvisio-doc_0.0.22-1_all.deb 396429b95ab32dbcf94bdcf0696f4b10 323426 libs optional libvisio-0.0-0_0.0.22-1_amd64.deb a7cbbc26bd18e078d3a5c06d3450c005 62410 utils optional libvisio-tools_0.0.22-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt6KiAAoJEAqgRXHQPj5wtisP/0T5QrLWGPcgCdDfzb+y55e/ ieOVoeq6l65PtQ5A2+jCLgJEoQCAo3iabBbKAQgDOjAlGIQOmrVaLGmQt3fRoOM8 s3/v/QGJubqhdH84Eg69GNZIY59Z9Toh3F5YE66ozXB5TKMKnCYOSPwentqxteVQ VbsBOdL6ZF13G6Rb/8G6oHATRnI3SpKYvnDRHUTxm0rU1zyWmmI/ikJ2B/KuIjz4 flrQEpTGok9ss/4FexvYv34LCzYCPwo2ydz8DuOmHhrT6a3lzeXq2efNQyn7H0Aj 0VxjZ6Mls2lMqx8AsfuoVjEtYR7WYHdaaTdUqnVYkUGEeUdTwOCODaDYy04hUfpX O/srnWFi7hGyYgaVVhBKqhyn91H3p4i9nJ6Wxgnd2Q3DSaONsCo4qe1EU0GiTsbv QnHgrjw8Ts2jvopRGilLlcCNI6CIXGMPH0joMTbu/MY9nWDhMfZWByLwn4gvn6VI MogMLV8MjrSQToeAFARohfVYx/Ys23L9rEgIYsUSGx8yxJSZI5jhfiYXG/lPdesV LZgN8xODOsNxYJXuQv/lmLxi0rWufK7IfmE5SsQgRhpyxhZI/thnxlf5kE2kRpIv 0FHV82RQGNGYHwjrkBsIp4y86mCJzUbAOBCk9J1zPBtrkCY8gtQd+VSmh6+C6il2 03Lyejzy1Xz79LG0kFUR =wkPH -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/e1te8g0-0004mf...@franck.debian.org
Accepted xmobar 0.14-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Nov 2012 22:13:55 +0200 Source: xmobar Binary: xmobar Architecture: source amd64 Version: 0.14-4 Distribution: unstable Urgency: low Maintainer: Apollon Oikonomopoulos apoi...@gmail.com Changed-By: Apollon Oikonomopoulos apoi...@gmail.com Description: xmobar - Lightweight status bar for X11 window managers with UTF-8 and Xft Closes: 693025 Changes: xmobar (0.14-4) unstable; urgency=low . * Backport upstream commit 0b1132, fixing coretemp information parsing (Closes: #693025) * Fix manpage typos Checksums-Sha1: 7145b8b8d0d64fb861a02a1ec301c8aa83f5983a 1894 xmobar_0.14-4.dsc ecace53edce2e5fb2d1825a4f94d338d75918e41 18636 xmobar_0.14-4.debian.tar.gz 7d707ee5b0d28ddc9ad8d227dcb1f3e884110279 867418 xmobar_0.14-4_amd64.deb Checksums-Sha256: a3f8d2f9aa6932296df4f6e5ff09bc1e11bd9eec8cce766fe7f98a88ad9a3586 1894 xmobar_0.14-4.dsc 3cfb3687ba1c693df371c0c3985d52d11f9d7794d383cd63dbaea7e4cd59a793 18636 xmobar_0.14-4.debian.tar.gz b44845d265f5acb1e933fc3ece449c5cdde53052ff7a73263614b8b73ba48fd6 867418 xmobar_0.14-4_amd64.deb Files: 1eb181ef521f09d28fbce7370c78fb22 1894 x11 optional xmobar_0.14-4.dsc d63b3e6e90559edfbdf7d3187c27957f 18636 x11 optional xmobar_0.14-4.debian.tar.gz 273c9b424eb75c0848df899c6b25c49f 867418 x11 optional xmobar_0.14-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJQt625AAoJEJ0LXlse7I8Ok6gP/0AYzCGzUL7Aap//BzW9ymTT eRq0FDXVtu5RaDVBbysZeF9WzL8yiymo2104MvbeYF9MEjYrxN5MIFU5avXvSS58 kiZQ1IIAY5kZBBDbS0qChAngcnmfkbMk+5FEe1XnNeOzgzAEOfq1/f9o5wfSdErO MJAnwFTzLVOoZHK9XSxQ9l5XHj0scdgYcd59j1LCW/dnN3Eo8dXZTRVH1vM6SQgV LZEcL25858vPsBGsKHo9IfROz4f+W7vgb0FrZqP/Q303Kda7s02IEBvsWIoT07mF L/4/KnkTFyvdpU5kZkEK06i1xbnbMFI8yfp5eHQpRpjogssB/bQyVqfOIYMz+ZSK fKaewe4mq779V1rdobpSY1rOJJMSf2h8vko3pE9eroDDI/ZXfipZxJgKSuvBXLpc YkLibNA53vQCALLQkyvo+2rbhDFC9T/pIqfu2zanPACAEYWLidfkozSUJi0z6SwX F+cwqPy/R+HfWcU6KaF1j0+bdfBBHEDKAkvjl6yBhjU67IJg79I6A1uTYprGIzLG Qdl7ESinTgEn1P1Qyvrcc/5icprvWt4ifeaE1H0rQ0Ru2T5+OfGeBipDmcDUr25o ZTzv+SCDuMfq0T4u13qJGi7OXKJGOuya969MbLdAwIzyYgTxp5jGRvotGoxF2+ok eoxpKcmyD831WSV7b7tj =jJpk -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/e1te9nw-0006df...@franck.debian.org
Accepted blktap-dkms 2.0.91-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 19:57:34 + Source: blktap-dkms Binary: blktap-dkms Architecture: source amd64 Version: 2.0.91-2 Distribution: unstable Urgency: low Maintainer: Debian Xen Team pkg-xen-de...@lists.alioth.debian.org Changed-By: Thomas Goirand z...@debian.org Description: blktap-dkms - Xen API blktap kernel component DKMS package Closes: 694429 Changes: blktap-dkms (2.0.91-2) unstable; urgency=low . * Fixes unowned files after purge (policy 6.8, 10.8) in /lib/modules/$KVERS/kernel/, thanks to Andreas Beckmann deb...@abeckmann.de for the report and fix (Closes: #694429). Checksums-Sha1: 6fe63c54fd7abe688678f3965ab27a2ada3001fc 1332 blktap-dkms_2.0.91-2.dsc 148b104581ea5b98a9ee423fba21e63f3ed9bfcd 4991 blktap-dkms_2.0.91-2.debian.tar.gz d6ab8d8f6543a7b874f2be43bea49ea03dfd7a66 18986 blktap-dkms_2.0.91-2_amd64.deb Checksums-Sha256: bdb84f7235e8adf1ba5fa2feb2af6ec72046763875e74f6f2688e32b1ce2e8cf 1332 blktap-dkms_2.0.91-2.dsc e93996228873ffab67a249512b3e95a0e72148c8827735853ab5b2e2857fa55b 4991 blktap-dkms_2.0.91-2.debian.tar.gz f3be3bd98143594e28c4ee8359ea54854e40ee15c17b0c8dccb6544b5bbb29db 18986 blktap-dkms_2.0.91-2_amd64.deb Files: 99f1d6bea3be3acc99d256153396da79 1332 kernel optional blktap-dkms_2.0.91-2.dsc c0f51ae45c36fcaff4b9baa40bcf6393 4991 kernel optional blktap-dkms_2.0.91-2.debian.tar.gz 19adead6ae3d4f3cbfc31f67433eaeb1 18986 kernel optional blktap-dkms_2.0.91-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlC3wGcACgkQl4M9yZjvmklFJwCgr6gJ6fQtxXv42/MPlz0SmHaE eWcAoJlRkyD2WdtZeUj5RZODLUzeUmpT =3IOR -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/e1te9bz-sb...@franck.debian.org
Accepted kgpg 4:4.8.4-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Nov 2012 20:34:53 +0100 Source: kgpg Binary: kgpg kgpg-dbg Architecture: source amd64 Version: 4:4.8.4-4 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Pino Toscano p...@debian.org Description: kgpg - graphical front end for GNU Privacy Guard kgpg-dbg - debugging symbols for kgpg Closes: 686632 Changes: kgpg (4:4.8.4-4) unstable; urgency=low . * Team upload. . [ Lisandro Damián Nicanor Pérez Meyer ] * Depend on gnupg or gnupg2 (Closes: #686632). Checksums-Sha1: 4602c9c434d2276416cb24a006e7ba5f097246e3 1550 kgpg_4.8.4-4.dsc c7bea3d89f3922c9761a1bf12c1d31a6f5aef9f8 3726 kgpg_4.8.4-4.debian.tar.gz 3ac36ae1614e1b477f34167ecb4bfb6a6287bdf7 913092 kgpg_4.8.4-4_amd64.deb 3effb48b3f64fb4d26529e37a1d54eb9cc73e109 2776296 kgpg-dbg_4.8.4-4_amd64.deb Checksums-Sha256: 617f3bddb7a9953bf09d3fedf5372319ec4db472b7fe6ac4d02f5c060d5efc5d 1550 kgpg_4.8.4-4.dsc ce6e7c6dd90576b2ddc521802d888cf30f7ea059d0411e352cbee59d79511c4e 3726 kgpg_4.8.4-4.debian.tar.gz 9acb841e7d69df32585ed1faab02fc9d68771fc4d9b7a5d290078ade1f22b883 913092 kgpg_4.8.4-4_amd64.deb 0c9d215ade82de2ba3d82cf381ed15d8397e9676888f36d18eee24774624346a 2776296 kgpg-dbg_4.8.4-4_amd64.deb Files: 67d765c54608a3f840ca76dff85c8488 1550 kde optional kgpg_4.8.4-4.dsc b8ca574b6dfdd2428c579874531a2ebc 3726 kde optional kgpg_4.8.4-4.debian.tar.gz 5e1904ac638e5924875817738ca7d18f 913092 utils optional kgpg_4.8.4-4_amd64.deb 24b43c415f99f7cb36085999e443f383 2776296 debug extra kgpg-dbg_4.8.4-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFQt7okTNH2piB/L3oRAgmeAKC1Tf5Y9LjFd5N/hnuSgSCEAUyaKwCgnjOs jVnjfBYQigd1s40WNVnrGPc= =2WSH -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/e1tea52-0007lx...@franck.debian.org
Accepted manpages-fr-extra 20121129 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 11:25:01 -0400 Source: manpages-fr-extra Binary: manpages-fr-extra Architecture: source all Version: 20121129 Distribution: unstable Urgency: low Maintainer: Nicolas FRANCOIS (Nekral) nicolas.franc...@centraliens.net Changed-By: David Prévot taf...@debian.org Description: manpages-fr-extra - French version of the manual pages Changes: manpages-fr-extra (20121129) unstable; urgency=low . * openssl: - Handle section 7 and 5 of manual pages - New translation of some files: + CMS_final.3 + CMS_sign_receipt.3 + CMS_verify_receipt.3 + d2i_DSAPublicKey.3 + SSL_CTX_set_cert_store.3 + SSL_set_session.3 + ui_compat.3 + des_modes.7 * sysvinit: Sync with version 2.88dsf-34 * eglibc: Sync with version 2.13-37 * util-linux, tar: Typo and format fixes Checksums-Sha1: 531045665d3da72935838d24bf1e5c79a95c69cb 1733 manpages-fr-extra_20121129.dsc 85d198de90a7fbe006cb616390eebd6c4fe30342 8800065 manpages-fr-extra_20121129.tar.gz 843fdb9558d48e8beb4f15a1f1ba531c396299bd 1401400 manpages-fr-extra_20121129_all.deb Checksums-Sha256: 0f1bfc9367a508d1fcf5aaf106836b1b5862f66541127569ba480434df3ae1ce 1733 manpages-fr-extra_20121129.dsc 1c6bc0e6c8506625eb497801c96828512f8f073fe87fe41765798ce6da204dd4 8800065 manpages-fr-extra_20121129.tar.gz e81557fd821b262bfa940718f0acb9a2121031a6886187ddc1aceaaba0cc45aa 1401400 manpages-fr-extra_20121129_all.deb Files: 45d4b354dd9a2f22d4cd8e7fdbb578ac 1733 doc optional manpages-fr-extra_20121129.dsc 2ec75015149c4d414264d102a57799ec 8800065 doc optional manpages-fr-extra_20121129.tar.gz c74878fa55f51cf3dced86d794a8aa07 1401400 doc optional manpages-fr-extra_20121129_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt4lNAAoJELgqIXr9/gnyx8UP/2K1+cmn26y1T5QFXlYd5A5i Ie0NbelGFlJJ4a6Xtl8sbrBjiyMm3JIJ54PDlUSrPMQVdjpzDEH19Y4YLLw5RA2/ AJnlxmCcqeoJSU+AMCwlvUa+knnLfN4wdy5HnpZJFNrBi+I8x9uVs5px9QuxiJO4 RJfJq/XEGbw30JI2ITGVpmPx98nJJEhOZQrc6FT8qgL3rSqJkx9HwXzasgd04CtP EopT+t/G8IY3Jg+zi17EfWzZYoWFAh6xxl+sdVuH30q1cifUhtIgFl4WDp5RMvnk XRWuDUH90+8m0IO+2sxs988JFNtohhuWWNRk6dRdFDGIAZz8lwffGo5PWfmPwu85 jVk9dAyjmnNMeJrOnaWEh7DQuQC0OrwgnlkiNe/tl8t3K4pLlQ8u2YMpBtp0OnfI hxqFOy5rur6o5vgOPGouH4scaKCoYDl9AooB8yFVL9+eaWFdgKx51Y9G3o6QS2RE 6qn03ebZWBf//b2HIqB1NKhmCrHz7qzu9dtKbEwgkj/uM7VJAKqXQ/l2vYW73VDw RQ1kCuTsiBJWr9mNXMm33Mif6hervxuD/uwe7rgK4An+CS01GpehlUDk20jt0EYd F0eX9OqRaCCN91ZcUvy2Y1qVy+DlrW8IT3ZRytTFrkVNTV/8KB3UaoYQ0OzyxHvG XIyf5fuGKC37bsiiQp4k =YBup -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/e1tea5d-0007pp...@franck.debian.org
Accepted xorg-server 2:1.12.4-4 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 19:27:31 +0100 Source: xorg-server Binary: xserver-xorg-core xserver-xorg-core-udeb xserver-xorg-dev xdmx xdmx-tools xnest xvfb xserver-xephyr xserver-xfbdev xserver-xorg-core-dbg xserver-common Architecture: source all amd64 Version: 2:1.12.4-4 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force debia...@lists.debian.org Changed-By: Julien Cristau jcris...@debian.org Description: xdmx - distributed multihead X server xdmx-tools - Distributed Multihead X tools xnest - Nested X server xserver-common - common files used by various X servers xserver-xephyr - nested X server xserver-xfbdev - Linux framebuffer device tiny X server xserver-xorg-core - Xorg X server - core server xserver-xorg-core-dbg - Xorg - the X.Org X server (debugging symbols) xserver-xorg-core-udeb - Xorg X server - core server (udeb) xserver-xorg-dev - Xorg X server - development files xvfb - Virtual Framebuffer 'fake' X server Closes: 694598 Changes: xorg-server (2:1.12.4-4) unstable; urgency=low . * Fix memory leak in libnettle sha1 patch. Thanks, Yaakov Selkowitz! * Cherry-pick from upstream: - dix: set the device transformation matrix. Avoids cursor jumps in virtualbox (closes: #694598) Checksums-Sha1: 6f12dffd7b3c5bbc5723d1254b0934e8b76d3e08 4095 xorg-server_1.12.4-4.dsc 501c9963220be06e8139d783e0dcbf7c42200b31 89106 xorg-server_1.12.4-4.diff.gz e25d8d4df650cd8f7ddd61bbd3700156d1a10070 1395676 xserver-common_1.12.4-4_all.deb 6a6a803abfa0dd85483534acb3a6718ec625d7f2 1761428 xserver-xorg-core_1.12.4-4_amd64.deb d196b44408ef179e26bcdc7de458e595642e89c1 868036 xserver-xorg-core-udeb_1.12.4-4_amd64.udeb 596d58efa3c700c5c35160f79bbe49569bfe7850 319814 xserver-xorg-dev_1.12.4-4_amd64.deb b1f677da9f7df4a89730f794d5c7840f1a64642e 922624 xdmx_1.12.4-4_amd64.deb 66f53c6c5e48e0e68613f4244eb846afee9faa01 125178 xdmx-tools_1.12.4-4_amd64.deb a61307c7975b600e7b944e821b686f96dcc6aadd 821150 xnest_1.12.4-4_amd64.deb 324dd7d3329e780f835ea4198ebd46dd060f517b 924726 xvfb_1.12.4-4_amd64.deb 9c5c22a1dcc8b328154e9af697551821faf765ad 1017444 xserver-xephyr_1.12.4-4_amd64.deb bb68514f163e46fb8fc72559170d2ef77acfb14b 939544 xserver-xfbdev_1.12.4-4_amd64.deb 2e263b9f2be64a400f991e3ee43ad52d43ed80fc 7289972 xserver-xorg-core-dbg_1.12.4-4_amd64.deb Checksums-Sha256: e676d309749ff32f534d1b1cb467038dcd59f3c1522c5351e67b61a50cbdbc6d 4095 xorg-server_1.12.4-4.dsc 93f7d8a2b89f45016df308e4113cfa7a4d8c0b752e7e6f49cf95d40d7fbdce3d 89106 xorg-server_1.12.4-4.diff.gz d8644453b5700e04f5d0936f4a2620ea420a8a96abb3a81065f587078016f040 1395676 xserver-common_1.12.4-4_all.deb b1b7d7a6443357700cef91f01d80bdc5291bf4dd52f2dde1574125c26a61b5f5 1761428 xserver-xorg-core_1.12.4-4_amd64.deb 2eb165de711d11c130bc1469c033ac9a7d4d826ce3f8992e98bfde8a7d9b2596 868036 xserver-xorg-core-udeb_1.12.4-4_amd64.udeb b20ac4c8800b3f69fadb17452af8c6981a1f61f4b7846121d30cf137a37c2185 319814 xserver-xorg-dev_1.12.4-4_amd64.deb 8c090de7f33639ebf837752af68bc256dd87aa6064b587e39d6e3744580a4fed 922624 xdmx_1.12.4-4_amd64.deb 4fcff535884f991202ae1aa2e5159337d3f3a93863b3e610f12883a014f41c77 125178 xdmx-tools_1.12.4-4_amd64.deb d6705c35cb39c33a1d3873aee77c331fff7c1e96977f2e63e41d7b2724a71083 821150 xnest_1.12.4-4_amd64.deb 04010c4c1fefe6737fb007bd77560ff0b4c693de54cbf35407ba474103be6f49 924726 xvfb_1.12.4-4_amd64.deb 5b7ee068893b461a13e58364b996e1d2e4ecf61186d608d52e79fe2189abeb00 1017444 xserver-xephyr_1.12.4-4_amd64.deb 966d6dc48fdc7c3e978eb51ea9cfbce0856a904067db919311f3fe8430af846a 939544 xserver-xfbdev_1.12.4-4_amd64.deb edc89787423dbbc3b13788c59379015a1bafb60dc098964f75267711aa488ec1 7289972 xserver-xorg-core-dbg_1.12.4-4_amd64.deb Files: d4e6400af779df6c9fda79a17faa7972 4095 x11 optional xorg-server_1.12.4-4.dsc 1a41114ffec831a2d5b1d08dbd19202d 89106 x11 optional xorg-server_1.12.4-4.diff.gz f16a9128af5c73aaba73daff92246859 1395676 x11 optional xserver-common_1.12.4-4_all.deb 9c8890b6f3c09ed81ea33ed49aa95ad4 1761428 x11 optional xserver-xorg-core_1.12.4-4_amd64.deb f5d66afedd9e2077d1e94ade4f47a628 868036 debian-installer optional xserver-xorg-core-udeb_1.12.4-4_amd64.udeb 99ba0bd3abf76c158c4478c52c7d21c5 319814 x11 optional xserver-xorg-dev_1.12.4-4_amd64.deb 6eb2f78b1502a5e818d17d2d6743e237 922624 x11 optional xdmx_1.12.4-4_amd64.deb d5cf10451d4fc110592dda8ade3179eb 125178 x11 optional xdmx-tools_1.12.4-4_amd64.deb d484994965b8282b723f91c9bd3b6ee7 821150 x11 optional xnest_1.12.4-4_amd64.deb 625fcf8d2352155c79958ef6f328b3aa 924726 x11 optional xvfb_1.12.4-4_amd64.deb 526899419b71d7d1f6e7cbacf5f425d7 1017444 x11 optional xserver-xephyr_1.12.4-4_amd64.deb 6e8c0b0f3ad174d89d4016d07e394aaa 939544 x11 optional xserver-xfbdev_1.12.4-4_amd64.deb 82b8ca907b0747e6e1ab8cbe79b6a51c 7289972 debug extra xserver-xorg-core-dbg_1.12.4-4_amd64.deb Package-Type: udeb -BEGIN PGP
Accepted manpages-fr 3.44d1p1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Nov 2012 22:40:19 +0100 Source: manpages-fr Binary: manpages-fr manpages-fr-dev Architecture: source all Version: 3.44d1p1-1 Distribution: unstable Urgency: low Maintainer: Nicolas FRANCOIS (Nekral) nicolas.franc...@centraliens.net Changed-By: Simon Paillard spaill...@debian.org Description: manpages-fr - French version of the manual pages about using GNU/Linux manpages-fr-dev - French version of the development manual pages Changes: manpages-fr (3.44d1p1-1) unstable; urgency=low . * New release, based on manpages 3.44-1 and perkamon 3.44-1: + new manpages: getauxval.3 secure_getenv.3 * Translate debian specific modifications: + motd.5 updated and motd.tail removed: due to new behaviour of sysvinit 2.88dsf-24 + fputs.3: missing space in putc(c,stdout) + resolv.conf.5: Document IPv6 format for nameserver + stat.2: Clarify description of EOVERFLOW error Checksums-Sha1: 0a6d38bc0e60bc171cb9011673a2f42e333f2604 2933 manpages-fr_3.44d1p1-1.dsc 4c7ac0e9f44ba25cbd2cc92f8724d80565e185e3 672416 manpages-fr_3.44d1p1.orig-manpages-dev.tar.bz2 585c2849a915a605ebe3a0d0aa84a9565721de59 347080 manpages-fr_3.44d1p1.orig-manpages.tar.bz2 6d6f83c69f0d4fece0f297bbe9376891f446f15e 4060942 manpages-fr_3.44d1p1.orig-perkamon-fr.tar.bz2 9dc56ea767723602284d1e6323550ec0d7d58049 2828 manpages-fr_3.44d1p1.orig.tar.bz2 751a377faef5a12d107a0b1c91d53c606fc31f52 37503 manpages-fr_3.44d1p1-1.debian.tar.gz ee6e1f43e3196116e2c9f96ba35090eaa57dff6c 735130 manpages-fr_3.44d1p1-1_all.deb a8151680170675b99d9106a4dd7984ad9d2c94ec 2256366 manpages-fr-dev_3.44d1p1-1_all.deb Checksums-Sha256: 035c2181d8851214e124539099e40a2c4d38dd70b77aea1fe713ed1e454b2ed1 2933 manpages-fr_3.44d1p1-1.dsc 49a20a8205c2e1e153f5e5144c543e79c2aa3837052f3e31ae056683d027f403 672416 manpages-fr_3.44d1p1.orig-manpages-dev.tar.bz2 22a49b4a5eaa7ad73dc7e8aadc41ff742e4e1820a7b58f090134d68ea2a96fa5 347080 manpages-fr_3.44d1p1.orig-manpages.tar.bz2 97771c568ebc8d73578a4bb608020644a2f4c0a5adfbe4dc8ec58d526064e264 4060942 manpages-fr_3.44d1p1.orig-perkamon-fr.tar.bz2 67fceb544f2031ba1e5506a52f300e826954d93b0fa270fe8ab60e9e6504089c 2828 manpages-fr_3.44d1p1.orig.tar.bz2 473407d39e97964a2f279fe5e5f865bdc738a6261a12ee7958d9435fb1f0e697 37503 manpages-fr_3.44d1p1-1.debian.tar.gz 9a203d28a5239c5ad88b05299a03b3c456f5e45beec1a019fc92e6771043dbb2 735130 manpages-fr_3.44d1p1-1_all.deb 8ff704a43f07cf2467bb75f80cafe3ea71b53f599f0d1b2feb6c428d03340b64 2256366 manpages-fr-dev_3.44d1p1-1_all.deb Files: b5d567b4da29d3fa1cb43ba93031ed33 2933 doc optional manpages-fr_3.44d1p1-1.dsc fc2bb5f8724ddadd326f607ffe683036 672416 doc optional manpages-fr_3.44d1p1.orig-manpages-dev.tar.bz2 cfa013c8f2700816891862b9bf1d3b8a 347080 doc optional manpages-fr_3.44d1p1.orig-manpages.tar.bz2 2c97d88f8b87796ec8bdad56fd4e3d05 4060942 doc optional manpages-fr_3.44d1p1.orig-perkamon-fr.tar.bz2 08ceee798afa49962d35a4fd3dab81be 2828 doc optional manpages-fr_3.44d1p1.orig.tar.bz2 7d4c3c85d4c7905c270f5d2ecdd76a2c 37503 doc optional manpages-fr_3.44d1p1-1.debian.tar.gz a372ea83b7a49078f451a915a325ab16 735130 doc optional manpages-fr_3.44d1p1-1_all.deb 4c65dc3b9919022247e7815ce0375686 2256366 doc optional manpages-fr-dev_3.44d1p1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQt917AAoJEN/3OMLRbPuiHzoP/jnduBvPNdgiYjWPdgbEl0sG tbr46nKM0LoTrKJ8sxQfpYZtPPa6zRuS/yFvT9i9dRCnN5RWLpuULXqSLCQ6CsAo eqkJVQn5o2G3jkaxp5o7ii/lpJXU1QjWj0682AOwO3JMi8WuMF6pY7XKn4QWY7dD bIX4on7+xGS4Rpo7wCsrzoA6A9l8l0x9MKfkdjfTW0x8dmYHjUv+V0xix3xV6QNU Hcml3XWQVJ/TwTXdh5QmtYlwLikr7jWkzL1fz+n/U/EWmL5hhpnY+mFqraKZPpQD L72GxNRKVTZ+lSZ+ND+z+UmADzaYRjQRRajg7WyZuFRcjmJOqIsU7noelTmzUFS+ ORUUYuuFS2HcgsI2QoxOVsVHFhf/ATO2lwo3L6tI2FP2cL/uwqkMsO6zelm4lo8g aIDYNPOBsk7BIyq/FO0tSuI7UdazaardwmgbiZKpinaChvLuriC8N+5AUOYLV3tG vJ3whZtOENKlOPAdBHtbCAn8zxkEXmoUr15DdbAVxWlw5GEEnr7KoZnI6xlrYam0 6Et/ZXRoUhtPtcBHvY42apQxZdP4yiFWtH/A1JRf00Kf5QvF55/UYhqLvQpdhKK8 aemLhvIwfopTjSULdYqfsyMOxsRxt57Z45h+IzQVcKuNFxlM+91NdD2owUKYRpFH 9w8TMatkcYQDNurkC22X =sYx+ -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/e1tecqp-0003yq...@franck.debian.org
