Re: Updating cloud part
+1, thanks, Alan! On 31.03.2017 18:51, Alan Pope wrote: On 31 March 2017 at 17:41, Tim Süberkrüb <tim.sueberkr...@web.de> wrote: ah, thanks for that info. So I guess '/' in part names has been deprecated? Yes. Some docs for cloud parts in general would be nice ;) Agreed. https://github.com/CanonicalLtd/snappy-docs/issues/54 :) -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Updating cloud part
Hey Joe, thanks for your reply. Yeah, I know but I updated it here: https://wiki.ubuntu.com/snapcraft/parts (see entry at the very bottom). I already checked snapcraft update/search and the API url. All the best, Tim On 31.03.2017 18:24, Joe Talbott wrote: I see 'liri-app' here https://parts.snapcraft.io/v1/parts.yaml Make sure you run 'snapcraft update' to download the latest parts.yaml file. Joe On Fri, Mar 31, 2017 at 12:22 PM, Tim Süberkrüb <tim.sueberkr...@web.de> wrote: Hey, I made some changes to the Liri cloud part few hours earlier, but parts.snapcraft.io still hasn't updated. Is there a problem with my changes or am I just too impatient? ;) All the best, Tim -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Contributing cloud parts
Thanks Leo! > We know that our remote parts workflow is lacking. If you have > suggestions or complaints, filing bugs for those would be really > useful: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=wiki What I could imagine as a proper solution would be something like "parts.snapcraft.io", similar or as part of "build.snapcraft.io" where developers could authenticate with their Ubuntu One and/or GitHub accounts and upload, manage and search for cloud parts. That would be really fantastic :) But that's just an idea. All the best, Tim On 26.03.2017 17:15, Leo Arias wrote: Done. But note that the parser runs every hour, so you will have to wait to see it. If everything goes well, a little after the hour you can run snapcraft update && snapcraft search liri to check it. We know that our remote parts workflow is lacking. If you have suggestions or complaints, filing bugs for those would be really useful: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=wiki thanks Tim! -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Contributing cloud parts
Hey Leo, thank you! I wanted to add the following part: --- origin: https://github.com/tim-sueberkrueb/liri-snapcraft-part.git maintainer: Tim Süberkrüb <d...@timsueberkrueb.io> description: | Helper for Liri Apps depending on the Liri Platform snap. Includes a specific launcher and Snapcraft configuration to deduplicate build configurations. parts: [liri-app] --- All the best, Tim Süberkrüb On 26.03.2017 16:30, Leo Arias wrote: Hello Tim, On Sun, Mar 26, 2017 at 7:34 AM, Tim Süberkrüb <tim.sueberkr...@web.de> wrote: Hey, I finally had the time to create the cloud part. It seems like I don't have sufficient permissions to edit the wiki page though: "You are not allowed to edit this page!" How do I request edit permissions for this page? All the best, Tim Süberkrüb I don't know how to answer your question, but while somebody gives you an answer you can share your part here and I'll put it in the wiki. pura vida -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Contributing cloud parts
Hey, I finally had the time to create the cloud part. It seems like I don't have sufficient permissions to edit the wiki page though: "You are not allowed to edit this page!" How do I request edit permissions for this page? All the best, Tim Süberkrüb On 21.03.2017 12:08, Tim Süberkrüb wrote: Hey Didier, I see, thanks for your answer! All the best, Tim Süberkrüb On 20.03.2017 09:42, Didier Roche wrote: Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : Hey, Hey Tim, what is the process of contributing a cloud part to https://wiki.ubuntu.com/snapcraft/parts (is it open for community contributions?)? Are there any plans for having a real parts repository instead of a wiki page for cloud parts? I think something like parts.snapcraft.io would be pretty cool :) There isn't any process as of now AFAIK. It is open for community contributions, so feel free to edit the wiki page adding your awesome cloud part :) snapcraft update && snapcraft search should list your part within the next hour (the importer runs hourly AFAIK). I agree some way to see/check metrics on parts popularity, getting user's feedback and such would be pretty cool! Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Contributing cloud parts
Hey Didier, I see, thanks for your answer! All the best, Tim Süberkrüb On 20.03.2017 09:42, Didier Roche wrote: Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : Hey, Hey Tim, what is the process of contributing a cloud part to https://wiki.ubuntu.com/snapcraft/parts (is it open for community contributions?)? Are there any plans for having a real parts repository instead of a wiki page for cloud parts? I think something like parts.snapcraft.io would be pretty cool :) There isn't any process as of now AFAIK. It is open for community contributions, so feel free to edit the wiki page adding your awesome cloud part :) snapcraft update && snapcraft search should list your part within the next hour (the importer runs hourly AFAIK). I agree some way to see/check metrics on parts popularity, getting user's feedback and such would be pretty cool! Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Contributing cloud parts
Hey, what is the process of contributing a cloud part to https://wiki.ubuntu.com/snapcraft/parts (is it open for community contributions?)? Are there any plans for having a real parts repository instead of a wiki page for cloud parts? I think something like parts.snapcraft.io would be pretty cool :) All the best, Tim Süberkrüb -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Store - Organizations/Namespaces/Transfer packages
Hey Evan, this is fantastic (/me is also watching https://github.com/canonical-ols/build.snapcraft.io/issues/132) :) Looking forward to this! All the best, Tim On 17.03.2017 10:35, Evan Dandrea wrote: On Thu, 16 Mar 2017 at 19:18 Tim Süberkrüb <tim.sueberkr...@web.de <mailto:tim.sueberkr...@web.de>> wrote: > You are correct, this is the best way to handle this situation right > now. You can use the + trick (realaddress+al...@domain.com <mailto:realaddress%2bal...@domain.com>) in your > email address if you don't have a convenient one to use. Once you set it > up and assign collaborators, you can proceed with your regular account. Okay. I'd personally really love to see something like organization accounts (maybe comparable to how GitHub handles organizations) in the future because I think this is a common use case. Hi Tim, Good timing, we're exploring exactly this. :) There are a few options under consideration, but all involve letting you treat organisation members as collaborators on a snap. Of course we'll announce it here. If you start with a developer account to hold your organisation identity, you'll be able to transfer over when the time comes. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Store - Organizations/Namespaces/Transfer packages
Hey Michael, thanks for your reply! On 16.03.2017 19:22, Michael Hall wrote: On 03/16/2017 01:41 PM, Tim Süberkrüb wrote: Hey everyone, I have some questions about best practices for organizations (like our Liri Project) regarding the store. 1. Accounts: Is it possible to have a "pure" organization account in the store where several people have full or partial access? The only option I can see right now would be someone from the team having to create a new Ubuntu One account (with a yet unregistered email address) who would have full access and could only grant rights to others for every individual package. What is recommended for organizations here/are there plans for the future? You are correct, this is the best way to handle this situation right now. You can use the + trick (realaddress+al...@domain.com) in your email address if you don't have a convenient one to use. Once you set it up and assign collaborators, you can proceed with your regular account. Okay. I'd personally really love to see something like organization accounts (maybe comparable to how GitHub handles organizations) in the future because I think this is a common use case. 2. Namespaces: If we'd choose the namespace "liri" and would register a new name in the store "liri-app", what would happen if someone else would try to register that name? Do we own "liri-app" because we were first or would users - in case of multiple "liri-app." packages have to install it using "liri-app.liri"? Package names are guaranteed to be unique in the snap store, so if you register liri-app then you're the only one who can publish a package by that name. Oh, I see, so I was wrong with my assumptions (probably because I thought about how namespaces worked with click). So a snap "namespace" is not really a namespace but rather an unique id/name for the developer? 3. Transferring Packages Is it possible to transfer packages from user1 to user2 (or from my personal account to a possible future Liri Account) or would I have to delete the package and create a new one? There is a mechanism to dispute the ownership of a package name. You can use this to transfer a registered name from one publisher account to another. Okay, great. Thanks for taking the time to answer my questions. Have a nice day, Tim Süberkrüb -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Store - Organizations/Namespaces/Transfer packages
Hey everyone, I have some questions about best practices for organizations (like our Liri Project) regarding the store. 1. Accounts: Is it possible to have a "pure" organization account in the store where several people have full or partial access? The only option I can see right now would be someone from the team having to create a new Ubuntu One account (with a yet unregistered email address) who would have full access and could only grant rights to others for every individual package. What is recommended for organizations here/are there plans for the future? 2. Namespaces: If we'd choose the namespace "liri" and would register a new name in the store "liri-app", what would happen if someone else would try to register that name? Do we own "liri-app" because we were first or would users - in case of multiple "liri-app." packages have to install it using "liri-app.liri"? 3. Transferring Packages Is it possible to transfer packages from user1 to user2 (or from my personal account to a possible future Liri Account) or would I have to delete the package and create a new one? Thanks in advance :) All the best, Tim Süberkrüb -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Handling versioning of platform snaps
Hey Mark, thank you for explaining this, the reasons are clearer to me now. > In the case of libraries and frameworks, you don't have to worry about > persistent data that can or cannot be shared between the two versions. > You would need to know the two paths of the two versions *anyway* in > order to use them. THere is no semantic difference in your code between > /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be > more complex one way or the other. You're right, that's a good point. The only difference is that it's slightly harder to maintain because instead of maintaining different versions of one package we need to maintain different versions of different packages. And for each new version, a new name has to be registered which is probably going to be harder to automate. Nevertheless, I agree, it is not such a big deal. As for Liri, we're now discussing different options inside of our team. I'm generally very happy with the developer experience of snapcraft and the user experience of snap and I'm really looking forward to see snaps running on Ubuntu phones & tablets. Thanks again for taking your time to help us! All the best, Tim On 08.03.2017 13:48, Mark Shuttleworth wrote: Snaps have a much stronger sense of identity. They *own* /snap/foo and that means you can build a much more predictable and reliable view of their behavior. Versioning is a key part of the snap story, it gives the user and the publiisher of the software a really *great* way to describe what they are releasing or what they are conuming on any particular device. The upstreams and the users that I have talked to generally say they *love* it. The fact that we know exactly where a snap is allows for rich interplay between snaps, like the way snaps can use the core snap, or other snaps through content interfaces. However, all of these things also required that we choose not to mount snaps in arbitrary locations. That ends up driving the requirement that you have administrative rights on a device if you want to change the set of installed snaps, and also that you can only have one active version at a time. In the case of libraries and frameworks, you don't have to worry about persistent data that can or cannot be shared between the two versions. You would need to know the two paths of the two versions *anyway* in order to use them. THere is no semantic difference in your code between /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be more complex one way or the other. Mark On 07/03/17 10:07, Tim Süberkrüb wrote: Hey Sergio and Mark, thanks very much for your help. After discussing different possible solutions in the team and the conversation on rocket chat I think that this is probably the best solution currently possible. We also considered other ways like placing different library versions in the platform snap but that would be in the end much more hassle and much more hacky than separating them. Nevertheless, I still think there could be a better and more convenient solution for this use case though - at least in theory. Sergio explained to me that it is not possible to have different versions of the same snap active, which is - I assume - the main reason why it's impossible to use different versions of the same runtime/platform snap, while Flatpak offers this functionality. I'm not familiar with the technical details of snap. There might be technical or other reasons why this is not something snap should offer. But if it is possible, I think it would be very reasonable to allow snaps to specify a specific version for a content interface plus being able to have separate versions of the same snap installed as long as another app depends on it. This would - if implemented flexible enough - not only benefit our specific use case but anyone who would like to control versioning of snaps connecting with the content interface (e.g. a snap that supports specific plugin versions of some sort of extension). Again, this is just a suggestion, that I as a user without much knowledge about the internals find reasonable. This might not fit in the concept of snaps for a good reason. Thanks for bearing with me! [...] garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules I think that would be good to have! Have a nice day, Tim On 07.03.2017 14:55, Sergio Schvezov wrote: On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: Hi Tim Welcome aboard, and thank you, this is exactly the type of question we want to be solving together on this list. The simplest approach would be to insert a major version/ABI indcation in the platform snap name. Something like lirios3 and lirios4 would be a very explicit way to provided different versions of your libraries. It would have the major benefit that both platform snaps could be installed at the same time
Re: Handling versioning of platform snaps
Hey Sergio and Mark, thanks very much for your help. After discussing different possible solutions in the team and the conversation on rocket chat I think that this is probably the best solution currently possible. We also considered other ways like placing different library versions in the platform snap but that would be in the end much more hassle and much more hacky than separating them. Nevertheless, I still think there could be a better and more convenient solution for this use case though - at least in theory. Sergio explained to me that it is not possible to have different versions of the same snap active, which is - I assume - the main reason why it's impossible to use different versions of the same runtime/platform snap, while Flatpak offers this functionality. I'm not familiar with the technical details of snap. There might be technical or other reasons why this is not something snap should offer. But if it is possible, I think it would be very reasonable to allow snaps to specify a specific version for a content interface plus being able to have separate versions of the same snap installed as long as another app depends on it. This would - if implemented flexible enough - not only benefit our specific use case but anyone who would like to control versioning of snaps connecting with the content interface (e.g. a snap that supports specific plugin versions of some sort of extension). Again, this is just a suggestion, that I as a user without much knowledge about the internals find reasonable. This might not fit in the concept of snaps for a good reason. Thanks for bearing with me! > [...] garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules I think that would be good to have! Have a nice day, Tim On 07.03.2017 14:55, Sergio Schvezov wrote: On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: Hi Tim Welcome aboard, and thank you, this is exactly the type of question we want to be solving together on this list. The simplest approach would be to insert a major version/ABI indcation in the platform snap name. Something like lirios3 and lirios4 would be a very explicit way to provided different versions of your libraries. It would have the major benefit that both platform snaps could be installed at the same time, too, enabling a more natural app transition (each app can choose when to hop from 3 to 4) rather than a big-bang flag day for each device. The downside would be the incremental size of having both installed at once during that transition, but we continually see that 'time is more precious than disk space' so giving users a low-friction way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk. It might be worth looking into the linking of apps to particular tracks, but this raises a lot of tricky questions that I suspect would be a swamp with more problems than solutions. Does that sound like a reasonable starting point? This is what I suggested during the rocket chat conversations and I agree it is the best way to move forward. What is interesting here is (once there is support to bring in default slot implemetations for an interface), to garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules). -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Problems running Qt/QML + Oxide snap
Hi Penk, thanks very much for your reply. I will try it out as soon as possible :) Have a nice day, Tim On 13.09.2016 14:35, Penk Chen wrote: Hi Tim, I'm working on the same idea of snap without any display server, you may try adding this to your wrapper script to disable oxide's sandbox: export OXIDE_NO_SANDBOX=1 And later on you may have a look of the browser-support interface with 'allow-sandbox: false'. Best, penk On Tue, Sep 13, 2016 at 8:01 PM, Tim Süberkrüb <tim.sueberkr...@web.de <mailto:tim.sueberkr...@web.de>> wrote: Hi everyone, today I was trying to snap an application originally created for Ubuntu phone. The app uses Qt5/QML, Ubuntu UI Toolkit, Oxide and Ubuntu Web. Source: https://github.com/tim-sueberkrueb/crazy-mark <https://github.com/tim-sueberkrueb/crazy-mark> snapcraft.yaml: http://paste.ubuntu.com/23173301/ <http://paste.ubuntu.com/23173301/> 1) Running the application using NVIDIA drivers fails, which is a known bug (https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575532 <https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575532>). 2) Running the application using Nouveau drivers fails with the following console output: http://paste.ubuntu.com/23173243/ <http://paste.ubuntu.com/23173243/> snappy-debug.security scanlog: http://paste.ubuntu.com/23173251/ <http://paste.ubuntu.com/23173251/> The application was installed with --devmode and --force-dangerous. I have two questions: 1) Are there any news about the NVDIA driver problem? 2) Am I doing something wrong (regarding Nouveau)? Is this a bug? Can I work around the problem? Thanks in advance! All the best, Tim -- Snapcraft mailing list Snapcraft@lists.snapcraft.io <mailto:Snapcraft@lists.snapcraft.io> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft <https://lists.ubuntu.com/mailman/listinfo/snapcraft> -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Problems running Qt/QML + Oxide snap
Hi everyone, today I was trying to snap an application originally created for Ubuntu phone. The app uses Qt5/QML, Ubuntu UI Toolkit, Oxide and Ubuntu Web. Source: https://github.com/tim-sueberkrueb/crazy-mark snapcraft.yaml: http://paste.ubuntu.com/23173301/ 1) Running the application using NVIDIA drivers fails, which is a known bug (https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575532). 2) Running the application using Nouveau drivers fails with the following console output: http://paste.ubuntu.com/23173243/ snappy-debug.security scanlog: http://paste.ubuntu.com/23173251/ The application was installed with --devmode and --force-dangerous. I have two questions: 1) Are there any news about the NVDIA driver problem? 2) Am I doing something wrong (regarding Nouveau)? Is this a bug? Can I work around the problem? Thanks in advance! All the best, Tim -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
