Re: Introducing dgit - git integration with the Debian archive
Hello Ian, thanks for your work on dgit. It looks very promising! I'm sorry to have missed that impromptu BOF at debconf, I would have definitely arranged myself to be there if I had known its existence. On Thu, 22 Aug 2013, Ian Jackson wrote: > With regret I must note that currently you can't use it if you don't > have a full DD account on both the Debian systems and on Alioth. Even > if you just want a read-only mode. This is due to deficiencies in the > archive software and in Alioth, which I have worked around in very > unpleasant ways. I'm hoping that this will improve fairly soon. > Please see the BUGS section of the manpage. “For `3.0 (quilt)' packages, dgit has to do more work to work around some braindamage in way dpkg-source handles changes made to this format. See also the BUGS section. We recommend against the use of `3.0 (quilt)'.” “`3.0 (quilt)' packages have an additional difficulty: if these are edited in the most normal way, and then fed to dpkg-buildpackage, dpkg-source will add extra quilt patch metadata to the source tree during the source package build. This extra metadata is then of course not included in the git history. So dgit push needs to commit it for you, to make sure that the git history and archive contents are identical. That this is necessary is a bug in the `3.0 (quilt)' format.” I don't think that "3.0 (quilt)" does things without justification so calling those features "braindamage" is not really nice. Clearly the quilt format duplicates some of the VCS features (with its .pc directory) and this is probably what you are referring to in the above paragraph. That said I have always thought of the "3.0 (quilt)" source package as something that we should be able to generate ouf of a VCS tree, not something to be directly stored in a VCS repository. In any case, I'm open to suggestions to improve the format to better suit your needs... so can you can explain me more precisely what's causing you issues? Either here or better in a bug report against dpkg-dev. I would really like to find a good workflow that suits "3.0 (quilt)". Badly supporting half the archive looks like a problem. BTW, instead of advising against "3.0 (quilt)" you should rather recommend the usage of the --single-debian-patch option when using that format... this will make it mostly work like "1.0". I have read the manual page but there some things that I don't really understand on the design yet. So let me ask some questions: - is there some server side part (running on alioth)? what does it take care of? - what/who creates the initial repository? and what/who keeps it in sync with the (non-dgit-based) archive uploads? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130823074507.gb8...@x230-buxy.home.ouaza.com
Bug#720536: ITP: libmango-perl -- Pure-Perl non-blocking I/O MongoDB client
Package: wnpp Severity: wishlist Owner: CSILLAG Tamas * Package name: libmango-perl Version : 0.12 Upstream Author : Sebastian Riedel * URL : https://metacpan.org/release/Mango * License : Artistic-2.0 Programming Lang: Perl Description : Pure-Perl non-blocking I/O MongoDB client Description: Mango is a pure-Perl non-blocking I/O MongoDB client, optimized for use with the Mojolicious real-time web framework, and with multiple event loop support. . To learn more about MongoDB you should take a look at the official documentation|http://docs.mongodb.org. . Note that this whole distribution is EXPERIMENTAL and will change without warning! . Many features are still incomplete or missing, so you should wait for a stable 1.0 release before using any of the modules in this distribution in a production environment. Unsafe operations are not supported, so far this is considered a feature. -- 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/20130823075549.7852.98106.report...@cstamas.hu
Bug#720537: ITP: r-bioc-iranges -- GNU R low-level containers for storing sets of integer ranges
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-iranges Version : 1.18.3 Upstream Author : H. Pages * URL : http://bioconductor.org/packages/2.3/bioc/html/IRanges.html * License : Artistic-2.0 Programming Lang: R Description : GNU R low-level containers for storing sets of integer ranges Ranges class and its extensions are low-level containers for storing sets of integer ranges. A typical use of these containers in biology is for representing a set of chromosome regions. More specific extensions of the IRanges class will typically allow the storage of additional information attached to each chromosome region as well as a hierarchical relationship between these regions. This package belongs to a large set of prerequisites we need from BioConductor to get the existing package r-bioc-cummerbund updated to the latest version. The packaging is done inside the Debian Med team and was prepared in svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-iranges/trunk/ -- 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/20130823084144.12585.75195.report...@mail.an3as.eu
Re: Introducing dgit - git integration with the Debian archive
On 23 August 2013 00:38, Charles Plessy wrote: > Le Thu, Aug 22, 2013 at 08:52:10PM +0100, Ian Jackson a écrit : >> I'm pleased to announce that dgit 0.7, which is a version of dgit >> suitable for alpha and beta testers, is available in unstable. >> >> >From the manpage: >> >>dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >>dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >>dgit [dgit-opts] build|sbuild [build-opts] >>dgit [dgit-opts] push [dgit-opts] [suite] >> >>dgit treats the Debian archive as a version control system, and >>bidirectionally gateways between the archive and git. The git >>view of the package can contain the usual upstream git history, >>and will be augmented by commits representing uploads done by >>other developers not using dgit. This git history is stored in >>a canonical location known as dgit-repos which lives outside >>the Debian archive (currently, on Alioth). > > Thanks a lot for this development ! > > For the packages that I maintain with Git, I commit build logs (the local one > for the uploaded binary packages, plus the buildd ones) in separate branches. > In some cases I found it quite useful. Have you considered integrating logs > in > dgit ? In a somehow similar goal (finding difference between builds), have > you > also considered committing the contents of the unpacked binary packages in > other branches ? > Apart from designated release dgit branches, it's a normal git repository into which one can push whatever one wants: pristine-tar, various git/quilt patch management branches, build-logs, upstream branches et. al. Regards, Dmitrijs. -- 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/canbhluhxyz9qkbbbwsvejcbsre9azss5e5ymgpcnpqkxpie...@mail.gmail.com
Re: asking for advice: all dependencies incl. version numbers
Hi, Quoting FARKAS, Illes (2013-08-22 17:47:57) > I'd like to download/parse for each version of each debian package which > other package versions it depends on. > > Do you think this information available in managable formats? In addition to the information Joachim already gave, let me specifically point you at dose3. It is a framework for working with dependencies and allows you to parse Packages.bz2 and Sources.bz2 files, create all kinds of dependency graphs and analyze them and includes a solver for package relationships. > Have you seen similar work before? Joachim was pointing you at edos. There exists the tool edos-debcheck (or edos-distcheck as a more general tool) in the main archive. But instead you might want to look at the dose3 tools which supersede the edos tools. More specifically you want to look at the binary packages built from the source package dose3. The dose-extra binary package contains a tool called ceve which allows you to build many different kinds of dependency graphs from a Packages.bz2 file. Maybe this gives you the information you need. Contact me if you have any trouble. cheers, josch -- 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/20130823094312.4755.71787@hoothoot
Re: Introducing dgit - git integration with the Debian archive
On Fri, 2013-08-23 at 10:15 +0100, Dmitrijs Ledkovs wrote: > Apart from designated release dgit branches, it's a normal git > repository into which one can push whatever one wants: pristine-tar, > various git/quilt patch management branches, build-logs, upstream > branches et. al. Hi, a somewhat related question: Anybody using guilt (qit+quilt)for patch management? -- 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/1377251889.4078.5.ca...@g3620.my.own.domain
Bug#720546: ITP: r-bioc-affyio -- BioConductor tools for parsing Affymetrix data files
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-affyio Version : 1.28.0-1 Upstream Author : Benjamin Milo Bolstad * URL : http://www.bioconductor.org/packages/2.12/bioc/html/affyio.html * License : LGPL-2.1+ Programming Lang: R Description : BioConductor tools for parsing Affymetrix data files This BioConductor package provides routines for parsing Affymetrix data files based upon file format information. Primary focus is on accessing the CEL and CDF file formats. This package belongs to a chain of preconditions to upgrade the package r-bioc-cummerbund. It is maintained in Debian Med team and available in SVN svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-affyio/trunk/ -- 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/20130823103939.15799.24995.report...@mail.an3as.eu
Bug#720547: ITP: ocaml-estring -- Estring: OCaml development platform
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: ocaml-estring Version : git snapshot Upstream Author : Jeremie Dimino * URL or Web page : https://github.com/diml/estring * License : BSD-3-Clause Description : Estring: OCaml development platform estring, which stands for `extended strings' is a syntax extension allowing to prefix string literals with a specifier to change their meaning. . This package used to be part of the batteries project. Regards, Dmitrijs -- 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/87a9k8lm4d@debian.org
Re: Bug#720518: ITP: tdbcpostgres -- Postgresql driver for the TDBC datatabase connectivity
I decided to call the package after the source package name. This package is eventually generating tcl8.x binary packages that follow the policy. In future it might happen that multiple binary packages for binary incompatible Tcl versions have to be released. -- Massimo On 08/23/2013 12:54 PM, Andrew Shadura wrote: Hello, On 23 August 2013 00:30, Massimo Manghi wrote: * Package name: tdbcpostgres Version : 1.0.0 Upstream Author : mxman...@apache.org * URL : http://tdbc.tcl.tk/ * License : BSD Programming Lang: (C,Tcl) Description : Postgresql driver for the TDBC datatabase connectivity I think you need to rename the package according to the Tcl packaging policy, just as you did with the SQLite backend. -- 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/52174119.6010...@apache.org
Re: Bug#720518: ITP: tdbcpostgres -- Postgresql driver for the TDBC datatabase connectivity
Hello, On 23 August 2013 00:30, Massimo Manghi wrote: > * Package name: tdbcpostgres > Version : 1.0.0 > Upstream Author : mxman...@apache.org > * URL : http://tdbc.tcl.tk/ > * License : BSD > Programming Lang: (C,Tcl) > Description : Postgresql driver for the TDBC datatabase connectivity I think you need to rename the package according to the Tcl packaging policy, just as you did with the SQLite backend. -- WBR, Andrew -- 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/cacujmdodb1trvjzzfvkcwd11pvkb4qc5xpva3tj20ggxczv...@mail.gmail.com
Bug#720550: ITP: r-bioc-preprocesscore -- BioConductor collection of pre-processing functions
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-preprocesscore Version : 1.22.0 Upstream Author : Benjamin Milo Bolstad * URL : http://www.bioconductor.org/packages/2.12/bioc/html/preprocessCore.html * License : LGPL-2.1 Programming Lang: R Description : BioConductor collection of pre-processing functions This BioConductor module contains a library of pre-processing functions. It is imported by several other BioConductor modules. This package belongs to the set of preconditions for the new version of r-bioc-cummerbund and is maintained in Debian Med team. It is available in SVN svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-preprocesscore/trunk/ -- 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/20130823110823.17194.6546.report...@mail.an3as.eu
Re: Introducing dgit - git integration with the Debian archive
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian
archive"):
> I'm sorry to have missed that impromptu BOF at debconf, I would have
> definitely arranged myself to be there if I had known its existence.
Yes, sorry about that, but it was arranged ad hoc at zero notice.
> I don't think that "3.0 (quilt)" does things without justification so
> calling those features "braindamage" is not really nice. Clearly the
> quilt format duplicates some of the VCS features (with its .pc directory)
> and this is probably what you are referring to in the above paragraph.
The thing that really bothers dgit is that it is not always possible
to round trip a tree through dpkg-source. (And the case where it
doesn't work is the common one.)
That is, if I do this:
1. dpkg-source -x
2. edit things
3. dpkg-source -b
4. dpkg-source -x on the output from stage 3
then the output of step 4 is not always the same as the input
to step 3. Typically the output of step 4 has additional metadata
files inside the tree.
It seems to me that the most fundamental requirement for an archive
format of any kind is that packing something into the archive, and
then unpacking it again, should give you back what you started with.
> That said I have always thought of the "3.0 (quilt)" source package as
> something that we should be able to generate ouf of a VCS tree, not
> something to be directly stored in a VCS repository.
With dgit, at the moment, all that happens is that the gitish
changes get piled into the dpkg-source-generated patch.
For some more sophisticated workflow, it is necessary to round trip
the patch stack through the archive and back into git.
> In any case, I'm open to suggestions to improve the format to better suit
> your needs... so can you can explain me more precisely what's causing you
> issues? Either here or better in a bug report against dpkg-dev.
Ideally, packing something up and then unpacking it again should not
produce changes. NB that if you change this you absolutely must not
change the meaning of existing source archives - ie you can make
changes to the packing algorithm but not to transformation implied by
the unpack algorithm.
> I would really like to find a good workflow that suits "3.0 (quilt)".
> Badly supporting half the archive looks like a problem.
The support is no worse than NMUs are now, from the maintainer's POV.
>From the git POV you just see a git history of some kind and commit on
it.
> BTW, instead of advising against "3.0 (quilt)" you should rather recommend
> the usage of the --single-debian-patch option when using that format...
> this will make it mostly work like "1.0".
This is a command-line option ? How does one specify in the source
package that this is to be used.
> I have read the manual page but there some things that I don't really
> understand on the design yet. So let me ask some questions:
>
> - is there some server side part (running on alioth)?
> what does it take care of?
Yes. It is a git repository. That is all that it is.
> - what/who creates the initial repository? and what/who keeps it in sync with
> the (non-dgit-based) archive uploads?
The repos are created only by dgit users. Different dgit users see
the same commits from the archive: the synthesised commits are
deterministic.
In the future there might be a robot keeping it in sync with the
archive.
Thanks,
Ian.
--
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/21015.18345.930607.890...@chiark.greenend.org.uk
Re: Bug#720518: ITP: tdbcpostgres -- Postgresql driver for the TDBC datatabase connectivity
Hello, On 23 August 2013 13:01, Massimo Manghi wrote: > I decided to call the package after the source package name. This package is > eventually generating tcl8.x binary packages that follow the policy. In > future it might happen that multiple binary packages for binary incompatible > Tcl versions have to be released. Yes, that's what I meant. -- WBR, Andrew -- 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/CACujMDMquUFJ0ME=+a3rcudyqfw+deadpjt_jupfftu8sja...@mail.gmail.com
Bug#720577: ITP: python-qt4reactor -- Provides support for Twisted to be driven by the Qt mainloop
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-qt4reactor Version : 1.0 Upstream Author : Michael Terry * URL : https://github.com/ghtdak/qtreactor * License : Expat Programming Lang: Python Description : Twisted Qt4 integration This package provides support for Twisted to be driven by the Qt mainloop -- 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/20130823125630.23442.68432.report...@muck.riseup.net
Bug#720579: ITP: r-bioc-biocinstaller -- Install/Update Bioconductor and CRAN Packages
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-biocinstaller Version : 1.10.3 Upstream Author : Dan Tenenbaum * URL : http://www.bioconductor.org/packages/2.12/bioc/html/BiocInstaller.html * License : Artistic-2.0 Programming Lang: R Description : Install/Update Bioconductor and CRAN Packages This package is basically created to fullfill a dependency of the r-bioc-affy package. Usually all BioConductor packages should be rather installed as Debian packages than with this tool. Another precondition for r-bioc-cummerbund as all the other ITPs today svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-biocinstaller/trunk/ -- 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/20130823130435.17627.32613.report...@mail.an3as.eu
Bug#720583: ITP: r-bioc-graph -- handle graph data structures for BioConductor
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-graph Version : 1.38.3 Upstream Author : Bioconductor Package Maintainer * URL : http://www.bioconductor.org/packages/2.12/bioc/html/graph.html * License : Artistic-2.0 Programming Lang: R Description : handle graph data structures for BioConductor This BioConductor module implements some simple graph handling capabilities. These are for instance used in hypergraph module which in turn is used by several other BioConductor packages. To this package applies the same as for the other packages r-bioc-* I ITPed today svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-graph/trunk/ -- 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/20130823140314.21471.80205.report...@mail.an3as.eu
Re: Introducing dgit - git integration with the Debian archive
Hi,
On Fri, 23 Aug 2013, Ian Jackson wrote:
> The thing that really bothers dgit is that it is not always possible
> to round trip a tree through dpkg-source. (And the case where it
> doesn't work is the common one.)
>
> That is, if I do this:
> 1. dpkg-source -x
> 2. edit things
> 3. dpkg-source -b
> 4. dpkg-source -x on the output from stage 3
> then the output of step 4 is not always the same as the input
> to step 3. Typically the output of step 4 has additional metadata
> files inside the tree.
Well, by default step 3 fails if you have upstream changes. Unless you
use --auto-commit or --single-debian-patch. So the logical thing to do
is to call "dpkg-source --commit . " when you know that you
have upstream changes compared to the last debian package.
I believe that after the --commit you have the same metadata that you
would have after step 4.
> For some more sophisticated workflow, it is necessary to round trip
> the patch stack through the archive and back into git.
I'm not following you here. Can you elaborate ? ("round-trip through the
archive" doesn't mean anything obvious to me)
What I would like to have with "3.0 (quilt)" source packages is a git
repository with the patches applied but without the .pc/ quilt dir (that's
just noise). We would probably have a debian/source/local-options to
indicate to dpkg-source that the patches are already applied and that
it should deal with it.
Then I add commits like usual and they would be automatically
converted to new quilt patches in a later step when I tell dgit
to build the source. (Bonus point: we could add some metadata
in commit notices to merge the change in a existing quilt patch)
The really tricky part is how to update the patches when you merge
a new upstream version that changes the underlying code so that the
patches no longer apply. See http://bugs.debian.org/572204 for how Colin
Watson deals with this. I think he uses bzr and I'm not sure if we
can force git to proceed with the merge if we have local uncommitted
changes.
Basically, it would be good enough I believe if we can approximate this
with:
1/ a commit that reverts the Debian patches
2/ a commit that merges the upstream changes + reapplies Debian patches
(git merge --no-commit + quilt push -a with the required human fixes)
Bonus point if your replace the "quilt push -a" with git cherry-pick of
all patches and automatic refresh of the patches.
> > BTW, instead of advising against "3.0 (quilt)" you should rather recommend
> > the usage of the --single-debian-patch option when using that format...
> > this will make it mostly work like "1.0".
>
> This is a command-line option ? How does one specify in the source
> package that this is to be used.
You put "single-debian-patch" in debian/source/local-options (or …/options
if you want to keep it in the generated source package).
(=> with "local-options" this is another case of something that you can
have in your tree and that you won't have in the unpack of the generated
source package)
> > - what/who creates the initial repository? and what/who keeps it in sync
> > with
> > the (non-dgit-based) archive uploads?
>
> The repos are created only by dgit users. Different dgit users see
> the same commits from the archive: the synthesised commits are
> deterministic.
OK, assuming that they are created on top of the same commit I guess.
Are those commits replacing all the files or are they actually a merge of
changes from upload_n-1 to upload_n in the git repository?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20130823164508.gc30...@x230-buxy.home.ouaza.com
Re: Introducing dgit - git integration with the Debian archive
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian
archive"):
> On Fri, 23 Aug 2013, Ian Jackson wrote:
> > The thing that really bothers dgit is that it is not always possible
> > That is, if I do this:
> > 1. dpkg-source -x
> > 2. edit things
> > 3. dpkg-source -b
> > 4. dpkg-source -x on the output from stage 3
> > then the output of step 4 is not always the same as the input
> > to step 3. Typically the output of step 4 has additional metadata
> > files inside the tree.
>
> Well, by default step 3 fails if you have upstream changes.
I'm not sure what you mean by "upstream changes". Do you mean changes
outside the Debian directory ? If so I wasn't aware of it. Perhaps I
didn't read the manpage clearly enough. I think that is also broken.
It seems to me that the most basic requirement of an archive source
format is that the four operations I describe above should work and
DTRT.
Ie:
(i) dpkg-source -b should be able to run on any reasonable tree
(ii) dpkg-source -b should not modify the directory it is run in
(iii) dpkg-source -x should always produce the same tree as
was fed to dpkg-source -b
But as I understand you, `3.0 (quilt)' violates these and this
deliberate.
If I have understood you, dgit won't work properly if you make the
"wrong" kind of change, so I need to either have this fixed, or (more
likely) to work around it (and bitch some more in the manpage). Does
"dpkg-source --commit" make any changes other than to quilt metadata ?
Perhaps dgit push should do that automatically.
> > For some more sophisticated workflow, it is necessary to round trip
> > the patch stack through the archive and back into git.
>
> I'm not following you here. Can you elaborate ? ("round-trip through the
> archive" doesn't mean anything obvious to me)
I would like to focus on fixing the existing situation before getting
into this discussion, so I'm afraid I'm not going to reply to this
part right now.
> > This is a command-line option ? How does one specify in the source
> > package that this is to be used.
>
> You put "single-debian-patch" in debian/source/local-options (or …/options
> if you want to keep it in the generated source package).
>
> (=> with "local-options" this is another case of something that you can
> have in your tree and that you won't have in the unpack of the generated
> source package)
It seems to me that it is the maintainer who determines the source
package format. Therefore putting this in local-options makes no
sense.
> > The repos are created only by dgit users. Different dgit users see
> > the same commits from the archive: the synthesised commits are
> > deterministic.
>
> OK, assuming that they are created on top of the same commit I guess.
There is an intervening pseudo-merge. So all dgit users will
create the same root commits with perhaps some different pseudo-merges
if they do dgit fetch at different times and so see different states
of the dgit/suite branch in dgit-repos.
> Are those commits replacing all the files or are they actually a merge of
> changes from upload_n-1 to upload_n in the git repository?
Each upload is represented as a new root commit whose tree contains
the files which are the result of "dpkg-source -x". This is then
merged into the existing head of the suite's branch in dgit-repos with
a pseudo-merge (ie, a merge which takes content only from one of the
parents). The dgit-repos suite branches are fast-forwarding.
Thanks,
Ian.
--
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/21015.38370.906620.363...@chiark.greenend.org.uk
Re: Introducing dgit - git integration with the Debian archive
Ian Jackson writes ("Re: Introducing dgit - git integration with the Debian
archive"):
...
> If I have understood you, dgit won't work properly if you make the
> "wrong" kind of change, so I need to either have this fixed, or (more
> likely) to work around it (and bitch some more in the manpage). Does
> "dpkg-source --commit" make any changes other than to quilt metadata ?
> Perhaps dgit push should do that automatically.
Does anyway know of a `3.0 (quilt)' format package whose maintainer
wouldn't mind a bunch of crazy (perhaps abortive) NMUs to
experimental, which I can therefore use for testing ? I promise not
to upload to sid by mistake.
Volunteers welcome :-).
Ian.
--
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/21015.39201.573731.46...@chiark.greenend.org.uk
Re: Introducing dgit - git integration with the Debian archive
On 2013-08-23 19:17, Ian Jackson wrote:
> Ian Jackson writes ("Re: Introducing dgit - git integration with the Debian
> archive"):
> ...
>> If I have understood you, dgit won't work properly if you make the
>> "wrong" kind of change, so I need to either have this fixed, or (more
>> likely) to work around it (and bitch some more in the manpage). Does
>> "dpkg-source --commit" make any changes other than to quilt metadata ?
>> Perhaps dgit push should do that automatically.
>
> Does anyway know of a `3.0 (quilt)' format package whose maintainer
> wouldn't mind a bunch of crazy (perhaps abortive) NMUs to
> experimental, which I can therefore use for testing ? I promise not
> to upload to sid by mistake.
>
> Volunteers welcome :-).
>
> Ian.
>
>
If you promise to add autopkgtest for it, you can use any of my
packages[1]. :P
~Niels
[1] Any of which I am the sole maintainer. E.g. mscgen.
--
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/52179c67.7010...@thykier.net
Re: Introducing dgit - git integration with the Debian archive
Le 22 août 2013 21:52, "Ian Jackson" a écrit : > > I'm pleased to announce that dgit 0.7, which is a version of dgit > suitable for alpha and beta testers, is available in unstable. What are the pro/con and différence compared to gitpkg ? > > >From the manpage: > >dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >dgit [dgit-opts] build|sbuild [build-opts] >dgit [dgit-opts] push [dgit-opts] [suite] > >dgit treats the Debian archive as a version control system, and >bidirectionally gateways between the archive and git. The git >view of the package can contain the usual upstream git history, >and will be augmented by commits representing uploads done by >other developers not using dgit. This git history is stored in >a canonical location known as dgit-repos which lives outside >the Debian archive (currently, on Alioth). > > If you don't like git, or think I have taken the wrong approach, then > you need read no further. You can carry on just as before. > > > If on the other hand you'd like to experiment with a new tool that > lets you work on any package in the archive using git, even with > upstream git history in your history if you like, and to share your > git-based work with other uploaders, please install dgit 0.7 from > unstable and try it out. > > For more information, the full manpage is here: > http://www.chiark.greenend.org.uk/~ijackson/2013/dgit.html > (this is slightly more up to date than the one on manpages.debian.net). > > This is still a very early version. I'm not aware of anyone but me > having used it in anger. So there are very likely to be bugs. Please > report them. > > With regret I must note that currently you can't use it if you don't > have a full DD account on both the Debian systems and on Alioth. Even > if you just want a read-only mode. This is due to deficiencies in the > archive software and in Alioth, which I have worked around in very > unpleasant ways. I'm hoping that this will improve fairly soon. > Please see the BUGS section of the manpage. > > The master git repository for dgit is here: > http://anonscm.debian.org/gitweb/?p=dgit-repos/dgit.git > Pull requests welcome (please send them to the BTS). > > > Some background: > > At Debconf we had a series of discussion on the problem of integrating > git and the archive, culminating in an excellent bar-BOF. We started > with a diagram Joey Hess had drawn on a piece of cardboard, of a > design he had; many of us came to the BOF with our own preconceptions. > Too often these discussions result in a gigantic edifice which will > take six-months to implement and six years to persuade people is a > good idea. But, during this conversation, instead, pieces were hacked > off until the result was implementable right away. So that's what > dgit is. > > Key points about dgit's design: > > * It doesn't require anyone else to change their existing workflow. > > * You can use it on any package. > > * If you are the maintainer and want to use it on your own package, >it will allow you to adopt a gitish workflow and will let you >easily import into your git history the changes made in NMUs, >security updates - and hopefully eventually derivative distros. > > * I think we can extend it later to support working on quilty >packages (with patch stacks) as if they were git branches. This is >not yet done because it's quite complicated. See PACKAGE SOURCE >FORMATS in the manpage. > > > Thanks, > Ian. > > > -- > 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/21014.27626.870447.341...@chiark.greenend.org.uk >
Re: Introducing dgit - git integration with the Debian archive
Bastien ROUCARIES writes ("Re: Introducing dgit - git integration with the
Debian archive"):
> Le 22 août 2013 21:52, "Ian Jackson" a
> écrit :
> > I'm pleased to announce that dgit 0.7, which is a version of dgit
> > suitable for alpha and beta testers, is available in unstable.
>
> What are the pro/con and différence compared to gitpkg ?
gitpkg seems to be something entirely different. dgit tries to make
the Debian archive look like a git repository.
Ian.
--
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/21015.42668.430786.342...@chiark.greenend.org.uk
Re: Custom Reload command/signal in upstart
> There is no point to start a daemon unless you actually > need it. This is complete 'modern' crap If you don't want a service started then why are your starting it, because you might want it is a stupid argument with next to no positives. SSH takes a blink of an eye to start. It is far better not to mention more secure to start a service during the pristeen boot phase than wait for it to do it's shizzle including dropping priviledges etc. upon the receipt of packets. You have to wait for the bios and hardware so a split second won't matter on boot. If ever more likely to matter (a second) then it will be when you need it in fact. I would also much rather have my daemons ready and waiting than have them come running when I or an attacker calls. Having a daemon hanging around with a trigger finger ready to kill daemons is also really dumb. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/907735.98771...@smtp112.mail.ir2.yahoo.com
Re: Custom Reload command/signal in upstart
On 31 May 2013 22:44, Ondřej Surý wrote: > > It's pretty much equivalent with one exception – I need to send USR2 on > reload. Does upstart already have the support for custom reload signals? > Upstart 1.10 released today has the following new stanza thus you will be able to specify: "reload signal SIGUSR2" Once 1.10 is uploaded in Debian. Regards, Dmitrijs. -- 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/canbhluis2jp-bvv6g5p2o-br2-ci6+2v4yhz0ybuvbho5nm...@mail.gmail.com
Re: Custom Reload command/signal in upstart
On 08/23/2013 04:02 PM, Kevin Chadwick wrote: >> There is no point to start a daemon unless you actually >> need it. > > This is complete 'modern' crap No, it's not. It's the only reasonable thing to do. Nothing is safer than a daemon which is *not* running. The fewer services are running, the fewer potential undisclosed vulnerabilities can be exploited. > If you don't want a service started then why are your starting it, > because you might want it is a stupid argument with next to no > positives. SSH takes a blink of an eye to start. I'm not sure whether I understand what you're trying to say. But, yes, since SSH takes a blink to start, there's no point having it running all the time while it isn't actually currently in use. > It is far better not to mention more secure to start a service during > the pristeen boot phase than wait for it to do it's shizzle including > dropping priviledges etc. upon the receipt of packets. That's non-sense. The time a process is started doesn't have any influence on the security of the service. If it does, this should be considered a bug since the service daemon would show an unpredictable and unreliable behavior. However, as I said before, it's in general more secure to have a service not running when it's not required. Imagine there is a vulnerability in SSH which has not been fixed yet for whatever reason. Having SSH run in this situation all the time would make the machine a target for possible attacks. However, SSH being started on demand only would dramatically reduce the probability that the vulnerability would actually be successfully exploited. > You have to wait for the bios and hardware so a split second won't > matter on boot. If ever more likely to matter (a second) then it > will be when you need it in fact. I'm pretty sure no one is talking about boot times in this context, that's not the point at all of starting services on demand. It's a matter of economic use of available resources. Having a service idling in the background all the time would be like having your car engine running while you're sitting on your sofa and watching TV. If you don't need something, turn it off. > I would also much rather have my daemons ready and waiting than have > them come running when I or an attacker calls. Honestly, that doesn't even make any sense. Again, a service which is not running is reducing the probability of an attack, not vice versa. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/5217c927.2010...@physik.fu-berlin.de
Re: Custom Reload command/signal in upstart
On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote: > Imagine there is a vulnerability in SSH which has not been fixed > yet for whatever reason. Having SSH run in this situation all the > time would make the machine a target for possible attacks. If all I have to do is make a connection to port 22 to start the service, which would happen as part of an attack anyway, then there's no added security provided by socket activation. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Custom Reload command/signal in upstart
On Aug 23, 2013, at 8:45 PM, James McCoy wrote: > >> On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote: >> Imagine there is a vulnerability in SSH which has not been fixed >> yet for whatever reason. Having SSH run in this situation all the >> time would make the machine a target for possible attacks. > > If all I have to do is make a connection to port 22 to start the > service, which would happen as part of an attack anyway, then there's no > added security provided by socket activation. True. But you could have SSH listen on a different port to avoid such an attack, couldn't you? Also, I remember there was a 'knockd', which would open the port for SSH when you send a certain sequence of packets to the host. Cheers, Adrian -- 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/22b26f29-0f55-45ff-a94d-08fb8d4d6...@physik.fu-berlin.de
