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

[Gergely Nagy]

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/releases/individual/driver/ 
>> xf86-video-ati-(.*)\.tar\.gz
>>
>> debcheckout gives you a debian-unstable branch by default. Then calling
>> the tiny xsf-remote-add-upstream script gets the watch file parsed, and
>> the upstream branch added:
>>   
>> http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xsf-tools.git;a=blob;f=xsf-remote-add-upstream
>>   
>
> That's really cool, but what would be even cooler would be something
> standardized in Debian, so that we all do the same way. Probably
> having your something like your xfs-remote-add-upstream script, but
> built in debcheckout, git-buildpackage or something like that.
>
> Now that you tell about it, I agree that adding yet another field in
> debian/control was short sighted.

While having a standardized way would be useful, there's just so many
workflows, that you can't possibly cover all of them with a single
syntax, and in the end, you'd end up with having to call
package-specific scripts in the source.

We already have Vcs-*, to check out the debian branch. If debian/rules
would have an optional target, similar to get-orig-source, that would
finish checking out the repository, grabbing upstream stuff, and setting
up branches too, that would solve your problem.

debcheckout could be extended to check whether the target exists, and
call it too, so in the end, you'd end up with using a single command,
that gets you what you want.

And we didn't attempt to cover every different case with a single syntax
in debian/control, or another file.

Call this target get-vcs-source or similar, and voila!

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boklrun1@luthien.mhp

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

[Jean-Christophe Dubacq]

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 resize it. It's
>>> easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;)
>>
>> Obviously, you only think of /tmp as mounted on /.
> 
> It was about /tmp on disk in general, but as long as default is to have
> everything on a root partition - it does not matter where exactly it is.
> For more complex configurations I suggested several "Alternatives"
> (e.g. mount-bind to /home/tmp), each of them is usually better than tmpfs,
> and don't need tmpfs-like resizes.
> 
>> This is often seen as not a good move to have a user-writable directory on
>> the system partition(s), since this provides for easy DOS
> 
> DoS like what? /tmp on disk have a 5% safety limit available for system,
> user can "DoS" only his own processes, and he can do that anyway. But
> /tmp on tmpfs is even worse move, since it does not have 5% safety.

1) With 2TB disks, I certainly do not use 5% any more
2) Mysql, apache, postfix, all kind of vital systems, do not run as
root. And if /tmp is full (and mounted on /), / is full (and so is
/var). All kind of mayhem may happen there (I have seen it).

>> (even involuntary; I know of people daily working with 30GB files, and
>> this easily fills the / partition).
> 
> Is there anything better for them than /tmp on disk? If it's a desktop with
> single disk I would suggested them a single root partition (with /tmp on it).
> If it's a server with small root but large /home on RAIDs then I would
> mount-bind /tmp to /home/tmp...

Learning not to use /tmp to place large files. Setting TMPDIR=/home/tmp
is a start, indeed.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: multiarch, required packages, and multiarch-support

[Russ Allbery]

"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
> required package depending on a package, multiarch-support, which is
> only at "standard" priority[2] 

> [1] 
> http://lintian.debian.org/tags/missing-pre-dependency-on-multiarch-support.html
> [2] http://qa.debian.org/debcheck.php?dist=unstable&package=e2fsprogs

> What is the right thing to do to resolve this mutually irreconcilable
> set of complaints from either Lintian or debcheck?

multiarch-support should be priority: required.  It's already a dependency
of several other priority: required packages, such as libselinux1 and
zlib1g.

That implies that in the interim you should ignore debcheck.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa05kxv0@windlord.stanford.edu

multiarch, required packages, and multiarch-support

[Theodore Ts'o]

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 package, multiarch-support, which is
only at "standard" priority[2] 

[1] 
http://lintian.debian.org/tags/missing-pre-dependency-on-multiarch-support.html
[2] http://qa.debian.org/debcheck.php?dist=unstable&package=e2fsprogs

What is the right thing to do to resolve this mutually irreconcilable
set of complaints from either Lintian or debcheck?

Thanks,

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e1sfnez-0006hn...@tytso-glaptop.cam.corp.google.com

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

[Serge]

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 /tmp on disk then resize /tmp on tmpfs, isn't it? ;)
>
> Obviously, you only think of /tmp as mounted on /.

It was about /tmp on disk in general, but as long as default is to have
everything on a root partition - it does not matter where exactly it is.
For more complex configurations I suggested several "Alternatives"
(e.g. mount-bind to /home/tmp), each of them is usually better than tmpfs,
and don't need tmpfs-like resizes.

> This is often seen as not a good move to have a user-writable directory on
> the system partition(s), since this provides for easy DOS

DoS like what? /tmp on disk have a 5% safety limit available for system,
user can "DoS" only his own processes, and he can do that anyway. But
/tmp on tmpfs is even worse move, since it does not have 5% safety.

> (even involuntary; I know of people daily working with 30GB files, and
> this easily fills the / partition).

Is there anything better for them than /tmp on disk? If it's a desktop with
single disk I would suggested them a single root partition (with /tmp on it).
If it's a server with small root but large /home on RAIDs then I would
mount-bind /tmp to /home/tmp...

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneq556_lkm4rblvynfx5ako1qgcllk-kg4jrgxke4vn...@mail.gmail.com

Work-needing packages report for Jun 15, 2012

[wnpp]

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 requested help for: 58 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   gresolver (#677302), orphaned yesterday
 Description: graphical tool for performing DNS queries
 Installations reported by Popcon: 83

452 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   libvncserver (#676895), offered 4 days ago
 Description: API to write one's own vnc server
 Installations reported by Popcon: 19565

   python-minimock (#677174), offered 2 days ago
 Description: simple library for Python mock objects
 Installations reported by Popcon: 22

   remmina (#676894), offered 4 days ago
 Description: remote desktop client for GNOME desktop environment
 Installations reported by Popcon: 29199

   vtun (#677006), offered 3 days ago
 Installations reported by Popcon: 485

149 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 864 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 55215

   asymptote (#517342), requested 1203 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3193

   athcool (#278442), requested 2788 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 88

   balsa (#642906), requested 263 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 249

   bastille (#592137), requested 677 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 220

   boinc (#511243), requested 1253 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1759

   cardstories (#624100), requested 416 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 5

   chromium-browser (#583826), requested 746 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10539

   debtags (#567954), requested 864 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2503

   doc-central (#566364), requested 873 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 207

   elvis (#432298), requested 1802 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 293

   fbcat (#565156), requested 883 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 153

   flightgear (#487388), requested 1454 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 822

   freeipmi (#628062), requested 385 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1471

   gnat-4.4 (#539633), requested 1521 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1658

   gnat-gps (#496905), requested 1386 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 415

   gnupg (#660685), requested 115 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 122686

   golang (#668870), requested 60 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 223

   grub2 (#248397), requested 2957 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 112986

   hfsprogs (#557892), requested 932 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1132

   hotkey-setup (#483107), requested 1479 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 3796

   irssi-scripts (#663577), requested 94 days ago
 Description: collection of scripts for irssi
 Installations reported by Popcon: 1027

   isdnutils (#661110), requested 111 days ago

Re: Is it me or virtualbox memory management crap?

[Serge]

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 and FF profile are on the same partition,
> as I want both to be encrypted. Writing to my disk is normally quite
> fast, but I've noticed indeed that when it's VB that does it, it's slow.
> If I don't find a way, I guess I'll switch back to Xen with NAT...

>> Can you reproduce that with 3.2 kernel?
>
> Why would this change?

I remember seing a thread in LKML with very similar scenarios. Not sure
what kernel version was there, but it was definitely 2.6.*. So I suggested
to check a newer kernel in case it was already fixed. No need to *switch*
to 3.2, just check (e.g. from backports) whether it makes any difference.
You can remove it after the test. :)

>> PS: you can check the output of `latencytop` as well
> zigo@buzig ~$ sudo latencytop
> Please enable the CONFIG_LATENCYTOP configuration in your kernel.
> Exiting...
>
> Is there a kernel module to load? Or is this only available in 3.2?

No, it's an old kernel config parameter. You need to build the kernel with
CONFIG_LATENCYTOP=y in your .config. That suggestion was just in case
you *want* to dig deeper into the problem.

There's another firefox-specific hack you can try, but I would suggest
to check a new kernel first.

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneo854tm0d6vzobdrpgejd8vfb8ufp2pxpz_ysey9an...@mail.gmail.com

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

[Marco d'Itri]

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


signature.asc
Description: Digital signature

Bind9 - anyone know what the maintainer is up to?

[Matthew Grant]

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 of them on bind9.  There is also a
security issue with current bind9  1:9.8.1.dfsg.P1-4 (CVE-2012-1667),
which needs fixing.

Any problems with me doing an NMU to unstable?  If so, which version,
9.8 or 9.9 (easy to strip DFSG non compliant stuff for 9.9)

Just checking before doing anything.  Don't like creating storms when
not needed.

Cheers,

Matthew Grant



signature.asc
Description: OpenPGP digital signature

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

[Chris Halls]

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
  Description : Google Web Toolkit dev and runtime libraries

  Google Web Toolkit (GWT) allows developers to quickly build and
  maintain complex JavaScript front-end applications in the Java
  programming language.

These packages are based on work by Alexandre Rossi, and Charles Plessy.
They will contain the buildtime and runtime libraries from GWT.

Many thanks for the sponsorship of this work by Eucalyptus.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614221341.ga28...@hp-cha.thehalls.de

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

[Chris Halls]

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 templates in pure Java

 JSilver is a pure-Java implementation of Clearsilver. Key benefits of JSilver
 over Clearsilver include:
 
 Performance
  - Templates are only parsed when the file changes - not for each request.
  - Optionally, templates can be compiled directly to Java bytecode, making
rendering super-fast.
  - Once-off template optimization step simplifies template making rendering
   even faster.
  - Internal optimizations to streamline string manipulation.
 
 Avoids the complexities of JNI
  - Avoids the risk of native code taking down the JVM.
  - Avoids JNI marshalling overhead.
  
 Simplifies IDE use (no more forgetting java.library.path).
  - Allows for easy extension in Java
  - API allows template functions to be defined in Java allowing logic to be
pulled out of templates.
  - Custom escaping / text filters can be plugged in.
  - Makes plugging in translations much simpler
(e.g. ).
  - API designed with testability in mind.
  - Custom mechanisms can be plugged in for loading templates and caching.
  - Low-level access to template AST for advanced transformations.

I am packaging this as it is needed as a dependency for Google Web Toolkit.
It is based on the existing package in Ubuntu by Alexandre Rossi.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614220311.ga27...@hp-cha.thehalls.de

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

[Chris Halls]

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 generator

 SableCC is a parser generator which generates fully featured
 object-oriented frameworks for building compilers, interpreters and
 other text parsers.
 
 In particular, generated frameworks include intuitive strictly-typed
 abstract syntax trees and tree walkers. SableCC also keeps a clean
 separation between machine-generated code and user-written code.
 
 This package also contains AntTask, a task to invoke SableCC on grammar 
 files.

I am packaging this as it is needed as a dependency for Google Web Toolkit.
It is based on the existing package in Ubuntu.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120614212112.6636.17036.report...@hp-cha.rugby.credativ.co.uk

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

[Dmitrijs Ledkovs]

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” for that.)
> 

I was undecided whether a new ITP is required or not and whether this
will be classed as a hijack. So I left 7-days for debating on
debian-devel. If there is consensus that it's ok, then I will consider
resheduling.

-- 
Regards,
Dmitrijs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fda5a16.6010...@debian.org

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

[Cyril Brulebois]

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: Digital signature

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

[James McCoy]

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
/ 
openstack
/ 
nova.git

Since devscripts 2.11.7, you can do this:

Vcs-Git: git://anonscm.debian.org
/ 
openstack
/ 
nova.git-b
debian/unstable

I thought the patch that added that also updated the documentation, but it
looks like documentation still needs to be added.

-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 
@ debian.org >

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

[Michael Gilbert]

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 package is built on amd64, its changelog
>> is taken and stuffed it into all of the other 'Multi-Arch: same' +b1
>> packages, which are now called +b2, and all of them uploaded.
>
> For various reasons you cannot do that without a rebuild. (Hint: Files must 
> not
> change, new versions have their versions in various fields.)

Right, there is that additional complexity, but even so I think it
could be made to work.

dpkg-gencontrol could be used to update the Version and any
${binary:Version} fields in the control file.  Also, the package's
md5sums could be regenerated to include the hash for the new
changelog.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MNn+1jxCbf_Gj=g2dH=meooxfggxz+iduge5dopzzd...@mail.gmail.com

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

[Dmitrijs Ledkovs]

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 into Debian. All bugs are fixed ;-)
And there are ~900 users in ubuntu popcon, which suggests that this
package is still useful.

Thanks a lot OXullo for maintaining this package in Ubuntu.
Thanks a lot for Torsten for maintaining it before then.
All three of us are listed in Maintainer/Uploaders fields.

Regards,

Dmitrijs.

 Original Message 
Subject: Processing of libavg_1.7.1-1_amd64.changes
Date: Thu, 14 Jun 2012 20:20:55 +
From: Debian FTP Masters 
To: x...@debian.org

libavg_1.7.1-1_amd64.changes uploaded successfully to localhost
along with the files:
  libavg_1.7.1-1.dsc
  libavg_1.7.1.orig.tar.gz
  libavg_1.7.1-1.debian.tar.gz
  python-libavg_1.7.1-1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

[Stefano Zacchiroli]

[ 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 agree upon a name. But if we want to have hopes to
> > promote it to something more official, I think it should rather be
> > independent from autopkgtest.
> 
> Fully agree. It should be specific to this standard (developed as
> DEP-8), which does not have a name yet apparently?

That's correct, "autopkgtest" itself is the closest thing we have to a
short name for DEP-8. We can also use that has a name and consider it
the name of the test description format instead of the current sole
implementation of it. At this point, it would be as arbitrary as
anything else, so why note.

> > How about something like "XS-Testsuite: runtime", where the key is
> > actually a space separate list of values values.  Right now only
> > "runtime" [1] makes sense, but others might appear in the future.
> 
> Perhaps "system-integration" or "install"/"installed" (as opposed to
> "build" test which are run during package build from debian/rules)
> might be clearer?
> 
> I saw that coming: There would be little dispute about adding a
> header, but lots of difficulty to find a good name. :-)

Nah, we know better :-) As long as it is the field value (rather than
the name) which is dep8-specific, and as long it's open ended, anything
would do.  So if "XS-Testsuite: autopkgtest" is something you could live
with, I think we could just go ahead with it. Could you please amend the
patch in that direction, and making it explicit that one should look for
the chosen tag in a space separated list [1] rather than simply testing
for equality?

Cheers.

[1] or comma separated, I don't particularly care --- go for what works
best for queries performed via python-apt, if there's a notion of
multi-value fields at that level
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Philipp Kern]

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 stuffed it into all of the other 'Multi-Arch: same' +b1
> packages, which are now called +b2, and all of them uploaded.

For various reasons you cannot do that without a rebuild. (Hint: Files must not
change, new versions have their versions in various fields.)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

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

[Thomas Goirand]

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/ 
> xf86-video-ati-(.*)\.tar\.gz
>
> debcheckout gives you a debian-unstable branch by default. Then calling
> the tiny xsf-remote-add-upstream script gets the watch file parsed, and
> the upstream branch added:
>   
> http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xsf-tools.git;a=blob;f=xsf-remote-add-upstream
>   

That's really cool, but what would be even cooler would be something
standardized in Debian, so that we all do the same way. Probably
having your something like your xfs-remote-add-upstream script, but
built in debcheckout, git-buildpackage or something like that.

Now that you tell about it, I agree that adding yet another field in
debian/control was short sighted.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fda359e.7000...@debian.org

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

[Michael Gilbert]

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 archs,

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 stuffed it into all of the other 'Multi-Arch: same' +b1
packages, which are now called +b2, and all of them uploaded.  Those
other architectures didn't undergo a rebuild, but nevertheless, they
got new packages.

Then lets say a +b3 is needed on i386, then the same is done, and the
'Multi-arch: same' amd64 package (and others) get stuffed with the
i386 +b3 changes (which includes the prior amd64 +b2 changelog).

> and one shouldn't have to look up whether
> a package builds m-a:same binaries.

This is a new special case that will need to be handled somehow,
right?  Look-ups are not that expensive; although admittedly the time
spent writing the infrastructure supporting may not be.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MM=NcxfT-kRLtXoA_7_nX+mJRrxW+4vc7eZYenwSn3=u...@mail.gmail.com

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

[Julien Cristau]

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-a:same binaries.  This has been said a few times
already, please drop this thread if you're just going to repeat old
shot-down ideas.

Thanks,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614170704.gz12...@radis.cristau.org

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

[Michael Gilbert]

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 mailing address.  This would also
>> mean rebuilding all of the other architectures for multi-arch same
>> packages so that they all get the same changelog.
>
> No, binNMUs numbers can be different, along with timestamps (even with:
> “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed
> one after each other). Also, reasons can be different.

Right, I imagine it will involving reworking of quite a few steps in
the process, and again this would be only for 'multi-arch: same'.  So,
instead of the buildd (or wherever that is done now) creating the
changelog/timestamp, instead create one 'multi-arch: same' changelog
before passing it off to the buildds, and then after the build is
done, replace the automatically architecture-specific changelog with
the 'multi-arch: same' one.  The reason for rebuilding a 'multi-arch:
same' package by definition should be for the same reason on all
architectures, right?

Non 'multi-arch: same' binnmus would not need to change.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mpnlz6gvczq2scfyzvzu_qvtn_s9ab7+i9kbjozled...@mail.gmail.com

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

[Cyril Brulebois]

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 other architectures for multi-arch same
> packages so that they all get the same changelog.

No, binNMUs numbers can be different, along with timestamps (even with:
“wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed
one after each other). Also, reasons can be different.

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Michael Gilbert]

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 bugs are IMHO
> at most important, not serious. Possibly we could allow one last sourceful
> upload when the transitions all settled, but it would again increase the 
> review
> load on the release team.
>
> IMHO it's on the "if it works, fine, if not, sorry about that" part of the
> list, given that it was finalized so late, with that critical piece missing.

Wouldn't the ideal solution be non-architecture-specific changelogs?
So, a normal binnmu changelog looks like this now:

package (version) sid; urgency=low

  * Binary-only non-maintainer upload for amd64; no source changes.

 -- amd64 Builddd Daemon (barber)
  Tue, 05 Jun 2012 16:33:05
+

which could be changed to something like this instead:

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 other architectures for multi-arch same
packages so that they all get the same changelog.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mpzr8wmwtrg4geqe5tscxhavcbiceny1wnp0zutf_c...@mail.gmail.com

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

[Jonas Smedegaard]

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 : open an HTML file with automatic charset detection

 IO::HTML provides an easy way to open a file containing HTML while
 automatically determining its encoding.  It uses the HTML5 encoding
 sniffing algorithm specified in section 8.2.2.1 of the draft standard.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120614161722.15503.89300.report...@auryn.jones.dk

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

[Cyril Brulebois]

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
> |Vcs-Git-Upstream: |https://github.com/openstack/nova.git
> 
> In case Vcs-Git-Upstream wasn't filled, then |debian-get-git-package
> would do the guess that the master branch is also in the Vcs-Git.

Bloating control is probably a no-no (might be doable if some fields
don't appear in the source/binary packages though).

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/ 
xf86-video-ati-(.*)\.tar\.gz

debcheckout gives you a debian-unstable branch by default. Then calling
the tiny xsf-remote-add-upstream script gets the watch file parsed, and
the upstream branch added:
  
http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xsf-tools.git;a=blob;f=xsf-remote-add-upstream

> 4/ Please comment
> =-=-=-=-=-=-=-=-
> I don't mind if there's another solution than 3/, but I really would
> love if we could achieve 2/. If using new debian/control fields isn't
> a good idea, please explain why and what's the alternative. I though
> that maybe, we could use debian/gbp.conf to do this. If the debian
> branch is made the default one in Alioth, and if the gbp.conf tells
> where to fetch upstream master branch, it seems doable.
> 
> Also, I've noticed that apt-cache show doesn't display the Vcs fields.
> What's the way on the command line, so we could write such a
> script that would clone the repo?

Because you want “apt-cache showsrc”, which is for source packages.
debcheckout does the right thing (if you have deb-src lines).

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Thomas Goirand]

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 the linked website.
>>
>> What I'd like to see in the Debian control file are Vcs-Upstream
>> fields that work like their Vcs- pendents but point to the upstream
>> sources. These URLs would also be linked in the PTS.
>>
>> Does this sound reasonable?
>> 
> I'd rather put it in debian/README.source, I see no need of shoveling
> yet more fields into debian/control. (Yeah, yeah, having it there would
> make it possible to do debheckout --upstream or similar, but.. that
> would be rarely needed enough to use README.source instead).
>   

I've been thinking about this for a long time as well. Thanks Gregor to put
this on the table.

I quite not agree with both "solutions" to use debian/README.source
or debian/upstream. Here's why.

1/ Packaging workflow with upstream Git repository
=-=-=-=-=-=-=-=-
When using Git, it's quite a common practice to only store the debian
branch on Alioth, then have the master branch stored ... upstream.
See for example:

http://openstack.alioth.debian.org/

2/ What do we need
=-=-=-=-=-=-=-=-
It would be really great to have everything stored in debian/control,
so we could write a shell script to fetch all needed branches based
on that. Ideally, I would like to be able to do something like:

debian-get-git-package --clone-source nova

and I would have as a result, a nova clone of:
git://anonscm.debian.org/openstack/nova.git

containing the debian/unstable branch, then a fetch of:
|https://github.com/openstack/nova.git

using the master branch.

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
|Vcs-Git-Upstream: |https://github.com/openstack/nova.git

In case Vcs-Git-Upstream wasn't filled, then |debian-get-git-package
would do the guess that the master branch is also in the Vcs-Git.

4/ Please comment
=-=-=-=-=-=-=-=-
I don't mind if there's another solution than 3/, but I really would
love if we could achieve 2/. If using new debian/control fields isn't
a good idea, please explain why and what's the alternative. I though
that maybe, we could use debian/gbp.conf to do this. If the debian
branch is made the default one in Alioth, and if the gbp.conf tells
where to fetch upstream master branch, it seems doable.

Also, I've noticed that apt-cache show doesn't display the Vcs fields.
What's the way on the command line, so we could write such a
script that would clone the repo?

Thoughts anyone?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fda084b.3010...@debian.org

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

[Marvin Renich]

* 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-building. It may be a useful place to point people, or just lift
> > the good bits from it:
> > 
> > http://wiki.debian.org/Multiarch/HOWTO

Very nice!  Thanks.

> That's quite good, but for release notes I think we would need something
> that more tersely explains what multiarch means and that you *must*
> enable it if you have certain packages installed on certain
> architectures.

Also, please be explicit about what it means to "enable" multiarch in
this context.  I presume, but am not certain, that it means to add the
correct foreign architecture (i386 in the case of wine-unstable?),
modify sources.list if needed, and do aptitude update (or equivalent).
If this is wrong or I am missing a step, I would appreciate
enlightenment!

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614144809.ga13...@cleo.wdw

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

[Simon Chopin]

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

Alot is a text mode mail user agent for the notmuch mail system.
It features a modular and command prompt driven interface to provide
a full MUA experience as an alternative to the Emacs and Vim modes shipped
with notmuch.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614135856.18899.17466.reportbug@mithrandir

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

[Gergely Nagy]

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 Debian control file are Vcs-Upstream
> fields that work like their Vcs- pendents but point to the upstream
> sources. These URLs would also be linked in the PTS.
>
> Does this sound reasonable?

I'd rather put it in debian/README.source, I see no need of shoveling
yet more fields into debian/control. (Yeah, yeah, having it there would
make it possible to do debheckout --upstream or similar, but.. that
would be rarely needed enough to use README.source instead).

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lijqowly.fsf@algernon.balabit

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

[Charles Plessy]

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 linked website.
> 
> What I'd like to see in the Debian control file are Vcs-Upstream
> fields that work like their Vcs- pendents but point to the upstream
> sources. These URLs would also be linked in the PTS.
> 
> Does this sound reasonable?

Dear Gregor,

how about using the debian/upstream file for that purpose ?  We are setting up
a system to parse them and feed their contents to the UDD, that the PTS could
query.  Alternatively, the files are gathered and refreshed for Unstable in a
pool directory accessible via a Subversion repository.

  http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/

  http://wiki.debian.org/UpstreamMetadata

The big advantage of this system is that, assuming that the source package
itself is stored in a VCS, the information can be updated without a sourceful
upload.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120614132208.gc...@falafel.plessy.net

[RFC] Add upstream VCS info to control file

[Gregor Jasny]

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 Vcs-Upstream fields 
that work like their Vcs- pendents but point to the upstream sources. 
These URLs would also be linked in the PTS.


Does this sound reasonable?

Thanks,
Gregor


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd9e02e.6060...@googlemail.com

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

[Ansgar Burchardt]

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/debian/dists/unstable/
> 
> ? We don't build a Contents-source.gz on Ubuntu either.

Contents-* files moved to the component subdirectories (main, contrib,
non-free) where you can also find Contents-source.gz.  As the latter was
only introduced after the move, there is no compat symlink for it.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd9df2b.6020...@debian.org

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

[Martin Pitt]

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.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Martin Pitt]

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 mail Ian directly
(his MTA rejects my mail server).

> Oh, that's nice, thanks! Is the test execution environment something
> that can easily deployed elsewhere?

Not directly yet, but we are planning to. From bottom up it's
autopkgtest running in a VM with a daily development release install
triggered by Jenkins jobs:

  https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/

I'm not sure whether the scripts to do the back and forth
setup/reporting are in some public branch, Jean-Baptiste would know.

Locally I test with something like

  sudo adt-run foo.dsc --- adt-virt-null

which is essentially what these Jenkins jobs do as well.

> I'm also curious about the implementation: do you actually use
> autopkgtest as low level test runner for Jenkins integration or...?

We do. We had to fix a number of bugs there, they just recently were
uploaded to Debian as well (thanks Ian).

> 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/debian/dists/unstable/

? We don't build a Contents-source.gz on Ubuntu either.

> As long as it stays as a XS-* header (which, for the history, it's also
> how Vcs-* fields came into existence), no tool change is needed.

Not needed, but it would be nice if dpkg-source could just add it
automatically, so that developers don't need to care about it.

> We should just agree upon a name. But if we want to have hopes to
> promote it to something more official, I think it should rather be
> independent from autopkgtest.

Fully agree. It should be specific to this standard (developed as
DEP-8), which does not have a name yet apparently?

> How about something like "XS-Testsuite: runtime", where the key is
> actually a space separate list of values values.  Right now only
> "runtime" [1] makes sense, but others might appear in the future.

Perhaps "system-integration" or "install"/"installed" (as opposed to
"build" test which are run during package build from debian/rules)
might be clearer?

I saw that coming: There would be little dispute about adding a
header, but lots of difficulty to find a good name. :-) Perhaps we
should think about an actual name for DEP-8 first (similar to what we
had with DEP-5 -> "copyright 1.0 format"), and then use an
abbreviation of that for the XS-Testsuite: value?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Jonas Smedegaard]

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 builds (and a third one if debuild -tc is 
> > > used). (Maybe less if debian/rules tracks the dependency of 
> > > debian/control on *.cabal, but I’m not sure how reliable this is 
> > > in the when packing and unpacking the sources.)
> > 
> > Not knowing the build-dependencies before building the packjage 
> > sounds... WRONG. Whatever you do to figure them out, please do it 
> > before uploadfing it and trying to do this on a buildd :\
> 
> that’s not what I am saying I would (let my mycomputer) figure them 
> out before uploading, as they would appear in the .dsc file. I was 
> assuming the buildds use the information in the .dsc files to install 
> the build dependencies, but if I read Julien’s mail correctly, this is 
> not the case, so my approach would indeed fail.

Maybe buildds ignore debian/control and instead trust .dsc for needed 
build-dependencies, but if so that's an implementation detail. Debian 
Policy describes that if any build-dependencies are declared in 
debian/control they must be complete.

So as I understand it, your suggested change need (at least) a change of 
Debian Policy.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

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

[Joachim Breitner]

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 if debian/rules tracks the dependency of debian/control on *.cabal,
> > but I’m not sure how reliable this is in the when packing and unpacking
> > the sources.)
> 
> Not knowing the build-dependencies before building the packjage
> sounds... WRONG. Whatever you do to figure them out, please do it before
> uploadfing it and trying to do this on a buildd :\

that’s not what I am saying I would (let my mycomputer) figure them out
before uploading, as they would appear in the .dsc file. I was assuming
the buildds use the information in the .dsc files to install the build
dependencies, but if I read Julien’s mail correctly, this is not the
case, so my approach would indeed fail.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

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

[Bernd Zeimetz]

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. 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 long list of build dependencies. If you’d compare
>>> that to
>>> http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
>>> you’d see that the process of creating the build dependencies is a
>>> mostly mechanical process and doing that manually is a waste of human
>>> developer time and a source for mistakes (which lead to FTBFSes and
>>> hence more waste in buildd and buildd admin time).
>>
>> Other peopel solve this by having a debian/control.in file and having
>> - a debian/control target in debian/rules
>> - having the clean target depend on debian/control.
>>
>> I don't think that your case is special enough to add yet an extra
>> option to dpkg-source. I have two packages where I'm changing much more
>> than the build-dependencies automatically, for example.
> 
> I am aware of approaches using debian/control.in, but I was under the
> impression that during the build, debian/control must not be changed and
> hence this always requires manual interaction. If Updating
> debian/control in the clean target, this is a large step in the right
> direction.

Well, debian/control is not modified at build time anymore. It is
created when *you* build the package before uploading it and should not
be modified afterwards.


> 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 if debian/rules tracks the dependency of debian/control on *.cabal,
> but I’m not sure how reliable this is in the when packing and unpacking
> the sources.)

Not knowing the build-dependencies before building the packjage
sounds... WRONG. Whatever you do to figure them out, please do it before
uploadfing it and trying to do this on a buildd :\


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd9aa93.1000...@bzed.de

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

[Joachim Breitner]

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/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc
> > you see it has a very long list of build dependencies. If you’d compare
> > that to
> > http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
> > you’d see that the process of creating the build dependencies is a
> > mostly mechanical process and doing that manually is a waste of human
> > developer time and a source for mistakes (which lead to FTBFSes and
> > hence more waste in buildd and buildd admin time).
> 
> Other peopel solve this by having a debian/control.in file and having
> - a debian/control target in debian/rules
> - having the clean target depend on debian/control.
> 
> I don't think that your case is special enough to add yet an extra
> option to dpkg-source. I have two packages where I'm changing much more
> than the build-dependencies automatically, for example.

I am aware of approaches using debian/control.in, but I was under the
impression that during the build, debian/control must not be changed and
hence this always requires manual interaction. If Updating
debian/control in the clean target, this is a large step in the right
direction.

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 if debian/rules tracks the dependency of debian/control on *.cabal,
but I’m not sure how reliable this is in the when packing and unpacking
the sources.)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

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

[Bernd Zeimetz]

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 long list of build dependencies. If you’d compare
> that to
> http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
> you’d see that the process of creating the build dependencies is a
> mostly mechanical process and doing that manually is a waste of human
> developer time and a source for mistakes (which lead to FTBFSes and
> hence more waste in buildd and buildd admin time).

Other peopel solve this by having a debian/control.in file and having
- a debian/control target in debian/rules
- having the clean target depend on debian/control.

I don't think that your case is special enough to add yet an extra
option to dpkg-source. I have two packages where I'm changing much more
than the build-dependencies automatically, for example.


Cheers,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd9a18c.6070...@bzed.de

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

[Joachim Breitner]

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 file which is taken into account
by our infrastructure, e.g. the build daemons and tools like apt-get
build-dep. Therefore, the data in .dsc is the effective copy. 

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 long list of build dependencies. If you’d compare
that to
http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
you’d see that the process of creating the build dependencies is a
mostly mechanical process and doing that manually is a waste of human
developer time and a source for mistakes (which lead to FTBFSes and
hence more waste in buildd and buildd admin time).

For binary dependencies, thia issue is solved already: Using substvars
we leave it to the build process to figure out the correct dependencies.
This has worked great so far. I would like to be able to do the same for
build dependencies.

Here is my suggestion: dpkg-source already supports substvars. What
needs to be added:
  * A dpkg-source option to enable all this, say
--enable-control-substvars (meant to go to
debian/source/options)
  * A way to pass the -T option to dpkg-source in
debian/source/options (currently not possible, although this is
not clearly documented)
  * When --enable-control-substvars option is enabled, dpkg-source
will call "debian/rules source-substvars" after "debian/rules
clean" and after creating the debian.tar.gz files, but before
creating the .dsc file¹
  * When creating the .dsc file, substvars specified in the file
specified in -T may be used in Build-Depends and related fields.

One downside is that dpkg-source cannot check the build dependencies
completely when calling debian/source clean, as it does now, but can
only check those that are given directly in debian/rules; at this stage
it should just ignore any substvars.

Comments?

Thanks,
Joachim

¹ Why at this stage? Calculating the precise build dependencies might
involve building the package. Doing it here allows this build to also be
used for creating the binaries, when doing a regular dpkg-buildpackage
build.

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part