Bug#677474: Substvars for Build-Depends in the .dsc file

Package: dpkg-dev Version: 1.16.4.2 Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Dear developers, currently a Debian source package specifies its build dependencies in debian/control; this information gets copied by dpkg-source to the .dsc file. From there it reaches the Source

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

Hi, > I would like to see more flexibility in dpkg-source as to where the > effective build depends come from. My use case are (as you might guess) > Haskell packages. If you look at > http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc > you see it has a very lo

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

Hi Bernd, Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz: > > I would like to see more flexibility in dpkg-source as to where the > > effective build depends come from. My use case are (as you might guess) > > Haskell packages. If you look at > > http://ftp.de.debian.org/debian/

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

On 06/14/2012 11:04 AM, Joachim Breitner wrote: > Hi Bernd, > > Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz: >>> I would like to see more flexibility in dpkg-source as to where the >>> effective build depends come from. My use case are (as you might guess) >>> Haskell packages

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

Hi, Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz: > > The only problem I see with this is that if the build dependencies can > > only be calculated after a full build, building source and binaries > > requires two builds (and a third one if debuild -tc is used). (Maybe > > less

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

On 12-06-14 at 11:13am, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz: > > > The only problem I see with this is that if the build dependencies > > > can only be calculated after a full build, building source and > > > binaries requires two bu

Re: DEP-8 extension proposal: Add source package header

Hello Stefan, Stefano Zacchiroli [2012-06-13 23:42 +0200]: > [ Adding autopkgtest-devel to recipients, where I've also just bounced > your mail. If you're interested in this topic, please consider > subscribing to that, very low traffic, list. ] Subscribed. Thanks for bouncing it, as I cannot

Re: DEP-8 extension proposal: Add source package header

Martin Pitt [2012-06-14 14:48 +0200]: > Right, that would do as well. However, I don't see this on > > http://ftp.debian.org/debian/dists/unstable/ Nevermind, found it; it's by-component apparently. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubun

Re: DEP-8 extension proposal: Add source package header

On 06/14/2012 02:48 PM, Martin Pitt wrote: > Stefano Zacchiroli [2012-06-13 23:42 +0200]: >> As a temporary alternative to a hardcoded list, Stuart's proposal to use >> Contents-source.gz is clearly better. > > Right, that would do as well. However, I don't see this on > > http://ftp.debian.org

[RFC] Add upstream VCS info to control file

Hello, When one tries to fix a FTBFS bug a look into the upstream VCS is often helpful. Sometimes a link to browse them is easily found on the homepage linked from the PTS page. But often these links are deeply buried in the linked website. What I'd like to see in the Debian control file are

Re: [RFC] Add upstream VCS info to control file

Le Thu, Jun 14, 2012 at 02:59:26PM +0200, Gregor Jasny a écrit : > > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on > the homepage linked from the PTS page. But often these links are > deeply buried in the linke

Re: [RFC] Add upstream VCS info to control file

Gregor Jasny writes: > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on the > homepage linked from the PTS page. But often these links are deeply > buried in the linked website. > > What I'd like to see in the De

Bug#677522: ITP: alot -- Text mode MUA using notmuch mail

Package: wnpp Severity: wishlist Owner: Simon Chopin * Package name: alot Version : 0.3.1 Upstream Author : Patrick Totzke * URL : http://github.com/pazz/alot/ * License : GPL-3 Programming Lang: Python Description : Text mode MUA using notmuch mail A

Re: Migration path for 'Multi-Arch:allowed' packages

* Ben Hutchings [120613 23:56]: > On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote: > > I added a user-oriented HOWTO to the multiarch doc-collection last > > month as there seemed to be a shortage of such docs to point to that > > weren't cryptic specifications, or talking mostly about > > cross-b

Re: [RFC] Add upstream VCS info to control file

On 06/14/2012 09:23 PM, Gergely Nagy wrote: > Gregor Jasny writes: > >> When one tries to fix a FTBFS bug a look into the upstream VCS is >> often helpful. Sometimes a link to browse them is easily found on the >> homepage linked from the PTS page. But often these links are deeply >> buried in

Re: [RFC] Add upstream VCS info to control file

Thomas Goirand (14/06/2012): > 1/ […] 2/ […] > 3/ How to achieve it > |=-=-=-=-=-=-=-=- > |To acheive this, we would need something like this: > > ||Vcs-Git-Debian-Branch-Name: debian/unstable > ||Vcs-Git: |git://anonscm.debian.org/openstack/nova.git > |||Vcs-Git-Upstream-Branch-Name: master > |V

Bug#677531: ITP: libio-html-perl -- open an HTML file with automatic charset detection

Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libio-html-perl Version : 0.04 Upstream Author : Christopher J. Madsen * URL : http://search.cpan.org/dist/IO-HTML/ * License : Artistic or GPL-1+ Programming Lang: Perl Description

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Fri, Jun 8, 2012 at 6:17 PM, Philipp Kern wrote: > On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: >> Does this mean M-A:same packages should be prevented from being >> binNMUed, but only source upload can be accepted? > > You cannot deprive the Release Team of this tool. Also multiarch

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

Michael Gilbert (14/06/2012): > package (version) sid; urgency=low > > * Binary-only non-maintainer upload; no source changes. > > -- Debian Release Team Tue, 05 Jun > 2012 16:33:05 + > > or some other appropriate binnmu mailing address. This would also > mean rebuilding all of the ot

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Thu, Jun 14, 2012 at 12:40 PM, Cyril Brulebois wrote: > Michael Gilbert (14/06/2012): >> package (version) sid; urgency=low >> >>   * Binary-only non-maintainer upload; no source changes. >> >>  -- Debian Release Team  Tue, 05 Jun >> 2012 16:33:05 + >> >> or some other appropriate binnmu m

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: > Wouldn't the ideal solution be non-architecture-specific changelogs? No, that would be very much non-ideal. One should be able to schedule binNMUs for a subset of archs, and one shouldn't have to look up whether a package builds m-

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Thu, Jun 14, 2012 at 1:07 PM, Julien Cristau wrote: > On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: > >> Wouldn't the ideal solution be non-architecture-specific changelogs? > > No, that would be very much non-ideal.  One should be able to schedule > binNMUs for a subset of arc

Re: [RFC] Add upstream VCS info to control file

On 06/15/2012 12:03 AM, Cyril Brulebois wrote: > Anyway, here's what I've been doing for our 150+ X packages: > > $ cat xserver-xorg-video-ati.git/debian/watch > #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati > version=3 > http://xorg.freedesktop.org/releases/individual/driver/ > x

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote: > I did not suggest that. Anyway, maybe this will be a bit clearer. > Let's say an existing package is at version +b1 on amd64, and it needs > to get a binnmu, then a +b2 package is built on amd64, its changelog > is taken and stuffe

Re: DEP-8 extension proposal: Add source package header

[ M-F-T: autopkgtest-devel + people possibly not subscribed ] On Thu, Jun 14, 2012 at 02:48:58PM +0200, Martin Pitt wrote: > > Oh, that's nice, thanks! Is the test execution environment something > > that can easily deployed elsewhere? Thanks for the technical overview. > > We should just agre

Fwd: Processing of libavg_1.7.1-1_amd64.changes

Dear all, I have uploaded libavg_1.7.1-1 into delayed/7 queue. After that it will hit new, as it was previously removed. Previously this package was removed due to being RC buggy and not used. The maintainance of this package has been picked in Ubuntu. I am now reintroducing this package back int

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

On Thu, Jun 14, 2012 at 3:43 PM, Philipp Kern wrote: > On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote: >> I did not suggest that.  Anyway, maybe this will be a bit clearer. >> Let's say an existing package is at version +b1 on amd64, and it needs >> to get a binnmu, then a +b2 pack

Re: [RFC] Add upstream VCS info to control file

On Jun 14, 2012 11:51 AM, "Thomas Goirand" @ debian.org > wrote: > > 3/ How to achieve it > |=-=-=-=-=-=-=-=- > |To acheive this, we would need something like this: > > ||Vcs-Git-Debian-Branch-Name: debian/unstable > ||Vcs-Git: > |git://anonscm.debian.org

Re: Fwd: Processing of libavg_1.7.1-1_amd64.changes

Dmitrijs Ledkovs (14/06/2012): > I have uploaded libavg_1.7.1-1 into delayed/7 queue. After that it > will hit new, as it was previously removed. Why the seven days delay? It looks to me like you could/should skip that. (dcut has “reschedule” for that.) Mraw, KiBi. signature.asc Description: D

Re: Fwd: Processing of libavg_1.7.1-1_amd64.changes

On 14/06/12 22:37, Cyril Brulebois wrote: > Dmitrijs Ledkovs (14/06/2012): >> I have uploaded libavg_1.7.1-1 into delayed/7 queue. After that it >> will hit new, as it was previously removed. > > Why the seven days delay? It looks to me like you could/should skip > that. (dcut has “reschedule” fo

Bug#677567: ITP: sablecc -- Object-oriented fully featured parser generator

Package: wnpp Severity: wishlist Owner: Chris Halls Package name: sablecc Version : 3.2 Upstream Author : Etienne M. Gagnon and others URL : http://www.sablecc.org/ License : LGPL Programming Lang: Java Description : Object-oriented fully featured parser genera

Bug#677569: ITP: jsilver -- Clearsilver templates in pure Java

Package: wnpp Severity: wishlist Owner: Chris Halls Package name: jsilver Version : 1.0.0 Upstream Author : David Beaumont, Ben Dodso URL : http://code.google.com/p/jsilver License : Apache 2.0 Programming Lang: Java Description : Clearsilver temp

Bug#677571: ITP: gwt -- Google Web Toolkit dev and runtime libraries

Package: wnpp Severity: wishlist Owner: Chris Halls Package name: gwt (binaries libgwt-dev-java and libgwt-user-java) Version : 2.4.0 Upstream Author : Google Inc URL : http://google-web-toolkit.googlecode.com License : Apache 2.0 Programming Lang: Java

Bind9 - anyone know what the maintainer is up to?

Hi! Just wondering how busy he is. Just that it would be good to have Bind 9.9.1 in wheezy instead of 9.8.3 etc. Major performance improvements, and some critical fixes for DNSSEC dynamic DNS re a race condition with rndc corrupting dynamic zones. ;-{ I can file a bug, but there is a pile o

Re: Bind9 - anyone know what the maintainer is up to?

On Jun 15, Matthew Grant wrote: > Just wondering how busy he is. Just that it would be good to have Bind Probably a lot. Did you ask him if he would like the help of a co-maintainer? Did you try sending patches for open bugs? Uploading a new release is the easy part of the job. -- ciao, Marco

Re: Is it me or virtualbox memory management crap?

2012/6/13 Thomas Goirand wrote: >> Do you use 2.6 kernel and have FF profile and VB images on the same ext4 >> partition? > > My laptop setup is: > - kernel 2.6.32-5 (Squeeze...) > - RAID1 (replacing my thinkpad DVD ultrabay by a 2nd HDD) > - LVM > - dm-crypt > - ext3 > > Yes, both the VB images a

Work-needing packages report for Jun 15, 2012

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: 453 (new: 1) Total number of packages offered up for adoption: 153 (new: 4) Total number of packages request

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

2012/6/13 Jean-Christophe Dubacq wrote: >> Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 >> commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on >> disk, because it's large by default and you don't need to resize it. It's >> easier to NOT resize /t

multiarch, required packages, and multiarch-support

If a required package (such as e2fslibs, which is required by e2fsprogs) provides multiarch support, then Lintian requires that the package have a dependency on the package "multiarch-support"[1]. However, this causes debcheck to complain because you now have a required package depending on a pac

Re: multiarch, required packages, and multiarch-support

"Theodore Ts'o" writes: > If a required package (such as e2fslibs, which is required by e2fsprogs) > provides multiarch support, then Lintian requires that the package have > a dependency on the package "multiarch-support"[1]. > However, this causes debcheck to complain because you now have a >

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

On 15/06/2012 03:11, Serge wrote: > 2012/6/13 Jean-Christophe Dubacq wrote: > >>> Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 >>> commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on >>> disk, because it's large by default and you don't need to r

Re: [RFC] Add upstream VCS info to control file

Thomas Goirand writes: > On 06/15/2012 12:03 AM, Cyril Brulebois wrote: >> Anyway, here's what I've been doing for our 150+ X packages: >> >> $ cat xserver-xorg-video-ati.git/debian/watch >> #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati >> version=3 >> http://xorg.freedesktop.org