Bug#928287: ITP: python-qutip -- python package for simulating the dynamics of open quantum systems
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: python-qutip Version : 4.3.1 Upstream Author : Paul D. Nation and Robert J. Johansson * URL : http://qutip.org/ * License : BSD Programming Lang: Python Description : python package for simulating the dynamics of open quantum systems QuTiP is open-source software for simulating the dynamics of open quantum systems. The QuTiP library depends on the excellent Numpy, Scipy, and Cython numerical packages. In addition, graphical output is provided by Matplotlib. QuTiP aims to provide user-friendly and efficient numerical simulations of a wide variety of Hamiltonians, including those with arbitrary time-dependence, commonly found in a wide range of physics applications such as quantum optics, trapped ions, superconducting circuits, and quantum nanomechanical resonators. This package will be maintained under the Debian Science team.
Re: Preferred git branch structure when upstream moves from tarballs to git
On 29 Apr 2019, Gard Spreemann wrote: >For one of my packages, I maintain two public git branches: one is >upstream/latest, where I've been importing upstream's released tarballs, >and the other is debian/sid that contains the packaging. > >Recently, upstream has finally started using git. What is the >recommended way for me to maintain a sane branch structure for the >packaging repository while starting to use upstream's git master as the >upstream branch to follow? I don't know about recommended, but even though the projects I maintain have git repositories themselves, I only sync their released tarballs. For that, I use git-buildpackage and uscan, more specifically, gbp import-orig --uscan [1], which automatically creates a branch structure similar to yours. As far as I know, you are not required to use git-buildpackage, nor to sync only from released tarballs, but the link below has some guidance on how to sync from upstream repositories, so I hope that helps. [1] https://wiki.debian.org/PackagingWithGit#Importing_upstream_as_tarballs-1 >(My first thought is to track upstream's master as upstream/latest-git >or something, and start merging from that into debian/sid, but I don't >know if there's a better way.) The link above describes a very similar approach.
Re: Preferred git branch structure when upstream moves from tarballs to git
Oh, only now I noticed that this has become a long thread. Sorry for the out-of-context reply. :) On 01 May 2019, Gabriel F. T. Gomes wrote: >On 29 Apr 2019, Gard Spreemann wrote: > >>For one of my packages, I maintain two public git branches: one is >>upstream/latest, where I've been importing upstream's released tarballs, >>and the other is debian/sid that contains the packaging. >> >>Recently, upstream has finally started using git. What is the >>recommended way for me to maintain a sane branch structure for the >>packaging repository while starting to use upstream's git master as the >>upstream branch to follow? > >I don't know about recommended, but even though the projects I maintain >have git repositories themselves, I only sync their released tarballs. >For that, I use git-buildpackage and uscan, more specifically, gbp >import-orig --uscan [1], which automatically creates a branch structure >similar to yours. > >As far as I know, you are not required to use git-buildpackage, nor to >sync only from released tarballs, but the link below has some guidance >on how to sync from upstream repositories, so I hope that helps. > >[1] https://wiki.debian.org/PackagingWithGit#Importing_upstream_as_tarballs-1 > >>(My first thought is to track upstream's master as upstream/latest-git >>or something, and start merging from that into debian/sid, but I don't >>know if there's a better way.) > >The link above describes a very similar approach. >
Minimal X11 footprint will be 5 times bigger with buster
I discovered that even though Xorg explicitly only recommends hardware-backed OpenGL it effectively depends it in buster, bloating minimal disk size of an X11 Debian system from 49 MB to 284 MB. This is reported as bug#928297 but sharing here as well, hoping that someone more knowledgeable than me on OpenGL linkage can find some time to try address this even if late in the freeze. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Preferred git branch structure when upstream moves from tarballs to git
On Wed, May 01, 2019 at 08:14:24AM +0200, Thomas Goirand wrote: > It's basically useless, since upstream repository is just one command > away, with the upstream URL documented in debian/rules. This assumes the upstream URL lives forever. But what if the upstream repo's hoster (let's call it "alioth") goes offline? It's not an unheard of thing: Gitorious, Google Code, etc... To me, having the pristine code in a preferred form for modification in the same place as your packaged version follows the spirit of GPL from 3 decades ago, or the design of .dsc of 2⅔ decades ago that calls for shipping the pristine upstream tarball and Debian patches separately. And today, I really wouldn't call a flat tarball the preferred form for modification. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#928318: ITP: onnxruntime -- scoring engine for Open Neural Network Exchange (ONNX) models
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: onnxruntime Version : 0.4.0 Upstream Author : Microsoft, et al. * URL : https://github.com/Microsoft/onnxruntime * License : MIT Programming Lang: C++ Description : scoring engine for Open Neural Network Exchange (ONNX) models
Bug#928319: ITP: ngraph -- C++ library, compiler and runtime for Deep Learning frameworks
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: ngraph Version : Upstream Author : Nervana / Intel * URL : https://github.com/NervanaSystems/ngraph * License : Apache-2.0 Programming Lang: C++ Description : C++ library, compiler and runtime for Deep Learning frameworks This is a low-level building block for modern deep learning frameworks or inference engines such as Tensorflow and ONNX runtime. I have a good impression on the quality of Intel's open source software. This library should be fine if it doesn't pose a heavy workload on me.
Re: Preferred git branch structure when upstream moves from tarballs to git
Hello, On Wed 01 May 2019 at 09:53PM +0200, Adam Borowski wrote: > On Wed, May 01, 2019 at 08:14:24AM +0200, Thomas Goirand wrote: >> It's basically useless, since upstream repository is just one command >> away, with the upstream URL documented in debian/rules. > > This assumes the upstream URL lives forever. But what if the upstream > repo's hoster (let's call it "alioth") goes offline? It's not an unheard > of thing: Gitorious, Google Code, etc... > > To me, having the pristine code in a preferred form for modification in the > same place as your packaged version follows the spirit of GPL from 3 decades > ago, or the design of .dsc of 2⅔ decades ago that calls for shipping the > pristine upstream tarball and Debian patches separately. And today, I > really wouldn't call a flat tarball the preferred form for modification. Perhaps I'm missing something, but zigo said he was pushing upstream's tags to his repo. Doesn't that cover this? -- Sean Whitton signature.asc Description: PGP signature
Re: Preferred git branch structure when upstream moves from tarballs to git
Sean Whitton writes: > Hello, > > On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > > > As an example: to update to a new upstream release, I ideally just > > have to drop the new upstream tarball, update d/changelog and am > > done. > > As a package maintainer, if you don't keep the whole source package in > git, you're giving up on a lot of the power of git. I can't speak for Ansgar, but “you don't keep the whole source package in Git” is not implied by keeping Debian packaging separate. It's not accurate to the workflow, at least as I described (I don't know Ansgar's case, but nothing he described implies that either). Rather, I keep the Debian packaging source separate from the upstream source. That doesn't preclude Git access to the upstream source, and I frequently use a Git repository cloned from upstream for that. So, the Debian-packaging-in-a-separate-repository does not give up any of the power of Git. > The most significant thing is that you cannot manipulate quilt patches > as commits on a branch. It is also much more involved to cherry pick > commits from upstream branches, and quickly obtain diffs between > Debian's version of the code and arbitrary other branches, to mention > a few other things. The full power of Git is available when I manipulate upstream source to refresh my Debian patches. Indeed, it's even neater to refresh those patches by going straight from the only-upstream-source repository. > I also think that you're doing a disservice to downstream users. If > you're trying to fix a bug in the packaged version of some software on > your computer, you don't care about the distinction between Debian's > packaging scripts and the upstream code. It's all going to be turned > into a .deb once you've fixed your problem. You want the history of > the whole thing. Thus, a git history that contains both the upstream > git history and the Debian maintainer's changes to the packaging > scripts is going to be very useful. A git history of only the Debian > packaging scripts is much less useful. Conversely, I think it does a disservice to downstream users to mix in Debian packaging changes with upstream changes. The separation is useful and much easier to maintain when the repositories are separate. -- \ “Time is the great legalizer, even in the field of morals.” | `\ —Henry L. Mencken | _o__) | Ben Finney
Re: Preferred git branch structure when upstream moves from tarballs to git
On 5/2/2019 7:11 AM, Ben Finney wrote: > Conversely, I think it does a disservice to downstream users to mix in > Debian packaging changes with upstream changes. The separation is useful > and much easier to maintain when the repositories are separate. To be honest the greatest disservice is that we cannot standardize on a single way so that a downstream can just pull all of them and build from them. Instead you need humans analyzing how every single one of them works. Kind regards Philipp Kern
