Re: testing new package version

2016-12-20 Thread Andrey Rahmatullin
On Tue, Dec 20, 2016 at 09:20:48PM +0100, Jose Gutierrez de la Concha wrote: > Just found the solution after asking, sorry for the noise. > > For the record the solution was to ping my repository with high priority Or you could pass -t with your repo to achieve temporary pinning. This is offtopic

Re: armel after Stretch

2016-12-20 Thread Russ Allbery
Ian Jackson writes: > I think I will probably do the i386->amd64 crossgrade on chiark some > time during the supported life of stretch. I certainly don't expect > it to be straightforward and I wouldn't dare trust it to a script. > Just a data point. Adding a similar data point for two of my p

Bug#848932: ITP: perl-openssl-defaults -- Version compatibility baseline for Perl OpenSSL packages

2016-12-20 Thread Niko Tyni
Package: wnpp Severity: wishlist Owner: Niko Tyni * Package name: perl-openssl-defaults Version : 1 Upstream Author : Niko Tyni * URL : https://anonscm.debian.org/cgit/pkg-perl/packages/perl-openssl-defaults.git * License : GPL-1+ or Artistic Programming La

Re: testing new package version

2016-12-20 Thread Jose Gutierrez de la Concha
Just found the solution after asking, sorry for the noise. For the record the solution was to ping my repository with high priority vagrant@debian-testing:~$ apt-cache policy zeroc-ice-all-runtime zeroc-ice-all-runtime: Installed: (none) Candidate: 3.6.3-4 Version table: 3.7a3-1 500

testing new package version

2016-12-20 Thread Jose Gutierrez de la Concha
Hi, I'm trying to test a new version of one package I maintain zeroc-ice. The current version in sid/testing is 3.6.3-4 and I want to test a new major release currently in alpha (3.7a3-1). I have build that version and upload it to a repository and configure the repository in my machine. But apt

Bug#848879: RFH: qbzr

2016-12-20 Thread Jelmer Vernooij
Package: wnpp Severity: normal The Bazaar packaging team is fairly understaffed. It would be great if somebody who uses qbzr could help out maintaining its packaging. In particular, the testsuite needs some debugging - it's currently disabled because it occasionally segfaults.

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Ian Jackson
Christoph Biedl writes ("Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)"): > Doing this by hand is of course neither fast nor simple. The migration > script you requested could change that, however it's a delicate job, > full of pitfalls, desaster if anything goes wrong, so no

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Christoph Biedl
[ limiting to devel- ] Wouter Verhelst wrote... > I think a proper procedure should involve a script that: [ sane criteria ] > We currently don't have anything remotely like the above, and I think we > should. Yes, but I doubt it would be used a lot. There's a wide-spread culture of re-install

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Christoph Biedl
Lennart Sorensen wrote... > I actually highly doubt there are that many armv7 boxes running armel. > armhf was a nice performance improvement and worth the hassle to reinstall > if you had such a box in the first place. I think most armel systems > are probably armv5, often the marvell chips. No

Re: depending on libssl1.0-dev, buildd fails to find it

2016-12-20 Thread Guillem Jover
Hi! On Mon, 2016-12-19 at 13:12:32 +0100, Johannes Schauer wrote: > Quoting Mattia Rizzolo (2016-12-18 11:38:24) > > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > > As Arno hinted at, it's to have reliable builds. A transient inability > > > to install the first arm of an alter

Re: depending on libssl1.0-dev, buildd fails to find it

2016-12-20 Thread Wouter Verhelst
On Mon, Dec 19, 2016 at 01:12:32PM +0100, Johannes Schauer wrote: > Hi, > > Quoting Mattia Rizzolo (2016-12-18 11:38:24) > > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > > As Arno hinted at, it's to have reliable builds. A transient inability > > > to install the first arm of

Re: depending on libssl1.0-dev, buildd fails to find it

2016-12-20 Thread Wouter Verhelst
On Mon, Dec 19, 2016 at 09:13:25AM +0100, Daniel Pocock wrote: > Provides: libssl1.0-dev > > in the control file and would that ensure it works without tweaks? It might, but the proper way to fix it is: Build-Depends: libssl1.0-dev (>= 1.0.0) | libssl-dev (<< 1.1) i.e., put what's in unstable f

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Wouter Verhelst
On Sat, Dec 17, 2016 at 08:15:15PM +0800, Paul Wise wrote: > On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote: > > > Yes, but that still says: > > Ack. > > > I think a proper procedure should involve a script that: > > > > - is packaged in Debian; > > Ack. > > > - checks whether the h

Bug#848854: ITP: node-grunt-contrib-copy -- Copy files and folders

2016-12-20 Thread Paolo Greppi
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-copy Version : 1.0.0 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-copy#readme * Li

Bug#848853: ITP: node-grunt-contrib-uglify -- Minify JavaScript files with UglifyJS

2016-12-20 Thread Paolo Greppi
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-uglify Version : 2.0.0 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-uglify#readme