A recent feature of Linux software RAID is a "write intent bitmap". The
purpose of this is that before writing to a section of disk the bitmap is
altered to mark it as dirty. Then if the machine experiences a power failure
or other catastrophic event then when rebooted it will know that the se
On Sat, 26 Jan 2008, Charles Plessy wrote:
> To make the dialign-t package, I removed the documentation from the
> upstream tarball, that I use for a dialign-t-doc package, in the
> non-free section as the their LaTeX sources are not provided.
>
> Now, I was informed that the reason is that the so
Charles Plessy <[EMAIL PROTECTED]> writes:
> To make the dialign-t package, I removed the documentation from the
> upstream tarball, that I use for a dialign-t-doc package, in the
> non-free section as the their LaTeX sources are not provided.
>
> Now, I was informed that the reason is that the so
Dear all,
To make the dialign-t package, I removed the documentation from the
upstream tarball, that I use for a dialign-t-doc package, in the
non-free section as the their LaTeX sources are not provided.
Now, I was informed that the reason is that the sources have been lost.
In that case, don't
Le Fri, Jan 25, 2008 at 12:51:40PM -0500, Joey Hess a écrit :
>
> Unless what you get when you run apt-get source is *not* the source that
> is in the end used to build the package, which is instead squirrled away
> in some arbitrary patch format somewhere under debian/. In this case,
> unlike in
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: dejima-mincho
Version: 126
Upstream Author: Yoshiki Hayashi <[EMAIL PROTECTED]>
URL: http://code.google.com/p/dejima-fonts/
License: MIT
Description: antiquated Japanese Tr
Package: wnpp
Severity: wishlist
Owner: Eric Cooper <[EMAIL PROTECTED]>
* Package name: eeepc-acpi-source
Version : 1.0-1
Upstream Author : Eric Cooper <[EMAIL PROTECTED]>
* URL : http://www.cs.cmu.edu/~ecc/eeepc-acpi_1.0.tar.gz
* License : GPL
Programming Lan
thanks to lucas nussbaum the address
http://debian.binera.de/wnpp/
is now accessible through
http://wnpp.debian.net/ .
sebastian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I demand that Pierre Habouzit may or may not have written...
> On Fri, Jan 25, 2008 at 07:26:04AM +, Andreas Tille wrote:
>> What would you suggest to enhance the situation?
> For one, I'm not sure the "situation" is that horrible. Second, I believe
> joeyh's proposal to be able to use some D
Andreas Tille <[EMAIL PROTECTED]> writes:
> Call me old fashioned but I want to see a set of files if I do
>
> apt-get source XY
>
> and want to see the patches to the original tarball.
That's not "old-fashioned", because that's never been what 'apt-get
source foo' is meant to do. "old-fash
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: qemulator
Version: 0.5-3
Upstream Author: [NAME <[EMAIL PROTECTED]>]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: qemulator
Version: 0.5-3
Upstream Author: [NAME <[EMAIL PROTECTED]>]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.
On 25/01/08 at 13:46 -0500, Joey Hess wrote:
> Would it be possible to get access to the binaries? I'm interested in
> choose-mirror, localechooser, ikiwiki, libperl-critic-perl, and
> fbreader, which differed only in package size between the two builds.
The host I stored them on isn't web-accessi
On 25/01/08 at 18:10 +0100, Daniel Leidert wrote:
> Am Freitag, den 25.01.2008, 16:37 +0100 schrieb Lucas Nussbaum:
> > On 25/01/08 at 15:59 +0100, Daniel Leidert wrote:
>
> [docbok-xsl-doc-html]
> > But if the size is the same, why would the Installed-Size differ? I have
> > no idea. I've copied
Package: wnpp
Severity: wishlist
Owner: Krzysztof Burghardt <[EMAIL PROTECTED]>
* Package name: grub2-splashimages
Version : 1.0.0
Upstream Author : Krzysztof Burghardt <[EMAIL PROTECTED]>
* URL : none (native package)
* License : GNU FDL or CC-BY(-SA) (one or b
Stefano Zacchiroli wrote:
> On Thu, Jan 24, 2008 at 09:07:07PM -0600, Raphael Geissert wrote:
>> It's been some time since DEHS[1] had some 'big' changes (probably since
>> its creation). Here's a list of changes that have been done lately:
>
> Can you please add an entry about that to
> http://wi
Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:
> Each maintainer may be familiar with his pet patch system, but for
> archive wide work I agree the current approach is a mess and makes
> security updates painful. Since it's unlikely to change anytime soon,
> each source packages, which uses someth
Michael Banck wrote:
> Why do you CC debian-devel for a regular bug report? If every bug
> report would be copied to debian-devel, the list would be totally
> flooded.
>
Sorry. Will take care of that.
Ritesh
--
If possible, Please CC me when replying. I'm not subscribed to the list.
--
To
Michal Čihař wrote:
> Hi
>
> Dne Fri, 25 Jan 2008 16:37:36 +0100
> Lucas Nussbaum <[EMAIL PROTECTED]> napsal(a):
>
>> Seems like gzip didn't compress the files in the exact same way, even if
>> the resulting size was the same:
>> $ diff -burN t t2
>> Binary files t/usr/share/doc/docbook-xsl-doc-
Andreas Tille wrote:
>
> I'm aware that the watch file of adun.app is wrong because it reports
> version 0.74 as newer than 0.8.2 (upstream should have choosen 0.7.4
> instead
> of 0.74). Any hint how to fix this watch file line
>
>http://download.gna.org/adun/Adun-(.*)\.tar\.gz
>
> to do t
On Fri January 25 2008 3:47:36 am sean finney wrote:
> hiya,
>
> On Friday 25 January 2008 09:50:56 am Andreas Tille wrote:
> > I would be absolutely unhappy about this. On one hand it is just a
> > waste of resources to clone upstream source on the other hand handling a
> > set of (documented!!)
Hello Andreas,
Andreas Tille wrote:
> On Thu, 24 Jan 2008, Raphael Geissert wrote:
>
>> It's been some time since DEHS[1] had some 'big' changes (probably since
>> its creation). Here's a list of changes that have been done lately:
>
> I don't know how to file wishlist bug reports but I would li
Quoting Lucas Nussbaum ([EMAIL PROTECTED]):
> >> I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
> >> use dpatch. It would be great to document in some place (devref?) why
> >> quilt should be used instead of dpatch, because I don't think it's
> >> obvious for everybody :)
Would it be possible to get access to the binaries? I'm interested in
choose-mirror, localechooser, ikiwiki, libperl-critic-perl, and
fbreader, which differed only in package size between the two builds.
That's semi-understandable for choose-mirror, but I can't guess what
would make the others buil
Andreas Tille wrote:
> What would you suggest to enhance the situation?
Each maintainer may be familiar with his pet patch system, but for
archive wide work I agree the current approach is a mess and makes
security updates painful. Since it's unlikely to change anytime soon,
each source packages,
On Fri, 25 Jan 2008, Michael Banck wrote:
> On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > On 25/01/08 at 08:01 +, Steve Langasek wrote:
> > > As a second runner up, quilt is ok by me. :)
> >
> > I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
> >
Andreas Tille wrote:
> If you ask me personally the situation with zillions of competing
> VSC systems is even worse than the hand full of tools to build
> Debian packages. I personally refuse to switch VCS every six month
> because there is a newer and even better one if you trust the one
> or ot
Andreas Tille wrote:
> I'm aware that the watch file of adun.app is wrong because it reports
> version 0.74 as newer than 0.8.2 (upstream should have choosen 0.7.4 instead
> of 0.74). Any hint how to fix this watch file line
>
> http://download.gna.org/adun/Adun-(.*)\.tar\.gz
>
> to do the ri
FWIW, I'm very disappointed in this thread so far -- everyone in it
seems to be missing between 50 and 90% of the point of my blog post.
Pierre Habouzit wrote:
> Oh and don't try to ask for complete uniformity in packaging, there
> are 1000 DDs, 10 times as many packages, different needs (you do
Mike Hommey wrote:
> On Fri, Jan 25, 2008 at 11:14:24AM +0100, sean finney <[EMAIL PROTECTED]>
> wrote:
>> On Friday 25 January 2008 11:08:13 am Mike Hommey wrote:
>> > On Fri, Jan 25, 2008 at 09:55:02AM +, Jon Dowland
>> <[EMAIL PROTECTED]> wrote:
>> > > Does anyone know how common it is fo
Jon Dowland wrote:
> On Fri, Jan 25, 2008 at 10:13:37AM +0100, Mike Hommey wrote:
>> The only sad thing is that quilt only deals with patches (i.e. diffs),
>> whereas dpatch can do scripts, too. Anyways, I now prefer not using
>> dpatch of quilt.
>
> Does anyone know how common it is for this add
On Fri, Jan 25, 2008 at 04:25:42PM +0100, Lucas Nussbaum wrote:
> On 25/01/08 at 15:36 +0100, Frank Lichtenheld wrote:
> > Hmm, the debdiff output is not really helpful in deciding whether my
> > packages actually have a problem (doc-linux and libgpod). It just
> > reports a different Installed-Siz
On Thu, 24 Jan 2008, Martin Michlmayr wrote:
> * Lucas Nussbaum <[EMAIL PROTECTED]> [2008-01-24 21:08]:
> > I think that the BTS learns the hierarchy of packages' versions by
> > parsing the changelogs. Would your plan work even if the version is a
> > fake one (not in any changelog)?
>
> At leas
On 25/01/2008, Frank Küster wrote:
> I don't think these bugs should be closed without considering the type
> of the removed package. If it's just gotten useless or uninteresting,
> no problem. But if there's some kind of successor (like foo2 in a new
> source package, iceweasel to firefox, or TeXL
Am Freitag, den 25.01.2008, 16:37 +0100 schrieb Lucas Nussbaum:
> On 25/01/08 at 15:59 +0100, Daniel Leidert wrote:
[docbok-xsl-doc-html]
> But if the size is the same, why would the Installed-Size differ? I have
> no idea. I've copied the source and the binary packages to
> gluck:~lucas/docbook-x
* Frank Küster <[EMAIL PROTECTED]> [2008-01-25 16:05]:
> I don't think these bugs should be closed without considering the
> type of the removed package. If it's just gotten useless or
> uninteresting, no problem. But if there's some kind of successor
> (like foo2 in a new source package, iceweasel
Hi
Dne Fri, 25 Jan 2008 16:37:36 +0100
Lucas Nussbaum <[EMAIL PROTECTED]> napsal(a):
> Seems like gzip didn't compress the files in the exact same way, even if
> the resulting size was the same:
> $ diff -burN t t2
> Binary files t/usr/share/doc/docbook-xsl-doc-html/changelog.Debian.gz
> and t2/u
On Fri, Jan 25, 2008 at 04:52:20PM +0530, Ritesh Raj Sarraf wrote:
> Package: xen-utils-3.2-1
> Version: 3.2.0-1
> Severity: important
Why do you CC debian-devel for a regular bug report? If every bug
report would be copied to debian-devel, the list would be totally
flooded.
cheers,
Michael
Martin Michlmayr cyrius.com> writes:
> In
> the past, I closed all bug reports from packages that were removed.
> Some people were unhappy about this but it was the best solution we
> had. This changed with the introduction of version tracking. The
> idea now is to close them with a fake versio
[Lucas Nussbaum]
> I'm not really sure of what we should do about those problems. The
> easiest way to fix them is to use source-only uploads (to avoid
> packages built on broken maintainer machines),
Very good work. I hope to find solutions for all my packages with
this problem.
I agree that s
Hmmm...
On Fri, Jan 25, 2008 at 10:51:41PM +0900, Osamu Aoki wrote:
> I ended up updating NM guide which only had dpatch to current one with
> quilt:
>
> http://www.debian.org/doc/manuals/maint-guide/ch-build.en.html#s-dpatch
As I read this thread back to d-project, ... interesting. It all star
Am Freitag, den 25.01.2008, 16:20 +0100 schrieb Jens Seidel:
> On Fri, Jan 25, 2008 at 03:59:01PM +0100, Daniel Leidert wrote:
[difference in Installed-Size for docbook-xsl-doc-html]
> > copies files from the source to the correct place in the file system. So
> > I checked the files: a) that I hav
Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> Of course, the list includes some false positives, but they are
> difficult to identify without going through all the debdiff outputs and
> build logs manually.
One false positive is when one of the builds fails, like ack-grep
which fails some times du
On 25/01/08 at 15:59 +0100, Daniel Leidert wrote:
> Am Freitag, den 25.01.2008, 15:25 +0100 schrieb Lucas Nussbaum:
>
> > I've done two rebuilds of sid on i386.
> > - one in a perfectly clean chroot, as I usually do
> > - one in a chroot, where as many build-dependancies as impossible were
> > i
On 25 Jan 15:59, Daniel Leidert wrote:
> Am Freitag, den 25.01.2008, 15:25 +0100 schrieb Lucas Nussbaum:
>
> > I've done two rebuilds of sid on i386.
> > - one in a perfectly clean chroot, as I usually do
> > - one in a chroot, where as many build-dependancies as impossible were
> > installed (t
On 25/01/08 at 15:36 +0100, Frank Lichtenheld wrote:
> On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote:
> > Of course, the list includes some false positives, but they are
> > difficult to identify without going through all the debdiff outputs and
> > build logs manually.
>
> Hmm, t
On Fri, Jan 25, 2008 at 09:59:00AM +0100, Pierre Habouzit wrote:
> Oh and don't try to ask for complete uniformity in packaging, there
> are 1000 DDs, 10 times as many packages
We have managed to get almost complete uniformity of the binary
packages produced. And imho, it's one of the things tha
On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote:
> Of course, the list includes some false positives, but they are
> difficult to identify without going through all the debdiff outputs and
> build logs manually.
Hmm, the debdiff output is not really helpful in deciding whether my
pa
On Fri, Jan 25, 2008 at 03:59:01PM +0100, Daniel Leidert wrote:
> Am Freitag, den 25.01.2008, 15:25 +0100 schrieb Lucas Nussbaum:
>
> > I've done two rebuilds of sid on i386.
> > - one in a perfectly clean chroot, as I usually do
> > - one in a chroot, where as many build-dependancies as impossibl
Am Freitag, den 25.01.2008, 15:25 +0100 schrieb Lucas Nussbaum:
> I've done two rebuilds of sid on i386.
> - one in a perfectly clean chroot, as I usually do
> - one in a chroot, where as many build-dependancies as impossible were
> installed (take the Sources file, extract the build-deps for al
On 25/01/2008, Vincent Danjean wrote:
> If someone has an example of how to use quilt + cdbs (or even quilt +
> standard debhelper debian/rules file) to patch the *clean* system of
> the software, I would be interested. Usually, patches are early
> removed (or not applied) when running "debian/rul
Package: wnpp
* Package name: libconfig-json-perl
Version: 1.1.2
Upstream Author: JT Smith <[EMAIL PROTECTED]>
* URL: http://search.cpan.org/dist/Config-JSON/
* License: GPL or Perl Artistic
Description:
Config::JSON parses configuration files written in JSON. It also does
some non-JSON stuf
Hi,
I've done two rebuilds of sid on i386.
- one in a perfectly clean chroot, as I usually do
- one in a chroot, where as many build-dependancies as impossible were
installed (take the Sources file, extract the build-deps for all
packages, and install as many packages as possible) (the chroot
Hi,
On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> On 25/01/08 at 08:01 +, Steve Langasek wrote:
> > As a second runner up, quilt is ok by me. :)
>
> I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
> use dpatch.
This was discussed in debian-doc a
gregor herrmann wrote:
> On Fri, 25 Jan 2008 12:20:59 +0100, Roland Mas wrote:
>
It would be great to document in some place
(devref?) why quilt should be used instead of dpatch, because I
don't think it's obvious for everybody :)
>>> Yes, please do so! I would like to read that.
>
On Fri, 25 Jan 2008 12:20:59 +0100, Roland Mas wrote:
> >> It would be great to document in some place
> >> (devref?) why quilt should be used instead of dpatch, because I
> >> don't think it's obvious for everybody :)
> > Yes, please do so! I would like to read that.
> Seconded. Also, please in
On Thu, Jan 24, 2008 at 09:07:07PM -0600, Raphael Geissert wrote:
> It's been some time since DEHS[1] had some 'big' changes (probably since its
> creation). Here's a list of changes that have been done lately:
Can you please add an entry about that to
http://wiki.debian.org/DeveloperNews, so that
[Petter Reinholdtsen]
> Today a new package to speed up the boot is available in unstable.
> The readahead binary package can speed up the boot quite significantly
> by optimizing how the hard drive is used. It make sure the kernel
> disk cache is populated as the very first thing done at boot wi
On Fri, Jan 25, 2008 at 12:14:01PM +0100, Andreas Tille wrote:
> Well, I do, but if I want to provide a fix for package XY I would have
> to install the perfered VCS of maintainer of XY and learn how to uncover
> the comments of a patch (including its history).
Nope, since nobody is stating that t
On 25/01/08 at 12:16 +0100, Andreas Tille wrote:
> On Fri, 25 Jan 2008, Lucas Nussbaum wrote:
>
>> I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
>> use dpatch. It would be great to document in some place (devref?) why
>> quilt should be used instead of dpatch, because I d
Package: xen-utils-3.2-1
Version: 3.2.0-1
Severity: important
X-Debbugs-Cc: [EMAIL PROTECTED]
Hi,
xen-utils fails to install. I'm sorry that I couldn't gather other information
that reportbug gathers.
virtian:~# apt-get install xen-hypervisor-3.2-1-i386 xen-utils-3.2-1
xen-docs-3.2
Reading p
Andreas Tille, 2008-01-25 12:16:02 +0100 :
> On Fri, 25 Jan 2008, Lucas Nussbaum wrote:
>
>> I made some stats (see [1]). 7.8% of our packages use quilt, while
>> 14.4% use dpatch. It would be great to document in some place
>> (devref?) why quilt should be used instead of dpatch, because I
>> don
On Fri, 25 Jan 2008, Lucas Nussbaum wrote:
I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
use dpatch. It would be great to document in some place (devref?) why
quilt should be used instead of dpatch, because I don't think it's
obvious for everybody :)
Yes, please do s
On Fri, 25 Jan 2008, Pierre Habouzit wrote:
a set of (documented!!) patches seems much more clearly for my taste.
You comment patches in the commit message, don't you ?
Well, I do, but if I want to provide a fix for package XY I would have
to install the perfered VCS of maintainer of XY and
On Fri, 25 Jan 2008, Pierre Habouzit wrote:
For one, I'm not sure the "situation" is that horrible. Second, I
believe joeyh's proposal to be able to use some DSCM features to replace
the old diff.gz is an excellent proposal, OTOH, you will have a lot of
people complaining about having to use gi
On Fri, Jan 25, 2008 at 11:14:24AM +0100, sean finney <[EMAIL PROTECTED]> wrote:
> On Friday 25 January 2008 11:08:13 am Mike Hommey wrote:
> > On Fri, Jan 25, 2008 at 09:55:02AM +, Jon Dowland
> <[EMAIL PROTECTED]> wrote:
> > > Does anyone know how common it is for this additional functionali
On 25/01/08 at 08:01 +, Steve Langasek wrote:
> As a second runner up, quilt is ok by me. :)
I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
use dpatch. It would be great to document in some place (devref?) why
quilt should be used instead of dpatch, because I don't t
hiya,
On Friday 25 January 2008 09:50:56 am Andreas Tille wrote:
> I would be absolutely unhappy about this. On one hand it is just a waste
> of resources to clone upstream source on the other hand handling a set of
> (documented!!) patches seems much more clearly for my taste.
"inconvenient bec
On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> On 25/01/08 at 08:01 +, Steve Langasek wrote:
> > As a second runner up, quilt is ok by me. :)
>
> I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
> use dpatch. It would be great to document in some pla
On Friday 25 January 2008 11:08:13 am Mike Hommey wrote:
> On Fri, Jan 25, 2008 at 09:55:02AM +, Jon Dowland
<[EMAIL PROTECTED]> wrote:
> > Does anyone know how common it is for this additional functionality to
> > be used in packages in the archive?
>
> I do use it for config.guess and config
On Fri, Jan 25, 2008 at 09:55:02AM +, Jon Dowland <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 25, 2008 at 10:13:37AM +0100, Mike Hommey wrote:
> > The only sad thing is that quilt only deals with patches (i.e. diffs),
> > whereas dpatch can do scripts, too. Anyways, I now prefer not using
> > dpat
On Thu, Jan 24, 2008 at 11:37:29AM -0600, Adam Majer wrote:
> Jon Dowland wrote:
> > On Mon, Jan 21, 2008 at 09:35:06PM -0500, David Nusinow wrote:
> >> Have you spoken with the rails package maintainer about this and your
> >> other ITP? Having duplicate copies of the same code lying around in
> >
On Fri, Jan 25, 2008 at 10:13:37AM +0100, Mike Hommey wrote:
> The only sad thing is that quilt only deals with patches (i.e. diffs),
> whereas dpatch can do scripts, too. Anyways, I now prefer not using
> dpatch of quilt.
Does anyone know how common it is for this additional functionality to
be u
On Thu, Jan 24, 2008 at 11:37:29AM -0600, Adam Majer wrote:
> Why? What is the disadvantage of having it together with rails? I'm
> assuming 7MB of diskspace (2MB archive) is not what is your main
> reason.
I'm interested in looking at active record in non-web situations. It's
only a mild interest
On Fri, Jan 25, 2008 at 09:59:00AM +0100, Pierre Habouzit wrote:
> For one, I'm not sure the "situation" is that horrible. Second, I
> believe joeyh's proposal to be able to use some DSCM features to replace
> the old diff.gz is an excellent proposal
Full ack!
> OTOH, you will have a lot of peo
On Fri, Jan 25, 2008 at 08:50:56AM +, Andreas Tille wrote:
> On Fri, 25 Jan 2008, Steve Langasek wrote:
>
> > - Store all of the source, upstream and Debian, in the same VCS
> > (better if upstream uses the same, but if it has to be a clone of
> > upstream then so be it)
>
> I would be ab
On Fri, Jan 25, 2008 at 10:08:29AM +0100, Josselin Mouette <[EMAIL PROTECTED]>
wrote:
> Le vendredi 25 janvier 2008 à 09:50 +0100, Andreas Tille a écrit :
> > > As a second runner up, quilt is ok by me. :)
> >
> > For historical reasons I use dpatch but I'm not really happy with this.
> > I would
Le vendredi 25 janvier 2008 à 09:50 +0100, Andreas Tille a écrit :
> > As a second runner up, quilt is ok by me. :)
>
> For historical reasons I use dpatch but I'm not really happy with this.
> I would gladly adopt any other patch system if it would be declared as
> kind of standard.
I’d be glad
On Fri, Jan 25, 2008 at 07:26:04AM +, Andreas Tille wrote:
> What would you suggest to enhance the situation?
For one, I'm not sure the "situation" is that horrible. Second, I
believe joeyh's proposal to be able to use some DSCM features to replace
the old diff.gz is an excellent proposal, O
On Fri, 25 Jan 2008, Steve Langasek wrote:
- Store all of the source, upstream and Debian, in the same VCS (better if
upstream uses the same, but if it has to be a clone of upstream then so be
it)
I would be absolutely unhappy about this. On one hand it is just a waste of
resources to clone
Andreas Tille <[EMAIL PROTECTED]> writes:
> IMHO there is a need for putting patches against upstream source
> into a defeult place.
Agreed. This place is provided by a VCS, especially one with good
merging algorithms. We are blessed with an ever-improving wealth of
such VCS software, with superl
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: scotch
Version: 5.0.1
Upstream Author: Francois PELLEGRINI
URL: http://www.labri.fr/perso/pelegrin/scotch/
License: CeCILL-C FREE S
On Fri, Jan 25, 2008 at 08:26:04AM +0100, Andreas Tille wrote:
> On Thu, 24 Jan 2008, Russ Allbery wrote:
>> I think:
>>http://kitenet.net/~joey/blog/entry/a_problem_with_tools/
>> is a big one that deserves attention. It's been a low-level grumble for
>> quite some time in various places,
83 matches
Mail list logo
