Re: Securely retrieving dscs from snapshot.debian.org

On Sat, Dec 30, 2017 at 6:57 PM, peter green wrote: > * what keys would be used to sign these re-signed release files? You > wouldn't want to use a regular Debian archive key because you wouldn't want > people to be able to use snapshots to attack Debian users. They would have to be separate

Re: Securely retrieving dscs from snapshot.debian.org

On 27/12/17 23:42, Paul Wise wrote: On Thu, Dec 28, 2017 at 5:41 AM, peter green wrote: Unfortunately there doesn't seem to be a good way to securely retrive a dsc from snapshot.debian.org given a package name and version number. At this time there isn't any good way to do that securely,

Re: Securely retrieving dscs from snapshot.debian.org

On Thu, Dec 28, 2017 at 5:41 AM, peter green wrote: > Unfortunately there doesn't seem to be a good way to securely retrive a dsc > from snapshot.debian.org given a package name and version number. At this time there isn't any good way to do that securely, until #763419 gets implemented.

Prendi uno Spin sull'ultimo Casinò Ora!

Visualizzazione immagine qui sotto All rights reserved © 2017 AlphaInfolab Pvt. Ltd. | Unsubscribe.       ___ vcs-pkg-discuss mailing list

autoforwardportergit call for testing.

I have been working the past few days to remove raspbian-specific assumptions from autoforwardportergit and adding some documentation. Autoforwardportergit is a tool for automating the process or merging downstream changes with new versions from Debian. At this point I would really appreciate

Re: extracting upstream source.

Package: dgit Version: 3.12 Peter Green writes ("extracting upstream source."): > As part of my dgit based autoforwardporter I want to add a script that will > de-fuzz patches with fuzz and remove patches that cannot be applied. > > To do this I need the "upstream" source tree. However the

Re: extracting upstream source.

On Tue, Jul 25, 2017 at 03:55:08PM +0100, Ian Jackson wrote: > Ian Jackson writes ("Re: extracting upstream source."): > > dgit often has "something like" the upstream source tree as a git tree > > object. dgit should provide a way for you to get at it. > > This is now #869675. For our Ubuntu

Re: extracting upstream source.

Ian Jackson writes ("Re: extracting upstream source."): > dgit often has "something like" the upstream source tree as a git tree > object. dgit should provide a way for you to get at it. This is now #869675. Ian. -- Ian Jackson These opinions are my own.

extracting upstream source.

As part of my dgit based autoforwardporter I want to add a script that will de-fuzz patches with fuzz and remove patches that cannot be applied. To do this I need the "upstream" source tree. However the process of extracting the upstream source is quite fiddly, there may be multiple tarballs

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

On Tue, Jun 13, 2017 at 03:18:27PM +0100, Ian Jackson wrote: > Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git > directories in source package uploads?]"): > > I disagree here. We don't need to "hope". I don't expect the build to > > see the importer's git history. It

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

On Tue, Jun 13, 2017 at 03:04:46PM +0100, Robie Basak wrote: > 1. The imported git trees are defined to escape /^\.git.*/ by > prepending a '.'. It just occurred to me that this would also escape '.gitignore' to '..gitignore', which personally I'd like, but others might find surprising. So

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"): > I disagree here. We don't need to "hope". I don't expect the build to > see the importer's git history. It should be invisible to the build > process, and I intend to make our

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

On Mon, Jun 12, 2017 at 05:46:14PM +0100, Ian Jackson wrote: > Again, I don't follow why `fail' occurs. You seem to be suggesting > that importing a .dsc containing a .git would generate ..git. Correct. I'm suggesting "fail" for the round-tripping - for "git ubuntu build-source" to "unescape"

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"): > I don't really follow what you're saying. Are you saying that wrapping > these types of things in general is bad, or that having a wrapper for > the specific case of unescaping

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

On Mon, Jun 12, 2017 at 04:57:06PM +0100, Ian Jackson wrote: > `dgit clone' disables these .gitattributes; provides a separate verb > for disabling them in other trees; and `dgit fetch' warns about them > if it finds them. So...you have a wrapper? I don't really follow what you're saying. Are

Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

Robie Basak writes (""git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"): > Some examples: > > Upstreams that ship .gitignore confuses distribution developers (IMHO) > who want to see *everything* that has changed. I'd like to work with git > upstream in

"git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

On Mon, Jun 12, 2017 at 04:31:48PM +0100, Ian Jackson wrote: > Robie Basak writes ("Re: What to do with .git directories in source package > uploads?"): > > In mitigation, we have "build" and "build-source" wrappers that could > > always do the correct unescaping here. Then you'd only fall into

Re: What to do with .git directories in source package uploads?

On Wed, May 24, 2017 at 10:56:52PM +0100, Ian Jackson wrote: > But if there are packages where the .git directory is somehow actually > used in the build, your scheme won't help because a build from the > imported git tree will use your history, not the history found in the > .dsc's .git. I don't

Re: What to do with .git directories in source package uploads?

Nish Aravamudan writes ("What to do with .git directories in source package uploads?"): > I noticed today that our Ubuntu git importer failed to import > src:nplan (which is only in Ubuntu). This is because the upload > (incorrectly) includes a .git directory. I see that dgit's behavior > for the

What to do with .git directories in source package uploads?

Ian, I noticed today that our Ubuntu git importer failed to import src:nplan (which is only in Ubuntu). This is because the upload (incorrectly) includes a .git directory. I see that dgit's behavior for the same DSC file with `dgit import-dsc` is to delete the .git directory from the source

Su respuesta urgente es necesaria / your urgent response is needed

Fondos donados a usted. Tu nombre es uno de los 5 afortunados personas contacto [ gloriacmackenzi...@gmail.com ] para más detalles Funds donated to you. your name is among the 5 lucky people contact [ gloriacmackenzi...@gmail.com ] for details --- This

!!!! Greetings !!!!

Hello, I am Barr Kong Khemara, I humbly ask if you are related to my client who died couple of years ago in a car accident here in my country Cambodia. I wish to also inquire if it is possible to have different families with the same last name as yours by coincidence who do not share the same

on quilt, dpkg, dgit and symlinks.

I recently discovered some unusual behaviour in a source package I was working on. I was using some scripts I put together myself to generate patch series for a debian package. dgit claimed I was creating a new symlink and that creation of a new symlink could not be represented by 3.0

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

On 09/03/17 16:05, s...@vilain.net wrote: git-lfs is your friend. And supported natively by GitHub. Thanks but it seems like a highly undesirable soloution to me. Firstly it seems to require mangling your git repo. That is going to make it at best a PITA to use with things like dgit.

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

On Mar 9, 2017 09:08, "peter green" wrote: On 09/03/17 16:05, s...@vilain.net wrote: git-lfs is your friend. And supported natively by GitHub. Thanks but it seems like a highly undesirable soloution to me. Firstly it seems to require mangling your git repo. That is going

Re: PSA: github file size limit means that some debian package imports can't be pushed to github.

git-lfs is your friend. And supported natively by GitHub. On March 9, 2017 7:42:20 AM PST, peter green wrote: >I have recently started pushing source for packages where we carry >modifications for in raspbian to github. The packages are imported into >git using dgit. >

PSA: github file size limit means that some debian package imports can't be pushed to github.

I have recently started pushing source for packages where we carry modifications for in raspbian to github. The packages are imported into git using dgit. However I have discovered that this is not possible for all packages. In particular github rejects files over 100 megabytes and the

!! GREETINGS !!!

Hello I am Mr. Hassan Karam, from Syria due to brutal civil war in my country, I am seeking your partnership in going into a private investment venture. I am interested in investing in your country, so I will like us to begin our acquaintance through this medium so we can deliberate more.I

Re: git based autoforwardporter.

On 19/01/17 19:36, Ian Jackson wrote: I think such a tool would be very useful in general, if it could be used for individual users. I see no reason why it couldn't be used by an individual user. I have posted the current code at . https://github.com/plugwash/dscdirtogit (import tool)

Re: git based autoforwardporter.

peter green writes ("git based autoforwardporter."): > I can't imagine raspbian is the only project who would find such a > tool useful. OTOH it would be a fair bit of work to clean up the > tool to seperate local raspbian assumptions from more generally > applicable functionality. > > Are there

Re: git based autoforwardporter.

Hi Peter, On Thu, Jan 19, 2017 at 02:16:27AM +, peter green wrote: > Some time ago I put together what I call the "autoforwardporter". The > aim of this is to take downstream changes and apply them on top of new > debian uploads. Can you expand on this? We do exactly this in Ubuntu as

re: patches-applied historical imports (usd import)

I haven't run dgit's dsc importer on a whole historical archive but Peter Green of Raspian has been running it and filing bugs. I haven't seen such a bug recently so I hope it has been working for all the packages he's seen. I haven't really been doing large scale importing, I have just

git based autoforwardporter.

First let me introduce myself, I am Peter Michael Green, cofounder of the Raspbian project. I have quite a bit of experiance with Debian Some time ago I put together what I call the "autoforwardporter". The aim of this is to take downstream changes and apply them on top of new debian uploads.

Re: patches-applied historical imports (usd import)

Nish Aravamudan writes ("patches-applied historical imports (usd import)"): > 1) Some source packages (bouncycastle, php7.0 are the ones I can think > of off the top of my head) upstream tarballs contain .gitattributes I investigted this. After looking at the docs and playing about, I concluded

SPENDE GRANT

Sir/Madam, Hiermit mchten wir Sie informieren, dass WESTERN UNION Internationale Spendenprojekt hat Ihnen eine Barzuwendung von ausgezeichnet [50,000 EURO], als Charity-Spende von Western union International, Grobritannien, frderte in Verbindung mit Kinderfonds der Vereinten Nationen

Re: patches-applied historical imports (usd import)

Ian Jackson writes ("Re: patches-applied historical imports (usd import)"): > I suggest you read "Intent to commit craziness - source package > unpacking" et seq, which were on this list in September. Here's the > archive: > > >

Re: patches-applied historical imports (usd import)

Ian Jackson writes ("Re: patches-applied historical imports (usd import)"): > Urk! I have just filed: ... > https://bugs.debian.org/850845 > dpkg-source fails to extract samba_3.6.5-2.dsc but exits status 0 - > https://bugs.debian.org/850845 This was actually in dget, not dpkg-source.

Re: patches-applied historical imports (usd import)

On 09.01.2017 [14:33:29 -0800], Nish Aravamudan wrote: > On 09.01.2017 [13:40:16 +], Ian Jackson wrote: > > Nish Aravamudan writes ("patches-applied historical imports (usd import)"): > > > ii) some patches may fail to apply with a trivial `quilt push`. This > > > occurs with, at least, a

Re: patches-applied historical imports (usd import)

On 09.01.2017 [13:40:16 +], Ian Jackson wrote: > Nish Aravamudan writes ("patches-applied historical imports (usd import)"): > > 1) Some source packages (bouncycastle, php7.0 are the ones I can think > > of off the top of my head) upstream tarballs contain .gitattributes > > files, which will

Re: patches-applied historical imports (usd import)

Hi Sean, On 08.01.2017 [21:34:50 -0700], Sean Whitton wrote: > Hello Nish, > > On Fri, Jan 06, 2017 at 02:26:29PM -0800, Nish Aravamudan wrote: > > 2) How do we determine if a source package is 1.0 vs. 3.0? I am > > currently using `dpkg-source --print-format`, but have found one source > >

Re: patches-applied historical imports (usd import)

On Mon, Jan 09, 2017 at 05:17:08PM +, Ian Jackson wrote: > Robie Basak writes ("Re: patches-applied historical imports (usd import)"): > > Right now, we're accepting rich history only for Ubuntu-specific > > commits. I don't think we have really considered yet what would be best > > for

Re: patches-applied historical imports (usd import)

On Mon, Jan 09, 2017 at 02:02:34PM +, Ian Jackson wrote: > Robie Basak writes ("Re: patches-applied historical imports (usd import)"): > > On Mon, Jan 09, 2017 at 01:45:52PM +, Ian Jackson wrote: > > > Ideally you and I could agree on a commit structure for the imported > > > packages, and

Re: patches-applied historical imports (usd import)

Nish Aravamudan writes ("patches-applied historical imports (usd import)"): > [stuff] It occurs to me that it would be a good idea for you to check that your importer produces identical answers to dgit. If nothing else, from your point of view dgit can help you test that your importer DTRT. At

Re: patches-applied historical imports (usd import)

Nish Aravamudan writes ("patches-applied historical imports (usd import)"): > 1) Some source packages (bouncycastle, php7.0 are the ones I can think > of off the top of my head) upstream tarballs contain .gitattributes > files, which will change the behavior of git itself when checking out a >

Re: patches-applied historical imports (usd import)

Hello Nish, On Fri, Jan 06, 2017 at 02:26:29PM -0800, Nish Aravamudan wrote: > 2) How do we determine if a source package is 1.0 vs. 3.0? I am > currently using `dpkg-source --print-format`, but have found one source > package (util-linux 2.13~rc3-5), where dpkg-source emits: I would just

patches-applied historical imports (usd import)

Hi Ian, I've got a few questions/comments about git-based publishing imports and history for patches-applied imports that I was hoping to bounce off you and other VCS folks. I apologize for the very long e-mail to follow! For context for everyone: I (along with Robie Basak and others) have been

Re: Idea: sbuild/pbuilder "--dgit" option

* Ian Jackson [161231 01:57]: > What I was suggesting was that users should, as an alternative, be > able to do the build themselves rather than via dgit, and still get > the .gitignore included. To highlight a point that I think is quite important here: adding

schroot default chroot path (was: Re: Intent to commit craziness - source package unpacking)

Hi, Quoting Ian Jackson (2016-11-30 12:11:22) > ~Johannes Schauer writes ("Re: Intent to commit craziness - source package > unpacking"): > > sbuild supports multiple backends. The default backend is schroot. How to > > get > > from "apt-get install sbuild" to actually building packages depends

Re: Intent to commit craziness - source package unpacking

~Johannes Schauer writes ("Re: Intent to commit craziness - source package unpacking"): > sbuild supports multiple backends. The default backend is schroot. How to get > from "apt-get install sbuild" to actually building packages depends on the > backend used. For the default schroot backend,

Re: Intent to commit craziness - source package unpacking

Hi, Quoting Ian Jackson (2016-10-04 18:55:14) > Russ Allbery writes ("Re: Intent to commit craziness - source package > unpacking"): > > If sbuild is now at the point where you can just apt-get install sbuild, > > run a single setup command, and be ready to build packages (which is where > >

Re: git workflows for general Ubuntu development

Dear Robie, On Tue, Nov 15, 2016 at 05:41:56PM +, Robie Basak wrote: > On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote: > > The most important part of the tutorial for realising this is putting > > "single-debian-patch" and "auto-commit" in debian/source/options, but I > > would

Re: git workflows for general Ubuntu development

Hi Sean, Since our UOS session will start very soon, I'll reply just to the things that I think I can address immediately for now. On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote: > The most important part of the tutorial for realising this is putting > "single-debian-patch" and

Re: git workflows for general Ubuntu development

Dear Robie, Thank you for your detailed explanation of your project. I'd like to make just a few remarks in response to your criticisms of dgit. Firstly, *everything* that you discuss under "Differences from Debian" was in fact a target when dgit was designed. I'm not going to respond

Re: DEP14 policy for two dots

FTR, I answered most questions about "why not dgit?" in the thread I just moved to vcs-pkg-discuss only[1]. For some specific questions here: On Thu, Nov 10, 2016 at 12:31:31AM +, Ian Jackson wrote: > dgit can work on Ubuntu too, in a readonly mode. (It would be nice to > make `dgit push'

Re: git workflows for general Ubuntu development

Cutting out the debian-devel and ubuntu-devel-discuss lists. I think this subthread has quite a risk of fragmenting, so I'm moving it to the one list (vcs-pkg-discuss) that seems most appropriate for this thread. I have seen a few comments about "why not dgit?" and I realise that I have yet to

WESTERN UNION SPENDE

Sir/Madam, Hiermit möchten wir Sie informieren, dass WESTERN UNION Internationale Spendenprojekt hat Ihnen eine Barzuwendung von ausgezeichnet [200,000EURO], als Charity-Spende von Western union International,Großbritannien, förderte in Verbindung mit Kinderfonds der Vereinten Nationen

Re: DEP14 policy for two dots

On Wed, 09 Nov 2016, Ian Jackson wrote: > Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like > > a reasonable extension. > > Attached. FYI I intend to implement this in dgit. Thanks, committed to the dep svn

Re: DEP14 policy for two dots

I forgot one: Ian Jackson writes ("Re: DEP14 policy for two dots"): > A patches-unapplied tree: > > * produces confusing and sometimes misleading output from >git grep, or (even if appropriate history is available) >with git blame; > > * cannot be used with `git cherry pick '; > > *

Re: DEP14 policy for two dots

On 09.11.2016 [21:27:14 +], Ian Jackson wrote: > Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like > > a reasonable extension. > > Attached. FYI I intend to implement this in dgit. Thank you! We will

Re: DEP14 policy for two dots

Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like > a reasonable extension. Attached. FYI I intend to implement this in dgit. Thanks, Ian. >From 5c63400e9be8cb1532515764a1179730aed550fb Mon Sep 17 00:00:00

Re: DEP14 policy for two dots

On Tue, 08 Nov 2016, Ian Jackson wrote: > > The reverse rule is to convert _ and % and delete all #. > > Quoted for completeness. Ok, can you prepare a patch for DEP-14 then? I'll apply it as it looks like a reasonable extension. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian

Re: DEP14 policy for two dots

Ian Jackson writes ("Re: DEP14 policy for two dots"): > Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > > On Fri, 04 Nov 2016, Ian Jackson wrote: > > > My proposal is reversible. It does not need to be extensible. > > > > So what about "..."? Would it give ".#.#."? > > Yes. I said

Re: DEP14 policy for two dots

Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > On Fri, 04 Nov 2016, Ian Jackson wrote: > > My proposal is reversible. It does not need to be extensible. > > So what about "..."? Would it give ".#.#."? Yes. I said (fixing my bug): > Insert "#": >- between each pair of

Re: DEP14 policy for two dots

On Fri, 04 Nov 2016, Ian Jackson wrote: > Raphael Hertzog writes ("Re: DEP14 policy for two dots"): > > We have defined simple "readable" mappings for the common cases that > > we encounter frequently. Now if we need mappings for silly things > > that we don't encounter, I would suggest to use

Re: DEP14 policy for two dots

Nish Aravamudan writes ("DEP14 policy for two dots"): > [ Raphael, apologies for sending twice, had a error in the headers in > the prior one ] > > Not sure exactly where to ask this better than debian-devel, but I am > working on an importer for the Ubuntu Server team which parses published >

Re: Intent to commit craziness - source package unpacking

Russ Allbery writes ("Re: Intent to commit craziness - source package unpacking"): > Ian Jackson writes: > > I'm not sure of the logic behind that. I don't think dgit helps much > > with the kind of tasks that pristine-tar helps with. > > The main benefit of

Re: Intent to commit craziness - source package unpacking

Guido Günther writes ("Re: Intent to commit craziness - source package unpacking"): > On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote: > [..snip..] > > Recommends: pristine-tar (>= 0.5) ...> > > > pristine-tar has been declared unmaintainable by its original > > author and

Re: Intent to commit craziness - source package unpacking

Hi Ian, On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote: [..snip..] > Because I'm a pernickety type of person I reviewed the dependencies of > git-buildpackage. I have some qualms about the following > dependencies: > > Recommends: pristine-tar (>= 0.5) > > pristine-tar has

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Guido Günther writes ("Re: Intent to commit craziness - source package > unpacking"): > > 'gbp pq import' does have 'debian/patches' since it just puts the > > patches that are in debian/patches on top of the

Re: Intent to commit craziness - source package unpacking

Guido Günther writes ("Re: Intent to commit craziness - source package unpacking"): > The authorship and subject information is taken from the patch if > available or made up from the filename and committer when not. > > If patches in the series file are in subdirs of debian/patches we store >

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Guido Günther writes ("Re: Intent to commit craziness - source package > unpacking"): > > Hi Ian, > > Hi, thanks for your attention. Please disregard this email. I hadn't finished editing it! Ian.

Re: Intent to commit craziness - source package unpacking

Hi Ian, On Wed, Sep 28, 2016 at 11:09:03AM +0100, Ian Jackson wrote: > Ian Jackson writes ("Re: Intent to commit craziness - source package > unpacking"): > > Thanks for your comments. I feel unblocked :-). > > So, I now intend to go and implement my plan. > > There will be a little while

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Thanks for your comments. I feel unblocked :-). So, I now intend to go and implement my plan. There will be a little while (perhaps a few weeks) before I am in a postion to release this in dgit 2.0. But after

Intent to commit craziness - source package unpacking

tl;dr: * dpkg developers, please tell me whether I am making assumptions that are likely to become false. Particularly, on the behaviour of successive runs of dpkg-source --before-build with successively longer series files. * git-buildpackage and git-dpm developers, please point me

Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]

Ian Jackson writes ("Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]"): > Colin Watson suggested (in pers.comm) >pkg/debian/ > This is better but it still has a problem with collate order. > > It may seem a petty thing to worry about, but for the reasons I > explain

git, debian/ tags, dgit - namespace proposal

Currently, the debian/ git tag namespace is used by a number of different tools, and can mean different things in different packages and sometimes even different things for the same package in different repos or trees. dgit produces, and the dgit git server requires, tags of this form, which

Re: git-buildpackage / dgit integration

Guido Günther writes (Re: git-buildpackage / dgit integration): On Sun, Aug 16, 2015 at 03:46:46PM +0100, Ian Jackson wrote: * .gitignore: We agree that the source package should contain .gitignore if the git tree does. (dgit requires this.) If the way that gbp does builds

Re: My use case of git-buildpackage

On Thu, 03 Nov 2011, Daniel Dehennin wrote: First, I'm not a Debian maintainer, I mostly do some package for my personal use, to follow SVN trunk or git HEAD of some softwares. that is the idea behind Debian -- personal use could benefit others alike -- why not to share those packages with the

Re: My use case of git-buildpackage

Hello, As I'm really interested in automatic building, here[1] is an updated section of my previous document. If any one has feedback on it, specially on the way to manage a Debian repository. Regards. Footnotes: [1] git clone git://git.baby-gnu.net/packaging-with-dvcs.git -- Daniel

My use case of git-buildpackage

Hello, First, I'm not a Debian maintainer, I mostly do some package for my personal use, to follow SVN trunk or git HEAD of some softwares. As I use Debian, I do not want to make install things ;-). I attach[1] a rough document about my actual uses of git for debian packaging and post it here

Re: Patch mgmt workflow proposal

also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0223 +0200]: This comes about ¾ of the way to the history pollution done by TopGit. I consider it very useful information, when needed. It's only pollution if you let it be so. That is a very wise statement, and I agree.

Re: Patch mgmt workflow proposal

also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0229 +0200]: 1. you develop your features on branches, but you do not push the branch heads; Right. The feature branches stay only with the people who are interested; usually the people actually working on each

Re: Patch mgmt workflow proposal

Thomas Koch: I had some time on my way back to think about patch bases. Is it right, that it isn't actually necessary to save the commit sha-1s of patch bases? It is my understanding that you could calculate them: 1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES) 2. for each

Re: Patch mgmt workflow proposal

also sprach Thomas Koch tho...@koch.ro [2011.08.02.1732 +0200]: the above algorithm is completly wrong, written in a hurry. The idea however was to merge all dependencies in a commit and to merge this commit in the patch branch. This is exactly what TopGit does: a top-base is the merge of a

Re: Patch mgmt workflow proposal

also sprach Thomas Koch tho...@koch.ro [2011.07.30.1229 +0200]: Martin F. Krafft (madduck) was so kind to remind me posting this here. We're right now at debconf discussing different patch mgmt workflows. Thanks to contributions from Joachim Breitner and Guido Günther I've written down an

Re: Patch mgmt workflow proposal

CC: debian-devel. Please subscribe to vcs-pkg-discuss@lists.alioth.debian.org to follow this topic! martin f krafft: also sprach Thomas Koch tho...@koch.ro [2011.07.30.1229 +0200]: Martin F. Krafft (madduck) was so kind to remind me posting this here. We're right now at debconf discussing

Branch dependencies with Git hooks

Dear list, I had this idea today while sitting with Guido and studying TopGit. I have no investigated any of this, but since DebConf is coming to an end and I won't have much time in the weeks to come, I wanted to make sure to capture the idea. TopGit manages dependencies between branches. If B

[FW: [ANNOUNCE] Project pb version 0.11.3 is now available]]

Hello, I'd encourage people interested in following the project to subscribe to the announce ML at least in order to receive more regular info. http://mondorescue.org/sympa/wwsympa-wrapper.fcgi/subscribe/pb-announce Full Announce is at: http://www.project-builder.org/news.shtml Best regards,

Re: Shared pidgin releases and vcs-pkg

On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote: On Sun, 2009-05-24 at 14:13 +0300, Felipe Contreras wrote: Optionally, each package maintainer can push their patches to this repository so that other people can easily fetch them, and perhaps even share patches between

Re: Shared pidgin releases and vcs-pkg

On Mon, 2009-05-25 at 01:14 +0300, Felipe Contreras wrote: On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote: 5) Do we really want to encourage direct sharing of patches between distros? Wouldn't we want to get them upstream ASAP if they're useful and cut a new

Re: Shared pidgin releases and vcs-pkg

On 05/24/2009 06:14 PM, Felipe Contreras wrote: Another advantage is that similar distros (ubuntu-debian, fedora-opensuse) can share most of the packaging stuff (.spec, debian/*). Fedora and Opensuse's specs are very different, so this is not an advantage. Warren Togami wtog...@redhat.com

Re: Shared pidgin releases and vcs-pkg

Le dimanche 24 mai 2009, à 18:27 -0400, Olivier Crête a écrit : On Mon, 2009-05-25 at 01:14 +0300, Felipe Contreras wrote: On Mon, May 25, 2009 at 12:35 AM, Richard Laager rlaa...@wiktel.com wrote: 5) Do we really want to encourage direct sharing of patches between distros? Wouldn't we

Fwd: [pb-announce] Project pb version 0.11.1 is now available

Hello, FTI, project-builder.org is tool to support the Continuous Packaging approach that we are working on jointly beyween HP and Intel. Best regards, Bruno. - Forwarded message from Bruno Cornec br...@project-builder.org - From: Bruno Cornec br...@project-builder.org Date: Wed, 9 Mar

[no subject]

Richiesta di autorizzazione all'invio dell'email L'Altra Dimensione esegue lavori di Ristrutturazione, imbiancature, controsoffittature, decorazione, coibentazioni termoacustici, trattamenti antimuffa, rifacimento tetti, canne fumarie ecc... Fornitura e posa di parquet, porte, finestre,

git-flow

Dear folks, in case you missed this, it's worth a look (although I have not yet checked out the actual tool): http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer

Fwd: [ANNOUNCE] Project pb version 0.10.1 is now available]

- Forwarded message from Bruno Cornec br...@project-builder.org - Project pb version 0.10.1 is now available The project team is happy to announce the availability of a newest version of pb 0.10.1. Enjoy it as usual! A lot has been done in that version, so look at the ChangeLogs file

Blessing 2 1 o217351 nhldwf0 oh3133

Hey, friend: if you are interested in our product (as Laptop,Television, Phone, Camera ,PSP, Car DVD and so on .). all items are Original and best price. If you have any questions, please feel free to contact us. (www: youtoi . com E-mail: youtoi @ 188 . com) ⊙ yzocpn3257

oferta cursuri de perfectionare

Title: oferta cursuri de perfectionare EVRIKA GROUP - cursuri de perfectionare : -contabilitate - costul cursului este de 300 ron, cu incepere dingrupa in formare; -expert fiscal - costul cursului este de 600 ron, cu incepere din25august2010; -inspector protectia muncii - nivel baza

(Dear God's elect,)

(Dear God's elect,) I am touched by God to hand you over this money considering my last wish, and you should also know that my contact to you is by special grace of God, please understand that you are not helping me rather you are working for God the creator of heaven and earth. In

CAN YOU SUPPLY THE PRODUCT TO US.

CAN YOU SUPPLY THE PRODUCT TO US. Dear Sir, I hope this mail meet you in good health. There is this product I suggest you may be able to supply to our company.  The name of the product is Diamond Misers use in Diamond Companies. I use to supply it to my company directly from Dubai UAE. I use to

  1   2   3   4   >