| ayan | i'm working on a snap with an executable that calls seccomp(). app armor (i think) blocks it even though the snap was built using 'devmode' confinement. | 01:43 |
|---|---|---|
| ayan | (really it is tor-browser.) | 01:43 |
| ayan | https://git.launchpad.net/~ayan/+git/tor-browser-snap/tree/snapcraft.yaml | 01:50 |
| ayan | also tor-browser has pretty restrictive file permissions. i wrote a simple plugin to walk the staged directly and fix the permissoins before creating the snap. i'm not sure if this is the best way to do it: | 01:54 |
| ayan | https://git.launchpad.net/~ayan/+git/tor-browser-snap/tree/parts/plugins/x-tor-browser.py | 01:54 |
| Shibe | will X be bundled with each DEs snap? | 01:57 |
| Chipaca | sgclark: what hackfest? | 09:03 |
| Chipaca | sgclark: ah, jamie already responded :-) | 09:03 |
| * Chipaca still doesn't know what hackfest | 09:03 | |
| Chipaca | croepha: what filesystem are you doing the build on? | 09:07 |
| Chipaca | ali1234: you can try the all-snap images, but I don't know if we expect them to work yet | 09:08 |
| Chipaca | ayan: I'd suggest bringing that up on the mailing list (as it'll require input from people that aren't here today) | 09:09 |
| Chipaca | Shibe: I doubt X will be bundled in snaps. I also doubt a DE will have a snap. But who knows? we'll see where people take it! | 09:09 |
| Shibe | Chipaca: how else will DEs be installed in a snappy system? | 09:10 |
| Chipaca | Shibe: in an all-snap system, that's a very good question and one that has been on my mind before | 09:10 |
| Chipaca | Shibe: all-snap systems are more aimed at IoT-kind of places though, at least until we make snappy rich enough to support things like DEs | 09:11 |
| Shibe | Chipaca: another thing is, what about dconf? I know that gtk apps use dconf for certain things and also for seeing what gtk theme to use | 09:11 |
| Chipaca | IoT and servers, i should add | 09:11 |
| Shibe | will you have to theme gtk on a per-app basis? | 09:11 |
| Chipaca | that is, ~single-purpose systems | 09:11 |
| Chipaca | Shibe: a related question: how do you snap a theme? | 09:12 |
| Shibe | yeah | 09:12 |
| Shibe | that is indeed a good question | 09:12 |
| ali1234 | another related question is how do you snap development tools? | 09:12 |
| Chipaca | these are nice juicy questions | 09:12 |
| ali1234 | currently you need a chroot to do any kind of serious development | 09:12 |
| Chipaca | ali1234: you do? | 09:13 |
| ali1234 | yes | 09:13 |
| ali1234 | there is no snap containing snapcraft | 09:13 |
| Chipaca | ali1234: in an all-snap system, i presume? | 09:13 |
| ali1234 | yes | 09:13 |
| Chipaca | ali1234: right | 09:13 |
| Chipaca | we need to circle back to all-snap systems soonish, to shore up that side of the store | 09:13 |
| ali1234 | all-snap systems are the only type of system worth considering, because if you don't have an all-snap system, you don't need snaps to begin with | 09:13 |
| Shibe | also btw, how was the size of libreoffice snap reduced from 1.1gb to the regular 200? | 09:14 |
| ali1234 | Shibe: by removing debug symbols | 09:14 |
| Chipaca | ali1234: well... I disagree, but I can also see why you'd think that | 09:14 |
| Shibe | ali1234: debug symbols were consisting of that 1.1gb? | 09:14 |
| ali1234 | Chipaca: there's this idea of using snaps to let upstream ship packages themselves whenever they want. this specifically is in my opinion a recipe for disaster if it is done on a regular "as it is now" ubuntu | 09:14 |
| Chipaca | Shibe: the libreoffice snap that was talked about a lot was built for testing the whole thing and included debug symbols to figure out what went wrong when it did | 09:14 |
| Shibe | ok | 09:15 |
| Chipaca | Shibe: the person has since renamed that to libreoffice-debug and built the debug-less libreoffice at 200M | 09:15 |
| Shibe | well that's nice | 09:15 |
| ali1234 | Chipaca: i've even heard people saying that for example, nvidia could distribute their drivers in a snap... | 09:15 |
| Chipaca | ali1234: why is it a recipe for disaster? | 09:16 |
| Shibe | btw will each app bundle mesa individually? | 09:16 |
| Shibe | I think in flatpak the application recieves the raw device node (/dev/nvidia-uvm on nvidia i think) and the application includes the libgl/mesa | 09:16 |
| Chipaca | I've got to go, I'll read up when I get back | 09:17 |
| Chipaca | o/ | 09:17 |
| ali1234 | Chipaca: i's a recipe for disaster because it necessitates including dependencies inside the snaps | 09:17 |
| ali1234 | that is a problem which you can ignore as long as snaps don't compose the base system | 09:18 |
| ali1234 | but for all-snap you basically have no choice but to deal with it | 09:18 |
| ali1234 | hence, my worry is that all-snap will be sidelined because it's too hard, and instead we just get a poor compromise that doesn't actually improve things at all | 09:18 |
| ali1234 | to put it another way: "snaps on a classic desktop" is a bit of a cop out, in my opinion | 09:20 |
| ali1234 | i mean sure it's a stepping stone, don't get me wrong... but snap has to go beyond that | 09:22 |
| ogra_ | it is just an additional playground, thats all ... the plans for all snap images in IoT havent changed ... nor has the idea of providing phone and pocket-desktop images | 09:22 |
| notadrop | hello | 09:22 |
| ogra_ | not sure where you expect the compromise to be | 09:23 |
| ali1234 | i don't expect compromise... i want an all-snap system to be able to do literally everything tht ubuntu can do today | 09:23 |
| ali1234 | without having to install "ubuntu classic" in a chroot | 09:23 |
| ali1234 | because then all you've done is moved the problem | 09:23 |
| ogra_ | it will probably not behave exactly like a classic system ... but you will eventually be able to do all you want | 09:24 |
| ali1234 | it doesn't have to be exactly like it, it just has to do the same things with the same amount of effort :) | 09:24 |
| ogra_ | things in a new world might be done differently, but stil provide your desirent behaviour | 09:25 |
| ogra_ | or results rather | 09:25 |
| ali1234 | and the same amount of disk space? ;) | 09:25 |
| ogra_ | it will just take a little more time for specific bits | 09:25 |
| ogra_ | why not | 09:26 |
| ali1234 | "why not" -> because developers are lazy :) | 09:28 |
| ogra_ | who knows, probably we might get to a point where they even need less diskspace ... snappy is still very young (compared to 20+ years of deb), i dont see why such improvements shouldnt come in the future | 09:28 |
| ali1234 | 20+ years is too long to wait | 09:29 |
| ogra_ | first of all all basics should be done right ... | 09:29 |
| ogra_ | i didnt say it has to take that long :) | 09:29 |
| ogra_ | just that debs had this time to mature | 09:29 |
| ali1234 | in 20 years people will be complaining that snap is out of date and no good and trying to rewrite it | 09:29 |
| ogra_ | cool := | 09:30 |
| ogra_ | :) | 09:30 |
| ogra_ | (that means it will still be around ;) ) | 09:30 |
| ali1234 | that's best case :) | 09:30 |
| ogra_ | nah, best case is that iin 20 years people will still like snaps because they evloved in the right direction | 09:31 |
| ali1234 | although i feel like if snap just becomes another way to package things for regular ubuntu then it wont be around in 20 years... flatpak will win | 09:31 |
| ogra_ | but the replace in 20 years case is a good one nontheless ;) | 09:31 |
| ogra_ | let the upstreams decide ... | 09:31 |
| ali1234 | you know which one they will choose | 09:31 |
| ogra_ | i see which one they choose today | 09:32 |
| ali1234 | upstreams wont decide it, all the other distros will | 09:32 |
| ogra_ | ?? | 09:32 |
| ogra_ | you mean they would denny opensource code in their distro ? | 09:32 |
| ali1234 | no | 09:32 |
| ogra_ | so how will thhey decide anything | 09:32 |
| ali1234 | debian does not deny upstart code in their distro? | 09:32 |
| ali1234 | yet still nobody uses it | 09:32 |
| ogra_ | if snaps are the way an upstream provides hiw stuff and the distro has snap support (even if you need to install it) ... then you will enable it | 09:33 |
| ogra_ | *his | 09:33 |
| ali1234 | if all distros support both, but flatpak works significantly better due to being what the distro itself chooses to ship a majority of packages, then upstreams will choose it too | 09:34 |
| ogra_ | distros are the least bits her that have any influence as long as they dont block snappy to enter their system ... upstreams count | 09:34 |
| ogra_ | if all uppstreams would decide to all go appimage ... what would you think distros would support | 09:34 |
| ali1234 | upstreams will choose whatever is best supported | 09:35 |
| ogra_ | and i'm only talking about the app delivery here ... they will indeed still use whatever base system they want | 09:35 |
| ogra_ | right ... | 09:35 |
| ogra_ | and we're at a point where multiple systems exist | 09:35 |
| ogra_ | lets just see what upstreams will chose | 09:35 |
| ali1234 | upstreams will wait to see what distros choose | 09:36 |
| ali1234 | basically, if distros do not convert to something like all-snap, then upstreams will continue to not use anything | 09:36 |
| ali1234 | afaik flatpak and appimage can't do all-snap? | 09:36 |
| ogra_ | why would any distro go to all-snap | 09:37 |
| ogra_ | not even ubuntu will | 09:37 |
| ali1234 | that's a problem | 09:37 |
| ogra_ | all-snap is for special use-cases | 09:37 |
| ogra_ | ubuntu wont drop traditional deb based installs | 09:37 |
| ali1234 | a distro would go all snap only for one reason: because it is an improvement over the current way of making a distro | 09:37 |
| ogra_ | heh | 09:37 |
| ali1234 | but of course you have to make that be true first | 09:38 |
| ogra_ | i rather think a distro will simply throw out all toplevel apps and will start focusing and improving their work on core ... simply because it frees manppower | 09:38 |
| ali1234 | if that doesn't happen then distros won't do it, and upstreams will just containue shipping tarballs and crappy binaries | 09:38 |
| ali1234 | yes, exactly | 09:39 |
| ogra_ | (why woould a distro care about gimp or libreoffice if upistream already provides a proper way to get it ) | 09:39 |
| ogra_ | so in the end it improves life of everyone ... | 09:39 |
| ali1234 | why would a distro care about gcc if upstream provides a proper way to get it? | 09:39 |
| ogra_ | because their existing packaging system requires them to have gcc in their distro | 09:40 |
| ali1234 | answer: because as distro maintainers they actually need to use it | 09:40 |
| ogra_ | yes, and there are existing established mechanisms to do so to build a distro | 09:40 |
| ali1234 | so it boils down to: which next gen package system supports development tools best? | 09:40 |
| ali1234 | and currently the answer is none of them | 09:41 |
| ogra_ | huh | 09:41 |
| ogra_ | snapcraft is well supported :) | 09:41 |
| ogra_ | and it fulfills my needs as a developer | 09:41 |
| ali1234 | oh, there is a snap containing snapcraft? | 09:41 |
| ogra_ | nope | 09:41 |
| ali1234 | well then | 09:41 |
| ogra_ | there will likely be one (thats trivial) | 09:41 |
| ogra_ | but thats not the point | 09:42 |
| ali1234 | can i make an ubuntu builder using all-snap? | 09:42 |
| ali1234 | what about a launchpad snap? | 09:42 |
| ogra_ | you have to ask the launchpad people if they plan to snap it ... else ... feel free to go ahead | 09:42 |
| ali1234 | these are the kind of things distro maintainers will want | 09:42 |
| ogra_ | sure | 09:43 |
| ali1234 | if you don't give them this, they won't care about supporting snap well enough that upstreams will want to use it | 09:43 |
| ogra_ | i dont see why they couldnt get it | 09:43 |
| ali1234 | i hope they will be able to in the future | 09:43 |
| ogra_ | if someone asks ... or if someone even sends code for this, it will happen | 09:43 |
| ali1234 | they're not going to write it themselves | 09:43 |
| ali1234 | developers are lazy remember? | 09:43 |
| ogra_ | havent said that :) | 09:44 |
| ali1234 | no, i did | 09:44 |
| ali1234 | distros won't accept it unless it is spoon fed to them | 09:44 |
| ogra_ | the point is that the demand needs to be expressed ... which happpens via whishlist bugs usually :) | 09:44 |
| ogra_ | and these get fixed at some point | 09:44 |
| ogra_ | and again, i dont see why distros would need it | 09:45 |
| ali1234 | that's not the point | 09:45 |
| ogra_ | snap is not there to replace distros | 09:45 |
| ali1234 | it should be | 09:45 |
| ali1234 | because distros suck | 09:45 |
| ali1234 | distros dont need to do anything | 09:46 |
| ali1234 | distros didn't need systemd, they chose it because it made their life easier | 09:46 |
| ogra_ | sure | 09:46 |
| ali1234 | imagine the average guy packaging software for debian | 09:46 |
| ali1234 | how does snap make their life easier? | 09:47 |
| ogra_ | why does he package for debian | 09:47 |
| ogra_ | and what | 09:47 |
| ogra_ | i dont see why a systemd debian packager would care for snap | 09:47 |
| ali1234 | not systemd | 09:47 |
| ogra_ | but i also dont see the need for a gimp package in debian if upstream already provides a snap and debian has snap support available | 09:48 |
| ali1234 | let's take as an example gcc... or maybe clang | 09:48 |
| ogra_ | yeah, they are components snapcraft uses when you roll your package :) | 09:49 |
| ali1234 | okay | 09:49 |
| ali1234 | so as the clang packager for debian, how does making sure my package works correctly with snapcraft make my life easier? | 09:49 |
| ogra_ | and will still be available through distro channels, since the distro itself needs them to build the distro | 09:49 |
| ogra_ | why would you do that ? | 09:50 |
| ali1234 | yes, that is what i am asking | 09:51 |
| ogra_ | the snapcraft maintainers will | 09:51 |
| ali1234 | who are the snapcraft maintainers? | 09:51 |
| ogra_ | if someone uses a snap with clang and hits a bug, he will file it and either the snapcraft maintainers or the person with the problem will eventually write code to fix it | 09:51 |
| ogra_ | as clang upstream you simply have to accept the patches | 09:51 |
| ali1234 | or you know.. they will just use flatpak instead | 09:51 |
| ogra_ | what for | 09:52 |
| ali1234 | instead of snap | 09:52 |
| ali1234 | or they mght just not bother at all | 09:52 |
| ogra_ | why would you package a complier in an app delivery system instread of the build tool for the app delivery system | 09:52 |
| ali1234 | because a compiler is an app? | 09:53 |
| ogra_ | (i dont see why it wouldnt be possible to snap up gcc or clang, i just dont see the benefit of it) | 09:53 |
| ali1234 | if you can't see the benefit of it, then why do you expect anyone else to? | 09:54 |
| ogra_ | ? | 09:54 |
| ogra_ | i dont ? | 09:54 |
| ali1234 | and if you don't expect anyone else to see the benefit, why do you expect anyone to use snap at all? | 09:54 |
| ogra_ | i think snapping compilers is pointless ... | 09:54 |
| ogra_ | you are the one who claims it isnt :) | 09:54 |
| ali1234 | okay, where do you draw the line? | 09:54 |
| ali1234 | what about secondary build tools like make or cmake? | 09:55 |
| ogra_ | at the level where the distro doesnt provide the bits to build itself | 09:55 |
| ali1234 | ultimately my point is that "next generation packaging tool" will require support from *everyone* to be successful. it won't get that support unless it offers something to everyone it needs support from | 09:56 |
| ogra_ | what i can imagine is that you eventually have tool bundles ... like "qt-build-env" that comes with all tools you need in a snap and offers you a high level way to work on your project ... more like sdks than single tools | 09:57 |
| ali1234 | that would be an excellent step along the way | 09:57 |
| ali1234 | and already a massive improvement over what we have now for a large number of people | 09:58 |
| ogra_ | right ... i dont see that gcc standalone would make much sense ... but in context of such a bundle it would be one tool that would be used in the process | 09:58 |
| ali1234 | installing an ubuntu-sdk snap would sure be nicere than an ubuntu-sdk chroot | 09:58 |
| ogra_ | thats an implementation detail | 09:59 |
| ali1234 | gcc standalone would make sense... there are plenty of use-cases where you dont need anything else | 09:59 |
| ali1234 | like developing for arm microcontrollers for example | 09:59 |
| ali1234 | i guess you might include a tiny libc in that too | 09:59 |
| ali1234 | so like avr-gcc/avr-libc | 10:00 |
| ogra_ | you could have a snap that mounts your project dir inside an lxd container and execs the build process there when you issue the build command ... all you as developer should care about is that you can work on your code and issue a command to build or debug the code ... | 10:00 |
| ali1234 | i regularly use binutils standalone too... since it has a decompiler | 10:00 |
| ali1234 | and strace | 10:01 |
| ogra_ | or it could be a chroot ... or a cloud instance or whatever :) | 10:01 |
| ali1234 | but here is the thing | 10:01 |
| ali1234 | having a snap which contains a full ubuntu chroot with every dev tool ever installed inside it violates the "uses the same amount of disk space" principle | 10:02 |
| ogra_ | whats that principle exactly ? :) | 10:03 |
| ali1234 | the one i invented | 10:03 |
| ogra_ | (also, why in the world would you build such a thing) | 10:03 |
| ali1234 | i wouldn't... i would just use regular ubuntu | 10:03 |
| ali1234 | but you want people to use snap right? | 10:03 |
| ogra_ | and thats fine | 10:03 |
| ogra_ | as a delivery mechanism for their products | 10:03 |
| ali1234 | here's the thing | 10:04 |
| ogra_ | and if there is a bundled snap that provides a specialzed build env for their products that eases their life by bundling, then too | 10:04 |
| ali1234 | i won't really trust snap as a delivery mechanism until i see the software i use delivered with it | 10:04 |
| ogra_ | thats a weird POV i must say | 10:05 |
| ali1234 | i don't think it is | 10:05 |
| ogra_ | i want to get my shit done ... whatever makes that easiest to me is what i use ... | 10:05 |
| ali1234 | nobody wants to be an early adopter | 10:05 |
| ogra_ | and i want to get my stuff inot hands of users | 10:05 |
| ogra_ | these are two distonct requirements | 10:06 |
| ali1234 | well if you want to get your stuff into the hands of users then you pick android apks... | 10:06 |
| ogra_ | i dont see why they would have to be fulfilled by the same thing | 10:06 |
| ogra_ | except that i dont develop android apps | 10:06 |
| ali1234 | then you cant really make an argument for picking tools based on distribution | 10:07 |
| ogra_ | (though i dont see why snapcraft culdnt have android execution env support | 10:07 |
| ogra_ | ) | 10:07 |
| ogra_ | like i dont see why snappy couldnt have a wine execution env ... so that windows applications could be delivered | 10:07 |
| ogra_ | s/snappy/snapcraft | 10:08 |
| ogra_ | in any case i see the two parts as distinct steps ... development vs delivery | 10:09 |
| ali1234 | i don't | 10:09 |
| ali1234 | there is too much overlap | 10:09 |
| ogra_ | not sure where | 10:10 |
| ali1234 | where does a tool like glade fall? | 10:10 |
| ogra_ | they are two sepearate steps | 10:10 |
| ali1234 | what about text editors | 10:10 |
| ali1234 | what about an IDE? | 10:10 |
| ogra_ | what about them | 10:10 |
| ali1234 | are they a development tool, or something that should be delivered as an app? | 10:10 |
| ogra_ | no, they are a tool that shoulld be part of a dev-env snap as i described above | 10:11 |
| ali1234 | so you would just have a gigantic snap with every development tool in it? | 10:11 |
| ogra_ | why would you use glade standalone | 10:11 |
| ogra_ | withhout buulding somethign with it | 10:11 |
| ogra_ | no | 10:12 |
| ali1234 | why would i want glade installed if i am writing a Qt application? | 10:12 |
| ogra_ | why would i put every development tool into it | 10:12 |
| ali1234 | okay, which development tools would you put in it? | 10:12 |
| ogra_ | i would put the tools that fit the project into it | 10:12 |
| ali1234 | so each developer would need to make their own monolithic development tools snap? | 10:12 |
| ogra_ | if there is a glade app it will likely buuld gtk stuff | 10:12 |
| ali1234 | with whatever tools they want in it | 10:12 |
| ogra_ | so i would put the gtk build deps, a compiler and whatever else is needed into it ... along with glade itself | 10:13 |
| ali1234 | what is the developer of qgtkstyle supposed to do? | 10:13 |
| ogra_ | i wouldnt put Qt libs in | 10:13 |
| ogra_ | dunno ... how many are there :) | 10:14 |
| ogra_ | they would probably take my snap and enhance it | 10:14 |
| ali1234 | probably about four or five... you know like every open source project ever | 10:14 |
| ogra_ | because that just means two extra lines in the snapcraft.yaml i provide | 10:14 |
| ali1234 | yeah and then waiting six hours for all that stuff to build :) | 10:14 |
| ali1234 | this does not sound very apealing to developers to me | 10:15 |
| ogra_ | dunno why you would have to wait 6h for a snap to be built by snapcraft | 10:15 |
| ogra_ | i havent seen such a snapcraft project yet :) | 10:16 |
| ogra_ | (though they will undoubtly exist some day) | 10:16 |
| ali1234 | because you removed half the stuff from the distro because it isn't needed any more | 10:17 |
| ali1234 | can you build a snap out of other snaps? | 10:17 |
| ogra_ | also why do you care ... as that potential glade developer you just snap install glade-dev-env | 10:17 |
| ogra_ | or as the one using qtgtk crossover stuf you install glade-and-qt-dev-env from someone else | 10:18 |
| ali1234 | that ends with every application having it's own dev-env snap | 10:18 |
| ogra_ | ? | 10:18 |
| ali1234 | in the same way that currently every snap needs to have a copy of all it's dependencies embedded | 10:19 |
| ali1234 | the same thing ends up happening in the -dev snaps | 10:19 |
| ogra_ | dev-env ... | 10:19 |
| ali1234 | yes, -dev-env | 10:20 |
| ogra_ | you use a toolkit, so you have the bits needed included | 10:20 |
| ali1234 | yeah except that in the real world just using a toolkit is not enough | 10:20 |
| ogra_ | well, you define what else is needed in yur snapcraft yaml | 10:21 |
| ali1234 | so then you fork the toolkit dev-env snap, add that one extra library you need, and rebuild it, and now you have a unique dev-env for your app | 10:21 |
| ogra_ | or your toolkit pffers you to add the needed bits on demand ;) | 10:21 |
| ogra_ | *offers | 10:21 |
| ali1234 | snapcraft can only install what the distro includes | 10:21 |
| ogra_ | s/toolkit/dev-env/ | 10:22 |
| ali1234 | and we removed all non-build-essential things from the distro because snap is way better, remember? | 10:22 |
| ogra_ | and ? | 10:22 |
| ali1234 | and so the only way to get the thing you need is as a snap | 10:22 |
| ali1234 | but you're not going to snap development tools | 10:22 |
| ogra_ | i dont need the distro to have my dev-env package use the upstream git tree of Qt | 10:23 |
| ogra_ | i can just define it in my snapcraft.yaml to use that | 10:23 |
| ali1234 | snapcraft itself is not available in a snap... | 10:24 |
| ogra_ | as i said, that will change | 10:24 |
| ali1234 | so first thing you have to do is make a snap with snapcraft in it | 10:24 |
| ogra_ | but thats a minor detail | 10:24 |
| ali1234 | it's not exactly minor in my opinion | 10:24 |
| ogra_ | again .. snap is just a delivery mechanism | 10:24 |
| ali1234 | t isn't really though | 10:25 |
| ogra_ | rolling a snapcraft snap is likely not very hard ... | 10:25 |
| ogra_ | just takes time that nobody has right now because thats currently not really a pressing prob for anyone | 10:26 |
| ali1234 | tar.gz is a delivery mechanism | 10:26 |
| ogra_ | the 50 or so upstreams that started fiddling with snaps over the last two weeks or so surely didnt have issues with using snapcraft in its current state | 10:27 |
| ali1234 | heh | 10:27 |
| ali1234 | well, i hit problems at every turn | 10:27 |
| ogra_ | file bugs :) | 10:28 |
| ali1234 | but i am not just trying to ship packages on standard ubuntu | 10:28 |
| ogra_ | right | 10:28 |
| ogra_ | and i doubt you will ever see gcc go away as a deb | 10:28 |
| ogra_ | or make | 10:28 |
| ali1234 | i don't want to see that | 10:29 |
| ali1234 | what i want is for apt to be a thing that is only used by snapcraft | 10:29 |
| ali1234 | and every single byte of binary code on my drive to be installed by snap | 10:30 |
| ogra_ | well, in certain setups that will be the case | 10:30 |
| ali1234 | in *every* setup | 10:30 |
| ali1234 | and without having loads of dupes of the same thing installed | 10:30 |
| ali1234 | right now i have about 10 copies of gcc installed and i'm not even using snaps yet | 10:32 |
| ogra_ | why do you have that ? | 10:32 |
| ali1234 | several different cross compilers | 10:33 |
| ali1234 | the problem is that everyone ships monolithic development SDKs | 10:34 |
| ali1234 | for example http://wiibrew.org/wiki/DevkitPPC | 10:34 |
| ali1234 | you know what would solve this problem? | 10:35 |
| ali1234 | if upstream gcc released a snap for every release/host/target combination | 10:35 |
| ali1234 | a standalone gcc snap | 10:35 |
| ogra_ | well, write a snapcraft.yaml and send it to them ... i'm sure they wouldnt refuse | 10:36 |
| ogra_ | (i still dont see the need ... you would likely also want make, binutils and such stuff in such a snap) | 10:37 |
| ali1234 | yes | 10:38 |
| ali1234 | but i'd only need one | 10:38 |
| ogra_ | (probably even libc) | 10:38 |
| ali1234 | instead of having 10 different ones | 10:38 |
| ali1234 | like currently ubuntu has packages for mingw which i use | 10:39 |
| ali1234 | it doesn't have one giant package that also includes make | 10:39 |
| ali1234 | that would be a step backwards in my opinion | 10:39 |
| ogra_ | well ... | 10:39 |
| ogra_ | i think we are back at the beginning of the conversation now | 10:40 |
| ali1234 | yes | 10:40 |
| ogra_ | deduplication or whatever will surely be looked at at some point | 10:41 |
| ogra_ | until then, just use a classic system or a classic shell in an all-snaps system (which should be back when we have actual images) | 10:42 |
| ali1234 | 99% of the software i write is for my own use | 10:43 |
| ali1234 | so for me, snappy has to be more than just a distribution system | 10:45 |
| ali1234 | because once i build the software i already have it | 10:45 |
| === bspock is now known as bpeak | ||
| ogra_ | bah | 12:59 |
| ogra_ | ogra@styx:~$ sudo snap remove telegram-sergiusens | 13:00 |
| ogra_ | error: cannot remove "telegram-sergiusens": snap "telegram-sergiusens" has changes in progress | 13:00 |
| ogra_ | seems the panel systray icon keeps running which confuses snapd .. now i cant either install or remove it | 13:00 |
| * ogra_ tries a reboot | 13:01 | |
| ogra_ | hmm, nope | 13:03 |
| ogra_ | funnily the snap mount is definitely gone after reboot | 13:05 |
| ogra_ | ah, but snap install works again ... something at leat | 13:10 |
| ogra_ | *least | 13:10 |
| aisrael | I'm having trouble getting my wireless dongle to work after upgrading to kernel 3.19.1-12. I'd installed linux-firmware_1.158_all.deb, but even after reinstalling it the only modules I have are for 3.19.0-51. Any idea what I'm missing? | 14:52 |
| ehbello | hello! | 17:56 |
| ehbello | I was packaging my first snap following ubuntu guides about snapcraft but it does not install in Ubuntu Core 15.04/stable | 17:56 |
| ehbello | It seems to be incompatible | 17:56 |
| ehbello | what version of Ubuntu Core must I use? | 17:56 |
| ehbello | "failed to install: open /tmp/read-file847258171/unpack/meta/package.yaml: no such file or directory" | 17:59 |
| ehbello | I'm using Ubuntu 16.04 to develop this snap | 18:01 |
| ehbello | ok... I answer to myself... Ubuntu 16.04 has snapcraft 2.x and Ubuntu Core 15.04/Stable has snapcraft 1.x but still there is no release of 16.04 | 18:35 |
| tsimonq2 | ehbello: snapd =/ snapcraft | 18:39 |
| tsimonq2 | ehbello: you should be looking at the all-snap images anyways | 18:40 |
| ehbello | tsimonq2: i'm sorry... i mean snapd, obviously | 18:42 |
| === JanC_ is now known as JanC | ||
| === dasjoe_ is now known as dasjoe | ||
| ehbello | @tsimonq2: ok, all-snap images... I now understand what it means: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html | 20:21 |
| nothal | ehbello: No such command! | 20:21 |
| ehbello | tsimonq2: ok, all-snap images... I now understand what it means: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html | 20:21 |
| ehbello | tsimonq2: thanks | 20:22 |
| ehbello | :D | 20:22 |
| tsimonq2 | ehbello: nice :) | 21:28 |
| tsimonq2 | you get everything squared away? | 21:28 |
| ehbello | tsimonq2: I get an error following this example to generate a "stable" release: https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#Image_generation_.2816_and_higher.29 | 21:39 |
| ehbello | tsimonq2: 'failed to install "canonical-pc" from "stable": canonical-pc failed to install: exit status 2' | 21:39 |
| ehbello | tsimonq2: how can I get a valid list of values for 'gadget' parameter? | 21:40 |
| ehbello | tsimonq2: answer: https://developer.ubuntu.com/en/snappy/guides/gadget/ :) | 21:50 |
| tsimonq2 | ehbello: to be honest, I don't know | 22:03 |
| tsimonq2 | oh nice :D | 22:03 |
| ehbello | tsimonq2: ok, thanks anyway :D | 22:05 |
| ehbello | 22:11 | |
| ehbello | 22:11 | |
| === Chipaca` is now known as Chipaca | ||
| ehbello | tai271828: FYI: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001735.html | 22:55 |
| ehbello | tai271828: sorry | 22:56 |
| ehbello | tsimonq2: FYI: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001735.html | 22:56 |
| ehbello | tsimonq2: this link is needed to fix the problem:`ln -s /bin/true /usr/local/bin/udevadm` | 22:56 |
| tsimonq2 | oh cool | 23:09 |
| tsimonq2 | that's good that you got it fixed :) | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!