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

[arch-dev-public] Upcoming archboot release and archboot iso/img files
by Tobias Powalowski 16 Oct '08

16 Oct '08

Hi all, after changing a lot of stuff in old archboot, a new release will come up next days. I already created an USB image and an ISO file. I would like to share those files with the community. They ship both architectures core repositories, though the size increased to approx. 445 MB. Included is a slightly modified setup, that fits better than the standard setup for archboot usage. I don't know if any plans for a new archiso is on the way and also i don't know how official you guys want to call them. Can i share them in /iso/2008.10 on ftp setver? Should the name change of the files? Archlinux-allinone-2008.10.iso/img is it now. You are also welcome to test those files ;) http://dev.archlinux.org/~tpowa/2008.10/ Thanks for your input on this. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] Repository Maintenance 16-10-2008 06:00
by repomaint＠archlinux.org 16 Oct '08

16 Oct '08

Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup qtiplot-0.9.7-1-i686.pkg.tar.gz tcl-8.5.4-1-i686.pkg.tar.gz tk-8.5.4-2-i686.pkg.tar.gz Scan complete for extra (x86_64) at /home/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup qtiplot-0.9.7-1-x86_64.pkg.tar.gz Scan complete for testing (i686) at /home/ftp/testing/os/i686/ The following files are in the repo but not the db They will be moved to /home/package-cleanup qtiplot-0.9.7.2-1-i686.pkg.tar.gz Scan complete for testing (x86_64) at /home/ftp/testing/os/x86_64/ The following files are in the repo but not the db They will be moved to /home/package-cleanup qtiplot-0.9.7.2-1-x86_64.pkg.tar.gz

1 0

Re: [arch-dev-public] boost rebuild status
by K. Piche 16 Oct '08

16 Oct '08

On Sat, 2008-10-11 at 19:55 +1000, Allan McRae wrote: > Allan McRae wrote: > > Allan McRae wrote: > >> Kevin: have you had a look at libavg? > >> > > > > I saw in an earlier email Kevin pointed out that the latest libavg > > needed graphicsmagick which is in [community] at the moment. I will > > add it to [extra] and stick the rebuilt libavg in [testing] (provided > > that no-one objects by the time I rebuild it....) > > > > Or, looking into this further, nothing in [extra] or [community] depends > on libavg so we could just dump it to [unsupported]. > > Opinions? I like this idea unless libavg is in extra for some good reason. Also I tested wesnoth and it worked fine. I think we're ready to move boost myself. Where's that moving script again? Thanks for looking at this. Just recovered from a drive "almost-failure". Got the heads up from smartmon, did a backup and moved to a new drive. k > Allan > > > -- K. Piche <kpiche(a)rogers.com>

3 3

[arch-dev-public] [Installer] Reserved-Blocks-Percentage
by Jud 16 Oct '08

16 Oct '08

Hi all, Now that the Installer is of interest again, I wanted to ask if this idea could make a better sane default for the Installer's /etc/mke2fs.conf - Meaning when you create and format ext2/3/4 (any others?) partitions. -m [reserved-blocks-percentage] "Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%." Now it seems this reserved space is unavailable to users and now that Hard Drives are massive, this 5% is alot of space. Would the option -m1 or even -m0 be a better sane default? or maybe even user defined? Thanks.

3 3

[arch-dev-public] Repository Maintenance 16-10-2008 00:00
by repomaint＠archlinux.org 16 Oct '08

16 Oct '08

Scan complete for core (i686) at /home/ftp/core/os/i686/ The following files are out of date They will be moved to /home/package-cleanup dnsutils-9.5.0-4-i686.pkg.tar.gz Scan complete for core (x86_64) at /home/ftp/core/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup dnsutils-9.5.0-2-x86_64.pkg.tar.gz Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup bind-9.5.0-4-i686.pkg.tar.gz boost-1.34.1-2-i686.pkg.tar.gz deluge-0.9.09-2-i686.pkg.tar.gz gnash-common-0.8.3-3-i686.pkg.tar.gz miro-1.2.4-1-i686.pkg.tar.gz python-vpython-3.2.9-3.pkg.tar.gz smc-1.4-1-i686.pkg.tar.gz Scan complete for extra (x86_64) at /home/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup bind-9.5.0-2-x86_64.pkg.tar.gz boost-1.34.1-2-x86_64.pkg.tar.gz deluge-0.9.09-2-x86_64.pkg.tar.gz gnash-common-0.8.3-3-x86_64.pkg.tar.gz miro-1.2.4-1-x86_64.pkg.tar.gz python-vpython-3.2.9-3.pkg.tar.gz smc-1.4-1-x86_64.pkg.tar.gz Scan complete for testing (i686) at /home/ftp/testing/os/i686/ The following files are in the repo but not the db They will be moved to /home/package-cleanup bind-9.5.0.P2-1-i686.pkg.tar.gz boost-1.36.0-2-i686.pkg.tar.gz deluge-1.0.2-1-i686.pkg.tar.gz dnsutils-9.5.0.P2-1-i686.pkg.tar.gz gnash-common-0.8.3-4-i686.pkg.tar.gz miro-1.2.7-2-i686.pkg.tar.gz python-vpython-3.2.9-4-i686.pkg.tar.gz smc-1.5-2-i686.pkg.tar.gz Scan complete for testing (x86_64) at /home/ftp/testing/os/x86_64/ The following files are in the repo but not the db They will be moved to /home/package-cleanup bind-9.5.0.P2-1-x86_64.pkg.tar.gz boost-1.36.0-2-x86_64.pkg.tar.gz deluge-1.0.0-1-x86_64.pkg.tar.gz deluge-1.0.2-1-x86_64.pkg.tar.gz dnsutils-9.5.0.P2-1-x86_64.pkg.tar.gz gnash-common-0.8.3-4-x86_64.pkg.tar.gz miro-1.2.7-2-x86_64.pkg.tar.gz python-vpython-3.2.9-4-x86_64.pkg.tar.gz smc-1.5-2-x86_64.pkg.tar.gz

1 0

[arch-dev-public] [signoff] dnsutils and bind 9.5.0.P2-1
by Eric Belanger 16 Oct '08

16 Oct '08

Hi, I guess Kevin forgot to start the signoff thread but: core/dnsutils 9.5.0.P2-1 and extra/bind 9.5.0.P2-1 are now in testing for both arches. Please signoff. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5 6

[arch-dev-public] squirrelmail duplicate
by Xavier 16 Oct '08

16 Oct '08

squirrelmail exists in both extra (1.5.2cvs-7) and community (1.4.16-2). Is this normal? If both versions are needed, maybe the first package should be renamed to squirrelmail-cvs or similar.

3 2

[arch-dev-public] Repository Maintenance 15-10-2008 18:00
by repomaint＠archlinux.org 16 Oct '08

16 Oct '08

Scan complete for core (i686) at /home/ftp/core/os/i686/ The following files are out of date They will be moved to /home/package-cleanup popt-1.10.6-3-i686.pkg.tar.gz Scan complete for core (x86_64) at /home/ftp/core/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup popt-1.10.6-3-x86_64.pkg.tar.gz Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup epdfview-0.1.6-8-i686.pkg.tar.gz Scan complete for extra (x86_64) at /home/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup epdfview-0.1.6-8-x86_64.pkg.tar.gz Scan complete for testing (i686) at /home/ftp/testing/os/i686/ The following files are out of date They will be moved to /home/package-cleanup orca-2.24.0-1-i686.pkg.tar.gz The following files are in the repo but not the db They will be moved to /home/package-cleanup popt-1.14-1-i686.pkg.tar.gz Scan complete for testing (x86_64) at /home/ftp/testing/os/x86_64/ The following files are in the repo but not the db They will be moved to /home/package-cleanup popt-1.14-1-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Request for new extra package: libv4l / Roadmap to better Webcam support
by Thomas Bächler 15 Oct '08

15 Oct '08

It all starts here: http://bugs.archlinux.org/task/11736 Many webcam drivers are now available for Linux in the 2.6.27 kernel. The current basis is video4linux 2 (v4l2), but there are problems: 1) Many applications only support v4l1, while many v4l2 drivers have missing or incomplete v4l1 emulations 2) Many webcams only support weird image formats requiring conversion which is not done in the kernel, so they won't work in either v4l1 or v4l2 programs. The solution is libv4l. See http://hansdegoede.livejournal.com/3636.html and http://people.atrpms.net/~hdegoede/libv4l-0.5.1.tar.gz. libv4l provides the following features: 1) Using libv4l1, all v4l2 devices are supported by old v4l1 applications. All that has to be done is replace open, close, mmap and ioctl calls to the video device by v4l1_open, v4l1_close, v4l1_mmap and v4l1_ioctl respectively. 2) libv4l2 provides a similar wrapper for v4l2 applications. 3) Both of these libraries use libv4lconvert to convert all known image formats to BGR24 or YUV420 if necessary, so that applications will be able to use them. 4) There are two LD_PRELOAD wrappers, v4l1compat and v4l2convert. v4l1compat can be preloaded to allow (binary) v4l1 applications to use all v4l2 devices and use the conversion feature of libv4lconvert. v4l2convert can be preloaded to allow (binary) v4l2 applications to use the conversion features as well. I suggest the following roadmap: 1) Add libv4l 0.5.1 to extra (I can do that). 2) Provide a HOWTO on the wiki on how to use the LD_PRELOAD wrappers to gain support for your camera (Should be done by a user who has done stuff on the wiki before). 3) Adjust applications to use libv4l directly. http://linuxtv.org/v4lwiki/index.php/Libv4l_Progress is part of a cross-distro effort (although all the work so far has been done by Fedora apparently) to fix applications. Right now, patches for gstreamer, vlc and xawtv exist, ptlib already includes support for libv4l when it is installed at compile-time. Apply those patches and in the long run adjust more applications to use libv4l, then submit those patches upstream. Just from my personal experience: I own a camera that is supported by the gspca_ov519 driver included in 2.6.27. However, this camera has only support for jpeg, and thus won't work in any v4l(2) application. By preloading v4l2convert.so, this camera works like a charm in skype. All this should result in support for ALL webcams in ALL v4l(2) applications. Are there any objections against implementing this or any additions?

4 3

[arch-dev-public] How to integrate Sheriff and Arch?
by Hugo Doria 15 Oct '08

15 Oct '08

A few days ago I showed Sheriff [1], . IMHO it is good tool to help us improve Arch's security. What is missing now is a way to integrate Sheriff with Arch and mark a vulnerability as fixed. It would be great if we could add a field in PKGBUILD to indicate that it fixed a vulnerability. It could be a comment (as the 'Contributor' tag work) or even a new variable (fix=('vulnx' 'vulny')). All this, of course, leads to some other things as commitment to correct flaws or the creation of a security team. I do not know. I am open to suggestions and would really like to know what you guys think about it and if you think it is worth. [1] http://dev.archlinux.org/~hugo/sheriff/ -- Hugo

2 1