[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
Can confirm the fix works here too. Compute jumps to 100%, but system remains fully usable and the process moves on slowly. Thanks again for your help, Aaron. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
> 100% usage of Render/3D means copy, vpp or display are stuck, The issue is certainly related to the 100% render/compute, but this looks like a symptom and a consequence rather than a cause. > since multiple inputs are set, could it work when encoding a single input each time? Yeah, there are several ways to workaround it. But to be clear, the concern here is not that ffmpeg is slow, but rather that whatever is happening is taking the entire system down instead of gracefully degrading. Even keyboard input stops working. > Maybe there is an unsupported video format input by Intel GPU decoder/encoder. No, the input/output encoding/decoding is fine. It's using H265/HEVC, well supported by the chip. I've done some more testing and bisected the problem to the following, with left.mp4 and right.mp4 being 4K videos. This works fine, with Video fluctuating beteween 20 and 30%, Render close to zero: ``` ffmpeg -y \ -vaapi_device /dev/dri/renderD128 \ -hwaccel vaapi -hwaccel_output_format vaapi -i left.mp4 \ -hwaccel vaapi -hwaccel_output_format vaapi -i right.mp4 \ -filter_complex " [0:v]hwdownload,format=nv12,copy[v0]; [1:v]hwdownload,format=nv12,copy[v1]; [v0][v1]hstack=shortest=true,format=nv12,hwupload[out]; " \ -c:v hevc_vaapi -map "[out]" slowtest.mp4 ``` This causes the issue, with Render at 100%, Video at 0%, system unresponsive: ``` fmpeg -y \ -vaapi_device /dev/dri/renderD128 \ -hwaccel vaapi -hwaccel_output_format vaapi -i left.mp4 \ -hwaccel vaapi -hwaccel_output_format vaapi -i right.mp4 \ -filter_complex " [0:v]hwdownload,format=nv12,copy,format=nv12,hwupload[v0]; [1:v]hwdownload,format=nv12,copy,format=nv12,hwupload[v1]; [v0][v1]hstack_vaapi=shortest=true[out]; " \ -c:v hevc_vaapi -map "[out]" out.mp4 ``` The key difference between these two pipelines is whether hstack happens in the GPU or the CPU. When it works, two frames are downloaded from the GPU, stacked together, and the merged frame is then re-uploaded for encoding. When it breaks, the two frames are uploaded individually and stacked in the GPU instead. The problem may be related to the amount of memory used in the GPU, since when the stacking happens in the GPU there is twice as much data. Even then, instead of degrading, the system came down to a halt with the GPU misbehaving, keyboard interrupts going wild, etc. Anything else I can do to help diagnose why that's the case or whether we can address it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
Thanks for the reply, Aaron. The dmesg.log file is already attached above. Your ffmpeg example is on the simple side compared to the pipeline that creates the issue for me, where ffmpeg has multiple inputs and a pipeline that touches both the GPU and the CPU. For simple things it works okay here as well. intel_gpu_top spikes to 100% on both Render/3D and Compute with very brief interruptions, probably while it moves the frame for processing by the CPU. Blitter, Video, and VideoEnhance remains at 0%. /proc/cpuinfo shows CPU comfortably alternating between 400MHz and 4GHz, apparently with plenty to spare and confirming the previous output provided by iostat and top in the original report above. sensors output shows the temperature for all CPUs comfortably under 70 degrees at all times, with almost all of them under 60. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
** Description changed: I've been using a Lenovo X12 Detachable Gen 2 model from 2024 [1] to encode some video files with ffmpeg, and the system becomes completely unresponsive for as long as the process executes. Although small, this is a pretty good device hardware wise, and while executing the system has plenty of RAM (32GB total, 10GB+ left), almost all CPUs are idle, no IO wait. [1] Intel Core Ultra 164U variant at: https://psref.lenovo.com/syspool/Sys/PDF/Think_Tablets/ThinkPad_X12_Detachable_Gen_2/ThinkPad_X12_Detachable_Gen_2_Spec.pdf Things I've tried: 1) Lowering the priority of ffmpeg with renice 2) Lowering the priority of ffmpeg with ionice - 3) Switching to the lowlatency kernel, with all recommended fiddling - 4) Using a single thread in ffmpeg + 3) Using a single thread in ffmpeg + 4) Switching to the lowlatency kernel, with all recommended fiddling + 5) Switching to the OEM kernel (6.8.0-1010-oem) Nothing even touches the complete lack of responsiveness. The system becomes so unresponsive that when typing nothing shows up, and then characters show repeated as long sequences all at once. In addition to the attached information, some details about the moment the problem happens: top - 16:27:49 up 3:26, 1 user, load average: 1.13, 0.70, 0.68 Tasks: 397 total, 1 running, 396 sleeping, 0 stopped, 0 zombie - %Cpu0 : 2.7 us, 0.0 sy, 0.0 ni, 56.3 id, 41.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu1 : 3.3 us, 0.3 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu2 : 3.0 us, 0.0 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu3 : 0.7 us, 1.0 sy, 6.3 ni, 2.7 id, 89.3 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu4 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu5 : 4.0 us, 0.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu6 : 3.3 us, 0.0 sy, 0.0 ni, 96.3 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu7 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu8 : 4.3 us, 0.0 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu9 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu10 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu11 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu12 : 3.0 us, 0.3 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - %Cpu13 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st - MiB Mem : 31537.6 total, 9596.6 free, 9784.3 used, 15292.1 buff/cache - MiB Swap: 8192.0 total, 8192.0 free, 0.0 used. 21753.3 avail Mem + %Cpu0 : 2.7 us, 0.0 sy, 0.0 ni, 56.3 id, 41.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu1 : 3.3 us, 0.3 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu2 : 3.0 us, 0.0 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu3 : 0.7 us, 1.0 sy, 6.3 ni, 2.7 id, 89.3 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu4 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu5 : 4.0 us, 0.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu6 : 3.3 us, 0.0 sy, 0.0 ni, 96.3 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu7 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu8 : 4.3 us, 0.0 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu9 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu10 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu11 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu12 : 3.0 us, 0.3 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + %Cpu13 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st + MiB Mem : 31537.6 total, 9596.6 free, 9784.3 used, 15292.1 buff/cache + MiB Swap: 8192.0 total, 8192.0 free, 0.0 used. 21753.3 avail Mem - - Linux 6.8.0-39-lowlatency (x12) 08/08/2024 _x86_64_(14 CPU) + Linux 6.8.0-39-lowlatency (x12) 08/08/2024 _x86_64_ + (14 CPU) avg-cpu: %user %nice %system %iowait %steal %idle -2.870.040.267.480.00 89.35 + 2.870.040.267.480.00 89.35 - - It may also be worth mentioning, the ffmpeg process is using hardware encoding/decoding. - + It may also be worth mentioning, the ffmpeg process is using hardware + encoding/decoding. Thanks for any help on this. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-39-lowlatency 6.8.0-39.39.1 ProcVersionSignature: Ubuntu 6.8.0-39.39.1-lowlatency 6.8.8 Uname: Linux 6.8.0-39-lowlatency x86_64 ApportVersion: 2.28.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Aug 8 17:23:32 2024 Install
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
** Also affects: linux-signed (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-signed (Ubuntu) Assignee: (unassigned) => Andy Whitcroft (apw) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] [NEW] Lenovo X12 Detachable Gen 2 unresponsive under light load
Public bug reported: I've been using a Lenovo X12 Detachable Gen 2 model from 2024 [1] to encode some video files with ffmpeg, and the system becomes completely unresponsive for as long as the process executes. Although small, this is a pretty good device hardware wise, and while executing the system has plenty of RAM (32GB total, 10GB+ left), almost all CPUs are idle, no IO wait. [1] Intel Core Ultra 164U variant at: https://psref.lenovo.com/syspool/Sys/PDF/Think_Tablets/ThinkPad_X12_Detachable_Gen_2/ThinkPad_X12_Detachable_Gen_2_Spec.pdf Things I've tried: 1) Lowering the priority of ffmpeg with renice 2) Lowering the priority of ffmpeg with ionice 3) Switching to the lowlatency kernel, with all recommended fiddling 4) Using a single thread in ffmpeg Nothing even touches the complete lack of responsiveness. The system becomes so unresponsive that when typing nothing shows up, and then characters show repeated as long sequences all at once. In addition to the attached information, some details about the moment the problem happens: top - 16:27:49 up 3:26, 1 user, load average: 1.13, 0.70, 0.68 Tasks: 397 total, 1 running, 396 sleeping, 0 stopped, 0 zombie %Cpu0 : 2.7 us, 0.0 sy, 0.0 ni, 56.3 id, 41.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 3.3 us, 0.3 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 3.0 us, 0.0 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 0.7 us, 1.0 sy, 6.3 ni, 2.7 id, 89.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu4 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu5 : 4.0 us, 0.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu6 : 3.3 us, 0.0 sy, 0.0 ni, 96.3 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu7 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu8 : 4.3 us, 0.0 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu9 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu10 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu11 : 3.7 us, 0.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu12 : 3.0 us, 0.3 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu13 : 4.0 us, 0.0 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 31537.6 total, 9596.6 free, 9784.3 used, 15292.1 buff/cache MiB Swap: 8192.0 total, 8192.0 free, 0.0 used. 21753.3 avail Mem Linux 6.8.0-39-lowlatency (x12) 08/08/2024 _x86_64_(14 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2.870.040.267.480.00 89.35 It may also be worth mentioning, the ffmpeg process is using hardware encoding/decoding. Thanks for any help on this. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-39-lowlatency 6.8.0-39.39.1 ProcVersionSignature: Ubuntu 6.8.0-39.39.1-lowlatency 6.8.8 Uname: Linux 6.8.0-39-lowlatency x86_64 ApportVersion: 2.28.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Aug 8 17:23:32 2024 InstallationDate: Installed on 2024-06-25 (44 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) SourcePackage: linux-signed-lowlatency UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-signed-lowlatency (Ubuntu) Importance: Undecided Assignee: Andy Whitcroft (apw) Status: New ** Tags: amd64 apport-bug noble wayland-session ** Attachment added: "uname-a.log" https://bugs.launchpad.net/bugs/2076361/+attachment/5803830/+files/uname-a.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
** Attachment added: "lspci-vvnn.log" https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803836/+files/lspci-vvnn.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
** Attachment added: "dmesg.log" https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803835/+files/dmesg.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2076361] Re: Lenovo X12 Detachable Gen 2 unresponsive under light load
** Attachment added: "version.log" https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+attachment/5803834/+files/version.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076361 Title: Lenovo X12 Detachable Gen 2 unresponsive under light load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency/+bug/2076361/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> How do you have "many more" voices to pay attention to? 1018 people have marked We have millions of users, Avamander. > "I'm sorry you chose to feel insulted Your words. Now I'll stop here and hope that we can go back to being productive on this issue. Failing that, we'll lock this thread up so we can all focus on the project development. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
The way we select priorities for the project every single cycle for years is having several stakeholders (that's more than a dozen people, covering community, customers, development groups, etc) with several different perspectives in a room after having followed a process of funneling requirements from these same groups over several weeks. We then have a long discussion to agree on what are the most important priorities for the project for the coming cycle, and then a fantastic development team works on these features for the next several months, often doing minor adjustments to the roadmap as the cycle progresses and we have new factors coming in. I realize that sitting here in a bug for 4 years waiting for your pet peeve to be fixed may be unsettling and frustrating, but hopefully the interactions from the team in the history above are good data to show that we've been around all along and did intend to improve things eventually. Not in your preferred timeline, unfortunately, but we have many more issues and voices to pay attention to. That's why you see https://snapcraft.io/store and the snap project and community being what they are today. Because we do care, and we do follow a process that is not just hand-picking issues arbitrarily. I'm sorry that you prefer to remove the application and vote yourself out of this community, but this is a freedom we also appreciate around here. We're glad you can make yourself comfortable with other tools. We'll stay here, improving things meanwhile. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
This is a place for respectful collaboration about the project and the issue at hand. People in the community are most welcome to participate and help, and many have done exactly that. Insults and blaming are not welcome here or anywhere else in this community, though, no matter how much you care about it. If we're unable to talk about the actual issue here due to this kind of behavior, we'll lock it down and move the conversation elsewhere. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> a ridiculously mismanaged and misprioritized project So you create an account just to come here say that? Indeed we have different a notion of priorities and time allocation, David. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Zygmunt, let's stick to the design and the spec only. Speculation or subjective remarks do not help the conversation. Avamander, your personal notion of fault attribution won't help you or anyone else. There's a lot of people here. Let's please preserve this thread relevant and respectful. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Hi Seth, >From recent conversations with the team, the approach has been discussed and we have an agreement on it, we should now see a design document made public in the next few weeks (september still, hopefully), which means an implementation available in the next few months. So we'll see it as part of the snapd release that will be in 21.04. We need to get it into one of the testing channels well before that, as this is a critical path that needs proper testing before being in a release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Right, I spent my time explaining the design and trationale that got us here, and in which direction we'll improve it. It seemed much more interesting for everyone. > WE are whining about it annoyingly. You are the one saying that. It is a hot topic for several reasons, but most people in this thread have been very reasonable. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Folks, we said multiple times above that this is in the roadmap and there's on going work to get it addressed. We'll be posting more details about the actual change soon, and it's not just a rename. > The community and it's voice matters - ignoring it will just cause people to not support Ubuntu. At this point you are the one ignoring what others are saying. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
If not having a ~/snap in your home is more important than what the entire snap ecosystem provides, then removing it indeed sounds like the right choice. With that said, we've been working on this issue and Zygmunt says so above quite clearly, because we care, and always did. But we can only care about so many things at a time, and there are literally millions of people using this system and many of them are making requests that we also care about. Thanks for your contribution to the topic, Robin. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> The dev team made it clear that for them it has no priority and from their point of view it is no bug and does not belong here. I actually stated something else way back above. We care, and we'll fix it. It's not as straightforward as it sounds, though, and indeed there were higher priorities. It's okay to disagree with our priorities, though.. it's easy to have an opinion on this, harder to make everyone happy all the time. > I have voiced my concerns directly to Ubuntu support last week We already have some good ideas for how we want that feature to shape up, and I'm hoping we can have something in the next cycle after 20.04 is fully baked. I don't do priorities alone, though, so that's not a promise. Feel free to reach out to me directly in the forum or online elsewhere if you're interested. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813365] Re: Local privilege escalation via snapd socket
Thanks for the clarification, Chris. We're in complete agreement. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813365 Title: Local privilege escalation via snapd socket To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1813365/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813365] Re: Local privilege escalation via snapd socket
Chris, I've just read your blog post at: https://shenaniganslabs.io/2019/02/13/Dirty-Sock.html There you install a snap in devmode, which does a bunch of things to demonstrate that the snap can access system resources via the vulnerability in <2.37. Just for the record, it's slightly undue to claim that the snap is exploiting the system in that scenario, because a snap in devmode already has full access to the system anyway. No need for any exploits. If you install a snap in devmode, you gave root to the snap: --devmode Put snap in development mode and disable security confinement If the snap was installed without devmode, it wouldn't not have access to the socket. Again, thanks for the report. Just wanted to clarify this point. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813365 Title: Local privilege escalation via snapd socket To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1813365/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1814640] Re: snap info showing "unset" license for snaps
The behavior of snapd seems correct, in the sense different revisions of the snap may have different licenses. "Rectifying" a license in a way that future information affect past code seems very bogus in this context. With that said, we might have a special case for "unset". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1814640 Title: snap info showing "unset" license for snaps To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1814640/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
The fix for one snap or ten thousand is exactly the same, as we're addressing this inside snapd proper. No snaps will need to change. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Viktoria, We have been working non-stop on snapd over those three years, including features that will improve the situation for this folder. The fact it is marked as Wishlist reflects more on the fact nothing is in fact broken, other than you and me would both like to have a nicer folder structure. The fact this bug has the most heat also reflects on how easy it is to have an opinion about it (https://en.wikipedia.org/wiki/Law_of_triviality). Don't get me wrong, though. We will do better here for sure. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Hi Carl, This is likely what we will do indeed, as it's a nice partner to the other standard options already there, is language-agnostic, and thus easier to handle on the confinement sense. We'll also clean it up a bit on the way, by stashing the non-current revisions in a better place. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1768625] Re: Bluetooth headset HSP/HFP mode not working in Bionic
The issue is most probably that your headset implements the HFP profile, but not the HSP profile, and pulseaudio does not yet support the HFP profile despite what that line says (HSP/HFP). To confirm, run bluetoothctl, and type something like: > devices (...) > info 11:22:33:44:55:66 Where the address is the one for your headset. It will likely display something like this: UUID: Audio Sink(110b--1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb) UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb) UUID: Handsfree (111e--1000-8000-00805f9b34fb) If so, the "Headset" (HSP) profile is missing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1768625 Title: Bluetooth headset HSP/HFP mode not working in Bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1768625/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> This is by design so not easy to fix if at all possible at this stage It is by design, but as I said the solution not only is possible, but is elegant, and is almost done. The foundations of snapshots is done and is landing (https://github.com/snapcore/snapd/pull/5955). In the coming weeks, we'll make that foundation automatically create a snapshot when a snap is removed. Proper man page support is also in the roadmap. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
The picture might not be completely clear if you haven't been watching, so let me help: - We have snaps by default in Ubuntu for years now - There are thousands of snaps published - There are more than 100 thousand snap installs per day - There are more than 3 million new snap installs a month - They are being used in 40+ Linux distributions - The developers that do snaps also worked on Synaptic, APT, APT-RPM, RPM, etc Improvements and features are constantly landing, and many more are coming, but this is as production as it gets. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Snapshots, which is mostly finished by now, will allow keeping data past the removal of the snap itself. That said, it will only hold the data saved for some time. The design applied there is a trade off between leaving data behind forever, and risking removing data unintendedly as you reported. Support for man pages shipped inside snaps is in the roadmap. Bash completion works and should work automatically, though. If it doesn't please file a bug for it if you have the time. It's just a shame you feel the need to be harsh instead of collaborating towards getting your problems fixed. Ubuntu was always developed in an iterative process, and with the collaboration of the community, and snapd is no different. We're very proud of where we got so far, yet there are many improvements and features to come still. That will happen with or without you, but it's always better to work together. Have fun and take it easy, no matter where you go. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> having a directory not hidden with a fixed name in the home directory is not a common practice. The vast majority of Ubuntu users in the desktop have directories named similar to "Video", "Pictures", "Documents", "Downloads", "Music", etc there, which means that in fact this is a common practice, and a very well established one at that. Claiming otherwise, and repeatedly so, washes out the better arguments. The better argument is that yes, the snap directory is a bit different, because it deals with confinement of applications that cannot write elsewhere, and yes it currently uses a technical organization that is unlike other cases for that same reason, and yes, this organization is not optimal for users which is why this issue is still open and not closed, and yes, we also want to improve it, and yes we have been working in other priorities non-stop for years now because we felt these were more important for the survival of the project. > Also, I would appreciate it if we could keep this focused on the discussion, and not the person. I would actually appreciate if sometimes there was some consideration of the fact there are reasonable people on the other side. Have a great day everyone, and sorry for the noise in your inboxes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
> I believe this is a very incorrect line of argumentation. Your position is "others have done it too". This is not an excuse. Also they have done it differently. This whole thread is about consistency and common practices, Ivàn. Consistency and common practices for the placement of a single directory. No matter how passioned you are about this subject, that's still what it is. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
That's not the only concern, Zygmunt. We also need to design what we'll move towards when it actually happens. As was detailed much earlier in this thread, there are considerations about both the kind of content that is inside those directories (which isn't something that typically goes hidden), and also in terms of what we'll move towards if we're not hiding it. There is another feature in development as well that will make it easier for applications to safely read/write content anywhere else. If that works well, it will influence the direction we go here. So, once more, we're aware that this is an important personal preference issue to some of you, but please realize that creating directories in $HOME for user content isn't novel, and if you're using the Ubuntu desktop you do have other entries there which were automatically created already. We understand the desire of being able to change that directory somewhere else, but for reasons there were outlined earlier (e.g. confinement), this isn't as straightforward as it sounds. It's also quite obviously not a priority for us either given everything else we're doing right now on this project. Trust me when I say we would like to see this improved as well. The difference is that we're even more keen on seeing other major features landing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
We listen, even to harsh comments like that one. I'm sorry that we cannot implement the exact changes you want on the exact time frames you want. Rest assured we are working hard on this project, though, and for years now we've been landing major improments like clock work. There are actually some very exciting changes coming in the following weeks, if you haven't been watching. About traction, well.. just look at how many people come here to complain about a directory not being in their preferred location and you might extrapolate a bit. ;-) More details about the solution and issues related to this directory name were provided in earlier comments above. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1791814] Re: [2.35.1] /v2/interfaces returns "system" instead of "core" as owning snap of core interface slots
Hi Eric, Thanks for the call yesterday. Similar to other cases we covered yesterday, and unlike stated above, the translation of the alias in "snap get system" to "snap get core" is actually made inside the daemon, so there shouldn't be any difference in results, whether via the command line or via the API. The following excerpt is a plain copy & paste from my terminal just now: [niemeyer@nomad ../snapcore/snapd]% sudo curl -s --unix-socket /run/snapd.socket http:/v2/snaps/system/conf | sha1sum d3f0bde1349f24893cc64573a6706f0065abb505 - [niemeyer@nomad ../snapcore/snapd]% sudo curl -s --unix-socket /run/snapd.socket http:/v2/snaps/core/conf | sha1sum d3f0bde1349f24893cc64573a6706f0065abb505 We share the values you raised, and we try hard not to make incompatible changes, whether in a minor or not (releasing breaking changes often is a pain, even if clearly labeled as such). An example where we've failed to do that, though, is the result of the /v2/interfaces API. It will indeed return an alias where before it would not, so this is a potential breaking change that we should have been more careful about, and per the conversation yesterday we'll be happy to revert if it becomes necessary. Ironically, precisely because we share the values of respect for greater API stability, we won't revert this change unless it is necessary, because our most recent stable release now presents that behavior already, and it's out there for a while. So reverting the change means modifying the behavior in a stable release, and that needs to be carefully considered among the other options. That's why in our call yesterday I explicitly asked what is the current impact of that change, and you said the issue is under control and reverting it won't bring a direct benefit to you. That's again confirmed above. So unless we receive further feedback indicating the pros of reverting outweigh the cons, my recommendation is for the change to remain in. As always, we remain available for further discussing this specific issue, the concept of API stability in general, and testing approaches to mitigate such issues in the future. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1791814 Title: [2.35.1] /v2/interfaces returns "system" instead of "core" as owning snap of core interface slots To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1791814/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1779948] Re: Snapd gets stuck when starting Ubuntu.
Woonjas, if you're having an issue, it's probably not this one as the problem was found and fixed. Can you please open a separate bug, and include the same details requested above for your machine, so we can investigate in more detail? Thank you. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1779948 Title: Snapd gets stuck when starting Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1779948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
For the record, the epoch feature is being actively worked on and it's not that far hopefully. You can track progress in the forum: https://forum.snapcraft.io/t/epochs-stepped-upgrades/1757/57 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1607067] Re: Add a dotfiles / hidden files interface
There's some further discussion about the topic of this PR here: https://forum.snapcraft.io/t/access-to-specific-hidden-file-path-in- users-home/6948/8 Josh, we're are researching about a way to solve problems similar to the ones you describe. It's still not ready for prime time, but I believe we should be able to address that. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1607067 Title: Add a dotfiles / hidden files interface To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1607067/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1746710] Re: Snap creates redundant duplicate directories in home folder
Sergio, see comment from Seb above. It's the launcher, and rebuilding apparently solves the problem. We won't pack the launcher in snapd. If you have some more information about why that's still a bug in snapd, then please talk to us or provide good details about why the affected applications above will be solved by a change in snapd, and what that change is. ** Changed in: snapd (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1746710 Title: Snap creates redundant duplicate directories in home folder To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1746710/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1533899] Re: Add support for proxies
This is supposed to work indeed, even outside of Ubuntu Core. It's also documented: https://snapdocs.labix.org/configuration-options/87 (this will go into snapcraft.io/docs soon) I'm going to close this issue for now. Please reopen if I'm missing something. ** Changed in: snapd (Ubuntu) Status: Triaged => Fix Released ** Changed in: snapd (Ubuntu Trusty) Status: New => Fix Released ** Changed in: snappy Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1533899 Title: Add support for proxies To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1533899/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1779948] Re: Snapd gets stuck when starting Ubuntu.
The problem here is lack of entropy in the kernel. A CVE was reported in the kernel related to low entropy, and the modification prevented the data from going out. Unfortunately that means any programs at early boot that attempted to obtain a few bytes of random data would get stuck, potentially for several minutes. That's of course unreasonable, so the patch in the kernel has since been reverted. In the snapd end we've also modified the particular logic that used the random data to use a different strategy, since the entropy was not important for the particular use we had for the data at play. So this should be fixed on both ends by now: the kernel was reverted, and snapd won't get blocked if that happens elsewhere. So an update should guarantee that you won't observe this anymore. ** Changed in: snapd (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1779948 Title: Snapd gets stuck when starting Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1779948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
It can be translated. It's software.. everything _can_ be done. It's just more complex, and not necessarily the best idea given potential options. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Hi Krisztian, There's no test here. Those are just user data files which need to be exposed, whether you're young or not. That said, your general sense is right: we want those exposed, and nicely so. You're also hitting the right points when you raise symlink and confinement issues. That's part of why we cannot just rename the directory overnight, and why it's an even larger issue when you account for translations. But we'll definitely improve it further, in multiple ways. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
Hi Tony, Stepping up on a culture pedestal and looking down on others is pretty unhealthy, even more if you do that blindly. As was repeated many times in this thread, the files inside ~/snap must *not* be hidden. Those are going to be music files, documents, pictures, which strict snaps want to make available. That's not content that should go unperceived no matter how your culture looks like. It's also instructive to consider history in this context. Hidden directories as they are known today were not supposed to be hidden in the first place. The original intention was preventing "." and ".." from being seen, but the assembly logic was miscoded, and the bug was abused until it was too late. So we are in good grounds both culturally and historically, yet we've been repeatedly saying we *do want* to improve the situation even further, and have on going work for that. If that sounds unreasonable to you still, we'd likely be unable to please no matter what. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
It's not even just that. Part of the confusion here is that people think this is content that should be hidden, but it's really not. This is closer to "~/Documents" than it is to "~/.config". The directories under ~/snap hold the $HOME for snaps. They are the place strict snaps can write to, unless they have a home interface. That's the real reason why it wasn't originally cooked under ~/.something. Per earlier notes, we are working on a richer mechanism, and once that lands we'll review the situation again. Meanwhile, apologies for the directory not having the name some of you would like to have. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
The snap infrastructure is used in production by us and many of our customers, and we also regularly hear about success stories from the community. So in that sense, yes it's production quality, today. That said, Ubuntu will not replace all debs by snaps. These are complementary technologies, and the rare replacements are special cases that had specific discussions behind them. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1730159] Re: Snapd should not start if there are no Snaps installed
It's way too late for that behavior right now. Many features expect snapd to be live to work. Seeding happens the first time snapd runs, which means a new system will by default start without any snaps installed. The data for command-not-found is acquired by snapd while running as well. We also cannot trivially start and then stop because there's no obvious control point for when snapd is done doing what needs to get done. So, yeah, we can look for good solutions for this problem, but changing the behavior now would be reckless in terms of stability. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1730159 Title: Snapd should not start if there are no Snaps installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1730159/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1758211] Re: snap 2.31.2 broke almost all my snaps
*** This bug is a duplicate of bug 1756793 *** https://bugs.launchpad.net/bugs/1756793 Sorry for the trouble, James. A reboot is the most trivial workaround, and the fix is being released. We got bitten by a misbehavior in systemd, which got hidden due to lack of testing for double updates (update, and update again on itself). Here are the details: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1756793 ** This bug has been marked a duplicate of bug 1756793 Can't run snaps on Ubuntu 18.04 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758211 Title: snap 2.31.2 broke almost all my snaps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1758211/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1756793] Re: Can't run snaps on Ubuntu 18.04
Hi Colin, We discussed in the sprint two weeks ago how we could prevent this from happening again. Part of the problem here is that this only shows up in a multi-stage upgrade, because it's a misbehavior of systemd that was triggered on the prerm script. So normal upgrade tests do not catch it. We need to test upgrading *out* of the given release instead. So install the *new* snapd, do changes to the system by installing snaps, reinstall the *new* snapd on top of the existing ones, and play with the system. We'll look into implementing this. That said, as usual regression tests catch regressions. They don't catch new and creative ways in which the system can break. So the true answer is that nothing can prevent this from happening again, unfortunately. We can just continue to work on making the risks ever smaller. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1756793 Title: Can't run snaps on Ubuntu 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1756793/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1756793] Re: Can't run snaps on Ubuntu 18.04
There are two recent issues in 18.04 that we're aware about. For one of them, the most trivial fix is to reboot the system. It's a problem in systemd ignoring a Condition on the snap.mount being inside a container and stopping the snap.mount unit, which chains into unmounting all snaps during the prerm which exists inside the previous deb. Fixes for both of these problems are in the process of being rolled out. We apologize for the trouble. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1756793 Title: Can't run snaps on Ubuntu 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1756793/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1749777] Re: Syntax tweaks for snap-friendly output
Yeah, we spent a lot of time trying to make the output both compact and
showing command lines. The problem is that once you have more than a few
options, it gets wild and unfriendly as a dump of information after a
typo.
That said, I think we can improve these headings indeed. The output I
see above ("foo can be found") disagrees with what we discussed, and
what is in the top proposal in this ticket. We need to improve this. The
+ vs * also looks like a typo.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749777
Title:
Syntax tweaks for snap-friendly output
To manage notifications about this bug go to:
https://bugs.launchpad.net/command-not-found/+bug/1749777/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move the "$HOME/snap" directory to a less obtrusive location
No worries, Joel Teixeira, we'll still be here if you need us, working on developing modern package management for Linux, and hopefully making it good enough that people will be excited to use despite the name of a directory not being their preferred one. In fact, we can definitely work allowing a per-user configuration setting so everyone can tune the name to their own preference. If you're doing that, it means you know where to find the data, and so we don't need to be worried that important information is tucked away in an obscure location. If there's enough support for that, we can put it in the roadmap for sooner rather than later. That will actually help even for when we do the actual transition into the hidden directory, as it means we could keep existing directories untouched so we don't break anything and people don't get confused by data moving. Yeah, that sounds like a good idea. Will provide more details about the plan in this forum topic: https://forum.snapcraft.io/t/change-home-snap-to-snap/1827 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move the "$HOME/snap" directory to a less obtrusive location To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575053] Re: Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to "$HOME/.local/share/snap" in accordance with the XDG spec)
This is the second hottest bug because it's very easy to have an opinion about it without any strings attached. As I believe was explained multiple times above the real reason this is not "hidden" is that snap/ is not just a configuration directory. This is where the writable space for all snaps live. For them to be able to write anywhere else they need interfaces that would allow them to do so. As a trivial example, this is content I have in my snap/ directory right now: $ ls ~/snap/telegram-desktop/current/Downloads/* VID-20180204-WA0007.mp4 VID-20180214-WA0008.mp4 Hiding this directory has an important unintended consequence which I'm sure you won't like either: it encourages packagers to use less strict confinement. For that specific reason, we won't change that just yet. Instead, we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place. Meanwhile, apologies for the inconvenience. ** Changed in: snapd Status: Confirmed => Won't Fix ** Changed in: snapd (Ubuntu) Status: Confirmed => Opinion ** Changed in: snapd Status: Won't Fix => Opinion ** Changed in: snapd Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575053 Title: Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to "$HOME/.local/share/snap" in accordance with the XDG spec) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1585403] Re: please support parallel operation
Per conversation on IRC: I think it can be closed 18:44:34 snapd indeed operates closer to make -j than it does to apt or deb in that regard Those really serialize all steps of the installation, while snapd goes wild and only rejects known conflicts as you pointed out pedronis make -j also doesn't parallelize _everything_ either.. just the things it knows are independent.. so vaguely resembling snapd's behavior indeed ** Changed in: snapd (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1585403 Title: please support parallel operation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1585403/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1662552] Re: snaps don't work with NFS home
It's in master now. ** Changed in: snapd Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1662552 Title: snaps don't work with NFS home To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1662552/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1504657] Re: ntp servers should be configurable on snappy
Discussing here: https://forum.snapcraft.io/t/allow-disabling-system-services-on-ubuntu- core/531/2 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1504657 Title: ntp servers should be configurable on snappy To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1504657/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663060] Re: Add a title field to snap metadata
*** This bug is a duplicate of bug 169 *** https://bugs.launchpad.net/bugs/169 We just got a bug report saying gnome-software is actually showing summaries as a title: https://forum.snapcraft.io/t/title-summary-pulled-from/469 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663060 Title: Add a title field to snap metadata To manage notifications about this bug go to: https://bugs.launchpad.net/developer-portal/+bug/1663060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1674509] Re: Unable to find bluetooth device on RPi3 running Ubuntu Core 16
Jamie's suggestion seems spot on for the time being. This is really something for the gadget to expose, and it should be made in an explicit way. It can be a regular expression as suggested because then you cannot assign a particular snap plug to a particular serial port anymore. The upcoming hot-plugging feature will take care of making the process less bothersome, which I think is your concern there, Oliver. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1674509 Title: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1674509/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1674509] Re: Unable to find bluetooth device on RPi3 running Ubuntu Core 16
Sorry, it CANNOT be a regular expression. I wish Launchpad allowed edits. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1674509 Title: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1674509/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1677417] Re: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system
Sorry, by "there" I mean in the forum Zyga mentioned above. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1677417 Title: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1677417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1677417] Re: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system
The bug is really in the snap. It shouldn't be doing that. I've provided a longer rationale and a fix proposal there, where we have more eyes watching. I would like to close this bug as "Invalid". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1677417 Title: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1677417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1665102] Re: Snap refresh not working as expected on devmode snaps
The current behavior was the precise outcome of a very long conversation we (Mark and I) had in Heidelberg, about the subtle properties of such updates. We agreed to block devmode => strict refreshes because we could not get a clear agreement on what was the proper way to treat those updates. Specifically, on refreshes that go from a snap that proposes devmode to one that proposes strict should it: 1. Refresh and keep the devmode flag on or 2. Refresh and disable the devmode flag I believe the more natural semantic is (1), given the flag meaning (development mode), while Mark would like to have behavior (2), taking the flag off. Behavior (2) doesn't seem sensible to me because it's an automatic and transparent change behind the developer's back which is changing the behavior of said snap for no apparent reason. It would also cause the strange effect that a devmode snap can be updated to strict, but cannot be updated _through_ strict (devmode => strict => devmode), even though the developer explicitly said this snap was in development mode before. So, if we go with 1, sounds good to me. If the idea is 2, then I'd prefer to keep the current behavior as we originally discussed in Heidelberg. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1665102 Title: Snap refresh not working as expected on devmode snaps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
Sounds good. We'll add something along those lines to the API. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663060] Re: Add a title field to snap metadata
If gnome-software is using summary as a name, it needs to be fixed to not do that, ASAP. Whether to have a different field is an unrelated conversation which is of less urgency than that. We have a name field today, and it should be used. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663060 Title: Add a title field to snap metadata To manage notifications about this bug go to: https://bugs.launchpad.net/developer-portal/+bug/1663060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663060] Re: Add a title field to snap metadata
Yes, but the discussion above also implies that we have multiple naming
fields, and that gnome-software is currently using summary as it
("Currently gnome-software is using sumary or name instead of this
field.").
We should discuss the possibility of another field, per above note, but
let's please not use a summary as a display name meanwhile. This will
encourage people to put wrong data in the wrong field.
In terms of the proposal itself, would be good to have a conversation
about it considering the pros and cons. If we allow a free form name, we
may end up with multiple applications named exactly the same thing (for
above example, imagine 10 different "Calculator" applications). How much
better is this than having a single "calculator" application? Our whole
apt/deb story circles around applications with unique and well-defined
lowercased names. What are the benefits of breaking that?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1663060
Title:
Add a title field to snap metadata
To manage notifications about this bug go to:
https://bugs.launchpad.net/developer-portal/+bug/1663060/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
@Mark: The command is not duplicated. The desktop file will call the actual command defined in the snap.yaml. It may provide additional arguments, but those will indeed be _in addition_ to the ones in snap.yaml. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
More food for thought on the above note: the desktop file cannot call the real underlying command by itself! That would break confinement. It calls the confined binary under /snap/bin instead, which is what the "command:" attribute specifies. So, necessarily respected. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
Another side note: there's no special meaning to the order of commands in snap.yaml. We can reorder it, and snapcraft can reorder it, so please don't take it to mean something specific as that'll easily break. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
Robert: what do you actually need here? We already support multiple desktop files, and they already hold metadata. gnome-software can already inspect to see which of these is available, I believe? What are the missing pieces? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663060] Re: Add a title field to snap metadata
The bug description is misleading. There's a single name field in snaps today, and its called "name". Summary is not a name, and description is not a name. If gnome-software or anything else is using "summary" as a name, that's a pretty obvious bug that would be great to see fixed. We can discuss the introduction of an alternative name field which is free-form and not unique, but that's a separate conversation. Proper applications supporting the snap format shouldn't mangle snap names, and shouldn't misuse fields for incorrect purposes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663060 Title: Add a title field to snap metadata To manage notifications about this bug go to: https://bugs.launchpad.net/developer-portal/+bug/1663060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1661590] Re: GNOME Software only supports running one application from a snap
Every application may already have an associated desktop file under meta/gui/.desktop today. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661590 Title: GNOME Software only supports running one application from a snap To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1661590/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1581713] Re: Ubuntu Software always asks for an Ubuntu Single Sign-On account when installing or removing a snap package
As we discussed the last time this came up, yes, that seems fine. Handing out a token to root that provides an authorization to manipulate the system is analogous to allowing root itself to be doing removals without further store information, which we allow. The necessary infrastructure for that is pretty much in place since we already have to maintain the local and remote macaroons separately, and the situation where the remote macaroon is missing or incorrect is already handled. If a store operation depends on a valid user, it will prompt for a full login, and once performed that will associate the remote macaroon with the existing local user instead of creating a new one. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1581713 Title: Ubuntu Software always asks for an Ubuntu Single Sign-On account when installing or removing a snap package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-gnome/+bug/1581713/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1662603] Re: snap refresh hang during download
Almost all of the logged messages are unrelated to snapd. Can you please show "snap changes" and then "snap change" on the latest refresh operation? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1662603 Title: snap refresh hang during download To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1662603] Re: snap refresh hang during download
Indeed. We need a way to distinguish between lack of purchase and other reasons for lack of access rights. Along similar lines, would be great to be able to distinguish between real not found (bogus endpoint) and semantic content not found (unknown snap). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1662603 Title: snap refresh hang during download To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1636934] Re: snapctl seem to cache values even if snap is removed and then installed again
We should just clear config up from the state when the last revision from the snap is going away. That needs to be done in a careful way to take undoing into account. Eventually we should actually migrate to a model where configuration is keyed by (snap, revision) instead of simply (snap), so that reverts work properly. But that's a separate issue besides the need to clear configuration up on removals. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1636934 Title: snapctl seem to cache values even if snap is removed and then installed again To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1636934/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1624322] Re: console-conf wlan race on pi3
** Changed in: snappy Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1624322 Title: console-conf wlan race on pi3 To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1624322/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
If it never stops growing, it's obviously a leak.. somewhere! If it stabilizes after a while, then it's a side effect of Go being a non- deterministic garbage collected language. Again, data. If the goal is testing this particular code path, it'd be best to have a tiny test case exercising it, rather than doing something like "snap find". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
@Colin, Sorry if it sounds different, but this is not a wish of mine. It's just about respecting the data we have. Not even Valgrind itself is reporting this as a leak. It's saying "block possibly lost". Unless we have either very basic empirical evidence of a leak (e.g. offending code alone in a loop grows the process larger), or someone that disagrees with the assessment I've made above reading the code, we shouldn't regard this as a leak. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
Once more, unless we have evidence showing otherwise, there were no leaks before either. Let's please stop pretending otherwise. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
@Colin, That's what I understood previously, but thanks for confirming it. The question was whether you had digged further to see whether that warning made any sense, or whether you had any further data confirming the leak to be real. I'll take your response as a no, which is fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
Did you did into that problem? I don't see the potential leak looking at the function. All of the arguments other than *ThreadStart are allocated in the stack, and ts is freed on threadentry which is the function provided as the start_routine parameter of pthread_create. What is the actual issue reported? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
@Colin, Sure it definitely needs to be improved. As I said above, this is just a cheap way to get us going, and the proper fix is a transactional storage on disk. @Mark, Yes, we can prune based on number of changes as well. It's not expensive. That's a good trick to get us going farther. @John, 2MB / (10 tasks * 180 changes) is in the ballpark of 1kb per task. That's not unrealistic I think. Also worth noting it's not just plain data.. there will be a small amount of additional garbage created per entry when processing it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
As mentioned above, unsuccessful changes are aborted after a few days, and pruned thereafter. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
Btw, there's a "snap changes" command you can see which changes currently exist. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1642068] Re: snapd memory sizes grows huge over time
If you install/remove on a loop, this will create changes which are kept in memory until they are pruned. This happens in the period of three days for successful ones, and a week for unsuccessful ones (which are aborted, and later pruned). Eventually we'll need to move to a model where this data is kept on disk with proper transactional control around it, but for now this is a cheap way for us to get going. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1642068 Title: snapd memory sizes grows huge over time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1642068/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1640514] Re: /snap/bin is not added to the PATH when using zsh
Indeed. The right fix is probably a trivial change in /etc/zsh/zshenv. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1640514 Title: /snap/bin is not added to the PATH when using zsh To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1640514/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1630145] Re: out of disk space needs better handling
Let's please keep the original topic as handling space issues in snapd needs to be improved indeed. If there's a specific request about ubuntu-image, this needs another bug. ** Summary changed: - ubuntu-image should add the regular 5% reserved space for root when creating filesystem for /writable + out of disk space needs better handling -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1630145 Title: out of disk space needs better handling To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1630145/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1635228] Re: Increase number of loopback devices
About where the notion came from, I've heard about this potential problem pretty much since we considered using the current mount-based model of snaps. Sounds like there's a wide belief that there is such a limit, perhaps backed by actual reality: http://askubuntu.com/questions/499131/how-to-use-more-than-255-loop- devices https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec- Configuring_the_Loopback_Device_Limit.html etc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1635228 Title: Increase number of loopback devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1635228/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1635228] Re: Increase number of loopback devices
Thank you very much for the test. I heard this morning that the limit was 256 based on an error on a test yesterday, but it must be something else then. I'll go back and ask for more details. ** Changed in: linux (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1635228 Title: Increase number of loopback devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1635228/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1635228] [NEW] Increase number of loopback devices
Public bug reported: Hello, As discussed today in the sprint in The Hague, the number of available loopback devices limits the number of snaps that may be installed on a given system. Would it be possible to increase the number of loopback devices to at least 4096 or 8192, so that we can increase the number of snaps that may be installed? Thank you. ** Affects: linux (Ubuntu) Importance: Undecided Status: Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1635228 Title: Increase number of loopback devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1635228/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1612783] Re: snapd requires U1 account to install local packages
The Ubuntu Software team is already working on an alternative for that. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1612783 Title: snapd requires U1 account to install local packages To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1612783/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1592088] Re: snap command doesn't finish when snapd already gave up
This symptom is fixed in the current master code (and likely in the latest SRU that is going in now). The umount will happen synchronously even if there are still processes alive. That said, please note that the old behavior was not as bad as it sounds from the description. The snapd daemon is not stuck due to the original removal being stopped, and CTRL-C will correctly not force it to simply abort midway through. Instead, snapd will keep track of the pending work and retry every few minutes by itself, attempting to complete the work that was requested and partially done. ** Changed in: snapd (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1592088 Title: snap command doesn't finish when snapd already gave up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592088/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1586400] Re: Snap type: change from "os" to "core"
We are doing a last minute push to get "ubuntu-core" renamed to "core", so that the images going out on RTM have the logic in place for testing, but this is unrelated to the topic here. This specific bug is simply about having the "core" snap with the "core" type, and this transition needs to be done without breaking current snaps out there. So yes, the build system needs to change to generate "core" snaps with the "core" type, but that's not urgent as snapd cannot refuse to take a "os" type snap any time soon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1586400 Title: Snap type: change from "os" to "core" To manage notifications about this bug go to: https://bugs.launchpad.net/click-reviewers-tools/+bug/1586400/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1586400] Re: Snap type: change from "os" to "core"
We went back and forth on this issue a bit, but I believe the latest agreement is actually that we want snaps of type "core" indeed. There's no reason to keep the inconsistency of naming something "os" internally when everything else refers to those as "core". We'll need to support snaps with the old "os" type for quite a while as these are out there, but I'd like to deprecate them sooner rather than later, and refer to these as "core" consistently. Also, we've agreed that "personal" will actually be built on the same "core" snap, as that's going to be much nicer to work with and maintain. ** Changed in: click-reviewers-tools Status: Invalid => Confirmed ** Changed in: snapcraft Status: Invalid => Confirmed ** Changed in: snapd (Ubuntu) Status: Invalid => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1586400 Title: Snap type: change from "os" to "core" To manage notifications about this bug go to: https://bugs.launchpad.net/click-reviewers-tools/+bug/1586400/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1606212] Re: getpwuid is failing on classic image
It is only a serious problem if we find a serious bug about it. Meanwhile it's an inconvenience which we should try to fix when the cost-benefit pays off. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1606212 Title: getpwuid is failing on classic image To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1606212] Re: getpwuid is failing on classic image
Apparently the message indicates this is about uid 0, which would hint at it being unrelated to user id mapping. On a quick search, this issue covers the same problem: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/649917 with the relevant comment from Evan Broder: Apparently an /etc/passwd file isn't sufficient - you actually need a nsswitch.conf file and libnss_files for getpwid_r to return something useful. Updated patch attached. I've tested it locally and confirmed that it suppresses the GLib warning, and the new version has been pushed to my PPA for test building and one of the fixes https://launchpadlibrarian.net/58336075/plymouth_0.8.2-2ubuntu6.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1606212 Title: getpwuid is failing on classic image To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1603018] Re: snap create-user gets bad username
** Changed in: snapd (Ubuntu) Status: New => Fix Committed ** Changed in: snappy Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1603018 Title: snap create-user gets bad username To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1603018/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1600260] Re: Support paravirtualization
Also virtio_net, virtio_blk, virtio_pci.. these are builtin in the standard Ubuntu images, so probably also builtin there? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1600260 Title: Support paravirtualization To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1600260/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1600260] Re: Support paravirtualization
virtio_scsi is the obvious one. Not sure if there's anything else necessary. Might be a good idea to catch up with the cloud image maintainers and ask. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1600260 Title: Support paravirtualization To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1600260/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1599783] Re: snapd is dead and panic when trying to start
This is not just UX. There's an actual panic in doDisconnect. No UX issue should result in a panic. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1599783 Title: snapd is dead and panic when trying to start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599783/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1593213] Re: snap install --channel=beta not working when snap already installed
You don't need to remove the snap. Just use "refresh" instead. We need to improve the error message. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1593213 Title: snap install --channel=beta not working when snap already installed To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1593213/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
