Bug#720772: ITP: tdbcodbc -- ODBC driver for the TDBC database connectivity
Package: wnpp Severity: wishlist Owner: Massimo Manghi * Package name: tdbcodbc Version : 1.0.0 Upstream Author : Kevin B. Kenny The Tcl Core Team * URL : http://tdbc.tcl.tk/ * License : (custom, BSD) Programming Lang: (C, Tcl) Description : ODBC driver for the TDBC database connectivity driver for the TDBC package, a database abstraction layer for the Tcl command language -- 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/2013082510.4789.69850.report...@magnesium.biol.unipr.it
Re: Introducing dgit - git integration with the Debian archive
Hello, On Thu, 22 Aug 2013, Ian Jackson wrote: > 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 Basically, this is "Ubuntu Distributed Development" (UDD) but for Debian & Git (instead of Ubuntu & bzr). Have you looked at UDD? They have been doing this for multiple years and have much more experience than us here. I'm sure there a quite a few things to learn from what they did to not redo the same mistakes. https://wiki.ubuntu.com/DistributedDevelopment http://developer.ubuntu.com/packaging/html/udd-intro.html https://launchpad.net/udd I'm putting James Westby in CC (as I believe he's one of the core UDD developers, and also a Debian contributor). He might want to review dgit and share his hindsights. Among notable differences there's that dgit contrary to UDD decentralizes the creation of the branch with all the archive uploads. But I never used UDD and don't know it well enough to comment much more than that. 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/20130825110432.gb20...@x230-buxy.home.ouaza.com
Bug#720773: ITP: tdbcodbc -- ODBC driver for TDBC database connectivity
Package: wnpp Severity: wishlist Owner: Massimo Manghi * Package name: tdbcodbc Version : 1.0.0 Upstream Author : Kevin B. Kenny The Tcl Core Team * URL : http://tdbc.tcl.tk/ * License : (custom, BSD) Programming Lang: (C, Tcl) Description : ODBC driver for TDBC database connectivity ODBC driver for the TDBC package, a database abstraction layer for the Tcl command language -- 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/20130824202850.9994.88738.report...@magnesium.biol.unipr.it
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 12:04, Raphael Hertzog wrote: > Hello, > > On Thu, 22 Aug 2013, Ian Jackson wrote: >> 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 > > Basically, this is "Ubuntu Distributed Development" (UDD) but for Debian & > Git (instead of Ubuntu & bzr). > > Have you looked at UDD? They have been doing this for multiple years and > have much more experience than us here. I'm sure there a quite a few > things to learn from what they did to not redo the same mistakes. > Things to learn from UDD: 1) the fact that debian didn't have a _standartised_ VCS repository format, for UDD workflow all debian packages had to be imported, such that lp:debian/package can be merged into lp:ubuntu/package. 2) 3.0 (quilt) causes problems: - we had to go with committing .pc directory in the unpacked tree. As otherwise, new patch end up at the start of the quilt series and can cause the rest of series to fail to apply - debian/patches/series.$vendor is evil, often series.ubuntu were not updated/refreshed/rebased causing dpkg-source -x to fail with DEB_VENDOR=Ubuntu - Merging two quilt series is a pain, as there is no $ quilt merge. We end up unapplying both quilt series, merging the branches and throw conflicts in debian/patches/series at the developer and asking them to figure out what patches to apply and refresh quilt series themselves. - versioning .pc directory is a pain, especially when quilt is updated. E.g. newer versions of quilt added pointless .timestamp files in the .pc directory which where not present in the automatic lp:ubuntu/* and lp:debian/* branches which used older quilt - a valid git/bzr patch may not be a valid quilt patch, and it turn may not be a valid "patch" as considered by dpkg. It's getting better with patch(1) starting to support git format-patch style patches. Thus cherry-picking from upstream becomes a pain, I have multiple times applied upstream cherry-picked patch, only later find out that e.g. +x flag was not preserved, or fuzz is generated, or files are not renamed. - tarball inside tarball packaging is evil & must die 3) Automatic importer is part of the UDD workflow, only because there was no standartised developer created rich-VCS history on Debian side which fully matched the archive state. And basing ubuntu branches, on something that doesn't match debian uploads into the archive was a no-go. 4) automatic importer was necessory to import Debian history and well it was not perfect: http://package-import.ubuntu.com/status/, pristine-tar used to fail (importer was running on stable, now upgraded and much better), dpkg-source -x sometimes fails, operational issues (timeouts, OOM, etc), unreconcilable history (developer rebases old tags, and importer can no longer reconcile it's state), - history can be odd: UDD discovered where referenced uploads didn't happen, or experimetal got ahead & then behind sid and has a really hard time figuring out when, if ever, experimental got merged into sid. (sometimes it's just abandoned) I think james can give more examples. The best UDD workflow seems to work with native packages: As a highlight I can give example debian-installer. All debian-installer git repositories are homogeneous and follow the same layout. All of d-i projects are imported into bzr branches https://code.launchpad.net/d-i And then Ubuntu Installer team maintains branches where Ubuntu diverges, e.g.: lp:~ubuntu-core-dev/apt-setup/ubuntu which frequently merges in debian changes from lp:apt-setup In a similar manner packages which use 1.0 format without a patch system work really well with lp:ubuntu/* and lp:debian/* branches. I have maintenance access to UDD & have filed a few bugs about it, and all I can say is that dgit so far is getting a lot of things right: 1) round-trip tree guarantee same is required for UDD, and automatic importer can fail to get the state right when developers push different tree in the VCS vs what dpkg-source -x produces. Don't forget, e.g. git doesn't commit empty directories. I have seen a case where bzr-git was used to push commits without empty directories into lp:ubuntu/$pkg branches & then dpkg-source -x not matching the state of the vcs, resulting in the automatic importer failing. 2) removing automatic importer forcing all the checks on the developer side & forcing VCS commit to match the src upload is a massive win. It means that one can actually trust the archive & VCS commits. And they will always match. (Well one can even verify that by unpac
Re: Preventing government subversion in Debian, verification of binary package uploads
On 08/24/2013 07:55 PM, Robert Holtzm wrote: On Sat, Aug 24, 2013 at 11:45:54PM +0200, Thomas Hood wrote: Here I assume that U.S. law is not so draconian that it can require someone who has contributed to Debian (and who is therefore trusted) to continue doing so. Don't be too sure. The owner of, I believe, lavabit was threatened with criminal prosecution for shutting down his site rather than comply with the NSA. Can't vouch for that but that's the story going around. It's unclear, but the interpretation of the reports which I find most plausible is that the threat (of "contempt of court", AIUI) may have been not for shutting down the site or for refusing to comply but for effectively violating a gag order about the whole thing by the way he explained that - and why - he was shutting down. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- 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/5219f221.7010...@fastmail.fm
Re: Introducing dgit - git integration with the Debian archive
On 22 August 2013 20:52, Ian Jackson wrote: > 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. > I have now started daily PPA builds for dgit, for all supported Ubuntu releases. add-apt-repository ppa:xnox/dgit Since dgit dependencies are so simple, it should also be safe to use that PPA on any debian release as well, e.g.: deb http://ppa.launchpad.net/xnox/dgit/ubuntu precise main deb-src http://ppa.launchpad.net/xnox/dgit/ubuntu precise main With the following archive key 1024R/4031D287 2D9DF1E22F3416238D46F49F157951FE4031D287 http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x157951FE4031D287 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/CANBHLUjGfENtc3ne+Cupwvgc4DtN3+_8kcJ=21oxxwzksd8...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian
archive"):
> What you mean is that on the server side the dgit-branches containing the
> uploads are in refs/dgit/ and not in refs/heads/. But there will also
> be refs/heads/dgit/ branches on the server side since that's where
> people will naturally push stuff:
Yes. That's fine.
> So there's a refs/head/dgit/ and it can be pushed to the server.
> But it will be different to the refs/dgit/ that gets merged by
> dgit pull...
Indeed, if you do that kind of "git push". The remote that
corresponds to that is "origin" though.
> Speaking of braindamage... :-)
I'll see if it confuses people. If so it should probably be mentioned
in the manpage.
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/21018.5937.766774.259...@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"):
> Unfortunately there is a problem that means it's difficult for others
> to test. The alioth git directory is not writeable by the right
> group. [...]
I have fixed this by using a subdirectory instead, whose permissions I
have set appropriately. (Thanks to Joey for the suggestion.)
This means that previous versions of dgit won't work any more. Also,
trees previosly made with "dgit clone" will have to have their
"origin" remotes adjusted with something like this:
git-remote set-url origin
git+ssh://i...@git.debian.org//git/dgit-repos/repos/.git
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/21018.11167.530395.993...@chiark.greenend.org.uk
Re: Introducing dgit - git integration with the Debian archive
On Sun, Aug 25, 2013 at 12:51:31PM +0100, Dmitrijs Ledkovs wrote: > I have maintenance access to UDD & have filed a few bugs about it, and > all I can say is that dgit so far is getting a lot of things right: > 2) removing automatic importer > forcing all the checks on the developer side & forcing VCS commit to > match the src upload is a massive win. It means that one can actually > trust the archive & VCS commits. And they will always match. (Well one > can even verify that by unpacking the .dsc and comparing it to the > Dgit: commit id) After all the archive will always be authoritative, > as that's that gets GPG signature, is mirrored and gets deployed to > the users. I don't think "removing the automatic importer" is an improvement at all. If we want VCS branches for the whole of Debian that we can rely on, something / someone needs to update them automatically when a package is uploaded. The problems with the UDD automatic importer have all been around its failing to cope with any kind of manual changes to the bzr branch. I.e., if even once the importer sees an upload before it sees the corresponding commit on the bzr branch - because a maintainer did a bzr push --overwrite, or because of a race between the upload and the branch propagation, or because of a bug on the server - then that package is forever after in "manual" import mode until someone with admin privileges can kick the machine. This is a pretty bad failure mode; but it's a failure because the importer can't cope with changes to the branch, not because automatic importing was being done. > And one is free to push pristine-tar (if makes sense/easy to > generate), and/or any other branches into the repository (git-dpm, > git-quilt, etc) I would have expected dgit to support pristine-tar directly/automatically/unconditionally. Any system that requires me to download the same information (== the upstream source) both from a VCS repository and the archive in order to get a fully-formed source package for upload is a non-starter. > I am exited about dgit, as for the first time it will be possible for > derivatives to centrally share history with Debian. I am as well! > In practice one doesn't actually care how far back the history goes, > as the history that is interesting is where developers get to do > intermediate commits between the two uploads to granulise the > changes I don't agree with this at all. I have regularly made use of the UDD branches to examine the history of packages (and not just the Ubuntu history, but also the Debian history). Being upload-level granularity makes it less useful than if it were at the granularity of a VCS branch being committed to natively by the developer, but it's still *very* useful for understanding the uploader's thought process at the time a change was made. The fact that git will allow us to graft the developer's own VCS on to these dgit repositories in a way that UDD never did is an important improvement, but as this is *optional*, not importing the package history from the archive would make dgit much less useful for the common case than UDD is today. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 17:31, Steve Langasek wrote: > On Sun, Aug 25, 2013 at 12:51:31PM +0100, Dmitrijs Ledkovs wrote: >> I have maintenance access to UDD & have filed a few bugs about it, and >> all I can say is that dgit so far is getting a lot of things right: > > > >> 2) removing automatic importer >> forcing all the checks on the developer side & forcing VCS commit to >> match the src upload is a massive win. It means that one can actually >> trust the archive & VCS commits. And they will always match. (Well one >> can even verify that by unpacking the .dsc and comparing it to the >> Dgit: commit id) After all the archive will always be authoritative, >> as that's that gets GPG signature, is mirrored and gets deployed to >> the users. > > I don't think "removing the automatic importer" is an improvement at all. > If we want VCS branches for the whole of Debian that we can rely on, > something / someone needs to update them automatically when a package is > uploaded. > Under dgit: push = (git push + dput *.changes). Thus the failure mode is much sooner and in general it's more strict. For uploads done without using dgit, it can synthesise "upload granulaty" commits with reproducible / stable commit ids. Thus the branches are maintained up to date, without the need to rely on automatic importer. One can trivially add automatic importer for uploads done without dgit. > The problems with the UDD automatic importer have all been around its > failing to cope with any kind of manual changes to the bzr branch. I.e., > if even once the importer sees an upload before it sees the corresponding > commit on the bzr branch - because a maintainer did a bzr push --overwrite, > or because of a race between the upload and the branch propagation, or > because of a bug on the server - then that package is forever after in > "manual" import mode until someone with admin privileges can kick the > machine. This is a pretty bad failure mode; but it's a failure because the > importer can't cope with changes to the branch, not because automatic > importing was being done. > >> And one is free to push pristine-tar (if makes sense/easy to >> generate), and/or any other branches into the repository (git-dpm, >> git-quilt, etc) > > I would have expected dgit to support pristine-tar > directly/automatically/unconditionally. Any system that requires me to > download the same information (== the upstream source) both from a VCS > repository and the archive in order to get a fully-formed source package for > upload is a non-starter. > if pristine-tar can recreate the tarball, without size penalties. Since it's just a git repository, one can do $ pristine-tar commit and push that into the dgit repository. At the moment it's not a requirement. >> I am exited about dgit, as for the first time it will be possible for >> derivatives to centrally share history with Debian. > > I am as well! > >> In practice one doesn't actually care how far back the history goes, >> as the history that is interesting is where developers get to do >> intermediate commits between the two uploads to granulise the >> changes > > I don't agree with this at all. I have regularly made use of the UDD > branches to examine the history of packages (and not just the Ubuntu > history, but also the Debian history). Being upload-level granularity makes > it less useful than if it were at the granularity of a VCS branch being > committed to natively by the developer, but it's still *very* useful for > understanding the uploader's thought process at the time a change was made. > > The fact that git will allow us to graft the developer's own VCS on to these > dgit repositories in a way that UDD never did is an important improvement, > but as this is *optional*, not importing the package history from the > archive would make dgit much less useful for the common case than UDD is > today. > Ok. Given that we have snapshots.debian.org & graft points we can create "import level" history in retrospect. But I find merging existing history more interesting: either upstream, or existing git/svn packaging repositories. For new packages with dgit, I start my repository on top of upstream git reposity, which gives full history of the project in the dgit repository. Imho shared history with upstream projects is more interesting than debian packaging upload history. Ideally one would have both =) 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/canbhluhypp-aaq-k1oihougwok+itswxkq2fsjl0qdk9gmf...@mail.gmail.com
Re: Preventing government subversion in Debian, verification of binary package uploads
On Sun, Aug 25, 2013 at 08:01:37AM -0400, The Wanderer wrote: > On 08/24/2013 07:55 PM, Robert Holtzm wrote: > > >On Sat, Aug 24, 2013 at 11:45:54PM +0200, Thomas Hood wrote: > > >>Here I assume that U.S. law is not so draconian that it can require > >>someone who has contributed to Debian (and who is therefore > >>trusted) to continue doing so. > > > >Don't be too sure. The owner of, I believe, lavabit was threatened > >with criminal prosecution for shutting down his site rather than > >comply with the NSA. Can't vouch for that but that's the story going > >around. > > It's unclear, but the interpretation of the reports which I find most > plausible is that the threat (of "contempt of court", AIUI) may have > been not for shutting down the site or for refusing to comply but for > effectively violating a gag order about the whole thing by the way he > explained that - and why - he was shutting down. Gag orders accompany NSA demands for compliance. The way I heard it, he shut the site down out of fear that he could be forced to comply. Again, I can't vouch for it but that's the way I heard the story. -- Bob Holtzman Your mail is being read by tight lipped NSA agents who fail to see humor in Doctor Strangelove Key ID 8D549279 signature.asc Description: Digital signature
Re: Introducing dgit - git integration with the Debian archive
Steve Langasek writes ("Re: Introducing dgit - git integration with the Debian
archive"):
> I don't think "removing the automatic importer" is an improvement at all.
I agree. Except that I wanted something I could deploy and use
immediately. Providing an automatic importer would involve
suddenly dumping the whole archive into alioth, which is not something
I should do without consultation. (It looks like the alioth admins
are very busy or away right now.)
However, dgit's design certainly doesn't forbid having an automatic
importer. Indeed there's a nice hole where the automatic importer
would sit, and most of the code necessary is already present.
> If we want VCS branches for the whole of Debian that we can rely on,
> something / someone needs to update them automatically when a package is
> uploaded.
Quite so.
> The problems with the UDD automatic importer have all been around its
> failing to cope with any kind of manual changes to the bzr branch. I.e.,
> if even once the importer sees an upload before it sees the corresponding
> commit on the bzr branch - because a maintainer did a bzr push --overwrite,
> or because of a race between the upload and the branch propagation, or
> because of a bug on the server - then that package is forever after in
> "manual" import mode until someone with admin privileges can kick the
> machine. This is a pretty bad failure mode; but it's a failure because the
> importer can't cope with changes to the branch, not because automatic
> importing was being done.
dgit suites can have an analogous error state. I don't expect it to
arise in practice.
> > And one is free to push pristine-tar (if makes sense/easy to
> > generate), and/or any other branches into the repository (git-dpm,
> > git-quilt, etc)
>
> I would have expected dgit to support pristine-tar
> directly/automatically/unconditionally. Any system that requires me to
> download the same information (== the upstream source) both from a VCS
> repository and the archive in order to get a fully-formed source package for
> upload is a non-starter.
I'm afraid you'll have to wait for dgit to be enhanced to treat
.orig tarballs specially, then.
I agree that having do download what amounts to the same data twice is
suboptimal.
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/21018.22268.542723.672...@chiark.greenend.org.uk
Re: Introducing dgit - git integration with the Debian archive
Hi All,
On szo, 2013-08-24 at 17:40 +0100, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Introducing dgit - git integration with the
> Debian archive"):
> > This is wrong on so many levels...
>
> I don't think we are going to agree. I stand by the description in
> the dgit manpage.
I agree with you, that quilt format is not as intuitive and
straightforward as it should be.
But I'm afraid that if we try to do it in any better way we will invite
the quilt format. :(
I see the following goals of the quilt format:
1. The orig.tar.gz should not be touched in any way.
2. ANY patch that touch the upstream files (ie. files outside of debian
directory) should be easily reproducible, recognisable and well
described
3. This patches ideally will be merged upstream, so drooping one of it
should be easy.
4. Of course if upstream change something we should follow. So this
patches should be easily changeable too.
Anyway.
I like this format very much because with this format the debian
directory in the orig.tar.gz is uninteresting. And with this mode I can
easily follow the upstream changes and merge it to the master branch
without fearing of conflicts. And I'm able to update all my patches in a
separate branch and merge it back to the master branch when it needed.
--
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/1377463197.3161.14.camel@mochrul.balabit
Re: Introducing dgit - git integration with the Debian archive
On Sun, Aug 25, 2013 at 08:11:56PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Introducing dgit - git integration with the
> Debian archive"):
> > I don't think "removing the automatic importer" is an improvement at all.
> I agree. Except that I wanted something I could deploy and use
> immediately. Providing an automatic importer would involve
> suddenly dumping the whole archive into alioth, which is not something
> I should do without consultation. (It looks like the alioth admins
> are very busy or away right now.)
> However, dgit's design certainly doesn't forbid having an automatic
> importer. Indeed there's a nice hole where the automatic importer
> would sit, and most of the code necessary is already present.
Right. Getting this going manually is an important first stepping stone on
the path; I just wanted to make sure we weren't stopping short of the real
goal.
If anything, the problems with the UDD automatic importer can be summarized
as: the importer is /not automatic enough/.
> > > And one is free to push pristine-tar (if makes sense/easy to
> > > generate), and/or any other branches into the repository (git-dpm,
> > > git-quilt, etc)
> > I would have expected dgit to support pristine-tar
> > directly/automatically/unconditionally. Any system that requires me to
> > download the same information (== the upstream source) both from a VCS
> > repository and the archive in order to get a fully-formed source package for
> > upload is a non-starter.
> I'm afraid you'll have to wait for dgit to be enhanced to treat
> .orig tarballs specially, then.
That's fine, I don't mind waiting, just as long as this is on the roadmap.
:-)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Introducing dgit - git integration with the Debian archive
On Sun, Aug 25, 2013 at 05:56:00PM +0100, Dmitrijs Ledkovs wrote: > >> In practice one doesn't actually care how far back the history goes, > >> as the history that is interesting is where developers get to do > >> intermediate commits between the two uploads to granulise the > >> changes > > I don't agree with this at all. I have regularly made use of the UDD > > branches to examine the history of packages (and not just the Ubuntu > > history, but also the Debian history). Being upload-level granularity > > makes it less useful than if it were at the granularity of a VCS branch > > being committed to natively by the developer, but it's still *very* > > useful for understanding the uploader's thought process at the time a > > change was made. > > The fact that git will allow us to graft the developer's own VCS on to > > these dgit repositories in a way that UDD never did is an important > > improvement, but as this is *optional*, not importing the package > > history from the archive would make dgit much less useful for the common > > case than UDD is today. > Ok. Given that we have snapshots.debian.org & graft points we can > create "import level" history in retrospect. Or perhaps it would be better to actually import into dgit directly from UDD? Since UDD has a more or less complete history of all packages in Debian, probably more extensive than even what we can assemble from snapshots.debian.org (thinking back to a snapshots hardware failure a few years ago). This won't get all the newer package history due to UDD importer failures, but it might be a good starting point. > But I find merging existing history more interesting: either upstream, > or existing git/svn packaging repositories. Absolutely; but that can only be done on a per-package basis, and will only happen for those packages where the maintainers are already bought into the model and are willing to do the work themselves. > Imho shared history with upstream projects is more interesting than > debian packaging upload history. Ideally one would have both =) Yes. This was always the ultimate target for UDD, the implementation just fell short of the ideal. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#720876: ITP: doxia-1.0 -- 1.0 alpha version of Doxia from codehaus
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: doxia-1.0 Version : 1.0~alpha-6 * URL : http://svn.apache.org/viewvc/maven/doxia/doxia/tags/ Programming Lang: Java Description : 1.0 alpha version of Doxia from codehaus Doxia from Codehaus moved to Apache about six years ago. I happen to have run into a reverse dependency that needs classes from the org.codehaus path, still. I'll upload to pkg-java's SVN repository at /trunk/doxia/1.0 but hope for some additional insights prior to uploading. -- 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/20130825212209.6027.13733.reportbug@Toshiba.siemens
Bug#720878: ITP: ngrok -- secure introspectable tunnels to localhost
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: ngrok Version : 0.17 Upstream Author : Alan Shreve * URL : https://ngrok.com/ * License : Apache-2.0 Programming Lang: Go Description : secure introspectable tunnels to localhost ngrok creates a tunnel from the public internet to a port on your local machine. You can give this URL to anyone to allow them to try out a web site you're developing without doing any deployment. It captures all traffic through the tunnel. It displays information about the HTTP traffic for your inspection. Raw request/response bytes, parsed headers and form data, JSON/XML syntax checking and more are included. It can also replay requests. By default, ngrok will use ngrok.com as a third-party relay. This service is provided at no-cost and without registration but it is possible to get additional features by signing up in the service (which is pay-as-you-want kind). However, it is possible to setup and use its own server. -- 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/20130825212724.17779.73676.report...@guybrush.luffy.cx
Re: Dreamhost dumps Debian
On 08/21/2013 05:45 PM, Kevin Chadwick wrote: > Large hosting companies not having made their scripts etc. good enough > to ride out upgrades well should have nothing to do with any decision. I don't think the problem here is with "Large hosting companies not having made their scripts etc. good enough". I don't think it has anything to do with size, or the type of company, or even the activity. I believe that the short life cycles of our stable releases is a problem for *MANY* companies. Dreamhost is the tree hiding the forest. On 08/21/2013 07:08 PM, Clint Byrum wrote: > It also doesn't hurt that OpenStack does all commit gating on Ubuntu, > thus making Ubuntu the preferred platform (RHEL/CentOS will likely > join Ubuntu in the gate someday soon). We asked Debian to be added. I hope that Debian will be added as a non-voting gating one day. I'll try to push for that to happen. > DreamHost is a player in > OpenStack, so it may be that the momentum of Ubuntu plus OpenStack is > just too great to ignore with the added pain of the 2 year upgrade > treadmill. > > I will ask them when I visit their offices at the next OpenStack LA > meetup. :) Well, yes. But also OpenStack release cycles are even shorter than Debian! Only a year, then the old stable is not supported anymore. It doesn't make sense that Dreamhost is complaining about 2 years of security support, when they are now in the "upgrade every 6 months" OpenStack stuff... If they join me and become supporters of a kind of "LTS" for OpenStack, that'd be great, and I would be very supportive of it. Thomas -- 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/521a9510.6060...@debian.org
Re: overriding udev rules
On 08/24/2013 03:53 PM, Ben Hutchings wrote: > There is a very clear standard that distinguishes globally and locally > administered addresses. > > While you would possibly to buy your own OUI and make global assignments > to your VMs, I seriously doubt you are doing that. Don't steal address > space. > > Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave "as if it was a virtual machine MAC address". Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. I'd say /etc/udev/udev.conf could be the correct place to configure this. If we want to keep the current behavior of double-guessing the use case of the network interface (which I recognize is the most useful case), then it could stay as default, as long as there is a reliable way to configure udev. Thomas Goirand (zigo) -- 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/521a91c1.7000...@debian.org
Re: Introducing dgit - git integration with the Debian archive
Steve Langasek wrote: > I would have expected dgit to support pristine-tar > directly/automatically/unconditionally. Any system that requires me to > download the same information (== the upstream source) both from a VCS > repository and the archive in order to get a fully-formed source package for > upload is a non-starter. AFAIK you don't actually need the bit-identical .orig.tar.gz to build the > -1 uploads of a package. You only need a tarball that contains the identical files as the .orig.tar.gz. Which can be generated from a tag or branch with the same contents. Perhaps dgit should arrange for that to be checked in automatically the same way it checks in the debinized source tree? (Having such a ref in git would be more or less a prerequisite for using pristine-tar in an efficient manner anyway.) -- see shy jo signature.asc Description: Digital signature
Re: Introducing dgit - git integration with the Debian archive
On Sunday, August 25, 2013 14:08:31 Steve Langasek wrote: > Or perhaps it would be better to actually import into dgit directly from > UDD? Since UDD has a more or less complete history of all packages in > Debian, probably more extensive than even what we can assemble from > snapshots.debian.org (thinking back to a snapshots hardware failure a few > years ago). This won't get all the newer package history due to UDD > importer failures, but it might be a good starting point. UDD (the Ubuntu one) is outside the trust boundary for the Debian project. I'm not sure how much effort would be saved once the repository contents were bounced against a trusted source for correctness. Scott K signature.asc Description: This is a digitally signed message part.
