Bug#812761: ITP: flif -- Free Lossless Image Format (FLIF) encoder/decoder
Package: wnpp Severity: wishlist Owner: Jon Sneyers * Package name: flif Version : 0.2.0 Upstream Author : Jon Sneyers * URL : http://flif.info/ * License : Currently: GPLv3+ (encoder), LGPLv3+ (decoder) (will probably change soon to more permissive license) Programming Lang: C++ Description : Free Lossless Image Format (FLIF) encoder/decoder FLIF is a lossless image (and animation) format. It tends to compress better than other image compression formats. This is the reference implementation of the FLIF encoder/decoder. The command-line utility 'flif' converts FLIF to/from PNG or PNM. The source package would have multiple binary packages: - flif (command line tool) - libflif (shared library) - viewflif (simple image/animation viewer) - gif2flif (shell script) - apng2flif (shell script) I am trying to put all necessary Debian packaging config files directly in the upstream git repository, at: https://github.com/FLIF-hub/FLIF Version 0.2.0 of flif has not actually been released yet, the most recent version is 0.2.0rc5, which may or may not become 0.2. At some point in February 2016, I expect to go from "release candidate" to the actual "release". This will be the first 'stable' release (in the sense that the file format will remain compatible). I hope to have flif included in the Debian archive when this release will be announced. I am new at Debian packaging, so while I _think_ most of the packaging work is done, it would help to have a more experienced co-maintainer who can check and improve my effort at packaging. Also I will certainly need a sponsor.
Re: Better Lintian checks
* Sebastiaan Couwenberg , 2016-01-26, 07:45: The use of Multi-Arch: no was suggested by https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html The wording is unfortunate. You should not add "Multi-Arch: no" to the control file, but instead remove the field, because "no" is the default. And most of the time changing multi-archness isn't the correct course of action anyway... The reject message Quoting the reject message would have been helpful... I guess you're referring to this: https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/checks.py?id=c51e71bbd9c2#n392 refers to #768353 which was fixed in November 2014, but the fix is most likely not available in stable yet, The version graph says it's fixed in "dose3/3.3~beta1-3 (stable)". -- Jakub Wilk
Re: Better Lintian checks
On Tue, Jan 26, 2016 at 7:45 AM, Sebastiaan Couwenberg wrote: > On 25-01-16 19:47, Bastien Roucaries wrote: >> I expect more problems detected in the next few days > > I guess the autorejects for Multi-Arch: no are among those problems. > The use of Multi-Arch: no was suggested by > > https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html > > The reject message refers to #768353 which was fixed in November 2014, > but the fix is most likely not available in stable yet, and hence still > an issue on the Debian infrastructure? > > If "Multi-Arch: no support in Debian is broken" is still true, the > suggested fix for old-style-config-script-multiarch-path is not an > actual solution. > > Should the autoreject be removed, or should lintian suggest a different fix? This tag is not on autoreject list. My warning was about https://lintian.debian.org/tags/license-problem-json-evil.html, https://lintian.debian.org/tags/license-problem-cc-by-nc-sa.html, https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html About you remark long term solution is here https://lintian.debian.org/tags/old-style-config-script.html Bastien > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 >
Re: Better Lintian checks
On 2016-01-26 12:10, Jakub Wilk wrote: * Sebastiaan Couwenberg , 2016-01-26, 07:45: The use of Multi-Arch: no was suggested by https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html The wording is unfortunate. You should not add "Multi-Arch: no" to the control file, but instead remove the field, because "no" is the default. The gdal package didn't have any Multi-Arch control fields. And most of the time changing multi-archness isn't the correct course of action anyway... Yeah, Bastiens reference to the suggestion for the general old-style-config-script tag should be the way forward. I just don't have time to fix all reverse dependencies, so I'd like to keep including gdal-config for the time being. The reject message Quoting the reject message would have been helpful... I guess you're referring to this: https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/checks.py?id=c51e71bbd9c2#n392 I quoted most of the reject message except the bug number. The reject in question is here: http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2016-January/042758.html The speed at which it arrived suggests that it's an auto reject, despite Bastien saying that it's not. refers to #768353 which was fixed in November 2014, but the fix is most likely not available in stable yet, The version graph says it's fixed in "dose3/3.3~beta1-3 (stable)". Thanks for the feedback, unfortunately no solution yet. Kind Regards, Bas
Re: Better Lintian checks
* Bas Couwenberg , 2016-01-26, 12:17: The use of Multi-Arch: no was suggested by https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html The wording is unfortunate. You should not add "Multi-Arch: no" to the control file, but instead remove the field, because "no" is the default. The gdal package didn't have any Multi-Arch control fields. This will be fixed in the next Lintian release: https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=20ad1f7fbe12 In the mean time, please add an override for the tag. -- Jakub Wilk
Re: Better Lintian checks
On 2016-01-26 14:41, Jakub Wilk wrote: * Bas Couwenberg , 2016-01-26, 12:17: The use of Multi-Arch: no was suggested by https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html The wording is unfortunate. You should not add "Multi-Arch: no" to the control file, but instead remove the field, because "no" is the default. The gdal package didn't have any Multi-Arch control fields. This will be fixed in the next Lintian release: https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=20ad1f7fbe12 Excellent, thanks! In the mean time, please add an override for the tag. Will do. Kind Regards, Bas
Re: mkdocs locale error building djangorestframework
On Mon, Jan 25, 2016 at 8:12 PM, Ben Hutchings wrote: > On Tue, 2016-01-26 at 11:49 +1100, Brian May wrote: import subprocess rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, > ... stderr=subprocess.PIPE).communicate()[0] type(rv) > > > This is clearly a bug in python3-click. Yes it was. I have just uploaded a fix. -- Alexandre Viau av...@debian.org
Re: Better Lintian checks
Hi Bastien, > Newer unstable Lintian version check now package testsuite for licence > problems/missing source Just FYI, the potential 'source-is-missing' false positive mentioned at the beginning of #798900 [1] still exists, regarding the automatic flagging of JS files with lines > 512 chars as minified although they may not be. The long line in question is also present in the source in my separately packaged version of DataTables, which is built from upstream's source repo exactly to address this borderline case. See [2]. This just popped back on my radar since the recent rewording of the lintian message broke my override ;) Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798900 [2] https://github.com/DataTables/DataTablesSrc/blob/master/js/DataTables.js -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: Bug#782264: grub-install fails in nested LVM
Le 9 avril 2015 18:05:50 GMT+02:00, "Pierre-Elliott Bécue" a écrit : >Source: grub >Version: 2.02~beta2-22 >Severity: important > >Dear maintainer, > >I've met a bug in GRUB under a Proxmox environment, which I was able to >reproduce under a clean Debian system (my laptop, under jessie). > >With Proxmox, I needed to build a nested LVM storage for my VM, that >is, >in the host point of view : > >/dev/sdxx (physical) -> first volumegroup (vg1) -> A single logical >volume (lv1) >(the guest physical disk) -> a single partition (lv1p1) -> a second >volumegroup (vg2) >-> logical volumes containing guest data. (slash, var, swap) > >For the guest, the single logical volume (lv1) is seen as the physical >disk of the VM, named /dev/vda when the VM is started. > >Under wheezy, I was able to debootstrap wheezy on the disks, and to >chroot in them to make a grub-install on lv1. > >Under jessie, I get an error : >grub-install: error: disk >`lvmid/[VOLUMEGROUPID]/[LOGICALVOLUMEID]' >not found. > >I first thought it was a bug due to Proxmox VE. So I tried to build a >proof of concept on my Jessie laptop, using an external drive. The >problem is the same. > >I tried to git clone the grub repo and to compile it to try a >grub-install, and this one worked. So it seems that grub 2.02~beta2-22 >is broken. > >I'm not able to say if it comes from Debian patches or from the actual >upstream code, but it seems this problem is important enough to be >noticed. > >I'll be happy to provide you with more data if I can. > >Cheers, Bump. It's been more than 10 months and still nothing (even a simple ack). Could you consider adding a stable version of grub in a partial release of Jessie? Thanks. -- PEB
Bug#812792: ITP: airlift-slice -- Java library for efficiently working with heap and off-heap memory
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: airlift-slice Version : 0.10 Upstream Author : David Phillips, Dain Sundstrom, Martin Traverso * URL : https://github.com/airlift/slice * License : Apache-2.0 Programming Lang: Java Description : Java library for efficiently working with heap and off-heap memory Slice is a library for working efficiently with heap and off-heap memory. Slice is a dependency required for packaging lucene-solr 5. It'll be maintained by the Java Team.
Bug#812836: ITP: sahara-dashboard -- OpenStack data processing cluster as a service - dashboard plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: sahara-dashboard Version : 4.0.0~b2 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/sahara-dashboard * License : Apache-2.0 Programming Lang: Python Description : OpenStack data processing cluster as a service - dashboard plugin The Sahara project provides a simple means to provision a data-intensive application cluster (Hadoop or Spark) on top of OpenStack. It's the ex Savanna project, renamed due to potential trademark issues. . This package contains the OpenStack dashboard plugin.
