| lotuspsychje | good morning | 03:45 |
|---|---|---|
| ducasse | good morning | 07:19 |
| oerheks | yay, the end of GA? ( google analystics) https://twitter.com/__jakub_g/status/1365400306767581185 | 12:50 |
| oerheks | ( and FB and more..) | 12:50 |
| clarkk | hello lotuspsychje | 13:42 |
| lotuspsychje | clarkk: the snap pages do indeed show publisher vs verified account | 13:43 |
| clarkk | to summarise, what is the green tick next to the developer name in the Ubuntu Software app | 13:43 |
| clarkk | lotuspsychje, at the moment, it's very obscure. It needs some documentation so people can use it | 13:44 |
| lotuspsychje | maybe popey or ogra might know more of that, if they are online atm | 13:44 |
| tomreyn | last time i asked (and pointed out this needs to be documented), which i have to admit is probably 2 years ago by now, i was told there are no fixed criteria which define whether or not something is flagged as verified | 13:52 |
| tomreyn | hopefully this has improved since. | 13:52 |
| ducasse | that sounds useless | 13:54 |
| tomreyn | the user guide at https://snapcraft.io/docs/getting-started mentioned verification ("verified") but does not explain what it means. | 13:54 |
| tomreyn | *mentions | 13:54 |
| ducasse | the word 'verified' implies some effort has been taken | 13:54 |
| tomreyn | relevant past context https://forum.snapcraft.io/t/bogus-apps-in-store/4703 https://ubuntu.com/blog/trust-and-security-in-the-snap-store | 13:54 |
| lotuspsychje | clarkk: ^ | 13:57 |
| tomreyn | https://forum.snapcraft.io/t/how-does-a-snap-publisher-become-verified/19902 is newer | 13:58 |
| tomreyn | (but lack an answer) | 13:58 |
| tomreyn | clarkk: <tomreyn> relevant past context https://forum.snapcraft.io/t/bogus-apps-in-store/4703 https://ubuntu.com/blog/trust-and-security-in-the-snap-store | 13:58 |
| tomreyn | also newer, also without answer https://forum.snapcraft.io/t/verified-developers/2005/6 | 13:59 |
| clarkk | tomreyn, thank you. I'll have a read | 14:00 |
| tomreyn | note there is also #snapcraft - the channel for developers trying to build snaps - which is where you *may* be able to get a current answer to the question | 14:01 |
| tomreyn | apart from the point that it's not clear what "verified" means, there's also the issue that you as a user don't get to choose who you trust, not in a systemic way (you can choose to only install snaps which are tagged verified manually, but there is no preference to only display verified ones). This is equivalent to configuring which apt repositories you'll install software from, in the apt domain (where you can even make choices on a | 14:07 |
| tomreyn | package name or package name pattern through apt preferences). | 14:07 |
| tomreyn | and then there is the issue of delegated trust - you don't get to choose whom you trust, you need to rely on the snap store maintainers to make wise choices for you, and to keep those updated for you, and to take counter measures for you once it turns out a "verified" developer has actually (intentionally or unintentionally) published malicious software. | 14:09 |
| tomreyn | those issues also apply to the apt ecosystem. but there it's somewhat well documented (at least for the main repositories) whom you're trusting and what they promise to deliver. | 14:10 |
| tomreyn | note also that the ubuntu security team does not have a handle on snaps | 14:10 |
| tomreyn | clarkk: ^ more to read, if you care. ;) i'll end the momologue here. | 14:11 |
| ogra | huh ? | 14:11 |
| ogra | where is that from ? | 14:11 |
| tomreyn | my brain | 14:12 |
| ogra | adding any random apt repo means you give the repo owner 100% root access to your machine ... this is never the case for snaps, they only can gain root in their own confined sandbox ever | 14:12 |
| ogra | you can not really compare that | 14:12 |
| tomreyn | i did not compare this aspect, but i agree, that's a positive part of snaps | 14:13 |
| tomreyn | there are up- and downsides | 14:13 |
| ogra | the security team maintains the upload checks for snaps, the whole interface system, does the security review for each single classic snap and a lot more stuff that i forgot | 14:13 |
| ogra | they are *deeply* invloved in snaps | 14:14 |
| tomreyn | oh, so this changed and my info is outdated, i guess | 14:14 |
| ogra | no, thats tha case since day one in 2014 when snaps started | 14:14 |
| tomreyn | what are the "upload checks for snaps"? | 14:14 |
| ogra | in fact the interface system was *designed* by the security team | 14:15 |
| ogra | if you upload a snap it will be held if it uses any overly privileged interface or is classic (i.e. unconfined) | 14:15 |
| ogra | there is an automated check in place | 14:15 |
| clarkk | ogra, essentially, will you install literally any snap without worrying whether it's malicious? If not, what general checks do you do? | 14:16 |
| ogra | i do install any snap because i trust the confinement system ... | 14:16 |
| ogra | but thats a matter of personal taste š | 14:17 |
| tomreyn | i know that seth designed much of the containment, after all it uses apparmor a lot | 14:17 |
| * ogra has to take back the above ... | 14:18 | |
| ogra | ... in fact i do install *any confined* snap without checking the dev | 14:19 |
| ogra | if i install a classic snap i check very well who made it | 14:19 |
| tomreyn | i wasn't aware that unconfined snaps are always reviewed by the security team, but that is one of the many things that should be documented, i think. | 14:19 |
| ogra | it is | 14:19 |
| ogra | https://forum.snapcraft.io/t/process-for-reviewing-classic-confinement-snaps/1460 | 14:20 |
| tomreyn | unlike a few, i don't consider forum posts to be documentation. | 14:20 |
| ogra | well, then you should shift your mind .. | 14:20 |
| ogra | *all* newer ubuntu documentation uses forum posts as input | 14:21 |
| clarkk | how do I know what's a classic snap and what isn't? | 14:21 |
| ogra | (non snap stuff lives on discourse.ubuntu.com ) | 14:22 |
| ogra | clarkk, you can not install it without consent | 14:22 |
| clarkk | that's the only way of knowing? | 14:22 |
| ogra | i admittedly never installed a clssic snap via the UI but i think there is a popup | 14:23 |
| ogra | before it gets installed | 14:23 |
| ogra | on cli you need to explicitly use the --classic snap to the snap install command | 14:23 |
| ogra | else snap will refuse to install it | 14:23 |
| * ogra shakes head | 14:24 | |
| ogra | s/the --classic snap/the --classic switch/ | 14:24 |
| ogra | (too much snap in my fingers today) | 14:24 |
| tomreyn | https://forum.snapcraft.io/t/process-for-reviewing-classic-confinement-snaps/1460 states this about the security teams' involvement: "The technical requirements [for why the snap uses classic confinement, as stated by its developer / publisher,] are gathered in [a] forum post [and] will be reviewed by the security team and/or an architect." | 14:26 |
| ogra | yep | 14:26 |
| tomreyn | iit's not clear wat "an architect is" (who can replace the security team in this task) | 14:27 |
| tomreyn | * "an architect" is | 14:27 |
| ogra | well, ask in the post š | 14:27 |
| tomreyn | also, the way i interpret this is that the security team (or "an architect") reviews the statements made by the developer, not the source code? | 14:28 |
| ogra | i personally havent seen any classic reviews withut security team involvement so i cant really tell | 14:28 |
| tomreyn | so hopefully the review is not limited to reading the statement a developer / publisher has made on whether or not a given snap should be trusted. ;-) | 14:29 |
| ogra | either way, classic snaps are rare ... | 14:29 |
| tomreyn | right, and restricted snaps aren't reviewed by the security team, just run through some automated checks. | 14:30 |
| ogra | which is fine since they can only use guarded access to the host | 14:30 |
| tomreyn | depends on what you consider to be fine, if you can't access the source nor know who the developer really is (other than a nickname) | 14:31 |
| tomreyn | i'm sure they could still do phishing with no system access, and probably more. | 14:32 |
| ogra | well, if you really dis-trust a strict snap, just disconnect its interfaces | 14:32 |
| ogra | not sure what/how they would phish | 14:32 |
| tomreyn | online banking logins, for example. | 14:33 |
| tomreyn | could also do click jacking | 14:33 |
| ogra | how would they phish that ? | 14:33 |
| ogra | (from wheer would such a snap get said info ?) | 14:34 |
| tomreyn | i haven't fully thought through the details, but i donp't see why a malicious snap can't choose to display a banking login form which they user might be led into bbelieving was the proper one. | 14:35 |
| tomreyn | but it's just an example, phishing can have a lot of varieties | 14:35 |
| ogra | disply where ? | 14:35 |
| ogra | or how | 14:35 |
| tomreyn | on screen of the users' computer? | 14:36 |
| ogra | do you mean someone does "snap install my-electron-phishing-app", then launches the app and types in her bank credentials ? | 14:36 |
| ogra | (note that a snap wont have access to your browser ... unless it is classic indeed) | 14:37 |
| tomreyn | i mean someone does "snap install my-confined-something-app", then launches the app and half an hour later this app pops up a login form which prompts the user for their bank credentials. or something completely different. | 14:38 |
| tomreyn | a snap can be a browser, though. or a browser and also an online game. | 14:38 |
| tomreyn | or a phishing app and also a tax declaration software | 14:38 |
| ogra | so you'D not be surprised if your calculator app started asking for your banking passwrod ? | 14:38 |
| tomreyn | sure, i would be, if i knew this was what is happening | 14:39 |
| tomreyn | but most users probably would not | 14:39 |
| ogra | yes, snap can be a browser (i maintain a bunch of electron snaps) but the popup will still be inside that app ... if it opens an additional window the window will still have the icon of the original app etc ... | 14:39 |
| ogra | sure, you definitely *can* create a banking fake app and push it to the store ... | 14:40 |
| ogra | but here the vetted publishers come in ... | 14:40 |
| ogra | i.e. you'd only install a banking app that is actually released by your bank | 14:40 |
| tomreyn | i see potential risks, which some users may fall for. you see ways how those might not apply to some or many users. but you don't gain security by safeguarding a couple users. | 14:40 |
| ogra | right, you can surely still shoot yourself in the foot, even with snaps ... but the risk is a lot lower | 14:41 |
| tomreyn | if you haven't reviewed the source code, you don't know what things, and maybe what other things, a software can choose to (not) do. | 14:41 |
| ogra | (i.e. by installing an unverified banking app an typing in you creds.) | 14:41 |
| ogra | right ... | 14:42 |
| ogra | but it can only do that within the defined bounds the snap system allows | 14:42 |
| tomreyn | for many attacks you don't need more than a way to take user inut and send it to the internet | 14:42 |
| tomreyn | which i assume is still possible with a fully confined snap | 14:43 |
| tomreyn | thanks for the discussion,though, i enjoy it. we probably have gone over much of the relevant points by now. | 14:43 |
| ogra | a confined snap can only do what you permit it to | 14:44 |
| tomreyn | but it comes with default permissions, doesn't it? | 14:45 |
| ogra | indeed such a malicious snap would come with the network interface and the desktop interface | 14:45 |
| ogra | so it could read input thats going to itself n it could send this input to the internet | 14:45 |
| ogra | you as a user can simply disconnect the network interface though | 14:45 |
| ogra | (the snap interface i mean, i'm not referring to "pull the network cable" ... the effect is the same though) | 14:46 |
| ogra | as a user you always have the full control what you allow a snap to access | 14:47 |
| ogra | not different from android or IOS | 14:47 |
| tomreyn | sure, but any malware developer would probably packaghe two applications in one snap. one software that has a legitimate use, probably a copy of some open source software, and another one, which has a malicious purpose. they'd choose the legitimate software so that it makes it reasnable to loosen confinement so that the malicious software can do what it wants / needs to. | 14:47 |
| ogra | sure | 14:47 |
| ogra | that doesnt even need malicious intend ... | 14:48 |
| ogra | we had one case wheer a game dev actually shipped a cryptominer along with his game ... | 14:48 |
| ogra | not because he was evil, bt simply to generate income for himself when people play his game | 14:48 |
| ogra | (which is a legit use case ... prob was that he did nowhere mention that a miner runs while you play) | 14:49 |
| tomreyn | and that this dual purpose was not detected before the snap was published, yes | 14:49 |
| ogra | well, sigle purpose snaps are really rare š | 14:50 |
| tomreyn | let's say "dual use" as in weapons then | 14:50 |
| tomreyn | or weapon parts, which can also be used for mining, or for agriculture | 14:51 |
| ogra | well, his snap didnt actualy do anything evil beyond stealing some cpu cycles while you were gaming | 14:51 |
| ogra | and yes, other snaps can do thsi too ... using memory and cpu (within confinement boundaries) is indeed allowed to every snap | 14:52 |
| tomreyn | that's what you consider evil. to me the existence of reachable crypto miner code in a game is always malicious. different users have different opinions on what is evial and what is tolerable. they should be able to make a choice. | 14:53 |
| ogra | as well as writing to ~/snap/<snapname>/current (and /common) | 14:53 |
| ogra | but thats about it ... | 14:53 |
| ogra | they have the choice to uninstall the game ... | 14:53 |
| ogra | it isnt like that miner does anything to your system apart from occupying some resources while you play | 14:54 |
| ogra | it doesnt encrypt your homedir, doesnt do any harm to your OS or anything (and cant do either) | 14:54 |
| ogra | it is a legit way for developers to make money of their software ... as long as they let the user know about it | 14:55 |
| ogra | (i.e. with a popup that tells you "this game will mine BTC for the creator while you play it") | 14:56 |
| tomreyn | i consider user tracking to be problematic. with snapos, i cannot tell whether it is taking place, and have no means to prevent it from happening (other than firewalling or disconnecting internet, but this will likely break the application). | 14:56 |
| ogra | if you do it secretly, then it is definitely evil and your snap will be removed if someone complains about it | 14:57 |
| tomreyn | yes, the "if someone complains about it" approach is not good enough for me. | 14:57 |
| tomreyn | i know that other app stores work the same way, which is why i don't use them for anything relevant. | 14:58 |
| tomreyn | (i do assume that google and itunes automated verification systems will be more advanced than snap's, though.) | 14:59 |
| ogra | thats a moot point given you can not verify that š | 14:59 |
| ogra | (i'D think it is the other way around š ) | 14:59 |
| ogra | (given that the snap side of things is completel opensource) | 15:00 |
| tomreyn | my main point there is that i've chosen not to trust them, much. and unfortunately that's also why i cannot use snaps, the way the ecosystem is designed now. | 15:01 |
| tomreyn | other users, were they aware of the implacations, which is not happening, might have a similar view on it. | 15:02 |
| ogra | well, snap wont go away ... | 15:02 |
| tomreyn | i very much like the snap technology, just dislike parts of its ecosystem. | 15:03 |
| lotuspsychje | they should have divided it from the start | 15:03 |
| tomreyn | it certainly has its uses (and could be much more useful). | 15:03 |
| lotuspsychje | leave the user the choice | 15:03 |
| ogra | divided ? | 15:03 |
| lotuspsychje | yeah divide apt packages vs snap in the store(s) | 15:04 |
| lotuspsychje | so if a user wants to not use snaps, he can | 15:04 |
| ogra | i dont think so ... that wouldnt be very ubuntu | 15:04 |
| ogra | (one of my main targets in nearly 16y of working on ubuntu is that my nearly 90y old mom does *not* need to know what a snap is š whe opens the sftware store and installs what she needs ...) | 15:06 |
| * tomreyn stepping away, thanks for the discussion, ogra | 15:06 | |
| ogra | enjoy your weekend | 15:06 |
| lotuspsychje | im not against snaps, some are very handy | 15:06 |
| lotuspsychje | but not leaving the user the choice was a bad idea in my opinion | 15:07 |
| ogra | well, what choice exactly ... | 15:07 |
| ogra | you can always sudo apt purge snapd | 15:07 |
| ogra | i dont see where anyone remves choice | 15:08 |
| lotuspsychje | but some snaps are now base of the system right? | 15:08 |
| ogra | in fact i see the exact opposite | 15:08 |
| lotuspsychje | wont you bork the gnome parts after purging snapd? | 15:09 |
| ducasse | i don't use snaps, and i have a perfectly functioning system | 15:09 |
| ducasse | several, actually | 15:09 |
| ogra | i dont think any snaps are mandatory | 15:09 |
| ogra | certain services are only provided as snaps though ... lxd ... or livepatch | 15:09 |
| ogra | but neither of them is mandatory for a default install | 15:10 |
| ducasse | i kind of wish they hadn't made lxd snap only, but i can make do with lxc | 15:10 |
| lotuspsychje | ogra: df -h on a clean ubuntu shows some default snaps | 15:10 |
| ogra | which ones | 15:11 |
| lotuspsychje | themes, core, gnome, snap-store? | 15:11 |
| ogra | core is the snap runtime env ... the gnome snap ships the libs for the store snap | 15:12 |
| ogra | and you can replace the store snap easily with gnome-software | 15:12 |
| ogra | (and alongside remove snapd) | 15:12 |
| ogra | so effectively we added choice š | 15:12 |
| lotuspsychje | so removing snapd wouldnt give issues? | 15:12 |
| ogra | it would remove the store ... so you still need to apt install gnome-software ... but nothing beyond that | 15:13 |
| lotuspsychje | maybe i should test that out on a clean soon | 15:13 |
| ogra | ducasse, well, it saves the lxd team tons of money to not having to maintain 20 distro packages ... and it enables you to have shiny features like being able to run a bunch of different lxd versions in parallel and such š | 15:14 |
| ducasse | true | 15:15 |
| ducasse | i love things like winbox being distributed as a snap, so i don't have to pollute my system with wine etc | 15:15 |
| ogra | yep | 15:16 |
| ducasse | i'll probably add that soon | 15:16 |
| lotuspsychje | yeah some snaps are very handy | 15:16 |
| ogra | snaps shine the most in ubuntu core though ... that we have desktop snaps is a nice side thing, but the real power of snaps lies beyond the desktop | 15:19 |
| lotuspsychje | core is a big octopus right? | 15:19 |
| ducasse | sadly i mainly use desktops these days, since i no longer work | 15:20 |
| ogra | nah, its a shiny little OS to do awesome stuff with š | 15:20 |
| ogra | here is a toy project of mine https://people.canonical.com/~ogra/UC20/pi-mediacenter-appliance/ | 15:20 |
| lotuspsychje | ogra: i mean, its the base of so many other things | 15:20 |
| ogra | yeah | 15:20 |
| lotuspsychje | Maik: maybe something for you^ | 15:21 |
| ogra | it is running big machines in factories, self driving cars ... network switches, APs, digital ADs ec | 15:21 |
| ducasse | that looks like a cool toy for me :) | 15:21 |
| ogra | still not done (i'm waiting for a new interface in snapd to land to finish it) | 15:22 |
| lotuspsychje | ogra: running smooth a bit on the pi? | 15:22 |
| ogra | as fast as libreelec on ym other pi | 15:23 |
| ogra | *my | 15:23 |
| lotuspsychje | neat | 15:23 |
| ogra | (which it will eventually replace) | 15:23 |
| lotuspsychje | i still use my mede8er for years now | 15:23 |
| lotuspsychje | the only thing it doesnt do is x265 | 15:24 |
| ogra | well, there is always ffmpeg š | 15:25 |
| lotuspsychje | ill settle with the regular mkvs | 15:26 |
| Maik | lotuspsychje: not my thing :) | 15:53 |
| clarkk | tomreyn, thanks for expressing a lot of the concerns I had about snaps, not having really had to deal with them before. I am happy about their advantages, and like that they're contained, but still would like to be able to follow the trail back to a snap's long-running OSS project and devs, to satisfy myself that it's legitimate. I get the impression that people familiar with them don't think this is necessary, but I don't really understand | 17:31 |
| clarkk | why it's been made impossible for those who wish to do so. I guess there's no planned solution to this, so I'll just have to accept it | 17:31 |
| tomreyn | clarkk: at this time, it's perfectly possible to run ubuntu desktop or server without having snapd installed. (and that's what i do on the systems i have not yet migrated back to debian, for this and other reasons related to the culture that ubuntu has sadly developed to - in my opinion.) this said, it does not seem certain that snap(d) will continue to be optional or removable in future releases. | 17:49 |
| oerheks | no livepatch without snapd | 17:51 |
| tomreyn | yes, but there are alternatives, and it's not mandatory anyways. | 17:52 |
| ogra | clarkk, most opensource snaps actually ship their snapcraft.yaml (the receipe used to build them) inside the snap package (all snaps that use the auto-build service do this by default unless the developer opted out) ... so you have a full paper trail | 18:08 |
| ogra | i.e.: | 18:10 |
| clarkk | ogra, I'm pretty tech savvy, and I definitely haven't found the "full paper trail | 18:10 |
| ogra | $ find /snap/htop/ -name '*snapcraft.yaml*' | 18:10 |
| ogra | /snap/htop/2069/snap/snapcraft.yaml | 18:10 |
| ogra | /snap/htop/2185/snap/snapcraft.yaml | 18:10 |
| clarkk | I'm still none the wiser | 18:10 |
| clarkk | I'd like to go to a snap in the Ubuntu Software app, click on a link to the repo, and have a look for myself | 18:11 |
| ogra | well, if you open it and rea it thats the full paper trail ... it has the soure tree used to build, shows any patches applied etc | 18:11 |
| clarkk | but there are no links | 18:11 |
| ogra | if the packager added that info you can ... but this is optional | 18:11 |
| clarkk | I think ubuntu need to start setting some standards | 18:12 |
| ogra | snaps have originally been created for IoT,cloud,embedded, robotics, self driving cars etc ... | 18:12 |
| ogra | a lot of that SW is proprietary | 18:12 |
| ogra | only about 2y after they started to exist (and a few weeks before flatpak was actually announced) snapd started to support to run desktop apps | 18:13 |
| ogra | so there is some legacy to support also proprietary stuff | 18:14 |
| clarkk | ok, then they need time to mature. That's fine. But I think it was too early to make it an integral part of Ubuntu | 18:14 |
| clarkk | they definitely have potential, but until that potential is met, it shouldn't be in the release | 18:15 |
| ogra | you mean 6 years is not enough for SW to mature ? | 18:15 |
| clarkk | I'm saying, that it hasn't been thought through from a user perspective | 18:15 |
| ogra | they dont *have a potential* they are used widely in commercial setups, there are whole facroies running ubuntu core to control the machines out there | 18:16 |
| ogra | *factories | 18:16 |
| clarkk | there is no paper trail, unless I physically type in the name on the dev, and try to find their repo | 18:16 |
| clarkk | the dev shouldn't have to use the description of the snap to state the repo | 18:16 |
| ogra | well, the repo likely just has a snapcraft.yaml file anyway ... | 18:16 |
| clarkk | there should be afield for that | 18:16 |
| ogra | pointing to the actual source trees used to build the snap | 18:16 |
| clarkk | that's not trivial | 18:16 |
| clarkk | that repo will have people following, and will have issues | 18:17 |
| clarkk | people can look at the code, and raise issues that can't be deleted | 18:17 |
| clarkk | it all adds to the integrity | 18:17 |
| ogra | well, take a look at https://github.com/ogra1/rkdeveloptool ... | 18:18 |
| clarkk | I agree with tomreyn - a bad actor doesn't need full access to do serious damage. They escalate privileges, or get around the limitations in ways you cannot perceive yet | 18:19 |
| ogra | how exactly do they escalate privileges ? | 18:19 |
| clarkk | just because it hasn't been done so far, doesn't mean it cannot be done | 18:19 |
| clarkk | all I'm asking is for a way to easily check up on the developer and the project. The way that users have been prevented from doing this seems to go against the principles of OSS | 18:21 |
| ogra | well ... snap confinement hooks deeply into the kernel (there are only very few userspace bits) ... if you could actually break out of this you have a far more serious problem already (i.e. a completely broken kernel) | 18:21 |
| ogra | this isnt docker containers | 18:21 |
| clarkk | essentially, what I want is transparency. It's just a shame that ubuntu has decided that this is not important | 18:22 |
| clarkk | *canonical | 18:22 |
| ogra | i just gave you the trail to transparency | 18:22 |
| ogra | this is not at all different from a source deb | 18:23 |
| tomreyn | just to clarify, i wasn't discussing privilege escalation, rather potential social engineering vectors involved in running untrusted / untrustable software | 18:23 |
| clarkk | tomreyn, true, but I'm arguing about both | 18:23 |
| ogra | yeah, cant do much about social engineering vectors ... except giving the user the ability to revoke access to certain parts of the system (which we do) | 18:24 |
| tomreyn | yes it's different, UIs matter. exposing information to less technical users matters. end user transparency matters. | 18:24 |
| clarkk | I want to check the developer and the project. atm, it's not at all easy | 18:24 |
| ogra | but you can perfectly fine look at how a snap was created and from what source | 18:24 |
| clarkk | ogra, from the software centre? | 18:25 |
| ogra | np from looking at the package as i described | 18:25 |
| ogra | s/np/nš | 18:25 |
| ogra | bah ... emoji plugin ... sorry | 18:25 |
| clarkk | sorry, I missed it. Where did you say that? | 18:25 |
| clarkk | please explain the steps from the Ubuntu Software app to the source code | 18:26 |
| ogra | the snapcraft.yaml prcisely describes each bit inside your package and how it was built | 18:26 |
| ogra | i said from cli | 18:26 |
| clarkk | ok, so I'm unnecessarily forced to use the CLI | 18:26 |
| clarkk | which I'm happy to do, now I know | 18:27 |
| ogra | if yu want to do forensics, yeah | 18:27 |
| clarkk | a simple html link in the software app would solve the whole problem | 18:27 |
| ogra | well, tell the gnome devs š | 18:27 |
| clarkk | ogra, could you tell me how I could become more familiar with managing snaps via the cli? I have no idea where to start | 18:29 |
| ogra | after all the software app is a gnome app to which ubuntu just adds a backend plugin to support a different devlivery mechanism for SW | 18:29 |
| ogra | clarkk, "snap help" is probably a good start | 18:29 |
| ogra | "snap info --verbose <snap name>" is usually also very helpful (and there is usually a "contact:" field to reach the developer) | 18:30 |
| clarkk | thank you, ogra. Really appreciate the info, and thanks for your patience in explaining it all | 18:32 |
| ogra | no prob š | 18:32 |
| ogra | btw, regarding your html link ... i persoanlly find https://snapcraft.io/<snapname> way more convenient than the software app (and it has typiclly more details and links to upstreams) | 18:37 |
| ogra | i.e. https://snapcraft.io/htop as an example (note the "contact" link) | 18:39 |
| oerheks | tomreyn, to keep track i hit f5 on https://launchpad.net/ubuntu/+source/firefox/+bugs?orderby=-datecreated&start=0 | 21:01 |
| oerheks | maybe it is moderated | 21:01 |
| tomreyn | oerheks: thanks, i was looking at this, too, as well as #ubuntu-bugs-announce | 21:02 |
| tomreyn | security would explain it, right | 21:02 |
| oerheks | yes. | 21:03 |
| oerheks | but i think also spam control .. | 21:03 |
| leftyfb | gah, love linux and open source | 21:58 |
| leftyfb | bought a new laptop a while back. Slowly creating an ansible playbook to rebuild said laptop from scratch comparing my existing laptop running 18.04 to the new one running 20.04.... | 21:59 |
| leftyfb | apparently the latest hexchat has an issue with it's font renduring which annoys the hell out of me https://github.com/hexchat/hexchat/pull/2500/ | 21:59 |
| daftykins | things change so often, surely that type of effort will be redundant quickly? | 22:00 |
| leftyfb | meh, not much. Even so. Updating some roles is and hitting go is a lot easier than doing it all from scratch manually | 22:00 |
| leftyfb | anyway, I downloaded the deb source for hexchat, updated the files in the patch above and recompiled. Now all is well | 22:01 |
| leftyfb | cept for not being able to upload to the ppa I created for it for some reason :/ | 22:01 |
| leftyfb | ah wait ... maybe just an issue of being impatient. Just got the "accepted" email | 22:02 |
| tomreyn | maybe your system's encryption libraries are too new to be compatible with launchpad | 22:02 |
| leftyfb | no, that was a whole thing as well. I really need to nail down the proper way to re-import my gpg keys. I THINK I got it, at least enough to make debuild happy | 22:03 |
| leftyfb | but seriously, being able to just fix the code and be on my way ... so nice | 22:03 |
| leftyfb | here's the annoying bit: https://i.imgur.com/kSm19BP.png | 22:04 |
| tomreyn | font size? | 22:04 |
| leftyfb | top is 18.04, bottom is 20.04 that isn't quite right. The difference doesn't jump out, but man does it mess with the eyes after being used to it a certain way all these years | 22:04 |
| leftyfb | tomreyn: yes/no | 22:05 |
| leftyfb | has to do with the font rendering the height properly | 22:05 |
| tomreyn | i see. but just decreasing the font size by 2px wont help? | 22:05 |
| tomreyn | i assuem you mean the vertical line spacing is an issue | 22:06 |
| leftyfb | ah, see, that's the bigger issue which the bug was ACTUALLY meant to resolve: https://github.com/hexchat/hexchat/issues/2449 | 22:06 |
| leftyfb | if you lower the size beyond 13px, you don't get to see underscores and the g is cutoff | 22:06 |
| tomreyn | oh, i remember running into that before, too | 22:06 |
| daftykins | heh | 22:07 |
| leftyfb | yeah, REAL annoying bug | 22:07 |
| leftyfb | nothing showstopping, but boy does it tick me off trying to use hexchat | 22:07 |
| tomreyn | maybe it was fixed before, then, since i still use 18.04. might be worth a search. | 22:07 |
| leftyfb | 18.04 is fine. 20.04 is broken with no fix in place ... other than my soon to be PPA :) | 22:08 |
| leftyfb | hexchat has merged the changes but not released it yet | 22:08 |
| leftyfb | so there's no existing fix anywhere | 22:08 |
| leftyfb | sweet, ppa finished. BRB. Gotta purge and try to install from PPA | 22:09 |
| leftyfb | bah, I missed something | 22:09 |
| leftyfb | "he repository 'http://ppa.launchpad.net/leftyfb/hexchat/ubuntu focal Release' does not have a Release file" | 22:09 |
| oerheks | hexchat - 2.14.3-5 pending... | 22:15 |
| oerheks | https://launchpad.net/~leftyfb/+archive/ubuntu/hexchat/+packages | 22:16 |
| leftyfb | oh right ... hm | 22:16 |
| leftyfb | I saw "1 successful" | 22:16 |
| leftyfb | tomreyn: when you update to 20.04 and find the same issue with hexchat, you are more than welcome to use my PPA. Assuming it finishes properly | 22:17 |
| tomreyn | leftyfb: thank you. i don't currently plan to move to ubuntu 20.04 or later. | 22:19 |
| leftyfb | oh? | 22:19 |
| tomreyn | back to the roots. ;-) | 22:19 |
| leftyfb | roots? | 22:20 |
| tomreyn | i'll wade through the pain that debian is instead. | 22:20 |
| leftyfb | oh, really? You moved to Debian? | 22:20 |
| leftyfb | or are planning to? | 22:20 |
| tomreyn | partially so far, not this desktop, yet | 22:21 |
| leftyfb | any particular reason? | 22:21 |
| tomreyn | a couple. we had a lengthy snap discussion here earlier, that's one of them. | 22:22 |
| tomreyn | but mostly it's the changed culture i no longer seem to be compatible with | 22:22 |
| leftyfb | the culture as fallen by the waitside over the years. I do miss the old days | 22:23 |
| leftyfb | waistside* | 22:23 |
| leftyfb | can someone highlight me? Need to test something | 22:24 |
| tomreyn | leftyfb: you got highlighted | 22:25 |
| leftyfb | bah, fail | 22:25 |
| leftyfb | thanks | 22:25 |
| leftyfb | hexchat jumps to focus on notifications. Just as annoying as the font issue | 22:26 |
| tomreyn | looks like you found another bug that needs fixing | 22:28 |
| tomreyn | here's another one, if you like: in case you'll choose to log any channel, it will write to disk every few seconds. | 22:28 |
| tomreyn | great for disco flashlights triggered by hdd controllers, not as great for your ssds. | 22:29 |
| leftyfb | tomreyn: what do you mean? I prefer my logging. | 22:30 |
| leftyfb | I have IRC logs going back over 10 years. All quickly searchable with some functions I made up | 22:30 |
| tomreyn | hexchat has a log feature, you can log select or all channels. if you enable it, logs will be written to disk a lot more often than they should be. | 22:31 |
| leftyfb | ah | 22:31 |
| leftyfb | another annoying issue with hexchat I've found.... not a bug but a lack of a feature. You can't specify $HOSTNAME as a variable for log location/name | 22:32 |
| leftyfb | IF I wanted several machines to log to the same location, there's no way to distinguish them. They would write to the same file(s) | 22:32 |
| tomreyn | that's what directories are good for, isnt it? | 22:34 |
| tomreyn | but i can see how you'd want multiple loggin into one, yes | 22:35 |
| tomreyn | otal DISK READ : 0.00 B/s | Total DISK WRITE : 7.54 K/s | 22:39 |
| tomreyn | Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s | 22:39 |
| tomreyn | TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND | 22:39 |
| tomreyn | 1234 be/4 tomreyn 0.00 B/s 7.54 K/s 0.00 % 0.00 % hexchat --existing | 22:39 |
| tomreyn | that's iotop, constantly listing hexchat on top | 22:40 |
| === himcesjf_ is now known as himcesjf | ||
| tomreyn | this may be of interest for nivdia driver users with a optimus / prime setup https://wiki.debian.org/NVIDIA%20Optimus#PRIMEOffload | 23:30 |
| daftykins | laptops turning into cars :O | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
