Re: [arch-general] [arch-announce] GNOME3 in [testing]
On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. -- Mauro Santos
Re: [arch-general] base stuff
Yaro Kasear (2011-04-08 11:32): So in general what is the benefits / costs for SELinux? Benefits: Probably the most effective MAC for Linux. Once it runs it's arguably not too hard to allow/deny certain access due to some third party tools simplifying things a bit. You can't deny the NSA-grade security it brings which the U.S. military requires AT MINIMUM for critical infrastructure. Costs: Painfully overcomplicated. Painfully difficult to set up and configure. Requires well over half the core system to be patched to support it, potentially introducing bugs. There was a mondo security vulnerability a few years back that could actually use SELinux to grant unrestricted access to the system. Only a few filesystems actually have support for its attributes. Even its policies have to be recompiled if they have to change. Way too much can easily go wrong during set up without you having even the slightest clue how to figure out exactly what DID, turning repairs for SELinux into an almost weekend-long Google crawl. Benefits from a base Arch perspective: I can't honestly see how this would benefit Arch from putting it in the base group. Costs from a base Arch perspective: Big one being that it's entirely unnecessary, and base is meant to have ONLY what's needed to have a more or less FUNCTIONAL Linux system. Being secure is not a requirement of being functional. Other cost being that it would introduce an entirely new layer of configuration we don't need at install time, and would also guarantee that Arch would only be able to officially support the few filesystems that actually support SELinux's labelling. To sum up, it's GREAT when you actually NEED the security benefits it can bring, otherwise, it's better to seek out AppArmor (Which I believe is actually defunct.) or Tomoyo (Which I can never find any information on.), or just leave MAC off altogether if you're not doing anything altogether mission or security critical. Home desktop users would probably be better off ignoring MAC. An interesting read, thanks. -- -- Rogutės Sparnuotos
[arch-general] [signoff] lilo-23.1-3
Hi guys, - added kernel sector fix please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On 04/09/2011 04:46 AM, Mauro Santos wrote: On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Also, does anyone know what is restarting pulseaudio after I --kill? Is it gnome-shell?
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, Apr 9, 2011 at 8:47 AM, Matthew Monaco dgbale...@verizon.net wrote: On 04/09/2011 04:46 AM, Mauro Santos wrote: On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Also, does anyone know what is restarting pulseaudio after I --kill? Is it gnome-shell? I believe it uses dbus activation so it could be any pulseaudio client...
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, Apr 9, 2011 at 9:24 AM, Sander Jansen s.jan...@gmail.com wrote: On Sat, Apr 9, 2011 at 8:47 AM, Matthew Monaco dgbale...@verizon.net wrote: On 04/09/2011 04:46 AM, Mauro Santos wrote: On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Also, does anyone know what is restarting pulseaudio after I --kill? Is it gnome-shell? I believe it uses dbus activation so it could be any pulseaudio client... Actually, not sure if that's entirely true what I just said. Now '/etc/pulse/client.conf' does have a autospawn configuration option which might prevent it from restarting.
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, 09 Apr 2011 09:47:16 -0400 Matthew Monaco dgbale...@verizon.net wrote: On 04/09/2011 04:46 AM, Mauro Santos wrote: On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Also, does anyone know what is restarting pulseaudio after I --kill? Is it gnome-shell? I don't have Pulseaudio installed, yet, so I haven't tried it myself, but AFAIK you could try to start VLC with pasuspender wich will suspend PA as long as a given programm is running.
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On 09-04-2011 14:47, Matthew Monaco wrote: Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Are you sure you have set vlc to output to pulse directly? It works fine here with minimal cpu usage. Also make sure you dont have any pavucontrol or volume metering apps running. I've found those can be quite taxing on the cpu. -- Mauro Santos
Re: [arch-general] base stuff
On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream?
Re: [arch-general] base stuff
On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote: On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream? SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch
Re: [arch-general] base stuff
On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote: On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream? SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch What about the SELinux patches for things other than the kernel? Are those official to upstream? This is not for an argument, now I'm just genuinely curious.
Re: [arch-general] base stuff
On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear y...@marupa.net wrote: On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote: On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream? SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch What about the SELinux patches for things other than the kernel? Are those official to upstream? This is not for an argument, now I'm just genuinely curious. The vast majority are, but there are a few places where patches are needed, like in pam and ssh. So yes, there is a half and half going on. Basic SELinux support works without patches, but adding some of the more advanced features to some of the core applications require a few patches. -Thomas S Hatch
Re: [arch-general] base stuff
On Saturday, April 09, 2011 12:54:23 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear y...@marupa.net wrote: On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote: On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream? SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch What about the SELinux patches for things other than the kernel? Are those official to upstream? This is not for an argument, now I'm just genuinely curious. The vast majority are, but there are a few places where patches are needed, like in pam and ssh. So yes, there is a half and half going on. Basic SELinux support works without patches, but adding some of the more advanced features to some of the core applications require a few patches. -Thomas S Hatch Great! Well, I look forward to maybe testing out your repository. Maybe I'll actually get SELinux working.
Re: [arch-general] base stuff
On Sat, Apr 9, 2011 at 11:56 AM, Yaro Kasear y...@marupa.net wrote: On Saturday, April 09, 2011 12:54:23 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear y...@marupa.net wrote: On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote: On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote: On Friday, April 08, 2011 14:29:34 Heiko Baums wrote: Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch thatc...@gmail.com: Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community. I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux unofficial to all the upstream? SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch What about the SELinux patches for things other than the kernel? Are those official to upstream? This is not for an argument, now I'm just genuinely curious. The vast majority are, but there are a few places where patches are needed, like in pam and ssh. So yes, there is a half and half going on. Basic SELinux support works without patches, but adding some of the more advanced features to some of the core applications require a few patches. -Thomas S Hatch Great! Well, I look forward to maybe testing out your repository. Maybe I'll actually get SELinux working. Thats good to hear! SELinux really is amazing stuff :)
[arch-general] [signoff] usbutils-002-2
Hi guys, latest upstream release, - fix lsusb.py #23624 please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] [signoff] xfsprogs-3.1.5-1
xfsprogs-3.1.5 (30 March 2011) - Polish translation update, thanks to Jakub Bogusz - xfs_repair now warns if running in low memory mode - Phase 2 of xfs_repair is now multithreaded - xfs_quota no longer attempts to get quota information if not enabled - Inode flags are now properly validated by xfs_repair - Metadump now obfuscates all file names reliably - xfs_io now supports the fiemap command, a more generic form of the bmap command - xfs_io now supports the fpunch command, as well as a -p flag to the fallocate command. Both implement hole punching. Thanks to Josef Bacik - A number of other bug fixes thanks to Ajeet Yadav please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] [signoff] udev-167-1
Hi guys. udev 167 Bugfixes. The udev runtime data moved from /dev/.udev/ to /run/udev/. The /run mountpoint is supposed to be a tmpfs mounted during early boot, available and writable to for all tools at any time during bootup, it replaces /var/run/, which should become a symlink some day. If /run does not exist, or is not writable, udev will fall back using /dev/.udev/. On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. The command 'udevadm info --convert-db' is gone. The udev daemon itself, at startup, converts any old database version if necessary. The systemd services files have been reorganized. The udev control socket is bound by systemd and passed to the started udev daemon. The udev-settle.service is no longer active by default. Services which can not handle hotplug setups properly need to actively pull it in, to act like a barrier. Alternatively the settle service can be unconditionally 'systemctl'enabled, and act like a barrier for basic.target. The fstab_import callout is no longer built or installed. Udev should not be used to mount, does not watch changes to fstab, and should not mirror fstab values in the udev database. please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] [signoff] lilo-23.2-1
Hi guys, bump with latest fixes, especially kernel sector please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [signoff] udev-167-1
On Sat, Apr 9, 2011 at 11:24 PM, Tobias Powalowski t.p...@gmx.de wrote: Hi guys. udev 167 Bugfixes. The udev runtime data moved from /dev/.udev/ to /run/udev/. The /run mountpoint is supposed to be a tmpfs mounted during early boot, available and writable to for all tools at any time during bootup, it replaces /var/run/, which should become a symlink some day. If /run does not exist, or is not writable, udev will fall back using /dev/.udev/. On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. The command 'udevadm info --convert-db' is gone. The udev daemon itself, at startup, converts any old database version if necessary. The systemd services files have been reorganized. The udev control socket is bound by systemd and passed to the started udev daemon. The udev-settle.service is no longer active by default. Services which can not handle hotplug setups properly need to actively pull it in, to act like a barrier. Alternatively the settle service can be unconditionally 'systemctl'enabled, and act like a barrier for basic.target. The fstab_import callout is no longer built or installed. Udev should not be used to mount, does not watch changes to fstab, and should not mirror fstab values in the udev database. please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org Package is not available : https://www.archlinux.org/packages/?q=udev Something wrong? -- Sébastien Luttringer www.seblu.net
Re: [arch-general] [signoff] udev-167-1
On 10/04/11 08:04, Seblu wrote: On Sat, Apr 9, 2011 at 11:24 PM, Tobias Powalowskit.p...@gmx.de wrote: Hi guys. udev 167 Bugfixes. The udev runtime data moved from /dev/.udev/ to /run/udev/. The /run mountpoint is supposed to be a tmpfs mounted during early boot, available and writable to for all tools at any time during bootup, it replaces /var/run/, which should become a symlink some day. If /run does not exist, or is not writable, udev will fall back using /dev/.udev/. On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. The command 'udevadm info --convert-db' is gone. The udev daemon itself, at startup, converts any old database version if necessary. The systemd services files have been reorganized. The udev control socket is bound by systemd and passed to the started udev daemon. The udev-settle.service is no longer active by default. Services which can not handle hotplug setups properly need to actively pull it in, to act like a barrier. Alternatively the settle service can be unconditionally 'systemctl'enabled, and act like a barrier for basic.target. The fstab_import callout is no longer built or installed. Udev should not be used to mount, does not watch changes to fstab, and should not mirror fstab values in the udev database. please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org Package is not available : https://www.archlinux.org/packages/?q=udev Something wrong? pacman -Si udev Repository : testing Name : udev Version: 167-1 The website does not update immediately.
Re: [arch-general] [signoff] udev-167-1
On Sat, Apr 9, 2011 at 11:24 PM, Tobias Powalowski t.p...@gmx.de wrote: Hi guys. udev 167 Bugfixes. The udev runtime data moved from /dev/.udev/ to /run/udev/. The /run mountpoint is supposed to be a tmpfs mounted during early boot, available and writable to for all tools at any time during bootup, it replaces /var/run/, which should become a symlink some day. If /run does not exist, or is not writable, udev will fall back using /dev/.udev/. On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. The command 'udevadm info --convert-db' is gone. The udev daemon itself, at startup, converts any old database version if necessary. The systemd services files have been reorganized. The udev control socket is bound by systemd and passed to the started udev daemon. The udev-settle.service is no longer active by default. Services which can not handle hotplug setups properly need to actively pull it in, to act like a barrier. Alternatively the settle service can be unconditionally 'systemctl'enabled, and act like a barrier for basic.target. The fstab_import callout is no longer built or installed. Udev should not be used to mount, does not watch changes to fstab, and should not mirror fstab values in the udev database. please signoff both arches, signoff x86_64 -- Sébastien Luttringer www.seblu.net
[arch-general] weird stuff: segfault in libc and other things
hi. I switched to [testing] to get gnome 3. I found that it was a pretty bad timing because I saw that pacman updated the kernel to 2.6.38 too, and the glibc, and nvidia drivers ! and gnome 3 all in one go. Oh my..; with gnome 3, I got the gnome-shell segfaulting quite often when I hit the left top corner. or bottom right corner. got log like Apr 8 19:02:34 soho kernel: gnome-shell[17340]: segfault at 938 ip b52aa518 sp bfcef0a0 error 4 in libnvidia-glcore.so.270.30[b4423000 +16b3000] in /var/log/messages.log and just during the last 30 minutes, all the pc gone crazy: chromium stopped to respond. conky stopped to be refreshed. starting a new shell in a terminal worked but a rm on a file get stuck for no reason. I switched to a console and log in as root and never got a prompt. I had to hard reset (I lost no files: the journal has ben replayed fine) So I got call trace of chromium crashing in /var/log/messages.log but other soft too. This is a snippet of my /var/log/messages.log http://paste.pocoo.org/show/368742/ Is it a badblock on my /home (reiserfs) partition that produce that behavior ? I have done a reiserfsck and a badblock check on the /home partition and it found nothing. is it the kernel ? the libc ? I saw a convert process that segfaulted in libc ??
[arch-general] Can't run gnome 3
Hi, I installed gnome 3 from the testing repo. I haven't been able to start. Noe from KDE if I try to run gedit I get this error. [papul@papuldesktop ~]$ gedit gedit: symbol lookup error: /usr/lib/libgtk-3.so.0: undefined symbol: g_application_get_type Please help.
