Re: upload debian package error

[Sandro Tosi]

Hello xiangfu,
this kind of questions are better addressed to debian-mentors mailing
list, adding it, and you also already received a reply [1] there.

[1] https://lists.debian.org/debian-mentors/2009/06/msg00573.html

On Wed, Jul 1, 2009 at 08:55, xiangfu wrote:
> Hi
> I try to upload xburst-tools[1], I have two warning and one error.

is this a new package? I can't find it in our archive or an ITP for it.

> my question is
> 1. the version number must 1.0.0(like that). can I use 2009.06(something like 
> that to be a version)

if upstream has a version standard, use that, bu you can also use
dates for version.

You have to create a non-native package, that's the reason for
"source-nmu-has-incorrect-version-number"

I think this question proves you didn't read debian policy, developers
reference and new maintainers guide: please fill this gap of knowledge
asap, and before asking further questions.

> 2. I am not a maintainer. but I want to be this package's maintainer.
>   can I add my name and email to the control file

you MUST add your name if you want to be the maintainer. That's th
reason for "xburst-tools source" lintian error.

> 3. what am I got do with last warining.

remove spuriours, auto-generated files in clean debian/rules target.

> maybe I ignore some help page because My English is not very good.

English is very important for debian communication, so I strongly
suggest to improve your english.

> So give me some advice or direct.

Read teh doc I've mentioned above and use debian-mentors, not -devel.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ia32-libs transition

[Michael Meskes]

On Tue, Jun 30, 2009 at 11:04:38PM +0200, Joerg Jaspert wrote:
> > Waiting for multi-arch, Goswin's system permits me to use wine (and 
> > chromium 
> > browser) on my 64bits Debian.
> 
> A simple chroot will permit you to use this. And is a much saner thing
> than anything we have seen until now.

I beg to disagree here, well kind of. A *working* system that allows me to just
" install "
is far superior to a chroot setup especially for users less
experienced/interested in technical details. Now whether the current system is
*working* is a different story.

And yes, I absolutely agree that getting such changes done on ones system
*without* notice and *without* full functionality is a no-go, as is btw
changing libc6-i386 without communication with the ia32 people, if it really
happened that way. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: upload debian package error

[xiangfu]

Hi Sandro Tosi

Thanks for the reply.
I will try my best

Sandro Tosi wrote:
> Hello xiangfu,
> this kind of questions are better addressed to debian-mentors mailing
> list, adding it, and you also already received a reply [1] there.
> 
> [1] https://lists.debian.org/debian-mentors/2009/06/msg00573.html
> 
> On Wed, Jul 1, 2009 at 08:55, xiangfu wrote:
>> Hi
>> I try to upload xburst-tools[1], I have two warning and one error.
> 
> is this a new package? I can't find it in our archive or an ITP for it.
> 
>> my question is
>> 1. the version number must 1.0.0(like that). can I use 2009.06(something 
>> like that to be a version)
> 
> if upstream has a version standard, use that, bu you can also use
> dates for version.
> 
> You have to create a non-native package, that's the reason for
> "source-nmu-has-incorrect-version-number"
> 
> I think this question proves you didn't read debian policy, developers
> reference and new maintainers guide: please fill this gap of knowledge
> asap, and before asking further questions.
> 
>> 2. I am not a maintainer. but I want to be this package's maintainer.
>>   can I add my name and email to the control file
> 
> you MUST add your name if you want to be the maintainer. That's th
> reason for "xburst-tools source" lintian error.
> 
>> 3. what am I got do with last warining.
> 
> remove spuriours, auto-generated files in clean debian/rules target.
> 
>> maybe I ignore some help page because My English is not very good.
> 
> English is very important for debian communication, so I strongly
> suggest to improve your english.
> 
>> So give me some advice or direct.
> 
> Read teh doc I've mentioned above and use debian-mentors, not -devel.
> 
> Regards,


-- 
Best Regards
Xiangfu Liu

jabber : xiangf...@gmail.com
skype  : xiangfu.z


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535256: ITP: libogginfo-ruby -- Ruby library for accessing low-level information on ogg files

[Daniel Moerner]

Package: wnpp
Severity: wishlist
Owner: Daniel Moerner 

  Package name: libogginfo-ruby
  Version : 0.3.2
  Upstream Author : Guillaume Pierronnet 
  URL : http://ruby-ogginfo.rubyforge.org/
  License : GPL
  Programming Lang: Ruby
  Description : Ruby library for accessing low-level information on ogg 
files

Ruby-ogginfo provides access to the bitrate, length, samplerate, encoder,
and tag information of ogg files. It can also access and write tags for
ogg files provided that vorbis-tools is installed.

I have joined the pkg-ruby-extras team on alioth to maintain this package
as part of the team.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#535233: ITP: collectl -- Initial package request

[Bernd Schubert]

Hello Christopher,

On Wednesday 01 July 2009, Simmons, Christopher wrote:
> Package: collectl
> Version: 3.3.4
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> *** Please type your report below this line ***
> I wish to work on creating a debian package for collectl-3.3.4
>


I already have a package, just didn't have the time yet to upload it. 
http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/collectl/


This also includes some patches from Goswin.


Cheers,
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ia32-libs transition

[Yannick]

Goswin von Brederlow wrote:

> The choices where
> 1) rewrite the old ia32-libs + ia32-libs-gtk for the new libc6-i386
> or
> 2) make ia32-apt-get take over (slightly prematurely in hindsight)

If it's possible (according to ftp-masters) to have the old ia32-libs 
packages adapted to the new libc6-i386; the best thing, for me, would be to 
have a minimal[1] ia32-libs package in the archive and an ia32-archive tool 
for those who want other ia32-* packages or wants to keep up to date with 
library versions.

Yannick

[1] Minimal in the sense of the required libraries for packages needing i386 
in main (only wine?).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Wed, 01 Jul 2009, Charles Plessy wrote:
> Thank you for the feedback. It made me understood that the format can be even
> simplified. First of all, let me clarify that I do not aim at describing the
> format of Debian control files, but the proposed format for DEP5, which I
> propose for DEP3 as well since it is simple and does not require prior
> experience of Debian control files.

I don't see that as an advantage. I'd rather be able to reuse existing
parsers rather than creating new ones just for this purpose.

That said, supporting the "patch as script" case needs some trickery to
be able to reuse existing parsers (stripping "# " before passing lines
to the parser). But allowing invalid lines as comments in the middle will
make it completely impossible to reuse standard parsers.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Petter Reinholdtsen]

[Giacomo A. Catenazzi]
> Hmm, so a switch to dash it is not because of POSIX, but because
> of "better code" and lighter shell for our scripts?
>
> Which is also a good reason for the change.

Yes, it is a good change.  I would love to switch every installation
to dash as /bin/sh, but believe the path of least surprises to the
sysadmin is to only change new installations and not existing systems.

> But could you tell us more about the "subtle problems for shutdown
> sequences".

http://bugs.debian.org/159771 > is an example, solved by
switching from bash to dash. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

A standard patch rule for our rules

[Rafael Almeida]

A ``patch'' rule for debian/rules there should always be
for I'd like to easily apply patches created by me
Don't worry I don't think of anything too hard
a simple standarization will ease my heart

Today ``debian/rules build'' is always a good match
but there's no mandatory ``debian/rules patch''
Is the ``build'' rule mandatory? I don't even know
it seems to work for most packages, though

Patches, it seems, are for ``configure'' rule to apply
but I want to make a script and I think it won't fly
That script I think of will install my own patches
to any installable package, from zopes to apaches

Configures can change too much
like config.h files and such
There should be one and only patch rule
and then I'll be able to build my tool


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Goswin von Brederlow]

Rafael Almeida  writes:

> A ``patch'' rule for debian/rules there should always be
> for I'd like to easily apply patches created by me
> Don't worry I don't think of anything too hard
> a simple standarization will ease my heart
>
> Today ``debian/rules build'' is always a good match
> but there's no mandatory ``debian/rules patch''
> Is the ``build'' rule mandatory? I don't even know
> it seems to work for most packages, though

Debian policy describes all the required targets and some optional
ones.

> Patches, it seems, are for ``configure'' rule to apply
> but I want to make a script and I think it won't fly
> That script I think of will install my own patches
> to any installable package, from zopes to apaches
>
> Configures can change too much
> like config.h files and such
> There should be one and only patch rule
> and then I'll be able to build my tool

man dpkg-source

   Format: 3.0 (quilt)
   A source package in this format contains at least an  original  tarball
   (.orig.tar.ext  where ext can be gz, bz2 and lzma) and a debian tarball
   (.debian.tar.ext). It can also  contain  additional  original  tarballs
   (.orig-component.tar.ext).   component  can  only  contain alphanumeric
   characters and dashes ("-").
   ...

Behold the future is, aeh, soon.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Paul Wise]

Nice poem :)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: libswt and eclipse

[Adrian Perez]

Sorry about not posting earlier. 
I got contact with sjackman and he is willing to review/sponsor the
package I've finished already, so I'm working on it. 
Anyway, since I've uploaded the package to debian-mentors and since
every comment is welcome, I could use as many reviews as I can get ;). 

http://mentors.debian.net/debian/pool/main/s/swt-gtk

-- 
Best regards, 

Adrian Perez 


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

Re: ia32-libs transition

[Peter Samuelson]

[Goswin von Brederlow]
> You only need "apt-get update". The rest works in aptitude or synaptic.

I've gotten into the habit of using 'apt-get update' even though I
otherwise use aptitude.  This was necessary while I was building a
custom repository at work, because apt-get's error reporting is far
better.
-- 
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

Re: Switching the default /bin/sh to dash

[Luk Claes]

Petter Reinholdtsen wrote:
> [Giacomo A. Catenazzi]
>> Hmm, so a switch to dash it is not because of POSIX, but because
>> of "better code" and lighter shell for our scripts?
>>
>> Which is also a good reason for the change.
> 
> Yes, it is a good change.  I would love to switch every installation
> to dash as /bin/sh, but believe the path of least surprises to the
> sysadmin is to only change new installations and not existing systems.

Right, though how would you implement that? It doesn't look trivial at
all to me and will possibly be an extra source of errors.

It should also only affect external scripts that are bash specific
AFAICS and they would be easily 'fixed' by changing bin/sh to bin/bash
in the shebang (can even happen unconditionally).

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Andreas Metzler]

Rafael Almeida  wrote:
> A ``patch'' rule for debian/rules there should always be
> for I'd like to easily apply patches created by me
> Don't worry I don't think of anything too hard
> a simple standarization will ease my heart

> Today ``debian/rules build'' is always a good match
> but there's no mandatory ``debian/rules patch''
> Is the ``build'' rule mandatory? I don't even know
> it seems to work for most packages, though
[...]

"patch" indeded is the standard way nowadays. See policy 4.9.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[James Vega]

On Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler wrote:
> Rafael Almeida  wrote:
> > A ``patch'' rule for debian/rules there should always be
> > for I'd like to easily apply patches created by me
> > Don't worry I don't think of anything too hard
> > a simple standarization will ease my heart
> 
> > Today ``debian/rules build'' is always a good match
> > but there's no mandatory ``debian/rules patch''
> > Is the ``build'' rule mandatory? I don't even know
> > it seems to work for most packages, though
> [...]
> 
> "patch" indeded is the standard way nowadays. See policy 4.9.
 
I think you mean “recommended”, although not using that could be a
reason to have a README.source explaining how the package is handled.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: Switching the default /bin/sh to dash

[Frans Pop]

Raphael Hertzog wrote:
> On Thu, 25 Jun 2009, Raphael Geissert wrote:
>> Artur R. Czechowski wrote:
>> > What about debconf question?
>> 
>> dash already has one, the idea is to make it essential and default to
>> yes, so that as soon as it is installed the symlink is changed. If you
>> wish to have dash installed but not as /bin/sh you can always
>> dpkg-reconfigure dash.
> 
> Hum, AFAIK if it defaults to yes, it will be changed on upgrade for
> anyone who has not yet seen the question. So that doesn't work if your
> plan is to not change it except for new installations.

I've not seen any response to this, but it seems to me to be a very valid 
point.

dash currently is optional, so there will be on a lot of existing systems 
on which it is not installed. How is the planned strategy going to 
prevent dash becoming the default shell on existing systems when it gets 
installed for the first time because of its raised priority?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Raphael Geissert]

Frans Pop wrote:
> Raphael Hertzog wrote:
>> 
>> Hum, AFAIK if it [debconf prompt] defaults to yes, it will be changed on
>> upgrade for anyone who has not yet seen the question. So that doesn't
>> work if your plan is to not change it except for new installations.
> 
> I've not seen any response to this, but it seems to me to be a very valid
> point.

I though I had replied, sorry.

> 
> dash currently is optional, so there will be on a lot of existing systems
> on which it is not installed. How is the planned strategy going to
> prevent dash becoming the default shell on existing systems when it gets
> installed for the first time because of its raised priority?

There are two, both ugly actually, ways to do it:
a) by making dpkg pre-depend on dash so that it is installed and can see if
an older dpkg is installed
b) by finding a file that could tell us the installation date and base the
decision on that.

I've personally had no time to check if there's any file installed by dpkg
that could indicate the installation date. But another option, as some
people have already expressed, is to simply make the change on all the
installations.

Unless somebody knows a file that could be used to do it the b) way I guess
I won't have another option but to send another proposal stating that all
the installations would be modified.

In case the reasons are not obvious enough, a D-I-based solution is not a
candidate as newly created chroots (debootstrap-created) should get dash
and not bash.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Frans Pop]

Raphael Geissert wrote:
>> dash currently is optional, so there will be on a lot of existing
>> systems on which it is not installed. How is the planned strategy going
>> to prevent dash becoming the default shell on existing systems when it
>> gets installed for the first time because of its raised priority?
> 
> There are two, both ugly actually, ways to do it:
> a) by making dpkg pre-depend on dash so that it is installed and can see
> if an older dpkg is installed
> b) by finding a file that could tell us the installation date and base
> the decision on that.

An alternative that is still not pretty, but at least keeps the ugliness 
in the packages related to the switch and is fairly straightforward to 
implement, would be to make the new dash pre-depend on a new version of 
bash and have the maintainer scripts of bash preseed the dash template to 
false if:
- bash is being upgraded
- the dash template does not yet exist

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

The multiarch conundrum

[Aneurin Price]

Hi,

I've just been trying to dig through some of the multitude of past discussions
on the planning and implementation of multiarch in Debian (and Ubuntu).

The short version of this for TLDR folks is that nobody seems to have coherently
written down all the problems in a way that they can be addressed, so far as I
can see.

The longer version:

It seems clear that there is no consensus yet on what exactly needs to be done,
let alone how to get there; discussions seem to go round in circles, then
eventually peter out to begin anew at a later date. If there is anywhere where
real progress is being made, then I can't find it, but I think a large part of
the problem is down to poor communication.

My proposal for one way to try moving forward with this is as follows:

Currently the collective discussions about multiarch have taken place in
numerous threads on numerous mailing lists, which makes it hard to find any
specific information.

I believe that a wiki or similar centralised collaborative process is a good way
of tying this together. If there is already some location where this is being
actively worked on in such a fashion then I apologise, and much of this mail
will be rather pointless - in which case that location really ought to be easier
to find :P.

Start with https://wiki.ubuntu.com/MultiarchSpec. The reason for choosing the
Ubuntu wiki page is that there is already some real content there, in an
organised form. If http://wiki.debian.org/multiarch is a better place then fine,
but either way it would be good to have the same content, or at least not
disagreement between the two. Ideally one would act as a pointer to the other -
this is assuming that everyone wants Ubuntu and Debian heading in the same
direction here, which seems to be the consensus.

Within the spec page there are sections describing the design and some notes on
the implementation. One major point which is missing is that each section needs
some description of the objections to it - which surely exist, otherwise we'd
already have multiarch by now, wouldn't we? Currently it looks more like 'well
that's a nice plan; why isn't it happening?'

Further, there has already been some work done which has been rejected or
ignored - this needs to be presented and the reasons documented; it doesn't
really help anyone to forget about past attempts. So far I've found the patches
by Goswin on the Alioth multiarch project page[0]; there must be more scattered
about the place?

Finally, there needs to be some organisation of the many existing threads on the
topic. A good first start would be to search through the list archives and add
links to related discussions on the wiki page - we need to be able to go to one
place and get an overview of the issues, proposals, and objections, without
having to hunt that information down. This way we can hopefully avoid going over
the same issues and making the same mistakes and arguments repeatedly.

If there is no objection, I would like to do the following:

* Merge multiarch information from the Debian wiki into the Ubuntu wiki.
  (I'm not too sure about tho organisation of the Ubuntu wiki; would the spec
  page be inappropriate for this? Where would be better?)
* Add pointers to any existing patches, and links to any discussions about them
  if I can find them in the ML archives.
* Start a list of related discussions and dig out archive links from whatever
  mailing lists are appropriate. So far I can think of debian-devel,
  debian-dpkg, debian-glibc (?), debian-amd64. Are there others? I don't know
  about any Ubuntu lists but I imagine it's been discussed to death there too.
* Start monitoring those lists for multiarch-related discussions and update the
  wiki appropriately.
* Possibly stub out some empty 'objections' sub-headings in the spec design, in
  the naive hope that somebody reading will see them and think 'no objections?
  Lies! I have objections!', and actually fill them in.


Does anybody have opinions on whether any of this would be even remotely useful?

-Nye

[0] https://alioth.debian.org/projects/multiarch/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The multiarch conundrum

[Steve Langasek]

On Wed, Jul 01, 2009 at 09:53:56PM +0100, Aneurin Price wrote:

> I've just been trying to dig through some of the multitude of past discussions
> on the planning and implementation of multiarch in Debian (and Ubuntu).

> The short version of this for TLDR folks is that nobody seems to have
> coherently written down all the problems in a way that they can be
> addressed, so far as I can see.

https://wiki.ubuntu.com/MultiarchSpec is the work in progress on this, and
there is a plan to move the implementation forward once this is finalized.
Please don't distract from this with yet another metadiscussion.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Raphael Geissert]

Frans Pop wrote:
> An alternative that is still not pretty, but at least keeps the ugliness
> in the packages related to the switch and is fairly straightforward to
> implement, would be to make the new dash pre-depend on a new version of
> bash and have the maintainer scripts of bash preseed the dash template

bash playing the evil role, trying to keep some users for himself :)

> to false if:
> - bash is being upgraded
> - the dash template does not yet exist
> 

It's another option, yes.

Will wait some more feedback, though.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535396: ITP: wrapsrv -- DNS SRV record command line wrapper

[Robert Edmonds]

Package: wnpp
Owner: "Robert S. Edmonds" 
Severity: wishlist

* Package name: wrapsrv
  Version : 0.1
  Upstream Author : Internet Systems Consortium, Inc.
* URL : ftp://ftp.isc.org/isc/toolmakers/wrapsrv/
* License : ISC
  Programming Lang: C
  Description : DNS SRV record command line wrapper
 wrapsrv adds support for connecting to a network service based on DNS SRV
 record lookups to commands that do not support the DNS SRV record. wrapsrv
 implements the weighted priority client connection algorithm in RFC 2782.
 The specified command line will be invoked one or more times with %h and %p
 sequences in the command line substituted for the hostname and port elements
 of the selected SRV record. 

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature

Bug#535429: ITP: xburst-tools -- tools for Ingenic XBurst CPU USB boot and NAND flash access

[Xiangfu Liu]

Package: wnpp
Severity: wishlist
Owner: Xiangfu Liu 


* Package name: xburst-tools
  Version : 0.0+200906
  Upstream Author : Xiangfu Liu 
* URL : http://github.com/xiangfu/xburst-tools
* License : GPL
  Programming Lang: C
  Description : tools for Ingenic XBurst CPU USB boot and NAND flash access

xburst-tools contains tools for Ingenic XBurst CPU device booting.
It can flash bootloader, kernel, rootfs to Ingenic XBurst CPU
device NAND, and also has test functions for Ingenic XBurst CPU 
devices.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-proposed'), (500, 'jaunty-backports'), (500, 'jaunty')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Charles Plessy]

Le Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler a écrit :
> Rafael Almeida  wrote:
> > A ``patch'' rule for debian/rules there should always be
> > for I'd like to easily apply patches created by me
> > Don't worry I don't think of anything too hard
> > a simple standarization will ease my heart
> 
> > Today ``debian/rules build'' is always a good match
> > but there's no mandatory ``debian/rules patch''
> > Is the ``build'' rule mandatory? I don't even know
> > it seems to work for most packages, though
> [...]
> 
> "patch" indeded is the standard way nowadays. See policy 4.9.

Unfortunately, it seems that with quilt, it is better ot use $(QUILT_STAMPFN)
in order to avoid a target to become phony. I do not know for other systems.

I just updated http://wiki.debian.org/debian/patches to mention this fact.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Ben Finney]

Charles Plessy  writes:

> Le Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler a écrit :
> > "patch" indeded is the standard way nowadays. See policy 4.9.
> 
> Unfortunately, it seems that with quilt, it is better ot use
> $(QUILT_STAMPFN) in order to avoid a target to become phony.

What's wrong with having a phony target? We already have many of them,
and a standard way of dealing with them: as dependencies of the ‘.PHONY’
target.

It seems to me that the whole point of adding ‘patch’ as a (phony)
target is to allow a dependency on that target, instead of something
patch-system-specific. What is your reasoning for wanting to diverge
from that?

-- 
 \   “Two possibilities exist: Either we are alone in the Universe |
  `\   or we are not. Both are equally terrifying.” —Arthur C. Clarke, |
_o__) 1999 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: A standard patch rule for our rules

[Russ Allbery]

Ben Finney  writes:
> Charles Plessy  writes:

>> Unfortunately, it seems that with quilt, it is better ot use
>> $(QUILT_STAMPFN) in order to avoid a target to become phony.

> What's wrong with having a phony target? We already have many of them,
> and a standard way of dealing with them: as dependencies of the
> ‘.PHONY’ target.

> It seems to me that the whole point of adding ‘patch’ as a (phony)
> target is to allow a dependency on that target, instead of something
> patch-system-specific. What is your reasoning for wanting to diverge
> from that?

I think Charles may be referring to the need to use $(QUILT_STAMPFN)
rather than patch as a dependency of a build-stamp target, since
otherwise the dependency on patch forces build-stamp to be always
considered out of date even if the stamp file is up-to-date.  This has
caused problems for a few packages where the build target was run
repeatedly in ways that it wasn't intended to.  Depending on
$(QUILT_STAMPFN) instead is more reliable.

I'm not entirely sure how that relates to the topic of conversation in
this thread, though.  It doesn't affect the presence of the patch target
in debian/rules.

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