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

[arch-dev-public] [signoff] glibc-2.12.1-3
by Allan McRae 25 Oct '10

25 Oct '10

* Pull new git 2.12 branch snapshot * Patch two security exploits: http://www.exploit-db.com/exploits/15274/ (fedora patch) http://www.exploit-db.com/exploits/15304/ (upstream patch) * fix IPTOS_CLASS definition (FS#21159) Signoff both, Allan

5 4

[arch-dev-public] xz 5.0.0 rebuild
by Pierre Schmitz 25 Oct '10

25 Oct '10

Morning, just to let you know: I'll prepare a xz rebuild in staging. It's only a few pacakges. I'll report back once the core packages are done; if you'd like to help let me know. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

1 1

[arch-dev-public] cleaning up xorg packages, adding missing packages
by Jan de Groot 24 Oct '10

24 Oct '10

Following my message about splitting the xorg-*-utils/apps packages in single packages for every app, I took a look at the official Xorg release set. With the release of Xorg 7.4 and 7.5, a lot of apps and drivers were removed. Some of these apps are still required but are no longer required, so I'll have a look at what's really deprecated and what is just removed without reason (xinit is one of them, I can't tell all our users to use a display manager instead of startx). Besides the applications, some changes have been made to the driver sets. The difflist between xorg and our repositories are as follows: -elographics -fpit -hyperpen -mutouch -penmount (-wacom) +ast +newport (-nouveau) -radeonhd +tga (-unichrome) +wsfb +xgi +xgixp I would suggest to remove the drivers with minus signs. They're no longer maintained and we already applied patches to make them build with current xorg-server. Upstream git contains patches that tell you to not use the driver anymore and abort compilation, so if anything breaks, we're on our own. The modules with a + should be added when they are valid for i686 or x86_64. This means that ast, xgi and xgixp get added to the repository. The modules with () are unofficial modules. All of those have active development, so I suggest keeping them. They are not allowed in the xorg or xorg-{input,video}-drivers groups however.

1 0

[arch-dev-public] [signoff] man-pages 3.29-1
by Andreas Radke 23 Oct '10

23 Oct '10

upstream update. please signoff. -Andy ==================== Changes in man-pages-3.29 ==================== Released: 2010-10-19, Detroit Contributors ------------ The following people contributed notes, ideas, or patches that have been incorporated in changes in this release: Balazs Scheidler <bazsi(a)balabit.hu> David Prevot <davidp(a)altern.org> Denis Barbier <bouzim(a)gmail.com> Guillem Jover <guillem(a)hadrons.org> Ivana Varekova <varekova(a)redhat.com> Lennart Poettering <mzxreary(a)0pointer.de> Michael Kerrisk <mtk.manpages(a)gmail.com> Sam Varshavchik <mrsam(a)courier-mta.com> Simon Paillard <simon.paillard(a)resel.enst-bretagne.fr> Stephan Mueller <stephan.mueller(a)atsec.com> Thomas Jarosch <thomas.jarosch(a)intra2net.com> Yuri Kozlov <yuray(a)komyakino.ru> Apologies if I missed anyone! New and rewritten pages ----------------------- subpage_prot.2 Michael Kerrisk New page documenting the PowerPC-specific subpage_prot(2) aio_init.3 Michael Kerrisk New page documenting aio_init(3) Newly documented interfaces in existing pages --------------------------------------------- posix_fadvise.2 Michael Kerrisk Document the architecture-specific arm_fadvise64_64() system call This ARM-specific system call fixes the argument ordering for that architecture. Since Linux 2.6.14. sync_file_range.2 Michael Kerrisk Document the architecture-specific sync_file_range2() system call As described in commit edd5cd4a9424f22b0fa08bef5e299d41befd5622, the sync_file_range() argument order is broken for some architectures (PowerPC, ARM, tile). The remedy was a different system call using the right argument order on those architectures. psignal.3 Guillem Jover Document psiginfo() psiginfo() was added to glibc in version 2.10. Michael Kerrisk Add details, VERSIONS, and BUGS for psiginfo() ip.7 Balazs Scheidler Document IP_RECVORIGDSTADDR Document IP_TRANSPARENT Michael Kerrisk Document IP_FREEBIND Text based on input from Lennart Poettering and Balazs Scheidler. See https://bugzilla.kernel.org/show_bug.cgi?id=20082 New and changed links --------------------- arm_fadvise64_64.2 Michael Kerrisk New link to posix_fadvise.2 arm_sync_file_range.2, sync_file_range2.2 Michael Kerrisk New links to sync_file_range.2 arrm_fadvise.2 Michael Kerrisk New link to posix_fadvise.2 psiginfo.3 Guillem Jover New link to psignal.3 Global changes -------------- Many pages Michael Kerrisk global fix: s/Unix/UNIX/ The man pages were rather inconsistent in the use of "Unix" versus "UNIX". Let's go with the trademark usage. Various pages Michael Kerrisk Global fix: s/pseudo-terminal/pseudoterminal/ grantpt.3, ptsname.3, unlockpt.3, pts.4 Michael Kerrisk Global fix: s/pty/pseudoterminal/ recv.2, cmsg.3, unix.7 Michael Kerrisk global fix: s/UNIX socket/UNIX domain socket/ fmtmsg.3, gethostbyname.3, termios.3 Michael Kerrisk Global fix: s/Unixware/UnixWare/ Changes to individual pages --------------------------- inotify_rm_watch.2 Michael Kerrisk SYNOPSIS: fix type of 'wd' argument posix_fadvise.2 Michael Kerrisk Rewrite VERSIONS, noting that the system call is fadvise64() syscalls.2 Michael Kerrisk Add the PowerPC-specific subpage_prot() system call Add sync_file_range2() truncate.2 Michael Kerrisk Fix feature test macros aio_cancel.3 aio_error.3 aio_fsync.3 aio_read.3 aio_return.3 aio_suspend.3 aio_write.3 Michael Kerrisk SEE ALSO: Add lio_listio(3) gai_cancel.3 gai_error.3 gai_suspend.3 Michael Kerrisk Make these into links In the previous release, these files were accidentally made copies of getaddrinfo_a.3, instead of being made as link files. getifaddrs.3 Thomas Jarosch Prevent possible NULL pointer access in example program malloc.3 Michael Kerrisk Emphasize that malloc() and realloc() do not initialize allocated memory malloc_hook.3 Ivana Varekova Warn that these functions are deprecated strcpy.3 Michael Kerrisk Formatting fixes in strncpy() example implementation code ip.7 Michael Kerrisk Reword NOTES on Linux-specific options sigevent.7 Michael Kerrisk SEE ALSO: Add aio_read(3), aio_write(3), and lio_listio(3) unix.7 Michael Kerrisk Document the autobind feature Michael Kerrisk Fix description of abstract socket names As reported by Lennart Poettering: The part about "abstract" sockets is misleading as it suggests that the sockaddr returned by getsockname() would necessarily have the size of sizeof(struct sockaddr), which however is not the case: getsockname() returns exactly the sockaddr size that was passed in on bind(). In particular, two sockets that are bound to the same sockaddr but different sizes are completely independent. See https://bugzilla.kernel.org/show_bug.cgi?id=19812 Michael Kerrisk Fix description of "pathname" sockets As reported by Lennart Poettering: The part about "pathname" sockets suggests usage of sizeof(sa_family_t) + strlen(sun_path) + 1 for calculating the sockaddr size. Due to alignment/padding this is probably not a good idea. Instead, one should use offsetof(struct sockaddr_un, sun_path) + strlen() + 1 or something like that. See https://bugzilla.kernel.org/show_bug.cgi?id=19812

2 1

[arch-dev-public] New Distribute packages for [extra]
by Stéphane Gaudreault 22 Oct '10

22 Oct '10

Setuptools is a popular method to make Python modules easier to install. However, it seems that the Setuptools author has been very slow to integrate bugfixes and there was almost no developement for a long period of time. Due to non-maintenance of Setuptools, the project has forked. Distribute is a compatible fork intended to replace Setuptools as the standard method for working with Python module distributions. http://packages.python.org/distribute Distribute uses the same module name than Setuptools package and also use the same API. Setuptools users do not have to change their code to use Distribute instead of Setuptools. Recent versions of Distribute also supports Python 3. Most Linux distributions (Debian/Ubuntu, Fedora or Gentoo for example) have started shipping Distribute as their Setuptools module. After discussion with Allan, we decided to create the following Distribute packages : * python2-distribute : An alternative to Setuptools (drop-in replacement). This package will work with Python 2.x. http://aur.archlinux.org/packages.php?ID=42062 * python-distribute : The new "official" method to work with Python 3 modules. http://aur.archlinux.org/packages.php?ID=29188 Any objections to bring these packages to [extra] ? Best regards, Stéphane

3 3

[arch-dev-public] unbundling of xorg-*-apps/utils packages
by Jan de Groot 21 Oct '10

21 Oct '10

While I was updating some xorg-*-apps/utils packages a few minutes ago, I became a bit sick of it. Right now I have a list of outdated packages and an announcement mailinglist with updated tarballs released by the X.Org project. Finding the package associated with a released tarball is hell, and going trough the tarball versions for a flagged package is hell also. Therefore I would like to get rid of the xorg package bundles in the current shape. The easiest way to do this is by packaging each release into its own package, prefixed with xorg- in front of it (I don't like to have a package called "bitmap" for example). After that has been done, I will create new meta packages that are empty and depend on the packages that it contained before. That means that: - nothing gets broken or needs changes dependency-wise - updating xorg-*-apps/utils packages is a lot easier - dependencies can become a lot tighter: xterm for example, only needs luit from xorg-apps. The only packages that I will keep bundled are the xorg-fonts-* packages. They have a logical reason to be bundled, they don't change very often, and when they change, they change all at the same time, with the same reason for that change.

1 0

Re: [arch-dev-public] [arch-general] What's happening about libdjvu?
by Thomas Bächler 21 Oct '10

21 Oct '10

Am 21.10.2010 15:56, schrieb Auguste Pop: > I noticed this by compiling the package myself... When I sent this > mail, the web page was not updated and I saw an old list of files that > did not contain the .so file. I should have tried it first rather than > relying on a presumably delayed response on the web site. Sorry for > the false alarm. The update of the file list in the web interface might be delayed compared to the update of the package data itself. Dan, what can we do here? Should a version mismatch between $repo.db and $repo.files cause archweb to discard the file list, stating that "There is currently no file list available for this package", or should archweb print a warning "This is a file list from an older version of this package and might differ from the current package". Is anything like this already done in archweb? Should it? Right now, the delay between updating the package info and the file list can be (in the worst case) little over 24 hours. Given that our packages update and change frequently, I think we should avoid confusion like in Auguste's case.

2 1

[arch-dev-public] [signoff] xz 4.999.9beta_212_gacbc-1
by Pierre Schmitz 20 Oct '10

20 Oct '10

Hi, this is a new xz snapshot. Mostly minor changes, documentation and translation updates. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

4 3

[arch-dev-public] [signoff] coreutils-8.6-1
by Allan McRae 19 Oct '10

19 Oct '10

Upstream update. Details: http://lists.gnu.org/archive/html/coreutils/2010-10/msg00079.html Signoff both, Allan

3 3

[arch-dev-public] PostgreSQL 9.0.1 in [testing]
by Dan McGee 19 Oct '10

19 Oct '10

Community feedback welcome as well, but this is now in testing now that the Python rebuild has moved on. Please let me know (good and bad) how things are going with it so I can move it along to [extra]. Long-term, this probably needs some packaging love so pg_upgrade is actually usable on Arch, but that has not happened yet so you will require the old-school dump/reload with these. If anyone wants to undertake this project and get this into a state where it is possible to use pg_upgrade you are more than welcome to contribute patches and such for the build and whatever else we have to do. -Dan

1 0