Easy Paychecks From Home

[Power Marketing Team]

Do not let the economy get you down.  We have the most exciting global home 
business launching next week,

Our automated marketing system does nearly everything for you after, and you 
sit back and collect.

Be smart, supplement your earnings with our proven system:  
http://alive7.begininwealth.in/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc
 

Thank you,
M. Gold


 
 
 
 
 
 
 
 
 
  
 
 
 
 
 
"If someone is going down the wrong road, he doesn't need motivation to speed 
him up. What he needs is education to turn him around" - Jim Rohn




This message was sent by user: alive7 on our system.
To be removed or report abuse click below.


Power Marketing Team
#1776 PO Box 13240,Johnsonville,Wellington NZ 6440

http://alive7.begininwealth.in/rm/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc



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

Source-Depends? Autoreconf?

[Marius Vollmer]

Hi,

here is some ghost spooking around in my head, and maybe you can help me
put it to rest.

The GNU build system makes a distinction between maintainers of a
source package and the people who eventually install it.  Essentially,
GNU is producing a source distribution that is aiming for very high
portability and ease of installation from source.

Because of that, the source packages produced by GNU projects are 'fat':
they contain the well-known biggish autotools build machinery, and they
even had a formal 'maintainer mode' concept.  That mode is falling out
of favor (because it is not doing its job in the best possible way), but
the release tarballs are still carefully constructed to need much fewer
external software than the maintainers need when creating that release
tarball.

Debian is much less concered about this distinction: for example, there
is no "dist" or "source" target in debian/rules, and no "Source-Depends"
or "Release-Depends" field that would state the required packages for
running it.

Making a Debian source package always felt cumbersome: dpkg-source just
tars up everything in front of it (I exaggerate, of course), and at
least I am not used to having to clean my source tree before making a
distribution tarball out of it.

Of course, Debian doesn't really need to be as careful about making
release tarballs as the GNU project: a Debian source package only needs
to work in Debian, and there is no need to include pre-built
documentation in the source, for example, because the tools to build it
are always there.

Still, I feel that this area of what should and shouldn't be in a source
package is a bit under-addressed in Debian.  (That is very likely only my
own ignorance.  I learned the little I know about packaging in Maemo;
apologies might be in order for me speaking up on this list... :)

On one end of the spectrum, a Debian source package could try to have as
little dependencies during build-time as possible.  This would be nice
for distributions downstream of Debian that would have less trouble
importing Debian source packages.  In this case, I think we would need
something like Source-Depends and making a source package would consist
of running the equivalent of "make maintainer-clean && autoreconf".

(If a downstream distribution wants to make changes to the source
packages that it imports from Debian, it can create the changed source
packages in Debian itself.  Ideally, there shouldn't ever be a need to
create a source package in such a--by choice--anemic downstream
distribution.)

On the other end of the spectrum, a source package would only contain
genuine sources; it wouldn't contain anything that can be regenerated
from other files in the source package.  For the typical package made
from a GNU upstream, this would mean always running autoreconf before
configure, for example.

I have the feeling that most Debian packages are somewhere in the
middle, without having any real opinion about where to go: they contain
lots of generated files, but there is no formal, uniform means to
regenerate them.  Also, no second thought is given to adding monster
toolchains like gtk-doc-tools to Build-Depends.


I think the first end of the spectrum is more flexible, and adding the
necessary bits to Debian (such as a "source" target in debian/rules)
would allow Debian to become a lot stronger as a repository of source
packages.  This added strength would mostly help the people lifting code
from Debian, of course, but I think Debian itself would also benefit
from it.

For example, Debian's 'lesser' architectures might have an easier time
with reduced build-dependencies, and it might even be possible to
formally allow 'cross' architectures into Debian: those architectures
would not be as general as the big ones and all packages for them would
be cross-compiled, perhaps.  (Reducing build-dependencies of source
packages goes a long way towards cross-compilability.)

Also, being more careful about source packages can help with keeping
things in VCS.  The new formalism for creating source packages can make
it easier to create them automatically from a 'bare' CVS branch that
doesn't contain any generated files.

That is actually what got me started thinking about this in the first
place: I want to keep my sources (both upstream and packaged) in a VCS
without any generated files; I want to automatically create source
packages of a bare branch in a rich environment; and I want to
automatically compile these source packages in a poor environment (that
doesn't have all the tools I use during development).

So, what do you think?


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

Re: Source-Depends? Autoreconf?

[Roger Leigh]

On Sat, May 02, 2009 at 02:50:26PM +0300, Marius Vollmer wrote:
> Making a Debian source package always felt cumbersome: dpkg-source just
> tars up everything in front of it (I exaggerate, of course), and at
> least I am not used to having to clean my source tree before making a
> distribution tarball out of it.

I personally dislike the entire concept of "Debian-native" source packages.
I would like it if all software in Debian had a split .orig/.diff.  Even
for real "native" sources, it makes things like backporting, reuse by
others, and minor fixes, NMUs etc. rather simpler to do, and you get a
diff of the changes to boot, which makes reintegration of the changes
less time consuming (just review and apply the diff).  Debian-native
packages hinder collaboration and reuse by others.

> Of course, Debian doesn't really need to be as careful about making
> release tarballs as the GNU project: a Debian source package only needs
> to work in Debian, and there is no need to include pre-built
> documentation in the source, for example, because the tools to build it
> are always there.

While it might be common practice for Debian-originating packages to be
packaged "Debian-native", I really do think that it makes sense to keep
the "upstream" and "Debian" parts separate.  For one thing, it
separates formal releases of the real code from the packaging which, by
its very nature, ends up being synched to Debian releases.  It also
encourages better separation of responsibilities and makes the packaging
(upstream and Debian) easier to deal with.

> Still, I feel that this area of what should and shouldn't be in a source
> package is a bit under-addressed in Debian.  (That is very likely only my
> own ignorance.  I learned the little I know about packaging in Maemo;
> apologies might be in order for me speaking up on this list... :)
> 
> On one end of the spectrum, a Debian source package could try to have as
> little dependencies during build-time as possible.  This would be nice
> for distributions downstream of Debian that would have less trouble
> importing Debian source packages.  In this case, I think we would need
> something like Source-Depends and making a source package would consist
> of running the equivalent of "make maintainer-clean && autoreconf".

Well, I do think this would make a certain degree of sense for people
working /on/ the package, as opposed to just automated building of the
package.  However, keeping these fields up-to-date and ensuring their
correctness would be an issue.  The existing fields if incorrect will
result in an FTBFS and prompt correction.  These new ones are only used
for manual work, and I'm not sure if it's worth the extra effort.
Typically maintainers will be well aware of what the "extra" tools are
they need for a complete development (as opposed to build) environment,
and will ensure they are present.  I'm not opposed to the concept, but
I do have concerns about keeping them current and correct.

As a general comment about your entire post, I think eliminating
Debian-native packages would be a valuable goal.  It will require
developers/maintainers to work on correctly packaging and
distributing their code like all other upstreams, rather than just
dumping their working tree into a tarball and calling it a "release",
which will increase the code/package quality and robustness.
And of course, it makes it vastly easier for third parties to work
with, making collaboration with downstream distributors much easier.

(All the Debian-specific software I work on such as schroot and
sbuild is all correctly autoconfiscated and packaged with a
.orig.tar.gz, despite lintian moaning about it for -1 releases.
It makes my life much easier.)

> That is actually what got me started thinking about this in the first
> place: I want to keep my sources (both upstream and packaged) in a VCS
> without any generated files; I want to automatically create source
> packages of a bare branch in a rich environment; and I want to
> automatically compile these source packages in a poor environment (that
> doesn't have all the tools I use during development).

Look at schroot.git for an example of how this is done.  You need to
./bootstrap the autotools in a "rich" environment, and then
./configure && make dist to get the upstream release tarball.
I don't currently separate the debian packaging on a separate branch,
but I do plan to in the future due to it making backporting and
supporting multiple debian branches simultaneously much easier.  This
wouldn't be a hard change, but I do look forward to dpkg-source
3.0 (git) becoming allowed officially to allow this type of repo to
be supported natively by the build infrastructure.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email t

Re: Source-Depends? Autoreconf?

[Bernhard R. Link]

* Marius Vollmer  [090502 13:50]:
> Still, I feel that this area of what should and shouldn't be in a source
> package is a bit under-addressed in Debian.  (That is very likely only my
> own ignorance.  I learned the little I know about packaging in Maemo;
> apologies might be in order for me speaking up on this list... :)

First of all, you do not discuss the most common type of packages: do
not change the build-system, but just use it. This means autotools are
never called, neighter when preparing the package, nor when building the
package.

I assume you only speak about Debian source package that have to change
the build system, because I think using upstream's build system where it
is resonably possible is the best way to go.

> On one end of the spectrum, a Debian source package could try to have as
> little dependencies during build-time as possible.

The "as little dependencies as possible" part is only a very minor thing
to look for in packages, especially when talking about relatively small
things like autotools.

The more important goals are:
 - derivation from upstream:
+ every change means using something not previously tested.
 - verifiability/identification of changes
+ we want users to see what we changed so they know what they use
+ we want upstreams/other downstreams to see what we changed so they
  can profit from out work
 - maintainability
+ when it is to hard for a maintainer to do something, errors happen
  more easily.
 - robustness
+ the less chances for failing builds, the better

These goals contradict each other, and the trick is to find a good
compromise.

The first dogma Debian usually follows is shipping sources as an
pristine upstream tarball plus changes. As this only effects the form
of distribution, it does not change anything but representation of
changes (assuming there are good enough tools). And there is no way to
claim changes from upstream are better expressed than by starting with
the pristine tarball.

Now if you have changes in the build system to do, there are multiple
possibilities:

Change source files, run autoreconf, ship the result in .diff.gz:
- derivation: may use a different autotools version than upstream, but
  that might be likely to be tested by others.
- identification: hard, as it is hard to see what is changed where
- maintainability: relatively easy
- robustness: good

Change source files, run autoreconf, ship the result in a seperate patch
- derivation: may use a different autotools version than upstream, but
  that might be likely to be tested by others.
- identification: better, as the "automatic" changes are in a single diff
- maintainability: needs proper tools or scripts, but quite easy
- robustness: good

Change source files, change the generated files to what the changes with
the same autotools version would produce or otherwise minimal
- derivation: actual derivation my be smaller than before, but noone
  else tests exactly that code.
- identification: most of the time even better to see what actually
  changed, though one has be able to verify that the build system's
  sources and generated files are modified the same way.
- maintainability: needs manual work, bad
- robustness: good

Change source files, run autoreconf at build time
- derivation: package is build with a system run with another autotools
  version, but the way this is done is canonical
- identification: as only the build system's source file changes, easy
  to grasp (unless the new autotools version bring the real changes).
- maintainability: perfect
- robustness: danger of new autotools version breaking the build


As you see, most of the pros and cons of each method depend massively
on what the actual changes are.

Also assessment of external factors plays an important role. Several
years ago, autotools changed quite rapdily and disruptively. Robustness
was an important reason to not run autotools while building.
Now this has changed, so running autotools at build time is often
considered the best solution, as it causes clean diffs, well-tested
build paths and easy maintanability. (Though it still depends on the
actual case. Very small changes, massively outdated uptreams and/or
usage of strange corner-cases of autotools can still make something else
better depending on a wide range of factors).

> This would be nice
> for distributions downstream of Debian that would have less trouble
> importing Debian source packages.

I do not think why this is "nice". If they do not change anything, it
does not matter much how the source builds. If they change anything,
every side could be argued to be more "nice".

Hochachtungsvoll,
Bernhard R. Link


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

Re: Source-Depends? Autoreconf?

[Henrique de Moraes Holschuh]

On Sat, 02 May 2009, Bernhard R. Link wrote:
> First of all, you do not discuss the most common type of packages: do
> not change the build-system, but just use it. This means autotools are
> never called, neighter when preparing the package, nor when building the
> package.

Yeah, it is really common, and it is also close to being the 'worst
practice' (except for the few packages whose upstream takes very good
care of their build system and keep it up-to-date themselves).

> The more important goals are:
>  - derivation from upstream:
> + every change means using something not previously tested.

Well, as a rule, we do much better at testing build systems than any
upstream, anywhere.  We build for MUCH more platforms, for one.  And
likely we're already using a newer toolchain than upstream anyway...
and that's far more likely to root out bogosity (or to cause bogosity
for that matter) than autoreconf.

> Change source files, run autoreconf at build time
> - derivation: package is build with a system run with another autotools
>   version, but the way this is done is canonical
> - identification: as only the build system's source file changes, easy
>   to grasp (unless the new autotools version bring the real changes).
> - maintainability: perfect
> - robustness: danger of new autotools version breaking the build

This is the current best practice, but it needs to be done right.
There is a reason why autotools-dev recommends that you should use the
proper environment vars (and build-deps and conflicts when needed) to
lock the auto* versions you have tested with.

There is one _very_ important reason why it is the best practice, too:
since the build process is complete, and tested at every upload on
every arch, it is far less likely to break on the hands of the
security team, or on the hands of a porter of a new arch, or in the
hands of someone else in a time of need.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems

[Nick Leverton]

On Wed, Apr 22, 2009 at 03:49:46PM +0200, Cyril Brulebois wrote:
> Nick Leverton  (22/04/2009):
> > Thanks for your interest in my IT(re)P and your comments.
> 
> No problem.
> 
> > Of the stated reasons for removal:
> > 
> > > | Please remove unicorn:
> > > | - mostly unused (2 in popcon for the binary package unicorn)
> > 
> > The unicorn binary package contains ancillary utils which are frankly
> > of little use.  A better metric for the use of driver packages such
> > as unicorn would be the module source.  Unicorn-source scores a not
> > completely moribund 50 users.
> 
> Alright. I guess the person proposing the removal thought that the tools
> were some kind of needed to get it working.

I'm thinking of renaming the binary package as unicorn-utils for the
next upload to make this clearer.  It's going to go into NEW anyway.
Though with only two popcon users I guess most people have figured it
out :)  It contains the natty GTK control/status app for the board though
which I've done some work on.

> > A better decision on the package's user base could have been gathered
> > by considering all the packages built from unicorn, not just one of
> > them.
> 
> Sounds fair.

Well I've discovered this may not be QA's oversight.  For some reason
the last upload didn't seem to link unicorn-source .deb to the unicorn
source package.  Don't know why not as they are both in the .dsc.

> Yes, it's bad luck that your activity wasn't noticed.

No worries.  People running unstable should be prepared for packages
popping in and out of installability.  It's probably quantum ...

> I guess this package might not have got a serious bug filed against
> it/wasn't noticed when the first round of gtk1 MBF because it's in
> non-free?
> 
> Also, not all packages are trivially portable, quite the opposite from
> what I've seen. Good luck it only took 2 hours. :)

My hubris was too quick, I found some bugs due to the Glade1 templates
generating some code which didn't work the same in GTK2.  Getting rid
of autoconf cruft from the .diff after running autoreconf took a while
too :(

> I think it might be worth adding an X-Debbugs-CC to the $package@ QA
> address when filing removal with reportbug, and add that step to the
> process. As you said, since you were monitoring this package, you would
> have then been notified and had more chance to reply.

Good idea.

> > I think that perhaps I should open a bug on the removal process, so
> > that at least removal notices are filed against the actual package,
> 
> I'll take that topic to debian...@.

I wouldn't want to mandate times because circumstances differ and the
core teams do a great job anyway without adding constraints.  I think
a policy of filing a bug on the package would be sufficient "notice to
interested parties".

Doing so with some suitable bug-tag might also help to automate the
remainder of the process, thus hopefully not adding to QA's work once
the decision had been taken to remove a package as unused/unmaintained.
By someone taking ownership of the bug they could declare an interest
and forestall the process.  However I wouldn't currently have time to
learn debbugs and code this myself :) so I would understand if other
stuff were more important.

Hope I don't sound too legalistic.  I think Debian's Developer and
QA processes are two of its great strengths and the chief source of
its consistently high quality.  The prospect of Debian quality control
helping us meet engineering standards is the reason I'm pushing Debian
at work instead of our existing RH/Fedora lash ups.

> > Anyway as I say, thanks for your interest and your time in responding.
> > I hope I've addressed your comments fairly.
> 
> No problem. I might nevertheless remove unicorn from m-a's
> compliant.list (I plan to do some cruft removal in the next upload).
> You're welcome to open a bug against module-assistant to have it
> included back once your package reaches the archive (although I'm trying
> to follow *-source package additions by myself).

That'd be fine by me.  I've re-packaged it to work with and indeed to
build using module-assistant, but I want to make sure the package is
great before re-introducing it.  The motherboard with the card in seems
to be buggy and causing IRQ problems.  I need to try it in a different
machine to be sure the drivers are OK, before uploading unicorn again.

Nick


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

Re: Source-Depends? Autoreconf?

[Manoj Srivastava]

Hi,

I wold like to say that I do not really see the Degbian source
 package as a primary mode of development  communication between Debian
 and the downstreams, as it is strictly a snapshot, and loses too much
 history.  I think that people deriving code based on lines of
 development I have in my packages will be better served by using a
 distributed VCS; and collaboration and feeback would be far easier. The
 Debian source packages are a stop gap . and vastly inferior, back
 channel mechanism.

On Sat, May 02 2009, Bernhard R. Link wrote:


> Change source files, run autoreconf at build time
> - derivation: package is build with a system run with another autotools
>   version, but the way this is done is canonical
> - identification: as only the build system's source file changes, easy
>   to grasp (unless the new autotools version bring the real changes).
> - maintainability: perfect
> - robustness: danger of new autotools version breaking the build

I have been doing this for some time now,  and have not yet had
 the sky fall on my head. I have started treating autotools just like
 any other part of the toolchain, like, say, gcc. I do not carry around
 the .o files in the package i case someone tries to build with a newer
 gcc that could introduce errors (as the new G++ did for one of my
 packages). 


> Also assessment of external factors plays an important role. Several
> years ago, autotools changed quite rapdily and
> disruptively. Robustness was an important reason to not run autotools
> while building.  Now this has changed, so running autotools at build
> time is often considered the best solution, as it causes clean diffs,
> well-tested build paths and easy maintanability. (Though it still
> depends on the actual case. Very small changes, massively outdated
> uptreams and/or usage of strange corner-cases of autotools can still
> make something else better depending on a wide range of factors).

The same might be true for any other component in the tool
 chain, no?

manoj
-- 
"Just the facts, Ma'am." Joe Friday
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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