[gentoo-dev] Last rites: dev-python/pisa
# Krzysztof Pawlik nelch...@gentoo.org (27 Jan 2012) # Deprecated, please migrate your code to dev-python/xhtml2pdf. # Removal by end of February. dev-python/pisa -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: x11-misc/enter
# Samuli Suominen ssuomi...@gentoo.org (28 Jan 2012) # Missing native ConsoleKit support and upstream has # stopped development. # Use lightdm, gdm, kdm, lxdm, slim (only latest), or xdm (only latest). # Removal in 30 days. x11-misc/enter
Re: [gentoo-dev] useless set*id binaries
On Sat, 28 Jan 2012, Samuli Suominen wrote: This is definitely not an improvement and should be reverted. The suid root is also needed to elevate cdrecord's scheduling priority. Missed that piece of code and reverted then. Any chance you could be more specific? cdrecord calls mlock(2), setpriority(2), and sched_setscheduler(2) to lock itself in memory and set realtime scheduling (and after having done so, it of course resets its uid to non-root). And yes, it really makes a difference on a moderately loaded machine. (Having written data from physics experiments to thousands of CDs/DVDs/Blurays, I think I can claim some experience here.) With file based capabilities, one could set CAP_IPC_LOCK and CAP_SYS_NICE instead of the suid root.
Re: [gentoo-dev] useless set*id binaries
On Sat, 28 Jan 2012 03:07:45 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: On 01/28/2012 02:41 AM, Mike Frysinger wrote: On Friday 27 January 2012 19:18:07 Samuli Suominen wrote: On 01/28/2012 02:14 AM, Mike Frysinger wrote: along these lines, why is cdrtools set*id ? if we have a cdrom group, and we assign our cdroms/dvdroms to that group, then we already have access control in place and can skip the set*id. cdrtools can't probe the drives without the binary being setuid, or the user belonging to the 'disk' group (and even that is not enough in some cases if the permissions vary) the drives are owned by the cdrom group and have group +rw. so if the user is in the cdrom group, why can't they probe the drives ? disk owns the non-removable hard drives. $ ls -l /dev/sr0 /dev/sg0 /dev/sg6 crw-rw 1 root disk 21, 0 Jan 6 23:07 /dev/sg0 crw-rw 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6 brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0 -mike i dont know why, but it does probe also non-removable disks... it probes per bus, iirc you can try it easily yourself: ssuominen@null ~ $ cdrecord -scanbus Does user actually need to be able to do this? Doesn't passing dev=... directly work? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Some news about status of ConsoleKit and Display Managers in Portage
pambase-20101024-r2 will restore the same behavior as pambase-20101024 had; it will restore the 'nox11' argument to the pam_ck_connector.so line in /etc/pam.d/system-login. this pam_ck_connector.so module is now used only for console logins because all of the display managers we ship, have native ConsoleKit support now: xdm since 1.1.11-r1 slim since 1.3.2-r7 lxdm, all versions gdm, all versions kdm, all versions lightdm, all versions enter, lastrited now in practise this means you don't need the CONFIG_AUDITSYSCALL in kernel for any of these display managers, or worry about pam_ck_connector.so at all. it also means you don't need to manually put 'ck-launch-session' anywhere in your configs, except when using startx with custom .xinitrc. and even startx works if you have XSESSION exported and no .xinitrc without adding ck-launch-session anywhere yourself. in otherwords, everything will just work(tm). long as people now remember to punt any custom trickery they might have added before we reached this point.
Re: [gentoo-dev] useless set*id binaries
On 01/28/2012 10:32 AM, Michał Górny wrote: On Sat, 28 Jan 2012 03:07:45 +0200 Samuli Suominenssuomi...@gentoo.org wrote: On 01/28/2012 02:41 AM, Mike Frysinger wrote: On Friday 27 January 2012 19:18:07 Samuli Suominen wrote: On 01/28/2012 02:14 AM, Mike Frysinger wrote: along these lines, why is cdrtools set*id ? if we have a cdrom group, and we assign our cdroms/dvdroms to that group, then we already have access control in place and can skip the set*id. cdrtools can't probe the drives without the binary being setuid, or the user belonging to the 'disk' group (and even that is not enough in some cases if the permissions vary) the drives are owned by the cdrom group and have group +rw. so if the user is in the cdrom group, why can't they probe the drives ? disk owns the non-removable hard drives. $ ls -l /dev/sr0 /dev/sg0 /dev/sg6 crw-rw 1 root disk 21, 0 Jan 6 23:07 /dev/sg0 crw-rw 1 root cdrom 21, 6 Jan 6 23:07 /dev/sg6 brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0 -mike i dont know why, but it does probe also non-removable disks... it probes per bus, iirc you can try it easily yourself: ssuominen@null ~ $ cdrecord -scanbus Does user actually need to be able to do this? Doesn't passing dev=... directly work? It will work if you specify it by hand. But how do you know without using -scanbus what to specify? Also, burning frontends, such as xfburn, rely on this functionality to automatically find the burner when USE=udev is disabled. And if I don't remember wrong, k3b also uses it as fallback method.
Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
On 01/27/2012 07:12 PM, Mike Frysinger wrote: On Friday 27 January 2012 16:05:13 Jason A. Donenfeld wrote: On Fri, Jan 27, 2012 at 21:13, Paweł Hajdan, Jr. wrote: Again - only if we don't get a consensus here. Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID binaries*? he was talking system wide considering the number set*id binaries in the tree, and their requirements (they tend to not be performance sensitive in the slightest), i don't have a problem with steering them in the PIE direction. ignoring /usr/bin/Xorg here of course, but that has a lot more problems that i doubt PIE will make much of a difference. -mike I've run nbench on two amd64 systems both running the same kernel vanilla-3.2.2. They only differed in that one uses the hardened toolchain and the other with a vanilla toolchain. nbench itself was compile pie on the former and no-pie on the later. I found negligible difference in performance. So at least on amd64, I don't think that performance is ever an issue. I have yet to look at x86. Below I give more info. Here's the result for the hardened system. # time -p /usr/bin/nbench BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 1172.2 : 30.06 : 9.87 STRING SORT : 533.16 : 238.23 : 36.87 BITFIELD: 5.0544e+08 : 86.70 : 18.11 FP EMULATION: 150.32 : 72.13 : 16.64 FOURIER : 30498 : 34.69 : 19.48 ASSIGNMENT : 35.543 : 135.25 : 35.08 IDEA:8060 : 123.28 : 36.60 HUFFMAN : 2549.8 : 70.71 : 22.58 NEURAL NET : 58.377 : 93.78 : 39.45 LU DECOMPOSITION: 1909.8 : 98.94 : 71.44 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 91.279 FLOATING-POINT INDEX: 68.525 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz 2673MHz L2 Cache: 8192 KB OS : Linux 3.2.2 C compiler : x86_64-pc-linux-gnu-gcc libc: MEMORY INDEX: 28.613 INTEGER INDEX : 19.197 FLOATING-POINT INDEX: 38.007 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. real 252.44 user 252.26 sys 0.01 Here's the result for the vanilla system # time -p /usr/bin/nbench BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 1179.4 : 30.25 : 9.93 STRING SORT : 540.12 : 241.34 : 37.36 BITFIELD: 5.0565e+08 : 86.74 : 18.12 FP EMULATION: 164.64 : 79.00 : 18.23 FOURIER : 30785 : 35.01 : 19.66 ASSIGNMENT : 35.677 : 135.76 : 35.21 IDEA: 7984.8 : 122.13 : 36.26 HUFFMAN :2686 : 74.48 : 23.78 NEURAL NET : 57.097 : 91.72 : 38.58 LU DECOMPOSITION: 1887.4 : 97.78 : 70.60 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 93.349 FLOATING-POINT INDEX: 67.966 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz 2673MHz L2 Cache: 8192 KB OS : Linux 3.2.2 C compiler : x86_64-pc-linux-gnu-gcc libc: MEMORY INDEX: 28.777 INTEGER INDEX : 19.879 FLOATING-POINT INDEX: 37.696 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. real 252.37 user 252.19 sys 0.01 The CPU is an 8 core i7 processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping: 5 microcode : 0xb cpu MHz
[gentoo-dev] Packages maintained by jokey need a co-maintainer
As talked with him, he won't be able to contribute a lot during the following months and then (Jokey: please remember to update your devaway message!!) would be nice to find co-maintainers for his packages: app-misc/bb app-misc/devtodo app-misc/ytree app-portage/maintainer-helper app-portage/portato app-shells/pdmenu dev-libs/libmba dev-perl/Filesys-Df dev-perl/IPC-Shareable dev-perl/ParaDNS dev-python/fuse-python dev-tcltk/tclx dev-util/kbuild dev-util/qdevelop dev-vcs/easygit dev-vcs/qbzr dev-vcs/qgit mail-mta/qpsmtpd media-gfx/duhdraw net-analyzer/pbnj net-im/climm net-im/openfire net-libs/gloox net-libs/gsoap net-misc/italc net-misc/nat-traverse net-misc/proxytunnel net-misc/x-lite sys-auth/pam_abl sys-fs/archfs www-apache/mod_vhost_ldap x11-drivers/xf86-input-virtualbox x11-drivers/xf86-video-virtualbox Thanks a lot signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by bass need a co-maintainer
As talked with him, he won't be able to contribute a lot during the following months and then would be nice to find co-maintainers for his packages if possible: app-admin/localepurge app-admin/recursos app-doc/ebookmerge app-misc/gnomecatalog dev-embedded/gnap-dev dev-embedded/gnap net-analyzer/midas-nms net-im/coccinella net-misc/htbinit net-nds/lat net-proxy/ufdbguard www-servers/cherokee Thanks a lot signature.asc Description: This is a digitally signed message part
[gentoo-dev] About obsolete/useless devaway messages
Was reviewing http://dev.gentoo.org/devaway/ and I have seen there are a lot of obsolete messages. Could you take a look and verify don't have an old .away file in your homes ;) ? Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About obsolete/useless devaway messages
On Sat, Jan 28, 2012 at 10:33 AM, Pacho Ramos pa...@gentoo.org wrote: Was reviewing http://dev.gentoo.org/devaway/ and I have seen there are a lot of obsolete messages. Could you take a look and verify don't have an old .away file in your homes ;) ? Might not hurt to generally consider the usefulness of .away messages in general. If you have one and it doesn't really convey anything useful, then it might as well not be there. If Gentoo is something you only sporadically work at, and you plan on being that way for years, and you carefully control your responsibilities accordingly, I'm not sure it is necessary to advertise the fact. If you normally have one level of availability, and it is going to be different for some reasonable period of time, then it is useful so that people know what is going on. Useful messages: I'm on vacation until Feb 8th - check with other team members in the meantime. Just started a new job - bear with me while I hand off responsibilities / get back on my feet in a few weeks. Less useful message: My job comes first - will not have much time for Gentoo for the next 30 years but I'll do what I can. If things are changing .away is a great tool. If things are going to impact your level of Gentoo contribution for a long time the best thing to do is to just change your level of involvement to suit. Probably not good to be the project lead for Chromium if you can only look for updates twice a year, and so on. If you maintain three packages and do the odd arch test and your teammates generally know that, no real need to advertise - just watch for bug emails and comment on anything that looks urgent... Rich
Re: [gentoo-dev] About obsolete/useless devaway messages
El sáb, 28-01-2012 a las 10:57 -0500, Rich Freeman escribió: On Sat, Jan 28, 2012 at 10:33 AM, Pacho Ramos pa...@gentoo.org wrote: Was reviewing http://dev.gentoo.org/devaway/ and I have seen there are a lot of obsolete messages. Could you take a look and verify don't have an old .away file in your homes ;) ? Might not hurt to generally consider the usefulness of .away messages in general. If you have one and it doesn't really convey anything useful, then it might as well not be there. If Gentoo is something you only sporadically work at, and you plan on being that way for years, and you carefully control your responsibilities accordingly, I'm not sure it is necessary to advertise the fact. If you normally have one level of availability, and it is going to be different for some reasonable period of time, then it is useful so that people know what is going on. Useful messages: I'm on vacation until Feb 8th - check with other team members in the meantime. Just started a new job - bear with me while I hand off responsibilities / get back on my feet in a few weeks. Less useful message: My job comes first - will not have much time for Gentoo for the next 30 years but I'll do what I can. If things are changing .away is a great tool. If things are going to impact your level of Gentoo contribution for a long time the best thing to do is to just change your level of involvement to suit. Probably not good to be the project lead for Chromium if you can only look for updates twice a year, and so on. If you maintain three packages and do the odd arch test and your teammates generally know that, no real need to advertise - just watch for bug emails and comment on anything that looks urgent... Rich I fully agree, personally, I think we should tend to only have messages informing about an important change in our involvement with Gentoo and the cases when we expect to not be able to commit anything for a few months but will return after that. Also looks important to me that, when going to contribute less on maintainership, people should try to find new maintainers or co-maintainers for their packages if possible (sending a mail to gentoo-dev for example) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by jokey need a co-maintainer
I'll look after app-misc/bb net-im/openfire -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] About obsolete/useless devaway messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/28/2012 03:57 PM, Rich Freeman wrote: On Sat, Jan 28, 2012 at 10:33 AM, Pacho Ramos pa...@gentoo.org wrote: Was reviewing http://dev.gentoo.org/devaway/ and I have seen there are a lot of obsolete messages. Could you take a look and verify don't have an old .away file in your homes ;) ? Might not hurt to generally consider the usefulness of .away messages in general. If you have one and it doesn't really convey anything useful, then it might as well not be there. If Gentoo is something you only sporadically work at, and you plan on being that way for years, and you carefully control your responsibilities accordingly, I'm not sure it is necessary to advertise the fact. If you normally have one level of availability, and it is going to be different for some reasonable period of time, then it is useful so that people know what is going on. Useful messages: I'm on vacation until Feb 8th - check with other team members in the meantime. Just started a new job - bear with me while I hand off responsibilities / get back on my feet in a few weeks. Less useful message: My job comes first - will not have much time for Gentoo for the next 30 years but I'll do what I can. If things are changing .away is a great tool. If things are going to impact your level of Gentoo contribution for a long time the best thing to do is to just change your level of involvement to suit. Probably not good to be the project lead for Chromium if you can only look for updates twice a year, and so on. If you maintain three packages and do the odd arch test and your teammates generally know that, no real need to advertise - just watch for bug emails and comment on anything that looks urgent... Rich This has been discussed in the paste and the result was this bug report[1]. But these people who have long standing devaways are not participating on our lists therefore these threads ends up in /dev/null. [1]: https://bugs.gentoo.org/show_bug.cgi?id=338829 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPJFKLAAoJEPqDWhW0r/LCZhsP+gOUH0oHUu/hstJF31Y9uzzQ 6av6w9e8+21tv41h/AuIdjfx0eb7w/6oXT+v6m7oVr0IcyfR+44VVQ146TAfcdCu cjwbmQEP+l/Omx3nic6DfG2RT9NTXsoC9nKSFQ9H3xqg3uKEZXRiwTgh3bnu/lYE tzXgfx7XBy8KBt6Tck+k5AIdJcM+aGvFsGWA0qqPYw9Wcu9CHYoaU7fkZFfVRBhh uNGhre/SYku0GQmi1C+fBnVIP4RJ+W9MY/4urJxgDbPOy2RV/naIH+jFYPBxPL8A 5tDKe9/YeGD/MwFUtc3PXFT66q6CPG3TP5cltyI6VpJKwLdCgln44486fIZQS8Qm KyhmxnVqX6sCeRFC14WeIZwif1w58BEJXHqUCfZrZbjeywCUa9wNgA8u7iLlFKaW ZlBlaoIEkjzowgEtjK5LaxpIPHrlhQGjawFwlAd94/hVDydElCLTamyEQqiEwIIJ UmPtKwYEFYMf9Xzzj9Yi3gMXhYncYFeO9xi1Y9YvjfIBD9kK9ljptZyvOxVPczGM OgnT4FVc/YSTHF7uhPXo7gN0hZiaDBAQaqGWx7DwdkyP7HE6ZNLa5NgTWW051TTc dJVkA0GfF+Ek70Omjl6NCpGA1N6rlK0JgK7qPeTouV1HjtyW9QrDLwdtpveyENNV aM657X0mCeXAqgsHfrPY =gbzw -END PGP SIGNATURE-
Re: [gentoo-dev] Packages maintained by bass need a co-maintainer
On Saturday 28 January 2012 08:29:44 Pacho Ramos wrote: As talked with him, he won't be able to contribute a lot during the following months and then would be nice to find co-maintainers for his packages if possible: app-admin/localepurge can probably just be dropped. packages should respect LINGUAS and only install the ones the user has listed. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages maintained by bass need a co-maintainer
El sáb, 28-01-2012 a las 15:57 -0500, Mike Frysinger escribió: On Saturday 28 January 2012 08:29:44 Pacho Ramos wrote: As talked with him, he won't be able to contribute a lot during the following months and then would be nice to find co-maintainers for his packages if possible: app-admin/localepurge can probably just be dropped. packages should respect LINGUAS and only install the ones the user has listed. -mike The problem is that I am sure it still cleans files for some packages that probably don't respect LINGUAS, not sure if maybe we could fix them in other way not too difficult :-/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last Rites: dev-db/pgaccess
# Aaron W. Swenson titanof...@gentoo.org (28 Jan 2012) # Masked for last rites. Package is no longer maintained upstream and # is not fully compatible with recent versions of PostgreSQL. Removal # in 60 days. # Alternatives: dev-db/pgadmin3 or dev-db/phppgadmin dev-db/pgaccess -- Mr. Aaron W. Swenson Gentoo Linux Developer Email: titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 pgpVWUzBFvMps.pgp Description: PGP signature
[gentoo-dev] [FYI] php-lib-r1.eclass going to die
Hi folks,
I thought I'd throw this out, so nobody is suprised when I start to put
qawarns in the eclass: I don't think php-lib-r1.eclass has any value now
that we have EAPI4. The only thing it basically does is
a) setting RDEPEND=dev-lang/php
and
b) provide a php_lib_r1_src_install that accepts as its parameters the
destination directory and the files to add. It then stores them
/usr/share/php/${PN}/$1.
Everything the eclass does can be done more cleanly and explictly inside
the ebuild. So if you planned to inherit php-lib-r1, please don't. Just
add the RDEPEND and use
src_install() {
insinto /usr/share/php/${PN}
doins -r your src/* (or wherever you stored your files)
dodoc README
}
as an example. I've also converted most of the ebuilds in our tree to do
this.
If your ebuild relied on php-lib-r1 to provide depend.php - shame on you
:p - depend.php will share the fate of php-lib-r1. But that's another mail.
Cheers, Matti
[gentoo-dev] Keeping older versions around
I've run into this three times today, so I'm a little grumpy. When you bump to a new ~arch version, please consider keeping at least one previous ~arch version around, so if people run into major issues they can at lease try the previously installed version to determine if it's your package at fault. Recent version bumps to two libraries have completely trashed a package I maintain, and the only option for my users is downgrading them to stable, which requires downgrading several other libraries. In both cases, the previous ~arch version, which worked fine, was removed. Personally I always try to keep two versions in ~arch and one stable, excepting security or other major bugs that render an older version useless. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Keeping older versions around
On Sat, Jan 28, 2012 at 10:33 PM, Ryan Hill dirtye...@gentoo.org wrote: When you bump to a new ~arch version, please consider keeping at least one previous ~arch version around, so if people run into major issues they can at lease try the previously installed version to determine if it's your package at fault. I mostly run stable and when I have to pull in the odd ~arch package it seems like for some of them I'm re-keywording them every third day. The stable version doesn't change in 9 months, and the unstable one changes 47 times, with old versions being dropped instantly so I have no choice but to move along or risk having a security bug that won't get GLSA'ed. Also, if we don't keep unstable versions around there isn't any way to get them stabilized, making stable more stale. If a particular unstable version is particularly buggy or otherwise not something upstream supports then it makes sense to move on. However, everything has some level of bugs (if you look hard enough) and if they're pretty minor then we should be asking ourselves if it is better or worse than the current stable, and if not then it should be left around if possible as a stable candidate. Obviously use common sense. If we can afford our users the luxury of upgrading at their leisure we should do so. Rich
Re: [gentoo-dev] Dropping localepurge
120128 Mike Frysinger wrote: On Saturday 28 January 2012 08:29:44 Pacho Ramos wrote: As talked with him, he won't be able to contribute a lot during the following months and then would be nice to find co-maintainers for his packages if possible: app-admin/localepurge can probably just be dropped. packages should respect LINGUAS and only install the ones the user has listed. 'should do' 'does' (smile). Below is the output from 'localepurge' after this week's system update. Please don't drop it till 'should' does = 'does'. root:502 ~ localepurge * localepurge: processing locale files in /usr/share/locale ... removed `/usr/share/locale/af/LC_MESSAGES/evince.mo' removed `/usr/share/locale/af/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/af/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/ang/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/ar/LC_MESSAGES/evince.mo' removed `/usr/share/locale/ar/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/ar/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/as/LC_MESSAGES/evince.mo' removed `/usr/share/locale/as/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/as/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/az/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/az/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/be/LC_MESSAGES/evince.mo' removed `/usr/share/locale/be/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bg/LC_MESSAGES/evince.mo' removed `/usr/share/locale/bg/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bg/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/bg/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/bg/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/bg/LC_MESSAGES/sane-backends.mo' removed `/usr/share/locale/bn/LC_MESSAGES/evince.mo' removed `/usr/share/locale/bn/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bn/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/bn_IN/LC_MESSAGES/evince.mo' removed `/usr/share/locale/bn_IN/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bn_IN/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/br/LC_MESSAGES/evince.mo' removed `/usr/share/locale/br/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bs/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/bs/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/ca/LC_MESSAGES/evince.mo' removed `/usr/share/locale/ca/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/ca/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/ca/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/ca/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/cs/LC_MESSAGES/evince.mo' removed `/usr/share/locale/cs/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/cs/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/cs/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/cs/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/cs/LC_MESSAGES/sane-backends.mo' removed `/usr/share/locale/cy/LC_MESSAGES/evince.mo' removed `/usr/share/locale/cy/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/cy/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/da/LC_MESSAGES/evince.mo' removed `/usr/share/locale/da/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/da/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/da/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/da/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/da/LC_MESSAGES/sane-backends.mo' removed `/usr/share/locale/de/LC_MESSAGES/evince.mo' removed `/usr/share/locale/de/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/de/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/de/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/de/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/de/LC_MESSAGES/sane-backends.mo' removed `/usr/share/locale/el/LC_MESSAGES/evince.mo' removed `/usr/share/locale/el/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/el/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/el/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/el/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/en_CA/LC_MESSAGES/evince.mo' removed `/usr/share/locale/en_CA/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/en_CA/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/evince.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/rekonq.mo' removed `/usr/share/locale/en_GB/LC_MESSAGES/sane-backends.mo' removed `/usr/share/locale/eo/LC_MESSAGES/evince.mo' removed `/usr/share/locale/eo/LC_MESSAGES/gdk-pixbuf.mo' removed `/usr/share/locale/eo/LC_MESSAGES/gnome-doc-utils.mo' removed `/usr/share/locale/eo/LC_MESSAGES/xkeyboard-config.mo' removed `/usr/share/locale/eo/LC_MESSAGES/rekonq.mo' removed
