Re: Handling Multi-Arch packages that must be installed for every enabled architecture?
On Sat, Jun 25, 2016 at 12:04:58PM -0700, Josh Triplett wrote: > > See https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges (and > > links) for more examples, potential solutions and problems/shortcomings > > from each of them. > > The "Install-Same-As" header on that page looks ideal for this case. The devil is in the details, e.g.: "It is only considered installed if it is installed for all architectures that the listed package is installed for" which translates roughly to "implement it in ALL tools, wait for these tools to be released as Debian stable, use it in stable+1" as "considered installed" is a dpkg thing. It also forbids the use of "magic" as hat doesn't play nice with hard rules about package installation states. > Do you know if anyone has looked into what it would take to implement > Install-Same-As in apt? I haven't and so I somehow doubt anyone else has, but who knows… The problem with a possible implementation is that it is in effect a "conditional auto-install enhances" and conditions are hard to implement. Theoretically it is possible to implement that type of conditions with a bunch of virtual packages as a workaround, but in practice apts dependency resolver will not like it, for roughly the same reasons it isn't as good as aptitude in solving sudoku puzzles (not that aptitude will invite you with open arms either, it will just not slam the door in your face). So, an implementation effecting all libapt users instantly via a workaround I would consider highly unlikely. If we talk implementing conditions for real, we are in the flying pigs for human transport department. That would leave us with adding it as "magic" somewhere between apt(-get) and libapt which depending on where it is placed exactly will effect more or less other libapt users which is very rougly proportional to the complexity of implementing the magic in that place. And in all the other places elsewhere to catch the rest of the fish. Disclaimer: This is just an educated guess. I could be entirely wrong. It would be more predictable if more than a few rough ideas existed. Cornercases like upgrading existing systems, opt-in/out configuration and syntax, if multiple packages are mentioned – assuming that is legal – is it an OR or an AND and if the later, does OR exist as | then?, is it a versioned relation, keeping API and/or ABI, what if v2 of a package adds/modifies/removes the field, interaction with autoremove……… Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Tollef Fog Heen writes: > ]] Holger Levsen > >> On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: >> > As I wrote earlier, we're open to making certain features available upon >> > request. In the specific case of the feature that was discussed - could you >> > please elaborate what is missing and what functionality is available on the >> > Enterprise edition that you'd like to be made public? We want to better >> > understand the use-case and the requirements to respond to this request. >> >> I'm obviously not Alex but I also object using a software for Debian's >> own infrastructure which is split into a free and an enterprise version. > > Do you also object to DSA using puppet for configuration management? Would objecting make any difference? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]
Hi all, considering that BOOST 1.60 changes the ABI when compiled with -std >= c++11 versus -std <= c++03 (cf. [1]) , and that g++-6 defaults to -std=c++14 it would probably be a good idea if a boost >= 1.60 version compiled with g++6 would be available from experimental when the bug squashing starts. Best, Gert [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823978
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
]] Philip Hands > Tollef Fog Heen writes: > > > Do you also object to DSA using puppet for configuration management? > > Would objecting make any difference? It's unlikely it'd be a significant factor in making us choose something else. I'm still curious, though. There are significant pieces of free software where there exists commercial and proprietary offerings either extending the software directly or building on it by offering various value adds. As long as the project is run like a free software project, I don't see a problem with this, in particular for the second version, where the value add exists in the form of, say, extra server-side analytics tools. I think it's problematic if enhancements are rejected because it would make the free version compete with the non-free version, which seems to more often be the case for software where the proprietary offering extends the software directly. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#828690: ITP: r-cran-pscbs -- R package: Analysis of Parent-Specific DNA Copy Numbers
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: r-cran-pscbs Version : 0.61.0 Upstream Author : Henrik Bengtsson * URL : https://github.com/HenrikBengtsson/PSCBS * License : GPL-2+ Programming Lang: R Description : R package: Analysis of Parent-Specific DNA Copy Numbers Segmentation of allele-specific DNA copy number data and detection of regions with abnormal copy number within each parental chromosome. Both tumor-normal paired and tumoronly analyses are supported. Prerequisite for cnvkit, to be maintained by Debian Med
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Sun, Jun 26, 2016 at 08:50:05PM +0200, Tollef Fog Heen wrote: > > > Do you also object to DSA using puppet for configuration management? I don't. In fact I wasnt aware puppet is under "non-free" CLA as well. > There are significant pieces of free software where there exists > commercial and proprietary offerings either extending the software > directly or building on it by offering various value adds. As long as > the project is run like a free software project, I don't see a problem > with this, in particular for the second version, where the value add > exists in the form of, say, extra server-side analytics tools. I think > it's problematic if enhancements are rejected because it would make the > free version compete with the non-free version, which seems to more > often be the case for software where the proprietary offering extends > the software directly. I guess I agree. -- cheers, Holger signature.asc Description: Digital signature
Bug#828691: ITP: golang-github-oleiade-reflections -- Golang high level abstractions over reflect library
Package: wnpp Severity: wishlist Owner: Andrew Starr-Bochicchio * Package name: golang-github-oleiade-reflections Version : 0.1.2+git20131121.2.632977f-1 Upstream Author : Théo Crevon * URL : https://github.com/oleiade/reflections * License : Expat Programming Lang: Go Description : Golang high level abstractions over reflect library Reflections Package reflections provides high level abstractions above the golang reflect library. . Reflect library is very low-level and can be quite complex when it comes to do simple things like accessing a structure field value, a field tag... . The purpose of reflections package is to make developers life easier when it comes to introspect structures at runtime. Its API is inspired from python language (getattr, setattr, hasattr...) and provides a simplified access to structure fields and tags. This is required for goss: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804202
Bug#828692: ITP: tasksh -- a shell that wraps Taskwarrior commands
Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" * Package name: tasksh Version : 1.0.0 Upstream Author : Paul Beckingham and Federico Hernandez * URL : http://tasktools.org/projects/tasksh.html * License : MIT Programming Lang: C++ Description : a shell that wraps Taskwarrior commands Tasksh is a shell command that wraps Taskwarrior commands. It is intended to provide simpler Taskwarrior access, and add a few new features of its own. The project is new, bear with us please. Tasksh replaces the built-in shell command of older releases, and the bundled tasksh program of version 2.3.0. The former was very limited and the latter unsupported, buggy and flawed. There has been discussion of a Taskwarrior packaging team in #827819. I would be open to adding this package to the team along with bugwarrior in #810629. --
Re: Vcs-* and shared repos
Hi, Am Freitag, den 24.06.2016, 15:38 +0100 schrieb Jonathan Dowland: > On Fri, Jun 24, 2016 at 03:02:57PM +0100, Joachim Breitner wrote: > > I never really understood why there is a games team; assuming that > > technically, almost every game is an island. (Ok, legal issues might be > > similar). This is a very different situation than programming library > > packaging. > > > > With the Haskell packages, regularly do mass-changes and they work > > well. I can try to dig up some examples from git history, if you are > > interested. > > You're right that games are probably less homogenous than common language > libraries. The kind of mass-changes we were making were therefore quite small, > and usually Debian specific (things like add or change a control field across > all packages, or bump standards version). Nevertheless, it rarely paid off. here is one example that worked well: https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/?id=aacf56121852f0618776bd36f162ba266221c674 Another example is mentioned in https://lists.debian.org/debian-haskell/2013/10/msg7.html that shows our "mass change" script (now "dht mass-change" in of pkg- haskell-tools). That was still when when every package had its own repository, so there are now many commits from that invocation; if I’d run this command now it would produce only a single commit. From "man dht": dht mass-change Usage: dht mass-change [-n] [MESSAGE] [ACTION] DIRECTORY ... This script runs ACTION in each of the given directories. If the ACTION ef‐ fected a change, it will add MESSAGE to the changelog. It assumes that all directories are in the same git repository as this script. It ensures that the repository is clean to begin with, and will commit all changes at once at the end, if there was a change. Greetings, Joachim -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
