> 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
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
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
> 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.
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.
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
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
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.
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
> 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.
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
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
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
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:
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
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
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
> 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,
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
-
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.
> 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
> 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
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),
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
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
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
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
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
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
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)
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
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
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
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
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,
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
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
*** 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
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.
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
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
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
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
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
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
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
*** 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
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
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
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
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
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.
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
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
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
@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
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
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
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
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
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
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
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.
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
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
** 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:
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,
@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
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
@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
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
@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,
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
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
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
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
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
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:
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
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
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
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
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
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
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.
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
** 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
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
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.
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
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
Note that the unlike the bug description states, snapcraft.io is
correct.
It mentions refresh explicitly, and only talks about the install option
when the goal is to install it new.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here it goes:
ii unity 7.4.0+16.04.20160526.1-0 amd64
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1597390
Title:
Screen unlocked on external monitor plugged?
To manage notifications about
There's no time in most lines in that file unfortunately, but this might
be it:
WARN 2016-06-28 20:36:08 nux.inputmethod.ibus InputMethodIBus.cpp:67
Impossible to connect to connect to ibus
[2378:2411:0629/100015:ERROR:connection_factory_impl.cc(367)] Failed to connect
to MCS endpoint with
Public bug reported:
This morning I experienced an interaction which left me a bit concerned.
I took a sleeping laptop to the office, opened it, and the usual login
dialog came up. I then plugged in an external monitor, and it unlocked.
Anybody experienced something similar recently?
Looking
As we discussed today on the channel, we should give a try at using
attributes to produce the final interface we want here. This is
supported for some time, and really not too much work compared making
the interface global.
I suggest something like this (whitespaces => underlines to make
No, please see the discussion above.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1585806
Title:
snap remove while in /snap/foo/current/... not robust
To manage notifications about this bug go
That's a very good point, Jamie. Let me sleep over that, please, to
ponder whether there's something else entirely that we could do.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1590679
Title:
If it's a blank check, I don't see many advantages over asking for
unity7 itself. Once we want to force the declaration, we can just
introduce the actual interface.
Might also be a good thing because unity7 will eventually be deprecated,
and we might use that timeframe to deprecate the general
We already do that today for existing interfaces. But I wonder if we
should open up a slightly wider door for name registration on the
session bus specifically (IOW, not system session, not communication),
so that applications can run even if they don't bother about interfaces.
This would unblock
1 - 100 of 242 matches
Mail list logo
