Re: [arch-general] [arch-dev-public] [signoff] xfsprogs-3.1.2-1
Hi bump to latest version, xfsprogs-3.1.2 (6 May 2010) - Fix missing thread synchronization in xfs_repair duplicate extent tracking. - Fix handling of dynamic attribute fork roots in xfs_fsr. - Fix sb_bad_features2 manipulations when tweaking the lazy count flag. - Add support for building on Debian GNU/kFreeBSD, thanks to Petr Salinger. - Improvements to the mkfs.xfs manpage, thanks to Wengang Wang. - Various small blkid integration fixes in mkfs.xfs. - Fix build against stricter system headers. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] [signoff] gawk-3.1.8-1
Hi bump to latest version, Changes from 3.1.7 to 3.1.8 --- 1. The zero flag no longer applies to %c and %s; apparently the standards changed at some point. 2. Updated to latest infrastructure: Autoconf 2.65, Automake 1.11.1, libtool 2.2.6b, Bison 2.4.2. 3. Failure to open a socket is no longer a fatal error. 4. dfa.h and dfa.c are now more-or-less in sync with GNU grep, for the first time in many years. 5. Gawk no longer includes its own copy of libsigsegv but it will use it if installed on the build system. The --disable-libsigsegv configure option is now gone. 6. The ' flag (%'d) is now just ignored on systems that can't support it. 7. Lots of bug fixes, see the ChangeLog. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] troubles with resume after hibernate
Hello all. I have such trouble: when i use `pm-hibernate` my notebook(asus x58-l) can`t resume normally(you can see a lot of error messages in dmesg). What should i do to fix this? Some log\config files you can find at http://devio.us/~hired777 Thx
[arch-general] [signoff] gettext-0.18-1
Hi bump to latest version, Version 0.18 - May 2010 * Runtime behaviour: - On MacOS X and Windows systems, libintl.h now extends setlocale() and newlocale() so that their determination of the default locale considers the choice the user has made in the system control panels. - On MacOS X systems, the gettext()/dgettext()/... functions now respect the locale of the current thread, if a thread-specific locale has been set. * PO file format: There is a new field 'Language' in the header entry. It denotes the language code (plus optional country code) for the PO file. This field can be used by automated tools, such as spell checkers. It is expected to be more reliable than looking at the file name or at the 'Language-Team' field in the header entry. msgmerge, msgcat, msgen have a new option --lang that allows to specify this field. Additionally, msgmerge fills in this new field by looking at the 'Language-Team' field (if the --lang option is not given). * xgettext and PO file format: For messages with plural forms, programmers can inform the translators about the range of possible values of the numeric argument, like this: /* xgettext: range: 0..15 */ This information 'range: 0..15' is stored in the PO file as a flag attached to the message. Translators can produce better translations when they know that the numeric argument is small. * Colorized PO files: msgattrib, msgcomm, msgconv, msgen, msgfilter, msggrep, msginit, msgmerge, msgunfmt, msguniq, xgettext now have options --color and --style, like msgcat has since version 0.17. * msgmerge is up to 10 times faster when the PO and POT files are large. This speedup was contributed by Ralf Wildenhues. * msgcmp has a new option -N/--no-fuzzy-matching, like msgmerge has since version 0.12. * msgfilter now sets environment variables during the invocation of the filter, indicating the msgid and location of the messge being processed. * xgettext now can extract plural forms from Qt 4 programs. The recommended xgettext command-line options for this case are: --qt --keyword=tr:1,1t --keyword=tr:1,2c,2t --keyword=tr:1,1,2c,3t * xgettext --language=GCC-source now recognizes also the format strings used in the Fortran front-end of the GCC compiler, and marks them as 'gfc-internal-format'. * autopoint can now be used to update several PO directories all together. * PO mode changes: - PO files with plural entries are now correctly handled. - Editing a message with previous msgid (in comments) removes these comments. Contributed by Noritada Kobayashi. * The po/Makevars file has a new field MSGMERGE_OPTIONS, that can be used to adjust msgmerge's operation. * The use of the macro AM_GNU_GETTEXT without 'external' argument and the --intl option of the gettextize program are deprecated and will be removed in the next release. Instead of including the intl sources in your package, we suggest making the libintl library an (optional) prerequisite of your package. * Updated the meaning of 'gcc-internal-format' to match GCC 4.3. * Installation options: The configure options --without-cvs and --with-git can be used to specify whether 'autopoint' will use the 'cvs' program, or the 'git' program, or none at all. These options allow to trade dependencies against installed package size: If --without-cvs is specified and --with-git is not specified, 'autopoint' will not rely on 'cvs' or 'git', but will instead rely on a locally installed a 3 MB large archive. * Portability: - The msgfilter program now also works on native Woe32 platforms. - Compiled C# message catalogs now also work with 'mono' versions from 2009 or newer. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] troubles with resume after hibernate
Hi, firs of all run memtest86 (maybe mprime too) and check if ram is OK. It's not good, if udevd and sh die with segfault. Regards, Andrej On 05/14/2010 12:44 PM, Nick Stepa wrote: Hello all. I have such trouble: when i use `pm-hibernate` my notebook(asus x58-l) can`t resume normally(you can see a lot of error messages in dmesg). What should i do to fix this? Some log\config files you can find at http://devio.us/~hired777 Thx
Re: [arch-general] troubles with resume after hibernate
Nick Stepa hired...@gmail.com writes: Hello all. I have such trouble: when i use `pm-hibernate` my notebook(asus x58-l) can`t resume normally(you can see a lot of error messages in dmesg). What should i do to fix this? All you can do is wait for this bug to get fixed, I think: https://bugzilla.kernel.org/show_bug.cgi?id=13811 csm
Re: [arch-general] troubles with resume after hibernate
I run memtest - no errors On Fri, May 14, 2010 at 12:54:32PM +0200, Andrej Gelenberg wrote: Hi, firs of all run memtest86 (maybe mprime too) and check if ram is OK. It's not good, if udevd and sh die with segfault. Regards, Andrej On 05/14/2010 12:44 PM, Nick Stepa wrote: Hello all. I have such trouble: when i use `pm-hibernate` my notebook(asus x58-l) can`t resume normally(you can see a lot of error messages in dmesg). What should i do to fix this? Some log\config files you can find at http://devio.us/~hired777 Thx
Re: [arch-general] troubles with resume after hibernate
Thx. On Fri, May 14, 2010 at 01:06:40PM +0200, Csomay Mihaly wrote: Nick Stepa hired...@gmail.com writes: Hello all. I have such trouble: when i use `pm-hibernate` my notebook(asus x58-l) can`t resume normally(you can see a lot of error messages in dmesg). What should i do to fix this? All you can do is wait for this bug to get fixed, I think: https://bugzilla.kernel.org/show_bug.cgi?id=13811 csm
[arch-general] upgrade issues
Hi, I'm running Arch for quite a while on several machines. On one laptop there were no updates applied for quite a while. It was running kde4.0 and was using hda instead of sda as harddisk device. After applying all updates (download was roughly 1.8 GB) there are some issues (mainly with kde 4.4.3). All icons are missing until I switch icon-theme. After that there are still lots of icons missing, kde itself (eg. log-off), kde-apps (system-management), applications (k3b) and unrelated apps (opera). Also missing are the rating stars inside dolphin and gwenview (and probably others). I reinstalled all kde-meta packages wich pulled a view additional packages but didn't change anything. I tried to delete $HOME/.kde4 and also tried a newly created user. I looked at all(?) *.pacnew files. The only somehow related was kdm but couldn't find anything else. Any hints? Regards, Wolfgang
Re: [arch-general] [arch-commits] Commit in (libgcrypt/trunk/PKGBUILD libgpg-error/trunk/PKGBUILD)
# keep static lib for crypsetup ./configure --prefix=/usr There's no need to keep static lib now that cryptsetup is only dynamically linked.
Re: [arch-general] [signoff] gettext-0.18-1
On Friday May 14 2010 12:45:11 Tobias Powalowski wrote: please signoff both arches, signoff x86_64 -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux
Re: [arch-general] testing xorg packages may not be nvidia friendly
On 05/13/2010 04:54 PM, Ng Oon-Ee wrote: On Thu, 2010-05-13 at 17:47 -0500, Burlynn Corlew Jr wrote: On Thu, May 13, 2010 at 5:37 PM, Caleb Cushingxenoterrac...@gmail.comwrote: I tried installing testing on a box running nvidia drivers that I have at school. X didn't come up. I don't know why and didn't really investigate (as I was really testing to see if my box at home had an env issue seems it does). using nvidia-173xx-utils -- Caleb Cushing http://xenoterracide.blogspot.com Nvidia has not released a driver for xorg 1.8 in regards to a legacy driver. The only one working so far afaik is the 'nvidia' driver itself. This is one thing preventing 1.8 moving out of testing. As well as nvidia-beta. Though that's not in the repos. Just for completeness. AUR's nvidia-beta== 195.36.24 (same as nvidia in testing)
Re: [arch-general] testing xorg packages may not be nvidia friendly
On Fri, 2010-05-14 at 08:41 -0600, jwbirdsong wrote: On 05/13/2010 04:54 PM, Ng Oon-Ee wrote: On Thu, 2010-05-13 at 17:47 -0500, Burlynn Corlew Jr wrote: On Thu, May 13, 2010 at 5:37 PM, Caleb Cushingxenoterrac...@gmail.comwrote: I tried installing testing on a box running nvidia drivers that I have at school. X didn't come up. I don't know why and didn't really investigate (as I was really testing to see if my box at home had an env issue seems it does). using nvidia-173xx-utils -- Caleb Cushing http://xenoterracide.blogspot.com Nvidia has not released a driver for xorg 1.8 in regards to a legacy driver. The only one working so far afaik is the 'nvidia' driver itself. This is one thing preventing 1.8 moving out of testing. As well as nvidia-beta. Though that's not in the repos. Just for completeness. AUR's nvidia-beta== 195.36.24 (same as nvidia in testing) Ah. Last I checked repos was 196.36.15. Thanks.
[arch-general] final release candidate images for testing
new images are done. version: 2010.05.13 these are the images I want to rename to an official 2010.05 release after testing. http://build.archlinux.org/isos/Changelog http://build.archlinux.org/isos/ how should they be tested? for every file, that is: archlinux-2010.05.13-core-dual.iso archlinux-2010.05.13-core-i686.iso archlinux-2010.05.13-core-x86_64.iso archlinux-2010.05.13-netinstall-dual.iso archlinux-2010.05.13-netinstall-i686.iso archlinux-2010.05.13-netinstall-x86_64.iso I want to get a report from someone that an installation went fine. what kind of install doesn't really matter. manual, automatic, autoprepare, net/core whatever. this has been tested enough before, so any kind of install with each single image. On top of that, I want: A) confirmation for virtio_pci and virtio_blk on the install ISO's initramfs http://bugs.archlinux.org/task/19401?project=6 B) at least one installation performed from a usb stick, using any of the above images. So if you test: send a reply mentioning which file you tested, and optionally if you can confirm A/B thanks for you help, Dieter
Re: [arch-general] final release candidate images for testing
On Fri, May 14, 2010 at 11:16 PM, Dieter Plaetinck die...@plaetinck.be wrote: new images are done. version: 2010.05.13 these are the images I want to rename to an official 2010.05 release after testing. http://build.archlinux.org/isos/Changelog http://build.archlinux.org/isos/ how should they be tested? for every file, that is: archlinux-2010.05.13-core-dual.iso archlinux-2010.05.13-core-i686.iso archlinux-2010.05.13-core-x86_64.iso archlinux-2010.05.13-netinstall-dual.iso archlinux-2010.05.13-netinstall-i686.iso archlinux-2010.05.13-netinstall-x86_64.iso I want to get a report from someone that an installation went fine. what kind of install doesn't really matter. manual, automatic, autoprepare, net/core whatever. this has been tested enough before, so any kind of install with each single image. On top of that, I want: A) confirmation for virtio_pci and virtio_blk on the install ISO's initramfs http://bugs.archlinux.org/task/19401?project=6 B) at least one installation performed from a usb stick, using any of the above images. So if you test: send a reply mentioning which file you tested, and optionally if you can confirm A/B My current system is installed from previous archlinux-2010.04.05-core-i686 image, but no idea about the release candidate image. I am using an IBM T43P. thanks for you help, Dieter
Re: [arch-general] vim runtime woes
On Fri, May 14, 2010 at 1:07 AM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). Just in case people think this is a theoretical problem no one cares about ... solving this would give us tar.xz support that comes with latest version of gzip plugin : http://code.google.com/p/vim/source/browse/runtime/plugin/gzip.vim Never opened a package in vim ? it's awesome :p Anyway, this is just an example, we are also missing the latest greatest changes in many runtime files. Well not me, as I use vim-hg, and I would recommend other vim users to do the same. http://aur.archlinux.org/packages.php?ID=33422
Re: [arch-general] vim runtime woes
On Thu, May 13, 2010 at 6:07 PM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). I also agree that building from Mercurial might be our best bet here. The vim PKGBUILD is crazy complex as it is, and switching to Mercurial snapshots is probably a cleaner idea.
Re: [arch-general] vim runtime woes
On Fri, May 14, 2010 at 2:21 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Thu, May 13, 2010 at 6:07 PM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). I also agree that building from Mercurial might be our best bet here. The vim PKGBUILD is crazy complex as it is, and switching to Mercurial snapshots is probably a cleaner idea. And it looks like it DOES have tags, so v7-2-325 would give us vim 7.2 including up to patch 325. Simpler PKGBUILD? Check. More up to date runtime? Check. Less headache to maintain? Check
Re: [arch-general] vim runtime woes
I'll edit the PKGBUILD, then. Should I submit it as a bug again? On Fri, May 14, 2010 at 9:23 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Fri, May 14, 2010 at 2:21 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Thu, May 13, 2010 at 6:07 PM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). I also agree that building from Mercurial might be our best bet here. The vim PKGBUILD is crazy complex as it is, and switching to Mercurial snapshots is probably a cleaner idea. And it looks like it DOES have tags, so v7-2-325 would give us vim 7.2 including up to patch 325. Simpler PKGBUILD? Check. More up to date runtime? Check. Less headache to maintain? Check
Re: [arch-general] vim runtime woes
On 14/05/2010 21:09, Xavier Chantry wrote: Just in case people think this is a theoretical problem no one cares about ... solving this would give us tar.xz support that comes with latest version of gzip plugin : http://code.google.com/p/vim/source/browse/runtime/plugin/gzip.vim Never opened a package in vim ? it's awesome :p Long ago I've added these lines to gzip.vim (copied to ~/.vim/plugin/): ... autocmd BufReadPost,FileReadPost*.lzma call gzip#read(lzma -d) autocmd BufReadPost,FileReadPost*.xz call gzip#read(xz -d) ... autocmd BufWritePost,FileWritePost*.lzma call gzip#write(lzma) autocmd BufWritePost,FileWritePost*.xz call gzip#write(xz) ... autocmd FileAppendPre*.lzma call gzip#appre(lzma -d) autocmd FileAppendPre*.xz call gzip#appre(xz -d) ... autocmd FileAppendPost*.lzma call gzip#write(lzma) autocmd FileAppendPost*.xz call gzip#write(xz)
Re: [arch-general] vim runtime woes
On 05/14/10 at 09:34pm, Jan Steffens wrote: I'll edit the PKGBUILD, then. Should I submit it as a bug again? On Fri, May 14, 2010 at 9:23 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Fri, May 14, 2010 at 2:21 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Thu, May 13, 2010 at 6:07 PM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). I also agree that building from Mercurial might be our best bet here. The vim PKGBUILD is crazy complex as it is, and switching to Mercurial snapshots is probably a cleaner idea. And it looks like it DOES have tags, so v7-2-325 would give us vim 7.2 including up to patch 325. Simpler PKGBUILD? Check. More up to date runtime? Check. Less headache to maintain? Check You can just send me the updated PKGBUILD. Been meaning to start working on a transitional package anyway, but been crazy busy with work the last two weeks. --
Re: [arch-general] vim runtime woes
The tags only go up to v7-2-325. Newer versions are untagged. :( On Fri, May 14, 2010 at 9:23 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Fri, May 14, 2010 at 2:21 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Thu, May 13, 2010 at 6:07 PM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). I also agree that building from Mercurial might be our best bet here. The vim PKGBUILD is crazy complex as it is, and switching to Mercurial snapshots is probably a cleaner idea. And it looks like it DOES have tags, so v7-2-325 would give us vim 7.2 including up to patch 325. Simpler PKGBUILD? Check. More up to date runtime? Check. Less headache to maintain? Check
