Re: [arch-dev-public] [signoff] kernel-2.6.36.3-2
Le janvier 24, 2011 01:38:44 PM, Tobias Powalowski a écrit : Upstream update. This package is NOT in testing (2.6.37 currently resides there), but at: http://dev.archlinux.org/~tpowa/kernel26/ fixed udev crash #22343 fixed ext3 default mount option #22544 please signoff for both arches. greetings tpowa Signoff x86_64 Stéphane
[arch-dev-public] Stepping down... for now
As much as I really hate to do it, I've decided that it's time to step down as an Arch Dev/TU. I love Arch, and will continue to contribute as time permits, but work has made it impossible as of late to keep up with my responsibilities to Arch. For those who don't know, I've been working as the CTO of a social media marketing and design company called Twelve31 Interactive for a while now, and I recently purchased a local bar as well. There just doesn't seem to be enough time in the day for everything and something has to give. At some point in time in the (hopefully not too far off) future, I fully intend to reapply and hope that you all will be willing to take me back. I will, however, stay on long enough to make sure that all of the more important packages I maintain find good homes.
Re: [arch-dev-public] Stepping down... for now
On 26 January 2011 00:32, Daniel J Griffiths (Ghost1227) ghost1...@archlinux.us wrote: As much as I really hate to do it, I've decided that it's time to step down as an Arch Dev/TU. I love Arch, and will continue to contribute as time permits, but work has made it impossible as of late to keep up with my responsibilities to Arch. For those who don't know, I've been working as the CTO of a social media marketing and design company called Twelve31 Interactive for a while now, and I recently purchased a local bar as well. There just doesn't seem to be enough time in the day for everything and something has to give. At some point in time in the (hopefully not too far off) future, I fully intend to reapply and hope that you all will be willing to take me back. I will, however, stay on long enough to make sure that all of the more important packages I maintain find good homes. :( But that's all awesome news. You're doing well and I wish you the best of luck!
Re: [arch-dev-public] Stepping down... for now
Il 25/01/2011 17:32, Daniel J Griffiths (Ghost1227) ha scritto: As much as I really hate to do it, I've decided that it's time to step down as an Arch Dev/TU. I love Arch, and will continue to contribute as time permits, but work has made it impossible as of late to keep up with my responsibilities to Arch. For those who don't know, I've been working as the CTO of a social media marketing and design company called Twelve31 Interactive for a while now, and I recently purchased a local bar as well. There just doesn't seem to be enough time in the day for everything and something has to give. At some point in time in the (hopefully not too far off) future, I fully intend to reapply and hope that you all will be willing to take me back. I will, however, stay on long enough to make sure that all of the more important packages I maintain find good homes. Sad to see you go. Good luck for everything you are doing. I wish you the best of luck. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
[arch-dev-public] new grub2 package: advice needed
Hi guys, I'm preparing a new set of grub2 packages together with a user (skodabenz). We've had a rather long discussion about if we should rename 's/grub/grub2' in the package. In theory this should allow to install both grub and grub2 (chainloading, but nobody will do that anyway I suppose), but it will also make things more clear as they no longer share similar directories. - This would rename however all utilities to have grub2 in the name instead of grub. - the config directory will move to /boot/grub2 Some consequences: - people can't find their utilities anymore (searching is difficult for some) - grub2 may replace grub and switching names again would be weird - previously used config file is not loaded and people get greeted by the grub command line (which is quite powerful though). We could possibly copy the old grub.cfg from the users system over to /boot/grub2/grub.cfg. If we don't copy it we can blame Allan. I'm not quite sure what the best option here is. What do you think? Ronald
Re: [arch-dev-public] new grub2 package: advice needed
On 26 January 2011 03:37, Ronald van Haren pre...@gmail.com wrote: Hi guys, I'm preparing a new set of grub2 packages together with a user (skodabenz). We've had a rather long discussion about if we should rename 's/grub/grub2' in the package. In theory this should allow to install both grub and grub2 (chainloading, but nobody will do that anyway I suppose), but it will also make things more clear as they no longer share similar directories. - This would rename however all utilities to have grub2 in the name instead of grub. - the config directory will move to /boot/grub2 Some consequences: - people can't find their utilities anymore (searching is difficult for some) - grub2 may replace grub and switching names again would be weird - previously used config file is not loaded and people get greeted by the grub command line (which is quite powerful though). We could possibly copy the old grub.cfg from the users system over to /boot/grub2/grub.cfg. If we don't copy it we can blame Allan. I'm not quite sure what the best option here is. What do you think? What is the aim, though? From what I gather: - allow to install both grub and grub2 - make the distinction clearer Is that correct? If so, the impact from the following: - people can't find their utilities anymore (searching is difficult for some) - grub2 may replace grub and switching names again would be weird Will, IMO, not be worth this rename.
Re: [arch-dev-public] new grub2 package: advice needed
On Tue, Jan 25, 2011 at 9:31 PM, Ray Rashif sc...@archlinux.org wrote: On 26 January 2011 03:37, Ronald van Haren pre...@gmail.com wrote: Hi guys, I'm preparing a new set of grub2 packages together with a user (skodabenz). We've had a rather long discussion about if we should rename 's/grub/grub2' in the package. In theory this should allow to install both grub and grub2 (chainloading, but nobody will do that anyway I suppose), but it will also make things more clear as they no longer share similar directories. - This would rename however all utilities to have grub2 in the name instead of grub. - the config directory will move to /boot/grub2 Some consequences: - people can't find their utilities anymore (searching is difficult for some) - grub2 may replace grub and switching names again would be weird - previously used config file is not loaded and people get greeted by the grub command line (which is quite powerful though). We could possibly copy the old grub.cfg from the users system over to /boot/grub2/grub.cfg. If we don't copy it we can blame Allan. I'm not quite sure what the best option here is. What do you think? What is the aim, though? From what I gather: - allow to install both grub and grub2 - make the distinction clearer Is that correct? If so, the impact from the following: - people can't find their utilities anymore (searching is difficult for some) - grub2 may replace grub and switching names again would be weird Will, IMO, not be worth this rename. That's what I was thinking, just making sure you all (or most) agree. Ronald
Re: [arch-dev-public] [signoff] openssh-5.7p1-1
On Mon, 2011-01-24 at 13:09 +0100, Gaetan Bisson wrote: Hi everyone, OpenSSH 5.7 has just been released. Due to Guillaume's work on this package, the upgrade was quite straightforward and openssh-5.7p1-1 is now in [testing]. All tests pass on both architectures. Enjoy your shiny new ECDSA keys! (And then please signoff.) -- Gaetan Changes since OpenSSH 5.6 = Features: * Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer better performance than plain DH and DSA at the same equivalent symmetric key length, as well as much shorter keys. Only the mandatory sections of RFC5656 are implemented, specifically the three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and ECDSA. Point compression (optional in RFC5656) is NOT implemented. Certificate host and user keys using the new ECDSA key types are supported - an ECDSA key may be certified, and an ECDSA key may act as a CA to sign certificates. ECDH in a 256 bit curve field is the preferred key agreement algorithm when both the client and server support it. ECDSA host keys are preferred when learning a host's keys for the first time, or can be learned using ssh-keyscan(1). * sftp(1)/sftp-server(8): add a protocol extension to support a hard link operation. It is available through the ln command in the client. The old ln behaviour of creating a symlink is available using its -s option or through the preexisting symlink command * scp(1): Add a new -3 option to scp: Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. * ssh(1): automatically order the hostkeys requested by the client based on which hostkeys are already recorded in known_hosts. This avoids hostkey warnings when connecting to servers with new ECDSA keys, since these are now preferred when learning hostkeys for the first time. * ssh(1)/sshd(8): add a new IPQoS option to specify arbitrary TOS/DSCP/QoS values instead of hardcoding lowdelay/throughput. bz#1733 * sftp(1): the sftp client is now significantly faster at performing directory listings, using OpenBSD glob(3) extensions to preserve the results of stat(3) operations performed in the course of its execution rather than performing expensive round trips to fetch them again afterwards. * ssh(1): atomically create the listening mux socket by binding it on a temporary name and then linking it into position after listen() has succeeded. This allows the mux clients to determine that the server socket is either ready or stale without races. stale server sockets are now automatically removed. (also fixes bz#1711) * ssh(1)/sshd(8): add a KexAlgorithms knob to the client and server configuration to allow selection of which key exchange methods are used by ssh(1) and sshd(8) and their order of preference. * sftp(1)/scp(1): factor out bandwidth limiting code from scp(1) into a generic bandwidth limiter that can be attached using the atomicio callback mechanism and use it to add a bandwidth limit option to sftp(1). bz#1147 BugFixes: * ssh(1)/ssh-agent(1): honour $TMPDIR for client xauth and ssh-agent temporary directories. bz#1809 * ssh(1): avoid NULL deref on receiving a channel request on an unknown or invalid channel; bz#1842 * sshd(8): remove a debug() that pollutes stderr on client connecting to a server in debug mode; bz#1719 * scp(1): pass through ssh command-line flags and options when doing remote-remote transfers, e.g. to enable agent forwarding which is particularly useful in this case; bz#1837 * sftp-server(8): umask should be parsed as octal * sftp(1): escape '[' in filename tab-completion * ssh(1): Typo in confirmation message. bz#1827 * sshd(8): prevent free() of string in .rodata when overriding AuthorizedKeys in a Match block * sshd(8): Use default shell /bin/sh if $SHELL is * ssh(1): kill proxy command on fatal() (we already killed it on clean exit); * ssh(1): install a SIGCHLD handler to reap expiried child process; bz#1812 * Support building against openssl-1.0.0a Portable OpenSSH Bugfixes: * Use mandoc as preferred manpage formatter if it is present, followed by nroff and groff respectively. * sshd(8): Relax permission requirement on btmp logs to allow group read/write * bz#1840: fix warning when configuring --with-ssl-engine * sshd(8): Use correct uid_t/pid_t types instead of int. bz#1817 * sshd(8): bz#1824: Add Solaris Project support. * sshd(8): Check is_selinux_enabled for exact return code since it can apparently return -1 under some conditions. Signoff
Re: [arch-dev-public] [signoff] libcap-2.20-1
Am 23.01.2011 07:39, schrieb Allan McRae: Upstream update: * Latest kernel capabilites supported: now includes CAP_SYSLOG (patch from Sergey Senozhatsky) * $(CFLAGS) Makefile fixes from Torsten Werner * Default to installing setcap with an inheritable capability. o You can disable this feature with: make RAISE_SETFCAP=no install Signoff x86_64. signature.asc Description: OpenPGP digital signature
[arch-dev-public] towards namcap 2.8
Hello, Following an earlier discussion, I have stepped forward as a volunteer to continue namcap maintenance: in my personal clone at http://projects.archlinux.org/users/remy/namcap.git/ you may find several patches addressing issues reported in FlySpray. I have also tried to update the NEWS file in some sensible way. Can someone have a look at these? I'd also like to know more about the release process of namcap and the main directions of development? My next goal would be the support for split packages. Regards, -- Rémy.
Re: [arch-dev-public] [signoff] kernel26-lts 2.6.32.28-2
Le janvier 24, 2011 01:36:09 PM, Tobias Powalowski a écrit : Latest LTS kernel is in testing, fixed udev crash #22343 fixed ext3 default mount option #22544 please signoff for both arches greetings tpowa Signoff i686 (in a VM) Stéphane
Re: [arch-dev-public] towards namcap 2.8
On Tue, Jan 25, 2011 at 5:11 PM, Rémy Oudompheng remyoudomph...@gmail.com wrote: Hello, Following an earlier discussion, I have stepped forward as a volunteer to continue namcap maintenance: in my personal clone at http://projects.archlinux.org/users/remy/namcap.git/ you may find several patches addressing issues reported in FlySpray. I have also tried to update the NEWS file in some sensible way. Can someone have a look at these? I'd also like to know more about the release process of namcap and the main directions of development? My next goal would be the support for split packages. Thanks Rémy. I'll take a look in the near future and give you feedback; I'm out of town this week without a lot of time on my hands. I'll also try to fill you in on the typical release steps I've taken for the past few tags and cuts of code. I'll also give you a TODO list I've had in my head for a while of things that would make namcap a much better system overall. -Dan
[arch-dev-public] [signoff] lvm2/device-mapper 2.02.82-1
Hi, lvm2/device-mapper 2.02.82-1 are in testing for minor upstream update. Please test and signoff. Users signoffs are welcome. Thanks Eric
