I'm testing the current buildroot 2016.02-rc2 release. It contains gstreamer1 packages for version 1.6.3, but I would like to build 1.7.2 instead. I successfully updated package definitions for gstreamer1 and the most important plugins to use 1.7.2. However gst-omx has only a 19 months old release archive for the version 1.2.0 for the direct download (https://gstreamer.freedesktop.org/src/gst-omx/) and it fails to compile. So I would like to use the latest version from git repo.
How can I do it? git repository contains a "common" submodule which buildroot's build system cannot handle as it seems. I thought about creating a new release tar.xz package, that would contain everything for building it like all other gstreamer packages, but couldn't find out how those tar.xz packages on the server are generated...
There is indeed no support for submodule in Buildroot, since most of the time, submodules should be packaged as separate packages.
So, for your own testing, you have two options:
1/ You can do a quick test by creating yourself a tarball that contains all the gst-omx source code (including the contents of the common/) subdirectory.
2/ You can package the gstreamer common stuff as a separate package, make your gst-omx package depend on it, and in a pre-configure hook, create a symlink $(#D)/common -> $(GSTREAMER_COMMON_DIR)
Related
There is a github repository that is no longer actively maintained. I want to use the code and move it into my project's components but that is tedious and not sure if that is the best approach.
I just want to bump the version of draftjs used by the repository.
Here is the repo and it uses draft js version 0.10.0
https://github.com/brijeshb42/medium-draft
My local project uses draft js version 0.11.7
This causes errors and incompatibility issues.
What is the best approach when a repository uses an outdated version of a repository used by local project?
Before forking and publishing to npm your own version of that dependencies, you might consider using the package/patch-package
Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package
# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"
In your case, you would be patching the brijeshb42/medium-draft/package.json file.
I've two Swift PM projects, both use some common code which I would like to store perhaps in a separate project, say a library, which then these two would be able to import.
I've used swift init --type library and so on to build a library but is there any other documented way of including it in the other projects without having to submit it to github and providing the link to the repo to the swift package manager?
I'm thinking something around the lines of building the library project and having a script which copy pastes it wherever it needs to be to be accessible to the other projects (in their own directories if need be)
According to the Swift Package Manager Usage documentation a swift package is designed to be used as a git repository.
Simply put: a [Swift] package is a git repository with semantically versioned tags, that contains Swift sources and a Package.swift manifest file at its root.
That said, the dependencies documentation section states that the depedency path can be a local path.
[Dependencies] is the list of packages that the package depends on. You can specify a URL (or local path) to any valid Swift package.
Note that the git tags are useful (needed) to manage which version of a dependent package is included.
// 1.5.8 ..< 2.0.0
.package(url: "path/SharedPackage", .upToNextMajor(from: "1.5.8")),
// Constraint to an arbitrary closed range.
.package(url: "path/SharedPackage", "1.2.3"..."1.2.8"),
// Branch and revision.
.package(url: "path/SharedPackage", .branch("develop")),
Key Points:
Treating the local package as the same local git repository could still align one's workflow with the Swift Package Manager design.
Some remote or additional git repository is not required because local dependency paths of the Swift package(s) can be used.
Basically, using git in a more simplified and streamlined way may be worth considering for the local-only, some-shared-code use case.
A while back I had to use a jQuery plugin in my project. I needed some different functionality,
so I rewrote the plugin and a few days back I published a fork on github. I wanted to add the
package to the bower repository.
The forked repository
I added a bower.json file to the repository and registered the package with the usual "bower register" command.
The problem is, when I try to install my package, bower installs the original script and not the fork.
What I already tried:
At first I thought it's because I didn't make a release, so I fixed that part. But It didn't help.
I also tried to change the version number to the version number of the original script with no luck.
So maybe the bower.json file I wrote was not well written, right? My next attempt was using Bower to
make a propper bower.json file for me using "bower init". No luck.
So what could I be doing wrong?
The GitHub help page defines a fork as a method to use someone else's project as a starting point for your own idea.
That was my intention since I rewrote the plugin to be oo oriented and added some functionality, but 80% of the code
used is still from the original plugin and it didn't feel right to just make a new repository. Should I instead make a new repository
and will registering my repo with Bower work then?
What is the usual approach if you did some medium to major changes to a repository? Do you fork it or publish a new repo?
Do you still make a pull request even if the changes are bigger?
This worked for me :
Fork the repository
Clone on your disk
Increment the version number in bower.json (ex. 2.0.1)
Commit and push
Create a new version tag higher than the forked repository. ex: git tag "2.0.1"
Push : git push --tag
bower install "https://github.com/myname/forkedrepo.git#2.0.1"
You don't need to create a new repository. A fork will work fine.
But you can't overload on someone else's registered package name with bower. It does look like you've changed the name from onepage-scroll to onepage-scroll-extended though.
If you want to figure out what Bower knows about your package:
Do: bower info onepage-scroll-extended
{
name: 'onepage-scroll-extended',
homepage: 'https://github.com/itd24/onepage-scroll-extended',
version: '1.1.1'
}
Available versions:
- 1.1.1
- 1.0.1
Here you can see that it does not have the full bower.json manifest information and the latest information that it has is for version 1.1.1 (not 1.1.3, your latest).
This is because you don't have a v1.1.3 tag in your repository's master branch. I can see a v1.1.1 and v1.2 tag, but no v1.1.3 tag. Create that tag and push it up to GitHub to enable you to bower install that new version.
You may also need to re-run the bower register command to tell it to pick up the latest manifest. This should be happening automatically (AFAIK). You don't include the bower register command that you ran, perhaps you used the wrong repo URL there. You should use something like:
bower register onepage-scroll-extended git#github.com:itd24/onepage-scroll-extended.git
i understand that nuget's package restore downloads and 'installs' the various required packages before building a project. but i can't work out what purpose this actually serves.
as far as i can tell, the 'installation' of a package during the package restore, isn't the same as a package's actual installation - for example, if you do the following:
install the jQuery package (NOTE that this adds jQuery script files to your project's 'Scripts' directory)
delete the added jQuery script files
delete the 'packages' directory (steps 2 & 3 simulate the state on a build machine, or other dev's machine)
do a build (triggering a package restore)
at this point the build states
2> Successfully installed 'jQuery 1.9.1'.
however, the jQuery package's script files are NOT added to the 'Scripts' folder, and the files are NOT added to the project.
this means that you have to check these files into source control anyway.
which also means that when you update this package, you have to manage adding/removing the new/old files (since different, versioned filenames are used). otherwise your 'Scripts' folder fills up with an endless history of versioned script files.
so, if you have to check everything in anyway, and you have to manually manage adding and removing files when updating, what exactly is the benefit of restoring the package on build? what purpose does this serve?
more to the point, why doesn't this serve the obvious purpose: automatically adding the package's files to the project?
Using NuGet Without Committing Packages to Source Control discusses the reason behind package restore.
Package restore means you do not have to check the packages folder into source control. Once enabled for your project it will download the packages and put them back into the packages folder at build time if they are missing. It will not, as you have found, add any package files to your project. In the case of jQuery all the files from the NuGet package are added to your project. Other NuGet packages however include one or more binary files.
I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.
I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.
What are some good practices for version controlling created NuGet packages?
I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.
Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the <version>$version$</version> form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.
In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.