Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Sven Joachim]

On 2011-05-26 08:03 +0200, Raphael Hertzog wrote:

> On Wed, 25 May 2011, Lucas Nussbaum wrote:
>> It also seems that repositories hosted in public_git don't show up on
>> gitweb anymore. Example:
>> http://anonscm.debian.org/gitweb/?p=users/lucas/packaging-tutorial.git
>> I agree that most of them should be moved to a packaging team, but
>> sometimes it makes sense to host temporary repos in one's home.
>
> This has been fixed in the mean time. The main listing still only shows a
> subset of repositories but if you know the correct url, then you can at
> least access it.

But the Vcs-Browser field from debian/control still does not work, links
on packages.qa.debian.org lead to a 404:

The requested URL /gitweb/gitweb.cgi was not found on this server.

Sven


-- 
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/87wrhducz6@turtle.gmx.de

Bug#627983: ITP: bmake -- Portable version of NetBSD's make

[Jeroen Schot]

Package: wnpp
Severity: wishlist
Owner: Jeroen Schot 

* Package name: bmake
  Version : 20110505
  Upstream Author : Simon J. Gerraty  
* URL : http://www.crufty.net/help/sjg/bmake.html
* License : BSD
  Programming Lang: C
  Description : Portable version of NetBSD's make

This is a portable version of the make from NetBSD. The bmake program
aids automatic building and installing of software with the help
Makefiles.


Note: Debian already contains pmake, also derived from NetBSD's make.
But pmake is a manual sync from NetBSD and thus difficult to maintain
(and as a consequence outdated). Bmake has a active upstream.



-- 
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/20110526072944.26997.81994.reportbug@evariste.localdomain

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Bernd Zeimetz]

On 05/25/2011 03:04 PM, Stefano Zacchiroli wrote:

> How about posting those rewrites here or, even better, helping out the
> Alioth admins to deploy them?  I guess they could use some helping hands
> more than a "bug report" sent to -devel.

They are well documented in /usr/share/doc/gitweb/README with various
examples. I'm using


RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^/$ /index.html [L]

RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^.*$  /gitweb.cgi%{REQUEST_URI}  [L,PT]

RewriteCond %{REQUEST_URI} ^/.+\.git.*$
RewriteCond %{REQUEST_URI} !^/repos/.*$
RewriteRule ^.*$  /gitweb.cgi%{REQUEST_URI}  [L,PT]


which should be similar to alioth's needs.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 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/4dde08ae.9040...@bzed.de

Please reconsider public vcs naming on alioth

[Bernhard R. Link]

If I have to guess what git.someorg.tld is, I'd guess one of
the following (in this order):

- a host offering git:// protocoll
- a host offering public access to git repositories over http://
- a host offering a web view of git repositories.

With the new alioth setup all those three are the same host as
far as I do understand it, to it is utterly unintuitive to have
none of those functions under the name git.debian.org but instead
the host storing the data and offering ssh access. [1]

With all due respect to the great work you do maintaining alioth
and understanding that after such a big transition it can be
annoying to have to change things again I really want to urge
you to change that again.

Not changing it now most likely means Debian is stuck for a very
long time with this extremly confusing host naming.

On the plus side changing it now would also mean all the other DDs
would not need to change all the package control files and all the
documentation and links to the repositories, so if there is anything
I can do to make this switch easier for you let me know.

Please, please, please,

Bernhard R. Link

[1] It feels like www.debian.org being the host running wml,
while http would be redirected to some anonwww.debian.org
serving the pages.


-- 
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/20110526081833.ga8...@pcpool00.mathematik.uni-freiburg.de

Re: .la file status and hint to clear the dependency_libs field

[Simon McVittie]

On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote:
> Comments welcome, but foremost I'd like a mass effort to clear the
> remaining dependency_libs fields! :-)

Am I right in thinking that this is the process people should follow?

if depended-on:
if dependency_libs:
clear the dependency_libs
else:
do nothing (until you are no longer depended-on)
else:
if dependency_libs:
clear the dependency_libs

if you are confident that it won't break anything:
delete the .la file entirely

Regards,
S


-- 
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/20110526084624.ga25...@reptile.pseudorandom.co.uk

Re: Bug#627983: ITP: bmake -- Portable version of NetBSD's make

[Andrew O. Shadoura]

Hello,

On Thu, 26 May 2011 09:29:44 +0200
Jeroen Schot  wrote:

> * Package name: bmake
>   Version : 20110505
>   Upstream Author : Simon J. Gerraty  
> * URL : http://www.crufty.net/help/sjg/bmake.html
> * License : BSD
>   Programming Lang: C
>   Description : Portable version of NetBSD's make

> This is a portable version of the make from NetBSD. The bmake program
> aids automatic building and installing of software with the help
> Makefiles.

> Note: Debian already contains pmake, also derived from NetBSD's make.
> But pmake is a manual sync from NetBSD and thus difficult to maintain
> (and as a consequence outdated). Bmake has a active upstream.

Alexey Cheusov and me are already working on creation of the package
for bmake, so you can join our team instead of doing this on your own.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Raphael Hertzog]

On Thu, 26 May 2011, Sven Joachim wrote:
> But the Vcs-Browser field from debian/control still does not work, links
> on packages.qa.debian.org lead to a 404:
> 
> The requested URL /gitweb/gitweb.cgi was not found on this server.

That was a temporary glitch, it's fixed now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110526091655.ga32...@rivendell.home.ouaza.com

Re: Bug#627983: ITP: bmake -- Portable version of NetBSD's make

[Jeroen Schot]

Hi,

On Thu, May 26, 2011 at 11:58:49AM +0300, Andrew O. Shadoura wrote:
> Alexey Cheusov and me are already working on creation of the package
> for bmake, so you can join our team instead of doing this on your own.

Good to hear. I've already had contact with Alexey. I'm more than
happy to work together on this. Any resources (Alioth project, VCS
repo) I can check? 

Regards,
-- 
Jeroen Schot


signature.asc
Description: Digital signature

Re: .la file status and hint to clear the dependency_libs field

[Laurent Bigonville]

Hi,

> sed -i "/dependency_libs/ s/'.*'/''/"
> "$(CURDIR)/debian//usr/lib/"
> 
> Comments welcome, but foremost I'd like a mass effort to clear the
> remaining dependency_libs fields! :-)

gnome-pkg-tools package is already providing a cdbs makefile snippet
that does the same thing on all .la files.

I've also opened a bug (#586082) a year ago asking if this snippet
could be added to cdbs directly, but nothing so far. I guess that step
would help a bit in reaching the goal.

Cheers

Laurent Bigonville

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082


-- 
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/20110526111625.07581...@eldamar.bigon.be

Re: Bug#627983: ITP: bmake -- Portable version of NetBSD's make

[Andrew O. Shadoura]

Hello,

On Thu, 26 May 2011 11:09:27 +0200
Jeroen Schot  wrote:

> > Alexey Cheusov and me are already working on creation of the package
> > for bmake, so you can join our team instead of doing this on your
> > own.

> Good to hear. I've already had contact with Alexey. I'm more than
> happy to work together on this. Any resources (Alioth project, VCS
> repo) I can check? 

First of all,
http://mova.org/~cheusov/pub/debian/dists/lenny/main/source/

Here are the original packages by Alexey. They have some problems, they
aren't really policy-compliant and so on. I did some work on some of
them, mostly bmake. I keep it versioned in Mercurial repository here:
  http://anonscm.debian.org/hg/collab-maint/bmake/
  http://anonscm.debian.org/hg/collab-maint/pkgsrc-mk-files/ (not much
here yet).

(After Alioth migration, hgweb isn't operational yet, but cloning via
http works, however.)

Last Friday, he had a discussion with Alexey and decided that we will
do the packaging work on these and other packages together as soon as
he gets an Alioth account.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: .la file status and hint to clear the dependency_libs field

[Michael Biebl]

Am 26.05.2011 10:46, schrieb Simon McVittie:
> On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote:
>> Comments welcome, but foremost I'd like a mass effort to clear the
>> remaining dependency_libs fields! :-)
> 
> Am I right in thinking that this is the process people should follow?
> 
> if depended-on:
> if dependency_libs:
> clear the dependency_libs
> else:
> do nothing (until you are no longer depended-on)
> else:
> if dependency_libs:
> clear the dependency_libs
> 
> if you are confident that it won't break anything:
> delete the .la file entirely
> 

Clearing the dependency_libs is always safe, afaics, so I'd rather say it is
something like

if depended-on
clear dependency_libs
else
remove *.la files

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: .la file status and hint to clear the dependency_libs field

[Jonas Smedegaard]

On 11-05-26 at 11:16am, Laurent Bigonville wrote:
> Hi,
> 
> > sed -i "/dependency_libs/ s/'.*'/''/"
> > "$(CURDIR)/debian//usr/lib/"
> > 
> > Comments welcome, but foremost I'd like a mass effort to clear the
> > remaining dependency_libs fields! :-)
> 
> gnome-pkg-tools package is already providing a cdbs makefile snippet
> that does the same thing on all .la files.
> 
> I've also opened a bug (#586082) a year ago asking if this snippet
> could be added to cdbs directly, but nothing so far. I guess that step
> would help a bit in reaching the goal.
> 
> Cheers
> 
> Laurent Bigonville
> 
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082


Do anyone perhaps have an opinion on Peter's suggestion in that 
bugreport?:

> I think in order of preference, this should be fixed by patching 
> libtool, or by a debhelper tool, and only then maybe in cdbs.  This 
> way you can reach the most packages.



Regards,

 - 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: Getting good bug reports

[Ian Jackson]

Goswin von Brederlow writes ("Re: Getting good bug reports"):
> Ian Jackson  writes:
> > The reason why there is a problem with an http submission interface is
> > that suddenly every idiot will think "oh I must write a cool ui for
> > this".
> 
> But with the tunneling suggested below the cool UI would have to talk
> smtp as well as http to setup the connection. So actualy doing this via
> http would be even harder than with plain smtp. So your argument doesn't
> hold.

Oh I see.  I'm not sure that implementing a complicated layered thing
like that.  How would you do sessions, anyway, or would you present
the whole SMTP session in a single transaction?

I don't think we should be implementing a perverse protocol out of
fear of a sociopolitical problem unless we don't have another way of
addressing the sociopolitical problem.

> Note: I'm not proposing bugs.d.o (or anyone else) gets an http
> submission interface. Just an interface to talk to the smtpd via http.

It should have the reportbug version string in the protocol, as I
described earlier.

> > The "bts" command is less relevant because it is run on your
> > workstation rather than some kind of installation target.
> 
> If my workstation is behing one of those stupid ISPs that don't allow
> smtp ...

My point is that you have to do a lot of setup to make your
workstation work like you want it to anyway.  Having to provide "bts"
(and indeed perhaps other commands) with a way to send email is just
one of those.  

It's much less of a problem than for reportbug, which you often want
to run on some kind of half-broken test setup.

> And the tunneling would keep your barrier intact.

I think it's ugly but that's not really an objection.  If the BTS
admins are happy with it.  

I still think we need the understanding that this will be used only
by programs which gain consensus here.  We can probably get that
consensus for bts, provided bts doesn't grow a way to submit bugs.

Ian.


-- 
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/19934.11176.186232.911...@chiark.greenend.org.uk

Re: Getting good bug reports

[Russell Coker]

There are plenty of cgi-bin scripts that send email via a web interface.  I'm 
sure that it wouldn't be difficult to install one of them on a web server for 
the purpose of forwarding Debian bug reports.  So really anyone who is good at 
running web servers can setup a HTTP submission method if they wish.

Would someone who wants to write a HTTP client bug reporting tool really be 
prevented because they have to setup their own server too?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201105262108.24824.russ...@coker.com.au

Re: Alioth status update, take 3

[Cyril Brulebois]

Hi,

Roland Mas  (23/05/2011):
>   We should now be in the phase where we pretend it's done, wait for
> the complaints, and fix the problems as they are reported (or laugh
> them off when they come from the too-common expectation that Alioth
> can be used to run any random stuff by anyone).

sorry, but I'll go for a big thank you instead.

Those are really kick ass machines!

Running mr on my ~/debian-x directory, with 12 parallel jobs (I had to
give it a try, usually I don't need to do that much in //):
| mr update: finished (171 ok)
| 
| real 0m4.819s
| user 0m0.368s
| sys  0m0.336s

Thanks to everyone who made that possible!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Getting good bug reports

[Ian Jackson]

Russell Coker writes ("Re: Getting good bug reports"):
> Would someone who wants to write a HTTP client bug reporting tool really be 
> prevented because they have to setup their own server too?

That would just result in their mail server being blocked by DSA or
owner@bugs.

Ian.


-- 
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/19934.16074.63311.574...@chiark.greenend.org.uk

Re: Getting good bug reports

[Patrick Strasser]

schrieb Ian Jackson am 2011-05-25 13:46:
> I wrote:
>> Brian May writes ("Re: Getting good bug reports"):
>>> [ explanation of how reportbug is broken right now ]
>>
>> We could solve this if we can avoid the slippery slope problem.
>>
>> Or to put it another way, I would have no objection to an http
>> submission interface to the BTS, provided that everyone understands
>> and agrees that:

I do note think that it exactly needs to be HTTP, but just something
without MTA and a online connection. HTTP is a well understood protocol,
usually working on port 80 - which is one of the least blocked ports -
with proxies - for those networks where direct access is not allowed.

Using port 80 brings advantages in the aspect of having a direct
connection from most hosts.
Using HTTP brings proxy support, but opens the door for easy to
implement additional bug reporting facilities without the control and
quality constraints that come with reportbug.

Why not use some simple non-HTTP-protocol on port 80?

For the workflow I could imagine:
- Try online submission
- if that fails, try email submission
- if that fails, save the bug report to a file and give the user
instructions how to submit the bug later, maybe from a different host.

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/irlgju$rp3$1...@dough.gmane.org

Re: .la file status and hint to clear the dependency_libs field

[Josselin Mouette]

Le jeudi 26 mai 2011 à 12:26 +0200, Jonas Smedegaard a écrit : 
> Do anyone perhaps have an opinion on Peter's suggestion in that 
> bugreport?:
> 
> > I think in order of preference, this should be fixed by patching 
> > libtool, or by a debhelper tool, and only then maybe in cdbs.  This 
> > way you can reach the most packages.

My dh_devlibs proposal (#534966) still stands.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1306413099.4334.99.camel@pi0307572

Re: Getting good bug reports

[Fernando Lemos]

On Thu, May 26, 2011 at 9:21 AM, Patrick Strasser
 wrote:
[...]
> Why not use some simple non-HTTP-protocol on port 80?

That tends to break transparent proxying. If port 80 is the only one
you have open, chances are you're behind a transparent proxy as well.

Regards,


-- 
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/BANLkTikhWKmYAwCYZRtng86f=o1aje8...@mail.gmail.com

Bug#628016: ITP: python-coverage-test-runner -- fail Python program unit tests unless they test everything

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

This package is in oldstable, but not in squeeze and later. It was
removed on my request because nothing in Debian required it, and I
wanted to retire. I am now preparing to upload some software that
uses this to run unit tests at build time, so I need to re-introduce
the package into Debian.

* Package name: python-coverage-test-runner
  Version : 1.5
  Upstream Author : Lars Wirzenius 
* URL : http://liw.fi/coverage-test-runner/
* License : GPL3+
  Programming Lang: Python
  Description : fail Python program unit tests unless they test everything

This package contains the Python module CoverageTestRunner, which runs
unit tests implemented using the unittest module in the Python standard
library. It runs them using coverage.py (in the python-coverage package)
and fails the test if all statements are not covered.



-- 
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/20110526124219.7456.37267.report...@havelock.liw.fi

Bug#628017: ITP: python-cliapp -- Python framework for Unix command line programs

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: python-cliapp
  Version : 0.11
  Upstream Author : Lars Wirzenius 
* URL : http://liw.fi/cliapp/
* License : GPL3+
  Programming Lang: Python
  Description : Python framework for Unix command line programs

cliapp makes it easier to write typical Unix command line programs,
by taking care of the common tasks they need to do, such as
parsing the command line, iterating over input files, and so on.



-- 
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/20110526124548.7580.50697.report...@havelock.liw.fi

Re: Conditional Recommends

[Darren Salt]

I demand that Scott Kitterman may or may not have written...

> On Wednesday, May 25, 2011 08:17:51 AM Darren Salt wrote:
>> I demand that Carsten Hey may or may not have written...
>> [snip]
>>> The third example with indirections would have advantages if one l10n
>>> package contains the translations for multiple packages (which seems to
>>> be planned).
>> ... which is something which, as upstream for a few packages, I'm not keen
>> on (AFAIK, Ubuntu do this). Particularly if, as seems to be the case with
>> Ubuntu, this leads to translations not being passed upstream or, if they
>> are, they're passed without proper attribution (which I will reject with
>> prejudice).

>> If they think that upstream should go and fetch translations from them,
>> well, I don't want to know: again, no obvious way to get
>> properly-attributed diffs.

>> [snip]

> That seems more than a little orthogonal to the question at hand.  KDE
> ships translations this way,

Not really relevant that they do: it's more that the process is working for
them. But then, they don't exactly have upstream maintainers/authors to send
patches on to. Debian does; while there is no requirement to do that, it's
good practice to do so.

> so translations for multiple packages is not just a code word for doing
> something that may benefit a derivative.

Hmm? I think that you're confused about what I wrote...

Basically, I just don't want this turning into what Ubuntu does (or what I
see of it), if it happens at all.

-- 
| Darren Salt  | linux or ds at  | nr. Ashington, |  _  ASCII ribbon
| using Debian | youmustbejoking | Northumberland | ( ) campaign against
| GNU/Linux| ,demon,co,uk||  X  HTML e-mail
/ \ www.asciiribbon.org
Look under the sofa cushion; you will be surprised at what you find.


-- 
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/51dedfcda4%li...@youmustbejoking.demon.co.uk

650.000/m2 đất sổ đỏ cạnh Sân Golf, Khu nghỉ dưỡng 5sao HànQuốc- ChươngMỹ, HàNội

[Anh Dung Nguyen]

 650.000/m2 đất sổ đỏ cạnh Sân Golf, Khu nghỉ dưỡng 5sao HànQuốc- ChươngMỹ,
HàNội


*Cần bán** **11.000m2 đất thổ cư sổ đỏ chỉ 650.000/m2 ngay cạnh Sân Golf 36
lỗ và Khu nghỉ dưỡng 5 sao SKY LAKE Hàn Quốc - Hồ Vân Sơn, huyện Chương Mỹ,
Hà Nội. *

* *

*Có thể bán toàn bộ hoặc bán lẻ mỗi mảnh 1000m2. Giá bán: 650.000/m2.  Gia
lộc giá bán cho khách mua toàn bộ lô đất.*

*
Đất mặt đường làng, đường đẹp rộng 8m. mặt tiền 200m, cách đường Hồ Chí Minh
(quốc lộ 21) 2km.  Về Hà Đông chỉ 20km theo đường xã Chúc Sơn, huyện Chương
Mỹ.

Đất đẹp, bằng phẳng, không khí trong lành, không gian thoáng mát. Nhân công
địa phương sẵn.

Phù hợp việc sử dụng làm Biệt thự nhà vườn, trang trại, địa điểm nghỉ dưỡng
cuối tuần, khu du lịch sinh thái giải trí, khu dịch vụ du lịch tổng hợp, nhà
xưởng bất kỳ, …

*

*Liên hệ chính chủ:  Mr. Dũng 09868 22982.**

P/s:  Đất chính chủ, không phải văn phòng môi giới. Là dân bản địa nên dễ
xin phép các thủ tục hành chính. Xem đất miễn phí, có hẹn trước. Chỉ tiếp
những ai có nhu cầu thật sự.*





*Tham khảo không gian Dự án 150 triệu USD - SKY LAKE:
http://www.skylakegolfclub.com/vn/about-us.aspx  .*

Bug#628034: ITP: uwsgi -- a fast, self-healing and developer/sysadmin-friendly application container server

[Xu ZhiXiang]

Package: wnpp
Severity: wishlist
Owner: Xu ZhiXiang 

* Package name: uwsgi
  Version : 0.9.7.2
  Upstream Author : Unbit 
* URL : http://projects.unbit.it/uwsgi/
* License : GPL2+
  Programming Lang: C
  Description : a fast, self-healing and developer/sysadmin-friendly 
application container server

uWSGI is a fast, self-healing and developer/sysadmin-friendly application
container server coded in pure C.

Born as a WSGI-only server, over time it has evolved in a complete stack for
networked/clustered web applications, implementing message/object passing,
caching, RPC and process management.

It uses the uwsgi (all lowercase, already included by default in the Nginx
and Cherokee releases) protocol for all the networking/interprocess
communications.

It can be run in preforking mode, threaded, asynchronous/evented and
supports various forms of green threads/coroutines (such as uGreen,
Greenlet, Stackless and Fiber).

Sysadmins will love it as it can be configured via several methods: command
line, environment variables, XML, .ini, yaml files and via LDAP.

On top of all this, it is designed to be fully modular. This means that
different plugins can be used in order to add compatibility with tons of
different technology on top of the same core. 



-- 
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/20110526123443.5249.28371.report...@buzig.gplhost.com

Re: .la file status and hint to clear the dependency_libs field

[Peter Samuelson]

[Michael Biebl]
> Clearing the dependency_libs is always safe, afaics, so I'd rather say it is
> something like
> 
> if depended-on
>   clear dependency_libs
> else
>   remove *.la files

Seems like the following would work instead:

remove *.la files
if depended-on
request some binNMUs

This is unstable after all, right?  (:
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20110526160439.gb15...@p12n.org

When create base.tgz with pbuilder , occured a error

[YunQiang Su]

I am using unstable/experimental, and when

pbuilder create

When it nearly success, an error occoured :

I: mounting /proc filesystem
mount: /proc already mounted or /media/tmpfs/pbuilder/4079/proc busy
mount: according to mtab, /proc is mounted on /proc
W: Aborting with an error
I: cleaning the build env
I: removing directory /media/tmpfs/pbuilder/4079 and its subdirectories
rmdir: failed to remove `/media/tmpfs/pbuilder/4079/proc': Device or
resource busy
rmdir: failed to remove `/media/tmpfs/pbuilder/4079': Directory not empty

And the base.tgz create before, works well.

-- 
YunQiang Su


-- 
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/BANLkTimSEgTXW5GsOm8VFr8h+QPPjLj4=q...@mail.gmail.com

When create base.tgz with pbuilder , occured a error

[YunQiang Su]

I am using unstable/experimental, and when

pbuilder create

When it nearly success, an error occoured :

I: mounting /proc filesystem
mount: /proc already mounted or /media/tmpfs/pbuilder/4079/proc busy
mount: according to mtab, /proc is mounted on /proc
W: Aborting with an error
I: cleaning the build env
I: removing directory /media/tmpfs/pbuilder/4079 and its subdirectories
rmdir: failed to remove `/media/tmpfs/pbuilder/4079/proc': Device or
resource busy
rmdir: failed to remove `/media/tmpfs/pbuilder/4079': Directory not empty

And the base.tgz buil

-- 
YunQiang Su


-- 
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/banlktikg9hm8wtcf7r6qdsjx4tg0bst...@mail.gmail.com

Bug#628062: RFH: freeipmi -- GNU implementation of the IPMI protocol

[Yaroslav Halchenko]

Package: wnpp
Severity: normal

I am seeking for help with FreeIPMI.  Project is really nice, upstream is
very knowledgeable, nice, and I even had them as an exemplar CVS gurus
(Just see http://www.onerussian.com/Linux/misc/freeipmi-big-picture.pdf for
the development tree after it got cvsimported into GIT).  FWIW ATM upstream
is using SVN.

There is only 2 simple bugs opened in DBTS

#619234 [n|  |  ] [freeipmi-bmc-watchdog] freeipmi-bmc-watchdog: Configuration 
file and init script do not match
#619248 [n|  |  ] [freeipmi] freeipmi: needs versioned build-dep on 
autotools-dev

and just slightly bigger piece of work is needed for preparing migration to
the recent upstream release of 1.x series where some tools were renamed, so
it would need just a bit of work to achieve a smooth transition for
existing users.

popcon is not high relatively, partially because freeipmi was initially
uploaded only in Nov 2009, but numbers seems to be growing exponentially at
this moment ;) :
http://qa.debian.org/popcon.php?package=freeipmi

Packaging maintained in GIT following git-buildpackage + pristine-tar
scheme:

http://git.onerussian.com/?p=deb/freeipmi.git

Ideally I am looking for a co-maintainer (or even adopter) who is using it
for his sysadmin needs.  I could mentor/sponsor if necessary.

-- 
Yaroslav



-- 
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/yzbyk4ddi6r4@novo.onerussian.com

packaging-dev meta package

[Benjamin Drung]

Hi,

A few days ago, we had a discussion in Ubuntu about a packaging-dev meta
package. The problem is that users have to install a bunch of packages
if they want to dive into packaging. Even some packagers get annoyed
when they need to turn a newly installed system into a packaging
environment. The solution would be a meta package that depends on the
commonly used packages for packaging.

As a starting point packaging-dev would depend on

build-essential
quilt
debhelper
cmake
autoconf
cdbs
bzr-builddeb
apt-file
ubuntu-dev-tools (only on Ubuntu systems)

Do you like the idea or not? Do you have a better name for the meta
package? Should something added to or removed from the dependency list?

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Fernando Lemos]

On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung  wrote:
> Hi,
>
> A few days ago, we had a discussion in Ubuntu about a packaging-dev meta
> package. The problem is that users have to install a bunch of packages
> if they want to dive into packaging. Even some packagers get annoyed
> when they need to turn a newly installed system into a packaging
> environment. The solution would be a meta package that depends on the
> commonly used packages for packaging.

Isn't apt-get build-dep enough? Users can always use equivs for
something more specific.

Regards,


-- 
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/BANLkTi=k=2t56u2njso39k8vwasonf3...@mail.gmail.com

Re: packaging-dev meta package

[Benjamin Drung]

Am Donnerstag, den 26.05.2011, 17:25 -0300 schrieb Fernando Lemos:
> On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung  wrote:
> > Hi,
> >
> > A few days ago, we had a discussion in Ubuntu about a packaging-dev meta
> > package. The problem is that users have to install a bunch of packages
> > if they want to dive into packaging. Even some packagers get annoyed
> > when they need to turn a newly installed system into a packaging
> > environment. The solution would be a meta package that depends on the
> > commonly used packages for packaging.
> 
> Isn't apt-get build-dep enough? Users can always use equivs for
> something more specific.

apt-get build-dep gets the build dependency for a specific package, but
it wont give you devscripts for example.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Mackenzie Morgan]

On Thu, May 26, 2011 at 4:29 PM, Benjamin Drung  wrote:
> Am Donnerstag, den 26.05.2011, 17:25 -0300 schrieb Fernando Lemos:
>> On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung  wrote:
>> > Hi,
>> >
>> > A few days ago, we had a discussion in Ubuntu about a packaging-dev meta
>> > package. The problem is that users have to install a bunch of packages
>> > if they want to dive into packaging. Even some packagers get annoyed
>> > when they need to turn a newly installed system into a packaging
>> > environment. The solution would be a meta package that depends on the
>> > commonly used packages for packaging.
>>
>> Isn't apt-get build-dep enough? Users can always use equivs for
>> something more specific.
>
> apt-get build-dep gets the build dependency for a specific package, but
> it wont give you devscripts for example.

I didn't realise you were going to send a mail to debian-devel too
(thought it'd just be ubuntu-devel), so I guess that'd mean make
devscripts a direct Rec if it ends up in Debian, because at the moment
it was being accounted for as a dependency of u-d-t

-- 
Mackenzie Morgan


-- 
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/BANLkTikq-HZj0-1FhDX6oCVre=z0sna...@mail.gmail.com

Re: packaging-dev meta package

[gregor herrmann]

On Thu, 26 May 2011 22:29:11 +0200, Benjamin Drung wrote:

> > Isn't apt-get build-dep enough? Users can always use equivs for
> > something more specific.
> apt-get build-dep gets the build dependency for a specific package, but
> it wont give you devscripts for example.

Maybe the idea was build-essential, but it's still not enough ...
 
Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Cat Stevens: The Foreigner Suite


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[Benjamin Drung]

Am Donnerstag, den 26.05.2011, 16:33 -0400 schrieb Mackenzie Morgan:
> On Thu, May 26, 2011 at 4:29 PM, Benjamin Drung  wrote:
> > Am Donnerstag, den 26.05.2011, 17:25 -0300 schrieb Fernando Lemos:
> >> On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung  wrote:
> >> > Hi,
> >> >
> >> > A few days ago, we had a discussion in Ubuntu about a packaging-dev meta
> >> > package. The problem is that users have to install a bunch of packages
> >> > if they want to dive into packaging. Even some packagers get annoyed
> >> > when they need to turn a newly installed system into a packaging
> >> > environment. The solution would be a meta package that depends on the
> >> > commonly used packages for packaging.
> >>
> >> Isn't apt-get build-dep enough? Users can always use equivs for
> >> something more specific.
> >
> > apt-get build-dep gets the build dependency for a specific package, but
> > it wont give you devscripts for example.
> 
> I didn't realise you were going to send a mail to debian-devel too
> (thought it'd just be ubuntu-devel), so I guess that'd mean make
> devscripts a direct Rec if it ends up in Debian, because at the moment
> it was being accounted for as a dependency of u-d-t

I thought that we should get the meta package into Debian if the DDs
like the idea of it and otherwise get it only into Debian.

Right, devscripts should be a direct dependency.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[gregor herrmann]

On Thu, 26 May 2011 22:05:42 +0200, Benjamin Drung wrote:

> As a starting point packaging-dev would depend on
> 
> build-essential
> quilt
> debhelper
> cmake
> autoconf
> cdbs
> bzr-builddeb
> apt-file
> ubuntu-dev-tools (only on Ubuntu systems)
> 
> Do you like the idea or not? Do you have a better name for the meta
> package? Should something added to or removed from the dependency list?

I tentatively think the idea is good; I don't really care about the
name :)

The problem might be that the set of packages is not
trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've
never heard about bzr-builddeb, I miss cowbuilder (and also
svn-buildpackage and git-buildpackage, and maybe dh-make) ... So yes,
the idea is interesting, but the selection of packages might need
some consideration :)
 
Cheers,
gregor 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Cat Stevens: The Foreigner Suite


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[Andrew Starr-Bochicchio]

On Thu, May 26, 2011 at 4:05 PM, Benjamin Drung  wrote:
> As a starting point packaging-dev would depend on
>
> build-essential
> quilt
> debhelper
> cmake
> autoconf
> cdbs
> bzr-builddeb
> apt-file
> ubuntu-dev-tools (only on Ubuntu systems)
>
> Do you like the idea or not? Do you have a better name for the meta
> package? Should something added to or removed from the dependency list?

This could be useful. A couple of suggestions:

Keep vcs specific tools (git-buildpackage, bzr-builddeb,
svn-buildpackage) in the Recommends field so they are not hard
dependencies.

I suppose you don't you don't list devscripts, gnupg, lintian, dput |
dupload, and dh-make (there are probably some others) as they are
pulled in by other packages. I would explicitly depend on them

Recommends on pbuilder | cowbuilder?.

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Contributor

   PGP/GPG Key ID: D53FDCB1


-- 
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/banlktinkqssjut8bvfjyr-gk5ddvclg...@mail.gmail.com

Re: packaging-dev meta package

[Mackenzie Morgan]

On Thu, May 26, 2011 at 4:44 PM, Andrew Starr-Bochicchio
 wrote:
> Keep vcs specific tools (git-buildpackage, bzr-builddeb,
> svn-buildpackage) in the Recommends field so they are not hard
> dependencies.

The current version of the control field I've got sitting here has
build-essential in Depends and the rest in Recommends so people can
slim down at-will.

> I suppose you don't you don't list devscripts, gnupg, lintian, dput |
> dupload, and dh-make (there are probably some others) as they are
> pulled in by other packages. I would explicitly depend on them
>
> Recommends on pbuilder | cowbuilder?.

Can do

-- 
Mackenzie Morgan


-- 
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/banlktinar-pc4noptu4b40k2qo9xkxm...@mail.gmail.com

Re: packaging-dev meta package

[Benjamin Drung]

Am Donnerstag, den 26.05.2011, 22:40 +0200 schrieb gregor herrmann:
> On Thu, 26 May 2011 22:05:42 +0200, Benjamin Drung wrote:
> 
> > As a starting point packaging-dev would depend on
> > 
> > build-essential
> > quilt
> > debhelper
> > cmake
> > autoconf
> > cdbs
> > bzr-builddeb
> > apt-file
> > ubuntu-dev-tools (only on Ubuntu systems)
> > 
> > Do you like the idea or not? Do you have a better name for the meta
> > package? Should something added to or removed from the dependency list?
> 
> I tentatively think the idea is good; I don't really care about the
> name :)
> 
> The problem might be that the set of packages is not
> trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've
> never heard about bzr-builddeb, I miss cowbuilder (and also
> svn-buildpackage and git-buildpackage, and maybe dh-make) ... So yes,
> the idea is interesting, but the selection of packages might need
> some consideration :)

Then let's put the uncontroversial into Depends, the common (this needs
discussion) into Recommends and the others into Suggests.

Here's the starting point for discussion:

Depends:
build-essential
debhelper
devscripts
gnupg
lintian
dput | dupload
quilt
ubuntu-dev-tools (only on Ubuntu)
pbuilder | cowbuilder

Recommends:
apt-file
autoconf
bzr-builddeb (maybe Depends on Ubuntu)
svn-buildpackage
git-buildpackage
dh-make

Recommends or Suggests:
cdbs
cmake

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Benjamin Drung]

Am Donnerstag, den 26.05.2011, 16:46 -0400 schrieb Mackenzie Morgan:
> On Thu, May 26, 2011 at 4:44 PM, Andrew Starr-Bochicchio
>  wrote:
> > Keep vcs specific tools (git-buildpackage, bzr-builddeb,
> > svn-buildpackage) in the Recommends field so they are not hard
> > dependencies.
> 
> The current version of the control field I've got sitting here has
> build-essential in Depends and the rest in Recommends so people can
> slim down at-will.

Can you upload the version of the package into collab-maint on Alioth?

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Mackenzie Morgan]

On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:
> Recommends or Suggests:
> cdbs
> cmake

My reasoning on these two was that some people probably aren't
interested in switching from cdbs to quilt, so coming across packages
still using it will be common for a while.  CMake is a corollary to
autoconf and heavily used in KDE-land, which seems like a
not-insignificant number of packages.

-- 
Mackenzie Morgan


-- 
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/banlktinoc0k+uh+vfs7kusps5s4pusp...@mail.gmail.com

Re: packaging-dev meta package

[Russ Allbery]

Andrew Starr-Bochicchio  writes:

> This could be useful. A couple of suggestions:

> Keep vcs specific tools (git-buildpackage, bzr-builddeb,
> svn-buildpackage) in the Recommends field so they are not hard
> dependencies.

A fancier thing to do would be to build separate packaging-dev-
packages for each popular VCS (I'd recommend bzr, Subversion, and Git to
start with, maybe Mercurial too), which would depend on the VCS packages
used for doing Debian development with that VCS plus the most popular
helper tools.  That might be a nice compromise between making that a
one-stop-shop and not installing whole VCS systems that people aren't
using.

-- 
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/87aae9maig@windlord.stanford.edu

Re: packaging-dev meta package

[Russ Allbery]

Mackenzie Morgan  writes:
> On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:

>> Recommends or Suggests:
>> cdbs
>> cmake

> My reasoning on these two was that some people probably aren't
> interested in switching from cdbs to quilt,

You mean from cdbs to using debhelper directly?  cdbs and quilt are
orthogonal to each other.

> so coming across packages still using it will be common for a while.
> CMake is a corollary to autoconf and heavily used in KDE-land, which
> seems like a not-insignificant number of packages.

It's a not-insigificant number of packages, but I think it's a lot fewer
in terms of number of developers, since I've never seen CMake used outside
of KDE-land.

-- 
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/8762oxmaff@windlord.stanford.edu

Re: packaging-dev meta package

[Stefano Zacchiroli]

On Thu, May 26, 2011 at 10:49:46PM +0200, Benjamin Drung wrote:
> Am Donnerstag, den 26.05.2011, 22:40 +0200 schrieb gregor herrmann:
> > I tentatively think the idea is good; I don't really care about the
> > name :)

ACK (on both).

> > The problem might be that the set of packages is not
> > trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've
> > never heard about bzr-builddeb, I miss cowbuilder (and also
> > svn-buildpackage and git-buildpackage, and maybe dh-make) ... So
> > yes, the idea is interesting, but the selection of packages might
> > need some consideration :)

True, but I don't see the controversy here as being more controversial
than other choices we already have to make in the archive, such as the
"Recommends" line of devscripts.

So, if introducing the meta-package is OK (and I can hardly see any
drawback in introducing it), the package will have a maintainer which
will decide upon its (weak) dependencies.

> Then let's put the uncontroversial into Depends, the common (this
> needs discussion) into Recommends and the others into Suggests.

Indeed.

> Here's the starting point for discussion:

I don't have specific comments on the various items ATM, just a
suggestion might be useful as starting point: have a look at devref,
there is a section about various utilities coming handy in packaging, it
might provide good "coverage testing" for the dependencies of the meta
package.

Cheers.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: new scripts and patches for devscripts

[Benjamin Drung]

Am Mittwoch, den 25.05.2011, 14:49 +0200 schrieb Tshepang Lekhonkhobe:
> On Tue, 2011-05-24 at 23:51 +0200, Benjamin Drung wrote:
> > Am Samstag, den 21.05.2011, 21:41 +0200 schrieb Tshepang Lekhonkhobe:
> > > On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote:
> > > > Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega:
> > > > > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung  
> > > > > wrote:
> > > > > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh:
> > > > > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote:
> > > > > >> > Should these script moved from ubuntu-dev-tools into devscripts?
> > > > > >> >
> > > > > >> > Most of the script are written in Python. Rewriting them to get 
> > > > > >> > them
> > > > > >> > included in devscripts is too much work without benefit. 
> > > > > >> > devscripts
> > > > > >> > would depend on python then.
> > > > > >>
> > > > > >> Most of the scripts are short.  Rewriting would be fairly simple, 
> > > > > >> and
> > > > > >> may be beneficial in removing the Ubuntu-specific bits.
> > > > > >
> > > > > > What speaks against having these script in python? Is python too 
> > > > > > heavy
> > > > > > for a _development_ machine?
> > > > > 
> > > > > It's not just about a package dependency.  It's more about restricting
> > > > > the knowledge base required for those maintaining the package.
> > > > > 
> > > > > Considering that scripts are contributed to devscripts and the support
> > > > > burden is then commonly left on the shoulders of those maintaining
> > > > > devscripts instead of the original script author, it's in our interest
> > > > > to maintain a consistent set of languages that we are willing to
> > > > > support.  This is currently Perl and shell.
> > > > > 
> > > > > So yes, IMO, accepting scripts written in Python (or any other 
> > > > > language)
> > > > > is too heavy.  Not for a "_development_ machine", but for a 
> > > > > maintenance
> > > > > team.  If people choose to ignore our requirement and develop scripts 
> > > > > in
> > > > > other languages, then they can deal with the consequences.
> > > > 
> > > > Stefano Rivera (stefanor) and I offer to maintain the Python scripts in
> > > > devscripts. Is it enough to have at two DDs to support Python?
> > > 
> > > Has this issue been resolved? Has this question been answered by
> > > devscripts maintainers?
> > 
> > We managed to alleviate the concerns / weaken the resistance. The two
> > Python scripts suspicious-source and wrap-and-sort landed in the
> > devscripts git master branch and will be included in the upcoming
> > upload.
> 
> Okay, thanks.
> 
> What about the rest? Is this discussed some place public? This thread
> makes it look like there was indecision. What did I miss?

The discussion from debian-devel was continued on
pkg-devscri...@teams.debian.net and on IRC (#devscripts on OTFC).

The scripts that should be moved where discussed at the UDS-o in
Budapest [1].

[1]
https://blueprints.launchpad.net/ubuntu-dev-tools/+spec/other-o-udt-upstreaming

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Steve Langasek]

On Thu, May 26, 2011 at 10:49:46PM +0200, Benjamin Drung wrote:
> > I tentatively think the idea is good; I don't really care about the
> > name :)

> > The problem might be that the set of packages is not
> > trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've
> > never heard about bzr-builddeb, I miss cowbuilder (and also
> > svn-buildpackage and git-buildpackage, and maybe dh-make) ... So yes,
> > the idea is interesting, but the selection of packages might need
> > some consideration :)

> Then let's put the uncontroversial into Depends, the common (this needs
> discussion) into Recommends and the others into Suggests.

> Here's the starting point for discussion:

> Depends:
> build-essential
> debhelper
> devscripts
> gnupg
> lintian
> dput | dupload
> quilt
> ubuntu-dev-tools (only on Ubuntu)
> pbuilder | cowbuilder

  ^^ you mean sbuild.

Happy to inject a little controversy ;)

Though honestly I don't think I'm a target user for this package anyway, so
I'm not sure you should care what I consider to be the standard developer
tools.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: .la file status and hint to clear the dependency_libs field

[Luk Claes]

On 05/26/2011 11:55 AM, Michael Biebl wrote:
> Am 26.05.2011 10:46, schrieb Simon McVittie:
>> On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote:
>>> Comments welcome, but foremost I'd like a mass effort to clear the
>>> remaining dependency_libs fields! :-)
>>
>> Am I right in thinking that this is the process people should follow?
>>
>> if depended-on:
>> if dependency_libs:
>> clear the dependency_libs
>> else:
>> do nothing (until you are no longer depended-on)
>> else:
>> if dependency_libs:
>> clear the dependency_libs
>>
>> if you are confident that it won't break anything:
>> delete the .la file entirely
>>
> 
> Clearing the dependency_libs is always safe, afaics, so I'd rather say it is
> something like
> 
> if depended-on
>   clear dependency_libs
> else
>   remove *.la files

There are some good reasons to keep some specific *.la files around,
that's why I'm not aiming at removing them, but at least have the real
problem solved.

So I suggest:

if dependency_libs
clear dependency_libs

Cheers

Luk


-- 
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/4ddec582.5000...@debian.org

Re: packaging-dev meta package

[Steve Langasek]

On Thu, May 26, 2011 at 04:52:38PM -0400, Mackenzie Morgan wrote:
> On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:
> > Recommends or Suggests:
> > cdbs
> > cmake

> My reasoning on these two was that some people probably aren't
> interested in switching from cdbs to quilt, so coming across packages
> still using it will be common for a while.  CMake is a corollary to
> autoconf and heavily used in KDE-land, which seems like a
> not-insignificant number of packages.

But in both cases, those should be pulled in as build-depends, no?

To have them as dependencies of this package sounds to me like you're
recommending these tools for use.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[Mackenzie Morgan]

On Thu, May 26, 2011 at 5:14 PM, Russ Allbery  wrote:
> Mackenzie Morgan  writes:
>> On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:
>
>>> Recommends or Suggests:
>>> cdbs
>>> cmake
>
>> My reasoning on these two was that some people probably aren't
>> interested in switching from cdbs to quilt,
>
> You mean from cdbs to using debhelper directly?  cdbs and quilt are
> orthogonal to each other.

Sorry, yes.

The push toward Source Format 3 with Quilt and DH7 happened around the
same time that I started doing packaging with any frequency so I'm
somewhat muddled on the "old way."  Do I recall correctly that there
was some sort of patch management included in cdbs or am I thinking of
another tool?

-- 
Mackenzie Morgan


--
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/banlktimgb0gm4jaudozjlefknore6jn...@mail.gmail.com

Re: .la file status and hint to clear the dependency_libs field

[Luk Claes]

On 05/26/2011 06:04 PM, Peter Samuelson wrote:
> 
> [Michael Biebl]
>> Clearing the dependency_libs is always safe, afaics, so I'd rather say it is
>> something like
>>
>> if depended-on
>>  clear dependency_libs
>> else
>>  remove *.la files
> 
> Seems like the following would work instead:
> 
> remove *.la files
> if depended-on
> request some binNMUs
> 
> This is unstable after all, right?  (:

No, breaking things when that can easily be avoided is not preferred.
Also not in unstable.

Plus some specific *.la files are not meant to be removed at all.

And if I'm not mistaken, removing the *.la files and binNMUing the ones
that depend on them does not work, some of these would just FTBFS,
others could break in unforseen circumstances.

Cheers

Luk


-- 
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/4ddec67e.4050...@debian.org

Re: packaging-dev meta package

[Russ Allbery]

Mackenzie Morgan  writes:

> Sorry, yes.

> The push toward Source Format 3 with Quilt and DH7 happened around the
> same time that I started doing packaging with any frequency so I'm
> somewhat muddled on the "old way."  Do I recall correctly that there was
> some sort of patch management included in cdbs or am I thinking of
> another tool?

Oh, yes, there was also a simple-patchsys system inside CDBS.  I'm not
sure if that's still in use with the new source package format.

-- 
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/87k4ddkv4g@windlord.stanford.edu

Re: packaging-dev meta package

[Benjamin Drung]

Am Donnerstag, den 26.05.2011, 17:28 -0400 schrieb Mackenzie Morgan:
> On Thu, May 26, 2011 at 5:14 PM, Russ Allbery  wrote:
> > Mackenzie Morgan  writes:
> >> On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:
> >
> >>> Recommends or Suggests:
> >>> cdbs
> >>> cmake
> >
> >> My reasoning on these two was that some people probably aren't
> >> interested in switching from cdbs to quilt,
> >
> > You mean from cdbs to using debhelper directly?  cdbs and quilt are
> > orthogonal to each other.
> 
> Sorry, yes.
> 
> The push toward Source Format 3 with Quilt and DH7 happened around the
> same time that I started doing packaging with any frequency so I'm
> somewhat muddled on the "old way."  Do I recall correctly that there
> was some sort of patch management included in cdbs or am I thinking of
> another tool?

It is an one-liner to add a patch system to a cdbs rules file. You could
freely choose between simple-patchsys, quilt and dpatch.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: packaging-dev meta package

[Jakub Wilk]

Not that I'd consider this package particularly useful, but...

* Benjamin Drung , 2011-05-26, 22:49:

Here's the starting point for discussion:

Depends:
build-essential
debhelper
devscripts
gnupg
lintian
dput | dupload
quilt


Agreed.


pbuilder | cowbuilder


Apart from missing initial "sbuild |", this should go to Recommends.


Recommends:
apt-file
autoconf

+ automake (sadly)
+ libtool (even more sadly)

bzr-builddeb (maybe Depends on Ubuntu)
svn-buildpackage
git-buildpackage


Agreed. (Though I don't use bzr-* or git-* stuff.) I'd add documentation 
packages here: developers-reference, debian-policy.



dh-make


Seriously? Are you, grown-up developers, using it? oO


Recommends or Suggests:
cdbs


The sad truth is that so many packages use cdbs, that is hard to live 
without it. I'd put it in Recommends.



cmake


Even though I happen to main two (non-KDE-related) packages that 
build-depends on cmake, I'd say it's exotic enough that should be 
excluded completely.


--
Jakub Wilk


--
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/20110526214433.ga6...@jwilk.net

Re: packaging-dev meta package

[Filippo Rusconi]

Greetings,

On Thu, May 26, 2011 at 02:14:28PM -0700, Russ Allbery wrote:
> 
> Mackenzie Morgan  writes:
> > On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  wrote:
> 
> >> Recommends or Suggests:
> >> cdbs
> >> cmake
> 
...
> > so coming across packages still using it will be common for a while.
> > CMake is a corollary to autoconf and heavily used in KDE-land, which
> > seems like a not-insignificant number of packages.
> 
> It's a not-insigificant number of packages, but I think it's a lot fewer
> in terms of number of developers, since I've never seen CMake used outside
> of KDE-land.

Many users of cmake are indeed KDE devs, but cmake is also used a lot
in projects that use Qt only (massXpert is one example, but there are
many).

Ciao

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer 
Author of ``massXpert'' at http://www.massxpert.org


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[Sune Vuorela]

On 2011-05-26, Jakub Wilk  wrote:
>>autoconf
> + automake (sadly)
> + libtool (even more sadly)

should be grouped with cmake (probably all at suggest)

>>bzr-builddeb (maybe Depends on Ubuntu)
>>svn-buildpackage
>>git-buildpackage

suggest.

>>dh-make
>
> Seriously? Are you, grown-up developers, using it? oO

Oh yes.

/Sune


-- 
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/slrnittjqd.p7v.nos...@sshway.ssh.pusling.com

Re: .la file status and hint to clear the dependency_libs field

[Michael Biebl]

Am 26.05.2011 23:26, schrieb Luk Claes:

> There are some good reasons to keep some specific *.la files around,

Just curious: what are these reasons / use case for keeping la files?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: packaging-dev meta package

[Jonas Smedegaard]

On 11-05-26 at 05:28pm, Mackenzie Morgan wrote:
> On Thu, May 26, 2011 at 5:14 PM, Russ Allbery  wrote:
> > Mackenzie Morgan  writes:
> >> On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  
> >> wrote:
> >
> >>> Recommends or Suggests:
> >>> cdbs
> >>> cmake
> >
> >> My reasoning on these two was that some people probably aren't 
> >> interested in switching from cdbs to quilt,
> >
> > You mean from cdbs to using debhelper directly?  cdbs and quilt are 
> > orthogonal to each other.
> 
> Sorry, yes.
> 
> The push toward Source Format 3 with Quilt and DH7 happened around the 
> same time that I started doing packaging with any frequency so I'm 
> somewhat muddled on the "old way."  Do I recall correctly that there 
> was some sort of patch management included in cdbs or am I thinking of 
> another tool?

Please - it is not the _version_ of debhelper but whether using 
short-form which was _introduced_ at version 7.


I use CDBS for 240+ packages.

Most of them use debhelper 6 to be easier to backport as far back as to 
Etch without any changes to source.  Some use debhelper 7, and they can 
do so with these two commands:

  echo 7 > debian/compat
  DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean

..but I do not use short-form dh for any of them - that clashes with 
CDBS while lacking some of the CDBS features.

None of them (should) use the CDBS-provided single-patchsys - that tool 
is deprecated and never was good.


I find a meta-package for development irrelevant: I recommend to simply 
install devscripts + whatever specific build-dependencies needed for the 
environment you want to work with.


Kind regards,

 - 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: packaging-dev meta package

[Jonas Smedegaard]

On 11-05-26 at 02:20pm, Steve Langasek wrote:
> On Thu, May 26, 2011 at 04:52:38PM -0400, Mackenzie Morgan wrote:
> > On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  
> > wrote:
> > > Recommends or Suggests:
> > > cdbs
> > > cmake
> 
> > My reasoning on these two was that some people probably aren't 
> > interested in switching from cdbs to quilt, so coming across 
> > packages still using it will be common for a while.  CMake is a 
> > corollary to autoconf and heavily used in KDE-land, which seems like 
> > a not-insignificant number of packages.
> 
> But in both cases, those should be pulled in as build-depends, no?
> 
> To have them as dependencies of this package sounds to me like you're 
> recommending these tools for use.

now this is getting interesting: This really is a debate on whether 
Debian should encourage or discourage development using CDBS and Qt?


 - 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: packaging-dev meta package

[Steve Langasek]

On Fri, May 27, 2011 at 12:45:41AM +0200, Jonas Smedegaard wrote:
> On 11-05-26 at 02:20pm, Steve Langasek wrote:
> > On Thu, May 26, 2011 at 04:52:38PM -0400, Mackenzie Morgan wrote:
> > > On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung  
> > > wrote:
> > > > Recommends or Suggests:
> > > > cdbs
> > > > cmake

> > > My reasoning on these two was that some people probably aren't 
> > > interested in switching from cdbs to quilt, so coming across 
> > > packages still using it will be common for a while.  CMake is a 
> > > corollary to autoconf and heavily used in KDE-land, which seems like 
> > > a not-insignificant number of packages.

> > But in both cases, those should be pulled in as build-depends, no?

> > To have them as dependencies of this package sounds to me like you're 
> > recommending these tools for use.

> now this is getting interesting: This really is a debate on whether 
> Debian should encourage or discourage development using CDBS and Qt?

Qt != cmake.  You can use Qt without incurring the NIH limitations of cmake.

If we were discussing whether to encourage development using Qt, I would
expect to see libqt4-dev in the proposed dependency list.

This is also not really a discussion of whether Debian encourages or
discourages anything, only of whether the maintainers of this proposed
package will encourage or discourage something.  As I said, I'm not a target
user for this package, so I don't really care what goes in it; but it's
pretty clear to me that the utility of such a package is that it provides
some "recommended" environment for developing packages.  If the maintainers
want to recommend cdbs as a packaging tool, they can depend on cdbs; if
that's not their recommendation, I don't see the point in including it in
the package relationships at all.  Conversely, if their recommendation is to
use cdbs, I don't think it makes sense for such a package to depend on
debhelper directly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[gregor herrmann]

On Thu, 26 May 2011 23:16:08 +0200, Stefano Zacchiroli wrote:

> > > The problem might be that the set of packages is not
> > > trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've
> > > never heard about bzr-builddeb, I miss cowbuilder (and also
> > > svn-buildpackage and git-buildpackage, and maybe dh-make) ... So
> > > yes, the idea is interesting, but the selection of packages might
> > > need some consideration :)
> True, but I don't see the controversy here as being more controversial
> than other choices we already have to make in the archive, such as the
> "Recommends" line of devscripts.
> So, if introducing the meta-package is OK (and I can hardly see any
> drawback in introducing it), the package will have a maintainer which
> will decide upon its (weak) dependencies.

Definitively.
I was just throwing in some quick brainstorming ideas.
 
> > Then let's put the uncontroversial into Depends, the common (this
> > needs discussion) into Recommends and the others into Suggests.
> Indeed.


Cheers,
gregor
 
-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Supertramp: You Win, I Lose


signature.asc
Description: Digital signature

Re: packaging-dev meta package

[The Fungi]

On Thu, May 26, 2011 at 10:05:42PM +0200, Benjamin Drung wrote:
[...]
> Should something added to or removed from the dependency list?

Not so much a vote for or against the main idea of the meta package
itself, but a glaring omission in my mind is piuparts, which is
great for package QA.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110527001545.gi1...@yuggoth.org

Re: packaging-dev meta package

[Ben Finney]

The Fungi  writes:

> On Thu, May 26, 2011 at 10:05:42PM +0200, Benjamin Drung wrote:
> [...]
> > Should something added to or removed from the dependency list?
>
> Not so much a vote for or against the main idea of the meta package
> itself, but a glaring omission in my mind is piuparts, which is
> great for package QA.

Which goes hand-in-hand with ‘pbuilder’ to ensure one's package behaves
properly in a minimal Debian environment.

-- 
 \“I knew it was a shocking thing to say, but … no-one has the |
  `\right to spend their life without being offended.” —Philip |
_o__)  Pullman, 2010-03-28 |
Ben Finney


-- 
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/87k4dcao97@benfinney.id.au

Re: packaging-dev meta package

[Paul Wise]

On Fri, May 27, 2011 at 4:05 AM, Benjamin Drung  wrote:

> Do you like the idea or not?

Seems reasonable.

> Do you have a better name for the meta package?

How about build-something (keeping with the build-essential naming)?

build-depends-common
build-recommends
build-suggests

> Should something added to or removed from the dependency list?

devscripts
the various vcs-buildpackage scripts
sbuild
schroot
signing-party (for caff)
lintian
valgrind
gdb
cppcheck
pyflakes
perlcritic



Please make most of the dependencies recommends so that people can
easily pick and choose what they want installed.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/


-- 
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/banlktimovvkulg3pij-tsreg9yaxfqf...@mail.gmail.com

Re: .la file status and hint to clear the dependency_libs field

[Neil Williams]

On Fri, 27 May 2011 00:17:45 +0200
Michael Biebl  wrote:

> Am 26.05.2011 23:26, schrieb Luk Claes:
> 
> > There are some good reasons to keep some specific *.la files around,
> 
> Just curious: what are these reasons / use case for keeping la files?

Plugins which us libltdl use the .la file but these methods do not use
the dependency_libs setting of the .la file which is where the
problems arise. Other plugin methods do not need a .la file.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpAWr8OY4fs4.pgp
Description: PGP signature

Re: .la file status and hint to clear the dependency_libs field

[Neil Williams]

On Thu, 26 May 2011 23:26:26 +0200
Luk Claes  wrote:

> On 05/26/2011 11:55 AM, Michael Biebl wrote:
> > Am 26.05.2011 10:46, schrieb Simon McVittie:
> >> On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote:
> >>> Comments welcome, but foremost I'd like a mass effort to clear the
> >>> remaining dependency_libs fields! :-)
> >>
> >> Am I right in thinking that this is the process people should follow?
> >>
> >> if depended-on:
> >> if dependency_libs:
> >> clear the dependency_libs
> >> else:
> >> do nothing (until you are no longer depended-on)

Even when depended-on, the dependency_libs field can be cleared,
the .la file itself though cannot be removed.

> >> else:
> >> if dependency_libs:
> >> clear the dependency_libs
> >>
> >> if you are confident that it won't break anything:
> >> delete the .la file entirely

If the only listing is dependency_libs, then the .la file can be
removed as long as the package itself doesn't use the .la for plugins.
If it does (and maintainers of such packages already know if their
package is affected), clear the dependency_libs.

> > Clearing the dependency_libs is always safe, afaics, so I'd rather say it is
> > something like
> > 
> > if depended-on
> > clear dependency_libs
> > else
> > remove *.la files
> 
> There are some good reasons to keep some specific *.la files around,
> that's why I'm not aiming at removing them, but at least have the real
> problem solved.
> 
> So I suggest:
> 
> if dependency_libs
>   clear dependency_libs

If it is just dependency_libs and there are no plugin issues, it IS
safe to remove the .la file rather than adding sed-based processing.

See these messages and pages for more information:

http://wiki.debian.org/ReleaseGoals/LAFileRemoval

http://lists.debian.org/debian-devel/2011/04/msg00055.html

http://lists.debian.org/debian-devel/2011/04/msg00199.html

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpbzgRNfZO0P.pgp
Description: PGP signature