Re: What's the use for Standards-Versio n?
Manoj Srivastava wrote: > On Wed, Aug 12 2009, Neil Williams wrote: > >> On Wed, 12 Aug 2009 08:16:14 -0500 >> Manoj Srivastava wrote: >> * updated Standards-Version (no changes needed) > > Firstly, you do not ahve to put that into the changelog, and, > secondly, one should not have to update a packagejust to up the > standards version string. I just fix local git and wait for a real > reason to update the package. > I would add that updating the package just to bump the version is a really bad idea from the POV of the user, who gets to incur a bandwidth hit to d/l a new package that is identical to his/her existing one. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What's the use for Standards-Version?
Daniel Moerner wrote: > On 08/12/2009 03:01 PM, David Claughton wrote: >> Manoj Srivastava wrote: >>> On Wed, Aug 12 2009, Neil Williams wrote: >>> >>>> On Wed, 12 Aug 2009 08:16:14 -0500 >>>> Manoj Srivastava wrote: >>>> * updated Standards-Version (no changes needed) >>> Firstly, you do not ahve to put that into the changelog, and, >>> secondly, one should not have to update a packagejust to up the >>> standards version string. I just fix local git and wait for a real >>> reason to update the package. >>> >> >> I would add that updating the package just to bump the version is a >> really bad idea from the POV of the user, who gets to incur a bandwidth >> hit to d/l a new package that is identical to his/her existing one. >> >> > > I don't think that anyone was every seriously defending that people do > uploads just to bump the Standards-Version, I think the objection was > more that bumping the Standards-Version needlessly clutters the > changelog and wastes space. I'll admit I don't quite understand why, > though. It's up to the maintainer to be as verbose as he or she feels there. > > Daniel > Fair enough - I thought Neil was implying that this sometimes happened but on re-reading this wasn't quite what he said ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Martin Langhoff wrote: > On Thu, Nov 12, 2009 at 8:40 AM, Mike Hommey wrote: >> Stupid question: with this wording of the AGPL, who, in his right mind, >> will be licensing a DNS or POP server under this license ? (Except maybe >> someone who didn't read it) > > There are lots of people who pick a license without close reading. > Perhaps even a majority. > That might mean Debian cannot distribute that particular program since it is impossible to comply with the license. It doesn't IMHO mean that all AGPL software must be excluded. > But more importantly: good code in a webapp (where AGPL is "at home") > might find its way into a different network service. The example > earlier in the thread of a webapp growing an IMAP service is right. > > So this AGPL webapp has an IMAP service; such a good one indeed that I > might want to reuse some of its code for a pure IMAP server. You might want to, but AFAICT you would not be able to distribute the result if the user cannot be told how to get the source to the AGPL parts you included. That doesn't mean the original software isn't DFSG free, at least I don't see how it does. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
The Fungi wrote: > On Thu, Nov 12, 2009 at 09:28:59PM +0000, David Claughton wrote: > [...] >> You might want to, but AFAICT you would not be able to distribute >> the result if the user cannot be told how to get the source to the >> AGPL parts you included. That doesn't mean the original software >> isn't DFSG free, at least I don't see how it does. > > If you wanted to modify the original software in such a way that it > becomes interactive but via protocols which don't provide a means to > send arbitrary notes, this license would prevent you from being able > to legally do so. True, but that in itself doesn't make it non-DFSG-free, at least not by any reasonable interpretation (IMHO). DFSG 3 says the license must allow modifications and the modified version must be redistributable under the same license. That is not the same thing as saying you must be able to make *any* modification you like, including mods that breach the terms of license. It is always possible to modify free software in ways that effectively make it non-free - for example if you remove all the copyright statements from a BSD covered program. If you wanted to incorporate small pieces of it > (say, an included library) into a new project which employs > protocols which don't provide a means to send arbitrary notes, this > license would prevent that too. It stifles innovation in ways the > earlier GPL versions did not. Some licenses are more restrictive than others - doesn't necessarily make them non-free. > > I'm not a GPL apologist to begin with (as I already find it too > restrictive of end-user/distributor freedom for works I write), but > I have a hard time seeing how AGPL works can pass the dissident > test, at a minimum. The original GPL only requires you to distribute > source for applications which you are already distributing modified > binaries. The AGPL adds on a requirement to begin distributing > source for modified applications to which you allow connections over > the network in any way, even if you aren't distributing the software > itself. I don't think the dissident test is meant to be read quite as literally as you seem to be reading it! My interpretation is its OK if you have to give the source to users of the application as long as you don't have to give it to non-users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
The Fungi wrote: > On Thu, Nov 12, 2009 at 11:07:12PM +0000, David Claughton wrote: > [...] >> It is always possible to modify free software in ways that effectively >> make it non-free - for example if you remove all the copyright >> statements from a BSD covered program. > [...] > > This is untrue, at least for modern 3-clause BSD[*] and its > derivatives. I can remove the copyright statements from any > BSD-licensed software I like, as long as I don't *redistribute* it > in that form. By my reading, licenses like BSD or (classic) GPL > place no restrictions on use, even of modified versions. Distribution is what we're talking about here - if you can no longer redistribute it then it has become non-free. > The AGPL > goes a great deal further than this, by *requiring* you to become a > distributor of software you use, even if you only do something so > simple as make a minor modification to an AGPL-covered work > providing a network service. You are only required to distribute the source if you choose to run it on a publicly accessible server. If it's on your own machine or a private server and no-one outside your organisation can access it, then you don't have to worry about it. If you are only distributing the software conventionally then you only have to provide or offer the source in exactly the same way as required by GPL. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
David Claughton wrote: > The Fungi wrote: >> goes a great deal further than this, by *requiring* you to become a >> distributor of software you use, even if you only do something so >> simple as make a minor modification to an AGPL-covered work >> providing a network service. > > You are only required to distribute the source if you choose to run it > on a publicly accessible server. If it's on your own machine or a > private server and no-one outside your organisation can access it, then > you don't have to worry about it. > > If you are only distributing the software conventionally then you only > have to provide or offer the source in exactly the same way as required > by GPL. > OK, I've just re-read section 13 of the AGPL and I'm going to retract that last sentence. It is indeed not quite that simple. If you modify the program you also need to modify the offer to download the source so it gets your modified code instead of the original. One way to do this is to point it to your server, but it is not the only way. For example, another way you might be able to comply with this requirement is to always distribute the source along with the binaries and arrange for the source to be downloaded from the same server the binary is running from. Now this could certainly involve more extensive modifications than you might otherwise want to do, and you might well decide it's not worth the effort. However I'm still not entirely convinced it makes the license non-free. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Bernhard R. Link wrote: > * David Claughton [091113 21:42]: >> Now this could certainly involve more extensive modifications than you >> might otherwise want to do, and you might well decide it's not worth the >> effort. However I'm still not entirely convinced it makes the license >> non-free. > > If the license makes running a locally modified version not worth the > efford, that is a very strong indication it is not free at all. > Well, as long as it's not on a public server and you don't distribute your version you are free to do what you want with the code AFAICT. > My biggest problem is still that the licence forbits sloppy code. Not > every modification is suitable for everybody. For example never having > passwords in your code or other details about your infrastructure you do > not want published is a sign of good code. Being required to implement > some configuration file handling to keep your changes out of the source > so those details are not published basicly means not having the right to > do quick and dirty modifications[2]. I agree this makes the license problematic and might make developers choose to avoid working on AGPL code - however as I said above, all licenses put some limits on what you can modify, some more than others, at least if you want to distribute the result. > And without the right to do quick and > dirty modifications you cannot speak about a right to modify in my eyes > at all. No, I don't agree with this. Don't get me wrong, the requirement that you have to make potentially large time-consuming modifications to one part of the code in order to make a one-line change elsewhere doesn't entirely sit well with me either. I just don't think this is sufficient to make the license non-free. > > Let's take this to some extreme: What about software with a license that > forbids you running it unless you published your changes in a > peer-reviewed scientific journal? > I hope we all agree that at least that would be non-free. Yes, that would breach DFSG 5 and possibly 6 as not everyone would be able to do that. However the AGPL does not limit who can make modifications so this isn't a good analogy. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Bernhard R. Link wrote: > * David Claughton [091114 12:43]: >> I agree this makes the license problematic and might make developers >> choose to avoid working on AGPL code - however as I said above, all >> licenses put some limits on what you can modify, some more than others, >> at least if you want to distribute the result. > > The problem is that with AGPL you do not need distribution, all that is > needed is running. Once you are no longer allowed to modify what > programs on your computer do, how can that be free? > AIUI you are allowed to run the program on your computer, assuming that the service cannot be connected to from a remote location (or you are the only person that can do so). >> > Let's take this to some extreme: What about software with a license that >> > forbids you running it unless you published your changes in a >> > peer-reviewed scientific journal? >> > I hope we all agree that at least that would be non-free. >> >> Yes, that would breach DFSG 5 and possibly 6 as not everyone would be >> able to do that. However the AGPL does not limit who can make >> modifications so this isn't a good analogy. > > If you phrase it that way, I start to think it is an good analogy. > Remembering how often I was told in AGPL discussions that having to run > some file server is no cost, as of course there will be enough people > out there ready to host your make-it-work-quickly patched versions and > garantee it will never go offline (so you will not have to monitor it > and stop your servers once it does), finding a journal that will take > your paper sounds easy in comparison... > You don't necessarily have to put the source on your own server - particularly if you are only distributing the program and not running it as a service yourself. As I've suggested above, one solution is to distribute the source with the binaries and arrange for it to be downloadable from any server the binaries happen to be running on. Without a doubt this is a PITA, and might not be possible for some programs, but it doesn't mean that the license itself is non-free IMHO. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Bernhard R. Link wrote: > As I said: I do not see a difference between a license that does not > give me some right (or even tries to take away some rights copyright law > does not take away) and a license which theoretically grant it but puts > so many restrictions in it that one practically does not have it. I think we agree that the AGPL might be considered less free than the GPL. I'm still not convinced its entirely non-free. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Charles Plessy wrote: > [If I remember correctly, the question below is whether the law in the U.S.A. > requires us to reproduce all copyright statements from the source files when > we > redistribute binary programs, or if this is only needed when the license > expliciterly asks so.] > I believe there was also a related question concerning who might be held liable for copyright infringement in the case of something dodgy making it into the archive - would it be the FTP team because they exert editorial control over the archive, would it be SPI as the umbrella organisation, or would the axe fall on the individual maintainer? Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug Squashing Party -- May 17th - 20th
Martin Zobel-Helas wrote: where to find available RC bugs: http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&new=5 I'm just curious - the "ignore=sid" part means exclude bugs that only affect sid, correct? Which means bugs which affect lenny but are already fixed in sid are still included (I think). Is it useful to have bugs already fixed in sid included in the list for BSP purposes? I would have thought "bydist=both" would be more appropriate. Just my 2p. Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug Squashing Party -- May 17th - 20th
Luk Claes wrote: David Claughton wrote: Is it useful to have bugs already fixed in sid included in the list for BSP purposes? I would have thought "bydist=both" would be more appropriate. You might want to read the section Testing-only bugs at [0] on why lenny-only bugs might also be interesting to fix. Cheers Luk [0] http://people.debian.org/~vorlon/rc-bugsquashing.html I think I see - the bugs themselves don't need fixing, it's just a case of keeping an eye on the situation to ensure the updated package isn't being held up entering testing. Thanks for the clarification. Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
Sam Hocevar wrote: That's right, we don't know the licensing terms of binary files. But if we stop at the "it's not sufficient" argument, we'll never get anywhere, because it is impossible for a source package to determine the exact licensing terms of its binary packages. I'll leave that to another proposal. Sorry, I don't want to be a nuisance, but this has been puzzling me for a few days now - I can't figure out how the license of a binary package compiled from a source package could not be derived by combining the licenses of the relevant source files? Would someone mind giving an example, just to stop it bugging me? Regards, Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
François Févotte wrote: I'm not an expert at all, so I might be wrong. I guess this would be the case if your source package compiled a statically linked binary against a library belonging to another source package. The licence of the binary package would then be a combination of the licences of boths the source files and the library. True, you would need the debian/copyright files from all relevant source packages, but in itself that wouldn't be a huge problem. The only thing I've been able to come up with is the idea that in some cases all code with a particular license could end up being optimized away, so that license would not apply to the executable (I think). Is that what's being referred to? Dave.
Re: Bug#438885: Mass bug filling: must use invoke-rc.d
Amaya wrote: In most cases the fix should be simple, replace this: /etc/init.d/package with this: if which invoke-rc.d >/dev/null 2>&1; then invoke-rc.d package else /etc/init.d/package fi Hi, I don't want to be a pest (given I'm not a developer or maintainer), but I'm just curious - why the conditional? AIUI invoke-rc.d is in sysvinit - which is an Essential package. Won't the 'which' command always succeed? TIA, Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438885: Mass bug filling: must use invoke-rc.d
Felipe Sateler wrote: Juan Céspedes wrote: invoke-rc.d is present since version 2.80-1 of sysvinit; maybe someone could have a modern package with a very old sysvinit, and thus without invoke-rc.d But oldstable has 2.86.ds1-1. I thought that only direct upgrades were supported. I guess the conditional is indeed redundant. Thanks for the clarifications. I hadn't considered the situation of people having really old versions of packages installed. Probably something to file away under "Things to keep in mind" ;-) Regards, Dave.
New Graphviz version 2.26.3 in experimental: please test
Hi, Version 2.26.3 of Graphviz has been uploaded to experimental. This new version is a significant jump from the existing 2.20 versions in stable and testing. The main differences are : 1. libagraph is no longer available - all packages now need to use libcgraph instead. This should already be the case with the sole exception of python-pygraphviz. This needs to be upgraded to a newer upstream release (at least 0.99.1). I've filed a bug for this. 2. The old libgraphviz4 package which used to contain all the libraries has now been split into separate packages - libgraph4, libcgraph5, libcdt4, libpathplan4 and libgvc5. This is due to the soname changes for cgraph and gvc. Since the other libraries have not changed the new packages conflict against libgraphviz4, which means the two versions cannot co-exist. 3. Dot output formats -Tdia and -Tmif are no longer available, at least for now. These were removed upstream due to code reorganisation so it's possible they will reappear in a future release. I would really appreciate it if some people could test the new version, both the command line tools and packages that use either the libraries or invoke the commands. Please let me know how you get on, either here, by email or on #debian-devel where I can be found most evenings as eclecticdave. I'm hoping to get the new version into unstable in time for the freeze, so any feedback I can get will be most helpful. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
Hi Vincent, Vincent Bernat wrote: > Now, if upstream want to get patch Z, he can : > - get patch Z for version X.Y > - get patch between upstream (X+1).0 and master (X+1).0 containing >patch Z and other stuff > Well, in this example there wouldn't be any "other stuff" - you would do the conflict resolution and end up with modified patch Z' which can be extracted easily. > While git allows to keep track of modifications, it is difficult for > upstream (or some other people) to review a precise patch. In the more general sense however, I agree - you could have committed 20 revisions to the master branch while fixing 3 bugs and intermittently working on one experimental feature which isn't finished yet. There is no simple way of separating these looking at the master branch alone. IMHO you still need to have someway to separate the commits into patches or something equivalent. You could use topic branches. You could cherry pick commits from master and combine them into one-commit-per-bugfix onto a different branch. Or, of course, you could cherry pick commits and combine them into quilt patches ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On 22/07/10 09:44, Jesús M. Navarro wrote: > Hi, Manoj: > > On Thursday 22 July 2010 07:17:15 Manoj Srivastava wrote: >> On Wed, Jul 21 2010, Will wrote: >> > Also I imagine that it helps that they have some kind of commercial >> > support behind their projects, whereas Debian has little/none of that. >> >> One of the issues I have faced in trying to get Debian >> introduced in big companies is the percieved lack of a coherent >> copyright; and company lawyers being uncomfortable with the concept >> that most licesnse pass the dfsg, but we can't guarantee that, please >> go read several thoudand individual license docs to figure out what you >> are getting. > > That's again about perception. Debian has exactly the same copyright > coherence (or lack of it) than SUSE, Red Hat, Ubuntu or even proprietary > Unices. > It might be just my cynical viewpoint - but I've always suspected that part of the attraction of a commercial distro to a big company is the perception that there's always someone to sue if you feel you've been left open to liability. If your supplier has millions in the bank for potential settlements, maybe you're more comfortable accepting all those licenses without quite as much scrutiny? Cheers, David. -- 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/i2a15u$n5...@dough.gmane.org
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On 13/08/10 17:58, Russ Allbery wrote: > Raphael Hertzog writes: > >> As suggested by Ian on -devel (see attachment), it would be nice to have >> a way to remove files during unpack of a source package to hide non-free >> files from our users without stripping them from the original tarball. > >> I also prefer this approach over repacking upstream files so let's >> implement this feature. > > I'm pretty sure ftp-master isn't going to allow source packages with > non-free content in the main archive regardless of whether that content is > hidden on unpack (I certainly wouldn't if I were them), so implementing > this is kind of pointless for Debian. > Another use-case might be to remove "convenience copies" of system libraries. Might be useful (e.g. for security reasons) to be able to guarantee that this code isn't being accidentally used by a build (in a way that can be easily checked by a script). Cheers, David. -- 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/4c6735d3.2010...@eclecticdave.com
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On 18/08/10 09:29, Goswin von Brederlow wrote: > David Claughton writes: > >> On 13/08/10 17:58, Russ Allbery wrote: >>> Raphael Hertzog writes: >>> >>>> As suggested by Ian on -devel (see attachment), it would be nice to have >>>> a way to remove files during unpack of a source package to hide non-free >>>> files from our users without stripping them from the original tarball. >>> >>>> I also prefer this approach over repacking upstream files so let's >>>> implement this feature. >>> >>> I'm pretty sure ftp-master isn't going to allow source packages with >>> non-free content in the main archive regardless of whether that content is >>> hidden on unpack (I certainly wouldn't if I were them), so implementing >>> this is kind of pointless for Debian. >>> >> >> Another use-case might be to remove "convenience copies" of system >> libraries. Might be useful (e.g. for security reasons) to be able to >> guarantee that this code isn't being accidentally used by a build (in a >> way that can be easily checked by a script). >> >> Cheers, >> >> David. > > And I ask again: How does that differ from deleting them in > debian/rules? Sure you could do that. What that doesn't give you (which I think is useful) is a way to easily script a check that this code is not being used. For example, around the time I adopted graphviz, there was a MBF against 40+ packages asking people to check that these packages were not using the embedded copy of libltdl (#559812 was the graphviz one FWIW). It would have been significantly more efficient if there were a way to check this automatically. > > Legally that should be the same. And practically you would have the > useless files on the initial source unpack but they would be gone when > debian/rules is invoked the first time. dpkg-source -x could run the > clean target by default to make the files disapear directly. Well it wasn't my intention to address the original use case of non-free files. But to an extent the same argument applies - if FTP Masters were to allow this (and as Russ says, it's a big IF) - I would imagine they would want a way to ensure that you really were deleting the files, and I don't expect they would want to check debian/rules in every upload for appropriate 'rm' commands. Cheers, David. -- 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/i4hjm4$un...@dough.gmane.org
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
On 19/08/10 07:02, Goswin von Brederlow wrote: > David Claughton writes: >>> Legally that should be the same. And practically you would have the >>> useless files on the initial source unpack but they would be gone when >>> debian/rules is invoked the first time. dpkg-source -x could run the >>> clean target by default to make the files disapear directly. >> >> Well it wasn't my intention to address the original use case of non-free >> files. But to an extent the same argument applies - if FTP Masters were >> to allow this (and as Russ says, it's a big IF) - I would imagine they >> would want a way to ensure that you really were deleting the files, and >> I don't expect they would want to check debian/rules in every upload for >> appropriate 'rm' commands. >> >> Cheers, >> >> David. > > No. The files must be legal to be included. They are distributed in the > tarball after all. So deleting or not deleting makes absolutely no > difference to ftp-master. This only works for things we don't WANT to > use, not for things we CAN'T use. Convenience copies are a perfect > example for this. The deleting is there to make sure we don't > accidentally use them. Not to make the tarball legal. Only repackaging > will make a tarball with truely non-free stuff usable. Sorry, I was taking that as read ... to be clear I meant non-free but redistributable files. Cheers, David. -- 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/i4js7t$cp...@dough.gmane.org
Re: Xen - Source?
Michael Shuler wrote: > On 06/09/2009 11:49 AM, Andreas wrote: >> Installing it (make), it downloads the binary of the hypervisor! >> "Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg " # >> (downloading) > > This is an incorrect understanding of that download step - it is a > *source* download from the upstream mercurial repository: > Are you saying the source package does not actually contain the source code, but is just a framework for downloading the actual source? If so, this seems unusual to me. AIUI it's normal practice for a source package to contain a local copy of the source tree because Debian cannot make the assumption that xenbits.xensource.com will always be there. > > You can also download tarballs from the parent web site, if you wish. > So why are these not used in the creation of the source package? Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen - Source?
Michael Shuler wrote: > You're right. Ben pointed to the xen patch directory in the linux-2.6 > source package in his reply - the package build should not fetch the > repo. I just spoke up (probably incorrectly, without asking for more > info) to help with what I thought he was seeing. > OK, fair enough, glad that's cleared up. Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
On 07/06/11 14:16, Vincent Danjean wrote: > On 07/06/2011 14:36, Osamu Aoki wrote: >> On Tue, Jun 07, 2011 at 12:54:23PM +0200, Vincent Danjean wrote: >>> On 05/06/2011 07:39, Vincent Bernat wrote: On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote: > What I do is use upstream provided tarballs, then put aside > autotools-generated files, then autogenerate myself, and in the clean > rule put back the upstream-provided files (because I want not only > minimal required build routines idempotent but also building with > git-buildpackage). In the clean rules, you can just delete those autogenerated files. >>> >>> If you do not want git-buildpackage to complain (of >>> "not committed changes"), you need to restore them. >>> >>> I often use this in my rules: >>> clean: >>> [...] >>> # if this is a git repository, restore removed files that would have >>> # been ignored by dpkg-source >>> -test -d .git && git checkout -- $$(git status | \ >>> sed -e >>> '/^#[[:space:]]*deleted:[[:space:]]*/s/^#[[:space:]]*deleted:[[:space:]]*//p;d' >>> | \ >>> grep -v '^debian/') >> >> I thought "git reset --hard; git clean -f" is enough to get pristine >> state under git for manual operation. I am curious why this is done >> with this fancy script? Maybe this is something to do with >> git-buildpackage which I should know. > > I do not want to do a reset if some files are modified/added and not > commited (the standard behavior of git-buildpackage, ie complaining, is > ok for me in this case). > I only want that git-buildpackage ignores missing files as dpkg-source > does. It is also a quick a dirty script and I would be very pleased > to know a better way to do this. > > Regards, > Vincent > >> (I was thinking , as long as git reflect pristine source situation, this >> shorter type-able sequence restores source tree for me. If inside >> debian tree should not be recorded in git, we can add .gitignore with >> debian in it.) >> >> >> Osamu >> >> > > Two possibilities : You could use the --filter option to git-import-orig to prevent the files from being imported into git in the first place, I do this to filter out the upstream debian directory. If you're using pristine-tar the excluded files still get included as part of its delta so created tarballs will still be byte-for-byte identical to upstream. Alternatively you could just build in a different directory using the --export-dir option. Cheers, David. -- 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/isokcc$iak$1...@dough.gmane.org
