Bug#700040: marked as done (RFS: rspamd/0.5.4-1 [ITP] -- rapid spam filtering system)

2013-06-25 Thread Debian Bug Tracking System 
Your message dated Wed, 26 Jun 2013 04:23:22 +
with message-id 
and subject line closing RFS: rspamd/0.5.4-1 [ITP] -- rapid spam filtering 
system
has caused the Debian Bug report #700040,
regarding RFS: rspamd/0.5.4-1 [ITP] -- rapid spam filtering system
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
700040: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700040
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist
Subject: RFS: rspamd

Dear mentors,

I am looking for a sponsor for my package "rspamd".

* Package name:rspamd
  Version: 0.5.4
  Upstream Author: Vsevolod Stakhov (vsevo...@highsecure.ru)
* URL: https://bitbucket.org/vstakhov/rspamd/
* License: BSD
  Section: mail
  Description: Rapid spam filtering system.

Rspamd is fast and modular spam filtering system written in C using
libevent. Rspamd can be extended by plugins and rules written in lua
language and has many internal modules: regexp, dkim, spf and several
others. Rspamd uses multigramm OSB-Bayes classifier with many options
and features for statistic analyzes.

It builds those binary packages:

rspamd - Fast spam filtering system

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/rspamd

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/r/rspamd/rspamd_0.5.4-1.dsc

I would be glad if someone uploaded this package for me.

--
Vsevolod Stakhov
--- End Message ---
--- Begin Message ---
Package rspamd has been removed from mentors.--- End Message ---

Re: Need detailed help on creating a Debian package (post-install configuration)

2013-06-25 Thread Russ Allbery 
T o n g  writes:

> I've successfully built a package, the building and installation was
> fine. The problem is that when people use Debian packages, they tend to
> assume that the package will work out of the box, whereas this pam-ssh-
> agent-auth PAM module need a bit of post-install configuration before it
> can be used, which I found at
> http://www.evans.io/posts/ssh-agent-for-sudo-authentication/

> I.e., it need to configure 3 system files, /etc/sudoers,
> /etc/pam.d/sudo, and /etc/ssh/sudo_authorized_keys.

> I've trying to automate the configuration as much as possible and have
> created patch files for /etc/sudoers, and /etc/pam.d/sudo:

> etc/sudoers: http://paste.debian.net/12646/
> /etc/pam.d/sudo: http://paste.debian.net/12647/

For /etc/sudoers, the Debian sudo package supports loading configuration
fragments dropped into /etc/sudoers.d.  So you can just install the
configuration fragment there.

For the PAM configuration, do you have to install this module *only* for
sudo and not for any other program?  Normally, in Debian, you would use
the pam-auth-update mechanism to customize common-auth, which handles
things like skipping other modules if an overriding module succeeds.  But
that will of course affect common-auth for all PAM-enabled applications.

If you need to customize *only* /etc/pam.d/sudo, I'm afraid that Debian
Policy says you're not allowed to do that.  Basically, configuration files
are owned by a single package, and only that package may modify it.  That
package *can* provide an interface for modifications that other packages
can use, but for this sort of thing, that's probably overkill.  The
typical thing to do in this sort of situation is to document the required
modification in README.Debian; it's not entirely satisfactory, but
sometimes there isn't another good option.

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


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

Need detailed help on creating a Debian package (post-install configuration)

2013-06-25 Thread T o n g 
Hi, 

The Debian package that I'm trying to create is libpam-ssh-agent
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595817

I need it to rsync files that belong to root between two systems as a 
normal unprivileged user, without specifying password (the root account 
is locked on both of systems, details at 
http://superuser.com/questions/605425/rsync-root-files-between-systems-
without-specifying-password). 

I've successfully built a package, the building and installation was 
fine. The problem is that when people use Debian packages, they tend to 
assume that the package will work out of the box, whereas this pam-ssh-
agent-auth PAM module need a bit of post-install configuration before it 
can be used, which I found at
http://www.evans.io/posts/ssh-agent-for-sudo-authentication/

I.e., it need to configure 3 system files, /etc/sudoers, /etc/pam.d/sudo, 
and /etc/ssh/sudo_authorized_keys.

I've trying to automate the configuration as much as possible and have 
created patch files for /etc/sudoers, and /etc/pam.d/sudo:

etc/sudoers: http://paste.debian.net/12646/
/etc/pam.d/sudo: http://paste.debian.net/12647/

However, that's pretty much all that I know/can do. I don't know what's 
the Debian policy regarding altering system files, i.e., is it OK to use 
my patch files, and if yes, how to automate it in Debian package post-
install configuration.

Please help. details are appreciated. 

Thanks



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kqdn7o$i5$2...@ger.gmane.org

Re: dpkg-deb: error: control directory has bad permissions

2013-06-25 Thread T o n g 
On Mon, 10 Jun 2013 23:47:13 +1000, Stuart Prescott wrote:

>> mk-build-deps is one of the usual way to do this.
> 
> sure. I know that. I just don't understand why that suggestion wasn't in
> the first message. If you're going to go to the trouble of replying to a
> question on the mentors mailing list, why not answer the question?
> "Don't do that" has precisely zero informational value but has more than
> a hint of (unwelcome) hostility.

Thank you very much Stuart to speak out for me. Learning to maintaining 
Debian packages could be very intimidating, and it couldn’t be any worse 
than being intimidated by being labelled as asking "silly" questions. I 
know it's been quite a while, but I was so intimidated that I only have 
the courage to revisit the thread today after getting the initial hostile 
respond. 

It is apparent in OP that I was trying to get depends installed for the 
emacs source package and I only know pbuilder-satisfydepends. I don't 
think anyone would misread that except using it as a lame excuse to cover 
up bullying. It really make me sick that I've been jerked around by some 
people who think they know enough to bully newcomers. 

Thanks again Stuart for trying to set things straight for new people like 
me. 

Thanks



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kqdl37$i5$1...@ger.gmane.org

Re: RFS: s3cmd python module

2013-06-25 Thread Robinson Sathaseevan 
Hi Jakub,

Please see below...


On Thu, Jun 20, 2013 at 8:21 AM, Jakub Wilk  wrote:

> * Robinson Sathaseevan , 2013-06-19, 22:43:
>
>  1. I'm packaging and testing in wheezy, do I have to be using sid?
>>
>
> Yes, you should be build and test your packages in unstable.
>
>
Switched to unstable.


>  lintian4python appears to be only in experimental.
>>
>
> Indeed.


I added experimental to be able to use this package as well.


>
>  2. Should I upgrade packaging to standards version 3.9.4
>>
>
> Yes.


Done.


>  or can I keep at 3.9.3 while I iron out the current packaging issues?
>>
>
> I'm confused. Why do you want to keep 3.9.3?


Laziness. :) No worries, I upgraded.

3. I have addressed the other concerns you have about d/*. I have yet to
> test the fixes you provided for upstream and submit them, however, should I
> patch myself for current package or wait until they are incorporated
> upstream?
>
> It's up to you.
>

I have forked upstream git repository. Then I applied the manpage patch.
Then I fixed the two pyflakes-undefined-names errors. Did a pull request to
get this into main. Until then I created patch in debian for this release.
I did not fix the warnings about "except:" usage.


>
>

> --
> Jakub Wilk
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-mentors-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**20130620122124.GA7217@jwilk.**net
>
>
New changelog reads as follows. Please let me know if I need to correct any
wording (other than of course changing UNRELEASED to experimental):

s3cmd (1.5.0~alpha3-1) UNRELEASED; urgency=low

  [ Jakub Wilk ]
  * Use canonical URIs for Vcs-* fields.

  [ Robinson Sathaseevan ]
  * New upstream release (Closes: #708538):
- debian/patches: refresh.
  * Add debian/patches/fix-undefined-names.patch due to pyflakes errors.
  * Update package maintainer (Closes: #674916).
  * Compute speed and elapsed time for multipart upload (Closes: #683558).
  * Add new python-tz, python-magic dependencies.
  * Update debian/copyright.
  * debian/rules: overwrite to use upstream NEWS file as changelog.
  * debian/control: Bump Standards-Version, no changes required.

 -- Robinson Sathaseevan   Wed, 25 Jun 2013 22:16:22
-0400

Re: Bug#710473: RFS: bats/0.2.0-1

2013-06-25 Thread Russ Allbery 
Grzegorz Niewisiewicz  writes:

> OK, so I'll change to "optional".

> BTW: what kind of packages should be classified as "extra"?

The distinction between optional and extra is basically pointless these
days.  That said, I usually classify packages as extra if they are
particularly obscure, if they are only useful for very specific purposes
(such as all debugging symbol packages), or if they conflict with packages
with a higher priority (such as alternative implementations of the same
functionality).

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


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

Bug#710473: RFS: bats/0.2.0-1

2013-06-25 Thread Grzegorz Niewisiewicz 
On 06/25/2013 01:58 PM, Jakub Wilk wrote:
>>> Why does it need such a new version of coreutils? (This, on the
>>> other hand, might be something worth explaining in the
>>> changelog.) This build-dependency makes the package unbuildable
>>> on i386, which is stuck with an earlier version of coreutils.
>> I changed the dependency to coreutils from stable (>= 8.13-3.3).
>> 
>>> Also, why does it need such a new version of bash?
> 
> Well, you didn't answer my questions. :)

How can I determine the correct version? Can I test it under oldstable
and make a dependency on its versions if the package works?

>>> Why priority "extra"? I'd use "optional".
> 
>> From the Debian Policy: ... I checked the practice in existing
>> packages and I'm a little bit confused. For example the packages
>> python-nose (test discoverer and runner) and libmysqlclient-dev
>> are optional while python-mox (mock object framework) is extra.
>> 
>> What's the rule here? I thought that you don't want to install 
>> development tools unless you have specialized (i.e. programming)
>> needs.
> 
> To give you some numbers: 27% of all binary packages have priority
> extra. 22% of binary packages in section devel have priority
> extra.
> 
> And I bet that most of these are because "extra" used to be
> dh_make's default, not because of deliberate maintainers'
> decisions.
> 

OK, so I'll change to "optional".

BTW: what kind of packages should be classified as "extra"?

Thank you for help!

Regards
--
Grzegorz Niewisiewicz


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ca15b4.9020...@niewisiewicz.pl

Bug#687564: RFS: irstlm/5.80.01-1 -- [ITP] IRST Language Modeling Toolkit

2013-06-25 Thread Jakub Wilk 

Control: noowner -1

It turns out that I won't have time to tackle this ITP. I'm sorry.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130625215140.ga3...@jwilk.net

Re: RFH: Bug#713565: gwyddion: FTBFS: ../libdraw/gwyrgba.h:24:23: fatal error: gdk/gdkgc.h: No such file or directory

2013-06-25 Thread Jan Beyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Paul,

Und es begab sich am 25.06.2013 22:18, dass Paul Gevers schrieb:
> ...
>> I uploaded more recent versions to experimental during the last
>> freeze. What is the policy on getting the latest version from
>> experimental to unstable? Just change in the latest debian/changelog
>> entry from experimental to unstable, update timestamp and reupload?
>> Or create a new changelog-entry?
> 
> Just add a new entry (on top of the experimental entry) with something
> like: * Upload to unstable and you are done.
Okay. Thanks a lot for your help!
I'll do that, as soon as I can compile gwyddion again... ;-)

Best regards,
Jan

- -- 
Jan Beyer   happy Debian Maintainer ;-) 

mailj...@beathovn.deGPG key ID 0x0CA6B4AA
jabber  beath...@jabber.org
web http://www.beathovn.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHJ/eUACgkQ8eMP5QymtKqZqgCaA/n/7Q8CHXtb2pykCJqk8F8P
GQgAn0sz3/pu13d5G+p7gSYSeuExwQDV
=IJLE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c9fde5.5080...@beathovn.de

Re: RFH: Bug#713565: gwyddion: FTBFS: ../libdraw/gwyrgba.h:24:23: fatal error: gdk/gdkgc.h: No such file or directory

2013-06-25 Thread Paul Gevers 
Hi Jan,

On 25-06-13 21:44, Jan Beyer wrote:
> recently I received the bug report below. The problem for the FTBFS is, that
> gwyddion currently seems to not include libgtk2.0-dev (which contains the
> missing header file gdkgc.h) correctly. Gwyddion correctly Build-Depends:
> on libtgtk2.0-dev, but still libtool(?) seems to no longer set the
> necessary -I/usr/include/gtk-2.0 switch any longer. This switch was set
> correctly about a year ago, when I uploaded version 2.28 to unstable.
> Now, neither this version nor the newer 2.31 builds - using the exactly
> same packaging. Both FTBFS with the given error message. So I suspect some
> change somewhere in the toolchain (libtool?/gcc?/...???) which requires an
> update to the packaging. Could anybody please give me some pointer to a
> solution or where I can read something about this?

Sorry, I don't know if there were relevant changes here and what is the
best solution, but.

> (Please CC me in replies, as I am currently not subscribed to -mentors.)

Done

> PS: As I am anyway about asking you:
> I uploaded more recent versions to experimental during the last freeze.
> What is the policy on getting the latest version from experimental to
> unstable? Just change in the latest debian/changelog entry from
> experimental to unstable, update timestamp and reupload? Or create a new
> changelog-entry?

Just add a new entry (on top of the experimental entry) with something like:
  * Upload to unstable
and you are done.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#712610: RFS: meson/0.4.1-22-gea3e8f1-1 [ITP]

2013-06-25 Thread Jussi Pakkanen 
On Sun, Jun 23, 2013 at 7:51 PM, Jakub Wilk  wrote:


> You put dh_python3 call in such a place, that is run when .deb has already
> been created. No wonder it's a no-op that late. :P
>
>>
That's where some googling told me to put it. Location fixed and now it
works. Thanks.


> Filing a wishlist bug against python3-ply would be a good start.


Done, marked it as blocking, too.

RFH: Bug#713565: gwyddion: FTBFS: ../libdraw/gwyrgba.h:24:23: fatal error: gdk/gdkgc.h: No such file or directory

2013-06-25 Thread Jan Beyer 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear mentors,

recently I received the bug report below. The problem for the FTBFS is, that
gwyddion currently seems to not include libgtk2.0-dev (which contains the
missing header file gdkgc.h) correctly. Gwyddion correctly Build-Depends:
on libtgtk2.0-dev, but still libtool(?) seems to no longer set the
necessary -I/usr/include/gtk-2.0 switch any longer. This switch was set
correctly about a year ago, when I uploaded version 2.28 to unstable.
Now, neither this version nor the newer 2.31 builds - using the exactly
same packaging. Both FTBFS with the given error message. So I suspect some
change somewhere in the toolchain (libtool?/gcc?/...???) which requires an
update to the packaging. Could anybody please give me some pointer to a
solution or where I can read something about this?

Thank you very much in advance!

Best regards,
Jan

(Please CC me in replies, as I am currently not subscribed to -mentors.)


PS: As I am anyway about asking you:
I uploaded more recent versions to experimental during the last freeze.
What is the policy on getting the latest version from experimental to
unstable? Just change in the latest debian/changelog entry from
experimental to unstable, update timestamp and reupload? Or create a new
changelog-entry?

-  Original Message 
Subject: [Debian-med-packaging] Bug#713565: gwyddion: FTBFS:
../libdraw/gwyrgba.h:24:23: fatal error: gdk/gdkgc.h: No such file or
directory

Source: gwyddion
Version: 2.28-2
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20130620 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:


The full build log is available from:

http://aws-logs.debian.net/ftbfs-logs/2013/06/20/gwyddion_2.28-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHJ8zsACgkQ8eMP5QymtKoLswCeJkBAIOHoyeWRpmWOxDq6AoXf
LFcAoL1SskpZrSCr+MlW+qD5RSc2rYla
=uhB7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c9f33b.6090...@beathovn.de

Bug#714087: RFS: ipmiutil/2.9.2

2013-06-25 Thread Andy Cress 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ipmiutil", which is a new package.
See Bug #650323 RFP also.

 * Package name: ipmiutil
   Version : 2.9.2
   Upstream Author : Andy Cress 
 * URL : http://ipmiutil.sourceforge.net
 * License : BSD
   Section : utils

  It builds these binary packages:

ipmiutil   - Easy-to-use IPMI server management utilities

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/ipmiutil


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/i/ipmiutil/ipmiutil_2.9.2.dsc

  More information about ipmiutil can be obtained from
http://ipmiutil.sourceforge.net.

  Changes since the last upload:

none


  Regards,
   Andy Cress


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAF=0vVWd==0x9stsbkvzwsmt56p3sl9n4uulehafacwlylu...@mail.gmail.com

Bug#706514: RFS: dcraw/9.17-1

2013-06-25 Thread Oliver Sander 

Hi Anton,
I finally got around to looking at the package again.


Currently getsource doesn't run due to some minor upstream format change.


Can you fix that?


I fixed the first bug it runs into.  It still doesn't seem to work, though.
No idea what is missing.



Yes, but in the previous uploaded version there are in "patch-section"
only Makefile, badpixels and manpages. You have now also configure,
Makefile.in etc.


That's a thing that I still don't understand.  In an AutoTools environment
all you need is configure.in and Makefile.in.  The files configure and
Makefile are then created automatically.  However when I remove configure
and Makefile from the patch, nothing is built at all.


Please, add into the patch only Makefile and badpixels. Manpages can be stored
somewhere in debian-directory (debian/manpages, for example).



All non-upstream manpages are in debian/manpages now.



I have now uploaded dcraw-9.17-1.1, which contains all my fixes and
cleanups in a single changelog entry.


Ok, looks good. Please, clean patches,


see above: The manpages have been removed, but configure and Makefile are still
there.

 try to fix watch-file,

Beyond my time/skill resources.  Besides, the getsource script is not a real
watch file.


use DEP-5 for
copyright,


The standard says this is optional.
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

 check README.debian (update or remove it, if the info is outdated),

Done.


use dcraw.manpages and dcraw.exapmles instead of putting them into the
override_*.


I don't understand what you mean here.

Best,
Oliver



Thanks for your work,

Anton



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c9ab59.4040...@igpm.rwth-aachen.de

Bug#707595:

2013-06-25 Thread Ansgar Burchardt 
On 06/25/2013 14:35, shuerhaaken wrote:
> I'd like to point out that releases of xnoise never require vala for
> building because the release contains the C sources!
>
> Usual configure-make-makeinstall works without vala.

Generated files aren't source (as in "preferred form of modification").

It's a requirement that packages can be built from source (here: vala)
with tools available in Debian. Otherwise it is, for example, not
possible to do security updates.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c994ef.1030...@debian.org

Bug#707595:

2013-06-25 Thread shuerhaaken 
Hello

I'd like to point out that releases of xnoise never require vala for
building because the release contains the C sources!

Usual configure-make-makeinstall works without vala.

bug #705677 should not be a blocker for this ITP bug.

Regards 
Jörn


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1372163755.2559.42.camel@notebook

Bug#710473: RFS: bats/0.2.0-1

2013-06-25 Thread Jakub Wilk 

* Grzegorz Niewisiewicz , 2013-06-25, 00:34:
If Lintian was a bit smarter, it would also emit 
hyphen-used-as-minus-sign for this line:

.RI [ -c ] " file" ...

Fixed. What about the header? Currently it reads:

   bats \- Bash Automated Test Suite

Do we want a hyphen or a minus here?


Keep "\-". That said, at least on Debian system both should work:
http://lists.debian.org/20030327201451.ga8...@riva.ucam.org

Why does it need such a new version of coreutils? (This, on the other 
hand, might be something worth explaining in the changelog.) This 
build-dependency makes the package unbuildable on i386, which is stuck 
with an earlier version of coreutils.

I changed the dependency to coreutils from stable (>= 8.13-3.3).


Also, why does it need such a new version of bash?


Well, you didn't answer my questions. :)


Why priority "extra"? I'd use "optional".



From the Debian Policy:
optional - (In a sense everything that isn’t required is optional, but 
that’s not what is meant here.) This is all the software that you might 
reasonably want to install *if you didn’t know what it was and don’t 
have specialized requirements*. This is a much larger system and 
includes the X Window System, a full TeX distribution, and many 
applications. Note that optional packages should not conflict with each 
other.


extra - This contains all packages that conflict with others with 
required, important, standard or optional priorities, or *are only 
likely to be useful if you already know what they are or have 
specialized requirements* (such as packages containing only detached 
debugging symbols).


So I assumed that a testing tools for developers are in the category of 
specialized requirements.


I checked the practice in existing packages and I'm a little bit 
confused. For example the packages python-nose (test discoverer and 
runner) and libmysqlclient-dev are optional while python-mox (mock 
object framework) is extra.


What's the rule here? I thought that you don't want to install 
development tools unless you have specialized (i.e. programming) needs.


To give you some numbers:
27% of all binary packages have priority extra.
22% of binary packages in section devel have priority extra.

And I bet that most of these are because "extra" used to be dh_make's 
default, not because of deliberate maintainers' decisions.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130625115807.ga3...@jwilk.net

blends-dev gsoc 2013, debian/control file

2013-06-25 Thread Emmanouil Kiagias 
Hello,

I am Emmanouil Kiagias a Debian gsoc student and my mentor is Andreas
Tille. The gsoc project goal is to redesign the metapackage creation for
Debian Blends [1].

I am bringing up a question to this list from the blends-list [2] . We
actually want to achieve architecture dependent metapackages for Blends and
thus now we have to deal me the syntax of the debian/control file. Here is
the part of the discussion[2]:

> On Fri, Jun 21, 2013 at 10:15 AM, Andreas Tille  wrote:
>
> >
> >   --architecture: This is more complex.  Finally we want to build *one*
> >  source package that fits *all* architectures.  For the moment
> >  we could go with the manual specification (or setting the
> >  currrent architecture as default).  However, finally you will
> >  need to dig the archives / ask on mailing lists what syntax to
> >  use to get a source package that will create the right
> >  dependencies according to the architecture the source package
> >  was build on.  There are such packages inside the Debian
> >  archive but I admit I never dealt with this before and also
> >  would need to do some research first
> >  So what we create is a source package containing either one
> >  control file or several of them (one for each architecture)
> >  and once the binary packages are built from this source the
> >  correct architecture needs to come into effect to get the
> >  correct dependencies for this architecture.
> >
> >

> Emmanouil Kiagias  wrote:
> According to this reference about the control file syntax:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html a package can
> have several architectures:
>
> "Specifying a specific list of architectures indicates that the source will
> build an architecture-dependent package only on architectures included in
> the list. Specifying a list of architecture wildcards indicates that the
> source will build an architecture-dependent package on only those
> architectures that match any of the specified architecture wildcards. "
>
> In this case if we can have multiple architectures per package(or eg: "any"
> which matches all Debian architectures ) but: What actually
> blend-gen-control does is that it checks if the "depends" packages if they
> exists in the target architecture, if not it adds the "depends" to
> "suggests" making sure the installation will not try to install an not
> existing package. If we apply the same method for all the possible Debian
> architectures per package, we will end up with having almost an empty
>  "depends" list, and all depends will go to suggests. (only the "all"
> packages will stay as is and the packages which exist for *all* Debian
> architectures), so having a  separate control file for each architecture
> sounds for convincing(for the moment). But the problem/question is that in
> case we have several control files how will the correct
> control/architecture come in effect when the binary packages are buil?t (I
> have to investigate and study more in order to obtain a better/clear
> understanding how this works). Can you suggest any other source than the
> Debian policy about the source syntax we have to use?

Andreas Tille  wrote:

I think the option above is not really what we want / need. We will end up
with packages Pi on architectures Aj where for instance P1 is available on
A1, A2, A3, A4 P2 is available on A1, A3 P3 is available on A1, A4 P4 is
available on A2 etc. You can not really implement this with the syntax
above. I think you might get an idea about a possible solution for instance
from the source package of the binary package openjdk-7-jre. Why do I think
this? When working on web sentinel I stumbled upon the fact that it is
possible that the same binary package can have different descriptions which
can easily be checked via: udd=# SELECT DISTINCT package, architecture,
description from packages where package like 'openjdk-7-jre' ORDER BY
package, architecture ; package | architecture | description
---++--
openjdk-7-jre | amd64 | OpenJDK Java runtime, using Hotspot JIT
openjdk-7-jre | armel | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | armhf | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | i386 | OpenJDK Java runtime, using Hotspot JIT
openjdk-7-jre | ia64 | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | kfreebsd-amd64 | OpenJDK Java runtime, using Hotspot JIT
openjdk-7-jre | powerpc | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | s390 | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | s390x | OpenJDK Java runtime, using Hotspot Zero
openjdk-7-jre | sparc | OpenJDK Java runtime, using Hotspot JIT So here we
have different effective control files from one source for the binaries of
different architectures and thus it coul