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

Re: [arch-dev-public] [signoff] filesystem 2010.12-1
by Thomas Bächler 14 Dec '10

14 Dec '10

Am 14.12.2010 08:54, schrieb Andrea Scarpino: > On Tuesday 14 December 2010 08:21:41 Pierre Schmitz wrote: >> Morning, >> >> this is a minor update to the filesystem package and I hope we can >> finally move it to core. Only change is: >> >> * don't check if profiles are executable; FS#22036 >> >> Please sign off, > signoff x86_64 > Signoff.

1 0

[arch-dev-public] [signoff] ca-certificates 20090814+nmu2-1 and run-parts 3.4.1-1
by Pierre Schmitz 14 Dec '10

14 Dec '10

Hi, these are upstream updates and a fix of the install script when installing into a new environment. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

5 9

Re: [arch-dev-public] [arch-general] What about gallium on r600?
by Andreas Radke 14 Dec '10

14 Dec '10

Am Tue, 14 Dec 2010 00:32:08 +0100 schrieb Sven-Hendrik Haase <sh(a)lutzhaase.com>: > On 14.12.2010 00:15, Sergej Pupykin wrote: > > Hi, > > > > it works not worse than classic mesa on my RV620. > > > > I add --enable-gallium-r600 and modify package_ati-dri-git() in > > mesa-git PKGBUILD as it is already done for r300 > > > > (make -C ${srcdir}/build/src/gallium/targets/dri-r600 > > DESTDIR="${pkgdir}" install) > > > > I test current (20101213) git snapshot. > > > > May be put it into testing and enable on next release? > > > Upstream does not currently advise using this driver. Upstream usually > is knowledgeable about this so we should hang on for some more time. > Unless, of course, some recent changes have been merged. Did you ask > in #radeon? If not, can you do that and inform us about the current > state of the driver and whether using gallium for r600 is recommended > yet? > > -- Sven-Hendrik > I'll probably follow again the Fedora way. They switched in FC Rawhide to Mesa 7.10 snapshots and enabled r600 gallium there. So expect this when we will push new Mesa 7.10 to our repos. Right now we are in a bad situation: With new libdrm 2.4.23 released Mesa 7.9 won't build anymore. Updating to Mesa 7.10 branch is possible but new Xorg 1.10 release candidate will break proprietary NVidia driver. I'll delay these updates for a some time if there's no other solution. -Andy

1 0

[arch-dev-public] [signoff] links-2.3pre1-1
by Eric Bélanger 14 Dec '10

14 Dec '10

Hi, links-2.3pre1-1 is in testing. Changes: - Upstream update - Added xlinks binary with X and frame buffer support along with .desktop file and icons - Added calibration documentation - Removed old patches and ChangeLog Please test and signoff. Eric

2 2

[arch-dev-public] [signoff] lvm2/device-mapper 2.02.78-1
by Eric Bélanger 14 Dec '10

14 Dec '10

Hi, lvm2/device-mapper 2.02.78-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Version 2.02.78 - 6th December 2010 =================================== Abort if segment tag allocation fails in pool format _add_stripe_seg. Abort in _mirrored_transient_status if referenced log/image LV is not active. Add backtraces for dev_set() and dev_close_immediate() errors in set_lv(). Log any unlink() error in clvmd remove_lockfile(). Log any pipe write() or close() errors in clvmd child_init_signal(). Detect if orphan vginfo was lost from cache before _lvmcache_update_vgname(). Do a full rescan if some device is missing in lvm1 format read_pvs_in_vg. Add missing check that dm_pool_create succeeded in write_config_node(). Use dm_snprintf in clvmd-command.c to ensure an overlong buffer is truncated. Don't write to buffer if its reallocation failed in clvmd do_command(). Switch from float to fixed point percentage handling. Avoid misleading missing PV warnings in vgextend --restoremissing. Fix memory leak when VG allocation policy in metadata is invalid. Ignore unrecognised allocation policy found in metadata instead of aborting. Factor out tag printing into _out_tags and avoid leaking string buffer. Remove some unused variables & assignments. Add missing vg_release calls in _vg_read_by_vgid. Fix debug logging of derived flag LCK_CACHE in clvmd. Fix test for no system_dir in _init_backup(). Disallow lvconvert ops that both allocate & free supplied PEs in a single cmd. Fix liblvm seg_size to give bytes not sectors. Add functions to look up LV/PV by name/uuid to liblvm. Free cmd_context if fallback to LVM1 fails in lvm2_main(). Free device name buffer in dmsetup parse_loop_device_name() error paths. Close format lib if init_format_fn fails in _init_formats(). Don't leave /proc/mounts open after dmeventd snapshot event processing. Fix out-of-scope arg_vgnames use in process_each_lv(). Remove incorrect dm_task_destroy(NULL) from _node_clear_table() error path. Add missing closedir in _rm_blks after removing stray LVM1 VG files. Suppress 'No PV label' message when removing several PVs without mdas. Fix default /etc/lvm permissions to be 0755. (2.02.66) Version 1.02.59 - 6th December 2010 =================================== Add backtraces to _process_mapper_dir and _create_and_load_v4 error paths. Remove superfluous checks for NULL before calling dm_free.

2 1

[arch-dev-public] [signoff] procps-3.2.8-3
by Eric Bélanger 13 Dec '10

13 Dec '10

Hi, procps-3.2.8-3 is in testing. Added patch to fix "Unknown HZ value!" on some machines. Please test and signoff. Eric

3 2

[arch-dev-public] [signoff] pkg-config 0.25-3
by Stéphane Gaudreault 13 Dec '10

13 Dec '10

* Rebuild of old package * Use system popt and glib Please signoff both. Thanks Stéphane

3 3

[arch-dev-public] tcp_wrappers- does anyone actually use it?
by Dan McGee 13 Dec '10

13 Dec '10

Guys, For the umpteenth time today I stared at ssh wondering why it wasn't accepting incoming connections until I remembered about tcp_wrappers junk, and put the standard "sshd : ALL : allow" line in hosts.allow. Does anyone use this for anything useful at all? 1. The package is now at version 7.6-12 (clearly it is getting a lot of upstream attention) 2. We have 11 patches applied to the package 3. It is inferior to iptables-based filtering 4. It is not very transparent Discussion welcome, but I am raising a vote to remove this dependency from packages currently using it (hopefully this is possible for all 21 of them, http://www.archlinux.org/packages/core/x86_64/tcp_wrappers/) and eventually remove it from core and the repositories. -Dan

6 9

[arch-dev-public] [signoff] bash 4.1.009-3
by Pierre Schmitz 13 Dec '10

13 Dec '10

Hi, the main difference between this and bash from [core] is that /etc/profile.bash has been removed as it is no longer sourced by /etc/profile (see filesystem package). This package was in testing for 2 weeks and I am not aware of any real problem here. This is now similar to Debian/Ubuntu and Fedora. The whole thing is a little weird though as bash does not source /etc/bash.bashrc on its own even if configured to do so. We have to do this in /etc/profile. Please sign off, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

3 2

[arch-dev-public] For how long should we support a smooth update?
by Pierre Schmitz 13 Dec '10

13 Dec '10

Hi all, because our development is always moving forward we sometimes need to break compatibility with old installations of Arch. For example switching to xz as compression for all packages of course requires a version of libarchive which can handle it. Allan's request for bumping glibc's kernel dependency is similar (but also a special case). Or imagine some special treatment in install files when updating from old package versions. We have also had some repository changes which made updates from very old setups difficult or broke old install isos. I would suggest to decide on a maximum age within which an update should be supported. What about one year? That would mean updating a system which hasn't been updated for more than one year or installing from an ISO image older than one year might not work. The benefit of such a defined "rule of thumb" would be that code and packages can be simplified and we are not hold back by keeping very old backwards compatibility. A side effect of this rule would be that keeping your system up to date is a requirement for using Arch. This is no big deal though and should affect virtually nobody. What do you think? Would you agree in general? Is a year too short or too long? Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

4 4