Re: [gentoo-user] Odd Update Issue
On Tue, 27 May 2014 20:58:56 -0400, Hunter Jozwiak wrote: Can you fix whatever you are using to post this. Portage output is difficult enough to parse without you adding extra layers of obfuscation. * Cannot find $EPATCHSOURCE! Value for $EPATCHSOURCE is: * * /usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-fo r-r3004patch * were mesa-10.2-dont-require-llvm-for-r3004patch were * ERROR: media-libs/mesa-10.2.0.rc433gentoo failed (prepare phase): * Cannot find $EPATCHSOURCE! * * Call stack: * ebuildddsh, line 93: Called srcprepare * environment, line 4773: Called epatch The ebuild is trying to apply a patch but the patch file does not exist. Most patch files are included in the portage tree and occasionally a dev omits to update one. Run emerge --sync and try again. If the problem persists, file a bug at bugs.gentoo.org, after checking that no one else has already done it. -- Neil Bothwick Experience is what you get when you didn't get what you wanted. signature.asc Description: PGP signature
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: On 27/05/2014 17:12, J. Roeleveld wrote: I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. I'm curious why you have yearly snapshots. I've yet to find any sane production system where a yearly backup had any worth at all. Even monthly is pushing it... Or do you do it to have a decent start point for incrementals? It's to have a decent start point for incrementals. Below are the 2 biggest shares on the NAS: /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted /dev/xvda16 3.0T 2.4T 517G 83% /data/software It is impossible to do a full backup on a daily or even weekly basis. Previously, I had 1 full backup and then a daily incremental. This appears like a good idea, untill you need to restore the filesystem from backups when the crash occured 2 years later. That is 1 full backup and over 700 incrementals Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. -- Joost
Re: [gentoo-user] Intel and Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
On Tuesday 27 May 2014 22:41:32 Alan McKinnon wrote: On 27/05/2014 18:20, Time Lucky wrote: VIDEO_CARDS=intel radeon -freedreno -i915 -i965 -ilo -nouveau -r100 -r200 -r300 -r600 -radeonsi -vmware Solved! I realized that your VIDEO_CARDS was -i915 then I removed i915 from make.conf I wouldn't. Unless you also have NVidia and Radeon cards too on your machine you do not all these entries. Try this in your /etc/make.conf: VIDEO_CARDS=intel i915 Then rebuild your xorg drivers and mesa. Finally run 'eselect mesa list' to see if you are using gallium or not. Adjust accordingly. Take what I say here with a pinch of salt (building the right drivers with the right settings to work right on the right hardware is, IMNSHO, a huge amount of black magic :-) anyway, I seem to recall that USE=i915 or i965 was the old way of doing things and you needed to know what chipset to build for. Recent code has merged all of that nonsense so all you have to do is set VIDEO_CARDS=intel and emerge can figure out what to build for the hardware it's running on. Unless it changed recently, you would need to add the mesa module name for your card too. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 11:32:22 Rich Freeman wrote: On Tue, May 27, 2014 at 11:21 AM, J. Roeleveld jo...@antarean.org wrote: Does anyone know how these will handle (and perform) with a possible 300+ snapshots per filesystem (or volume, as I think it's called)? I can't speak for zfs. I had upwards of 1000 snapshots on my system before I stopped creating them hourly and and just started having issues with it. Ok, it can handle my backup schedule then. :) I wouldn't really say it is ready for prime time, but it is workable. Of course, you'll still want backups - a million snapshots does you no good if some bug wipes out your filesystem. For one of my ENOSPC incidents I ended up just wiping the entire filesystem and restoring from backup, though if I kept at it I'd probably have been able to fix it. Agreed, this is why the backup system would be adjusted for BTRFS on the fileserver, when I get round to it. I would probably keep snapshots active for the past 2 weeks. Oh, one other tip if you use btrfs - be sure you have a rescue disk that supports it. Hint, the old Gentoo install CD I had lying around didn't. You'll probably want to keep a rescue CD with a recent kernel and btrfs-tools handy at all times. Always important. I just saw the other email which states that the latest sysresccd supports it. That is fine for me. -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Wed, 28 May 2014 12:03 +0200, Joost Roeleveld wrote: Always important. I just saw the other email which states that the latest sysresccd supports it. That is fine for me. Sysresccd has supported btrfs for some time. I realise my mail could have been read otherwise, but the reason for keeping a recent CD for btrfs is that it is evolving and the recommendation is to always use the latest kernel and userspace available. -- Neil Bothwick If you can smile when things go wrong, you have someone in mind to blame. signature.asc Description: PGP signature
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 11:28:17 Rich Freeman wrote: On Tue, May 27, 2014 at 11:12 AM, J. Roeleveld jo...@antarean.org wrote: On Tuesday, May 27, 2014 10:31:26 AM Rich Freeman wrote: btrfs wouldn't have any issues with this at all. You'd have an advantage in that you wouldn't have to unmount the filesystem to cleanly create the snapshot (which you have to do with lvm). That, or a sync prior to creating the snapshot. :) If the filesystem is still mounted, I'm not sure that a sync is guaranteed to give you a clean remount. It only flushes the caches/etc. You need to remount read-only or unmount before doing the sync (and the sync probably isn't actually necessary as I'd think LVM would snapshot the contents of the cache as well). I do this for the OS-partitions of my VMs. In the VM, run sync, then on the host, take an LVM snapshot and then mount the snapshot on the host. I have not had any errors from this. I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. You only need to store snapshots for use with incremental backups. So, if all your backups are full, then you don't need to retain any snapshots (and you wouldn't use btrfs send anyway). If your yearly is full and your monthlies are incremental against the yearly then you need to keep your yearly snapshot for a year. If your yearly is full and your monthlies are incremental against the last month, then you only need to keep the yearly until the next monthly. If your monthlies are full then you only need to keep the current monthly assuming your dailies are incremental against those, but if they're incremental from the last daily then you never need to keep anything for more than a day. That makes for an interesting option. Not sure if I would implement it that way. But, it is a good idea for backing up desktops and laptops. It is really intended more for something like datacenter replication. Snapshot every 5 min, send the data to the backup datacenter, delete the snapshots upon confirmation of successful receipt. In such a scenario you wouldn't retain the sent files but just keep playing them against the replicate filesystem. They'd be fine for backups as well, as long as you can store the snapshots online until no longer needed for incrementals. app-backup/dar uses catalogues for the incrementals. I think I will stick to that for the foreseeable future. But, you can always just create a snapshot, write it to backup with your favorite tool (it is just a directory tree), and then remove it as soon as you're done with it. Creating a snapshot is atomic at the filesystem level, though again if you want application level consistency you need to deal with that until somebody comes up with a transactional way to store files on Linux that is more elegant that fsyncing on every write. That would require a method to keep database and filesystem perfectly in sync when they are not necessarily on the same machine. Well, right now we can't even guarantee consistency when everything is written by a single process on the same machine. The best we have is a clunky fsync operation which kills the write cache and destroys performance, and even that doesn't do anything if you have more than one file that must be consistent. Yep, and that's why those filesystems are actually umounted prior to creating the LVM snapshot. Umounting forces the filesystem to be put into a consistent state. The result is journals on top of journals as nobody can trust the next layer down to do its job correctly. Going across machines does complicate things further as there are more failure modes that take out one part of the overall system but not another. However, I'd like to think that an OS that natively supports transactions could at least standardize things so that every layer along the path isn't storing its own journal. In fact, many of the optimizations possible with zfs and btrfs are due to the fact that you eliminate all those layers. Either of those 2, probably btrfs as I prefer native support in the kernel, will be implemented when I get the opportunity to get the NAS on bare metal and remove the virtualization for that component. I need to find a different host for the other services first. That might take a while. -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Wed, May 28, 2014 at 6:13 AM, Joost Roeleveld jo...@antarean.org wrote: app-backup/dar uses catalogues for the incrementals. I think I will stick to that for the foreseeable future. I used to use that and sarab (which is a wrapper). I moved on to duplicity. The problem with dar is that it uses quite a bit of RAM as the number of files being backed up grows I think. So, if you have 6TB full of multimedia it might not be a huge problem, but if you have 6TB full of portage trees good luck with that. The other problem with dar is that if a file changes it stores a complete copy of it. Duplicity uses librsync, so if a file changes it only stores the parts that actually changed. It also uses catalogs, and supports things like caching catalogs (so you don't need the last incremental mounted), and a bunch of storage backends (like S3). However, dar definitely is more useful than tar if you want the option for random access. Rich
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On 28/05/2014 11:58, Joost Roeleveld wrote: On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: On 27/05/2014 17:12, J. Roeleveld wrote: I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. I'm curious why you have yearly snapshots. I've yet to find any sane production system where a yearly backup had any worth at all. Even monthly is pushing it... Or do you do it to have a decent start point for incrementals? It's to have a decent start point for incrementals. Below are the 2 biggest shares on the NAS: /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted /dev/xvda16 3.0T 2.4T 517G 83% /data/software It is impossible to do a full backup on a daily or even weekly basis. Previously, I had 1 full backup and then a daily incremental. This appears like a good idea, untill you need to restore the filesystem from backups when the crash occured 2 years later. That is 1 full backup and over 700 incrementals Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. OK, that makes sense. It reminds me of an issue my wife had with the data warehouse when she worked at the bank. In a nutshell, they needed backups but backups were impossible to achieve because physics says so. They needed to get data off the disk 4 times faster than data comes off a disk - SCSI limits being rather hard limits :-) That opinion didn't go down well when I offered it The solution was to do it much like your plan above. With the benefit that the infrequent full backups would be done on a fixed schedule in a change window with X hours downtime that was known well in advance. -- Alan McKinnon alan.mckin...@gmail.com
RE: [gentoo-user] Odd Update Issue
-Original Message- From: Neil Bothwick [mailto:n...@digimed.co.uk] Sent: Wednesday, May 28, 2014 3:58 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Odd Update Issue On Tue, 27 May 2014 20:58:56 -0400, Hunter Jozwiak wrote: Can you fix whatever you are using to post this. Portage output is difficult enough to parse without you adding extra layers of obfuscation. * Cannot find $EPATCHSOURCE! Value for $EPATCHSOURCE is: * * /usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-fo r-r3004patch * were mesa-10.2-dont-require-llvm-for-r3004patch were * ERROR: media-libs/mesa-10.2.0.rc433gentoo failed (prepare phase): * Cannot find $EPATCHSOURCE! * * Call stack: * ebuildddsh, line 93: Called srcprepare * environment, line 4773: Called epatch The ebuild is trying to apply a patch but the patch file does not exist. Most patch files are included in the portage tree and occasionally a dev omits to update one. Run emerge --sync and try again. If the problem persists, file a bug at bugs.gentoo.org, after checking that no one else has already done it. -- Neil Bothwick Experience is what you get when you didn't get what you wanted. Thanks much. The patch did sync across this time.
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Wednesday 28 May 2014 13:07:49 Alan McKinnon wrote: On 28/05/2014 11:58, Joost Roeleveld wrote: On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: On 27/05/2014 17:12, J. Roeleveld wrote: I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. I'm curious why you have yearly snapshots. I've yet to find any sane production system where a yearly backup had any worth at all. Even monthly is pushing it... Or do you do it to have a decent start point for incrementals? It's to have a decent start point for incrementals. Below are the 2 biggest shares on the NAS: /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted /dev/xvda16 3.0T 2.4T 517G 83% /data/software It is impossible to do a full backup on a daily or even weekly basis. Previously, I had 1 full backup and then a daily incremental. This appears like a good idea, untill you need to restore the filesystem from backups when the crash occured 2 years later. That is 1 full backup and over 700 incrementals Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. OK, that makes sense. It reminds me of an issue my wife had with the data warehouse when she worked at the bank. In a nutshell, they needed backups but backups were impossible to achieve because physics says so. They needed to get data off the disk 4 times faster than data comes off a disk - SCSI limits being rather hard limits :-) That opinion didn't go down well when I offered it Haha :) I know the feeling. I'd love to know the final solution they came up with. The solution was to do it much like your plan above. With the benefit that the infrequent full backups would be done on a fixed schedule in a change window with X hours downtime that was known well in advance. Using snapshots, the downtime is the same couple of minutes each night. The problem is that during the backup, the performance of the server is impacted. For a full backup, that means weeks... -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On 28/05/2014 13:42, Joost Roeleveld wrote: Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. OK, that makes sense. It reminds me of an issue my wife had with the data warehouse when she worked at the bank. In a nutshell, they needed backups but backups were impossible to achieve because physics says so. They needed to get data off the disk 4 times faster than data comes off a disk - SCSI limits being rather hard limits :-) That opinion didn't go down well when I offered it Haha :) I know the feeling. I'd love to know the final solution they came up with. It was clever magic with LVM snapshots, but I'm not privy to the details - it was a bank after all and there's only so much Mrs Alan and the sysadmins could tell me. But it went something like this: Take a snapshot and copy that data to the SAN. This takes days or weeks and it's only ever done once. Thereafter, snapshots only. The backup system would take that last full + incrementals and create a new full for it's own use, this process runs independent from everything else and must take as long as it takes while the db carries on doing it's thing. If two backup jobs start to overlap in time, one of them gets discarded. Quite a clever scheme actually and it relies on storage being shared on the SAN to work, plus some in-house magic to get the backup system to recognise and use LVM snapshots natively. I believe performance impact was kept to acceptable levels by cleverly setting priorities - read/writes by the db take priority over backup reads which has to take a back seat and just wait it's turn. The solution was to do it much like your plan above. With the benefit that the infrequent full backups would be done on a fixed schedule in a change window with X hours downtime that was known well in advance. Using snapshots, the downtime is the same couple of minutes each night. The problem is that during the backup, the performance of the server is impacted. For a full backup, that means weeks... -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Intel and Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
#emacs /etc/portage/make.conf VIDEO_CARDS=intel i915 # emerge -av xorg-drivers mesa # reboot # eselect mesa list 915 (Intel 915, 945) [1] classic [2] gallium * i965 (Intel GMA 965, G/Q3x, G/Q4x, HD) r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) [1] classic [2] gallium * and gnome tells it is Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits) again. it seems i915 is the very reason. 2014-05-28 15:14 GMT+08:00 Mick michaelkintz...@gmail.com: On Tuesday 27 May 2014 22:41:32 Alan McKinnon wrote: On 27/05/2014 18:20, Time Lucky wrote: VIDEO_CARDS=intel radeon -freedreno -i915 -i965 -ilo -nouveau -r100 -r200 -r300 -r600 -radeonsi -vmware Solved! I realized that your VIDEO_CARDS was -i915 then I removed i915 from make.conf I wouldn't. Unless you also have NVidia and Radeon cards too on your machine you do not all these entries. Try this in your /etc/make.conf: VIDEO_CARDS=intel i915 Then rebuild your xorg drivers and mesa. Finally run 'eselect mesa list' to see if you are using gallium or not. Adjust accordingly. Take what I say here with a pinch of salt (building the right drivers with the right settings to work right on the right hardware is, IMNSHO, a huge amount of black magic :-) anyway, I seem to recall that USE=i915 or i965 was the old way of doing things and you needed to know what chipset to build for. Recent code has merged all of that nonsense so all you have to do is set VIDEO_CARDS=intel and emerge can figure out what to build for the hardware it's running on. Unless it changed recently, you would need to add the mesa module name for your card too. -- Regards, Mick
Re: [gentoo-user] Intel and Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
Now I change the VIDEO_CARDS to intel i965 Everything seems OK too. Gnome can detect Intel® Sandybridge Mobile rather than Gallium 0.4 for i915 I dont know the difference between classic and gallium but i965's classic mode works well. By the way, I think i965 is just for HD3000, why does i915 be suggested ? # eselect mesa list i915 (Intel 915, 945) i965 (Intel GMA 965, G/Q3x, G/Q4x, HD) [1] classic * r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) [1] classic [2] gallium * 2014-05-28 21:14 GMT+08:00 Time Lucky fly8...@gmail.com: #emacs /etc/portage/make.conf VIDEO_CARDS=intel i915 # emerge -av xorg-drivers mesa # reboot # eselect mesa list 915 (Intel 915, 945) [1] classic [2] gallium * i965 (Intel GMA 965, G/Q3x, G/Q4x, HD) r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) [1] classic [2] gallium * and gnome tells it is Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits) again. it seems i915 is the very reason. 2014-05-28 15:14 GMT+08:00 Mick michaelkintz...@gmail.com: On Tuesday 27 May 2014 22:41:32 Alan McKinnon wrote: On 27/05/2014 18:20, Time Lucky wrote: VIDEO_CARDS=intel radeon -freedreno -i915 -i965 -ilo -nouveau -r100 -r200 -r300 -r600 -radeonsi -vmware Solved! I realized that your VIDEO_CARDS was -i915 then I removed i915 from make.conf I wouldn't. Unless you also have NVidia and Radeon cards too on your machine you do not all these entries. Try this in your /etc/make.conf: VIDEO_CARDS=intel i915 Then rebuild your xorg drivers and mesa. Finally run 'eselect mesa list' to see if you are using gallium or not. Adjust accordingly. Take what I say here with a pinch of salt (building the right drivers with the right settings to work right on the right hardware is, IMNSHO, a huge amount of black magic :-) anyway, I seem to recall that USE=i915 or i965 was the old way of doing things and you needed to know what chipset to build for. Recent code has merged all of that nonsense so all you have to do is set VIDEO_CARDS=intel and emerge can figure out what to build for the hardware it's running on. Unless it changed recently, you would need to add the mesa module name for your card too. -- Regards, Mick
[gentoo-user] systemd and amixer
Hi. Since I booted into systemd, if I try to run amixer from a normal user I get very different results than if I run amixer as root. The directory /dev/snd is world rw and I would like to know what is happening. The numbers are very different for instance the Master volume as a regular user is 100%, but as root its 40% where it should be. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Intel and Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
On Wednesday 28 May 2014 14:46:30 Time Lucky wrote: Now I change the VIDEO_CARDS to intel i965 Everything seems OK too. Gnome can detect Intel® Sandybridge Mobile rather than Gallium 0.4 for i915 I dont know the difference between classic and gallium but i965's classic mode works well. By the way, I think i965 is just for HD3000, why does i915 be suggested ? Oh! I suggested i915 thinking that this is the chipset of your Intel video card - apologies if I got it wrong. A couple of years ago the gallium driver of mesa was still work in progress for Intel cards. http://www.x.org/wiki/GalliumStatus/ I don't know if it has improved since, but from what you reported it must have some problems. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: bluez 5 not connecting
On Sunday 27 Apr 2014 08:27:31 William Kenworthy wrote: On 04/27/14 11:14, William Kenworthy wrote: On 04/27/14 02:33, Mick wrote: On Thursday 24 Apr 2014 02:11:57 William Kenworthy wrote: I was able to get it working manually - gentoo's init scripts are out of date with bluez 5, blutoothctl is broken (or probably just poorly documented which equates to the same thing if the command doesn't work) . In bluetoothctl: power on scan on agent on default-agent pair dev_id trust dev_id exit In a shell: rfcomm bind rfcomm0 dev_id do serial port stuff with /dev/rfcomm0 rfcomm unbind rfcomm0 bluetoothctl connect command does not work - connects and immediately disconnects with an error gentoo's rfcomm initscript has removed the -f flag which bluez 5 does not have, but it also looks like the bind all in the 5.17 ebuild is also not supported by late bluez5 so it immediately exits and no rfcomm device is created. Ive adapted my python script to the changes now - but the pairing does not survive restarting bluetooth so I'll need an expect script to set it up each bluetooth re-init as it looks like there are no scripting hooks in bluetoothctl. BillK Thanks BillK, your suggestions above helped somewhat, because I was able to connect with my phone, but it didn't get me far enough. I was not able to connect with rfcomm to my mobile. When I ran 'pon connection_name' pppd started, but I got errors like: Apr 26 18:15:12 dell_xps chat[29579]: -- write failed: Transport endpoint is not connected Apr 26 18:15:12 dell_xps chat[29579]: Failed This was despite the fact that I had created manually the rfcomm0 device and binded it to the bdaddr of my phone as you suggested. Googling for this error revealed that this is because the rfcomm code has changed - but there is a patch which may fix things: http://comments.gmane.org/gmane.linux.bluez.kernel/42303 I ran out of time and did not try 'rfcomm connect' instead of 'rfcomm bind' to see if it makes a difference in my case. FYI, I'm on net-wireless/bluez-5.15 and kernel 3.12.13-gentoo. I just upgraded to 3.12.13 and it stopped working with the same error you have. I did see some other messages saying that certain kernel versions are broken but I'll now need to look into that now. BillK I used the patch from the reply above - worked! It did take a couple of goes but after restarting the bluetooth initscript before using bluetoothctl via expect (took 3 goes before I got a clean run from expect - timing might need adjusting?) This is getting worse! O_O I am on net-wireless/bluez-5.18 and gentoo-sources-3.12.20 without the patch. Now I have no rfcomm service at all listed under rc-update and if I try to start /etc/init.d/bluetooth I get: # /etc/init.d/bluetooth restart * ERROR: bluetooth needs service(s) rfcomm Creating /dev/rfcomm0 with: # rfcomm bind rfcomm0 hci0 does not change the error. Starting KDE's BlueDevil shows no adaptor found. Indeed, hci0 is not configured. O_o So, running: # hciconfig hci0 up allows me to list it: $ hcitool dev Devices: hci090:4C:E5:FA:F2:A8 but NOT under bluetoothctl! [bluetooth]# power on No default controller available [bluetooth]# show No default controller available [bluetooth]# list [bluetooth]# [bluetooth]# devices [bluetooth]# NOTE: using hcitool I can scan my mobile phone, but without rfcomm I can't use it. Hmm ... am I alone in this quest? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: bluez 5 not connecting
On 28/05/14 21:42, Mick wrote: Hmm ... am I alone in this quest? See here, http://bugs.gentoo.org/show_bug.cgi?id=505362
Re: [gentoo-user] systemd and amixer
On Wed, May 28, 2014 at 10:06:44AM -0400, cov...@ccs.covici.com wrote Hi. Since I booted into systemd, if I try to run amixer from a normal user I get very different results than if I run amixer as root. The directory /dev/snd is world rw and I would like to know what is happening. The numbers are very different for instance the Master volume as a regular user is 100%, but as root its 40% where it should be. Thanks in advance for any suggestions. Is /var/lib/alsa/asound.state world readable? If not, regular users may get some default value. On my system... [d531][waltdnes][~] ll /var/lib/alsa/asound.state -rw-r--r-- 1 root root 7749 May 28 17:32 /var/lib/alsa/asound.state -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: bluez 5 not connecting
On Wednesday 28 May 2014 20:02:29 Samuli Suominen wrote: On 28/05/14 21:42, Mick wrote: Hmm ... am I alone in this quest? See here, http://bugs.gentoo.org/show_bug.cgi?id=505362 Thanks! I missed this bug when I glanced earlier. However, it does not mention rfcomm is now missing, or the fact that the gentoo rc script fails to initialise bluethooth and complains about rfcomm service not having started/exist, or that bluetoothctl now does not work at all. Is all this down to a missing udev rule? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] systemd and amixer
Walter Dnes waltd...@waltdnes.org wrote: On Wed, May 28, 2014 at 10:06:44AM -0400, cov...@ccs.covici.com wrote Hi. Since I booted into systemd, if I try to run amixer from a normal user I get very different results than if I run amixer as root. The directory /dev/snd is world rw and I would like to know what is happening. The numbers are very different for instance the Master volume as a regular user is 100%, but as root its 40% where it should be. Thanks in advance for any suggestions. Is /var/lib/alsa/asound.state world readable? If not, regular users may get some default value. On my system... [d531][waltdnes][~] ll /var/lib/alsa/asound.state -rw-r--r-- 1 root root 7749 May 28 17:32 /var/lib/alsa/asound.state Yep, its the same, but when I tried to restore as a regular user (which I normally don't do) it complained about the .lock file and restored to some strange values which involved so much feedback that I had to go to a root window and restore again. The strange thing is that I had no problems like this under openrc, so I wonder what systemd is doing and how I can get around it. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: bluez 5 not connecting
On 29/05/14 06:28, Mick wrote: On Wednesday 28 May 2014 20:02:29 Samuli Suominen wrote: On 28/05/14 21:42, Mick wrote: Hmm ... am I alone in this quest? See here, http://bugs.gentoo.org/show_bug.cgi?id=505362 Thanks! I missed this bug when I glanced earlier. However, it does not mention rfcomm is now missing, or the fact that the gentoo rc script fails to initialise bluethooth and complains about rfcomm service not having started/exist, or that bluetoothctl now does not work at all. Is all this down to a missing udev rule? No its the fact that bluez 5 has been redesigned to fit in more with the systemd world. it works if: remove rfcomm using rc-update /etc/init.d/bluetoothctl restart (get rid of any existing config) bluetoothctl power on scan on agent on default-agent trust [MAC ADDRESS OF CLIENT] pair [MAC ADDRESS OF CLIENT] enter PIN when requested wait for Connected: no exit After this you should have an rfcomm channel available to the client. I have the above in an expect script as bluetoothctl has no inate remote controllability capabilities. No separate pairing app or rfcomm init script needed. BillK
Re: [gentoo-user] systemd and amixer
On Wed, May 28, 2014 at 06:36:28PM -0400, cov...@ccs.covici.com wrote Walter Dnes waltd...@waltdnes.org wrote: Yep, its the same, but when I tried to restore as a regular user (which I normally don't do) it complained about the .lock file and restored to some strange values which involved so much feedback that I had to go to a root window and restore again. The strange thing is that I had no problems like this under openrc, so I wonder what systemd is doing and how I can get around it. The settings are supposed to be automatically restored as part of the bootup process. If you run openrc, did you execute... rc-update add alsasound boot ...at alsa installation as per http://wiki.gentoo.org/wiki/ALSA ? If you run systemd, I assume there's an equivalant service file. And, grasping at straws, is your regular user a member of the audio group? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
