[Touch-packages] [Bug 1164016] Re: restore type-ahead find
I don't know how long it will take, but in the meantime Ubuntu could ship the patch maintained by the Arch community: https://aur.archlinux.org/cgit/aur.git/tree/nautilus-restore- typeahead.patch?h=nautilus-typeahead It looks like this patch is kept up to date pretty well. There is a similar patch for gtk3 to make the file chooser dialog have type-ahead. It's the best of both worlds, since you can still tap ctrl-f to search. Whilst it would be nice for the Nautilus devs to upstream the patch or for there to be a dialog about what kind of patch they might accept (if any), in the meantime distros can include the patch, there is little downside since the patch is maintained and not bit rotting. Canonical would not be committing themselves to maintaining it by including it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/1164016 Title: restore type-ahead find Status in Nautilus: Expired Status in nautilus package in Ubuntu: Fix Released Status in ubuntu-settings package in Ubuntu: Fix Released Bug description: GNOME removed type-ahead find in Nautilus 3.6, not without controversy: https://mail.gnome.org/archives/nautilus- list/2012-August/msg2.html Now when you type in a Nautilus window, Nautilus immediately performs a search in the current directory and all its subdirectories. I personally find this annoying. If I want to search, I'll click the search icon. Often I'm looking at a long directory listing and simply want to jump to a certain point in it, and type-ahead find works great for that. Would Ubuntu consider patching type-ahead find back in? To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1164016/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1164016] Re: restore type-ahead find
I don't think it's true that an option is always good. I think software should endeavour to have decent default options, and if multiple use cases can be accommodated without an option, then that is preferable. But you're right, a recursive search with ctrl-f vs typeahaed with simple typing would accomplish what everyone wants without an option. I'm using the 'search in current folder only' setting in order to make the search more like typeahead, but this has the downside that I have to go into the settings to do an actual recursive search. In reality, recursive search is useful, and I want to use it, but it's different to typeahead and it's a shame I have to pick one or the other. Ideally for me would be typing is just going to select things similarly to the old typeahead behaviour, and ctrl-f would do a search, either in the current folder or recursively depending on a checkbox that would ideally be in the main interface next to the search box rather than in the settings menu - since one often wants one or the other, it's not really an all-time preference. I do think things will eventually go back this way. There is currently wasted effort trying to make search meet the requirements of type-ahead, whereas this would be unnecessary if typeahead existed too. Search is becoming a bit of a frankenstein trying to be both, with returning items from the current folder first, and having the search-in-current-folder- only setting being global. It should just be search - features should do one thing each instead of trying to please everyone. I understand that search has been improved a lot in response to complaints about type-ahead being removed, and this shows that the devs are trying to meet people's use cases. But ultimately I think it is misguided and making the search implementation more complex than it otherwise would need to be. They are really are different features. So I know there has been a lot of vitriol over this issue, but I would encourage the nautilus devs to consider that they should become different features once again. Ctrl-f to search will not confuse anybody, type-ahead will not confuse anybody, whereas the current search is trying to be both and so can behave unexpectedly in terms of the order of search results and whether the search is recursive. Presumably this means code complexity too. I also understand that the old type-ahead code was holding back the codebase and so it was desirable to excise it. I imagine new typeahead functionality, working as much as possible within the current codebase and its future directions, would be more amenable to nautilus dev approval than just restoring the old code. For example, we probably don't need the popup box in the bottom right as you type. It should just be type a few characters and have a few-second timeout before forgetting them, just like it is on other platforms such as windows and macos (I think). It seems similar to me to the case or removing nautilus handling the desktop. The code was holding back the codebase, but now we see that a desktop extension for gnome-shell is in development by the main nautilus dev. I do think Nautilus can satisfy everyone's preferences here, and I do think typeahead will eventually be re implemented once tensions die down, especially if the nautilus devs can do it on their terms instead of rejecting a patch that just re-adds code that they don't want to maintain. A good typeahead implementation would even allow Nautilus to remove code that customises how the search works to make it more useful as typeahead - there would no longer be a need for that if typeahead were present in its own right. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/1164016 Title: restore type-ahead find Status in Nautilus: Expired Status in nautilus package in Ubuntu: Fix Released Status in ubuntu-settings package in Ubuntu: Fix Released Bug description: GNOME removed type-ahead find in Nautilus 3.6, not without controversy: https://mail.gnome.org/archives/nautilus- list/2012-August/msg2.html Now when you type in a Nautilus window, Nautilus immediately performs a search in the current directory and all its subdirectories. I personally find this annoying. If I want to search, I'll click the search icon. Often I'm looking at a long directory listing and simply want to jump to a certain point in it, and type-ahead find works great for that. Would Ubuntu consider patching type-ahead find back in? To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1164016/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1747711] Re: file mis-identifies modern executables as application/x-sharedlib
Has this been fixed upstream? Looking at the changelog, there has been a
related change, but I'm not sure if it resolves the issue yet, it now
says they're both executables.
https://github.com/file/file/blob/219846094c7593e27453e62855e61181089c48cf/ChangeLog
file 5.3.3:
python3.6: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.4.0, with debug_info, not stripped
libpython3.6m.so.1.0: ELF 64-bit LSB pie executable x86-64, version 1
(SYSV), dynamically linked, with debug_info, not stripped
file 5.3.2:
python3.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.4.0, with debug_info, not stripped
libpython3.6m.so.1.0: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked, with debug_info, not stripped
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to file in Ubuntu.
https://bugs.launchpad.net/bugs/1747711
Title:
file mis-identifies modern executables as application/x-sharedlib
Status in file package in Ubuntu:
Confirmed
Bug description:
file doesn't recognize modern PIE (Position Independent Executable)
x86 executables as such, reporting them as “application/x-sharedlib”.
Consequently, only non-PIE executables can be opened in graphical file
managers such as nautilus. This may cause a minor (?) security risk if
a commonly-published workaround is attempted.
Expected behaviour:
$ echo "int main() { return 0; }" > foo.c
$ gcc -o foo foo.c
$ file foo
foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
$ file --mime-type foo
foo: application/x-executable
Actual behaviour:
$ echo "int main() { return 0; }" > foo.c
$ gcc -o foo foo.c
$ file foo
foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
$ file --mime-type foo
foo: application/x-sharedlib
Workaround (unsafe?):
$ echo "int main() { return 0; }" > foo.c
$ gcc -o foo-nopie foo.c -no-pie
$ file foo-nopie
foo-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, BuildID[sha1]=3eb8c581f43c19997e3c828f5a9730dbdc794470, not stripped
$ file --mime-type foo-nopie
foo-nopie: application/x-executable
gcc now defaults to building with PIE enabled for security reasons.
Also affects: nautilus (and likely other graphical file managers like
those on Lubuntu) - because nautilus uses mime-type to determine if a
file is executable, double-click to run a program no longer works.
Also noted on: Gnome Bugs -
https://bugzilla.gnome.org/show_bug.cgi?id=737849 (2014) - before PIE
became the default build option.
This may be an upstream issue. This may not affect architectures
outside x86.*
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: file 1:5.32-1
ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
Uname: Linux 4.13.0-32-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Feb 6 11:21:20 2018
InstallationDate: Installed on 2017-05-11 (270 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: file
UpgradeStatus: Upgraded to artful on 2017-10-21 (108 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 655835] Re: avahi-daemon consumes 100% CPU time after a period of networked Desktop use
Still present in 18.04 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/655835 Title: avahi-daemon consumes 100% CPU time after a period of networked Desktop use Status in avahi package in Ubuntu: Confirmed Bug description: On Ubuntu 10.10 Release candidate, after using the machine for some time, the avahi-daemon consistently jumps to 100% CPU usage. It is a networked machine but I haven't made any extensive tests whether this problem also occurs when offline. avahi-daemon: 0.6.27-2ubuntu3 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: avahi-daemon 0.6.27-2ubuntu3 ProcVersionSignature: Ubuntu 2.6.35-22.33-generic-pae 2.6.35.4 Uname: Linux 2.6.35-22-generic-pae i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Wed Oct 6 12:40:32 2010 InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate i386 (20100928) ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: avahi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/655835/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1721537] Re: No sound from headphone jack on xps13 9350 after ubuntu 17.10 dist-upgrade
This problem seems to be the same as in the following two Ubuntu stackexchange posts: https://askubuntu.com/questions/768463/laptop-headphone-jack-produces-no-sound https://askubuntu.com/questions/219342/no-sound-output-from-headphone-jack-ubuntu12-04/859931 A temporary solution mentioned in those threads is: alsactl restore which fixes the problem for me. Might be a problem with Dell hardware specifically - a few comments mention Dell models. In any case it doesn't seem like a new problem since the two stackexchange posts are from 2016 and 2012. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1721537 Title: No sound from headphone jack on xps13 9350 after ubuntu 17.10 dist- upgrade Status in alsa-driver package in Ubuntu: Confirmed Bug description: I just upgraded from 17.04 to 17.10 on my Dell XPS13 9350. Ever since my headphone jack doesn't output anything. The internal speakers are still working fine, the speakers I connect to the laptop too (tested with my phone). The system does recognize the speakers being connected, since I get the Headpones | Headset | Microphone popup and I can also test left/right speakers in Sound. However, no audio is coming through. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 ApportVersion: 2.20.7-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: rienheuver 1426 F pulseaudio CurrentDesktop: GNOME Date: Thu Oct 5 14:41:11 2017 InstallationDate: Installed on 2016-11-22 (316 days ago) InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Release amd64 (20161012.1) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Black Headphone Out, Front Symptom_Type: No sound at all Title: [XPS 13 9350, Realtek ALC3246, Black Headphone Out, Front] No sound at all UpgradeStatus: Upgraded to artful on 2017-10-05 (0 days ago) dmi.bios.date: 12/18/2015 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.9 dmi.board.name: 07TYC2 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.1.9:bd12/18/2015:svnDellInc.:pnXPS139350:pvr:rvnDellInc.:rn07TYC2:rvrA01:cvnDellInc.:ct9:cvr: dmi.product.name: XPS 13 9350 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1721537/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1721537] Re: No sound from headphone jack on xps13 9350 after ubuntu 17.10 dist-upgrade
I am also having this problem on a Dell Precision 5520 (which is similar hardware to both the Dell XPS 15 and Dell XPS 13). Headphone output worked initially since install and then stopped working mid-session after unplugging and re-plugging the headphones. I was adjusting the "Alert volume" setting in sound settings at the time, which may or may not be relevant. Reebooting, unplugging and replugging, etc, nothing seems to bring it back. I am on Ubuntu 17.10 having installed fresh at the time of Beta 2, and the problem started occurring whilst I was fully updated today. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1721537 Title: No sound from headphone jack on xps13 9350 after ubuntu 17.10 dist- upgrade Status in alsa-driver package in Ubuntu: Confirmed Bug description: I just upgraded from 17.04 to 17.10 on my Dell XPS13 9350. Ever since my headphone jack doesn't output anything. The internal speakers are still working fine, the speakers I connect to the laptop too (tested with my phone). The system does recognize the speakers being connected, since I get the Headpones | Headset | Microphone popup and I can also test left/right speakers in Sound. However, no audio is coming through. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 ApportVersion: 2.20.7-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: rienheuver 1426 F pulseaudio CurrentDesktop: GNOME Date: Thu Oct 5 14:41:11 2017 InstallationDate: Installed on 2016-11-22 (316 days ago) InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Release amd64 (20161012.1) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Black Headphone Out, Front Symptom_Type: No sound at all Title: [XPS 13 9350, Realtek ALC3246, Black Headphone Out, Front] No sound at all UpgradeStatus: Upgraded to artful on 2017-10-05 (0 days ago) dmi.bios.date: 12/18/2015 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.9 dmi.board.name: 07TYC2 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.1.9:bd12/18/2015:svnDellInc.:pnXPS139350:pvr:rvnDellInc.:rn07TYC2:rvrA01:cvnDellInc.:ct9:cvr: dmi.product.name: XPS 13 9350 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1721537/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
