Description of problem: The current version of the library presents the "trust bug" where some Apple devices with iOS 7 will not pair with the host and keep prompting the user. Additionally, I'd like to submit a package for review which does not build against the current library. A recent git snapshot I tried (440fdebcd2cdbc10e14ed08d38f9910c15bdac6b) solves both issues and is available at https://github.com/libimobiledevice/libimobiledevice/archive/440fdebcd2cdbc10e14ed08d38f9910c15bdac6b.tar.gz. Version-Release number of selected component (if applicable): 1.1.5-3
Update it to what exactly? We're running the current stable release, once we go to RCs I'll update it in rawhide.
To a post-release snapshot version, like 1.1.5-4.gitXXX, or perhaps a pre-release like 1.1.6-0.1.gitXXX (this is the version number I got from ./configure)? If it can't be done, I'll run with a local upgrade for now and wait until the official release of 1.1.6 becomes available.
1.1.6 is out. Any chance of an update? Sorry if I seem impatient, but this bug has been a big disruption.
This is being worked on at least in rawhide https://lists.fedoraproject.org/pipermail/devel/2014-March/197022.html
(In reply to ajs from comment #3) > 1.1.6 is out. Any chance of an update? It's under review. > Sorry if I seem impatient, but this bug has been a big disruption. Not as big as the possible disruption to a stable release. There's big changes in the library including new dependent libraries and changes to ABI. There will be a number of packages that need to be updated and I'll be landing the change in rawhide first once it's ready to ascertain the impact. I'm not prepared to break core components of a stable release for this, it will come when and if it's ready.
*** Bug 1084180 has been marked as a duplicate of this bug. ***
Fair enough. Do you know if the ABI changes are due to iOS 7 or some choice by the libimobiledevice developers?
*** Bug 1088980 has been marked as a duplicate of this bug. ***
this bug is causing me to not even be able to charge my iphone on my laptop because it pops up the trust dialogs every few seconds. This is a pretty serious bug, irrespective of whether or not one can mount the iphone fs.
(In reply to Peter Robinson from comment #5) > (In reply to ajs from comment #3) > > 1.1.6 is out. Any chance of an update? > > It's under review. > > > Sorry if I seem impatient, but this bug has been a big disruption. > > Not as big as the possible disruption to a stable release. Though I am not a fan of Apple's total control of their products and related software and accessories. It is a reality, and they are at a 51% market share for IOS. IOS 7 has been out for ten months, and the IOS 7 upgrade made libimobiledevice completely non-functional. Fedora 20 came out 7 months ago, which means that libimobiledevice has been broken for the entire life of Fedora 20. libimobiledevice has been a disruption since the initial release of Fedora 20, and will continue to be a disruption until it is updated. I had to install a dual boot just to work around the IOS 7 vs. libimobiledevice incompatibility. When an upgrade happens, users like me will be very happy that Fedora finally works with IOS again.
It's in Fedora 21... and there's been exactly zero confirmations that it works OK. It clearly isn't that much of a priority for everyone
(In reply to Peter Robinson from comment #11) > It's in Fedora 21... and there's been exactly zero confirmations that it > works OK. It clearly isn't that much of a priority for everyone Probably because F21/rawhwide isn't something that people want to install on their systems. An F20 COPR or an F21 liveCD with the updated packages would ease testing.
(In reply to Bastien Nocera from comment #12) > (In reply to Peter Robinson from comment #11) > > It's in Fedora 21... and there's been exactly zero confirmations that it > > works OK. It clearly isn't that much of a priority for everyone > > Probably because F21/rawhwide isn't something that people want to install on > their systems. An F20 COPR or an F21 liveCD with the updated packages would > ease testing. Isn't that what the workstation Live nightly image is?
(In reply to Peter Robinson from comment #13) > (In reply to Bastien Nocera from comment #12) > > (In reply to Peter Robinson from comment #11) > > > It's in Fedora 21... and there's been exactly zero confirmations that it > > > works OK. It clearly isn't that much of a priority for everyone > > > > Probably because F21/rawhwide isn't something that people want to install on > > their systems. An F20 COPR or an F21 liveCD with the updated packages would > > ease testing. > > Isn't that what the workstation Live nightly image is? It fails with SELinux enabled because usbmuxd tries to create a /var/lib/lockdownd/ directory and write files in it, which SELinux won't allow. If SELinux is disabled, it kind of works, but there's some integration problems in GNOME (gvfs in particular).
Just trying this Copr repository: http://copr.fedoraproject.org/coprs/cwawak/libimobiledevice/ We'll need at least a rebuild, or an update, for these packages: - ifuse - libgpod - upower
There's been some fixes upstream I've been awaiting for systemd fixes which I believe this now looks mostly sane so I'm pushing an update with a high karma requirement for it to land into stable so please test it and provide karma feedback when the update lands in testing (or get the bits from koji).
libplist-1.11-2.fc20,libusbmuxd-1.0.9-2.fc20,libimobiledevice-1.1.6-2.fc20,usbmuxd-1.0.9-0.4.c24463e.fc20,ifuse-1.1.3-3.fc20,libgpod-0.8.3-2.fc20,upower-0.9.23-3.fc20,gvfs-1.18.3-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libplist-1.11-2.fc20,libusbmuxd-1.0.9-2.fc20,libimobiledevice-1.1.6-2.fc20,usbmuxd-1.0.9-0.4.c24463e.fc20,ifuse-1.1.3-3.fc20,libgpod-0.8.3-2.fc20,upower-0.9.23-3.fc20,gvfs-1.18.3-3.fc20
Package libplist-1.11-2.fc20, libusbmuxd-1.0.9-2.fc20, libimobiledevice-1.1.6-2.fc20, usbmuxd-1.0.9-0.4.c24463e.fc20, ifuse-1.1.3-3.fc20, libgpod-0.8.3-2.fc20, upower-0.9.23-3.fc20, gvfs-1.18.3-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libplist-1.11-2.fc20 libusbmuxd-1.0.9-2.fc20 libimobiledevice-1.1.6-2.fc20 usbmuxd-1.0.9-0.4.c24463e.fc20 ifuse-1.1.3-3.fc20 libgpod-0.8.3-2.fc20 upower-0.9.23-3.fc20 gvfs-1.18.3-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9092/libplist-1.11-2.fc20,libusbmuxd-1.0.9-2.fc20,libimobiledevice-1.1.6-2.fc20,usbmuxd-1.0.9-0.4.c24463e.fc20,ifuse-1.1.3-3.fc20,libgpod-0.8.3-2.fc20,upower-0.9.23-3.fc20,gvfs-1.18.3-3.fc20 then log in and leave karma (feedback).
I like to address an issue. When I installed Fedora 20 from a CD/DVD it automatically provides me with all the idevice* files in the bin directory. With this update all files in the bin directory get removed. I initially though that this might be a bug since I as normal user expect an update to NOT remove files that I expect to be there. From previous Fedora installations I know libimobiledevice to provide all these files and that package got updated. I reported a bug about this a few hours ago. https://bugzilla.redhat.com/show_bug.cgi?id=1126154 My expectation was that an update will leave the system with all required files as it used to be previous. Instead of that someone introduced a NEW package called libmobiledevice-utils which contains exactly the files that got ripped out of libmobiledevices. So far so good. I don't have an issue with a split up package. But this has to be communicated somehow so people know what actually happened and where their files they rely on are. For me libimobiledevice is not just about the library. It's all about the utils that comes with it. The utils are what makes libimobiledevice worth installed and thats how a stock Fedora 20 releases them. Libimobiledevice == /bin/idevice* I therefore would suggest that an update OF AN OLD libimobiledevice automatically installs libimobiledevice-utils as well so the system stays consistent as someone would expect it. I hope I was able to make my point clear. Thanks.
libplist-1.11-2.fc20, libusbmuxd-1.0.9-2.fc20, libimobiledevice-1.1.6-2.fc20, usbmuxd-1.0.9-0.4.c24463e.fc20, ifuse-1.1.3-3.fc20, libgpod-0.8.3-2.fc20, upower-0.9.23-3.fc20, gvfs-1.18.3-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This bug still exist. Can't mount an iPad with iOS8 at Fedora 20.
(In reply to kafran from comment #21) > This bug still exist. Can't mount an iPad with iOS8 at Fedora 20. No, the bug does not still exist. It's been updated. If it doesn't work with iOS8 it's because it's likely not been reverse engineered upstream yet.
(In reply to Peter Robinson from comment #22) > (In reply to kafran from comment #21) > > This bug still exist. Can't mount an iPad with iOS8 at Fedora 20. > > No, the bug does not still exist. It's been updated. If it doesn't work with > iOS8 it's because it's likely not been reverse engineered upstream yet. I'm unable to connect my iPad with iOS 8.0.2; When I connect it I get the error:Unhandled Lockdown error (-16); and a SELinux says something about usbmuxd.
This is what SELinux informes: SELinux is preventing /usr/sbin/usbmuxd from using the chown capability. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that usbmuxd should have the chown capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep usbmuxd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:usbmuxd_t:s0 Target Context system_u:system_r:usbmuxd_t:s0 Target Objects [ capability ] Source usbmuxd Source Path /usr/sbin/usbmuxd Port <Unknown> Host i5447 Source RPM Packages usbmuxd-1.0.9-0.6.c24463e.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-183.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name i5447 Platform Linux i5447 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 Alert Count 5 First Seen 2014-10-07 10:55:10 BRT Last Seen 2014-10-07 11:19:20 BRT Local ID 21dcc7fc-ccb7-4f62-90c7-adf55e48d60d Raw Audit Messages type=AVC msg=audit(1412691560.506:394): avc: denied { chown } for pid=3410 comm="usbmuxd" capability=0 scontext=system_u:system_r:usbmuxd_t:s0 tcontext=system_u:system_r:usbmuxd_t:s0 tclass=capability permissive=0 type=SYSCALL msg=audit(1412691560.506:394): arch=x86_64 syscall=chown success=no exit=EPERM a0=1285290 a1=71 a2=71 a3=0 items=0 ppid=1 pid=3410 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=usbmuxd exe=/usr/sbin/usbmuxd subj=system_u:system_r:usbmuxd_t:s0 key=(null) Hash: usbmuxd,usbmuxd_t,usbmuxd_t,capability,chown