On Fri, 19 Oct 2012 12:10:00 +0700
Ivan Shmakov wrote:
> I find somewhat unusual for the following packages to depend on
> gettext, given that the latter is a collection of utilities of
> interest primarily to software developers and maintainers (as
> stated in its own Des
On 19/10/2012 13:29, Steve Langasek wrote:
> On Thu, Oct 18, 2012 at 09:54:27PM -0700, Russ Allbery wrote:
>>> AIUI, most users of pristine-tar in git don't have the second of these
>>> branches, which means the pristine-tar binary delta is done against the
>>> upstream branch - so each pristine-ta
On Thu, Oct 18, 2012 at 09:54:27PM -0700, Russ Allbery wrote:
> > AIUI, most users of pristine-tar in git don't have the second of these
> > branches, which means the pristine-tar binary delta is done against the
> > upstream branch - so each pristine-tar blob contains all the information
> > about
I find somewhat unusual for the following packages to depend on
gettext, given that the latter is a collection of utilities of
interest primarily to software developers and maintainers (as
stated in its own Description:.) Could someone please clarify
on this
On 19/10/2012 12:54, Russ Allbery wrote:
> Delta compression should always take care of that, no matter how you
> organize your repository.
It only works if your things are bitwise similar in the first place. But does
pristine-tar's delta bear any semblance to the original copy of the file? If you
Russ Allbery writes:
> Steve Langasek writes:
>> And if your packaging branch actually tracks the full source package
>> contents, then it would have to track the autogenerated files, so you
>> might actually be storing these files twice.
> Delta compression should always take care of that, no
On Thu, Oct 18, 2012 at 9:19 PM, Christoph Anton Mitterer wrote:
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These a
Steve Langasek writes:
> The UDD branch model used in Launchpad has three branches (not counting
> the pristine-tar objects):
> - the upstream branch (as it exists upstream)
> - a synthesized branch which merges from the upstream branch and tracks
>the contents of the upstream tarball rele
On 19/10/2012 12:35, Steve Langasek wrote:
> On Thu, Oct 18, 2012 at 08:16:50PM -0700, Russ Allbery wrote:
>> Steve Langasek writes:
>
>>> The last time I complained about non-pristine-tar git package repos on
>>> IRC, I was told that pristine-tar doesn't scale. So apparently in git
>>> usage, f
On 19 October 2012 09:19, Christoph Anton Mitterer
wrote:
> 1) Programs (I usually mean apt or aptitude here don't give exit
> statuses != 0 in all cases when something critical has happened.
The apt-utils are mostly ok at aborting with non-zero for critical
errors. Aptitude is not.
> e.g. apt-
On Thu, Oct 18, 2012 at 08:16:50PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > The last time I complained about non-pristine-tar git package repos on
> > IRC, I was told that pristine-tar doesn't scale. So apparently in git
> > usage, folks haven't worked out that the unpacked upstre
Chow Loong Jin writes:
> On 19/10/2012 11:16, Russ Allbery wrote:
>> What did you mean by that last sentence? I was unable to parse it. In
>> particular, I think I don't understand the difference between "tracked
>> as a branch" and "track a pristine-tar delta against the upstream git
>> branch
On 19/10/2012 11:16, Russ Allbery wrote:
> Steve Langasek writes:
>
>> The last time I complained about non-pristine-tar git package repos on
>> IRC, I was told that pristine-tar doesn't scale. So apparently in git
>> usage, folks haven't worked out that the unpacked upstream source should
>> be
On Thu, 2012-10-18 at 21:30:25 -0500, Peter Samuelson wrote:
> [Joerg Jaspert]
> > As one thing to keep in mind - we have an acl structure in dak.
> > Currently it reads something like
> >
> > all DD keys are allowed all uploads.
> > all DM keys are allowed their own uploads according to DM rights
Peter Samuelson writes:
>> This preserves the ability to upload a manual binNMU, which is not
>> common, but is useful and sometimes necessary. (And not only for
>> bootstrapping an arch or a compiler.)
> ...and I forgot to add that something like this is required by the GR
> http://www.debian.
Steve Langasek writes:
> The last time I complained about non-pristine-tar git package repos on
> IRC, I was told that pristine-tar doesn't scale. So apparently in git
> usage, folks haven't worked out that the unpacked upstream source should
> be tracked as a branch instead of trying to track a
Christoph Anton Mitterer writes:
> And still sounds like a fork in a respect that forks usually don't
> change everything.
I think of a fork as a permanent division of the code base, with possibly
some importing of code back and forth but with major development happening
independently. While th
> This preserves the ability to upload a manual binNMU, which is not
> common, but is useful and sometimes necessary. (And not only for
> bootstrapping an arch or a compiler.)
...and I forgot to add that something like this is required by the GR
http://www.debian.org/vote/2007/vote_002, or at le
[Joerg Jaspert]
> As one thing to keep in mind - we have an acl structure in dak.
> Currently it reads something like
>
> all DD keys are allowed all uploads.
> all DM keys are allowed their own uploads according to DM rights.
> all buildd keys are allowed binary only uploads for their arch.
>
>
On Mon, 2012-10-15 at 13:46 -0400, Michael Gilbert wrote:
> Are there bug reports with a clear description of the problem,
> preferably with a proposed fix? Discussion doesn't really get us
> anywhere. Useful info and actual efforts at fixing problems do.
Well it's not that easy in that areas to
On Wed, 2012-10-17 at 17:43 +0200, Wouter Verhelst wrote:
> > Making opensource more open for proprietary stuff is sometimes simply
> > necessary... but this may ultimately also become a big threat for the
> > free software world, namely then when that non-free stuff plays such an
> > important rol
On Mon, 2012-10-15 at 08:11 +0200, Tollef Fog Heen wrote:
> Do you remember the sorry state of, for instance hotplugging of devices
> and the utterly poor integration with desktops back in 2004 when Ubuntu
> first started? It was a _huge_ step forward.
I didn't say everything was Ubuntu made or ma
On Sun, 2012-10-14 at 22:01 -0700, Russ Allbery wrote:
> Except it's not, because that's not what Ubuntu does. Most of the
> packages are imported into Ubuntu unmodified. Among those that are
> modified, most of the modifications are exactly the minor changes that
> Debian makes to upstream, and
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 472 (new: 1)
Total number of packages offered up for adoption: 137 (new: 1)
Total number of packages request
On Wed, Oct 17, 2012 at 12:57:18PM +0400, Игорь Пашев wrote:
> For git we have gitweb, gitolite, git-daemon, pristine-tar.
> I'd like to have similar for bzr, hg and svn.
There's nothing specific to git about pristine-tar. In fact, it is much
more consistently used with bzr due to the top-notch b
On Wed, Oct 17, 2012 at 2:56 AM, Joerg Jaspert wrote:
> On 13001 March 1977, Michael Gilbert wrote:
>
>> So, are we ready to do this?
>
> No.
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is being able to deal with arch
On Wed, Oct 17, 2012 at 10:22 PM, Matthew Grant wrote:
> On Wed, Oct 17, 2012 at 1:57 PM, Michael Gilbert
>> No. We're in the freeze now. Fixes need to be backported.
>
>
> If backporting a fix is not possible with the certainty of no introduced
> bugs, we have no choice.
>
> Debian Bind9 cannot
❦ 18 octobre 2012 11:29 CEST, Arno Töll :
> why don't we just let people decide themselves? We already grant every
> DD very liberal upload permissions to the archives because we trust them
> and their capabilities. Hence, I do not think we would like something
> like this despite of dak's suppo
Package: wnpp
Severity: wishlist
Owner: Joenio Costa
* Package name: libdist-zilla-localetextdomain-perl
Version : 0.81
Upstream Author : David E. Wheeler
* URL : http://search.cpan.org/dist/Dist-Zilla-LocaleTextDomain/
* License : Artistic or GPL-1+
Program
On Thu, 18 Oct 2012, Arno Töll wrote:
> On 18.10.2012 04:29, Paul Wise wrote:
> > On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
> >> We could have a lintian warning for any occurance of the string "/home" in
> >> a
> >> packaged file and have error conditions for "/build" and the current
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: python-geojson
Version : 1.0.1
Upstream Author : Sean Gillies
* URL : https://github.com/sgillies/geojson
* License : BSD
Programming La
Hi,
On 18.10.2012 10:50, Joerg Jaspert wrote:
> some DDs may upload $listofpackages including binaries.
> all DDs may upload $listofpackages including binaries.
>
> where listofpackages is those insane "needthemself" ones.
> And could be by DD.
>
> However far we want to drive this, we can.
why
Dmitrijs Ledkovs:
>>> loggerhead is replacement for gitweb
Tollef Fog Heen:
>> Yes, we «run» it, but it's memory-hungry, slow and crash-prone.
Dmitrijs Ledkovs:
> Yeah, I did end up using nginx & uwsgi workers to actually host it
> together with hosting bzr smart server as well.
If you'd c
On 18 October 2012 08:13, Игорь Пашев wrote:
> 2012/10/18 Dmitrijs Ledkovs :
>> bzr serve is the equivalent of git-daemon and it is builtin
>>
>> loggerhead is replacement for gitweb
>
> Last time I tried it, it seemed to support only one repository.
Maybe you didn't configure it right? Look on a
On 18 October 2012 07:27, Tollef Fog Heen wrote:
> ]] Dmitrijs Ledkovs
>
>> loggerhead is replacement for gitweb
>
> As one of the alioth admins, I'd like to contest this statement.
>
> loggerhead is a replacement for gitweb in the same way that crawling is
> a replacement for sprinting.
>
> Yes,
> So yes, this is something that should be accounted for if Debian moves to a
> model where binary uploads are discarded and rebuilt. However, I suspect
> that for all the sensible cases, the proposal to add staged-build metadata
> (for bootstrapping circular build-dependencies on new ports) woul
Hi,
On 18.10.2012 04:29, Paul Wise wrote:
> On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
>
>> We could have a lintian warning for any occurance of the string "/home" in a
>> packaged file and have error conditions for "/build" and the current value of
>> $HOME for the account running li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list. The bugs that put them on this list
can be found in the removals file (also at
On 17-10-12 23:48, Matthias Klose wrote:
> On 17.10.2012 21:49, Steve Langasek wrote:
>> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
>>> Also remeber, there are packages like cmucl that can only be built by the
>>> same upstream release of itself and can currently survive in De
2012/10/18 Dmitrijs Ledkovs :
> bzr serve is the equivalent of git-daemon and it is builtin
>
> loggerhead is replacement for gitweb
Last time I tried it, it seemed to support only one repository.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
40 matches
Mail list logo
