- Arch-dev-public - lists.archlinux.org

[arch-dev-public] mesa versions
by Dan McGee 31 Mar '10

31 Mar '10

What happened here? Was the downgrade to pkgrel of 0.1 on purpose (it doesn't seem to be in SVN), or did these sneak in via someones staging dir unintentionally? http://www.archlinux.org/packages/extra/i686/mesa/ It is mesa and all of its split packages. -Dan

2 2

[arch-dev-public] GNOME 2.30 release plans
by Jan de Groot 31 Mar '10

31 Mar '10

Tarballs for GNOME 2.30.0 are due for March 29, 23:59 UTC. This means new tarballs will get uploaded to the FTP today and tomorrow. Final release is on Wednesday March 30. At this moment I'm trying to follow the flow of tarballs in gnome-unstable. Plans are to get this fully packaged in gnome-unstable. When all is done, it should move to extra, I don't want to get another duplication process through testing. As it looks now, GNOME 2.30.0 should be done in gnome-unstable on wednesday or thursday, we could have it in extra on saturday.

2 2

[arch-dev-public] [signoff] bison 2.4.2-1
by Eric Bélanger 31 Mar '10

31 Mar '10

Hi, bison 2.4.2-1 is in testing for testing/signoff. Could someone build the x86_64 package? Thanks. Changes: * Upstream update * Removed texinfo dependency in install scriptlet * Updated license * Added sh depends Upstream ChangeLog: * Changes in version 2.4.2 (2010-03-20): ** Some portability problems that resulted in failures and livelocks in the test suite on some versions of at least Solaris, AIX, HP-UX, RHEL4, and Tru64 have been addressed. As a result, fatal Bison errors should no longer cause M4 to report a broken pipe on the affected platforms. ** `%prec IDENTIFIER' requires IDENTIFIER to be defined separately. POSIX specifies that an error be reported for any identifier that does not appear on the LHS of a grammar rule and that is not defined by %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this error report for the case when an identifier appears only after a %prec directive. It is now restored. However, for backward compatibility with recent Bison releases, it is only a warning for now. In Bison 2.5 and later, it will return to being an error. ** Detection of GNU M4 1.4.6 or newer during configure is improved. ** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS, YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now avoided. ** %code is now a permanent feature. A traditional Yacc prologue directive is written in the form: %{CODE%} To provide a more flexible alternative, Bison 2.3b introduced the %code directive with the following forms for C/C++: %code {CODE} %code requires {CODE} %code provides {CODE} %code top {CODE} These forms are now considered permanent features of Bison. See the %code entries in the section "Bison Declaration Summary" in the Bison manual for a summary of their functionality. See the section "Prologue Alternatives" for a detailed discussion including the advantages of %code over the traditional Yacc prologue directive. Bison's Java feature as a whole including its current usage of %code is still considered experimental. ** YYFAIL is deprecated and will eventually be removed. YYFAIL has existed for many years as an undocumented feature of deterministic parsers in C generated by Bison. Previously, it was documented for Bison's experimental Java parsers. YYFAIL is no longer documented for Java parsers and is formally deprecated in both cases. Users are strongly encouraged to migrate to YYERROR, which is specified by POSIX. Like YYERROR, you can invoke YYFAIL from a semantic action in order to induce a syntax error. The most obvious difference from YYERROR is that YYFAIL will automatically invoke yyerror to report the syntax error so that you don't have to. However, there are several other subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from inherent flaws when %error-verbose or `#define YYERROR_VERBOSE' is used. For a more detailed discussion, see: http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but deterministic parsers in C will continue to implement it. However, because YYFAIL is already flawed, it seems futile to try to make new Bison features compatible with it. Thus, during parser generation, Bison 2.5 will produce a warning whenever it discovers YYFAIL in a rule action. In a later release, YYFAIL will be disabled for %error-verbose and `#define YYERROR_VERBOSE'. Eventually, YYFAIL will be removed altogether. There exists at least one case where Bison 2.5's YYFAIL warning will be a false positive. Some projects add phony uses of YYFAIL and other Bison-defined macros for the sole purpose of suppressing C preprocessor warnings (from GCC cpp's -Wunused-macros, for example). To avoid Bison's future warning, such YYFAIL uses can be moved to the epilogue (that is, after the second `%%') in the Bison input file. In this release (2.4.2), Bison already generates its own code to suppress C preprocessor warnings for YYFAIL, so projects can remove their own phony uses of YYFAIL if compatibility with Bison releases prior to 2.4.2 is not necessary. ** Internationalization. Fix a regression introduced in Bison 2.4: Under some circumstances, message translations were not installed although supported by the host system.

3 2

[arch-dev-public] [signoff] e2fsprogs 1.41.11-1
by Ronald van Haren 31 Mar '10

31 Mar '10

in testing for both architectures, please signoff. Ronald local changes: - remove libcom_err patch, it's now included upstream upstream changes: E2fsprogs 1.41.11 (March 14, 2010) E2fsck will no longer give a fatal error and abort if the physical device has been resized beyond 2**32 blocks. (Addresses Launchpad Bug: #521648) Debugfs has a bug fixed so that "logdump -b " now properly shows the allocation status of the block . (Addresses Debian Bug: #564084) E2fsck now prints a much more emphatic and hopefully scary message when a file system is detected as mounted while doing a read/write check of the filesystem. Hopefully this will dissuade users from thinking, "surely that message doesn't apply to *me*" :-( E2fsck -n will now always open the file system read-only. We now disallow certain combination of options which previously were manual exceptions; this is bad because it causes users to think they are smarter than they really are. So "-n -c", "-n -l", "-n -L", and "-n -D" are no longer supported. (Addresses Launchpad Bug: #537483) In e2fsprogs 1.41.10, mke2fs would ask for confirmation to proceed if it detected a badly aligned partition. Unfortunately, this broke some distribution installation scripts, so it now just prints the warning message and proceeds. (Addresses Red Hat Bug: #569021. Addresses Launchpad Bug: #530071) Mke2fs would take a long time to create very large journal files for ext4. This was caused by a bug in ext2fs_block_iterate2(), which is now fixed. E2fsck now understands the EOFBLOCKS_FL flag which will be used in 2.6.34 kernels to make e2fsck not complain about blocks deliberately fallocated() beyond an inode's i_size. E2fsprogs 1.41.10 introduced a regression (in commit b71e018) where e2fsck -fD can corrupt non-indexed directories when are exists one or more file names which alphabetically sort before ".". This can happen with ext2 filesystems or for small directories (take less than a lock) which contain filenames that begin with a space or some other punctuation mark. (Addresses Debian Bug: #573923, Addresses Launchpad Bug: #525114) Programmer's Notes Add new test, f_rehash_dir, which checks to make sure e2fsck -D works correctly. The libcom_err function now has support for Heimdal's com_right_r function(). (Addresses Sourceforge Bug: #2963865, Addresses Debian Bug: #558910)

3 2

[arch-dev-public] Arch Linux Planet restriction
by Andrea Scarpino 31 Mar '10

31 Mar '10

Hi everybody, I'd like to know what do you think about adding some restriction to our planet. First of all, blogs should have an Arch Linux category. In second, we could restrict access only to: DEVs, TUs, past DEVs, forum moderators, wiki and flyspray contributors, pacman/AUR/projects.archlinux contributors. What about Arch Linux based projects? Cheers -- Andrea

4 6

[arch-dev-public] [signoff] mlocate-0.22.4-1
by Allan McRae 30 Mar '10

30 Mar '10

Upstream update - translation additions/fixes only. Added coreutils dep for chown in install file. Signoff both, Allan

3 3

[arch-dev-public] [signoff] grep-2.6.2-1
by Allan McRae 30 Mar '10

30 Mar '10

Upstream bug fix release. Signoff both, Allan

3 2

[arch-dev-public] [signoff] tzdata 2010g-1
by Andreas Radke 30 Mar '10

30 Mar '10

New timezones for everone? No. But at least some countries made small changes. Please signoff latest upstream release. -Andy The files... ftp://elsie.nci.nih.gov/pub/tzcode2010f.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2010f.tar.gz ...are now available; these reflect the changes circulated last week on the time zone mailing list. For those seeking to avoid version thrash, I'm guessing that tzdata2010g will appear next week; the proposed changes (based on reports from Alexander Krivenyshev) should appear in two days. --ado The file... ftp://elsie.nci.nih.gov/pub/tzdata2010g.tar.gz ...is now available, reflecting the changes circulated last week on the time zone mailing list. Given news received since last Wednesday, I plan to circulate a few more changes (including Pakistan and Tunisia) this coming Wednesday, so data2010h may appear in a week. Those wanting to avoid version thrash may want to wait for data2010h. --ado

3 2

[arch-dev-public] [signoff] grep-2.6.1-1
by Allan McRae 29 Mar '10

29 Mar '10

Upstream bug fix release. Signoff both, Allan

5 5

[arch-dev-public] [signoff] glib2 2.24.0
by Jan de Groot 28 Mar '10

28 Mar '10

Please test very careful and signoff. This is a new major version that should be backwards compatible to older releases, but as always, things could break due to behaviour changes. This is required for GNOME 2.30, it has been sitting as beta/rc in the gnome-unstable repository for a while.

2 1