Re: [arch-dev-public] adding rng-tools to extra?
Am 04.06.2012 07:32, schrieb Tobias Powalowski: Am 04.06.2012 02:22, schrieb Gaetan Bisson: [2012-06-03 20:48:21 +0200] Tobias Powalowski: with enabling pacman signing, shouldn't we add the rng-tools to extra to be able to use it on install media too? For interactive installers, it seems to me like a better solution to simply ask the user to provide true entropy through typing random stuff on their keyboards - shouldn't take more than twenty seconds or so. For virtual machines, I use the stupid code attached to transfer entropy from the host to the guest. I don't know rng-tools but if it better answers either problem it would indeed be nice to have it in [extra]. Ok as discussed on IRC, haveged seems the better choice because rng-tools need a real hw generator to work correct. Thanks guys for clarification, no need for it in extra repository then. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 6 fully signed off packages * 14 packages missing signoffs * 2 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * fakeroot-1.18.4-1 (i686) * fakeroot-1.18.4-1 (x86_64) == Incomplete signoffs for [core] (3 total) == * fakeroot-1.18.4-1 (i686) 1/2 signoffs * pinentry-0.8.1-4 (i686) 1/2 signoffs * fakeroot-1.18.4-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (9 total) == * fcpci-31107-75 (i686) 0/2 signoffs * fcpcmcia-31107-70 (i686) 0/2 signoffs * gc-7.2-1 (i686) 0/2 signoffs * lirc-1:0.9.0-18 (i686) 0/2 signoffs * nvidia-295.53-2 (i686) 0/2 signoffs * fcpci-31107-75 (x86_64) 0/2 signoffs * fcpcmcia-31107-70 (x86_64) 0/2 signoffs * gc-7.2-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-18 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * libusbx-1.0.11-2 (i686) 1/2 signoffs * libusbx-1.0.11-2 (x86_64) 1/2 signoffs == Completed signoffs (6 total) == * linux-3.4-1 (i686) * pacman-4.0.3-2 (i686) * linux-3.4-1 (x86_64) * pacman-4.0.3-2 (x86_64) * pinentry-0.8.1-4 (x86_64) * nvidia-295.53-2 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * gc-7.2-1 (i686), since 2012-05-18 * gc-7.2-1 (x86_64), since 2012-05-18 == Top five in signoffs in last 24 hours == 1. pierre - 5 signoffs 2. allan - 3 signoffs
Re: [arch-dev-public] Current [core] repo packages build failures
Am 01.06.2012 11:56, schrieb Allan McRae: I am doing a local rebuild of all [core] packages to test if there are any issues with the upcoming glibc-2.16 before it gets released. As a baseline, I built the [core] repo using the current glibc. All failures are from the latest package in [testing]/[core] with building with testing-x86_64 FAIL: syslinux /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t' Sounds weird. I'll look into it. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Current [core] repo packages build failures
On 04/06/12 18:15, Thomas Bächler wrote: Am 01.06.2012 11:56, schrieb Allan McRae: I am doing a local rebuild of all [core] packages to test if there are any issues with the upcoming glibc-2.16 before it gets released. As a baseline, I built the [core] repo using the current glibc. All failures are from the latest package in [testing]/[core] with building with testing-x86_64 FAIL: syslinux /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t' Sounds weird. I'll look into it. Don't look to hard. It is due to the header being broken. I reported it to the kernel bugtracker but the response was basically do not use that header... The syslinux dev knows about it. Allan
Re: [arch-dev-public] Current [core] repo packages build failures
Am 04.06.2012 10:24, schrieb Allan McRae: FAIL: syslinux /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t' Sounds weird. I'll look into it. Don't look to hard. It is due to the header being broken. I reported it to the kernel bugtracker but the response was basically do not use that header... The syslinux dev knows about it. Allan There's also https://bugs.archlinux.org/task/30084. signature.asc Description: OpenPGP digital signature
[arch-dev-public] alberich refuses ssh,http
what happened with this box? dieter@dieter-ws ~ ssh alberich.archlinux.org ssh: connect to host alberich.archlinux.org port 22: Connection refused dieter@dieter-ws ~ telnet alberich.archlinux.org 80 Trying 216.151.172.98... telnet: Unable to connect to remote host: Connection refused
Re: [arch-dev-public] alberich refuses ssh,http
Am 04.06.2012 13:56, schrieb Dieter Plaetinck: what happened with this box? dieter@dieter-ws ~ ssh alberich.archlinux.org ssh: connect to host alberich.archlinux.org port 22: Connection refused dieter@dieter-ws ~ telnet alberich.archlinux.org 80 Trying 216.151.172.98... telnet: Unable to connect to remote host: Connection refused I am also unable to login to the control panel. This is weird. Aaron, can you contact Joshua about it? signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] filesystem-2012.3-1
On Sat, Jun 02, 2012 at 11:45:26PM +0200, Tom Gundersen wrote:
Hi guys,
We want to tidy up the /var/{lock,run} situation. They should be
symlinks to /run{,/lock}.
Currently they are shipped as regular directories in the filesystem
package, and on the next boot they are replaced by symlinks (by
initscripts). It has been like this for about a year, and I'd like to
fix this up properly by shipping the symlinks in the filesystem
package.
The upgrade requires user intervention:
# rm /var/{lock,run} ; pacman -Syu
Deleting these symlinks/folders on a running system might have
unintended side effects, but as far as we have been able to figure out
nothing fatal. To be on the safe side, I think we should (in a news
item) advice users to shut down anything going on in the background to
the extent possible before doing the upgrade and reboot after the
upgrade is finished.
Any thoughts on this?
A request: it would be really ideal if we could roll a new installer
release as soon as this is out, so people don't have to deal with
these sorts of things on their first upgrade after install. Would that
be possible?
Cheers,
Tom
FYI: This has been released into the wild as filesystem 2012.06-1.
Re: [arch-dev-public] PAM config rework
On Sat, Jun 02, 2012 at 07:42:20PM -0400, Dave Reisner wrote: Hey all, I'll be pushing a package into testing this weekend by the name of 'pambase'. The name and basis for this package comes from Gentoo. I'd like for this to live in [core] and become a dependency of PAM (as well as absorb /etc/pam.d/other). pambase will provide a few common PAM configuration files which other services can draw from (essentially implementing an ancient FS [1]). For example, it shrinks a useful /etc/pam.d/login down to the following: auth required pam_securetty.so auth include system-local-login accountinclude system-local-login sessioninclude system-local-login In the short term, util-linux will be rebuilt to enable binaries from its login-utils subdirectory: login, chfn, chsh, vigr, vipw, and newgrp. They'll disappear from shadow, and I suspect that over time, more of shadow's utils will re-appear in util-linux (with the benefit of a more active and responsive maintainer/community). In the long term, other utilities are encouraged to adopt these common PAM files. Until I actually release the package, I've left a source tarball on gerolde, for interested parties to review [2]. Cheers, Dave [1] https://bugs.archlinux.org/task/17188 [2] http://dev.archlinux.org/~dreisner/pambase-20120602-1.src.tar.gz Since there were no objections, I've rebuilt PAM and added pambase to testing.
[arch-dev-public] Removing gimp-devel from [extra]
Hi, I would like to move gimp-devel to AUR. At the moment, I'm the maintainer of gimp and gimp-devel, but I don't see any reason for the devel package in our repository. These are not the development files for gimp, it's the next devel branch for the next version (just for clarification). I will move it tomorrow, if no objections appears. Daniel signature.asc Description: PGP signature
[arch-dev-public] KDE 4.9 packages
Hi all, the first beta of the 4.9 series has been released[1]. As usual, you find the kde packages in the [kde-unstable] repo, which only contains major beta release. Read install instruction from here[2]. NOTE: It requires [testing] enabled. kde-multimedia has been split, so there's no kdemultimedia-kioslave in 4.9, instead you find: - kdemultimedia-audiocd-kio - libkcddb - libkcompactdisc Packagers should update their deps when 4.9 hits [extra]. In the meantime, this is a list of the packages that need to be rebuilt if you enable [kde- unstable]: - k3b (replace kioslave with libkcddb to depends) - audex (replace kioslave with libkcddb, libkcompactdisc to depends) - kaudiocreator (replace kioslave with libkcddb, libkcompactdisc to depends) - soundkonverter (replace kioslave with libkcddb to depends) - tellico (replace kioslave with libkcddb to depends) Also, there are: - a new kdebase-runtime dependence: nepomuk-core - a new game in kdeedu: kdeedu-pairs - a new kdebase-workspace dependence: kdebase-workspace kdesdk-kdeaccounts-plugin, kdesdk-kdepalettes, kdeutils-ksecrets have been removed from the KDE SC. Please reply to the thread on BBS[3] or report any bug to our bug tracker[4] for any packaging bug. KDE bugs go in the upstream bug tracker. Have a nice update/testing! :) Cheers [1] http://kde.org/announcements/announce-4.9-beta1.php [2] https://wiki.archlinux.org/index.php/DeveloperWiki:KDE#Using_the_kde- unstable_repository [3] https://bbs.archlinux.org/viewtopic.php?pid=024#p024 [4] https://bugs.archlinux.org/ -- Andrea
Re: [arch-dev-public] Proposed news item: Package verification
On 02/06/12 17:25, Gaetan Bisson wrote: [2012-05-31 23:07:34 +1000] Gaetan Bisson: Attached are an updated proposed news post and pacman-4.0.3-2 release. Since nobody objects, I'll push this to [testing] tomorrow. How many packages need to provide the same instructions... (1/2) installing archlinux-keyring [##] 100% Run `pacman-key --init` to set up your pacman keyring. Then run `pacman-key --populate archlinux` to install the Arch Linux keyring. (2/2) upgrading pacman [##] 100% warning: /etc/makepkg.conf installed as /etc/makepkg.conf.pacnew warning: /etc/pacman.conf installed as /etc/pacman.conf.pacnew Run `pacman-key --init; pacman-key --populate archlinux` to import the data required by pacman for package verification. See: https://www.archlinux.org/news/having-pacman-verify-packages
