Re: How to cope with patches sanely

[Raphael Hertzog]

On Fri, 01 Feb 2008, Ben Finney wrote:
> Daniel Leidert <[EMAIL PROTECTED]> 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".

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: changing the default syslog daemon for lenny?

[Raphael Hertzog]

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Ben Finney]

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

Raphael Hertzog <[EMAIL PROTECTED]> 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
interested in comparing). Merges between the two will show up as
single revisions in each branch, so the changes in feature-branch-A
will show exactly the history of feature A.

Any time the changes in feature-branch-A are at a point where they
need to be included in the main development branch, simply merge them
in.

The important thing that enables this workflow is *easy merging*
between arbitrary branches that share a common ancestor. Again, this
rules CVS and Subversion out. (Some, like git, allow merging
*anywhere*, but that's not necessary for this to work well.)

-- 
 \ "I have had a perfectly wonderful evening, but this wasn't it." |
  `\   -- Groucho Marx |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Josselin Mouette]

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.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: How to cope with patches sanely

[Raphael Hertzog]

On Fri, 01 Feb 2008, Ben Finney wrote:
> Raphael, please follow the Debian Mailing List code of conduct
> http://www.debian.org/MailingLists#codeofconduct>; in particular,
> don't send individual copies of list messages unless specifically
> requested.

If you were using mutt and a right configuration, you would have
an appropriate Mail-Followup-To and those mistakes wouldn't happen... (I
so hate those discussions and remarks about code of conduct for one copy
more of a mail).

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

Thank you, I know a DVCS can be used. However it's not that easy, one
feature branch might rely on another one and then you have to keep that
ancestry information to be able to generate the diffs properly (and in the
right order).

And as explained somewhere else in this thread, this doesn't scale very
well with dozens of patches.

With git I'd use a "debian-patches" branch that I would rebase on the
upstream branch regularly and would edit history of changes as needed so
that one commit generates one file in debian/patches/.

Anyway, I didn't want to discuss this, but just point out what Daniel was
saying. 

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Josselin Mouette]

Le vendredi 01 février 2008 à 10:45 +0100, Raphael Hertzog a écrit :
> If you were using mutt and a right configuration, you would have
> an appropriate Mail-Followup-To and those mistakes wouldn't happen...

Mail-Followup-To is not a standard of any kind. Only a handful of
mailers understand it and I don’t think this is going to change.

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


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Automatic mirror selection

[Adam Borowski]

On Fri, Feb 01, 2008 at 02:38:04AM +0100, Leo costela Antunes wrote:
> 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.

Hell yeah.  Finally.

We got plenty of packages which pull debs from their author's country:
ftp.pl.debian.org, ftp.uk.debian.org.  It would be helluva better to have
them use geoip by default.

I once gave this a though, but never went any farther than checking which
mirrors work.  The status page is still online:
http://angband.pl/deb/mirrors
although it doesn't even update the mirror list.  There are better such
status pages elsewhere, too, except none checks IPv4 and IPv6 separately.

> 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.

Since the packaged version of geoip gives you just the country, my idea
would be to simply give a cname for ftp.XX.debian.org.  On MaxMind's page,
you can also get a "geoip-city-lite" database which appears to be dfsg free
once you purge nondistributable parts about ISPs (city and ISP data is
intermingled in a single file).  That could perhaps provide some better
resolution than just country.

> - filtering by country and arch, with a fallback host if the country
> isn't found or no mirrors provide the needed arch.

Uhm, and how exactly do you get the arch?  At DNS time you don't have
anything but the requester's or his ISP's IP.

> 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.

Would a vserver, one IP and a NS delegation for a test subdomain be enough
for your tests?  No fallover or anything, though.

> - 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.

What about this:
  ftptest.debian.net CNAME debian.XXX
  debian.XXX NS your_vserver.XXX
(where XXX is any domain you can control without bothering the DSA for every
change)

> 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
> aside from my own? The DSA through a ticket?

This would be a great addition to the official infrastructure.  If this goes
official, it would need some reliable hosting, but for tests, you can use
any machine, even one of mine.

> Please fire away if you have any comments on the idea, but keep in mind
> it's not intended to supplant anything we currently have and it's
> obviously not intended for every scenario.

To the contrary, with the name "ftp.debian.org" being deprecated, I can
think of a perfect case you can supplant once you go official :p


Great work, carry on!

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Lars Wirzenius]

On pe, 2008-02-01 at 01:45 +0900, Charles Plessy wrote:
> Hi Lars, I do not get your point.
> 
> If you are concerned that the persons who sent you a package to sponsor
> have put malicious code in it, what I guess you will first review is
> wether the scripts you have to execute to test the packages are safe.

At the moment, I can unpack a source package and then review it before I
run anything. You propose to make things more complicated by having to
review things before unpacking. I find that to be an unwanted,
unnecessary, and _dangerous_ complication.

> Shall we conclude that the idea of
> automatically applying the patches when the sources are unpacked is
> ruled out by the complexity and the side-effect security issues that it
> would create ?

That is a highly premature conclusion. We can create ways in which
patches are applied by dpkg-source directly, for example, instead of
having to run code from the package. That's the point of my
participation in this sub-thread: to stop the _wrong_ way of
implementing this.

See David Nusinow's e-mail[1] as an example of an outline for how this
can be done sanely. (He refers to Ted Tso's e-mail, and I think it's
[2].)

[1] http://lists.debian.org/debian-devel/2008/02/msg3.html
[2] http://lists.debian.org/debian-devel/2008/01/msg01008.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Ben Finney]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> On Fri, 01 Feb 2008, Ben Finney wrote:
> > Raphael, please follow the Debian Mailing List code of conduct
> > http://www.debian.org/MailingLists#codeofconduct>; in
> > particular, don't send individual copies of list messages unless
> > specifically requested.
> 
> If you were using mutt [...]

I'm not. Please follow the code of conduct regardless.

-- 
 \ "For of those to whom much is given, much is required."  -- |
  `\   John F. Kennedy |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be Include InDebian Distribution

[maximilian attems]

Dear May,

On Mon, 28 Jan 2008, May Hwang wrote:

> Dear Margarita,
> 
> Thanks, please help include our driver in etch-n-half.
> 
> Please find Latest HighPoint Source files in 2.6.24 are located at:
> drivers\scsi\hptiop.c
> drivers\scsi\hptiop.h
> Documentation\scsi\hptiop.txt
> 
> 2.6.24-rc8-mm1 built-in it, you can get it from www.kernel.org.

as linus already merged the driver update.
just commited the patch from latest git into our tree for the
2.6.24 etch+half update kernel:
http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2008-February/009187.html

> FYI, HighPoint do have validation program with most of main vendors in the
> market- Seagate, Western Digital, Hitachi, Supermicro, Tyan, Asus,
> clustersoftware vendor, Storage software vendors, AIC, CI-design and etc. 
> 
> In regards of source package guideline, I will check with my firmware group
> if they have any questions.
> 
> Thanks for the quick response!

thanks for bringing the issue to our attention.
 
> Best Regards,
>  
> May Hwang
>  
> HighPoint Technologies,Inc.
>  
> Tel:408-240-6118/6112
> Fax-408-942-5800
>  
> www.highpoint-tech.com
> www.hptmac.com
>  
> Distribution Partners: ASI, BellMicro, D&H, Malabs
> "RocketRAID - Terabyte Storage Technologies"

for more information about the debian kernel see
http://wiki.debian.org/DebianKernel
(commit list, team, general docs, ..)

it would be cool if you would test tomorrows sid snapshot builds?
see aboves for the apt lines.


best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Fathi BOUDRA]

> * Package name: latencytop
>   Version : 0.3
>   Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
> * URL : http://www.latencytop.org/
> * License : GPL-2
>   Description : A tool for developers to visualize system latencies
>
> LatencyTOP is a Linux tool for software developers (both kernel and
> userspace), aimed at identifying where system latency occurs, and what
> kind of operation/action is causing the latency to happen. By identifying
> this, developers can then change the code to avoid the worst latency
> hiccups.

short description: tool for developers to visualize system latencies

See Developers Reference, 6.2.2

cheers,

Fathi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Daniel Leidert]

Am Freitag, den 01.02.2008, 08:25 +1100 schrieb Ben Finney:
> Daniel Leidert <[EMAIL PROTECTED]> writes:
> 
> > And people should check the VCS history just to get the current
> > "patch"?
> 
> What is "the current patch"?

The current specific/logical patch for one issue.

> 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.

I did not refer to generate the .diff.gz. I know, this can easily be
done by diff-ing two branches.

What I mean is: Say you have addressed 5 different issues in the code. I
still think it is easier to understand, if 5 separate patches are
provided instead of one. And tracking each of them be checking commits
for the initial fix and changes done later to update the fix is IMHO not
as easy as simply providing a separate patch. As long as you maintain
the package alone, you probably do not have advantages of using separate
patches. But say e.g. a co-maintainer offers help or you do
collaborative maintenance in general. Then I think, it is much easier to
separate fixes into logical patches. And IMHO this cannot be done by
just using "good" commit messages.

> 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.

What I ask for is already possible and implemented: quilt and dpatch
exist. But I cannot agree to your opinion, that "[..] commits [..] at
the same level of granularity (or finer) [..]" offer the same
functionality and advantages. This is IMO not a valuable replacement for
separated patches, because of the reasons I tried to point out in my
last mail.

I read your answer to Raphael, where you point to so called "feature
branches". This leads to the question, if people should be forced to use
a special VCS (which is already discussed somewhere else in the thread),
whereas creating Debian packages never relayed on the usage of a VCS.

To be honest, your workflow is different to mine. I would need to
examine your way and compare it to mine. All I can say is, that I'm
pretty satisfied with my workflow and I'm sure, you claim the same for
your solution.

> If you mean something else by "the current patch", please explain
> further.

HTH
Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Hendrik Sattler]

Quoting Fathi BOUDRA <[EMAIL PROTECTED]>:


* Package name: latencytop
  Version : 0.3
  Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
* URL : http://www.latencytop.org/
* License : GPL-2
  Description : A tool for developers to visualize system latencies

LatencyTOP is a Linux tool for software developers (both kernel and
userspace), aimed at identifying where system latency occurs, and what
kind of operation/action is causing the latency to happen. By identifying
this, developers can then change the code to avoid the worst latency
hiccups.


short description: tool for developers to visualize system latencies


Or just "visualize system latencies".

HS





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Kumar Appaiah]

On 01/02/2008, Raphael Hertzog wrote:
> With git I'd use a "debian-patches" branch that I would rebase on the
> upstream branch regularly and would edit history of changes as needed so
> that one commit generates one file in debian/patches/.

Dear Raphael,

Is this what you mean?

- Have a branch upstream, and upstream-patched
- Make upstream stay in sync with the upstream tarball. Merge it with
debian-patches
- Use the differences between these branches to generate
debian/patches, which can be wrapped around
quilt/dpatch/simple-patchsys?

Thanks.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[May Hwang]

Dear Maks,

Thanks for the update. So this etch-n-half is the next Debian release, which
already have HighPoint driver included? When etch-n-half will official hit
the market?  

Best Regards,
 
May Hwang
 
HighPoint Technologies,Inc.
 
Tel:408-240-6118/6112
Fax-408-942-5800
 


-Original Message-
From: maximilian attems [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 01, 2008 7:04 AM
To: May Hwang
Cc: 'Wouter Verhelst'; 'Margarita Manterola';
[EMAIL PROTECTED]; debian-devel@lists.debian.org
Subject: Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian
Distribution

Dear May,

On Mon, 28 Jan 2008, May Hwang wrote:

> Dear Margarita,
> 
> Thanks, please help include our driver in etch-n-half.
> 
> Please find Latest HighPoint Source files in 2.6.24 are located at:
> drivers\scsi\hptiop.c
> drivers\scsi\hptiop.h
> Documentation\scsi\hptiop.txt
> 
> 2.6.24-rc8-mm1 built-in it, you can get it from www.kernel.org.

as linus already merged the driver update.
just commited the patch from latest git into our tree for the
2.6.24 etch+half update kernel:
http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2008-February/00
9187.html

> FYI, HighPoint do have validation program with most of main vendors in the
> market- Seagate, Western Digital, Hitachi, Supermicro, Tyan, Asus,
> clustersoftware vendor, Storage software vendors, AIC, CI-design and etc. 
> 
> In regards of source package guideline, I will check with my firmware
group
> if they have any questions.
> 
> Thanks for the quick response!

thanks for bringing the issue to our attention.
 
> Best Regards,
>  
> May Hwang
>  
> HighPoint Technologies,Inc.
>  
> Tel:408-240-6118/6112
> Fax-408-942-5800
>  
> www.highpoint-tech.com
> www.hptmac.com
>  
> Distribution Partners: ASI, BellMicro, D&H, Malabs
> "RocketRAID - Terabyte Storage Technologies"

for more information about the debian kernel see
http://wiki.debian.org/DebianKernel
(commit list, team, general docs, ..)

it would be cool if you would test tomorrows sid snapshot builds?
see aboves for the apt lines.


best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be Include InDebian Distribution

[maximilian attems]

On Mon, 28 Jan 2008, May Hwang wrote:

> 
> Thanks, please help include our driver in etch-n-half.
> 

forgot to mention that your posting gave you good german tech press
-> http://www.heise.de/newsticker/meldung/102841


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Christian Perrier]

Quoting Fathi BOUDRA ([EMAIL PROTECTED]):
> > * Package name: latencytop
> >   Version : 0.3
> >   Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
> > * URL : http://www.latencytop.org/
> > * License : GPL-2
> >   Description : A tool for developers to visualize system latencies
> >
> > LatencyTOP is a Linux tool for software developers (both kernel and
> > userspace), aimed at identifying where system latency occurs, and what
> > kind of operation/action is causing the latency to happen. By identifying
> > this, developers can then change the code to avoid the worst latency
> > hiccups.
> 
> short description: tool for developers to visualize system latencies


I'd even suggest:

system latencies visualization tool

"for developers" does not seem really relevant here.



signature.asc
Description: Digital signature

Re: Bug#463584: ITP: rubyripper -- an open-source secure ripper for Linux

[Christian Perrier]

Quoting Carlos Laviola ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Carlos Laviola <[EMAIL PROTECTED]>
> 
> * Package name: rubyripper
>   Version : 0.5.0
>   Upstream Author : Bouke Woudstra <[EMAIL PROTECTED]>
> * URL : http://code.google.com/p/rubyripper/
> * License : GPL v3
>   Programming Lang: Ruby
>   Description : an open-source secure audio ripper


"open source" is not really relevant here

"secure audio ripper" seems to better fit the recommended writing
style (DevRef 6.2.2)



signature.asc
Description: Digital signature

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[maximilian attems]

On Fri, Feb 01, 2008 at 06:29:48PM +0100, Josselin Mouette wrote:
> Le vendredi 01 février 2008 à 07:38 -0800, May Hwang a écrit :
> > Dear Maks,
> > 
> > Thanks for the update. So this etch-n-half is the next Debian release, which
> > already have HighPoint driver included? When etch-n-half will official hit
> > the market?  
> 
> This release will include whatever has been included in the upstream
> kernel at version 2.6.24. AIUI, if your driver has been included only in
> the 2.6.25 branch, it will probably not be included.

indeed 2.6.24 Debian deviates only slightly from upstream,
some added patches, GPL enforcement, but we always consider driver
backports to our stable kernel and have a history to do such.

also joss is not a member of the etch+half pushing teams
aka the debian kernel, installer and security teams.

so be assured that your latest driver landed.
i haven't heard yet from you May that you would test our
tomorrows snapshot sid builds next week?

bon weekend again

-- 
maks
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#463597: ITP: libdb4.6-ruby -- Interface to Berkeley DB 4.6 for Ruby

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: libdb4.6-ruby
  Version : 0.6.2
  Upstream Author : Guy Decoux <[EMAIL PROTECTED]>
* URL : http://moulon.inra.fr/ruby/bdb.html
* License : Ruby's
  Programming Lang: C, Ruby
  Description : Interface to Berkeley DB 4.6 for Ruby

BDB is an interface to Berkeley DB, distributed by Sleepycat
(http://www.sleepycat.com/).  This package provides BDB for Ruby 1.8
linked to libdb4.6.

Ruby's License: http://www.ruby-lang.org/en/LICENSE.txt

- -- System Information:
Debian Release: lenny/sid
  APT prefers gutsy-updates
  APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHo1vCHajaM93NaGoRAlMFAJ9xfw35iNpy7MGf3jKLgRevP2H54QCgitoQ
URypVMCBCxZURerbS6Q0XpM=
=OjuT
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#463584: ITP: rubyripper -- an open-source secure ripper for Linux

[Carlos Laviola]

Package: wnpp
Severity: wishlist
Owner: Carlos Laviola <[EMAIL PROTECTED]>

* Package name: rubyripper
  Version : 0.5.0
  Upstream Author : Bouke Woudstra <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/rubyripper/
* License : GPL v3
  Programming Lang: Ruby
  Description : an open-source secure audio ripper

Rubyripper uses cdparanoia in a sophisticated way to make sure that
a CD rip is done successfully and accurately. Through multiple rips
and byte comparison, rubyripper aims to correct and inform the user
about any differences that would otherwise go unnoticed. It is very
similar to and inspired by EAC.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Leo "costela" Antunes]

Adam Borowski wrote:
> you can also get a "geoip-city-lite" database which appears to be dfsg free
> once you purge nondistributable parts about ISPs (city and ISP data is
> intermingled in a single file).  That could perhaps provide some better
> resolution than just country.

I thougth about this too, but we don't currently have reliable city
information for the mirrors, so it would demand more work and wouldn't
bring big benefits, since it's already not certain that the user's
country's mirror will actually be any faster than an inter-country link,
I decided that going for a country based approach was the best
middle-ground bet. We'd have even less certainty about the user's city's
mirror performance.

> Uhm, and how exactly do you get the arch?  At DNS time you don't have
> anything but the requester's or his ISP's IP.

This would have to be placed inside sources.list at some point, then I
figure the automatic or manual process responsible should stick
"dpkg-architecture -qDEB_BUILD_ARCH" somewhere in there, so you just
have to query ".geomirror.d.net", for instance, to get the best
mirror for your country which contains your arch.
It could be during D-I, if the D-I people like the idea and no big
problems arise from a testing period.

> Would a vserver, one IP and a NS delegation for a test subdomain be enough
> for your tests?  No fallover or anything, though.

Yes, certainly. Do you have one available?
The only needed things are:
- pdns-backend-pipe
- libgeo-ip-perl


> What about this:
>   ftptest.debian.net CNAME debian.XXX
>   debian.XXX NS your_vserver.XXX
> (where XXX is any domain you can control without bothering the DSA for every
> change)

I don't think that'll work. Since the Debian nameserver won't find a
break in the SOA line (introduced with a NS entry), it'll try to find
YYY.ftptest.d.net directly. A CNAME entry on an upper-level domain won't
be enough to "redirect" the lower-level domains.
But I'm no DNS specialist, so if you (or anyone) have a more specific
way of making this work, I'm all ears!



Thanks for the feedback!

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Frans Pop]

(CCing the BR.)

On Friday 01 February 2008, Mike Hommey wrote:
> On Fri, Feb 01, 2008 at 08:17:11PM +0100, Frans Pop wrote:
> > > * Package name: latencytop
> > >   Version : 0.3
> > >   Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
> > > * URL : http://www.latencytop.org/
> > > * License : GPL-2
> > >   Description : A tool for developers to visualize system
> > > latencies
> > >
> > > LatencyTOP is a Linux tool for software developers (both kernel and
> > > userspace), aimed at identifying where system latency occurs, and
> > > what kind of operation/action is causing the latency to happen. By
> > > identifying this, developers can then change the code to avoid the
> > > worst latency hiccups.
> >
> > I wonder if this tool should be packaged separately, or if it would be
> > more logical to just package it together with powertop. After all, they
> > are fairly similar in purpose and have the same upstream author.
>
> I wonder if this tool will ben any useful, considering it requires a
> patched kernel.

Patches have already been included in 2.6.25, so it may require enabling an 
kernel config option, but will not require patching the kernel.


signature.asc
Description: This is a digitally signed message part.

Re: changing the default syslog daemon for lenny?

[Guillem Jover]

On Thu, 2008-01-31 at 05:30:47 +0100, Michael Biebl wrote:
> Guillem Jover wrote:
> > On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> > > For 12.) and 28.), I'd file a wishlist bug providing a config file
> > > snippet for /etc/rsyslog.d/
> >
> > Can we please use /etc/syslog.d/ instead? this way we don't get locked
> > in any specific implementation. I'm preparing a patch for
> > inetutils-syslogd to support that, and it might also make sense to
> > require all system-log-daemon providers to support that dir as well.
>
> I'd rather not do that. There is no common config file format, that all  
> sylog daemons understand. E.g. you can't mix syslog-ng configuration  
> with metalog or rsyslog. The additional functionality of rsyslog is  
> implemented via special directives, which other syslog daemons won't  
> understand. So, I don't think this is a good idea.

I've just checked a bit and sysklogd, inetutils-syslogd and rsyslog
understand the standard syslog.conf format. rsyslog has additional
directives, but IMO those should not be used by third party packages
that would drop config snippets under /etc/syslog.d/. rsyslog could of
course read configs from syslog.d and rsyslog.d, and admins could
install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
use of those additional features.

The only daemons not understanding the standard format are syslog-ng,
socklog, and metalog (which is not even on the distro).

My concern is making packages explicitely dependant on rsyslog, when
they could be generic, making it difficult for admins to switch
syslogd and also any future transition to another syslogd.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Mike Hommey]

On Fri, Feb 01, 2008 at 08:17:11PM +0100, Frans Pop wrote:
> > * Package name: latencytop
> >   Version : 0.3
> >   Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
> > * URL : http://www.latencytop.org/
> > * License : GPL-2
> >   Description : A tool for developers to visualize system latencies
> >
> > LatencyTOP is a Linux tool for software developers (both kernel and
> > userspace), aimed at identifying where system latency occurs, and what
> > kind of operation/action is causing the latency to happen. By identifying
> > this, developers can then change the code to avoid the worst latency
> > hiccups.
> 
> I wonder if this tool should be packaged separately, or if it would be
> more logical to just package it together with powertop. After all, they
> are fairly similar in purpose and have the same upstream author.

I wonder if this tool will ben any useful, considering it requires a
patched kernel.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

On Fri, Feb 01, 2008 at 09:48:42AM -0800, May Hwang wrote:
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=tree;f=dr
> ivers/scsi;h=03a18a7adc45ab39658ac83cf90e56e43598ee3e;hb=HEAD.

i know if you followed the link to the kernel svn change,
you would have seen that the commit was directly taken out of git.
 
> Meanwhile, I really would like to know more about the "back porting" our GPL
> driver into current stable Debian distribution?
> 
> I'm sorry, What is snapshot sid builds?  

please read the docs you are pointed to
-> wiki.debian.org/DebianKernel
there you have the sid daily builds,
it would be really appreciated that you test boot
such a kernel and show us dmesg.

 
weekend starting, best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Steve Langasek]

On Fri, Feb 01, 2008 at 08:13:38PM +0100, Christian Perrier wrote:
> > > LatencyTOP is a Linux tool for software developers (both kernel and
> > > userspace), aimed at identifying where system latency occurs, and what
> > > kind of operation/action is causing the latency to happen. By identifying
> > > this, developers can then change the code to avoid the worst latency
> > > hiccups.

> > short description: tool for developers to visualize system latencies

> I'd even suggest:

> system latencies visualization tool

This doesn't scan right to me.  "system latency visualization tool" would be
ok, but I think "tool for system latency visualization" or "tool for
visualizing system latencies" would be better.

> "for developers" does not seem really relevant here.

If it's a tool targeted at developers, I don't think it's inappropriate to
mention in the short description (space allowing).

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies

[Frans Pop]

> * Package name: latencytop
>   Version : 0.3
>   Upstream Author : Arjan van de Ven <[EMAIL PROTECTED]>
> * URL : http://www.latencytop.org/
> * License : GPL-2
>   Description : A tool for developers to visualize system latencies
>
> LatencyTOP is a Linux tool for software developers (both kernel and
> userspace), aimed at identifying where system latency occurs, and what
> kind of operation/action is causing the latency to happen. By identifying
> this, developers can then change the code to avoid the worst latency
> hiccups.

I wonder if this tool should be packaged separately, or if it would be
more logical to just package it together with powertop. After all, they
are fairly similar in purpose and have the same upstream author.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[May Hwang]

Dear Maks,

Thanks! Is this the first time you head about HighPoint? We used to only
offer Cost effective RAID controller or if refer to Linux community these
are the Fake RAID category. 

My SI customer suggest we should educate Linux distributions or ask advice
from Linux distribution developer where can we update our hardware RAID
product information, it kind of letting Linux community knows HighPoint
products now its GPL licensed and it is hardware RAID controller.

Any ideas?


Best Regards,
 
May Hwang
 
HighPoint Technologies,Inc.
 
Tel:408-240-6118/6112
Fax-408-942-5800
 
www.highpoint-tech.com
www.hptmac.com
 
Distribution Partners: ASI, BellMicro, D&H, Malabs
"RocketRAID - Terabyte Storage Technologies"


-Original Message-
From: 'maximilian attems' [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 01, 2008 8:17 AM
To: May Hwang
Cc: 'Wouter Verhelst'; 'Margarita Manterola';
[EMAIL PROTECTED]; debian-devel@lists.debian.org
Subject: Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian
Distribution

Hello May!

On Fri, Feb 01, 2008 at 07:38:03AM -0800, May Hwang wrote:
> 
> Thanks for the update. So this etch-n-half is the next Debian release,
which
> already have HighPoint driver included? When etch-n-half will official hit
> the market?  

etch-n-half is the planed Linux kernel upgrade for the Etch Debian
distribution, roughly after 1/2 of it's lifetime, for more info on it
see http://wiki.debian.org/EtchAndAHalf

there is no hard date out yet, but you get an educated guess from
http://lists.debian.org/debian-kernel/2008/01/msg00217.html
http://lists.debian.org/debian-kernel/2008/01/msg00697.html
(due to beta1 debian-installer and etch+half coupling)
 
> Best Regards,
>  
> May Hwang

happy weekend.


-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[May Hwang]

Dear Mak,

I have communicated your suggestion to corresponding departments, we will
update our FAQ and check out dell idea storm cite as well.

Thanks for being so helpful for HighPoint, appreciated everyone's valuable
advice.

Best Regards,
 
May Hwang
 
HighPoint Technologies,Inc.
 
Tel:408-240-6118/6112
Fax-408-942-5800
 
www.highpoint-tech.com
www.hptmac.com
 
Distribution Partners: ASI, BellMicro, D&H, Malabs
"RocketRAID - Terabyte Storage Technologies"


-Original Message-
From: 'maximilian attems' [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 01, 2008 8:48 AM
To: May Hwang
Cc: 'Wouter Verhelst'; 'Margarita Manterola';
[EMAIL PROTECTED]; debian-devel@lists.debian.org
Subject: Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian
Distribution

hello May,

On Fri, Feb 01, 2008 at 08:31:29AM -0800, May Hwang wrote:
> 
> Thanks! Is this the first time you head about HighPoint? We used to only
> offer Cost effective RAID controller or if refer to Linux community these
> are the Fake RAID category. 

not the first time,
i had followed the hptiop submission upstream for the 2.6.18 time
frame, but yes i haven't encountered the hardware directly.
 
> My SI customer suggest we should educate Linux distributions or ask advice
> from Linux distribution developer where can we update our hardware RAID
> product information, it kind of letting Linux community knows HighPoint
> products now its GPL licensed and it is hardware RAID controller.
> 
> Any ideas?

you seem to have already generated quite some good press on the most
important German tech press.

dell has a community centre where customers can generated input,
try to consider such. the dell idea storm cite generated quite
some participation also people where very happy that they got
listened to so new laptop models coming out with Linux.

otherwise a tech show off of the capabilities of your product
in terms of performance benchmarks, power efficiency (powertop)

your worst defficiency currently seems that a quick top ten
google of "highpoint gpl" doesn't direct me anywhere near to
a cool site of yours. also "highpoint linux" lands on a faq
as top one that is quite terse.

hope that helps.
 
> Best Regards,
>  
> May Hwang

good success + warm greetings of cold vienna

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463597: ITP: libdb4.6-ruby -- Interface to Berkeley DB 4.6 for Ruby

[Christian Perrier]

Quoting Scott Kitterman ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Scott Kitterman <[EMAIL PROTECTED]>
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> * Package name: libdb4.6-ruby
>   Version : 0.6.2
>   Upstream Author : Guy Decoux <[EMAIL PROTECTED]>
> * URL : http://moulon.inra.fr/ruby/bdb.html
> * License : Ruby's
>   Programming Lang: C, Ruby
>   Description : Interface to Berkeley DB 4.6 for Ruby


I suggets not capitalizing "interface". The leading word of synopsis
should not be capitalized except for project names or acronyms.

Hence: "interface to Berkeley DB 4.6 for Ruby"

alternative: "Berkeley DB 4.6 Ruby interface"



signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Raphael Hertzog]

Hi,

On Fri, 01 Feb 2008, Kumar Appaiah wrote:
> On 01/02/2008, Raphael Hertzog wrote:
> > With git I'd use a "debian-patches" branch that I would rebase on the
> > upstream branch regularly and would edit history of changes as needed so
> > that one commit generates one file in debian/patches/.
> 
> Dear Raphael,
> 
> Is this what you mean?
> 
> - Have a branch upstream, and upstream-patched
> - Make upstream stay in sync with the upstream tarball. Merge it with
> debian-patches

No, I said "rebase" and not merge. 
See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

(Note that this means that nobody should derive from upstream-patched as
the branch is regularly rewritten and one can't branch and later merge
from it)

> - Use the differences between these branches to generate
> debian/patches

Yes. git rev-list upstream..upstream-patched would give a list of commit
to use to generate the debian/patches/

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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[Josselin Mouette]

Le vendredi 01 février 2008 à 07:38 -0800, May Hwang a écrit :
> Dear Maks,
> 
> Thanks for the update. So this etch-n-half is the next Debian release, which
> already have HighPoint driver included? When etch-n-half will official hit
> the market?  

This release will include whatever has been included in the upstream
kernel at version 2.6.24. AIUI, if your driver has been included only in
the 2.6.25 branch, it will probably not be included.

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


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: wnpp.debian.net sources released, security review wanted, plans for the future

[Holger Levsen]

Hi,

On Wednesday 30 January 2008 18:00, Sebastian Pipping wrote:
> > What do you think about that lucas? Why only a redirect in the first
> > place?
> > 1. http://people.debian.org/~nion/net-domains.html
> Lucas offered that to me but the host the site runs
> on cannot handle a new IP for free.

It doesnt need a new IP. Just point wnpp.d.n to the current IP of your server.


regards,
Holger


pgpDlxpIFzkKF.pgp
Description: PGP signature

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

hello May,

On Fri, Feb 01, 2008 at 08:31:29AM -0800, May Hwang wrote:
> 
> Thanks! Is this the first time you head about HighPoint? We used to only
> offer Cost effective RAID controller or if refer to Linux community these
> are the Fake RAID category. 

not the first time,
i had followed the hptiop submission upstream for the 2.6.18 time
frame, but yes i haven't encountered the hardware directly.
 
> My SI customer suggest we should educate Linux distributions or ask advice
> from Linux distribution developer where can we update our hardware RAID
> product information, it kind of letting Linux community knows HighPoint
> products now its GPL licensed and it is hardware RAID controller.
> 
> Any ideas?

you seem to have already generated quite some good press on the most
important German tech press.

dell has a community centre where customers can generated input,
try to consider such. the dell idea storm cite generated quite
some participation also people where very happy that they got
listened to so new laptop models coming out with Linux.

otherwise a tech show off of the capabilities of your product
in terms of performance benchmarks, power efficiency (powertop)

your worst defficiency currently seems that a quick top ten
google of "highpoint gpl" doesn't direct me anywhere near to
a cool site of yours. also "highpoint linux" lands on a faq
as top one that is quite terse.

hope that helps.
 
> Best Regards,
>  
> May Hwang

good success + warm greetings of cold vienna

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Adam Borowski]

On Fri, Feb 01, 2008 at 09:09:24PM +0100, Leo costela Antunes wrote:
> Adam Borowski wrote:
> > Uhm, and how exactly do you get the arch?  At DNS time you don't have
> > anything but the requester's or his ISP's IP.
> 
> This would have to be placed inside sources.list at some point, then I
> figure the automatic or manual process responsible should stick
> "dpkg-architecture -qDEB_BUILD_ARCH" somewhere in there, so you just
> have to query ".geomirror.d.net", for instance, to get the best
> mirror for your country which contains your arch.
> It could be during D-I, if the D-I people like the idea and no big
> problems arise from a testing period.

Ah, right.  Yet at least in some cases, it could be tricky to have the arch,
so I think you would need a generic mirror anyway.

> > Would a vserver, one IP and a NS delegation for a test subdomain be enough
> > for your tests?  No fallover or anything, though.
> 
> Yes, certainly. Do you have one available?

(Details sent privately).  Too bad, I just learned it can possibly go down
somewhere in the near future...

> > What about this:
> >   ftptest.debian.net CNAME debian.XXX
> >   debian.XXX NS your_vserver.XXX
> > (where XXX is any domain you can control without bothering the DSA for every
> > change)
> 
> I don't think that'll work. Since the Debian nameserver won't find a
> break in the SOA line (introduced with a NS entry), it'll try to find
> YYY.ftptest.d.net directly. A CNAME entry on an upper-level domain won't
> be enough to "redirect" the lower-level domains.

Aargh, it appears you're right.  Does someone have another idea?

If not, we can always do a brief test on a random subdomain, and then toss a
working config to the DSA guys.


Cheers, and so on...
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: changing the default syslog daemon for lenny?

[Holger Levsen]

Hi Michael,

On Thursday 31 January 2008 00:11, Michael Biebl wrote:
> > - Involve the rsyslog maintainer in the work
> I'm here and all ears. I'm willing to work on the necessary steps.

> Ok, here we go...

I just wish to say a big thanks to you for all the work you've already done on 
this. You rock!

> > - Document the change by preparing a patch for the release notes

I guess I c+should at least take over this one ;-)


regards,
Holger


pgpO0pfkOWFUf.pgp
Description: PGP signature

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

Hello May!

On Fri, Feb 01, 2008 at 07:38:03AM -0800, May Hwang wrote:
> 
> Thanks for the update. So this etch-n-half is the next Debian release, which
> already have HighPoint driver included? When etch-n-half will official hit
> the market?  

etch-n-half is the planed Linux kernel upgrade for the Etch Debian
distribution, roughly after 1/2 of it's lifetime, for more info on it
see http://wiki.debian.org/EtchAndAHalf

there is no hard date out yet, but you get an educated guess from
http://lists.debian.org/debian-kernel/2008/01/msg00217.html
http://lists.debian.org/debian-kernel/2008/01/msg00697.html
(due to beta1 debian-installer and etch+half coupling)
 
> Best Regards,
>  
> May Hwang

happy weekend.


-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Adding Install-Architecture to debian/control

[Julian Andres Klode]

Currently, we have Architecture to specify supported Architectures.

The problem are packages containing arch-indep content, but are only useful
on specific architectures (e.g. ndisgtk on i386 and amd64) and/or need
dependencies only available on these architectures. This means that the
package would be arch-dep.

I would like to add a field called Install-Architecture (or similar), which
lists the architectures the package should be installed in, i.e. added to
the Packages file.

Such a field would allow us to make packages like ndisgtk arch-indep, while
installing them only into the architectures specified in Install-Architecture.

This could reduce needed disk space, reduce the work for the buildds and
many other things.
-- 
Julian Andres Klode, Fellow of the Free Software Foundation Europe
 Ubuntu Member | Debian Packager | Developer

try Ubuntu: http://www.ubuntu.com/ | my site: http://jak-linux.org/
 mail: [EMAIL PROTECTED]  | IRC: juliank
languages: German  | English



signature.asc
Description: OpenPGP digital signature

Bug#463643: no i386 and powerpc build daemons available which can run 64bit binaries

[Matthias Klose]

Package: general
Severity: important

There are no i386 and powerpc build daemons which run a 64bit kernel.
This means that packages requiring testsuites to be run for 64bit
won't run and won't be tested on a regular basis.  If we do want to be
able to test packages build for a biarch setup we should have build
daemons to be able to run the testsuites for these packages as well.

This currently affects at least gcc-4.X and glibc.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463584: ITP: rubyripper -- an open-source secure ripper for Linux

[Eric Cooper]

On Fri, Feb 01, 2008 at 08:15:04PM +0100, Christian Perrier wrote:
> "open source" is not really relevant here
> 
> "secure audio ripper" seems to better fit the recommended writing
> style (DevRef 6.2.2)

"secure" connotes "safe from exploits", but I think what is intended is
"extremely careful about obtaining an accurate copy of the audio data".

-- 
Eric Cooper e c c @ c m u . e d u


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Adding Install-Architecture to debian/control

[Russ Allbery]

Julian Andres Klode <[EMAIL PROTECTED]> writes:

> Currently, we have Architecture to specify supported Architectures.
>
> The problem are packages containing arch-indep content, but are only
> useful on specific architectures (e.g. ndisgtk on i386 and amd64) and/or
> need dependencies only available on these architectures. This means that
> the package would be arch-dep.
>
> I would like to add a field called Install-Architecture (or similar),
> which lists the architectures the package should be installed in,
> i.e. added to the Packages file.
>
> Such a field would allow us to make packages like ndisgtk arch-indep,
> while installing them only into the architectures specified in
> Install-Architecture.
>
> This could reduce needed disk space, reduce the work for the buildds and
> many other things.

This would be useful for kernel module source that will only build on a
subset of the architectures that Debian supports as well.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic mirror selection

[Leo "costela" Antunes]

Adam Borowski wrote:
> Ah, right.  Yet at least in some cases, it could be tricky to have the arch,
> so I think you would need a generic mirror anyway.

I don't see any scenario where getting the arch would be tricky, do you
have any in mind?
Even if there is such a case, we have many mirrors that don't support
all arches, so - to avoid problems - we'd have to filter the list to
have only complete mirrors, drastically diminishing its utility,
therefore I think it would be best to ignore the very few - if any -
corner cases in which it's a little harder to get the arch, in the name
of maintained utility.

> (Details sent privately).  Too bad, I just learned it can possibly go down
> somewhere in the near future...

Thanks a lot anyway!

> If not, we can always do a brief test on a random subdomain, and then toss a
> working config to the DSA guys.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Happy New Year and May all the bitches disappear from the humanbeings world !

[anndy firstsing]

http://www.firstsing.com/news_8.htm





*Dear all the people with ingenuous head and heart ,
*

*  *

*Thanks for all your help during the year 2007 ! 
*

*And may god bless us to lift our head high and never hesitate to
**fight against the bitches
hard if they dare to bite us !
*

*  *

*We are still doing business since we have to MAKE LIVE ! And we have to
keep strength to fight against the bitches at any time if they bite us again
! *

*  *

*Now I understand that the 5000 years Chinese culture is just to produce
bitches , most of the " Chinese " are bitches ! They are proud that their
parents have murdered the great Liu ShaoQi , Lin Biao , He Long , Peng
DeHuai , Zhu De , and even the administrator Zhou EnLai ( tired working into
death to raise such a big group of bitches ) . They are threatening us that
they can murder all of us if we don't want to be bitches like they want !
But they don't know that the world has understood the bitch truth of them
and won't raise them any more ! The " humanbeing " world don't need any
bitch ! *

*  *

*Bitches are bitches . Bitches are CHEAP but never WORTHY
!
*

*  *

*I've met our dearest administrator Zhou EnLai's neice face to face last
year , and she told me that our new administrator Wen JiaBao is also a "
love people good administrator " , but will he love my little brother and me
? Will he love all our Firstsing members and their families and their
ingenuous friends ? Will he take care on all these bitch things , save my
little brother from the bitches' prison and punish the bitches for us
?
*

*  *

*May all the bitches disappear from the humanbeings world ASASP
!
*

*  *

*Never will the Firstsing members give up to any bitch
!
*

*Thank you very much for have saved us out off the bitches' hands and
Anndy's little brother JuLun , Wang is still in the bitches' prison as a
postage to stop us from accusing them !!! They haven't paid anything to
their bitch actions till now ! *

*Thank you for all your support and hope to work with you for more good
things ! Thank you all for all your care on the faithful Firstsing members
and their families ! Firstsing will always be the Best in reward to your
ingenuous persons ! *

*  *

*http://www.firstsing.com/news_8.htm*

Bug#463643: no i386 and powerpc build daemons available which can run 64bit binaries

[Charles Plessy]

Le Fri, Feb 01, 2008 at 11:11:19PM +0100, Matthias Klose a écrit :
> Package: general
> Severity: important
> 
> There are no i386 and powerpc build daemons which run a 64bit kernel.
> This means that packages requiring testsuites to be run for 64bit
> won't run and won't be tested on a regular basis.  If we do want to be
> able to test packages build for a biarch setup we should have build
> daemons to be able to run the testsuites for these packages as well.
> 
> This currently affects at least gcc-4.X and glibc.

Hi Matthias,

Apparently there are ppc64 machines available here:
http://tuxppc.rz.uni-augsburg.de/

I do not know if they run the 32- or 64-bit port in their userland,
however.

At worse, you can also look for people having such installations on the
following wiki page:

http://wiki.debian.org/VolunteersForPowerPC

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan

Bug#463666: ITP: tomoe -- Tomoe - A handwriting recognition engine

[NIIBE Yutaka]

Package: wnpp
Severity: wishlist
Owner: NIIBE Yutaka <[EMAIL PROTECTED]>


* Package name: tomoe
  Version : 0.6.0
  Upstream Author : 
Takuro Ashie <[EMAIL PROTECTED]>
HIGUCHI Daisuke <[EMAIL PROTECTED]>
Juernjakob Harder <[EMAIL PROTECTED]>
Hiroyuki Ikezoe <[EMAIL PROTECTED]>
* URL : http://tomoe.sourceforge.jp/cgi-bin/en/blog/index.rb
* License : GPL and LGPL
  Programming Lang: C
  Description : 
 Tomoe - Tegaki Online MOji recognition Engine - is a software which
 provides a handwriting recognition engine and its user interface on
 open source desktop environment.  Here, "Tegaki" means "Handwriting"
 and "Moji" means "Letter" in Japanese.
 It consists of following modules:
  Handwriting recognition engine library
  User interface widget library for handwriting recognition
  uim module
  SCIM module



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#463666: ITP: tomoe -- Tomoe - A handwriting recognition engine

[Christian Perrier]

Quoting NIIBE Yutaka ([EMAIL PROTECTED]):

>   Description : 


Apparently your proposed synopsis for the package is "-- Tomoe - A
handwriting recognition engine". May I suggest a simpler and more
"standard" one:

handwriting recognition engine



signature.asc
Description: Digital signature

Re: wnpp.debian.net sources released, security review wanted, plans for the future

[Sebastian Pipping]

Holger Levsen wrote:

Lucas offered that to me but the host the site runs
on cannot handle a new IP for free.


It doesnt need a new IP. Just point wnpp.d.n to the current IP of your server.


Sorry for me imprecision. I think I cannot make that
server accept requests for wnpp.debian.net .



Sebastian


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Package synopsis: appositive clause, not full sentence (was: Bug#463666: ITP: tomoe -- Tomoe - A handwriting recognition engine)

[Ben Finney]

Christian Perrier <[EMAIL PROTECTED]> writes:

> Quoting NIIBE Yutaka ([EMAIL PROTECTED]):
> >   Description : 
> 
> Apparently your proposed synopsis for the package is "-- Tomoe - A
> handwriting recognition engine". May I suggest a simpler and more
> "standard" one:
> 
> handwriting recognition engine

Yes.

In general, all Debian packages should follow the Debian Developer's
Reference guide on package descriptions:

It's a good idea to think of the synopsis as an appositive clause,
not a full sentence. An appositive clause is defined in WordNet as
a grammatical relation between a word and a noun phrase that
follows, e.g., "Rudolph the red-nosed reindeer". The appositive
clause here is "red-nosed reindeer". Since the synopsis is a
clause, rather than a full sentence, we recommend that it neither
start with a capital nor end with a full stop (period). It should
also not begin with an article, either definite ("the") or
indefinite ("a" or "an").


http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis>

-- 
 \   "For fast acting relief, try slowing down." —Jane Wagner, |
  `\   via Lily Tomlin |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]