Re: Meta-packages for snaps
On 25/03/17 00:27, mhall119 wrote: Usually you would include all related tools in the same snap. Is there a need to having them separate if they all need to be installed together? Mostly that they don't technically _need_ to all be together. I mean, why not split stuff up if its components can be provided independently, allowing the user to pick what bits they want (or not)? Maybe I'm hanging on too much to the deb world, but multiple independent packages with a meta-package to provide the recommended collection, seems like a good pattern in general. But from your answer, I take it that it's not currently possible? -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Meta-packages for snaps
Usually you would include all related tools in the same snap. Is there a need to having them separate if they all need to be installed together? On Mar 24, 2017 6:42 PM, "Joseph Rushton Wakeling" < joseph.wakel...@webdrake.net> wrote: > Hello folks, > > Is it possible -- or are there plans for -- snap 'meta-packages' whose > only job is to make sure that multiple related snap packages get installed > together? > > The use-case I'm thinking of is a collective 'dlang' meta-package that > would install a group of snaps each providing a different tool relating to > the D programming language. > > Thanks & best wishes, > > -- Joe > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Defining multiple (external) snap packages in a single git repo
Hello all, I've been discussing with some of the D language developers about how to move forward with snap packages for the core D tools. The D language project has a dedicated git repo for building packages for various targets [1] and the obvious place to define snap packages would be there. However, would this be able to work with snap-package CI such as build.snapcraft.io or the Launchpad build tools? They both seem rather biased towards the assumption that a single git repo defines a single snap package. An alternative would of course be for D's own CI tools to run `snapcraft cleanbuild` and upload the resulting packages to the store. Any advice on how this could me made workable ... ? Thanks & best wishes, -- Joe [1] https://github.com/dlang/installer -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Meta-packages for snaps
Hello folks, Is it possible -- or are there plans for -- snap 'meta-packages' whose only job is to make sure that multiple related snap packages get installed together? The use-case I'm thinking of is a collective 'dlang' meta-package that would install a group of snaps each providing a different tool relating to the D programming language. Thanks & best wishes, -- Joe -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Snapping scientific software
Hi there! Please bear with my boasting for a while. :-) I just wrote a blog post [1] on my experience with snapping photogrammetry software, that is software which can build a 3D model out of a set of 2D photographs. I also made a video overview of the process: https://www.youtube.com/watch?v=ELHOjC_V-FE What might be of interest to the readers of this mailing list, is that there is a multitude of software tools out there which are not packaged for Linux, mostly because their authors are more interested in programming than in software distribution. That is certainly the case for scientific software, where authors are researchers who excel in their field but who often happen not to be interested in software distribution (presumably because they target other university researchers, who are anyway supposed to hack on the sources). Sometimes they are also not even very good programmers, which can make building their software harder than what it could be. Snapcraft and snaps can be of enormous help in this case. I enjoyed writing those snaps, and despite being initially totally indifferent about these projects, I've ended up contributing to them with pleasure. The bottom line is: if you have time, and are looking for some cool software to snap, have a look for scientific and academic projects. Chances are that they are not packaged for Linux, and that their popularity can benefit a lot from being snapped. At the same time, you'll be making snap more popular, which is always a win. :-) Ciao, Alberto [1]: http://blog.mardy.it/2017/03/making-snap-packages-of-photogrammetry.html -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
is it the gadget snap upgradable?
hi all, I have a doubt. It seem that a gadget can't be upgraded during the lifetime of a supported board. I don't find anything in the snap framework for making it in a transational manner: is my mindset wrong? Thank in advance for any clarification. Nicolino -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Strategy for Snaps with Debugging Symbols
Hi everybody,
My question is in the context of a libvirt & qemu snap but I think it is
worthwhile to discuss that for any software written in C, C++ or other
compiled languages for which debugging symbols can be generated.
A lot of debugging tasks can be solved by looking at logs and {s,l}tracing
but sometimes this is not enough.
With Debian packages the approaches are:
1) to provide your own -dbg package;
2) let https://launchpad.net/ubuntu/+source/pkg-create-dbgsym generate it
and add a ddebs.ubuntu.com repo on demand.
https://wiki.ubuntu.com/Debug%20Symbol%20Packages
https://wiki.ubuntu.com/AptElfDebugSymbols
https://wiki.debian.org/AutomaticDebugPackages
One idea for snaps is to use -dbg tracks which are going to contain snaps
with embedded debugging symbols. Of course, some snaps may contain a number
of services so you'd have to customize your build process and create
additional automation around snapcraft to make it more manageable.
https://snapcraft.io/docs/reference/channels
Another issue is that with separate snaps that would have debugging symbols
you'd have to replace a non-debug snap with a debug snap which would
complicate things if you had a certain state already and did not want a
transactional erase of the state you wanted to debug.
In the case of ddebs you can just download symbols and use them with an
existing application while with a separate snap you need to perform a
replacement.
I was wondering if anybody thought about it yet and, if not, to start this
discussion here.
Thanks in advance!
Best Regards,
Dmitrii Shcherbakov
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
vim snap issue with bad system call
Hello, In order to fit my habit for better experiences (e.g. bundle), I tried to snapcraft the vim snap [1], but after installing the snap and connecting the home interface, I got the weird error of bad system call when vim was closed with ":wq" for write. Another thing I noticed that .vim and .vimrc should be placed in the $HOME/snap/demo-vim/current/, however, I still got the same error there, even if I added undo/backup/swap dirs inside .vimrc. So currently I don't find any clues from syslog about this. Just give me some suggestions if anyone interests vim snap. Here's my .vimrc (just simply test): *set undodir=/home/admin/snap/demo-vim/current/.vim/.undo//* *set backupdir=/home/admin/snap/demo-vim/current/.vim/.backup//* *set directory=/home/admin/snap/demo-vim/current/.vim/.swp//* *set viminfo="NONE"* [1] https://github.com/woodrow-shen/snapcraft-vim.git Thanks, Woodrow -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/m ailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: clarification about review process
hi Seth it seem what i need. Thanks a lot Nicolino Il 24/03/2017 07:36, Seth Arnold ha scritto: > On Fri, Mar 24, 2017 at 05:09:28AM +, Nicolino Curalli wrote: >> I want to build a CI pipeline for test my snap for the fundamental >> requirements to pass the review process before uploading it on store. >> Where could i find something to help me to build this pipeline? > Hi Nicolino, > > Is this what you are looking for? > > https://code.launchpad.net/~store-reviewers/click-reviewers-tools/trunk > > Thanks -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: clarification about review process
On Fri, Mar 24, 2017 at 05:09:28AM +, Nicolino Curalli wrote: > I want to build a CI pipeline for test my snap for the fundamental > requirements to pass the review process before uploading it on store. > Where could i find something to help me to build this pipeline? Hi Nicolino, Is this what you are looking for? https://code.launchpad.net/~store-reviewers/click-reviewers-tools/trunk Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
