[00:03] <hggdh> this specific bug can be marked as triaged; there is nothing else we can do here
[00:05] <hggdh> sccman: in this case, the bug went to triaged/wishlist
[00:07] <hggdh> sccman: also, please do not hesitate is asking here if you have doubts on triaging
[00:08] <hggdh> sccman: and yes, we need people to help :-)
[01:03] <sccman> How do you mark bug reports as Wishlist?
[01:04] <rbasak> Not everyone has permission to set the Importance field for what are I hope obvious reasons :)
[01:04] <rbasak> If you need something changing and can't do it yourself, please ask here.
[01:04] <sccman> What "obvious reasons" are those?
[01:05] <sccman> :)
[01:05] <rbasak> Otherwise everything would end up Critical, since to a bug reporter his or her bug is always Critical.
[01:05] <sccman> Oh. Makes sense.
[01:06] <sccman> Unless you prevent people from marking Critical.
[01:06] <rbasak> Then all bugs would end up High :)
[01:06] <sccman> But it's up to the makers lol
[01:07] <rbasak> This is the right place to ask for privileged bug status changes. We're always looking for more volunteers to help. If you show that you understand how to set the privilege fields, we'd be happy to give you permission to do that directly.
[01:07] <sccman> True.
[01:07] <sccman> Where would you say you guys need the help with the most?
[01:14] <rbasak> Good question. I'm not sure.
[01:14] <rbasak> Everything :)
[01:14] <rbasak> I think it's really a case of matching a volunteer's skills (and motivation/interest) to what needs doing
[01:14] <sccman> There's no job that's in real demand in Ubuntu?
[01:14] <sccman> I mean in particular that is.
[01:14] <sccman> Like if you work for a company and they say they're "desperate" for X personnell?
[01:14] <rbasak> The bug database is a massive list of what users would like us to be doing :)
[01:14] <sccman> Fair enough.
[01:15] <sccman> The users are the customers after all lol
[01:16] <rbasak> Ubuntu isn't a single entity with a single direction.
[01:17] <rbasak> *Canonical* have goals, but they hire employees for what they need.
[01:17] <sccman> Right.
[01:18] <rbasak> But Ubuntu itself does whatever the project participants want to do, except when those goals are in conflict (which is rare).
[01:18] <sccman> I see.
[01:18] <rbasak> Of course everyone wants an Ubuntu developer to appear to fix *their* bug.
[01:19] <rbasak> I don't mean that in a bad way. It's pretty much tautological.
[01:19] <rbasak> And separate from bugs, there are features. Right now we want people to work on snaps for third party projects. That's a big area of focus for Canonical right now.
[01:20] <sccman> Every user wants their problems fixed with computers. Even Microsoft and Apple lol
[01:20] <sccman> They want the computer to fix their lives like magic.
[01:20] <rbasak> Because snaps solve a bunch of problems for Ubuntu users, and we have a solution for it.
[01:20] <sccman> What are snaps?
[01:20] <rbasak> https://snapcraft.io/
[01:21] <rbasak> It solves the problem of packaging software outside a distribution.
[01:21] <rbasak> Eg. if you're a software vendor and you want to ship some software directly to Ubuntu users.
[01:22] <rbasak> Or if you're an Ubuntu user and you want to try some cool new software that didn't ship with Ubuntu because it didn't exist at the time, and you want to try it out without risking destabilising your system or risking security.
[01:23] <sccman> How is that different from the package manager?
[01:23] <sccman> Like apt and pacman?
[01:24] <rbasak> apt package repositories must be tightly integrated with each other in order to work.
[01:24] <rbasak> It's difficult for a third party to provide a package from outside the distribution with the required level of integration.
[01:25] <rbasak> Separately, users trust the distribution repository because everything in it has been vetted by the distribution.
[01:25] <rbasak> And you have to trust *something*.
[01:25] <rbasak> Third party packages don't have to pass the same quality requirements, so they can vary wildly in quality.
[01:26] <rbasak> For example some may "call home" and leak user data from your home directory.
[01:26] <rbasak> These things are unacceptable in distributions and so generally get rejected, removed, fixed, etc. as soon as they're spotted.
[01:26] <rbasak> But if you use third party repositories, you have no control over what that repository can do on your system.
[01:27] <rbasak> snaps provide isolation and confinement so you can safely install a snap on your system without having to worry about this.
[01:27] <rbasak> (the just-published hardware vulnerability aside)
[01:30] <sccman> Isn't it just another third-party respository?
[01:30] <sccman> I'm not trying to bash snapcraft, I'm only trying to understand.
[01:33] <sccman> Maybe a better question would be...how does it offer more control over what a repository does?
[01:33] <rbasak> Snaps come from third parties, yes. But snapd, the (sort of) package manager that runs on your system, runs package contents "confined". As well as just installing something on your system, it also manages the rnning of it.
[01:33] <sccman> It sounds like it has heavy security in it.
[01:33] <rbasak> "Confined" means that when the process is run, it doesn't have access to a bunch of things unless it is given that access.
[01:33] <rbasak> Right
[01:34] <rbasak> For example, if I install and run a snap, it can't just stream video from my webcam.
[01:34] <rbasak> But a program installed by apt can.
[01:34] <rbasak> With snaps, I have to explictly connect that interface for it to be able to do it.
[01:34] <rbasak> A bit like permissions on Android apps.
[01:35] <rbasak> This makes third party snap repositories "safe" when compared to third party apt repositories.
[01:35] <sccman> Hmm
[01:37] <sccman> It sounds like it's a third-party repository, but yet it's not. Almost like it's apt-get but with a little more liberal security standards.
[01:37] <sccman> For a lack of a better term.
[01:40] <rbasak> Instead of vetting taking place at the point the package is included in the distribution, the vetting takes place at the time the program is run on a user's system.
[01:40] <rbasak> This removes the need for manual vetting.
[01:40] <rbasak> In contrast, a third party apt repository receives no vetting.
[01:41] <sccman> Oh okay.
[01:42] <sccman> And I'm sure it would give developers more flexibility so they don't have to meet Ubuntu's strict standards.
[01:43] <sccman> They won't be restricted as much by Ubuntu's standards in their features.
[01:50] <rbasak> Right
[01:51] <sccman1> How would you describe the users of snapcraft?
[01:53] <sccman> Sorry been messing with pidgin lol
[01:57] <sccman1> How would you describe the users of snapcraft?
[02:05] <rbasak> I'm not sure I understand the question.
[02:08] <sccman> Well it's obviously solving a group of people's problems, otherwise nobody would use it :)
[02:11] <sccman> All published software will, at the end of the day, be used by its users. However not all users will use the software. Linux for example is typically used for people who are more tech-savvy versus Windows and Mac's audience is more geared towards everyday non-technical users.
[02:11] <sccman> versus Windows' and Mac's audience will gear toward*
[02:13] <sccman> In marketing there's typically a target group of people that you gear your products to. I was wondering if you happen to have any insight on that :)
[02:13] <sccman> Maybe if you overheard.
[02:43] <hggdh> sccman: I will give you an example: I use pycharm (from jetbrains.com). Up to nowish, pycharm was distrivuted as a tgz (compressed tarball). Now they offer a snap for it
[02:44] <hggdh> and I jumped over to the pycharm snap... now I do not have to worry about updating it, and I can (theoretically) install it on any Linux distro that supports snap
[02:44] <hggdh> Now... I am waiting for CLion to be snapped as well, then I am happy :-)
[02:55] <rbasak> For a long time, third parties have shipped software to Ubuntu users by hacking something together.
[02:55] <rbasak> All PPAs and third party apt repositories are fundamentally a hack.
[02:56] <rbasak> The target, IMHO, should be to have snaps replace all of those.
[02:59] <hggdh> +1
[18:19] <padv> Can somebody please close LP: #776376 this package has been deleted in artful on 2017-07-28 by Steve Langasek (From Debian) ROM; no longer used; Debian bug #863235 and Ubuntu 11.04 is no longer supported
[18:19] <ubot5> Launchpad bug 776376 in libgnuinet-java (Ubuntu) "package libgnuinet-java 1.1.1-4 failed to install/upgrade: subprocess dpkg-deb --control returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/776376
[18:19] <ubot5> Debian bug 863235 in ftp.debian.org "RM: libgnuinet-java -- ROM; no longer used" [Normal,Open] http://bugs.debian.org/863235
[18:24] <rbasak> padv: I don't just want to change a bug status without an explanation. Could you write the reason into the bug, please?
[18:29] <padv> rbasak: I added the reason into the bug report and was able to mark it Fix Released (did know I could do that)
[18:29] <padv> rbasak: Thanks for your help
[18:29] <padv> rbasak: s/did/didn't
[18:30] <hggdh> it is actually not fix released, if the package was dropped. Invalid would be better
[18:30] <hggdh> padv: and yes, you can move to fix released. You just cannot move it out of it
[18:31] <padv> hggdh: sorry can you change to Invalid
[18:32] <rbasak> I don't like Invalid, because that suggests it was Invalid at the time it was filed, which isn't necessarily true.
[18:32] <rbasak> We usually set Won't Fix for EOL bug reports.
[18:32] <rbasak> So I did that.
[18:32] <hggdh> rbasak: cool, and I agree
[18:32] <padv> rbasak: Thanks!
[18:32] <rbasak> Though in this case I think it's quite clearly a system issue rather than a bug.
[18:33] <padv> hggdh: Thanks for agreeing
[18:33] <rbasak> But to explain that, and apologise for telling them now rather than at the time of the report when it would be useful, is quite an essay to write :-/