headers
Charles Plessy | 1 Feb 02:16
Favicon

http://wiki.debian.org/debian/patches

Le Thu, Jan 31, 2008 at 11:52:28PM +0100, Andreas Tille a écrit :
> On Thu, 31 Jan 2008, Steve Langasek wrote:
> 
> >No, but I think it's a *bug* that this is not the common case.  If more
> >packages were maintained in distributed VCS, it would become practical to
> >consider publishing official "Debian" branches in an organized fashion,
> >keeping them synced with the maintainer's branch and letting NMUers push
> >their own changes to the Debian branch so that they're trivially mergeable
> >by the maintainer with full change history.
> 
> Well, I have no personal experience with other VCS than CVS and SVN
> but I see some sense behind your arguing and I'm perfectly willing
> to enhance my skills if I see some kind of master plan behind it
> to enhance Debian in general.

Good morning, afternoon or evening everybody,

In order to help the master plan to be prepared, I tryed to update the
summary of the discussion in the wiki:

http://wiki.debian.org/debian/patches

Of course, please feel free to rephrase, reorganise, complement and
alter the page.

Have a nice day,

--

-- 
Charles Plessy
http://charles.plessy.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leo "costela" Antunes | 1 Feb 02:38
Picon
Favicon

Automatic mirror selection

Hey there,

As an incredibly late follow-up to this [0] small thread, I created a
small script to act as backend for pdns and return a mirror for the
user's country.
It's a simple DNS based geographic mirror selection idea.

It works by:
- using logic based on D-I to select a mirror from a copy of
Mirrors.masterlist[1], making it behave like a user that selects his own
country during installation.
- filtering by country and arch, with a fallback host if the country
isn't found or no mirrors provide the needed arch.
- applying a _very_ simple priority scheme to the mirrors that match,
giving top points to hosts that match "ftp{1,2}.{2}.debian.org" and also
preferring "leaf" over "push" mirrors.

This last point is something I am still reluctant about: the logic was
"leafs will tend to be less loaded", but this is really not true;
perhaps some priority like "secondary > primary > leaf", to offload
primaries, but keep leafs as a last resort would be better.

I'd like to put this to use for Debian, but I face two small problems:
- I currently don't have access to any server in which I could host this.
- our d.net domains apparently[2] can't contain NS records, which means
I couldn't have anything more "integrated" without DSA's approval, even
if I had a machine.

So, which friendly soul could I ask about getting this running on a
Debian server with a d.net domain, assuming there's some interest in it
(Continue reading)

Permalink | Reply | 10 comments |
headers
David Nusinow | 1 Feb 02:42
Favicon

Re: How to cope with patches sanely

Hi buxy,

On Tue, Jan 29, 2008 at 07:44:13AM +0100, Raphael Hertzog wrote:
> I just need a clear concept that I can try to implement.
> 
> Some questions/problems:
> 
> 1/ it seems that we agree that patches should be applied by default
> during unpack of the source archive. This means that dpkg-source might
> want to know which patches are currently applied (or we could get strange
> results while building the package with patches unapplied)... do we use
> the same format than quilt for that (.pc directory AFAIK)?

My sense is that Ted nailed this one. The thing all the patch systems have
in common is that they have a stack of diffs and a file denoting the order
to apply them. There are variations on the theme (dbs lacks an explicit
series file, and dpatch uses its perverse scripts-as-diffs) but overall
it's consistent. I'd like to see this be the model for whatever dpkg uses.
The file is always kept in the same directory as the patches, so dpkg
should also expect this.

If you want to call the file "series", that'd be sufficient for immediate
quilt use because quilt will generate the .pc directory when used. For the
X packages we don't store the .pc file in the VCS, just the patches and
series file, and it works perfectly. If you name the file something other
than series, it can be symlinked and quilt will work fine.

 - David Nusinow
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Nusinow | 1 Feb 02:47
Favicon

Re: How to cope with patches sanely

On Tue, Jan 29, 2008 at 06:52:55PM +0100, sean finney wrote:
> i'd argue that's it's somewhat backwards to expect a patch management system 
> like dpatch or quilt to perform this task, and really it should be the 
> responsibility of the vcs or vcs-wrapper tools.

I agree entirely.

 - David Nusinow
Permalink | Reply | 0 comments |
headers
Christian Perrier | 1 Feb 06:44
Picon
Favicon
Gravatar

Re: Bug#463462: ITP: libsys-lastlog-perl -- Provides a moderately Object Oriented interface to lastlog

Quoting Jorge Salamero Sanz (bencer <at> cauterized.net):
> Package: wnpp
> Severity: wishlist
> Owner: Jorge Salamero Sanz <bencer <at> cauterized.net>
> X-Debbugs-CC: debian-devel <at> lists.debian.org
> 
>    Package name: libsys-lastlog-perl
>    Version: 1.5
>    Upstream Author: Jonathan Stowe <jns <at> gellyfish.com>
>    URL: http://search.cpan.org/dist/Sys-Lastlog/
>    License: Perl (GPL+Artistic)
>    Description: Provides a moderately Object Oriented interface to lastlog

"object-oriented interface for lastlog"

See DevRef 6.2.2 for a rationale of such changes
Permalink | Reply | 0 comments |
headers
wnpp | 1 Feb 08:26
Picon
Favicon

Work-needing packages report for Feb 1, 2008

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: 299 (new: 7)
Total number of packages offered up for adoption: 94 (new: 1)
Total number of packages requested help for: 36 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.

------------------------------------------------------------------------

The following packages have been orphaned:

   bmv (#462909), orphaned 4 days ago
     Description: PostScript viewer for SVGAlib
     Installations reported by Popcon: 111

   libgtk-perl (#462553), orphaned 6 days ago
     Description: Perl module for the gtk+ library
     Reverse Depends: dfontmgr glade-perl gtkgrepmail libgdk-pixbuf-perl
       libglade-perl libgladexml-perl libgnome-perl libgtk-imlib-perl
       libgtkglarea-perl libgtkxmhtml-perl
     Installations reported by Popcon: 3127

   libtlen (#463453), orphaned today
     Description: API for tlen.pl, an IM protocol based on Jabber
     Reverse Depends: libtlen1-dev tleenx2
     Installations reported by Popcon: 108
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raphael Hertzog | 1 Feb 09:13
Picon
Favicon
Gravatar

Re: How to cope with patches sanely

On Fri, 01 Feb 2008, Ben Finney wrote:
> Daniel Leidert <daniel.leidert.spam <at> gmx.net> writes:
> 
> > And people should check the VCS history just to get the current
> > "patch"?
> 
> What is "the current patch"? If you mean the entire set of differences
> against the upstream source, I already addressed that: simply generate
> a diff between the branches containing upstream source versus
> debian-packaged source.
> 
> As I pointed out, there are already tools that generate an entire
> Debian source package, including 'foo.orig.tar.gz' and 'foo.diff.gz',
> in a single step from a given VCS. Evidently what you ask for is
> possible, and already indeed implemented such that it is easy.
> 
> If you mean something else by "the current patch", please explain
> further.

Imagine an history like this:

- Change behaviour1
- Change behaviour2
- Bugfix in patch to change behaviour1
- Bugfix in patch to change behaviour2

You have two logical patches and a dumb export from the VCS into
debian/patches/ would give 4 patches when you really want only two.

In his own words, "current patch" is the "logical patch".
(Continue reading)

Permalink | Reply | 10 comments |
headers
Raphael Hertzog | 1 Feb 09:27
Picon
Favicon
Gravatar

Re: changing the default syslog daemon for lenny?

On Thu, 31 Jan 2008, Michael Biebl wrote:
> Should, I file a lenny release goal first and wait for it's approval, or  
> can I take this thread as consensus that I can pursue changing the  
> default system-log-daemon to rsyslog?

Go ahead and keep up the good work!

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 0 comments |
headers
Ben Finney | 1 Feb 09:35
Picon

Re: How to cope with patches sanely

Raphael, please follow the Debian Mailing List code of conduct
<URL:http://www.debian.org/MailingLists#codeofconduct>; in particular,
don't send individual copies of list messages unless specifically
requested.

Raphael Hertzog <hertzog <at> debian.org> writes:

> Imagine an history like this:
> 
> - Change behaviour1
> - Change behaviour2
> - Bugfix in patch to change behaviour1
> - Bugfix in patch to change behaviour2
> 
> You have two logical patches and a dumb export from the VCS into
> debian/patches/ would give 4 patches when you really want only two.

In a VCS with good merging support (most DVCSes fit this description,
Subversion does not), those "logical patches" can be maintained as
"feature branches".

Essentially, any set of changes that is more than "add this change and
let it be absorbed into the stream of changes" merits branching the
development tree to maintain that feature. Into that feature branch go
any commits that are related logically to the feature; anything else
goes into other branches.

Any time you want to find how feature-branch-A differs from the
development branch, that's a simple diff operation between the two
branches (optionally specifying which revision of each you're
(Continue reading)

Permalink | Reply | 9 comments |
headers
Josselin Mouette | 1 Feb 10:18
Picon
Favicon

Re: How to cope with patches sanely

Le jeudi 31 janvier 2008 à 11:28 -0800, Steve Langasek a écrit :
> This just isn't going to happen as long as svn dominates, because acls on
> centralized svn repos are just too coarse-grained.  Maintainers (including
> me) aren't going to want their package staging areas to be randomly
> scribbled on by developers they don't know, which is what opening up an svn
> tree to everyone with NMU rights would allow; so that's a conversation we
> can't even realistically have without the paradigm shift to DVCS.

Really? GNOME has been doing that for years, and I don’t think they are
drowning under unwanted commits by developers not following policies.

--

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
Permalink | Reply | 0 comments |

Gmane