Re: Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

On Thu, Jun 18, 2015 at 8:57 PM, Christoph Anton Mitterer wrote: > On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote: >> See previous message. > I've had read that only afterwards, as well as this message. > > >> You will get >> absolutely nowhere continuing to tell people that they need to

Re: Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote: > See previous message. I've had read that only afterwards, as well as this message. > You will get > absolutely nowhere continuing to tell people that they need to drop > everything to scratch your particular itches. I don't think I've as

Work-needing packages report for Jun 19, 2015

The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 664 (new: 1) Total number of packages offered up for adoption: 177 (new: 1) Total number of packages request

Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

On Thu, Jun 18, 2015 at 8:23 PM, Christoph Anton Mitterer wrote: > - still no DSA (or something like that) See previous message. > - still no concentrated effort at the Debian level to pro-actively work > against such sources that include or more or less secretly download > blobs If you have an

Re: Clarifications about the alleged transition to FFmpeg

Hi Alessio, 2015-06-18 19:25 GMT+02:00 Alessio Treglia : > On Thu, Jun 18, 2015 at 5:30 PM, Bálint Réczey wrote: >> While the team has not announced a formal decision the majority of the >> team supports FFmpeg (which you don't ;-). > > I've never denied that: [1] > However you have to give peopl

Re: Clarifications about the alleged transition to FFmpeg

On Thu, Jun 18, 2015 at 5:30 PM, Bálint Réczey wrote: > While the team has not announced a formal decision the majority of the > team supports FFmpeg (which you don't ;-). I've never denied that: [1] However you have to give people enough time to ***think***, ***review*** things, and ***speak up*

Re: Clarifications about the alleged transition to FFmpeg

2015-06-18 18:30 GMT+02:00 Bálint Réczey : > Hi Alessio, > > 2015-06-18 18:00 GMT+02:00 Alessio Treglia : >> Hello everybody, >> >> I am afraid that I have to inform you that Bálint's blog post [1] >> about the current status of libav's provided is untrue as there's >> still a discussion ongoing on

Re: Clarifications about the alleged transition to FFmpeg

Hi Alessio, 2015-06-18 18:00 GMT+02:00 Alessio Treglia : > Hello everybody, > > I am afraid that I have to inform you that Bálint's blog post [1] > about the current status of libav's provided is untrue as there's > still a discussion ongoing on the Debian Multimedia Maintainers' team > mailing li

Clarifications about the alleged transition to FFmpeg

Hello everybody, I am afraid that I have to inform you that Bálint's blog post [1] about the current status of libav's provided is untrue as there's still a discussion ongoing on the Debian Multimedia Maintainers' team mailing list, and a clear outcome is yet to come. We'll eventually get in touch

Bug#789171: ITP: libxmlbird -- XML parser written in Vala

Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org, johan.mattsso...@gmail.com Package name: libxmlbird Version: 1.0.4 Upstream Author: Johan Mattsson URL: http://birdfont.org/xmlbird-

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

On 2015-06-18 02:31:57 + (+), Clint Adams wrote: > No, in this particular case, upstream IS releasing source tarballs > and the packagers are refusing to use them for reasons I find > incomprehensible. Well, for some of the packages in question where I'm involved upstream, we still aren't

Re: preparing for GCC 5, especially libstdc++6

On Thursday 18 June 2015 14:59:39 Matthias Klose wrote: [snip] > I would prefer b), and preparing the packages to build with the gcc-5 from > experimental (not unstable). OK. > Does Qt 5.4.2 change sonames? If not, please > prepare to change the library package names, if new cxx11 symbols are >

RFH: os-autoinst and make test script for d-i

Hi, As Bug#690244 I've filed ITP some years ago... and now I've done it ;) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690244 os-autoinst is automated testing tool for low-level, such as bootloader, kernel and installer using kvm. So, we can test installer automatically, probably some

Re: RFH: dropbear initramfs support

On Thu, Jun 18, 2015 at 03:09:26PM +0200, Guilhem Moulin wrote: > Hi Gerrit, > > On Thu, 18 Jun 2015 at 11:23:04 +, Gerrit Pape wrote: > > Thanks for the help. I'd be happy to have the initramfs functionality > > split out and maintained separately. If a binary/service split is > > necessary

Re: Lintian auto-reject changes

On 13976 March 1977, Matthias Klose wrote: > On 06/17/2015 11:17 PM, Joerg Jaspert wrote: >> Everything hitting "empty-binary-package" is a *nonfatal* reject now. > How does this make packages better? It does not "make packages better". No lintian check (or reject based on one) does it. It helps c

Re: RFH: dropbear initramfs support

Hi Gerrit, On Thu, 18 Jun 2015 at 11:23:04 +, Gerrit Pape wrote: > Thanks for the help. I'd be happy to have the initramfs functionality > split out and maintained separately. If a binary/service split is > necessary, I'd prefer to have a "dropbear" package with the binaries, > and a "dropbe

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

On Sun, Jun 14, 2015 at 06:43:33PM +0200, Marc Haber wrote: > btw, please read up on bug severities. I consider filing this bug as > "grave" quite short of being offensive. If you're genuinely offended by a bug submitter's choice of severity, it's time to take a step back from the computer and get

Re: preparing for GCC 5, especially libstdc++6

On 06/17/2015 09:42 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote: >> Hi, >> >> it's time to prepare for GCC 5 as the default compiler in unstable. >> Compared to earlier version bumps, the switch to GCC 5 is a bit more >> complicated becaus

Re: RFH: dropbear initramfs support

On Sat, May 30, 2015 at 02:09:16AM +0200, Guilhem Moulin wrote: > On Fri, 01 Aug 2014 at 20:29:41 +, Gerrit Pape wrote: > > Generally I'm with upstream who wrote in bug#692932: > >> As Dropbear upstream I'm keen to see this fixed. Given how > >> many Debian Dropbear bugs are in the initramfs po

Re: Lintian auto-reject changes

On 18/06/15 13:00, Jakub Wilk wrote: > * Simon McVittie , 2015-06-18, 11:26: Everything hitting "empty-binary-package" is a *nonfatal* reject now. >>> How does this make packages better? >> By avoiding bugs like . Most packagers meant >> to package something (an

Re: Lintian auto-reject changes

* Simon McVittie , 2015-06-18, 11:26: Everything hitting "empty-binary-package" is a *nonfatal* reject now. How does this make packages better? By avoiding bugs like . Most packagers meant to package something (and it's non-fatal so that metapackages that have n

Re: Lintian auto-reject changes

On 18/06/15 11:17, Matthias Klose wrote: > On 06/17/2015 11:17 PM, Joerg Jaspert wrote: >> Everything hitting "empty-binary-package" is a *nonfatal* reject now. > > How does this make packages better? By avoiding bugs like . Most packagers meant to package somethin

Re: Lintian auto-reject changes

Am 18.06.2015 um 12:17 schrieb Matthias Klose: > On 06/17/2015 11:17 PM, Joerg Jaspert wrote: >> Hi, >> >> we got one more lintian auto-reject active on ftp-master, in dak.git >> commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc >> >> Everything hitting "empty-binary-package" is a *nonfatal* reject

Re: Lintian auto-reject changes

On 06/17/2015 11:17 PM, Joerg Jaspert wrote: > Hi, > > we got one more lintian auto-reject active on ftp-master, in dak.git > commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc > > Everything hitting "empty-binary-package" is a *nonfatal* reject now. How does this make packages better? Is there a