Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote: On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org wrote: On 08/02/12 17:22, Aron Xu wrote: Some packages come with data files that endianness matters, and many of them are large enough to split into a separate arch:all package if endianness were not something to care about. AFAIK some maintainers are not aware of endianness issues in their packages and then just ignored it (not sure how many, but if any of them are discovered it should lead to RC bug). Hopefully Jakub Wilk's automatic checks for conflicting files http://people.debian.org/~jwilk/multi-arch/ will already be picking this up, in cases where the less-used-endianness architectures aren't broken already. If the less-used-endianness architectures are already broken, that's also a bug (potentially an RC one), just like code that compiles but doesn't work on a particular endianness due to other assumptions - and if nobody has noticed it yet, presumably the package doesn't have any users (or regression tests) on those architectures. Or some of them just gave up because it is less-used architecture. It would be great to have some mechanism to handle such kind of problems in Debian, to avoid forcing those data to be placed into arch:any package. If the right endianness is critical: libfoo:i386 Depends: libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be respectively? This looks not very nice, because we need to maintain a list of architectures in debian/control, and when new architectures are added the package is potentially broken. Also, arch:all packages are usually generated by the uploading DD on one architecture, mostly amd64 and i386 today, how can he managed to generate be data files if he doesn't have access to such a machine? Adding an option to the data generator/parser and make it able to generate be/le data on any architecture seems not to be a reasonable approach. Or just make sure the data has an endianness marker, and enhance the reading package to do the right byteswapping based on the endianness marker - e.g. this has been discussed for gettext, which ended up just writing out the same endianness on all platforms. Many formats (particularly those that originated on Windows) are always little-endian, and big-endian platforms reading them just take the minor performance hit; formats that respect network byte order have the opposite situation. This is valid for most-used applications/formats like gettext, images that are designed to behave in this way, but on the contrary there are upstream that don't like to see such impact, especially due to the complexity and performance impact. Currently I am using arch:any for data files which aren't be affected with multiarch, i.e. not same or foreign. For endianness-critical data that is required to make a library working, I have to force them to be installed into /usr/lib/triplet/$package/data/ and mark them as Multiarch: same, this is sufficient to avoid breakage, but again it consumes a lot of space on mirror. Actually, what is a lot here? I mean, how many libraries are there containing endianness-critical data and how big are the actual files? Not that I'm any kind of expert, but this solution sounds reasonable to me. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
history transparency
Hi there. Looking at advances in storage that are on the horizon coupled with advances with processing power, it would appear that something wonderful is on the horizon. It will be possible to build an entire Debian distribution in a matter of minutes. This capability requires no changes to the way Debian does things right now. But when it comes to old bug reports involving source packages in GIT or other version control systems, it's already the case that older C/C++ code won't compile due to advances and increasing strictness in compilers. Right now it's difficult/impossible to recreate a snapshot of Debian as it was (updates included) when the bug was reported. I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. With more and more source packages becoming available under publicly accessible version control, what needs to change in Debian to make this possible? Regards, Philip Ashmore -- 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/4f3387b6.10...@philipashmore.com
Re: history transparency
On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote: I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. With more and more source packages becoming available under publicly accessible version control, what needs to change in Debian to make this possible? Nothing, it already exists: http://snapshot.debian.org/archive/debian/20091229T215155Z/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6hlnhnrfsf5vsbmsbu79o_0h8-mhprpocxgp4+gy0v...@mail.gmail.com
Re: history transparency
On 09.02.2012 08:45, Philip Ashmore wrote: Right now it's difficult/impossible to recreate a snapshot of Debian as it was (updates included) when the bug was reported. I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. Like http://snapshot.debian.org/ , for instance? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/09830c12ff300691e77eb43968a1c...@mail.adsl.funky-badger.org
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use lots more space on single
arch installations.
Does it really?
A quick test tells me that uncompressing every file under /usr/share/doc
does indeed increase the size of that directory on my laptop by a factor
of approximately two:
After running sudo find /usr/share/doc -name '*.gz' -exec gunzip {} \;,
the size of that directory is as reported by 'du -s' is 1263220
kibibytes, while it was 757280 before, a difference of 505940.
This is on a system with 2524 packages installed, for a grand total
of...
dpkg-query -W -f '${Installed-Size}\n' | awk '{TOT+=$0} END{print TOT}'
8830371
... approximately 8.5GiB of installed software. While I agree that
adding around 500MiB to that installed size is significant, I wouldn't
define it as 'lots more space'. Additionally, it should be possible for
dpkg to support compressing at install time for those users who request
it, based on a configuration parameter.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
signature.asc
Description: Digital signature
Re: history transparency
On 09/02/12 09:00, Adam D. Barratt wrote: On 09.02.2012 08:45, Philip Ashmore wrote: Right now it's difficult/impossible to recreate a snapshot of Debian as it was (updates included) when the bug was reported. I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. Like http://snapshot.debian.org/ , for instance? Regards, Adam Never heard of it, or if I did, I didn't understand its significance - thanks! I guess the next thing to roll out in the future will be virtual machines representing Debians target architectures running acceptance tests on the snapshots before publication. Regards, Philip Ashmore -- 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/4f339079.3060...@philipashmore.com
MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)
Mark A. Hershberger (all his packages are co-maintained; Vincent, are you in contact with him?): mhershber...@intrahealth.org: host mail2.intrahealth.org[207.254.211.2] said: 550 No such user (mhershber...@intrahealth.org) (in reply to RCPT TO command) Reporting-MTA: dns; mail.nic.cz X-Postfix-Queue-ID: BD6A22A3086 X-Postfix-Sender: rfc822; ondrej.s...@nic.cz Arrival-Date: Thu, 9 Feb 2012 10:00:34 +0100 (CET) Final-Recipient: rfc822; mhershber...@intrahealth.org Original-Recipient: rfc822;mhershber...@intrahealth.org Action: failed Status: 5.0.0 Remote-MTA: dns; mail2.intrahealth.org Diagnostic-Code: smtp; 550 No such user (mhershber...@intrahealth.org) Robert Jordens (all his packages are NMUed, so he is probably MIA) jord...@debian.org: host master.debian.org[70.103.162.29] said: 550 Unrouteable address (in reply to RCPT TO command) Reporting-MTA: dns; mail.nic.cz X-Postfix-Queue-ID: 3437C2A3107 X-Postfix-Sender: rfc822; ondrej.s...@nic.cz Arrival-Date: Thu, 9 Feb 2012 10:00:36 +0100 (CET) Final-Recipient: rfc822; jord...@debian.org Original-Recipient: rfc822;jord...@debian.org Action: failed Status: 5.0.0 Remote-MTA: dns; master.debian.org Diagnostic-Code: smtp; 550 Unrouteable address O. -- Ondřej Surý ond...@sury.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/caljhhg99spl4rbbjlvhimsjdzyhjk2m5tuo-juqo-sjkvhy...@mail.gmail.com
Re: Linux 3.2 in wheezy
m...@linux.it (Marco d'Itri) writes: On Jan 30, Holger Levsen hol...@layer-acht.org wrote: http://blog.bofh.it/debian/id_413 would you mind filing a bug about this?! Refering to your blog post is nice, Yes, since the upstream maintainers do not consider this to be a bug. -- ciao, Marco There are also non-malicious use cases for this: binfmt-misc. Would be nice if the binfmt-misc config would be per namespace too MfG Goswin -- 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/874nv0tk6v.fsf@frosties.localnet
Re: Bug#605090: Linux 3.2 in wheezy
Yves-Alexis Perez cor...@debian.org writes: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? Regards, -- Yves-Alexis Don't forget to set Build-With: in the resulting binary package. That ensure DAK will keep the right linux-source package around as long as your package is in the repository. Otherwise you will have GPL violations. MfG Goswin -- 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/87zkcss5e4.fsf@frosties.localnet
Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)
Le 09.02.2012 10:15, Ondřej Surý a écrit : Mark A. Hershberger (all his packages are co-maintained; Vincent, are you in contact with him?): I have done the latest uploads for php-mdb2 packages. I suppose you want me to drop php-mdb2-driver-sqlite package? -- 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/f29a710105652e84ea7b5d3f34f9f...@luffy.cx
Re: essential and transitivly-essential
Bernhard R. Link brl...@debian.org writes: My proposal is still: - Add a new priority essential for the must always be available (so this is what in a bootstrap is unpackaged manually). Require that Priority essential packages only depend on Priority essential, so this is the new transitively-essential set. - Reduce Essential: yes with Priority: required to mean only that cannot be removed easily. So things like mount or initscripts must not be unpacked twice and available in every buildd chroot. - Reduce the set of does not need depended on to Essential: yes and Priority: essential. Bernhard R. Link Don't forget about awk. Awk is quasi-essential but it can come from gawk or mawk. MfG Goswin -- 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/87vcngs54k.fsf@frosties.localnet
Re: DEP-5 and files with white spaces
Benjamin Drung bdr...@debian.org writes: Am Mittwoch, den 01.02.2012, 14:20 -0800 schrieb Russ Allbery: Benjamin Drung bdr...@debian.org writes: DEP-5 is nice, but how can I specify a license for a file with white spaces? For example you want to specify that the file foo/file one.bar is licensed under ISC, but foo/file_one.bar is licensed under GPL. How can you do that? No, that distinction isn't representable. There was some earlier discussion about that, and the conclusion reached was that it was a rare case that wasn't worth making the syntax more complicated (after various more complicated syntaxes were tossed around without making anyone very happy). Is it to complex to have a syntax that is similar to what the shell does? Two solutions pop into my mind. Please let me know, why these are not use. You can point me to previous discussions. Idea 1: Use a escape sequence for specifying a whitespace (e.g. \ for a space). Idea 2: Allow quotation marks. Not a solution on its own. What about a file named foo bar' baz? For a worst case what about files with newlines? MfG Goswin -- 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/87r4y4s4v7.fsf@frosties.localnet
Re: Versionned dependencies
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Packages can currenctly declared dependencies on specific versions of other packages, with simple relations: , =, =, = and . For instance: Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13) | iceape (= 2.1) | ⦠While this is sufficient for most cases, it does not cover one interesting case: a dependencies on a range of versions. For instance: Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13, 12.0~a1+) | iceape (= 2.1, 2.9~a1+) | ⦠That is just a Depends: iceweasel (= 3.6.13) | iceape (= 2.1), iceweasel ( 12.0~a1+) | iceape (= 2.1), iceweasel (= 3.6.13) | iceape ( 2.9~a1+), iceweasel ( 12.0~a1+) | iceape ( 2.9~a1+) Because this kind of conceptual dependency cannot be expressed¹, what is currently done is: Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13) | iceape (= 2.1) | ⦠Breaks: iceweasel (= 12.0~a1+), iceweasel ( 3.6.13), iceape (= 2.9~a1+), iceape ( 2.1) which is not accurate and has unwanted since it declares conflicts whith other package versions that do not really conflict but only do not satisfy the real dependency. That could be shortened to: Depends: iceweasel (= 3.6.13) | iceape (= 2.1) Breaks: iceweasel (= 12.0~a1+), iceape (= 2.9~a1+) There is another solution: Dummy packages (build by xul-ext-adblock-plus) Package: xul-ext-adblock-plus Depends: xul-ext-adblock-plus-iceweasel | xul-ext-adblock-plus-iceape Package: xul-ext-adblock-plus-iceweasel Depends: iceweasel (= 3.6.13), iceweasel ( 12.0~a1+) Package: xul-ext-adblock-plus-iceape Depends: iceape (= 2.1), iceape ( 2.9~a1+) I'm not saying that is the way to do it but it is a possibility. In practice, this causes problems such as #653302: installing xul-ext-adblock-plus removes iceape just because the current packaged version of iceape cannot take advantage of adblock-plus. Why does it remove it? Or rather in which situations? A simple upgrade or dist-upgrade should keep back the package rather than remove iceape. Obviously if you force the issue it will remove iceape but that then is your own fault. I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. This might be a bug in the frontent rather than xul-ext-adblock-plus. I would like to hear your opinions on that subject. Independently of the Mozilla extension context, I think that double-versionned dependency make as much sense as simple versionned ones. Or, in other words, if a piece of software can depend on some other one's versions superior to X, or inferior to Y, it could very well depend on versions superior to X and inferior to Y, and I do not see a reason why we should not be able to represent that. Note: ¹ Technically, it could be expressed by expanding it according to de Morgan's laws, but the result would be a huge and complicated dependency list, which would probably give a hard time to dependency solvers. It grows exponentially but for 2 packages that is still ok. MfG Goswin -- 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/87mx8ss48i.fsf@frosties.localnet
Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]
On Wed, 08 Feb 2012, Michael Biebl wrote: As mentioned, a simple Replaces in the newly split-off package is not sufficient, as you will have obsolete conffiles, in case the new split-off package is not installed. I've seen this problem a couple of times and I thought it would be worthwile getting a best practice for this case documented. Thinking a bit more about it could be handled with a conditional dpkg-maintscript-helper rm_conffile that verifies who owns the file currently. preinst: if out=$(dpkg-query --search $CONF 2/dev/null); then pkg=$(echo $out | sed -s 's/: .*//') if [ $pkg = sysvinit-utils ]; then dpkg-maintscript-helper rm_conffile $CONF version sysvinit-utils -- $@ fi fi and you're doing the same in postinst and postrm except that in postinst you extend it to deal with the case where the command was initiated but not completed (this is a layer violation and thus this whole logic should be integrated in dpkg-maintscript-helper itself). postinst: if out=$(dpkg-query --search $CONF 2/dev/null); then pkg=$(echo $out | sed -s 's/: .*//') if [ $pkg = sysvinit-utils ]; then dpkg-maintscript-helper rm_conffile $CONF version sysvinit-utils -- $@ else if [ -e $CONF.dpkg-remove ]; then rm $CONF.dpkg-remove fi if [ -e $CONF.dpkg-backup ]; then # XXX: we could also want to replace $CONF to reinstate the # modified conffile mv $CONF.dpkg-backup $CONF.dpkg-bak fi fi fi This needs some tests of course and should ideally be integrated in dpkg-maintscript-helper as a separate command (rm_conffile_if_owner). There are also some edge cases that require some attention (like the fact that the output of dpkg-query --search on diverted file takes several lines). Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20120209095814.ga3...@rivendell.home.ouaza.com
Re: Versionned dependencies
Goswin von Brederlow, 2012-02-09 11:14+0100: Tanguy Ortolo tanguy+deb...@ortolo.eu writes: While this is sufficient for most cases, it does not cover one interesting case: a dependencies on a range of versions. For instance: Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13, 12.0~a1+) | iceape (= 2.1, 2.9~a1+) | … That is just a Depends: iceweasel (= 3.6.13) | iceape (= 2.1), iceweasel ( 12.0~a1+) | iceape (= 2.1), iceweasel (= 3.6.13) | iceape ( 2.9~a1+), iceweasel ( 12.0~a1+) | iceape ( 2.9~a1+) For two packages, yes, but as you noticed, it grows exponentially with the number of packages. More specifically, the number of dependencies as developped with de Morgan's laws is 2^n here. There is another solution: Dummy packages (build by xul-ext-adblock-plus) Package: xul-ext-adblock-plus Depends: xul-ext-adblock-plus-iceweasel | xul-ext-adblock-plus-iceape Package: xul-ext-adblock-plus-iceweasel Depends: iceweasel (= 3.6.13), iceweasel ( 12.0~a1+) Package: xul-ext-adblock-plus-iceape Depends: iceape (= 2.1), iceape ( 2.9~a1+) I'm not saying that is the way to do it but it is a possibility. Yes, a possibility which has other interesting advantages, although it may be difficult to implement. Why does it remove it? Or rather in which situations? A simple upgrade or dist-upgrade should keep back the package rather than remove iceape. Obviously if you force the issue it will remove iceape but that then is your own fault. I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. This might be a bug in the frontent rather than xul-ext-adblock-plus. No, you are correct by saying that a simple upgrade or safe-upgrade will not remove it, but holding back a package for that reason is still a problem, and anyway the incompatibility will be problematic for a stable Debian release. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Tanguy | `-'Debian Developer \_ -- 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/jh07bk$lft$2...@dough.gmane.org
Re: Description-less Packages indices
Martin Eberhard Schauer martin.e.scha...@gmx.de writes: The changes have ill side-effects: - DDTP/DDTSS is partially broken (1). The Database has $(nr_of_packages) new entrys since 01-22 containing just the short description. - These (untranslated) one-liners is what one gets visiting (2), e.g. (3). - There are no new Translation-xx files (4). - In (5) there is the link why it was done: (6). IMHO one part of the reasoning is not really convincing. ... and also enables non-English-speaking users (and eventually multi-arch enabled APT) to save on download size, as they no longer need to download a language that is of no use to them or is already there. But I need to download binary-amd64/Packages, binary-i386/Packages, binary-armel/Packages, binary-mipsel/Packages. That is 4 times nearly identical sets of long descriptions. Now I only need to download the english translation once. Actually most of the users have to read the English descriptions. Only Italian people are lucky enough to have more than 55% translated. Cheers, Martin 1: http://lists.debian.org/debian-i18n/2012/02/msg7.html 2: http://packages.debian.org 3: http://packages.debian.org/search?searchon=nameskeywords=manpages-de 4: http://ftp.debian.org/debian/dists/sid/main/i18n/ 5: http://lists.debian.org/debian-devel/2012/01/msg00614.html 6: http://lists.debian.org/debian-devel/2011/11/msg00103.html MfG Goswin -- 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/87ipjgs3de.fsf@frosties.localnet
Re: history transparency
On 02/09/2012 10:23 AM, Philip Ashmore wrote: I guess the next thing to roll out in the future will be virtual machines representing Debians target architectures running acceptance tests on the snapshots before publication. images can be built by pointing to specific urls of snapshot.d.o used as mirror sources for live-build. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- 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/4f33a194.1070...@progress-technologies.net
Re: Please test gzip -9n - related to dpkg with multiarch support
Josh Triplett j...@joshtriplett.org writes: The only downside that I can see: packages couldn't refer to a particular file under /usr/share/doc/$package/ by path, because those packages wouldn't know how the administrator might choose to compress their files. Given the policy of not depending on files under /usr/share/doc/ to function, at most this will result in manpages and similar referencing paths that then need a .gz or .xz appended, and that doesn't seem like a big deal; people will cope and tools can learn to check for compressed variants. We already have this situation with dh_compress, which compresses files if it saves space. I had cases where between releases a file would end up sometimes compressed and sometimes not. And that file was mentioned in the README. I decided to just refer to the file without .gz extention and figured users would be smart enough to find it. MfG Goswin -- 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/87ehu4s2xc.fsf@frosties.localnet
Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)
Vincent Bernat ber...@debian.org (09/02/2012): I have done the latest uploads for php-mdb2 packages. I suppose you want me to drop php-mdb2-driver-sqlite package? From #debian-release's backlog, it seems likely. Mraw, KiBi. signature.asc Description: Digital signature
Re: Comments on introducing a new Essential package: base-init?
On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote: sysvinit is currently Essential. Why do we need an init as essential anyway? It is used in all real systems, but not chroots or other special systems. This makes it similar to the kernel, which does not even have a high priority. where init is a virtual package provided by all packages providing /sbin/init. The interface provided by sysvinit is much more then /sbin/init. (I note that it currently has no depends other than a pre-depends on awk.) And awk is not even a real package. Bastian -- ... freedom ... is a worship word... It is our worship word too. -- Cloud William and Kirk, The Omega Glory, stardate unknown -- 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/20120209105001.ga16...@wavehammer.waldi.eu.org
Re: Please test gzip -9n - related to dpkg with multiarch support
Adam Borowski kilob...@angband.pl writes: On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote: For those not subscribed to that bug, how to reproduce[1] and possible fix[2] are available now. There might be other places where buffers are reused, I only spent a few minutes on this during my lunch break. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Even if you ensure a particular build behaves exactly the same on a given architecture, you're merely introducing future problems. gzip's output is likely to change: * on a new version Yes, but not a big problem (other than a small race condition) since all buildds should have the same version. * after a bugfix (including security ones) Yes, but not a problem (other than a small race condition) since all buildds should have the same version. * on a different architecture No. I consider that a bug. * with different optimizations Not a problem. * with a different implementation (like those parallel ones) Not a problem (yet). We only have one gzip. pigz doesn't replace gzip. * possibly with a different moon phase No. I consider that a bug. Especially the first is pretty guaranteed to bite: whenever the upstream does a small improvement, binaries in the archive get invalidated until rebuilt with the new gzip. Not true. Packages only break if they are build with one gzip on one arch and another on other archs. On gzip uploads there is a window where archs will have different gzip versions so this is of some concern. But not as bad as you make it look. Breaking the ideas for diverting /bin/gzip by pigz is not nice, too. True. But why should gzip and pigz give different output? They should be able to result in the same compressed output. I think for pigz one problem is where to split the input. Making it split at the same points as gzip --rsyncable does (and using that option in gzip) could be a solution. Or files in /usr/share/doc (where we have the collisions) could be compressed with /usr/bin/gzip.gzip (assuming that would be the name of the real binary providing the gzip alternative). MfG Goswin -- 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/87aa4ss20y.fsf@frosties.localnet
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 01:33:58AM +, Wookey wrote: Some of the issues are already clear I think (moving arch-dependent headers into arch-qualified dirs, but leaving the others where they are) And what is considered the best way to share the architecture–independent headers between M-A: same -dev packages? Install them in all packages, and let dpkg handle the conflicts? I still don’t feel very confortable doing so, and it would cause an increase in the archive size. Or ship them in a separate Arch: all -dev-common package, which all the other -dev packages depend on? This would ensure a single copy of the headers is present in the archive, but it would also add yet another binary package per library to the Packages file… -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Comments on introducing a new Essential package: base-init?
On 09.02.2012 11:50, Bastian Blank wrote: On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote: sysvinit is currently Essential. Why do we need an init as essential anyway? It is used in all real systems, but not chroots or other special systems. This makes it similar to the kernel, which does not even have a high priority. I also think that simply dropping the Essential flag is how we should address this. The priority of sysvinit would make sure that is installed as the default init (similar to how we handle the default syslog daemon). If it is a concern that people make accidentally uninstall their /sbin/init and render their system un-booteable, we could add a warning to postinst similar to how the kernel does it. Or are there other reasons why sysvinit needs to be essential? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
Guillem Jover guil...@debian.org writes: On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote: In practice, the only compressor we need to care is gzip, which is not actively maintained upstream[0]. Chances that a new version of it will break large number of packages are minute. That assumes that we will never want to switch to a better/faster compressor for any gzip compressed file. Or that there's no existing files compressed with anything other than gzip. But anyway, I believe that in the long run we should simply deprecate compressing stuff in /usr/share/doc/. So the main reason people are arguing for shared files boils down to used size, either in installed files, or Packages files, etc, yet you want to fix the compression issue by not compressing them and using even more space? While this could benefit the multiarch installations (for which they can easily use --path-exclude), it would use lots more space on single arch installations. Also splitting files into new arch:all packages should usually reduce archive size usage for example. regards, guillem There are 2 cases to consider here: 1) Lots of data in /usr/share/doc/ Please do split them into an arch:all package. 2) Tiny amount of data in /usr/share/doc/ Policy requires that we have a Changelog there and those are usualy large enough to benefit from compression but not large enough to warant their own -common package. Adding one or two other small files as docs usualy doesn't pass the thresshold for splitting them into -common too. Now those are our problem cases where we need identical compression. But if it is such a tiny amount then keeping it uncompressed should be reasonably fine. Systems where those few extra kib make a difference probably want to --path-exclude /usr/share/doc. There could also be a new option --path-compress compresor path that would compress any file below that path with the given compressor. So my suggestion would be twofold: 1) encourage splitting stuff into -common packages or 2) leave files uncompressed in MA:same packages MfG Goswin -- 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/8762fgry94.fsf@frosties.localnet
Re: Please test gzip -9n - related to dpkg with multiarch support
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Re: Please test gzip -9n - related to dpkg with multiarch support): Another possible solution is to just give any package an implicit Replaces (possibly constrained to /usr/share/doc) on any other package with the same name and version and a different architecture. This isn't as defensive, in that it doesn't catch legitimate bugs where someone has made a mistake and the packages contain different contents, but it also solves the binNMU issue (well, solves; the changelog will randomly swap back and forth between the packages, but I'm having a hard time being convinced this is a huge problem). Well, it does mean that you might be lacking important information because the other changelog wouldn't be present on the system. One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Ian. Or dpkg could do that for you. At least for files in /usr/share/doc when there is a collision. MfG Goswin -- 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/871uq4rxzq.fsf@frosties.localnet
Use of the first person in messages from the computer
I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: - If you approve, I will edit /etc/X11/app-default/XTerm for you, and - save your old file as XTerm.backup.not-trad. (Note that this is a - conffile so you may get prompts from dpkg about it in the future.) The suggested alternative from the reviewer: + If you choose this option, /etc/X11/app-default/XTerm will be modified + and the old file will be kept as XTerm.backup.not-trad. [...] Good plain English style is to use the simplest constructions and sentences that will serve, including avoiding needless use of the passive voice. This is not just my opinion. The Plain English Campaign[1] howto guide's[2] 2nd and 3rd bullet points on the summary page are: * Prefer active verbs * Use `you' and `we' Also relevant is their guide to (paper) forms[3], which contains this imprecation: * Make it personal Use `you' rather than, for instance, `the applicant' [etc.] Use `we' rather than, for instance, `the council' [etc.] I don't know where the English l10n team got the idea from that there is something wrong with a computer speaking to the user in the first person. But in my opinion this criticism is entirely misplaced. I would suggest that, in general, I would refer to the computer (or some part of it, as demanded by context). It should be used whenever the meaning is clear. You can see an example which I think is correct, above. I think we would usually refer to the authors of the software. Again, it should be used where appropriate. For example we recommend is a lot better than it is recommended. That's not to say that every use of the first person is correct, of course. It should always be clear who the putative speaker is. And I think it is incorrect to use the first person singular when writing as the software author, because Free Software is a collaborative enterprise: the authors are always in principle collective and thus plural even if in practice there is a principal or single human author. My reviewer also seems to think there is (sometimes?) something wrong with the use of the second person to refer to the user or the owner of the system. For example: - Optionally, this package will edit your system configuration to make + Optionally, this package will edit the system's configuration to make the default fonts used by xterm refer to the traditional font. Unpersonnalize. Again, I think my version is clearer, and also adds (appropriately) more emphasis to the fact that the configuration that is being edited is system-wide. The advice to unpersonnalize (sic) is directly contrary to what I think is very good advice from the Plain English Campaign. Finally, the reviewer revealed in the review that they're not a native speaker of English. Is it normal for l10n reviews to be conducted by non-native speakers of the target language ? Are we really so short of native English speaking l10n reviewers ? If so I would be happy to help (although you may find me too opinionated...) PS I have not named the reviewer because I get the impression that the matters I'm questioning are general practice in the English l10n team, so I don't want to make any personal criticism of the reviewer. Ian. [1] http://www.plainenglish.co.uk/ [2] http://www.plainenglish.co.uk/files/howto.pdf [3] http://www.plainenglish.co.uk/files/formsguide.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/20275.47606.843838.52...@chiark.greenend.org.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
Steve Langasek vor...@debian.org writes: - For many of these files, it would be actively harmful to use architecture-qualified filenames. Manpages included in -dev packages should not change names based on the architecture; having /usr/share/pam-config contain multiple files for the same profile, one for each architecture of the package that's installed, would not work correctly; etc. Appropos pam config. Shouldn't that be arch-qualified (which includes /etc)? Say I have pam modules for ldap installed for amd64 but not for armel? MfG Goswin -- 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/87ty30qiwm.fsf@frosties.localnet
Re: Use of the first person in messages from the computer
On 2012-02-09 13:20, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: [...] I suspect devref 6.5.2.5 is a (possible) source of this impression. As I recall, there are also some Lintian checks about using first person. ~Niels -- 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/4f33beca.4070...@thykier.net
Re: Endianness of data files in MultiArch
Aron Xu happyaron...@gmail.com writes:
On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org wrote:
On 08/02/12 17:22, Aron Xu wrote:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK some maintainers
are not aware of endianness issues in their packages and then just
ignored it (not sure how many, but if any of them are discovered it
should lead to RC bug).
Hopefully Jakub Wilk's automatic checks for conflicting files
http://people.debian.org/~jwilk/multi-arch/ will already be picking
this up, in cases where the less-used-endianness architectures aren't
broken already.
If the less-used-endianness architectures are already broken, that's
also a bug (potentially an RC one), just like code that compiles but
doesn't work on a particular endianness due to other assumptions - and
if nobody has noticed it yet, presumably the package doesn't have any
users (or regression tests) on those architectures.
Or some of them just gave up because it is less-used architecture.
It would be great to have some mechanism to
handle such kind of problems in Debian, to avoid forcing those data to
be placed into arch:any package.
If the right endianness is critical: libfoo:i386 Depends:
libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data
packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be
respectively?
I would have them conflict and use the same directory. Otherwise you
need to use different paths in the binary, docs and maybe even
conffiles (which would then be architecture dependend too).
This looks not very nice, because we need to maintain a list of
architectures in debian/control, and when new architectures are added
the package is potentially broken.
If endian dependend data is really a larger issue then introduce a
dpkg-architecture -qDEB_HOST_ENDIANESS
Also, arch:all packages are usually generated by the uploading DD on
one architecture, mostly amd64 and i386 today, how can he managed to
generate be data files if he doesn't have access to such a machine?
Adding an option to the data generator/parser and make it able to
generate be/le data on any architecture seems not to be a reasonable
approach.
That is indeed the biggest problem currently. Also a problem for the
idea of building arch:all packages on buildds. They might not build on
all archs.
Or just make sure the data has an endianness marker, and enhance the
reading package to do the right byteswapping based on the endianness
marker - e.g. this has been discussed for gettext, which ended up just
writing out the same endianness on all platforms. Many formats
(particularly those that originated on Windows) are always
little-endian, and big-endian platforms reading them just take the minor
performance hit; formats that respect network byte order have the
opposite situation.
This is valid for most-used applications/formats like gettext, images
that are designed to behave in this way, but on the contrary there are
upstream that don't like to see such impact, especially due to the
complexity and performance impact.
Currently I am using arch:any for data files which aren't be affected
with multiarch, i.e. not same or foreign. For endianness-critical
data that is required to make a library working, I have to force them
to be installed into /usr/lib/triplet/$package/data/ and mark them
as Multiarch: same, this is sufficient to avoid breakage, but again
it consumes a lot of space on mirror.
I thought about something like /usr/share/$package/data/{be,le} in
arch:all, but appears to be not a reasonable solution because we need
to modify the data generator/parser.
It should be possible to build a converter or generator that can output
either endianess. So you could have a single arch:all package with both
/usr/share/$package/data/{be,le} in it or to generate the right
endianness on install. That way the performance impact argument is non
existant.
MfG
Goswin
--
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/87pqdoqict.fsf@frosties.localnet
Re: Please test gzip -9n - related to dpkg with multiarch support
Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with multiarch support): Ian Jackson ijack...@chiark.greenend.org.uk writes: One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Or dpkg could do that for you. At least for files in /usr/share/doc when there is a collision. Urgh, I think this is a really ugly idea, compared to just having the packages contain the arch-specific filenames. After all a multiarch:same package knows that it is, and can DTRT. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20275.48825.356091.885...@chiark.greenend.org.uk
Re: Endianness of data files in MultiArch
On Thu, 2012-02-09 at 13:52:34 +0100, Goswin von Brederlow wrote: Aron Xu happyaron...@gmail.com writes: This looks not very nice, because we need to maintain a list of architectures in debian/control, and when new architectures are added the package is potentially broken. If endian dependend data is really a larger issue then introduce a dpkg-architecture -qDEB_HOST_ENDIANESS This already exists: DEB_BUILD_ARCH_ENDIAN and DEB_HOST_ARCH_ENDIAN regards, guillem -- 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/20120209125803.ga12...@gaara.hadrons.org
Re: Comments on introducing a new Essential package: base-init?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 09.02.2012 13:09, Michael Biebl wrote: On 09.02.2012 11:50, Bastian Blank wrote: On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote: sysvinit is currently Essential. Why do we need an init as essential anyway? It is used in all real systems, but not chroots or other special systems. This makes it similar to the kernel, which does not even have a high priority. not objecting the idea by itself, please bear in mind this would turn thousands of packages RC buggy immediately, as they all need to declare a dependency against (an) init script given they rely on a init script for functionality then. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPM8flAAoJEMcrUe6dgPNtkR0P/2Hw3O30Hrs3HqhzIWkKXnCi PybdNUJe4AH+UGNEyR/sexwxt5CYAt6sJnEt978eAvU1MrpEC8VdP81cCdGApoWP UrWfnk0qwc181jL170ha62KE0c6hXPDjnUu4Z/iL3wcPDF/SJLDzy8FyEEwyxrbX i2HMzIXA+eK6WwLfUbFxYerlJD1qH0Gz0OTHfe9zibn56HZ2TIJDp1tqMRz4uTDH S7kMhYAVuPAmBIZuBfcwmKqut9aYArdyRijpqqfDdEvrVkDyhZf7d8p0bmAHeOOx +dkMb2nA0fKdB5SAALZiJHO+5R00E8fslQTHTgTlsAOzKB29zCwdlDmay8lOF0Ly 4kGXT4BkcqUw4JsE27Fjhfn9KditNkkDhKF5mCu8iB7h5MXw+HGr3uAhXH75C9Sg pRS9kq12QuwWnNotedQM+u4mVi+mH76oaWbeY9f0Bas5srzWGgpRrDeuGaVMVYTw w2p+NrnqWlj/kxS02BYvytI+SW1rEVqE29rojU8yOsc3dOPR+tz3raFJFYzD6XmY hC4Zm59Prxm4z8jZ4ijGo5YolzkJA3v+tBCqo3u+rZ4PvWJtYYN+5h/bK9vTbxZn titDow8p4rWPH20GusetnQ0GufSEzIYShkY7oNj68fd2M6pYaB6WSGXYFuUHbaeA bCO2gcnGlOMJ2cQ0wQND =LZA3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f33c7e5.1070...@toell.net
Re: Use of the first person in messages from the computer
On Thu, Feb 09, 2012 at 01:40:42PM +0100, Niels Thykier wrote: On 2012-02-09 13:20, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: [...] I suspect devref 6.5.2.5 is a (possible) source of this impression. As I recall, there are also some Lintian checks about using first person. The computer is not a person. IMO, the use of first-person personal pronouns such as I grate badly in the context of being used by the computer. By all means refer to the user this way (e.g. you), but I don't think Ian's opinion on the use of I is by any means universal. It's by no means wrong, but I think such uses could be phrased better. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120209132908.gm8...@codelibre.net
Re: Use of the first person in messages from the computer
On Thu, Feb 09, 2012 at 12:20:06PM +, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. Well, by Christian Perrier; nobody else has had a chance to reply yet. If people with opinions on this topic want to join the d-l-e team, which mostly seems to consist of me and Christian, please do! The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: - If you approve, I will edit /etc/X11/app-default/XTerm for you, and - save your old file as XTerm.backup.not-trad. (Note that this is a - conffile so you may get prompts from dpkg about it in the future.) (Side note: isn't that a Policy 10.7.4 must not violation anyway?) The suggested alternative from the reviewer: + If you choose this option, /etc/X11/app-default/XTerm will be modified + and the old file will be kept as XTerm.backup.not-trad. [...] Good plain English style is to use the simplest constructions and sentences that will serve, including avoiding needless use of the passive voice. This is not just my opinion. The Plain English Campaign[1] howto guide's[2] 2nd and 3rd bullet points on the summary page are: * Prefer active verbs Often good advice. Occasionally ignorant superstition. * Use `you' and `we' Also relevant is their guide to (paper) forms[3], which contains this imprecation: * Make it personal Use `you' rather than, for instance, `the applicant' [etc.] Use `we' rather than, for instance, `the council' [etc.] I don't know where the English l10n team got the idea from that there is something wrong with a computer speaking to the user in the first person. But in my opinion this criticism is entirely misplaced. Notice that Christian's text *does* use you, and the Plain English Campaign *doesn't* recommend I. I would suggest that, in general, I would refer to the computer (or some part of it, as demanded by context). It should be used whenever the meaning is clear. You can see an example which I think is correct, above. It could mean debconf, or xfonts-traditional, or Ian, or some upstream author, or an animated paperclip; and there's nothing much in the context to help readers sort this out. I think we would usually refer to the authors of the software. Again, it should be used where appropriate. For example we recommend is a lot better than it is recommended. You probably think that because you're used to speaking as the author of software. But I'm pretty sure ordinary end users are *not* thinking of you when they run apt-get, and you really can't expect them to naturally interpret it your way. That's not to say that every use of the first person is correct, of course. It should always be clear who the putative speaker is. And I think it is incorrect to use the first person singular when writing as the software author, because Free Software is a collaborative enterprise: the authors are always in principle collective and thus plural even if in practice there is a principal or single human author. My reviewer also seems to think there is (sometimes?) something wrong with the use of the second person to refer to the user or the owner of the system. For example: - Optionally, this package will edit your system configuration to make + Optionally, this package will edit the system's configuration to make the default fonts used by xterm refer to the traditional font. Unpersonnalize. Again, I think my version is clearer, and also adds (appropriately) more emphasis to the fact that the configuration that is being edited is system-wide. The advice to unpersonnalize (sic) is directly contrary to what I think is very good advice from the Plain English Campaign. We should make the English we use as simple as possible, but no simpler. The problem with questions like do you wish to do this to your computer is that the reader may be reluctantly following site policy on the company server; paring it down to a decision about what should be done on the computer makes it more likely to be appropriate. Still, when this policy leads to unwieldy English I usually argue for just using second person - I don't have any problem with referring to the reader as you. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- 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/20120209130619.ga32...@xibalba.demon.co.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
Wouter Verhelst wou...@debian.org writes:
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use lots more space on single
arch installations.
Does it really?
A quick test tells me that uncompressing every file under /usr/share/doc
does indeed increase the size of that directory on my laptop by a factor
of approximately two:
After running sudo find /usr/share/doc -name '*.gz' -exec gunzip {} \;,
the size of that directory is as reported by 'du -s' is 1263220
kibibytes, while it was 757280 before, a difference of 505940.
This is on a system with 2524 packages installed, for a grand total
of...
dpkg-query -W -f '${Installed-Size}\n' | awk '{TOT+=$0} END{print TOT}'
8830371
... approximately 8.5GiB of installed software. While I agree that
adding around 500MiB to that installed size is significant, I wouldn't
define it as 'lots more space'. Additionally, it should be possible for
dpkg to support compressing at install time for those users who request
it, based on a configuration parameter.
Note that only a fraction of that would be in MA:same packages.
Everything else can stay compressed. Some other test (see other mails in
thread) estimated an increase of 60MB.
MfG
Goswin
--
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/87y5scp0ws.fsf@frosties.localnet
Re: Use of the first person in messages from the computer
On Thu, Feb 09, 2012 at 01:29:08PM +, Roger Leigh wrote: The computer is not a person. There there, havelock.liw.fi, don't listen to the *mean* man who says you're not a person. You are too a person! Tell you what, it's a magical Internet, ol' buddy... Let's go exploring! signature.asc Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
Ian Jackson ijack...@chiark.greenend.org.uk writes: Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with multiarch support): Ian Jackson ijack...@chiark.greenend.org.uk writes: One thing which no-one yet seems to have suggested is to have multiarch:same packages put the changelog in a filename which is distinct for each architecture. (It wouldn't have to be the triplet; the shorter Debian arch would do.) Perhaps there are obvious reasons (which I have missed) why this is a terrible idea, but it seems to me that it's something we should consider. Or dpkg could do that for you. At least for files in /usr/share/doc when there is a collision. Urgh, I think this is a really ugly idea, compared to just having the packages contain the arch-specific filenames. After all a multiarch:same package knows that it is, and can DTRT. Ian. Changing the name in the package would break tools that rely on the name (like packages.debian.org extracting the Changelog). Also ugly. MfG Goswin -- 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/87ty30p0re.fsf@frosties.localnet
Re: Comments on introducing a new Essential package: base-init?
On 09.02.2012 14:19, Arno Töll wrote: Hi, On 09.02.2012 13:09, Michael Biebl wrote: On 09.02.2012 11:50, Bastian Blank wrote: On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote: sysvinit is currently Essential. Why do we need an init as essential anyway? It is used in all real systems, but not chroots or other special systems. This makes it similar to the kernel, which does not even have a high priority. not objecting the idea by itself, please bear in mind this would turn thousands of packages RC buggy immediately, as they all need to We do have ~1200 init scripts belonging to ~1100 packages. declare a dependency against (an) init script given they rely on a init script for functionality then. I guess you are referring to the fact that initscripts would no longer by transitively-essential. Most sysv initscripts do not directly depend on services from initscripts, like mountall, mountkernfs, checkfs or checkroot. Actually, those direct dependencies in the LSB header are very rare and generally discouraged. What most if not all init scripts have in their LSB header, is a dependency on a virtual facility like $local_fs or $remote_fs. And those virtual facilities are only really interesting for insserv to calculate the start priorities. So maybe if insserv depends on initscripts that would be all that is needed. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Versionned dependencies
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Goswin von Brederlow, 2012-02-09 11:14+0100: Why does it remove it? Or rather in which situations? A simple upgrade or dist-upgrade should keep back the package rather than remove iceape. Obviously if you force the issue it will remove iceape but that then is your own fault. I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. This might be a bug in the frontent rather than xul-ext-adblock-plus. No, you are correct by saying that a simple upgrade or safe-upgrade will not remove it, but holding back a package for that reason is still a problem, and anyway the incompatibility will be problematic for a stable Debian release. Again I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. The problem here is that the packages only work with a certain combination of versions. Same as every single other versioned dependency. I don't see a problem for a stable Debian release there. MfG Goswin -- 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/87pqdop0kj.fsf@frosties.localnet
Re: Use of the first person in messages from the computer
Ian Jackson ijack...@chiark.greenend.org.uk I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. I'm not active within the l10n-english reviews for some time (see below) and while I agree with the comments about using the simplest constructions, I think there is something wrong with personifying the system. It hates that. While we can all engage in a huge discussion about what we like, that should be a last resort. Is there any research-based guidance about what is best for human/computer interaction? (for some value of best) Also relevant is their guide to (paper) forms[3], which contains this imprecation: * Make it personal Use `you' rather than, for instance, `the applicant' [etc.] Use `we' rather than, for instance, `the council' [etc.] This example is rather easier, because the author of the form is presumably part of the council or whatever, so the first person plural we is accurate. So, the example: - If you approve, I will edit /etc/X11/app-default/XTerm for you, and - save your old file as XTerm.backup.not-trad. (Note that this is a - conffile so you may get prompts from dpkg about it in the future.) would become something like: If you approve, we will change /etc/X11/app-default/XTerm for you, and save your old file as XTerm.backup.not-trad. (Note that this is a conffile, so you may get prompts from dpkg about it in the future.) where we would be the debian project contributors. After all, the computer is not doing anything on its own - it is just carrying out some instructions from the project as the user fills out a glorified form. It would be freaky if a council form said I, wouldn't it? My reviewer also seems to think there is (sometimes?) something wrong with the use of the second person to refer to the user or the owner of the system. [...] I disagree with making things impersonal for the sake of it, but I'd note that the user is not necessarily the system's owner, so I'm not sure about using the possessive. Finally, the reviewer revealed in the review that they're not a native speaker of English. Is it normal for l10n reviews to be conducted by non-native speakers of the target language ? Are we really so short of native English speaking l10n reviewers ? If so I would be happy to help (although you may find me too opinionated...) Yes, we are so short of native English speakers to do the reviews. Help would be welcome, but we probably should resolve the differences above as a first step, else it will just inflame things. However, personally, I feel we're short of reviewers because the review process requires too many resources - it expects reviewers to be online too often, sends too much email noise, has long delays and risks collisions at various steps. I think that's why there's only ever been about six reviewers AFAICS (of which, I think only half were first-language speakers), most of whom only did one review, and it's fallen to only one second-language reviewer since last August. Actually, I wondered what the review process is now. It's not on http://www.debian.org/international/ and nor is the l10n-english list and it's not mentioned in mails like http://lists.debian.org/debian-i18n/2012/02/msg00030.html but a later email http://lists.debian.org/debian-l10n-english/2012/02/msg00011.html did contain a link to http://wiki.debian.org/I18n/SmithDebconfReviewProcess It looks like there are some scripts now (one reason I dropped out, but I've not checked their functionality), but the process still seems no easier to track and there are still collisions, which both waste contributor effort and are sort-of related. I have not had time to try to bugfix the process and I don't really know where to start: the wiki page is immutable anyway (it might be editable if you are allowed to create an account, which some disabled developers are not, so I do not know). There's also an understandable resistence to lapsed contributors who try to bugfix debian's processes that work well enough, but maybe this one really is not working well enough. Thanks for your comments, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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/e1rvuio-0004g2...@petrol.towers.org.uk
Re: Versionned dependencies
Goswin von Brederlow, 2012-02-09 15:02+0100: Again I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. Well, with Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13, 12.0~a1+) | iceape (= 2.1, 2.9~a1+) you could install xul-ext-adblock-plus as long as you have a compatible version of iceweasel, even if you have an incompatible version of iceape. With the current implementation Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13) | iceape (= 2.1) Breaks: iceweasel (= 12.0~a1+), iceweasel ( 3.6.13), iceape (= 2.9~a1+), iceape ( 2.1) you cannot install xul-ext-adblock-plus if you have an incompatible version of iceape, even if you have a compatible version of iceweasel. Which is wrong. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Tanguy | `-'Debian Developer \_ -- 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/jh0l4f$7os$1...@dough.gmane.org
How to tell users that ia32-libs will go away
Hi, now that a multiarch dpkg has been uploaded to experimental it looks like we can finaly get rid of ia32-libs* for wheezy. !!!HURAY!!! The problem now is the transition: 1) multiarch and ia32-libs are incompatible Having multiarch packages and ia32-libs installed will lead to some confusion. The runtime linker will not be able to differentiate between multiarch or ia32-libs libs. One of /usr/lib32/ and /usr/lib/i486-linux-gnu/ will be first in the search path and libs will be taken from there preferably. As a result binaries might end up with the wrong version of a library and potentially break. As time goes on the problem will only get worse. What this means is that users that want to use multiarch should remove ia32-libs (and lib32* really) soonest. 2) How to inform the user that ia32-libs is no longer and what to do? I will do one more upload of ia32-libs to unstable to fix a number of critical issues that have collected over the last months. I don't intend to fix anything beyond that and nobody else seems to care enough to help. Therefore I intend to request removal of ia32-libs from wheezy shortly before the release. This gives me the chance to inform testing/unstable users of what is to come. Get more users to test multiarch as replacement for ia32-libs. Are there any objections to adding a debconf message to ia32-libs with a short message and reference to a Debian wiki page on how to transition to multiarch? 3) What about stable users? I don't see a way to transition stable users slowly. As said above I intent to request removal of ia32-libs for wheezy. So there will be no transition period where both ia32-libs and multiarch will be in stable. I guess it is then up to the release notes to tell users about multiarch and how to transition to that from ia32-libs. Hopefully by then the Debian wiki page will have been filled with lots of information that can be used to add to the release notes. 4) Should we have some Breaks/Conflicts between multiarch and bi-arch packages? The libc6:i386 package could Conflicts/Breaks: libc6-i386, ia32-libs-core and the libc6:amd64 package could Conflicts/Breaks: libc6-amd64. This would essentially prevent multiarch and bi-arch packages to be installed in parallel. Enabling multiarch and installing basically any foreign package would then automatically remove any bi-arch package. Given the file conflict on the ld.so between those packages it should be Conflicts or Breaks+Replaces actually. Thoughts? MfG Goswin -- 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/87ehu4oy6o.fsf@frosties.localnet
Re: Endianness of data files in MultiArch
Guillem Jover guil...@debian.org writes: On Thu, 2012-02-09 at 13:52:34 +0100, Goswin von Brederlow wrote: Aron Xu happyaron...@gmail.com writes: This looks not very nice, because we need to maintain a list of architectures in debian/control, and when new architectures are added the package is potentially broken. If endian dependend data is really a larger issue then introduce a dpkg-architecture -qDEB_HOST_ENDIANESS This already exists: DEB_BUILD_ARCH_ENDIAN and DEB_HOST_ARCH_ENDIAN regards, guillem Even better. Should have tested in a sid chroot. MfG Goswin -- 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/874nv0oxo4.fsf@frosties.localnet
Re: Use of the first person in messages from the computer
Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: - If you approve, I will edit /etc/X11/app-default/XTerm for you, and - save your old file as XTerm.backup.not-trad. (Note that this is a - conffile so you may get prompts from dpkg about it in the future.) The suggested alternative from the reviewer: + If you choose this option, /etc/X11/app-default/XTerm will be modified + and the old file will be kept as XTerm.backup.not-trad. [...] Good plain English style is to use the simplest constructions and sentences that will serve, including avoiding needless use of the passive voice. First of all, as pointed out elsewhere in the thread but not linked: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#s6.5.2.5 That recommendation does also say However, try using active voice if still possible, and I'd agree that the patch above needlessly uses the passive voice. How about: Choosing this option will modify /etc/X11/app-default/XTerm, preserving the old file as XTerm.backup.not-trad. Simpler and shorter than either your original and the patched version, with no passive voice and no I. More importantly, this removes a layer of indirection: rather than saying that you want to take some action with the user's approval, you effectively say that the user performs the action by choosing the option, leaving the software in the role of a tool the user uses to perform the action. That seems like the kind of thinking we want to encourage: users do things, software helps. In general I don't see anything wrong with you in most circumstances, though I think phrases like this system seem clearer and less ambiguous than your system. However, I agree entirely with the recommendation in the developer's reference to avoid I or we. - Josh Triplett -- 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/20120209145415.GA13354@leaf
Re: How to tell users that ia32-libs will go away
Goswin von Brederlow, le Thu 09 Feb 2012 15:53:35 +0100, a écrit : 3) What about stable users? I don't see a way to transition stable users slowly. As said above I intent to request removal of ia32-libs for wheezy. So there will be no transition period where both ia32-libs and multiarch will be in stable. Can't we keep an ia32-libs package which is empty and just depends on the corresponding multiarch packages? Samuel -- 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/20120209150126.gq4...@type.u-bordeaux.fr
Re: Use of the first person in messages from the computer
On Fri, 10 Feb 2012, Lars Wirzenius l...@liw.fi wrote: On Thu, Feb 09, 2012 at 01:29:08PM +, Roger Leigh wrote: The computer is not a person. There there, havelock.liw.fi, don't listen to the *mean* man who says you're not a person. You are too a person! Tell you what, it's a magical Internet, ol' buddy... Let's go exploring! In the US corporations are people, so surely computers are people too. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201202100215.46382.russ...@coker.com.au
Re: How to tell users that ia32-libs will go away
Goswin von Brederlow goswin-...@web.de (09/02/2012):
now that a multiarch dpkg has been uploaded to experimental it looks
like we can finaly get rid of ia32-libs* for wheezy.
!!!HURAY!!!
The problem now is the transition:
0) make sure all packages are multiarchified.
To check that, I debcheckout'd ia32-libs{,-gtk} and ran that (tail -1 is
here because of testing/unstable/experimental):
| for i in ia32-libs*/packages.list; do for p in $(cat $i); do s=$(apt-cache
showsrc $p 2/dev/null|awk '/^Package:/ {print $2}'|tail -1); if [ -z $s ];
then s=UNKNOWN; fi; echo $p $s; done|column -t $i.lookup; done
| for i in ia32-libs*/packages.list.lookup; do echo $i:; awk '{print $2}' $i
| sort -u; echo; done
Output for the second command:
| ia32-libs-gtk/packages.list.lookup:
| atk1.0
| at-spi
| cairo
| dbus-glib
| gconf
| glib2.0
| gtk+2.0
| gtk2-engines
| gtk2-engines-xfce
| jasper
| libart-lgpl
| libbonobo
| libcanberra
| libdatrie
| libglade2
| libgnomecanvas
| libidl
| libmng
| libthai
| libwmf
| lua5.1
| orbit2
| pango1.0
| pcre3
| pixman
| qt4-x11
|
| ia32-libs/packages.list.lookup:
| acl
| attr
| audiofile
| avahi
| celt
| coreutils
| cups
| curl
| cyrus-sasl2
| db
| db4.8
| dbus
| directfb
| e2fsprogs
| esound
| expat
| flac
| fltk1.1
| fontconfig
| freeglut
| freetype
| gcc-3.3
| gdbm
| gnutls26
| hal
| isdnutils
| jack-audio-connection-kit
| keyutils
| krb5
| lcms
| lesstif2
| libaio
| libasyncns
| libbsd
| libcaca
| libcap2
| libdrm
| libedit
| libexif
| libgcrypt11
| libgpg-error
| libgphoto2
| libice
| libidn
| libieee1284
| libjpeg6b
| libjpeg8
| libnss-ldap
| libogg
| libpam-ldap
| libpciaccess
| libpng
| libsamplerate
| libsdl1.2
| libselinux
| libsigc++-2.0
| libsm
| libsndfile
| libssh2
| libtasn1-3
| libtool
| libusb
| libvorbis
| libx11
| libx86
| libxau
| libxaw
| libxcb
| libxcomposite
| libxcursor
| libxdamage
| libxdmcp
| libxext
| libxfixes
| libxi
| libxinerama
| libxml2
| libxmu
| libxp
| libxpm
| libxrandr
| libxrender
| libxslt
| libxss
| libxt
| libxtst
| libxv
| libxxf86vm
| lzo2
| mesa
| mpg123
| nas
| nspr
| nss
| openal-soft
| openldap
| openssl
| pam
| popt
| pulseaudio
| rtmpdump
| sane-backends
| slang2
| sqlite3
| svgalib
| sysfsutils
| tcp-wrappers
| tdb
| tiff3
| tslib
| unixodbc
| UNKNOWN
| util-linux
| xaw3d
| xbitmaps
| xcb-util-renderutil
| xcursor-themes
| xft
|
And the UNKNOWN packages are:
| ia32-libs/packages.list.lookup:libartsc0UNKNOWN
| ia32-libs/packages.list.lookup:libartsc0-devUNKNOWN
| ia32-libs/packages.list.lookup:libaudiofile0UNKNOWN
| ia32-libs/packages.list.lookup:libssl0.9.8 UNKNOWN
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Please test gzip -9n - related to dpkg with multiarch support
Goswin von Brederlow wrote: * after a bugfix (including security ones) Yes, but not a problem (other than a small race condition) since all buildds should have the same version. And then if I have a multiarch system, and want to locally download the source of some library, build it and install it, dpkg will complain if I didn't use the same gzip that was used to build other arch versions I have installed. -- see shy jo signature.asc Description: Digital signature
Re: How to tell users that ia32-libs will go away
Le 09/02/12 15:53, Goswin von Brederlow a écrit : Hi, now that a multiarch dpkg has been uploaded to experimental it looks like we can finaly get rid of ia32-libs* for wheezy. !!!HURAY!!! The problem now is the transition: 1) multiarch and ia32-libs are incompatible [...] What this means is that users that want to use multiarch should remove ia32-libs (and lib32* really) soonest. Couldn't you make ia32-libs a meta-package pulling the multiarch version of the libs it used to include ? T. -- 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/4f33e988.4080...@free.fr
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote: gzip's output is likely to change: * on a different architecture * with different optimizations If either of these are the case (assuming a valid, deterministic, non-arch-specific implementation) then this violates C's as-if rule. The compiled version has to act as if it did exactly what the C said. Optimizations or other transformations that cause the compiled code to violate this are a bug in the compiler. -- 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
Re: Versionned dependencies
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Goswin von Brederlow, 2012-02-09 15:02+0100: Again I don't see how the situation would be different with depends instead of breaks. In both cases it is impossible to install a mismatching set of versions. Well, with Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13, 12.0~a1+) | iceape (= 2.1, 2.9~a1+) you could install xul-ext-adblock-plus as long as you have a compatible version of iceweasel, even if you have an incompatible version of iceape. With the current implementation Package: xul-ext-adblock-plus Depends: iceweasel (= 3.6.13) | iceape (= 2.1) Breaks: iceweasel (= 12.0~a1+), iceweasel ( 3.6.13), iceape (= 2.9~a1+), iceape ( 2.1) you cannot install xul-ext-adblock-plus if you have an incompatible version of iceape, even if you have a compatible version of iceweasel. Which is wrong. True, there is a small difference there. Thanks for explaining. Unless it truely breaks (e.g. segfaults) iceweasel or iceape the depends would then be better. MfG Goswin -- 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/87vcngngml.fsf@frosties.localnet
Re: Re: Use of the first person in messages from the computer
Josh Triplett wrote: In general I don't see anything wrong with you in most circumstances, though I think phrases like this system seem clearer and less ambiguous than your system. I agree. This is often seen in package descriptions, for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657196 But I think the second person should generally be avoided as much as possible. See also http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Second-person_pronouns However, I agree entirely with the recommendation in the developer's reference to avoid I or we. +1 -- 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/4f33ef44.8010...@gmail.com
Re: Use of the first person in messages from the computer
also sprach Josh Triplett j...@joshtriplett.org [2012.02.09.1554 +0100]: Choosing this option will modify /etc/X11/app-default/XTerm, preserving the old file as XTerm.backup.not-trad. Because choosing this option does not modify anything but the debconf cache, and only the postinst script modifies… no wait, choosing this option only changes the in-memory state of some UI widget and hitting enter then informs debconf… It's good to see that Debian doesn't have any more pressing problems to solve. ;) I suggest to use words like causes or yields. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems mulutlitithtrhreeaadededd s siigngnatatuurere digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: How to tell users that ia32-libs will go away
Samuel Thibault sthiba...@debian.org writes: Goswin von Brederlow, le Thu 09 Feb 2012 15:53:35 +0100, a écrit : 3) What about stable users? I don't see a way to transition stable users slowly. As said above I intent to request removal of ia32-libs for wheezy. So there will be no transition period where both ia32-libs and multiarch will be in stable. Can't we keep an ia32-libs package which is empty and just depends on the corresponding multiarch packages? Samuel I fear not. 1) Debian doesn't allow cross architecture depends (yet, afaiks, problems with DAK, testing migration, etc, might be outdated info). 2) Multiarch doesn't magically work in stable - The user needs to install a multiarch dpkg / apt / aptitude. - The user needs to enable multiarch (add i386 to the architectures) - The user needs to apt-get / aptitude update to fetch i386 Packages.gz - Now the user can install multiarch packages An ia32-libs transitional package that depends on libfoo:i386, libbar:i386, 50 other libs would be uninstallable on upgrade. But maybe that would be acceptable. Something to keep in mind. MfG Goswin -- 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/87r4y4ng5b.fsf@frosties.localnet
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 11:45:52AM -0400, Joey Hess wrote: And then if I have a multiarch system, and want to locally download the source of some library, build it and install it, dpkg will complain if I didn't use the same gzip that was used to build other arch versions I have installed. dpkg would complain anyway, because the versions are different. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, Friday's Child, stardate 3497.2 -- 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/20120209162132.ga23...@wavehammer.waldi.eu.org
Re: severity for bugs in ignoring TMP/TMPDIR?
In data Tuesday 07 February 2012 17:39:46, bastien ROUCARIES ha scritto: And swap as hell and kill interactivity i am afraid many people on this list have no direct experience of what happens when linux is out of memory and starts to swap. i have an embedded system with 32MiB of RAM where no matter how large the swap partition is, going out of memory causes some programs to crash, or sometimes leads to strange behaviour of programs being running, doing nothing and impossible to kill. And in these cases an hard reboot is the only solution. -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Re: DEP-5 and files with white spaces
Hello, On Thu, 09 Feb 2012 11:01:00 +0100 Goswin von Brederlow goswin-...@web.de wrote: Idea 2: Allow quotation marks. Not a solution on its own. What about a file named foo bar' baz? For a worst case what about files with newlines? You can double the delimiter to embed it into a string, like this: foo bar' baz or 'foo bar'' baz'. -- WBR, Andrew signature.asc Description: PGP signature
Re: severity for bugs in ignoring TMP/TMPDIR?
On Thu, 9 Feb 2012 17:22:58 +0100 Salvo Tomaselli tipos...@tiscali.it wrote: In data Tuesday 07 February 2012 17:39:46, bastien ROUCARIES ha scritto: And swap as hell and kill interactivity i am afraid many people on this list have no direct experience of what happens when linux is out of memory and starts to swap. ... on something other than a fast hard disk ... Swapping isn't a problem on a desktop or reasonably modern laptop (it's arguably an indicator of other problems on a server) because it's usually fast enough that the user won't notice. Swapping - if it's even enabled - on embedded devices with solid state storage really isn't fun because writing data is just so slow. i have an embedded system with 32MiB of RAM where no matter how large the swap partition is, going out of memory causes some programs to crash ... usually with a SIGABORT which is very, very unkind to the data being handled by the process at that time ... , or sometimes leads to strange behaviour of programs being running, doing nothing and impossible to kill. And in these cases an hard reboot is the only solution. 32Mb is a very small amount of RAM though - we've been doing OK in 128Mb (with no swap support) but got into problems with fork|exec because that effectively cuts your RAM in half - or fails. We found a fix for that (the blame eventually lay in pango) and we also try to avoid fork|exec inside processes which need a lot of RAM. It's more manageable to use something like dbus, sockets or other IPC and have two processes each using 30% of RAM (or less) than one taking 60%. To fit into very small amounts of RAM, you have to be able to restructure the code and that, generally, means cross-building modified packages. One day, once Multi-Arch is fully implemented, Emdebian will restart work on that area. I'd be surprised if you're able to use eglibc in 32Mb of RAM though - I wonder if you've considered rebuilding for uClibc or similar. Mind you, once you get into that area, you wonder if the final system is actually recognisably Debian anymore... -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp4r2RYHw9VG.pgp Description: PGP signature
Re: DEP-5 and files with white spaces
On Thu, Feb 09, 2012 at 07:38:29PM +0300, Andrew Shadura wrote: Hello, On Thu, 09 Feb 2012 11:01:00 +0100 Goswin von Brederlow goswin-...@web.de wrote: Idea 2: Allow quotation marks. Not a solution on its own. What about a file named foo bar' baz? For a worst case what about files with newlines? You can double the delimiter to embed it into a string, like this: foo bar' baz or 'foo bar'' baz'. Urgh. Or do 1. as well as 2. and have escape sequences. Also urgh. It's a theoretical problem and Jakub has shown that there is a workable solution with the current syntax. He's also shown that we couldn't handle distinguishing foo bar from foo\tbar. That is, surely, also entirely theoretical. -- Jon Dowland -- 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/20120209171751.GA23213@debian
Re: Use of the first person in messages from the computer
martin f krafft dijo [Thu, Feb 09, 2012 at 05:07:39PM +0100]: Because choosing this option does not modify anything but the debconf cache, and only the postinst script modifies… no wait, choosing this option only changes the in-memory state of some UI widget and hitting enter then informs debconf… It's good to see that Debian doesn't have any more pressing problems to solve. ;) I suggest to use words like causes or yields. As a far-from-native English speaker, please stick with causes if given a choice. Yields is a much less common word. -- 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/20120209171957.gc19...@gwolf.org
Bug#659269: ITP: starconf -- Starlink autoconf support
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: starconf Version : 1.3 Upstream Author : Norman Gray * URL : http://starlink.jach.hawaii.edu/starlink * License : TBD Programming Lang: Shell Description : Starlink autoconf support This package contains the support m4 autoconf macros to build packages from the starlink project. This package is built in preparation to build slalib http://bugs.debian.org/359003 and starlink-libast http://bugs.debian.org/657957, which are then required to re-insert saods9 http://bugs.debian.org/655648. -- 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/4f340542.8010...@liska.ath.cx
Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)
OoO En cette fin de matinée radieuse du jeudi 09 février 2012, vers 11:43, Cyril Brulebois k...@debian.org disait : I have done the latest uploads for php-mdb2 packages. I suppose you want me to drop php-mdb2-driver-sqlite package? From #debian-release's backlog, it seems likely. OK, I have requested removal for both unstable and testing. -- Vincent Bernat ☯ http://vincent.bernat.im printk(autofs: Out of inode numbers -- what the heck did you do??\n); 2.0.38 /usr/src/linux/fs/autofs/root.c pgpPQ9FwbzaCd.pgp Description: PGP signature
Re: How to tell users that ia32-libs will go away
On Thu, Feb 09, 2012 at 04:43:04PM +0100, Thibaut Paumard wrote: Le 09/02/12 15:53, Goswin von Brederlow a écrit : now that a multiarch dpkg has been uploaded to experimental it looks like we can finaly get rid of ia32-libs* for wheezy. !!!HURAY!!! The problem now is the transition: 1) multiarch and ia32-libs are incompatible [...] What this means is that users that want to use multiarch should remove ia32-libs (and lib32* really) soonest. Couldn't you make ia32-libs a meta-package pulling the multiarch version of the libs it used to include ? This would require something like Depends: libpam0g:i386, libssl098:i386, [...] and this syntax is not yet supported (intentionally, because there's a lot of policy that needs to be put in place before we allow such things). Ubuntu, faced with the same issue, kludged a bit to make upgrades possible. Package: ia32-libs Architecture: amd64 Depends: ia32-libs-multiarch Package: ia32-libs-multiarch Architecture: i386 Multi-Arch: foreign Depends: libpam0g, [...] This doesn't require us to support :arch syntax for dependencies anywhere yet; it just requires that the i386 arch is enabled via multiarch, and that the package manager is able to resolve the fact that ia32-libs' dependency is satisfied by the only copy of ia32-libs-multiarch available, the i386 one. However, this still introduces at least some of the same policy problems - for instance, britney has to be taught that this is ok if you want to be able to migrate this package to testing automatically. And you need a multiarch-capable package manager installed and configured *before* you can upgrade this package, so that requires a two-step upgrade of some variety: either holding ia32-libs back until after the dist-upgrade, or upgrading the package manager before the dist-upgrade. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20120209185255.gc17...@virgil.dodds.net
Bug#659282: ITP: eeglab -- electrophysiological data analysis
Package: wnpp Severity: wishlist Owner: Michael Hanke m...@debian.org * Package name: eeglab Version : 11.0.0.0 Upstream Author : Scott Makeig, Arnaud Delorme and others * URL : http://sccn.ucsd.edu/eeglab * License : GPL-2+ Programming Lang: Matlab (Octave) Description : electrophysiological data analysis This is sofwware for processing continuous or event-related EEG or other physiological data. It is designed for use by both novice and expert users. In normal use, the EEGLAB graphic interface calls graphic functions via pop-up function windows. The EEGLAB history mechanism can save the resulting calls to disk for later incorporation into scripts. . This package provides EEGLAB to be used with Matlab. Note that this package depends on Matlab -- a commercial software that needs to be obtained and installed separately. Notes - At this point this package basically only works with Matlab (hence aiming at contrib). However, there is hope to enable an interesting subset of non-GUI functionality to work with Octave. Upstream provides a substantial unittest suite to help such an effort. Until this can be achieved, this package, at least, strengthens Debian's utility for electrophysiological data analysis, as eeglab is one of the most popular tools in this field. A number of source-less extensions from 3rd parties have been stripped for DFSG-compliance. -- Michael Hanke http://mih.voxindeserto.de -- 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/20120209192003.GA3323@meiner
Re: How to tell users that ia32-libs will go away
On Thu, Feb 09, 2012 at 10:52:55AM -0800, Steve Langasek wrote: On Thu, Feb 09, 2012 at 04:43:04PM +0100, Thibaut Paumard wrote: Le 09/02/12 15:53, Goswin von Brederlow a écrit : now that a multiarch dpkg has been uploaded to experimental it looks like we can finaly get rid of ia32-libs* for wheezy. !!!HURAY!!! The problem now is the transition: 1) multiarch and ia32-libs are incompatible [...] What this means is that users that want to use multiarch should remove ia32-libs (and lib32* really) soonest. Couldn't you make ia32-libs a meta-package pulling the multiarch version of the libs it used to include ? This would require something like Depends: libpam0g:i386, libssl098:i386, [...] and this syntax is not yet supported (intentionally, because there's a lot of policy that needs to be put in place before we allow such things). Ubuntu, faced with the same issue, kludged a bit to make upgrades possible. Package: ia32-libs Architecture: amd64 Depends: ia32-libs-multiarch Package: ia32-libs-multiarch Architecture: i386 Multi-Arch: foreign Depends: libpam0g, [...] This isn't even that much of a kluge - ia32-libs is there to support unpackaged (mostly non-free) software and so a metapackage that pulls in libraries likely to be dependencies of that software remains useful. This doesn't require us to support :arch syntax for dependencies anywhere yet; it just requires that the i386 arch is enabled via multiarch, and that the package manager is able to resolve the fact that ia32-libs' dependency is satisfied by the only copy of ia32-libs-multiarch available, the i386 one. However, this still introduces at least some of the same policy problems - for instance, britney has to be taught that this is ok if you want to be able to migrate this package to testing automatically. And you need a multiarch-capable package manager installed and configured *before* you can upgrade this package, so that requires a two-step upgrade of some variety: either holding ia32-libs back until after the dist-upgrade, or upgrading the package manager before the dist-upgrade. There is a similar issue with linux-image-*-amd64, which I would definitely like to remove from i386 as soon as possible. We have metapackages to help with this already, but we still need users to add amd64 as a foreign architecture before upgrading. 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/20120209194511.gh12...@decadent.org.uk
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote: Riku mentioned as an argument that this increases the data to download due to slightly bigger Packages files, but pdiffs were introduced exactly to fix that problem. And, as long as the packages do not get updated one should not get pdiff updates. And with the splitting of Description there's even less data to download now. off-topic but often pdiffs don't really speed up apt-get update. Added roundtrip time latency on pulling several small files slows down the download unless you run update nightly. But the more interesting slowdown is that the amount of packages is general slows down apt operations in a rate that is around O(dependencies^2) (pure guess, perhaps someone has better knowledge?). We do remember apt-get slowing down to crawl on maemo platforms with much smaller repositories.. Adding shared file support into dpkg, introduces additional uneeded complexity, that can never be taken out, and which seems clear to me should be dealt with at the package level instead. However, if we add the complexity to dpkg, we don't need to add it to all of the 1000+ multiarched packages. It would not be wise to do something 1000 times in packages which could be done once in dpkg. Even when doing it once in dpkg is harder, it is still a lot less total work. Since Debian has chronic lack of active hands working on packages, solutions that add the workload of maintainers will just slow down the development of debian even further. -- 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/20120209195017.ga13...@afflict.kos.to
Re: Please test gzip -9n - related to dpkg with multiarch support
Goswin von Brederlow goswin-...@web.de writes: Changing the name in the package would break tools that rely on the name (like packages.debian.org extracting the Changelog). Also ugly. We control the tools; we can change the tools. Multiarch is a big deal. We weren't going to get through this without changing some tools. (One should not read that as my support of this specific alternative, as I've not decided there yet, but in general I think it's fair game to change our tools to support multiarch.) -- 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/87k43vu389@windlord.stanford.edu
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote: On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote: Riku mentioned as an argument that this increases the data to download due to slightly bigger Packages files, but pdiffs were introduced exactly to fix that problem. And, as long as the packages do not get updated one should not get pdiff updates. And with the splitting of Description there's even less data to download now. off-topic but often pdiffs don't really speed up apt-get update. Added roundtrip time latency on pulling several small files slows down the download unless you run update nightly. One of the reasons of this I think, is that the current pdiff implementation in apt is really not optimal, see #372712. But the more interesting slowdown is that the amount of packages is general slows down apt operations in a rate that is around O(dependencies^2) (pure guess, perhaps someone has better knowledge?). We do remember apt-get slowing down to crawl on maemo platforms with much smaller repositories.. Well, if we take the number of new packages Steve quoted (even w/o taking into account the stuff I mentioned that could be reduced), and round it to 200 new packages, that's really insignificant compared to the amount of packages one will inject into apt per new foreign arch configured. I really fail to see the issue here. Adding shared file support into dpkg, introduces additional uneeded complexity, that can never be taken out, and which seems clear to me should be dealt with at the package level instead. However, if we add the complexity to dpkg, we don't need to add it to all of the 1000+ multiarched packages. It would not be wise to do something 1000 times in packages which could be done once in dpkg. Even when doing it once in dpkg is harder, it is still a lot less total work. Since Debian has chronic lack of active hands working on packages, solutions that add the workload of maintainers will just slow down the development of debian even further. If this was something that dpkg could do reliably, was future-proof, introduced no issues at all and was technically sound, then I'd agree with you that even if it might be harder to implement (which is not the case), and maintain (maybe) it would be well worth it. But given the amount of problems, inconsitent handling between M-A: same and other packages, corner cases and general fragility it introduces, for the supposed benefit of size reduction (which does not seem to be significant at all) and to avoid a possible one time package split, it seems clear this is the complete wrong approach. Also except for the package splits, most of the arch-qualified path changes should be easily handled automatically by something like debhelper or cdbs. In any case when I was talking about complexity here, was not code wise, but the implications it has on the handling of packages in general. I'll write more about this in a summary mail I'm finishing up. regards, guillem -- 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/20120209212953.ga26...@gaara.hadrons.org
Re: mass bug filing of 'ucf: command not found' errors detected by piuparts
Roger Leigh wrote: On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote: On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote: Interesting timing. initscripts started depending on ucf just a few days ago, which makes ucf quasi-essential. [...] Well, I would argue that packages in the essential set shouldn't be adding new dependencies without some discussion and review on debian-devel first. Hopefully we can remove the ucf dependency; please see #648433. Currently /etc/default/rcS is intentionally only installed once sysvinit is currently at 9/10 days and about to migrate to testing. If these two controversial changes (initscripts adding dependency on ucf (which becomes transitively-essential), updating rcS on upgrade) should not find their way into testing (in the current form), action should be taken now. Andreas -- 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/4f344620.8010...@abeckmann.de
No release/transition to libpoppler 0.18 ?
Hi all, A few weeks/months back libpoppler 0.18 got released. The version we have in Debian (running sid) is 0.16.7 which was released in Jun 2011. Please see http://poppler.freedesktop.org/releases.html . Subsequently a wishlist bug was filed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=67 . If one sees the bug then one can see Mr. Martin Pitt sharing debdiffs for libpoppler when they are doing the same for ubuntu. Now during that time-frame I have been seeing various errors while viewing pdf's which I did suspect were due to the library being old. The latest victims though is the Open Advice e-book. Please see https://github.com/lydiapintscher/Open-Advice/issues/41 I tried to see if the maintainer Monsieur Loic Minier had asked for transition but was unable to find anything of value. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable I know that in couple of months (or a little more) we would be looking at Freeze. Is there possibility of getting a fresh release in soonish ? Looking forward to know more. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/CADdDZRk5Cex-Xk8�DZ04-6=mftmyuevvvhbgmoltnvbnw...@mail.gmail.com
Re: No release/transition to libpoppler 0.18 ?
addition at bottom :- 2012/2/10 shirish शिरीष shirisha...@gmail.com: Hi all, A few weeks/months back libpoppler 0.18 got released. The version we have in Debian (running sid) is 0.16.7 which was released in Jun 2011. Please see http://poppler.freedesktop.org/releases.html . Subsequently a wishlist bug was filed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=67 . If one sees the bug then one can see Mr. Martin Pitt sharing debdiffs for libpoppler when they are doing the same for ubuntu. Now during that time-frame I have been seeing various errors while viewing pdf's which I did suspect were due to the library being old. The latest victims though is the Open Advice e-book. Please see https://github.com/lydiapintscher/Open-Advice/issues/41 I tried to see if the maintainer Monsieur Loic Minier had asked for transition but was unable to find anything of value. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable I know that in couple of months (or a little more) we would be looking at Freeze. Is there possibility of getting a fresh release in soonish ? Looking forward to know more. Please CC me if anybody replies to this :) -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/CADdDZR=ubermdbdumg4m2zkws_cycwqfea_+hhdz2zru9lt...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 10:29:53PM +0100, Guillem Jover wrote: But the more interesting slowdown is that the amount of packages is general slows down apt operations in a rate that is around O(dependencies^2) (pure guess, perhaps someone has better knowledge?). We do remember apt-get slowing down to crawl on maemo platforms with much smaller repositories.. Well, if we take the number of new packages Steve quoted (even w/o taking into account the stuff I mentioned that could be reduced), and round it to 200 new packages, that's really insignificant compared to the amount of packages one will inject into apt per new foreign arch configured. I really fail to see the issue here. That's based on a sample of 1200 packages currently tagged Multi-Arch: same in the Ubuntu precise archive. If we have all packages in sections libs and libdevel converted for multiarch (which I suppose we eventually will), this number will be closer to 7000. Does 700 more of these support packages approach the level that it starts to be a problem? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Work-needing packages report for Feb 10, 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: 403 (new: 13) Total number of packages offered up for adoption: 143 (new: 0) Total number of packages requested help for: 59 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bochs (#659023), orphaned 2 days ago Description: IA-32 PC emulator Reverse Depends: bochs bochs-sdl bochs-svga bochs-term bochs-wx bochs-x Installations reported by Popcon: 2210 catwalk (#658918), orphaned 3 days ago Installations reported by Popcon: 60 openhackware (#658774), orphaned 4 days ago Description: OpenFirmware emulator for PowerPC Reverse Depends: qemu-system Installations reported by Popcon: 8215 proll (#658886), orphaned 3 days ago Description: JavaStation PROM 2.x compatible replacement Installations reported by Popcon: 1692 python-tgext.admin (#658921), orphaned 3 days ago Reverse Depends: python-catwalk Installations reported by Popcon: 60 python-toscawidgets (#658922), orphaned 3 days ago Reverse Depends: python-sprox python-tgext.admin python-turbogears2 Installations reported by Popcon: 79 python-webflash (#658923), orphaned 3 days ago Reverse Depends: python-turbogears2 Installations reported by Popcon: 93 sprox (#658924), orphaned 3 days ago Reverse Depends: python-catwalk python-tgext.admin Installations reported by Popcon: 64 tg.devtools (#658925), orphaned 3 days ago Installations reported by Popcon: 54 ttb (#659241), orphaned today Description: Browse teletekst (Dutch) on your computer Installations reported by Popcon: 27 turbogears2-doc (#658927), orphaned 3 days ago Installations reported by Popcon: 71 vera (#659056), orphaned 2 days ago Description: Dictionary of computer related acronyms Installations reported by Popcon: 494 vgabios (#658776), orphaned 4 days ago Description: VGA BIOS software for the Bochs and Qemu emulated VGA card Reverse Depends: bochs qemu-kvm qemu-system Installations reported by Popcon: 8838 390 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 143 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#646208), requested 110 days ago Description: Apache HTTP Server Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker apache2-prefork-dev apache2-suexec apache2-suexec-custom (178 more omitted) Installations reported by Popcon: 61054 apt-xapian-index (#567955), requested 738 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: adept ept-cache fuss-launcher packagesearch Installations reported by Popcon: 51823 asymptote (#517342), requested 1077 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 3028 athcool (#278442), requested 2662 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 91 balsa (#642906), requested 137 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg debreaper Installations reported by Popcon: 271 bastille (#592137), requested 551 days ago Description: Security hardening tool Installations reported by Popcon: 246 boinc (#511243), requested 1127 days ago Description: BOINC distributed computing Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway boinc-app-seti boinc-dbg boinc-nvidia-cuda Installations reported by Popcon: 1871 cardstories (#624100), requested 290 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 5 chromium-browser (#583826), requested 620 days ago Description: Chromium browser Reverse Depends: chromium chromium-browser chromium-browser-dbg chromium-browser-inspector chromium-browser-l10n chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 9986 cryptsetup (#600777), requested 477 days ago Description: configures encrypted block devices Reverse Depends: cryptsetup cryptsetup-udeb
Re: Endianness of data files in MultiArch
On Thu, Feb 9, 2012 at 20:52, Goswin von Brederlow goswin-...@web.de wrote:
It should be possible to build a converter or generator that can output
either endianess. So you could have a single arch:all package with both
/usr/share/$package/data/{be,le} in it or to generate the right
endianness on install. That way the performance impact argument is non
existant.
Yes, it's possible, but it requires additional work for both
upstream/debian maintainer to care the case a lot. IMHO this idea is
not very constructive for finding a better solution than the current
way.
--
Regards,
Aron Xu
--
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/CAMr=8w66hu3l_nyr9egmjbtdq4kyr8issahc2hungtgq0p4...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 9, 2012 at 22:29, Guillem Jover guil...@debian.org wrote: On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote: On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote: Riku mentioned as an argument that this increases the data to download due to slightly bigger Packages files, but pdiffs were introduced exactly to fix that problem. And, as long as the packages do not get updated one should not get pdiff updates. And with the splitting of Description there's even less data to download now. off-topic but often pdiffs don't really speed up apt-get update. Added roundtrip time latency on pulling several small files slows down the download unless you run update nightly. One of the reasons of this I think, is that the current pdiff implementation in apt is really not optimal, see #372712. The real slowdown is that APT currently works on one pdiffs at the time. The solution for this is two-fold: First get all pdiffs needed - for debian this is easy as its strictly sequential, but other archives can (and some even do) use different paths so we need a bit more metadata to support these, too. After we have all these pdiffs we can merge these to one big pdiff and apply this one. As we walk over 25 MB files only once and not for each patch we should be quiet a bit faster. The theory and even python code for the merge part can be found at [0], it's just that the APT team is since years so overcrowded that we haven't yet decided who can pick this one [/irony]. If someone wants to work on that, feel free to drop a line to deity@l.d.o (and to Anthony) and i will try to help if time permits. [0] http://lists.debian.org/deity/2009/08/msg00169.html But the more interesting slowdown is that the amount of packages is general slows down apt operations in a rate that is around O(dependencies^2) (pure guess, perhaps someone has better knowledge?). My question would be why you are guessing O(d^2) for a situation which should be intuitively a O(d*2). My empirical testing seems to support this, given that the runtime roughly doubles (a bit less) (Less than doubled packages as we have arch:all packages, but a bit more than doubled deps given that we have new implicit ones for multiarch). But as team member and implementer of multiarch in APT i might be a bit biased here… ;) (note though that numbers/timing are based on experimental, sid has currently a slightly different implementation, but shouldn't be that bad either) We do remember apt-get slowing down to crawl on maemo platforms with much smaller repositories.. As an owner of an N810 i am not, but i might be used to pain, given that i managed bootstrapping Debian with a recent (partly working) kernel on it (the gentoo/openwrt have details on that if someone is interested). So if you can go into details what you remember exactly we might be able to work on it - until then, my only comment to adding more packages: What should possible go wrong? ;) If APT survives i386 packages in amd64, it might survive some new ones, too. Best regards David Kalnischkies -- 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/caaz6_fa8ujbu23_4qqhlqrcgmiu35mcsifk+d-vh-msqg2s...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote: gzip's output is likely to change: * on a new version * after a bugfix (including security ones) * on a different architecture * with different optimizations * with a different implementation (like those parallel ones) * possibly with a different moon phase Especially the first is pretty guaranteed to bite: whenever the upstream does a small improvement, binaries in the archive get invalidated until rebuilt with the new gzip. Checking with a of 82613 files, compressing each file with gzip -n9 $file resulted exactly same result with gzip of oldstable (2008) and gzip of sid (2012). Picking up woody gzip and libc from archive.debian.org (2002), 33 files were not identical. This a 0.04% chance of differing file over a DECADE of changes. While evidently changes do happen, certainly not a case of whenever a butterly flaps wings in a certain direction gzip compression results change. specifics of the the test setup: 2012 sid setup, gzip 1.4-2, eglibc 2.13-20, built with gcc 4.6.1 amd64 binaries 2008 lenny setup, gzip 1.3.12-6+lenny1, glibc6 2.7-18lenny7, built with gcc 4.3, i386 binaries 2002 woody setup, gzip 1.2.4-33.1, glibc6 2.1.3-20, probably built with gcc 3.0, i386 binaries (duh) Corpus of files was all the gzip compressed files extracted and uncompressed from a partial debian mirror. All tests during the current almost full moon phase. Riku -- 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/20120210015817.ga15...@afflict.kos.to
Re: severity for bugs in ignoring TMP/TMPDIR?
On Sun, Feb 5, 2012 at 10:51 AM, Paul Wise wrote: If I notice that software in Debian is ignoring TMP/TMPDIR (since I use libpam-tmpdir), what severity should I file the resulting bugs at? I'll file them at wishlist as suggested by the second mail in this thread. This thread has gotten out of hand. Please stop babbling about /tmp, RAM and so on. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gkbf2zjjvzfvhwszpzmdf6ns4mdq1k2lxtvoo6lyk...@mail.gmail.com
Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
Sorry, the thread was broken and I saw your reply just now. On Thu, Feb 9, 2012 at 16:23, Jan Hauke Rahm j...@debian.org wrote: On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote: This is valid for most-used applications/formats like gettext, images that are designed to behave in this way, but on the contrary there are upstream that don't like to see such impact, especially due to the complexity and performance impact. Currently I am using arch:any for data files which aren't be affected with multiarch, i.e. not same or foreign. For endianness-critical data that is required to make a library working, I have to force them to be installed into /usr/lib/triplet/$package/data/ and mark them as Multiarch: same, this is sufficient to avoid breakage, but again it consumes a lot of space on mirror. Actually, what is a lot here? I mean, how many libraries are there containing endianness-critical data and how big are the actual files? Not that I'm any kind of expert, but this solution sounds reasonable to me. Hauke As far as I know, there isn't too many libraries known to have endianness-critical data, but there might be landmines because the maintainer just aren't aware about it. I have the chance to notice this problem because my team maintain several stack of input methods, which usually need to deal with linguistic data. [1] For me here is a library named libpinyin at hand to package, which has some data files of ~7.5MiB size after gzip -9 (the total size of this library is no more than 9MiB after gzip -9). We have 14 architectures on ftp-master, so the data file eats up 105MiB, while if we find some way to have only one copy for be/le, it'll only use 15MiB. And think about when it get released as a stable, a new copy of those data is making their way to the archive when new version get uploaded to unstable. Such concern is also valid to other endianness-critical data that are not bothered with Multi-Arch at present, we need to make them arch:any and in the end they are eating more and more space. [1] Performance is critical for these applications, this doesn't mean it consumes a lot of CPU percentage, but it must response very quickly to user's input - do some complex calculations to split a sentence into words and find out a list of most related suggestions, which needs to query from 10^5 ~ 10^6 lines of data several times to complete such an action. There was project tried to use something like SQLite3 but the performance is a bit frustrating, so they have now decided not to care about that but just design data format that can fit for their requirements. -- Regards, Aron Xu -- 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/CAMr=8w6qiM6VB_2iegzKMFx=tv+ert6lqely6naoqfpaco-...@mail.gmail.com
Re: Use of the first person in messages from the computer
Ian Jackson ijack...@chiark.greenend.org.uk writes: Finally, the reviewer revealed in the review that they're not a native speaker of English. Is it normal for l10n reviews to be conducted by non-native speakers of the target language ? Are we really so short of native English speaking l10n reviewers ? If so I would be happy to help (although you may find me too opinionated...) Hmmm, while it may not be the best thing to have a non-native speaker in charge of wording, I think it actually _is_ useful to have their input. Sometimes language that seems pretty obvious to a native speaker isn't clear at all to many non-native speakers (even if they're fairly competent)... -miles -- Discriminate, v.i. To note the particulars in which one person or thing is, if possible, more objectionable than another. -- 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/buoipjfclhh@dhlpc061.dev.necel.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 09, 2012 at 02:54:43PM +0100, Goswin von Brederlow wrote:
Wouter Verhelst wou...@debian.org writes:
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use lots more space on single
arch installations.
Does it really?
A quick test tells me that uncompressing every file under /usr/share/doc
does indeed increase the size of that directory on my laptop by a factor
of approximately two:
After running sudo find /usr/share/doc -name '*.gz' -exec gunzip {} \;,
the size of that directory is as reported by 'du -s' is 1263220
kibibytes, while it was 757280 before, a difference of 505940.
This is on a system with 2524 packages installed, for a grand total
of...
dpkg-query -W -f '${Installed-Size}\n' | awk '{TOT+=$0} END{print TOT}'
8830371
... approximately 8.5GiB of installed software. While I agree that
adding around 500MiB to that installed size is significant, I wouldn't
define it as 'lots more space'. Additionally, it should be possible for
dpkg to support compressing at install time for those users who request
it, based on a configuration parameter.
Note that only a fraction of that would be in MA:same packages.
Everything else can stay compressed. Some other test (see other mails in
thread) estimated an increase of 60MB.
Yes, but I think that's a bad idea. Either we should compress
everything, or nothing at all. Compressing some files but not others is
going to be confusing, inconsistent, and generally a bad idea.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
--
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/20120210063939.go3...@grep.be
Re: DEP-5 and files with white spaces
On Thu, Feb 09, 2012 at 11:01:00AM +0100, Goswin von Brederlow wrote: Idea 2: Allow quotation marks. Not a solution on its own. Actually, I think it's a perfectly workable solution. What about a file named foo bar' baz? For a worst case what about files with newlines? Unless these are part of a test suite on filenames, slap upstream and tell them to use sane filenames? (and if they *are* part of a test suite on file names, they need not have content, therefore need not appear in a copyright file, and can be trivially created at run time with 'touch') -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120210062901.gn3...@grep.be
Re: Use of the first person in messages from the computer
Quoting Niels Thykier (ni...@thykier.net): On 2012-02-09 13:20, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: [...] I suspect devref 6.5.2.5 is a (possible) source of this impression. As I recall, there are also some Lintian checks about using first person. Well, devref 6.5.2.5 is actually directly or indirectly written by the reviewer cited by Ian, aka /me..:-) So, don't take it too much as Word of Wisdom, here. I'm personnally deeply and strongly convinced that the computer is not a person and should not talk to users. I consider this is a kinda amateurish style which I never meet in commercial, professionnal (insert your favourite word here) software, documentation, etc. And I personnally never use it. From what I witness in various texts, this is shared by many. And, if you look closely, or you dislike me taking professional software as an example, just check the most common free software environments and try finding uses of first person in them. You'll be in trouble..:-) This is also something that is never used in writings such as scientific publications (we is sometimes tolerated, mostly depending in what kind of publication).. So, in short, we (debian-l10n-english) try to suggest that such use should be avoided. Still, this is of course enver enforced on maintainers who are free to disagree and ignore this advice, of course (Manoj is a very good example of someone who disagrees with me about this:-)) signature.asc Description: Digital signature
Re: DEP-5 and files with white spaces
Wouter Verhelst wou...@debian.org writes: On Thu, Feb 09, 2012 at 11:01:00AM +0100, Goswin von Brederlow wrote: Not a solution on its own. Actually, I think it's a perfectly workable solution. What about a file named foo bar' baz? For a worst case what about files with newlines? Unless these are part of a test suite on filenames, slap upstream and tell them to use sane filenames? We're basically retracing the previous discussion, and rediscovering why we left the spec alone. Formal correctness says that any possible file name should be representable, at which point filenames with newlines or embedded quote characters are a theoretical possibility and we would want some sort of robust solution for all those cases. If we *aren't* going to try to represent absolutely any possible legal filename exactly, then we're debating over how much of a technical correctness hole we want to leave, not over whether we're going to have one. At that point, I think it's reasonable to ask if we care about going to the work of expanding the spec to handle filenames with spaces in them without wildcards, as even that is not a horribly common case. (I realize it's more common for upstreams who develop on Windows or Mac OS.) That's how ended up where we are now. Note that another case that I don't think has been discussed, but which is probably more common than embedded quote marks, is a filename that's invalid UTF-8 (straight ISO 8859-1, for example). That's also not representable in our typical debian/copyright file, and is likely to cause significant practical problems (such as having the encoding format change every time the maintainer edits the file, since some editors will try to fix such problems). -- 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/87pqdn183u@windlord.stanford.edu
Re: Use of the first person in messages from the computer
On Thu, Feb 09, 2012 at 12:20:06PM +, Ian Jackson wrote: I have just received a review by a l10n team of a package of mine. The reviewer seems to be under the impression that there is something wrong with the computer speaking to the user in the first person. For example: - If you approve, I will edit /etc/X11/app-default/XTerm for you, and - save your old file as XTerm.backup.not-trad. (Note that this is a - conffile so you may get prompts from dpkg about it in the future.) The suggested alternative from the reviewer: + If you choose this option, /etc/X11/app-default/XTerm will be modified + and the old file will be kept as XTerm.backup.not-trad. [...] Good plain English style is to use the simplest constructions and sentences that will serve, including avoiding needless use of the passive voice. This is not just my opinion. The Plain English Campaign[1] howto guide's[2] 2nd and 3rd bullet points on the summary page are: * Prefer active verbs * Use `you' and `we' Also relevant is their guide to (paper) forms[3], which contains this imprecation: * Make it personal Use `you' rather than, for instance, `the applicant' [etc.] Use `we' rather than, for instance, `the council' [etc.] Yes, but these are about councils and persons, if I understand correctly; not about computers. I don't know where the English l10n team got the idea from that there is something wrong with a computer speaking to the user in the first person. But in my opinion this criticism is entirely misplaced. I believe this stems from a feeling that having the computer speak in first-person form implies some form of (artificial?) sentience on the part of the computer. A computer is an inanimate object that just happens to have the capability to make calculations and interact with humans. Would you refer to a table as a person? A computer cannot refer to itself, because it does not have a self. Whenever I see a first-person statement on the part of the computer, I don't actually read it as coming from the computer; instead, I read it as coming from the programmer who wrote the actual statement--a person. Having a first-person form coming from a programmer is somewhat awkward; as you say: [...] I think it is incorrect to use the first person singular when writing as the software author, because Free Software is a collaborative enterprise: the authors are always in principle collective and thus plural even if in practice there is a principal or single human author. and therefore I think the reviewer is correct and the first-person form should indeed not be used. My reviewer also seems to think there is (sometimes?) something wrong with the use of the second person to refer to the user or the owner of the system. For example: - Optionally, this package will edit your system configuration to make + Optionally, this package will edit the system's configuration to make the default fonts used by xterm refer to the traditional font. Unpersonnalize. Again, I think my version is clearer, But possibly wrong. The person configuring the system need not necessarily be the owner of the system. I believe 'this system' rather than 'the system' would be better, but that's a bit nitpicking. At any rate, 'your system' implies ownership, which may not be in line with reality. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Re: Use of the first person in messages from the computer
Quoting Ian Jackson (ijack...@chiark.greenend.org.uk): Finally, the reviewer revealed in the review that they're not a native speaker of English. Is it normal for l10n reviews to be conducted by non-native speakers of the target language ? Are we really so short of native English speaking l10n reviewers ? If so I would be happy to help (although you may find me too opinionated...) PS I have not named the reviewer because I get the impression that the matters I'm questioning are general practice in the English l10n team, so I don't want to make any personal criticism of the reviewer. Well, I think that many know who is the reviewer and he has no problem with the entire world knowing he's not a native speaker..:-) (apparently, he now even speaks about himself at third person, doh). So, well, that was me. For sure, it may seem weird that English reviews are most of the time triggered by a non native English speaker. It's even more weird when the review is done for a text that has been written by a native speaker..:-) Well, this is mostly how it is and works since April 2007, when I started working on these issues because I was puzzled by some very very very bad wording we had in packages. If you remember, many people indeed thought that I was doing an April Fool's joke when I sent this annoucement (http://lists.debian.org/debian-devel-announce/2007/04/msg0.html). The current work method is what you witnessed for your package : I volunteer to coordinate the work and I propose the first review. It usually helps other contributors to focus on important issues. We *are* very short of contributors, indeed. Most of the time, Justin Rye is the only person who reviews my review. Thankfully, Justin is an incredibly picky and competent person and always comes up with great improvements. A few other native speakers contribute from time to time as well as some non native (often translators and often people much more clever in English than me) Actually, as a side effect, I learned a lot in English language thanks to this work and particularly Justin's reviews and comments. Even better, we always try to find a good balance between the various local variations in English (en_US/en_UK as first example, of course). I think that, in general, the result is quite worth the effort and also does not require too much from maintainers. Most indeed seem happy with the process and we always follow their feelings when they disagree with us (as you did, Ian, on some of our suggestions). We can improve the process, for sure (and I think we did so in nearly 5 years) and we definitely welcome new contributors to help. Anyone is welcome, particularly native speakers (but non native ones also bring interesting light as English is our defacto lingua franca and we have to be intelligible for as many people as possible). I will take care to read comments in this thread and improve our processes, suggestions and reviews in light of them. Thanks anyway for your comments and for bringing that topic. All processes sometimes need to be questioned in order to be improved and contradiction is also welcomed. (and I hope I didn't break too much rules of English grammar in the above text) signature.asc Description: Digital signature
Accepted hunspell-sv 1.51-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 08 Jan 2012 18:44:35 +0200 Source: hunspell-sv Binary: hunspell-sv-se myspell-sv-se Architecture: source all Version: 1.51-1 Distribution: unstable Urgency: low Maintainer: Jon Lachmann (JoTaB) j...@lachmann.nu Changed-By: Agustin Martin Domingo agmar...@debian.org Description: hunspell-sv-se - Swedish (SE) dictionary for hunspell myspell-sv-se - transitional dummy package Changes: hunspell-sv (1.51-1) unstable; urgency=low . * New upstream release from www.dsso.se Checksums-Sha1: b0ac968d36f75e0eebf35ca36adecadca4ed0fa3 1155 hunspell-sv_1.51-1.dsc fb9da9d21137a513d2a9717abe6d9f33b028703d 382577 hunspell-sv_1.51.orig.tar.gz 6ce922dc2428068d649e6055f1e74d9cd9202fc5 2591 hunspell-sv_1.51-1.debian.tar.gz c0b8976473ea9231e287e014af1ea75baf4f45d0 385674 hunspell-sv-se_1.51-1_all.deb 680ff3692212400fa75241e90f3814287396a797 2404 myspell-sv-se_1.51-1_all.deb Checksums-Sha256: fc7c85121bef40dbe553efac925a0487c71d5770661f0c3f47feff55f23fb771 1155 hunspell-sv_1.51-1.dsc 1c2c6ad3d54f0b18c5d53f097cfd6ea78adbde7af64dd1a8a5f46fb95663e867 382577 hunspell-sv_1.51.orig.tar.gz e11be354632d3f71579e3ac7e33b32555f017fe8c2e2c9a796d2a533e95b 2591 hunspell-sv_1.51-1.debian.tar.gz de787043e5dceaa5e2bd0366b639287586e3ddb099c6913f655479da34fb423d 385674 hunspell-sv-se_1.51-1_all.deb c340cf8c1b61c57387e88399daf3915c3a0001b8e02cfc35802f72dad2642a09 2404 myspell-sv-se_1.51-1_all.deb Files: 21ff2fab0c30f94b5756eb641f00336f 1155 text optional hunspell-sv_1.51-1.dsc 6f8553a80c53c6558f48edc10c2082ab 382577 text optional hunspell-sv_1.51.orig.tar.gz 558bad2ce356b425947b20dc188dd249 2591 text optional hunspell-sv_1.51-1.debian.tar.gz 0f2afe485b324eac60da90e2e9a83b39 385674 text optional hunspell-sv-se_1.51-1_all.deb 07e4acb062a710ea67ebed83a4373974 2404 oldlibs optional myspell-sv-se_1.51-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFPM31PTShHqj72DpwRAscLAJ9ccciTmMpsBsztjptU66QEd5FjNQCcD5F3 2I2IltN72r8qOCKAWIguMEw= =wCAC -END PGP SIGNATURE- Accepted: hunspell-sv-se_1.51-1_all.deb to main/h/hunspell-sv/hunspell-sv-se_1.51-1_all.deb hunspell-sv_1.51-1.debian.tar.gz to main/h/hunspell-sv/hunspell-sv_1.51-1.debian.tar.gz hunspell-sv_1.51-1.dsc to main/h/hunspell-sv/hunspell-sv_1.51-1.dsc hunspell-sv_1.51.orig.tar.gz to main/h/hunspell-sv/hunspell-sv_1.51.orig.tar.gz myspell-sv-se_1.51-1_all.deb to main/h/hunspell-sv/myspell-sv-se_1.51-1_all.deb -- 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/e1rvphd-0006fv...@franck.debian.org
Accepted libmemcached 1.0.4-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Feb 2012 07:53:00 +0100 Source: libmemcached Binary: libmemcached9 libmemcached-dev libmemcached-dbg libmemcachedutil2 libmemcachedprotocol0 libhashkit1 libhashkit-dev libmemcached-tools Architecture: source amd64 Version: 1.0.4-2 Distribution: unstable Urgency: low Maintainer: Michael Fladischer fladischermich...@fladi.at Changed-By: Michael Fladischer fladischermich...@fladi.at Description: libhashkit-dev - libmemcached hashing functions and algorithms (development files) libhashkit1 - libmemcached hashing functions and algorithms libmemcached-dbg - Debug Symbols for libmemcached libmemcached-dev - C and C++ client library to the memcached server (development fil libmemcached-tools - Commandline tools for talking to memcached via libmemcached libmemcached9 - C and C++ client library to the memcached server libmemcachedprotocol0 - library implementing the memcached protocol libmemcachedutil2 - library implementing connection pooling for libmemcached Closes: 659193 Changes: libmemcached (1.0.4-2) unstable; urgency=low . * Disable tests on all architectures due to networking problems on the autobuilders. * libhashkit-dev now Replaces/Breaks on libmemcached-dev ( 1.0.3-1) to avoid ownership conflicts on certain files (Closes: #659193). * Update Vcs-* fields to point to new git repository. Checksums-Sha1: 3093f31ed4de18fe7007ed451a97da119b6d 2340 libmemcached_1.0.4-2.dsc 54a8290945c160a4528dc809aaaca329d85161e2 12188 libmemcached_1.0.4-2.debian.tar.gz 73e4cf582e001a49b2a295c06f47680c10d3ff84 100178 libmemcached9_1.0.4-2_amd64.deb e5ffae2d3765c9c1ba810b4476739c961ae03557 306706 libmemcached-dev_1.0.4-2_amd64.deb edb240d51b722193d06779a212d2ed9d368a5447 563412 libmemcached-dbg_1.0.4-2_amd64.deb 02b7632083767de0d00758d1162cf13eb8fc29a0 22784 libmemcachedutil2_1.0.4-2_amd64.deb 70543d21c31931342a5d3aa80b831d23e94e08bb 26396 libmemcachedprotocol0_1.0.4-2_amd64.deb 51edeac0ec3900174b0c778dc0ba77b35efcb1c7 23150 libhashkit1_1.0.4-2_amd64.deb a9d4dae084d65b183c694bb945e8251ed86e1587 41934 libhashkit-dev_1.0.4-2_amd64.deb e366057e129f4fd3af2c84c3fbf8ac000eb2ccdc 99478 libmemcached-tools_1.0.4-2_amd64.deb Checksums-Sha256: a53765d67618597666c0780058bd148e07e345ca7ee8da5ef10c8fc7719f090d 2340 libmemcached_1.0.4-2.dsc 310d5352824afdbf4fdde57fe66ed0700729ede2ea338d5b5a771b5a02faa701 12188 libmemcached_1.0.4-2.debian.tar.gz e421c362a7dd75d6e49400fb4750c3bd3d74e03aad2909a59d91ec5723e90c65 100178 libmemcached9_1.0.4-2_amd64.deb 13bd0cba870c331c7c4d167496150c69646b5287b9cdf019cb803104148b46c8 306706 libmemcached-dev_1.0.4-2_amd64.deb 5a52276b24706f7eecb14fb2a339eda511db05625c6d9d6a09fd00022aab1895 563412 libmemcached-dbg_1.0.4-2_amd64.deb c67c871001205b141cf4e8a3c42c62c5cf322bb2c9db71259845e81d827a5a0f 22784 libmemcachedutil2_1.0.4-2_amd64.deb f12c641d45affec9769c83f328362805bf3e7a6750a205441f01b49434549b7a 26396 libmemcachedprotocol0_1.0.4-2_amd64.deb 3fcdb1b53c8566a45997d2297266cf2364f2a24958bb425e8e6f5caa6aa10050 23150 libhashkit1_1.0.4-2_amd64.deb 151067b89931417c4738ae1889dab551005e8807b70dc4b6036f18f0bfdaad6c 41934 libhashkit-dev_1.0.4-2_amd64.deb 3542124f099f7f1c16c43b71009e9f22dc7e4b98b7432abbd2a2d32aa0a4bf61 99478 libmemcached-tools_1.0.4-2_amd64.deb Files: 3944ac9580ee7fb065b08190ea73d01a 2340 libs optional libmemcached_1.0.4-2.dsc 11602a823c9f9814437cde8603b20b0a 12188 libs optional libmemcached_1.0.4-2.debian.tar.gz dd9c7f328397c3c4117a9632da5c6dc3 100178 libs optional libmemcached9_1.0.4-2_amd64.deb 46b132958403ccb6b1492ede5f2a1d13 306706 libdevel optional libmemcached-dev_1.0.4-2_amd64.deb 9d9afcadb89b2272cf417ad2f31eb8c0 563412 debug extra libmemcached-dbg_1.0.4-2_amd64.deb b63072bf80017094777d293252997ab4 22784 libs optional libmemcachedutil2_1.0.4-2_amd64.deb f6f893c233f4b1d0036c359d39d4d1d6 26396 libs optional libmemcachedprotocol0_1.0.4-2_amd64.deb df63ffa15eecdb8296a45400ec773a21 23150 libs optional libhashkit1_1.0.4-2_amd64.deb 4f2e9227d78d586604dcad60771ba9c5 41934 libdevel optional libhashkit-dev_1.0.4-2_amd64.deb 75b5ad91ac77ad0539d27d436c320f27 99478 utils optional libmemcached-tools_1.0.4-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJPM4EhAAoJEBLZsEqQy9jkfpUP/30NSJfjHFgymdcvjYD2plYZ bCBytqBUBumpLVaUOhLU31Mr8+NE0N8YK71yc6kuiaGrWxiRxgondtN19Aqy40zK M2g+ng0jB1P0VM0+UOE8o+fV+JiyQvjl6bpm4Ik+EABPv4XuGjdO/40XlGhYnQ8q UuZ4R3edq4K7uCjrpdfJi8h4JcDi09o1dzOvsgQfCH791C6eHPcv8QGNvkqUVDXf TvjOVUK3ZX+W/eQXBzNFJqQ98z3BMHylhjz1BpGj4ludzo5+JyETmln36b/WmUDO iZYNsBuXJHSMGEYGDOt1dFwmAyAMqjGlj8gpIoRT6Zhh/QsdFup2KwKrbX6c4+hD STwTKoxOgWhYRsjmuNbFcfYalOsZk4f9BjOdCqfRqwwe9BH6XrN25T2//f3Wzb5S xTKtbsDbxGCToXD1ltkztmdKdD9EWK8hsKsk6060vfrzadqcGgANpkJFjfVbm4Us kcZdyxzR7MBeZh68onjQlFnRjcUfFCJA9HmZbFs/rpLuTG5BA6gVY6kr6TSJm7vD 64d5Ugr4iNHWiXxMCztAWqaKzljxCpQ09bSt3LbOxVuJnuKxcRgtpSmJ9/pRKbbD
Accepted pinot 0.96-1.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 30 Jan 2012 01:11:28 -0600 Source: pinot Binary: pinot Architecture: source amd64 Version: 0.96-1.2 Distribution: unstable Urgency: low Maintainer: Jonas Smedegaard d...@jones.dk Changed-By: Steve M. Robbins s...@debian.org Description: pinot - meta-search engine for local files and web queries Closes: 652786 Changes: pinot (0.96-1.2) unstable; urgency=low . * Non-Maintainer Upload. * patches/boost1.48.patch: New. Include code from Boost singleton.hpp header, obsoleted in Boost 1.48. Closes: #652786. Checksums-Sha1: 3066f8c5907714dad3187e9c4bdeafea290007df 1596 pinot_0.96-1.2.dsc 3fd28994d2cb54a301a7c13599fed72e38834d35 17391 pinot_0.96-1.2.debian.tar.gz 2a8712bf6850973bffb4a9dcccd1bde43ab78df3 1971260 pinot_0.96-1.2_amd64.deb Checksums-Sha256: 0f38fd57a524947a4223a35454e9e7c4c92b9433f8965312c87221338a408713 1596 pinot_0.96-1.2.dsc 02ce6cb15f0d0dc1ef75fedc445f5c75ee26f6ad616bb7d90b5ce2c477075e0c 17391 pinot_0.96-1.2.debian.tar.gz 85360104cf9cca8cee25b1b9aed426ac393fa9e600709e45897e2acf1d20ce77 1971260 pinot_0.96-1.2_amd64.deb Files: 667d0fc433ecee01810c324c421b4b7b 1596 x11 optional pinot_0.96-1.2.dsc ec3bc314f2e0028350e5dfc9c25e8cb8 17391 x11 optional pinot_0.96-1.2.debian.tar.gz deb9d98db93879d750a7b4b39bfbe441 1971260 x11 optional pinot_0.96-1.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFPJkgk0i2bPSHbMcURApeTAJ9196U6KqaN0wBXV8+NbJSf/KXi4wCgrc6f fAWnfbbAOtlzvPBxNvD1KxU= =+t+j -END PGP SIGNATURE- Accepted: pinot_0.96-1.2.debian.tar.gz to main/p/pinot/pinot_0.96-1.2.debian.tar.gz pinot_0.96-1.2.dsc to main/p/pinot/pinot_0.96-1.2.dsc pinot_0.96-1.2_amd64.deb to main/p/pinot/pinot_0.96-1.2_amd64.deb -- 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/e1rvpiw-0007ey...@franck.debian.org
Accepted libmikmod 3.1.12-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 10:10:59 +0100 Source: libmikmod Binary: libmikmod2-dev libmikmod2 Architecture: source amd64 Version: 3.1.12-3 Distribution: unstable Urgency: low Maintainer: Gergely Nagy alger...@madhouse-project.org Changed-By: Gergely Nagy alger...@madhouse-project.org Description: libmikmod2 - Portable sound library libmikmod2-dev - Portable sound library - development files Closes: 656779 Changes: libmikmod (3.1.12-3) unstable; urgency=low . * Build with hardened build flags. Based on a patch by Moritz Muehlenhoff j...@debian.org. (Closes: #656779) Checksums-Sha1: 08fe31d3205daec75d12d25caefe2dc82f3aa69b 1929 libmikmod_3.1.12-3.dsc a953b3ebaff7b10ef28f073eabb1d8f1e5769753 11911 libmikmod_3.1.12-3.debian.tar.gz fd9a388945463fb97efaaab6b467ebed2f1e07e6 265764 libmikmod2-dev_3.1.12-3_amd64.deb 3389826365fbebe0b7819228dfc22b7b03ecb968 162500 libmikmod2_3.1.12-3_amd64.deb Checksums-Sha256: 27a43d8a0a990f9e0b4f35544b30ed9b1dee02e985c6ebc928c6667785791b2d 1929 libmikmod_3.1.12-3.dsc 527eb8825c2be97bec71ff09aa1a590b1a7f7ac079327c4818759689c136b7d7 11911 libmikmod_3.1.12-3.debian.tar.gz 9eeffd60e672d4e20d2d17459589b52c6262a8219105502b35a7cbfeba6600aa 265764 libmikmod2-dev_3.1.12-3_amd64.deb 694d017ab9b089988b40ca9868e0e279b9b98537cb0acbf88d41185cafac2332 162500 libmikmod2_3.1.12-3_amd64.deb Files: d38f2bd306000bef90cb16f82f7e8568 1929 libs optional libmikmod_3.1.12-3.dsc a50ae5dc036dc475e94c99b48d474c50 11911 libs optional libmikmod_3.1.12-3.debian.tar.gz f9cb6a1da08126a063f30458e360f02b 265764 libdevel optional libmikmod2-dev_3.1.12-3_amd64.deb b31a4eec6e6fb005aada97f4194beab6 162500 libs optional libmikmod2_3.1.12-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPM5FtAAoJEKwekLrEM/aPsmkQANE3f9XAk3joWnwBwvwp1N3r qdbwQTzDYkrB9A+CNjzcGFN3NcikkA1/j+83E8EBftVJ7im7/K97T23+hiQl2v9j OHYiGyF5Rq3AWscPRPjUwuDDfA3aYfFQuCeAuj6BF10GDP+dL+CPvdeMU6EXyCmx Glk+0krD6jJAiue3YVjVnG2D+WybO9WCS3bUShj1CXKQrFA9b42mnB0FmzgLg5sX Q1gdjHRkLQSrsuLKhNcQWI20jZu/+NghOpLIucRwfxmojlD0Z7LOVYk+vnCrHgNm lIaoVruuvbp0Hd2yYQdqmSWMiUhLojLNQT2Yo8E+sPHO8T5i7t7HbnxIegVYj/Kt pza1+CHcQKtnNnxFkJpU3ODXYCTazC9BtU3UKmYm/JBfO705WCE85h5E28Bh5ffN OZn+3ZOLRbdId24qCkpPycFSRPu/MQvukrUSz+4VkwZVZsRGBhU7X6vrK4wnrvYM xCP+njRXKyu6kxqDrVVw9sGjIT0oWyt2NwQ/f1GYFY8ksllbkX5S7M4aBq1k09iY ECiylOsZnLcPIazqhjQTYn8j3jRfn4Xj4KzQfvNFTy3SvIzmDEJT6qs3tDEiMgpf B2jbxYWqVg1HgNg9vTH2zoNh+kakIv9rNWPhHl6gW085zo0rI4/29YH//UwfsK8J +muMaU6+fMF2r7J+WG55 =lwm8 -END PGP SIGNATURE- Accepted: libmikmod2-dev_3.1.12-3_amd64.deb to main/libm/libmikmod/libmikmod2-dev_3.1.12-3_amd64.deb libmikmod2_3.1.12-3_amd64.deb to main/libm/libmikmod/libmikmod2_3.1.12-3_amd64.deb libmikmod_3.1.12-3.debian.tar.gz to main/libm/libmikmod/libmikmod_3.1.12-3.debian.tar.gz libmikmod_3.1.12-3.dsc to main/libm/libmikmod/libmikmod_3.1.12-3.dsc -- 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/e1rvqnz-0003u6...@franck.debian.org
Accepted ideviceinstaller 1.0.0-1.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 07 Feb 2012 10:10:12 +0100 Source: ideviceinstaller Binary: ideviceinstaller ideviceinstaller-dbg Architecture: amd64 source Version: 1.0.0-1.2 Distribution: unstable Urgency: low Maintainer: Julien Lavergne julien.laver...@gmail.com Changed-By: Ansgar Burchardt ans...@debian.org Closes: 656938 Description: ideviceinstaller - Utility to manage installed applications on an iDevice ideviceinstaller-dbg - Utility to manage installed applications on an iDevice - debug Changes: ideviceinstaller (1.0.0-1.2) unstable; urgency=low . * Non-maintainer upload. * Fix build failure on architectures where sizeof(long) is 4. (Closes: #656938) Thanks to peter green plugw...@p10link.net for the patch. + updated patch: 653893-libzip-0.10.patch Checksums-Sha1: 47aed17472c5d399163b6a26af7595c36161d9fa 1938 ideviceinstaller_1.0.0-1.2.dsc f87196a82781b6fcf90b6a2efa0883f0e5f180b3 3116 ideviceinstaller_1.0.0-1.2.debian.tar.gz 61844bf747ae65cc5cf414aab2e812030982b154 14652 ideviceinstaller_1.0.0-1.2_amd64.deb a4d5e11e4b6be84566d63e15bddf7f5011df86f9 14388 ideviceinstaller-dbg_1.0.0-1.2_amd64.deb Checksums-Sha256: f685d8efcd4be4d8e8e554d84af7157378bd973527aa05f15960a0902bba72e0 1938 ideviceinstaller_1.0.0-1.2.dsc c6053963616ae318c8c1485c8936fd37fca5987c81eeb547411c42005589d83d 3116 ideviceinstaller_1.0.0-1.2.debian.tar.gz 772f8d73bf9eb6f6199263d010122bdf5bb47288ed719f6036ea6bef16867c63 14652 ideviceinstaller_1.0.0-1.2_amd64.deb bff4261ae6aa1246c7c6dac5241d639663811a6e2ae754141ac58481417f0ae8 14388 ideviceinstaller-dbg_1.0.0-1.2_amd64.deb Files: f1f3de3862ce21a5c600f73393f299cb 1938 utils optional ideviceinstaller_1.0.0-1.2.dsc 9a03797736069ecc7275a4ef70705df2 3116 utils optional ideviceinstaller_1.0.0-1.2.debian.tar.gz fe5c2661b9b696487fe2163c39e63c54 14652 utils optional ideviceinstaller_1.0.0-1.2_amd64.deb 56c69df79b61c1f6f98bbceec8940253 14388 debug extra ideviceinstaller-dbg_1.0.0-1.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPMO6xAAoJEIATJTTdNH3Ifu8QALnJQ42FntysBP9bHL0M9O/3 QE5bjrxDzT2aj/M4wLHalA/CkKgOH4Kbq0MlrDR+gTbRErBt1tInLhVA2dAzas13 czvVFz0kvm3oYpXhtlGrCAQvGocmuzYg7i1xv6FL0DFDSO6PNRXKlCQ1zBSuKJhO 0AfFAdW+/32t3kCuCAVph07JIEhqm+Wd4CBUEtsy6FRxTxZHWLjt9V5uodFczuWc +/MkCDcSXBk5C6lIrnE83XAHxA1nunEX5ZeoAk538glnV6CqGVvCwnd2YTd504QP eZ8hyytvirjmSUA6TEJNpHMnGsW0ifXsElJvisCYM5CsK4r9zDhSJneIYNSg1MeH sGMF7xN3hZQRD8Wz7pqQxoKrODqpmultlcz99s/stINdhXoGBXwCgSuhY5ydUWm8 xHiSlaGAaq/QXiy/4NNgtoY8OMt5B46mWWLdOq+UuhPxw2TFRBcSE0H3dv55Io7h ULoTNQ2XeUw+ETB1bMfoHryJZEZ85jLQWbuc7x0ntGuH8yHjNCya60R6Lq4e8adG 2JSMiPZIWcDn/l5TyaL7zYwPe6Kb4YAfBw7CIBgHwbaHC32eiD7oHNzrfFCo2VeU 8gFj7Zx7lIsyjXEJ7Fg+2kJIyDUHPAsNny4zKDK4oPvo+s7vIJ+d3dTQAcppS5Z5 T+/jhq//Fc5XmwSZ+jvY =Xsqn -END PGP SIGNATURE- Accepted: ideviceinstaller-dbg_1.0.0-1.2_amd64.deb to main/i/ideviceinstaller/ideviceinstaller-dbg_1.0.0-1.2_amd64.deb ideviceinstaller_1.0.0-1.2.debian.tar.gz to main/i/ideviceinstaller/ideviceinstaller_1.0.0-1.2.debian.tar.gz ideviceinstaller_1.0.0-1.2.dsc to main/i/ideviceinstaller/ideviceinstaller_1.0.0-1.2.dsc ideviceinstaller_1.0.0-1.2_amd64.deb to main/i/ideviceinstaller/ideviceinstaller_1.0.0-1.2_amd64.deb -- 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/e1rvqbd-0005go...@franck.debian.org
Accepted php5 5.4.0~rc7-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 00:03:26 +0100 Source: php5 Binary: php5 php5-common libapache2-mod-php5 libapache2-mod-php5filter php5-cgi php5-cli php5-fpm 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.0~rc7-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 php-pear - PEAR - PHP Extension and Application Repository php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-enchant - Enchant module for php5 php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) php5-gd- GD module for php5 php5-gmp - GMP module for php5 php5-imap - IMAP module for php5 php5-interbase - interbase/firebird module for php5 php5-intl - internationalisation module for php5 php5-ldap - LDAP module for php5 php5-mcrypt - MCrypt module for php5 php5-mysql - MySQL module for php5 php5-mysqlnd - MySQL module for php5 (Native Driver) php5-odbc - ODBC module for php5 php5-pgsql - PostgreSQL module for php5 php5-pspell - pspell module for php5 php5-recode - recode module for php5 php5-snmp - SNMP module for php5 php5-sqlite - SQLite module for php5 php5-sybase - Sybase / MS SQL Server module for php5 php5-tidy - tidy module for php5 php5-xmlrpc - XML-RPC module for php5 php5-xsl - XSL module for php5 Closes: 633100 633491 650203 650204 659123 Changes: php5 (5.4.0~rc7-2) experimental; urgency=low . * Use corrected module PHPAPI (20100525) and not (220100525) * Use $ZEND_MODULE_API_NO for $DEBIAN_PHP_API. Check for PHPAPI changes, so we don't become binary incompatible without knowing it. * Update debian/README.Debian.security: + register_globals was removed from PHP 5.4 + Remove safe_mode (removed upstream) and update and reformat text slightly + Reviewed by english l10n team (thanks a lot) * php5-fpm now listen on socket instead of localhost by default (Closes: #650204) * Add NEWS about change of default location of php5-fpm socket * Stop php5-fpm on runlevels 0 1 6 (Closes: #650203) * Add -ignore_readdir_race to find call in session cleanup (#634864) * Don't prefix extension list automatically, it's done by subsvars now (Closes: #633491) * Depends on non-forking fuser in psmisc (Closes: #633100) * php5-common.README.Debian additions and cleanup: + Add a paragraph about PHP_INI_SCAN_DIR (Closes: #659123) + Reformat README.Debian to common formatting + Mention php5-fpm where appropriate + Use 'PHP 5' and 'Apache HTTP Server' instead of php5 and apache2 Checksums-Sha1: 398ce41863c37cc77ae3071b5c2ff39c86935a6b 3644 php5_5.4.0~rc7-2.dsc a12aa7ddea784f50b9bddc7d05643c230a2b3c2d 175151 php5_5.4.0~rc7-2.diff.gz 89560474f8acc541670b25221afe90eaaf26046c 587188 php5-common_5.4.0~rc7-2_amd64.deb 9312ceb094810b31b6bc05c86e53074c457ac46f 2635614 libapache2-mod-php5_5.4.0~rc7-2_amd64.deb d9e768feb8badb1fa969a5d4aa8a4a73e3c1a807 2634378 libapache2-mod-php5filter_5.4.0~rc7-2_amd64.deb 5efd21f4e41a72212ac06f62143428baaff790c1 5034334 php5-cgi_5.4.0~rc7-2_amd64.deb 8977c7cb16bf39299e366d47d8a945fb23a77413 2526898 php5-cli_5.4.0~rc7-2_amd64.deb 207bb52a20fcbbc2acacad0efd78600779d4ac0d 2558674 php5-fpm_5.4.0~rc7-2_amd64.deb 60d2d3a15afa8c752cd1270cfd3b1e0832ed62aa 492984 php5-dev_5.4.0~rc7-2_amd64.deb 68624aecf1d34af173c6e6562bf6ae50958eebb5 14272952 php5-dbg_5.4.0~rc7-2_amd64.deb 297ec09068241914b30ab7c38cf7d8fcbbc966b6 28980 php5-curl_5.4.0~rc7-2_amd64.deb f51fd798431c1170eedba39ae8900321b1c971f2 9764 php5-enchant_5.4.0~rc7-2_amd64.deb ab32f53faf09ae3337fa6b9857a2585ca8d75575 35262 php5-gd_5.4.0~rc7-2_amd64.deb cc4bea379e08acc8facee6d3ad00c76b9b31b902 17290 php5-gmp_5.4.0~rc7-2_amd64.deb 1c4b0c7bac7bcadbbe398df9da2bffd1e70a2816 35478 php5-imap_5.4.0~rc7-2_amd64.deb da81503a4954fa399ca7742f8b71d5369e57880f 49770 php5-interbase_5.4.0~rc7-2_amd64.deb ab3620df96f1495f99351c3b9e626a647ff81c63 71700 php5-intl_5.4.0~rc7-2_amd64.deb e8788966e63971c7c53186f2143448d54c1e33ea 21710 php5-ldap_5.4.0~rc7-2_amd64.deb
Accepted libgpepimc 0.9-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 10:40:33 + Source: libgpepimc Binary: libgpepimc-dev libgpepimc0 libgpepimc0-dbg Architecture: source amd64 Version: 0.9-4 Distribution: unstable Urgency: low Maintainer: Moray Allan mo...@debian.org Changed-By: Neil Williams codeh...@debian.org Description: libgpepimc-dev - category management for GPE applications [development] libgpepimc0 - category management for GPE applications [runtime] libgpepimc0-dbg - category management for GPE applications [debugging] Changes: libgpepimc (0.9-4) unstable; urgency=low . * Drop docs completely, there never was any additional content over what is listed in the header file. Checksums-Sha1: ebed80a41514a77b74b79d6130a687fcfcd6619f 1579 libgpepimc_0.9-4.dsc 9d8b48e581854c95eb5d21a14fc163650e2ba552 2490 libgpepimc_0.9-4.debian.tar.gz 8f7489fa1b0e5e403713c32656f0ee17b41f8620 15322 libgpepimc-dev_0.9-4_amd64.deb 83fe9763e4ae2333cdfea1ddc84d647e6680a535 16272 libgpepimc0_0.9-4_amd64.deb 3ac5dc1d06a99aab0df26dd9afa2d3a50bc1dbae 25486 libgpepimc0-dbg_0.9-4_amd64.deb Checksums-Sha256: 37e52ea151a546aceb8133bfd468ec76ceb2aeccbd59020295048881aaf55638 1579 libgpepimc_0.9-4.dsc 95d8ea0a9a3c22610bf101c5293128fe2c550c771362af1d8671f345c999fe5b 2490 libgpepimc_0.9-4.debian.tar.gz 896ef266f34f2bf33d6424ae78bf10c22a0135f9d8f4bf91e15fe16280358132 15322 libgpepimc-dev_0.9-4_amd64.deb 6dfdd9493d91ecd454ffe4f3d3f8e64a9148eb19da4dc124df398824a97d10dd 16272 libgpepimc0_0.9-4_amd64.deb 18b8c1cb9f2eaf9062c21c8ea68d80df2e5df1558f9a191e712981702bfa6312 25486 libgpepimc0-dbg_0.9-4_amd64.deb Files: c736660d4e80f2494c00c3a94b1df7bc 1579 libs - libgpepimc_0.9-4.dsc 0fa1e1f881d9f14ac7f0ca7e4b96c63b 2490 libs - libgpepimc_0.9-4.debian.tar.gz 2f5a68e8c372eb8f32f02b53b0ac8222 15322 libdevel optional libgpepimc-dev_0.9-4_amd64.deb acd1476aa409c5dfb3792b2bb50f12f7 16272 libs optional libgpepimc0_0.9-4_amd64.deb 643c460f3aa91656ca66685da9148855 25486 debug extra libgpepimc0-dbg_0.9-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8zqM4ACgkQiAEJSii8s+OnZwCg34hLvVp9qHeKoKu1Szm5Uo37 xOgAnjaJuSGM/dPrSmYHQtLuVSvFt8dT =PRwS -END PGP SIGNATURE- Accepted: libgpepimc-dev_0.9-4_amd64.deb to main/libg/libgpepimc/libgpepimc-dev_0.9-4_amd64.deb libgpepimc0-dbg_0.9-4_amd64.deb to main/libg/libgpepimc/libgpepimc0-dbg_0.9-4_amd64.deb libgpepimc0_0.9-4_amd64.deb to main/libg/libgpepimc/libgpepimc0_0.9-4_amd64.deb libgpepimc_0.9-4.debian.tar.gz to main/libg/libgpepimc/libgpepimc_0.9-4.debian.tar.gz libgpepimc_0.9-4.dsc to main/libg/libgpepimc/libgpepimc_0.9-4.dsc -- 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/e1rvs0x-0006b3...@franck.debian.org
Accepted identicurse 0.8.2+dfsg0-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 09 Feb 2012 12:10:50 +0100 Source: identicurse Binary: identicurse Architecture: source all Version: 0.8.2+dfsg0-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: identicurse - simple Identi.ca client with a curses-based UI Changes: identicurse (0.8.2+dfsg0-3) unstable; urgency=low . * Orphaning this. Checksums-Sha1: b6a22e8fff4bbd3f44217e928c9263fa0ef94b38 1944 identicurse_0.8.2+dfsg0-3.dsc 787a06a1e655f2686f6325d32df85fac819b892f 4408 identicurse_0.8.2+dfsg0-3.debian.tar.gz de2d4c5d6da09fd6c898a23e453672217d1c2e0f 58674 identicurse_0.8.2+dfsg0-3_all.deb Checksums-Sha256: 4d1685805acb7457815e2677a803000beaf02769a38c29069974175036c10e80 1944 identicurse_0.8.2+dfsg0-3.dsc 314160c3c332d42ab720bf3348f7091dabb03479090f3c29ef28062d5b148d95 4408 identicurse_0.8.2+dfsg0-3.debian.tar.gz de3bab6b9c5fd6ddda2a71df1549a09978071d61ed26bcc132fd03dccf6c5880 58674 identicurse_0.8.2+dfsg0-3_all.deb Files: e45e0c8ec9dd153e61d98165003a850c 1944 net optional identicurse_0.8.2+dfsg0-3.dsc a39af1c443f7555e966646620c46ff84 4408 net optional identicurse_0.8.2+dfsg0-3.debian.tar.gz 77d81d9acba792dd414ec727daf2f91c 58674 net optional identicurse_0.8.2+dfsg0-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPM6qSAAoJEOikiuUxHXZaAa4P/itZ5FiEWHnHgjy4ylQSZ+Pd DGnrV7+xJjYAeMb/oaPbnVDKGrRmn84iQr89neC62YdGW27VDUAhunCbEx/sMZw4 sdx2zv80S22JrlUkiFdyDwSuzafoUgfN6xsbXTCfKprJeYuU0og1Pg2c73UB78UD cqr8fW4w1eJB42VNouxhl3XH333FcbkYRCs/4jdybYzWKRLr+PgvpwYwg+Lo5/z6 vIx/oYpDPxggujUHpKBPPpUfr/0UTEkkQl86fAUYlZ5yEb9IuwV3417q50tzpaTR g00qwMp3bWjKacpJVzRhr0un3Y7X69JSBkZhynxfHPEaBBwoTiutFEK426MiEv8I 3Xc25zE72MX3FS/ZyEey1t3owJAwtCC0CjuOYqLSgQZf9rUnXhnsSmHdzV0HlhpP wVX2BAWwbygTxIPwrAP3oofLdmXOdhvasNde6LAAO0AawIN7V7R3t4/aAb99kA95 yuACgluVtuu25NQW/hJxiWCEo6vXRgls0wLF+lFz8W8jna+GYjMKpvRhZDLnP+na bn5pErXS4tC1sd4b0ov5YYFVXnc4WxRPLNx5jnFA0JHvGWVb7qrJvaR4oSsPfstO G+T4ltniMmbMYKWfHf/EEBq+0ww2o+uuX2VgZwGSFa9sDEx2R5dMq0pmzaP0KjC9 AX9TqRaieI3x63Vc0SDY =Ht6U -END PGP SIGNATURE- Accepted: identicurse_0.8.2+dfsg0-3.debian.tar.gz to main/i/identicurse/identicurse_0.8.2+dfsg0-3.debian.tar.gz identicurse_0.8.2+dfsg0-3.dsc to main/i/identicurse/identicurse_0.8.2+dfsg0-3.dsc identicurse_0.8.2+dfsg0-3_all.deb to main/i/identicurse/identicurse_0.8.2+dfsg0-3_all.deb -- 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/e1rvsf4-ei...@franck.debian.org
Accepted python-gudev 147.2-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 28 Apr 2011 00:20:39 +0200 Source: python-gudev Binary: python-gudev Architecture: source amd64 Version: 147.2-3 Distribution: unstable Urgency: low Maintainer: Alessio Treglia ales...@debian.org Changed-By: Alessio Treglia ales...@debian.org Description: python-gudev - Python bindings for gudev Changes: python-gudev (147.2-3) unstable; urgency=low . * Add dh-autoreconf to DH sequence. * Switch to dh_python2. * debian/rules: - Add --as-needed to linker flags. - Build for all supported Python versions. - Remove unneeded *.la files. - Prune empty directories. * debian/gbp.conf: Set sign-tags to True. * Update debian/copyright. * Bump Standards. Checksums-Sha1: a090a8d1715483591b0707b00808bcf90e4a626b 2044 python-gudev_147.2-3.dsc 07f10b5dc7d1cc3e623f8b94745ddac1060f2712 2164 python-gudev_147.2-3.debian.tar.gz d9976e54937679af5e56addef97ac7192e4c9f45 12208 python-gudev_147.2-3_amd64.deb Checksums-Sha256: b027583dbf77b02e871347123b0142cffb3ff91fd1d3f76fbae9fcf3bbcec7c4 2044 python-gudev_147.2-3.dsc a80bbb5e41e8035d47077fc237ae912eea9f70b5c7a66c136eb3bf3a87b4849f 2164 python-gudev_147.2-3.debian.tar.gz 40cfbe2107ad29afac3e0efa7aa345fea8fd3354d60116de64e1d15d855a1c52 12208 python-gudev_147.2-3_amd64.deb Files: 95176dc69bac2b08aae021fa425687a9 2044 python optional python-gudev_147.2-3.dsc 50abe2853972d40cfe44a586a8ba0317 2164 python optional python-gudev_147.2-3.debian.tar.gz b0680f4802607761aabae19011d6b907 12208 python optional python-gudev_147.2-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPM62MAAoJEOikiuUxHXZacgQP/1nLu7s66v3/l68rTApeNkwq LRPD5zyVQD0+3kSVrJ8u2q3aRUfjgQiTF8fW6ak2cpYxYBoj0axuVG0pf16i+3pf PtRFxhNOSZXkjdAw/baK7kBfmMyfZZ4VNQD9GFVP/vMrfuCfQnF3YLrhtJHITfGb hKw1Qm9WfSrSALfTflRYTTq2RmTHhoR2Q31rKVXUSnNrUMtr+C8IyXUjGpJ3AhkQ Gzdq7FxJt6VOylXNqAxJHe/WHEqCNyUItq5tUky55vsEGlG1OS/ZXDwigFNRBk1c 6FvbYzldLnmqDIb4VIyaBLTldRz2wbZODZtGI8z/pHc0l1yIqbpKcJI8zekb0jtG tyIU2tBn+auFyMak5TY2BnX9cgQXvDXAe0miLoPccqxwOrzmCMxNgh3wy/gWnsCq l/EVBpqBCeEBRbUqj9nLLNW3c/kTPeUGwCPFBa65HPfZzst/dLAQBq8G8gldOY8h UWpeSkkUKHwXqCee8A9wJjprqhGC0IIahoyxP/Loe3ymlJ/clXgOV2UCuRhQTLn6 pSJ/YtkTHIzPobYUcjr3TpZyIQ1ybTrovGbTBj+rD59mw0jceXH5GxZBbh0gZ7hH vgfqpMA5Du9Ncgi5TfoJ8j+6hdTd+2+Tn1xqjAnY1MJF1jBMch9kDk5jJw9KI6Yt P44GDQ3vTKp8lLZXPqPQ =0PRo -END PGP SIGNATURE- Accepted: python-gudev_147.2-3.debian.tar.gz to main/p/python-gudev/python-gudev_147.2-3.debian.tar.gz python-gudev_147.2-3.dsc to main/p/python-gudev/python-gudev_147.2-3.dsc python-gudev_147.2-3_amd64.deb to main/p/python-gudev/python-gudev_147.2-3_amd64.deb -- 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/e1rvsfc-hv...@franck.debian.org
Accepted sql-ledger 2.8.36-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Feb 2012 11:48:03 +0100 Source: sql-ledger Binary: sql-ledger Architecture: source all Version: 2.8.36-1 Distribution: unstable Urgency: low Maintainer: Raphaël Hertzog hert...@debian.org Changed-By: Raphaël Hertzog hert...@debian.org Description: sql-ledger - Web based double-entry accounting program Changes: sql-ledger (2.8.36-1) unstable; urgency=low . * New upstream release. * Use debhelper compatibility level 9. * Update description to drop leading article (lintian warning). * Updated Standards-Version to 3.9.2. Checksums-Sha1: 0e7807345b60f3a406f3268d77bb5cf01088bd73 1892 sql-ledger_2.8.36-1.dsc e9d5d60c3ce3d3d1bfa5c2c40fb68bc8a13ee06e 3961574 sql-ledger_2.8.36.orig.tar.gz ca9c20c08f49725c41d82cbac71b87b7bb0d3d0c 16022 sql-ledger_2.8.36-1.debian.tar.gz cab5e66c3cadd5e0769ba1143faaeb3782841508 5521402 sql-ledger_2.8.36-1_all.deb Checksums-Sha256: c3a83894a7923aa8a3b9373b9fabba69e45a86a329da37dacd67c57c8f7bc0af 1892 sql-ledger_2.8.36-1.dsc f281f91804fe70e1ba71bf76d9ebdcb853b84d96b1d4d40e3b9610241a0b 3961574 sql-ledger_2.8.36.orig.tar.gz e40280939675c9f245279197149ee13f7d5314cee357b05aabbb756896e6be68 16022 sql-ledger_2.8.36-1.debian.tar.gz 5e57232ec8b87f66b353c2ee0f09e4c73c6f34cd7726c2c44ccd604f7cffdbcd 5521402 sql-ledger_2.8.36-1_all.deb Files: 6fa628ad0fc4106171a083a985bb285d 1892 web optional sql-ledger_2.8.36-1.dsc 4cac1938c0666a8db62bfb97ef7d1b41 3961574 web optional sql-ledger_2.8.36.orig.tar.gz f02a260144ea39808a0b66c7dfc8948f 16022 web optional sql-ledger_2.8.36-1.debian.tar.gz 5539e624aa5aa2ccf1d1578c9c6b4e6e 5521402 web optional sql-ledger_2.8.36-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Signed by Raphael Hertzog iQIcBAEBCAAGBQJPM6o8AAoJEOYZBF3yrHKaZxsQANO+FNTBfU/1EvbBA37yo40c aWNteV/t4LHthhjBWKV80VP3kzqDSV1+5wFy+yMwT7D++5kCLX7esU4CCqpxLA9s F4C7pV5lrEhOWm0roCOIu3mLcGOjYxXOCcZfnyxW7SZQwjGbPjO7/3hhIC6LgK5T Ydctapyx6gf1xBvTYHgJVQpRyEchV/wzj3jKPLcijtFLyodntODSRqPISvXggvyy 5o1/hX8ggkGptm9kET/cyv/YVr7fyIE//B3FXIMSsuPXMnM0ioUXBAxWRzUDuCug mCpxfJr1zFQYUkgmvcUx7YHf/TzBXxI2I41Uq0MbKZeaaGC5ipoLW8+aiklpjwr6 Ev+EPc1lD7xk57WtqLT8gGlIWt9CZls+di7JYPQzJFFJJBsPIktpkWJTl0uAhMfk eNOs5jTDo/T3sC8wwSbKaVUqpIVNJ7CB5ST7bBjzsoLGtvDQQuJcrfhSoUHbODv6 2IkZ0qsKDLtig3jsnF5YG2ckhFDtsugtGfude5FEUtLXr+0cC+8Xufuk9ueLoiAy XheyGS/oVPcfCUkBHMGNKNo2j9FbT4KJPa8fZRHNVLZSkTkSMsNlsALSg2GKg3Gl vUpDXFwAiIyWS4rXQplClKZW9nR5oijqooKbI0tTZUE0mHZUtNI8CFdX9DS1PAQu 159+Rgdudey+UVC/Vjjq =QE/q -END PGP SIGNATURE- Accepted: sql-ledger_2.8.36-1.debian.tar.gz to main/s/sql-ledger/sql-ledger_2.8.36-1.debian.tar.gz sql-ledger_2.8.36-1.dsc to main/s/sql-ledger/sql-ledger_2.8.36-1.dsc sql-ledger_2.8.36-1_all.deb to main/s/sql-ledger/sql-ledger_2.8.36-1_all.deb sql-ledger_2.8.36.orig.tar.gz to main/s/sql-ledger/sql-ledger_2.8.36.orig.tar.gz -- 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/e1rvsgb-jy...@franck.debian.org
Accepted qbzr 0.22-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 11:11:07 +0100 Source: qbzr Binary: qbzr Architecture: source all Version: 0.22-1 Distribution: unstable Urgency: low Maintainer: Debian Bazaar Maintainers pkg-bazaar-ma...@lists.alioth.debian.org Changed-By: Stefano Karapetsas stef...@karapetsas.com Description: qbzr - Graphical interface for Bazaar using the Qt toolkit Changes: qbzr (0.22-1) unstable; urgency=low . * New upstream release. * debian/patches/2.5compatibility.patch removed, it's applied upstream. Checksums-Sha1: 1af2090a6ea19a91341d94f803dbdc4607c3e75b 1566 qbzr_0.22-1.dsc fd17300bbfae7c18aad99c0149d74c89cd2c10a3 782946 qbzr_0.22.orig.tar.gz 2393cb6651b55375ff0d1230652ccb7e013d89f4 5790 qbzr_0.22-1.debian.tar.gz 34d5967f55b522a80574936c6dd16e3b3a73341d 446718 qbzr_0.22-1_all.deb Checksums-Sha256: 6011eb34b4b441abfd0c2a79a5e3ef3135f471d35b8cfe36c1e25338538eed19 1566 qbzr_0.22-1.dsc 6ec22d8f294bf6b59b0d4b16cd80a2042e11ba62fd730880752bb6185243cdb5 782946 qbzr_0.22.orig.tar.gz 9d42bc53e3308ac7fc20e235e4019cdf9d609fc2e04029c1feaaf53e79a348c0 5790 qbzr_0.22-1.debian.tar.gz bea5e087bd1e733741713811597c53c5622a07dfa2f4517051d2af3e869ae8a1 446718 qbzr_0.22-1_all.deb Files: b2bce3a99357ddd83903857347893bd8 1566 vcs optional qbzr_0.22-1.dsc c1434c822f48106d803be41e80ed4ab0 782946 vcs optional qbzr_0.22.orig.tar.gz b4c98e02e08872643681f8438ab69a47 5790 vcs optional qbzr_0.22-1.debian.tar.gz f3a589546be4ac62221bddf09061d02f 446718 vcs optional qbzr_0.22-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8zr+wACgkQPa9Uoh7vUnZTGgCfUjiw9mtTusfOUwU+9zasqsV1 b+gAnRz/qXOqhB/1Lab/H1DFlRbeog/q =A1g5 -END PGP SIGNATURE- Accepted: qbzr_0.22-1.debian.tar.gz to main/q/qbzr/qbzr_0.22-1.debian.tar.gz qbzr_0.22-1.dsc to main/q/qbzr/qbzr_0.22-1.dsc qbzr_0.22-1_all.deb to main/q/qbzr/qbzr_0.22-1_all.deb qbzr_0.22.orig.tar.gz to main/q/qbzr/qbzr_0.22.orig.tar.gz -- 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/e1rvsvq-00024a...@franck.debian.org
Accepted gnumed-client 1.1.12-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 12:59:51 +0100 Source: gnumed-client Binary: gnumed-client gnumed-client-de gnumed-common gnumed-doc Architecture: source all Version: 1.1.12-1 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org Changed-By: Andreas Tille ti...@debian.org Description: gnumed-client - medical practice management - Client gnumed-client-de - medical practice management - Client for German users gnumed-common - medical practice management - common files gnumed-doc - medical practice management - Documentation Changes: gnumed-client (1.1.12-1) unstable; urgency=low . * New upstream version * debian/control: Suggests: edfbrowser, autokey-qt | autokey-gtk as requested by upstream Checksums-Sha1: 703a9062c230880d1a16054f11362d0de24273cd 1621 gnumed-client_1.1.12-1.dsc a244458b501eef561d4e3208d44542c02bccb69d 12966441 gnumed-client_1.1.12.orig.tar.gz 33f01905db15ed285bfc15a143d0aec412f4cc3c 20524 gnumed-client_1.1.12-1.debian.tar.gz 387f84821f66622c74cc7d17fe44365ab032465a 1514704 gnumed-client_1.1.12-1_all.deb cdc0a99ae6ff3acf6f490600fe04efd09ffdc507 15304 gnumed-client-de_1.1.12-1_all.deb 54639bb2f0d30c16c1807ad26cdecfe767ddbdc0 135704 gnumed-common_1.1.12-1_all.deb fb7fb04922f5bc565a9382438bb802888cf287f2 1059510 gnumed-doc_1.1.12-1_all.deb Checksums-Sha256: b4ccfa5b6f25e8e0ddba78b2915daa87513e65a31fef2f30fb5a6996b2d8aac6 1621 gnumed-client_1.1.12-1.dsc e36fe4fa8b730be31f6384b2771c686fff3fe5b00fee7e02cc5985f79709b590 12966441 gnumed-client_1.1.12.orig.tar.gz e1a91134aef02ac3e5be1e1d512f50fc10826409f2c979e289a165bf63f6d8fe 20524 gnumed-client_1.1.12-1.debian.tar.gz 5347a640cf9f6adaa1c54499478a4671d3d0376e264c7f95c64e955ec9ebac04 1514704 gnumed-client_1.1.12-1_all.deb 4fa9d18a132af37be65ad12c4e778b8d77bec6b231c1fe295c48596daf1ea138 15304 gnumed-client-de_1.1.12-1_all.deb 0337bec1a8875addce83064d6acda3e7f9015d4bca62befa22c0b2eff618613a 135704 gnumed-common_1.1.12-1_all.deb 7982a92cef690e00840c0dcf55ca548f7e86ed7ecc24ccca4b891b8e8a412d78 1059510 gnumed-doc_1.1.12-1_all.deb Files: ca2750c6bce2185531e74962e1ee231f 1621 misc optional gnumed-client_1.1.12-1.dsc 8f18bf931703a5752dbbc76b8127150e 12966441 misc optional gnumed-client_1.1.12.orig.tar.gz cc7324d0b42636953f5a04c849445657 20524 misc optional gnumed-client_1.1.12-1.debian.tar.gz e8104b1f57a91db8f614fc2a11676b68 1514704 misc optional gnumed-client_1.1.12-1_all.deb e4dd1ac5b50eaf646960c705f6de0488 15304 misc optional gnumed-client-de_1.1.12-1_all.deb 22fa668ea543a677ad2c49a0d359a4bc 135704 misc optional gnumed-common_1.1.12-1_all.deb 08073b3794af56e326d19321d058700f 1059510 doc optional gnumed-doc_1.1.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8ztnsACgkQYDBbMcCf01qIhQCgw95xJMxw/IaBTWvcJ9Cdc4/X p7AAoKLqh6YxvtIG24Gr0OzrO49EwGza =z6nC -END PGP SIGNATURE- Accepted: gnumed-client-de_1.1.12-1_all.deb to main/g/gnumed-client/gnumed-client-de_1.1.12-1_all.deb gnumed-client_1.1.12-1.debian.tar.gz to main/g/gnumed-client/gnumed-client_1.1.12-1.debian.tar.gz gnumed-client_1.1.12-1.dsc to main/g/gnumed-client/gnumed-client_1.1.12-1.dsc gnumed-client_1.1.12-1_all.deb to main/g/gnumed-client/gnumed-client_1.1.12-1_all.deb gnumed-client_1.1.12.orig.tar.gz to main/g/gnumed-client/gnumed-client_1.1.12.orig.tar.gz gnumed-common_1.1.12-1_all.deb to main/g/gnumed-client/gnumed-common_1.1.12-1_all.deb gnumed-doc_1.1.12-1_all.deb to main/g/gnumed-client/gnumed-doc_1.1.12-1_all.deb -- 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/e1rvswb-0004by...@franck.debian.org
Accepted gnumed-server 16.12-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Feb 2012 13:18:24 +0100 Source: gnumed-server Binary: gnumed-server Architecture: source all Version: 16.12-1 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org Changed-By: Andreas Tille ti...@debian.org Description: gnumed-server - medical practice management - server Changes: gnumed-server (16.12-1) unstable; urgency=low . * New upstream version Checksums-Sha1: 17ded4567ff22eb2051c84774cb9f10652efbfea 1420 gnumed-server_16.12-1.dsc cca276356f0c90a8a5f71770cb1f164b235d37b3 13645857 gnumed-server_16.12.orig.tar.gz 8d306019b9fa77e5ef07001ab18cfbcf93423a7d 9862 gnumed-server_16.12-1.debian.tar.gz e67e15811474ed13fb0a675ea01e78c551c4f264 13493634 gnumed-server_16.12-1_all.deb Checksums-Sha256: 7d1b08c9bd4202db55cda097a9fb7f06b811cd667b7ea699b9ff34bf2dd37e60 1420 gnumed-server_16.12-1.dsc 4229ee4465c8e8ab6a9fdfb725abc7e28e3b1b6a0f51d22f7fbd93c6633a 13645857 gnumed-server_16.12.orig.tar.gz f6b528a70f80ec70c908e9967baef42025a89fe9a0b607412e206f848f7ff734 9862 gnumed-server_16.12-1.debian.tar.gz 3edd96d3eddfcc5a65d5b3a0b371a3ebe852788fb4dc4f229d47321b9df292a7 13493634 gnumed-server_16.12-1_all.deb Files: 753374bd0e2de31b4f6a9ea312f0d303 1420 misc optional gnumed-server_16.12-1.dsc 36deea6c19f09c73ef48c72868e5745e 13645857 misc optional gnumed-server_16.12.orig.tar.gz 0f5f61152164c1a354ce6f8a05cac6df 9862 misc optional gnumed-server_16.12-1.debian.tar.gz 0ec1c110b9d60862ae3d2cb072f7c8bb 13493634 misc optional gnumed-server_16.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8zueoACgkQYDBbMcCf01rbuACfV5fUJKvyI957SwrCeB649f7z 4KgAnj6B2h6d3RHJpinNe8dT5qMZ17Do =StT6 -END PGP SIGNATURE- Accepted: gnumed-server_16.12-1.debian.tar.gz to main/g/gnumed-server/gnumed-server_16.12-1.debian.tar.gz gnumed-server_16.12-1.dsc to main/g/gnumed-server/gnumed-server_16.12-1.dsc gnumed-server_16.12-1_all.deb to main/g/gnumed-server/gnumed-server_16.12-1_all.deb gnumed-server_16.12.orig.tar.gz to main/g/gnumed-server/gnumed-server_16.12.orig.tar.gz -- 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/e1rvtaf-00063s...@franck.debian.org
Accepted php-xml-parser 1.3.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Format: 1.8
Date: Sun, 29 Jan 2012 22:35:25 +0800
Source: php-xml-parser
Binary: php-xml-parser
Architecture: source all
Version: 1.3.4-1
Distribution: unstable
Urgency: low
Maintainer: PKG-PHP-PEAR team pkg-php-p...@lists.alioth.debian.org
Changed-By: Thomas Goirand z...@debian.org
Description:
php-xml-parser - PHP PEAR module for parsing XML
Closes: 656986
Changes:
php-xml-parser (1.3.4-1) unstable; urgency=low
.
* New upstream release.
* Switching from SVN to Git packaging on Alioth (updated Vcs fields).
* Using PKG-PHP-PEAR team pkg-php-p...@lists.alioth.debian.org as
maintainer (Closes: #656986).
* Switching debian/copyright to DEP5.
* Switching to source format 3.0 (quilt), updated patch to use quilt instead
of dpatch, remove a part of it for the new upstream version already includes
the switch from ereg to preg patch.
* Switching to pkg-php-tools and dh 8 sequencer.
* Removed now useless debian/{dirs,examples,README.Source}.
* Updated debian/watch file.
* Bumps Standard-Version to 3.9.2 (no changes).
Checksums-Sha1:
b4f7778d7bdbd0a86318e46412951ba052b954c6 1398 php-xml-parser_1.3.4-1.dsc
7dd5206d3de9654d2cbb4a9ece4ae2dcd30f377c 16040 php-xml-parser_1.3.4.orig.tar.gz
ea9ab495842c8c1e7efd1f214d699cec2ef7fc94 3585
php-xml-parser_1.3.4-1.debian.tar.gz
4a50e413727adff13068b1a57cca05fcf18d7177 26988 php-xml-parser_1.3.4-1_all.deb
Checksums-Sha256:
02393f95c03f28ccadde0b02eebaa9a165d471d0ac8ca6f983081dfcbcb2ffc7 1398
php-xml-parser_1.3.4-1.dsc
a56051e7a85cad139f150d3604a30cd92a91d7f2d9a32f3af9c59e0e3284c714 16040
php-xml-parser_1.3.4.orig.tar.gz
d7bab69175884c9264bc371803ff8f0dd00ee8e50141e3d2553b9f48ba26f950 3585
php-xml-parser_1.3.4-1.debian.tar.gz
17e84660da7e1cb99abe6e009519d3ab560e3bf91f41867b292d1686423e1b52 26988
php-xml-parser_1.3.4-1_all.deb
Files:
6dcb6af613d20407451da19cec7d2eaa 1398 php optional php-xml-parser_1.3.4-1.dsc
ee6add40489eb7df6670e18c26457cf9 16040 php optional
php-xml-parser_1.3.4.orig.tar.gz
322f192965867c3582a015d5fc8f5ba5 3585 php optional
php-xml-parser_1.3.4-1.debian.tar.gz
c754a495856790778860f2a624d0893e 26988 php optional
php-xml-parser_1.3.4-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEAREDAAYFAk8zzR4ACgkQl4M9yZjvmklysACfUK6b6CoxbiNa5YngKzb4VSw1
Qd4AnArBKE0qm7wzyw0j7fg9I3ZqpXe+
=dxyt
-END PGP SIGNATURE-
Accepted:
php-xml-parser_1.3.4-1.debian.tar.gz
to main/p/php-xml-parser/php-xml-parser_1.3.4-1.debian.tar.gz
php-xml-parser_1.3.4-1.dsc
to main/p/php-xml-parser/php-xml-parser_1.3.4-1.dsc
php-xml-parser_1.3.4-1_all.deb
to main/p/php-xml-parser/php-xml-parser_1.3.4-1_all.deb
php-xml-parser_1.3.4.orig.tar.gz
to main/p/php-xml-parser/php-xml-parser_1.3.4.orig.tar.gz
--
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/e1rvteb-0001as...@franck.debian.org
Accepted fso-abyss 0.9.0+git20100310-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 07 Feb 2012 13:45:30 +0100
Source: fso-abyss
Binary: fso-abyss
Architecture: source i386
Version: 0.9.0+git20100310-1.1
Distribution: unstable
Urgency: low
Maintainer: Debian FreeSmartphone.Org Team
pkg-fso-ma...@lists.alioth.debian.org
Changed-By: gregor herrmann gre...@debian.org
Description:
fso-abyss - GSM 07.10 Multiplexer
Closes: 629747
Changes:
fso-abyss (0.9.0+git20100310-1.1) unstable; urgency=low
.
* Non-maintainer upload.
* Fix FTBFS: build-dependency not installable: libvala-dev (=
0.8.1): switch to vala-0.10 (debian/{control,rules}, inspired by the
Ubuntu patch from Barry Warsaw).
(Closes: #629747, LP: #618809)
Checksums-Sha1:
c040e32fee8245aec29858038c175a45bfeb7953 2145
fso-abyss_0.9.0+git20100310-1.1.dsc
08edd3b037f05a35368704d80834235bff0c306e 3395
fso-abyss_0.9.0+git20100310-1.1.diff.gz
b663745dc50dd86ae0130e054a0f82429a24f124 30530
fso-abyss_0.9.0+git20100310-1.1_i386.deb
Checksums-Sha256:
33df0b72de831ac89fb3a188549cd431467390e621ee0adbe121a880cf337d05 2145
fso-abyss_0.9.0+git20100310-1.1.dsc
feb070a678e072c234c225eeaeed252a66e4b8e64213dc8a6e1019689419075a 3395
fso-abyss_0.9.0+git20100310-1.1.diff.gz
ffd704afa23d23d1579ca4a31e293f47d172cc5827faedc6f19805ff7ed49782 30530
fso-abyss_0.9.0+git20100310-1.1_i386.deb
Files:
5530c1a4d922ee3d43531b88bad9341b 2145 misc extra
fso-abyss_0.9.0+git20100310-1.1.dsc
5b3c4b9f98747cbda11f2c6a6f95a2d0 3395 misc extra
fso-abyss_0.9.0+git20100310-1.1.diff.gz
0550de96a820b830687ede02011c2a70 30530 misc extra
fso-abyss_0.9.0+git20100310-1.1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJPMR1jAAoJELs6aAGGSaoGd4QP/RGKmMzei36kjXTjAIfJjrdt
dPPGGCFsXzdEOEVLciz0uWO8CpqxC96WkGIN51D8OWxRSJ0CvLnonzIiQJJnuJ/n
QaORNQ3bhgd9u55sHXMxV4/QRmemgKV6fTOhlHMXgM0QzSKVFzs2cnh5jeRlxLHP
c3YHt8koxZMztqXV14sNQmgP1gMb++oIYoFXTr0LhDQeXKP35Gk6T99Ds94/JPCU
yHa/w6PVV5mkH+VeohKE72dxhrUgv3Iat9aPU+1FP2ClPjffHgHTnYbbOmWLp6i1
+kleGvGxT7SytucvSR+2ycZn8fCv4sg/kVIPfd+UbKS6Jpdm8Kltz8FaA7xp01dP
qmLl9nb+1Dc3a+8/kAmljLNv/fruOJRdT2qdCgjbvpL3O4rI3yCHpmM+5+0lnzao
YYlfzUYcgdzOGBJF6LleDh+XgVyUlotNvYF2sDtL6kgDHTOnxxqGPRyitgj5WhCZ
JdHIqp60deAOgFN3gl3WIzR9YAl3rnUvplFNNuHMlub945OgeOCsTDEOP+idzrta
mD3B33WFdmt62kMbls8/6NUcZzT0L2ZTsmfY49R8IuphUbKjexJ9X85wiF3sX9dj
fkcYar0wYc4y3j65hwmSr/nvOjQ4a5xKFMpprPmPW8CjApk/9jmVX//1u16MnIx1
pKhTa2BXJj3R+co/iT/c
=7mcc
-END PGP SIGNATURE-
Accepted:
fso-abyss_0.9.0+git20100310-1.1.diff.gz
to main/f/fso-abyss/fso-abyss_0.9.0+git20100310-1.1.diff.gz
fso-abyss_0.9.0+git20100310-1.1.dsc
to main/f/fso-abyss/fso-abyss_0.9.0+git20100310-1.1.dsc
fso-abyss_0.9.0+git20100310-1.1_i386.deb
to main/f/fso-abyss/fso-abyss_0.9.0+git20100310-1.1_i386.deb
--
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/e1rvtsd-00037e...@franck.debian.org
