dpatch -> quilt (Was: How to cope with patches sanely)

[Andreas Tille]

On Sat, 26 Jan 2008, Pierre Habouzit wrote:


 Seconded. I'd add, that in fact we should standardize on quilt as an
exchange format for patches, because it's simple, and that there are
powerful tools to handle them. Basically you have almost the same power
in quilt that in many SCMs when it comes to patch reordering or
amending. I personally find git-rebase more appealing than quilt
UI-wise, but both provide the same amount of features and helpers to
avoid to shoot yourself in the foot.


Is there any easy conversion from dpatch to quilt for a given package
that is using dpatch?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: dpatch -> quilt

[gregor herrmann]

On Mon, 28 Jan 2008 09:09:28 +0100, Andreas Tille wrote:

> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?

The following two links might give an idea:
* manual conversion:
  http://blog.orebokech.com/2007/08/converting-debian-packages-from-dpatch.html
* script (but svn-centric):
  http://svn.debian.org/wsvn/pkg-perl/scripts/dpatch2quilt?op=file&rev=0&sc=0 

gregor

-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-You're dead, Jim.  -- McCoy, "Amok Time", stardate 3372.7 


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

Re: dpatch -> quilt (Was: How to cope with patches sanely)

[Paul Wise]

On Jan 28, 2008 5:09 PM, Andreas Tille <[EMAIL PROTECTED]> wrote:

> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?

It is as simple as:

mv debian/patches/00list debian/patches/series

rename s/\.dpatch$/.patch/ debian/patches/*

edit debian/patches/series to add .patch to the patch names

maybe edit debian/patches/*.patch to remove all the dpatch comments
and just leave the patch descriptions and other human-readable info.

Set this in your ~/.quiltrc since it makes nicer patches:

QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index"

quilt push and quilt refresh each patch to update them.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: dpatch -> quilt (Was: How to cope with patches sanely)

[David Paleino]

Il giorno Mon, 28 Jan 2008 09:09:28 +0100 (CET)
Andreas Tille <[EMAIL PROTECTED]> ha scritto:

> Is there any easy conversion from dpatch to quilt for a given package
> that is using dpatch?

Isn't dpatch just adding a header (from "#!/usr/bin/dpatch -f" to "@DPATCH@")?
Or am I missing something? I believe one can just remove those headers and
`quilt import` them.

Cheers,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: How to cope with patches sanely (Was: State of the project - input needed)

[Andreas Tille]

On Sat, 26 Jan 2008, Pierre Habouzit wrote:


 IOW in order to perform a NMU, you just need to know how to:
 * checkout sources, debcheckout(1) knows that ;
 * commit your changes, debcommit(1) knows that almost, mr(1) could
   also probably be of help ;


The only problem that me and I guess at least 50% of DDs have with
debcheckout(1) and debcommit(1) is that they did not know them before
this thread.  Feel free to call me ignorant, but I was not aware of
these tools (and will not be able to check them for the next couple
of days because of time constraints).  So perhaps we do face here a
mere communication problem for a problem that is technically solved.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: announcing new tools

[Stefano Zacchiroli]

On Mon, Jan 28, 2008 at 08:00:24AM +0100, Andreas Tille wrote:
>> Isn't this what debian-devel-announce is for?
> I think so.  I personally do not understand the restraint to post to
> d-d-a.  I can not imagine that 5-10 mails more per month on this low
> volume list might worry anybody.

Yeah, right. But wiki.d.o/DeveloperNews eventually flows to d-d-a, so
problem settled, I would say.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: assimilating OpenBSD

[Mathieu Stumpf]

What about this project? Is it dead?


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

Re: changing the default syslog daemon for lenny?

[Javier Fernandez-Sanguino]

2008/1/28, Holger Levsen <[EMAIL PROTECTED]>:
> The main reason is that we need/want to configure syslogd via debconf (or any
> other policy complient way) for remote logging and the sysklogd maintainer
> doesn't want to provide it. See #370339 for details.

I find it surprising that the maintainer himself has not pronounced
his standing on the issue. The only reference to the maintainer is a
cut & paste note from an IRC log which might or might not be true.

The maintainer hasn't even tagged this issue (which is open for almost
2 years) as 'wontfix'. (!)

Regards

Javier


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

Re: table view wnpp page now on wnpp.debian.net

[Holger Levsen]

Hi,

On Monday 28 January 2008 11:03, Holger Levsen wrote:
> Could you add an explaination of "dust" on the page, too? I'm pretty sure
> it means "age in days", but as there seem to be 23 wnpp-bugs from today, I
> checked half of them as I couldnt believe there are so many on a monday
> morning already :)

It doesnt mean "age in days" but "days since last activity on the bug". The 
bugs I checked first, were indeed filed today, but then I saw #456640, which 
was filed in December but had activity today, so the dust was 0. 

Also "installs" seems to deserve more explaination. openoffice.org has 859223 
installs, which I believe is the installation number of all openoffice.org 
binary packages reported by popcorn combined.


> regards,
>   Holger


pgpJGwUqiafCj.pgp
Description: PGP signature

Re: changing the default syslog daemon for lenny?

[Francesco P. Lovergine]

On Sun, Jan 27, 2008 at 07:10:55PM -0600, William Pitcock wrote:
> 
> I agree with this. Additionally, Balasz Schielder (Balabit) makes people
> who contribute to syslog-ng sign a contributory license agreement [1],
> so that they can be included in syslog-ng premium, which is in my view
> against the whole purpose of open source. If you disagree with signing
> the CLA, your patch is rejected. As such, I feel that syslog-ng is not a
> good choice for the default syslogd in Debian.
> 
> rsyslog upstream have a fairly good reputation of being cooperative and
> generally good to work with, at least from what i have observed.
> 

What about first hand experiences with them in heavy-load production 
environments? Stability, etc.

-- 
Francesco P. Lovergine


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

Re: table view wnpp page now on wnpp.debian.net

[Holger Levsen]

Hi Sebastian,

On Saturday 26 January 2008 02:13, Sebastian Pipping wrote:
> thanks to lucas nussbaum the address
>http://debian.binera.de/wnpp/
> is now accessible through
>http://wnpp.debian.net/ .

Heh, cool, I tried wnpp.debian.net last week and it was not there yet :-)

Could you add an explaination of "dust" on the page, too? I'm pretty sure it 
means "age in days", but as there seem to be 23 wnpp-bugs from today, I 
checked half of them as I couldnt believe there are so many on a monday 
morning already :)

Also, what do the different colors mean? Ah, got that. You could use them as  
background colors also in the "ITA/ITP = Intent to package/adopt . O = 
Orphaned . RFA/RFH/RFP = Request for adoption/help/packaging" line.
 
Last, there is no explaination of what the good news and bad news feeds are 
(or the others). I can guess, but I dont want to have to :-)

Besides that, great work!

IMO this should be mentioned in the developer news, adding it there.


regards,
Holger


pgp7lPB3bhlAY.pgp
Description: PGP signature

Re: dpatch -> quilt (Was: How to cope with patches sanely)

[Cyril Brulebois]

On 28/01/2008, Paul Wise wrote:
> maybe edit debian/patches/*.patch to remove all the dpatch comments
> and just leave the patch descriptions and other human-readable info.
> 
> QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index"

Agreed on --no-index, not convinced by --no-timestamps and -p0.
 
FWIW, I use:
| QUILT_NO_DIFF_INDEX=true
| QUILT_DIFF_ARGS="--color=auto -p ab"
| QUILT_REFRESH_ARGS="-p ab"

> quilt push and quilt refresh each patch to update them.

No need to walk through them all, filterdiff is your friend.
 * --strip 0, if you want to keep -p0.
 * --remove-timestamps, if you want --no-timestamps.
 * dpatch stuff will be stripped.

Cheers,

-- 
Cyril Brulebois


pgpeD34ElH1X1.pgp
Description: PGP signature

Re: changing the default syslog daemon for lenny?

[Holger Levsen]

Hi Javier, hi Joey,

On Monday 28 January 2008 10:51, Javier Fernandez-Sanguino wrote:
> 2008/1/28, Holger Levsen <[EMAIL PROTECTED]>:
> > The main reason is that we need/want to configure syslogd via debconf (or
> > any other policy complient way) for remote logging and the sysklogd
> > maintainer doesn't want to provide it. See #370339 for details.
> I find it surprising that the maintainer himself has not pronounced
> his standing on the issue. The only reference to the maintainer is a
> cut & paste note from an IRC log which might or might not be true.
>
> The maintainer hasn't even tagged this issue (which is open for almost
> 2 years) as 'wontfix'. (!)

I agree that this bug should be tagged "wontfix", but I leave it to the 
maintainer to do it. 

But I have no reason not to believe the maintainer handles this bug 
as "wontfix", no (self-written) reply to the bug by him states this pretty 
well.

CC:ed Joey, so he can comment.


regards,
Holger


pgpusFdWv8MHf.pgp
Description: PGP signature

Re: dpatch -> quilt (Was: How to cope with patches sanely)

[Pierre Habouzit]

On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
> On 28/01/2008, Paul Wise wrote:
> > maybe edit debian/patches/*.patch to remove all the dpatch comments
> > and just leave the patch descriptions and other human-readable info.
> > 
> > QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index"
> 
> Agreed on --no-index, not convinced by --no-timestamps and -p0.

  -p0 allows patches to all be at the same level, which is just
consistency but I agree it's not needed. I don't use it.

  Though the "need" for --not-timestamps is really important when you
refresh a whole patch series, and don't want spurious timestamps changes
generating useless changes in your $SCM, and I do use it for this very
reason.

> FWIW, I use:
> | QUILT_NO_DIFF_INDEX=true
> | QUILT_DIFF_ARGS="--color=auto -p ab"
> | QUILT_REFRESH_ARGS="-p ab"

QUILT_PATCH_OPTS="--unified-reject-files" is great too.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpiDGqbI1bho.pgp
Description: PGP signature

Re: The meaning of Vcs-* fields

[Andreas Tille]

On Sat, 26 Jan 2008, Teemu Likonen wrote:


I do maintain some unofficial packages which - of course - I can do
anything I want with, but I also want to do things right, so I'd
appreciate your help in this.


May I ask for the sake of interest what unofficial packages you
are maintaining?  Sometimes it makes sense to publish your work
for a wider audience.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: The meaning of Vcs-* fields

[Cyril Brulebois]

On 28/01/2008, Andreas Tille wrote:
> There are other reasons for repackaging (for instance large chunks of
> precompiled binary data that would just bloat the archive even if
> everything is DFSG free).  I'm not aware of a default extension for
> the tarball name in case of repackaged tarballs.

I already pointed to Devref 6.7.8.2, now quoting it:
| A repackaged .orig.tar.gz:
| …
| 4. should use -.orig as the name of the
| top-level directory in its tarball. This makes it possible to
| distinguish pristine tarballs from repackaged ones.

-- 
Cyril Brulebois


pgpvlmjcnGgmA.pgp
Description: PGP signature

Re: The meaning of Vcs-* fields

[Andreas Tille]

On Sun, 27 Jan 2008, Raphael Geissert wrote:


Not only "dfsg", "debian" and "ds" are also used (when repackaging wasn't
because the real source isn't completely DFSG-free).


There are other reasons for repackaging (for instance large chunks of
precompiled binary data that would just bloat the archive even if everything
is DFSG free).  I'm not aware of a default extension for the tarball name
in case of repackaged tarballs.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: The meaning of Vcs-* fields

[Andreas Tille]

On Sun, 27 Jan 2008, Stefano Zacchiroli wrote:


Many people correctly pointed out that get-orig-source is only suggested
by the policy and that, as a best practice, it is recommended only when
repacking is needed. Fair enough. Can we either change its meaning or
add a new target which does what you are asking for?


IMHO the connection to the repacking is old fashioned and I would vote
for changing its meaning to a general recommendation.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: The meaning of Vcs-* fields

[Andreas Tille]

On Mon, 28 Jan 2008, Cyril Brulebois wrote:


everything is DFSG free).  I'm not aware of a default extension for
the tarball name in case of repackaged tarballs.


I already pointed to Devref 6.7.8.2, now quoting it:
| A repackaged .orig.tar.gz:
| ?
| 4. should use -.orig as the name of the
| top-level directory in its tarball. This makes it possible to
| distinguish pristine tarballs from repackaged ones.


... which describes the _content_ of the tarball, but not the _name_
(or extension) of the tarball.  So there is no clarification whether
to use 'dfsg', 'debian', 'ds' or something else in the tarball name
to my knowlwedge.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: rebuilding the archive in a dirty chroot: results

[Cyril Brulebois]

On 28/01/2008, Lucas Nussbaum wrote:
> Build-Conflicts: libwxgtk2.6-dev?

I thought we were moving away from wx 2.4, not from 2.6. ;-)

-- 
Cyril Brulebois


pgpLO4s4mwjfE.pgp
Description: PGP signature

Re: rebuilding the archive in a dirty chroot: results

[Hamish Moffatt]

On Mon, Jan 28, 2008 at 07:23:09AM +0100, Lucas Nussbaum wrote:
> On 27/01/08 at 12:47 +1100, Hamish Moffatt wrote:
> > trustedqsl build-depends(*) on libwxgtk2.4-dev, but your bdfh had
> > libwxgtk2.6-dev installed as well. The bdfh build used the newer
> > version, hence the binary dependencies were different. I'm not really
> > sure how to solve this. The two libwxgtk-dev packages are
> > co-installable (obviously).
> 
> Build-Conflicts: libwxgtk2.6-dev?

Possibly, although you'd really need to Build-Conflicts all future
libwxgtk versions, and there's no virtual package which can be used to
group them. And it doesn't really build-conflict, it just isn't the
default choice...

Anyway the problem has gone away for now.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: rebuilding the archive in a dirty chroot: results

[Lucas Nussbaum]

On 27/01/08 at 12:47 +1100, Hamish Moffatt wrote:
> trustedqsl build-depends(*) on libwxgtk2.4-dev, but your bdfh had
> libwxgtk2.6-dev installed as well. The bdfh build used the newer
> version, hence the binary dependencies were different. I'm not really
> sure how to solve this. The two libwxgtk-dev packages are
> co-installable (obviously).

Build-Conflicts: libwxgtk2.6-dev?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: CDBS cmake.mk class

[Cyril Brulebois]

On 28/01/2008, Salvatore Ansani wrote:
> Hi guys I've a strange behaviour compiling a kde4 package with
> cmake.mk CDBS class.

(And gales?)

> Investigating I found variable who cause error:
> -DCMAKE_C_COMPILER="cc".
> 
> Other Question: How I tell debian/rule to modify some variables ? If I
> redefine CMAKE_C_COMPILER with "" I don't have any 
> changes

http://bugs.debian.org/cdbs will lead you to #450901.
http://bugs.debian.org/cmake will lead you to #459207.

Since it's not being fixed right now, I personally embed a copy of
cmake.mk, without setting the two (C and CXX) offending variables.

Cheers,

-- 
Cyril Brulebois


pgpq40lfbcfZy.pgp
Description: PGP signature

Standard to indicate repacking in version numbers?

[Cyril Brulebois]

On 28/01/2008, Andreas Tille wrote:
> ... which describes the _content_ of the tarball, but not the _name_
> (or extension) of the tarball.  So there is no clarification whether
> to use 'dfsg', 'debian', 'ds' or something else in the tarball name to
> my knowlwedge.

How are “dfsg”, “debian”, or “ds” extensions? It's in the very middle of
the tarball name, and the extension would rather be “((orig.)tar.)gz”
(there's the revision in the way, also).

It'd be clearer to talk about the string to include in version numbers,
and I agree that having a common pattern in the policy or the devref
would make sense. There are several combinations of the above, mixed
together with the use of ‘+’, ‘~’ and ‘.’, and getting a standard for
that couldn't hurt.

Cc'ing -policy.

Cheers,

-- 
Cyril Brulebois


pgp38jPLnd6TN.pgp
Description: PGP signature

Re: The meaning of Vcs-* fields

[Teemu Likonen]

Andreas Tille kirjoitti:

> On Sat, 26 Jan 2008, Teemu Likonen wrote:
> > I do maintain some unofficial packages which - of course - I can do
> > anything I want with, but I also want to do things right, so I'd
> > appreciate your help in this.
>
> May I ask for the sake of interest what unofficial packages you
> are maintaining?  Sometimes it makes sense to publish your work
> for a wider audience.

You may. Actually "my" packages have already been published in Debian. 
I'm one of the upstream authors of Finnish spell-checking system Voikko 
(small part of it). Voikko's upstream developers maintained early 
Debian packages in purpose to help us to test the software and gain 
more testers from larger audience. For some time those packages were 
for end users too.

Now Timo Jyrinki is maintaining the official Debian and Ubuntu packages 
for Voikko (see aptitude search '~mjyrinki'). To help testing we still 
have the Debian-specific data in Voikko's upstream svn repositories. So 
those are the unofficial "packages" I still maintain. Timo Jyrinki is 
keeping touch with us and does a great job in spreading Voikko around 
Debian and Ubuntu world. Thanks Timo if you're reading this. :)


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

Re: How to cope with patches sanely

[Ben Finney]

Andreas Tille <[EMAIL PROTECTED]> writes:

> On Fri, 25 Jan 2008, Joey Hess wrote:
> 
> > The competing vcs situation has its problems, but no matter what
> > vcs is used for a package, you can check out the source to the
> > package using apt-get source. This allows examination and
> > modification of the source to any package, without needing to know
> > the vcs.
> 
> I agree here, but if I understood Ben Finney in
> 
>http://lists.debian.org/debian-devel/2008/01/msg00912.html
> 
> right, others do not.

I also agree with JoeyH's point above (again, as I understand it).

It seems to me that you can only agree with the position that "you can
check out the source to the package using 'apt-get source'. This
allows examination and midification of the source to any package" if
"the source to the package" is agreed upon.

I believe JoeyH defines "the source to the package" as being the exact
source that is then built to become the binary package; *not* an
intermediate form that must be patched again before it is ready to
build. It is that former position that I agree with, and that 'dpatch'
et al are obstacles to.

> So your main issue is that patches belong into the code not into a
> separate directory (in whatever form).

Rather (again, my understanding of JoeyH's position) that the source
package (i.e. that which is unpacked and presented by 'apt-get source
foo') can be examined in the knowledge that it is exactly the source
form that will be built, with no further patching operations required.

> I for myself would refuse to learn different vcs but if there is a
> chance for a common wrapper - I might consider changing my working
> preferences.

Sure. This is analogous to "I don't care what tool the package
maintainer uses to manipulate their patches, so long as I can be
completely ignorant of that tool and just 'apt-get source foo' to see
the already-patched source".

-- 
 \ "I object to doing things that computers can do." —Olin |
  `\   Shivers |
_o__)  |
Ben Finney


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

CDBS cmake.mk class

[Salvatore Ansani]

Hi guys I've a strange behaviour compiling a kde4 package with cmake.mk CDBS 
class.


I get a lot of strange CMake errors (like "MATH cannot parse the 
expression:" and so on...) when try to compile with dpkg-buildpackage but 
all was OK if I use "cmake ..".


Investigating I found variable who cause error: -DCMAKE_C_COMPILER="cc".

First Question: Why I got this kind of error ?? (cc is 4.2.3 - but same 
error with 4.2.1 and 4.3)
Other Question: How I tell debian/rule to modify some variables ? If I 
redefine CMAKE_C_COMPILER with "" I don't have any changes.


Regards (and sorry for my english),
Salvatore 



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

Re: CDBS cmake.mk class

[Salvatore Ansani]

Hi Cyril,

I follow your tips and now I redefine CC and CXX on "debian/rules" with 
correct path and now all is ok.


10x,
Salvatore


--
From: "Cyril Brulebois" <[EMAIL PROTECTED]>
Sent: Monday, January 28, 2008 2:05 PM
To: 
Subject: Re: CDBS cmake.mk class




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

Re: assimilating OpenBSD

[Jon Dowland]

On Mon, Jan 28, 2008 at 09:25:06AM +0100, Mathieu Stumpf wrote:
> What about this project? Is it dead?

For anyone else confused about this message, I believe Mathieu is
referring to
.


-- 
Jon Dowland


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

Re: preparing sid/lenny to build with GCC-4.3

[Mike Hommey]

On Mon, Jan 28, 2008 at 12:17:48PM -0200, Margarita Manterola <[EMAIL 
PROTECTED]> wrote:
> On Jan 28, 2008 4:53 AM, Mike Hommey <[EMAIL PROTECTED]> wrote:
> > On Sun, Jan 27, 2008 at 10:53:59PM +0100, Matthias Klose wrote:
> > > (...) so that we have
> > > the chance to drop gcc-4.2 for the next release (together with
> > > gcc-3.4/g++-3.4/gcc-4.0).
> >
> > Except if you want to remove qemu and kvm from the archive, there are
> > currently no chances of removing gcc-3.4.
> 
> Is there no way at all of fixing those so that they can be built with 4.3 ?

There are finally some patches [1], but it is still being discussed.

Mike

1. http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00380.html


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

Re: preparing sid/lenny to build with GCC-4.3

[Fathi Boudra]

> Is there no way at all of fixing those so that they can be built with 4.3?


And about applications or packages not  in Debian ?
In particular, gcc/g++-3.4 is often used in the embedded world.

HighPoint- GPL Licensed Controller wants To be Include In Debian Distribution

[May Hwang]

Dear Debian Developer,

 

This is May Hwang, Product Manager from HighPoint Technologies.  HighPoint
have launched a new series of H/W RAID controllers based on Intel 2nd
generation PCI-express I/O processor, one main advantage is we are the only
manufacturer integrate this Intel Fastest SATA I/O processor on HighPoint 4
and 8 ports controllers compares to others RAID controllers use 1st
generation PCI-express of I/O Processor.

 

These Hardware RAID controllers offer GPL licensed Linux Open Source driver
and have been accepted into 2.6.25 main kernel tree but since this is not a
stable kernel version yet so our Debian system integrators still have to go
through driver compilation in every installation process. Therefore, our
Debian customers request HighPoint must work with Debian developer to
include our linux drivers into the latest Debian Distribution. HighPoint is
always looking ways to provide friendly use experience for customers so we
will assign a dedicated firmware interface to work with Debian developer on
this project. 

   

We are looking forward to provide better support for Debian customers, let
us know how to move forward?

 

 

Best Regards,

 

May Hwang

 

HighPoint Technologies,Inc.

 

Tel:408-240-6118

Fax-408-942-5800

 

  www.highpoint-tech.com

  www.hptmac.com

 

Distribution Partners: ASI, BellMicro, D&H, Malabs

"RocketRAID - Terabyte Storage Technologies"

 

Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?

[Jon Dowland]

On Sat, Jan 19, 2008 at 06:18:32PM +0100, Sebastian Pipping wrote:
> i noticed that there exist many ita/itp bugs that are much older than
> two month. would it make sense to set them back to rfa/rfp?  if so how
> many days would be good to be the "too old" edge value?

I'd say more than two months. As a non-DD with no fixed sponsor, It can
often take me >2 months to get a package sponsored, let alone prepared.

(on that note, I've just stuck an RFP up on -mentors[1] for a nice pidgin
plugin if anyone is interested ;))

[1] 


-- 
Jon Dowland


-- 
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 Samstag, den 26.01.2008, 19:05 +0100 schrieb Pierre Habouzit:
> On Sat, Jan 26, 2008 at 04:34:27PM +, David Nusinow wrote:
> > If we can't figure out a good and clean way to keep a large stack of
> > long-lived patches in the vcs then I firmly believe we should standardize
> > on quilt.
> 
>   Seconded. I'd add, that in fact we should standardize on quilt as an
> exchange format for patches, because it's simple, and that there are
> powerful tools to handle them.

A question that comes up again and again is, if quilt can handle
debian-only VCS layouts? Is it able to handle this layout?

Regards, Daniel


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

Bug#462971: ITP: odtwriter -- convert reStructured Text to OpenDocument Text files

[Michael Schutte]

Package: wnpp
Severity: wishlist
Owner: Michael Schutte <[EMAIL PROTECTED]>


* Package name: odtwriter
  Version : 1.1a
  Upstream Author : Dave Kuhlman <[EMAIL PROTECTED]>
* URL : http://www.rexx.com/~dkuhlman/odtwriter.html
* License : MIT
  Programming Lang: Python
  Description : convert reStructured Text to OpenDocument Text files

odtwriter is a Python library capable of translating reStructuredText
(reST) files into the OpenDocument Text (ODT) format.  Applications able
to handle the latter document format include the word processors from
OpenOffice.org and KOffice, as well as AbiWord.

The package also contains a small script, rst2odt, to do the conversion
from the command line.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_AT.UTF-8)
Shell: /bin/sh linked to /bin/bash


signature.asc
Description: Digital signature

Re: Standard to indicate repacking in version numbers?

[Andreas Tille]

On Mon, 28 Jan 2008, Cyril Brulebois wrote:


How are ?dfsg?, ?debian?, or ?ds? extensions? It's in the very middle of
the tarball name, and the extension would rather be ?((orig.)tar.)gz?
(there's the revision in the way, also).

It'd be clearer to talk about the string to include in version numbers,
and I agree that having a common pattern in the policy or the devref
would make sense. There are several combinations of the above, mixed
together with the use of ?+?, ?~? and ?.?, and getting a standard for
that couldn't hurt.

Cc'ing -policy.


I agree with that we should have a common pattern.  But I would vote
for a neutral extension not trying to describe the reasons for repackaging.
Some kind of _.repack.tar.gz comes to mind.  This makes
clear that a changed upstream tarball is used.  Those tarballs should
feature a mandatory debian/README.repack which states clearly the reasons
for the repackaging and debian/rules should have a mandatory
get-orig-source target.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: rebuilding the archive in a dirty chroot: results

[Lucas Nussbaum]

On 26/01/08 at 08:59 +, Roger Leigh wrote:
> On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote:
> 
> > I'm not really sure of what we should do about those problems. The
> > easiest way to fix them is to use source-only uploads (to avoid packages
> > built on broken maintainer machines), and a better sbuild that can use
> > lvm snapshots so that it can start all builds with a clean environment.
> 
> Routine testing of this sort would help to catch this sort of problem,
> since always building in a clean chroot will "mask" the problem--but
> clean chroots would effectively prevent this for Debian.
> 
> Just FYI, there is a patch currently being discussed on the
> buildd-tools-devel list which would add union filesystem support in
> addition to lvm-snapshots.  This would also provide a mechanism to
> always ensure a clean build (by overlaying a temporary scratch
> filesystem over a clean chroot).
 
I was under the impression that the packaged sbuild isn't the one used
on buildds, and that the buildd-tools-devel list discusses the packaged
tools, not the one from the buildds. So this improvement would only be
available for the users of the packaged sbuild?

Are there any plans to move to the packaged versions on the buildds? The
packaged sbuild has been doing a very good job for me.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: The meaning of Vcs-* fields

[Felipe Sateler]

Josselin Mouette wrote:

> On sam, 2008-01-26 at 22:37 +0200, Riku Voipio wrote:
>> On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote:
>> > If I were you I would have tried "fakeroot debian/rules
>> > get-orig-source", which is the policy mandated target to retrieve
>> > orig.tar.gz.  I haven't tried, but looking at madwifi's debian/rules it
>> > is indeed implemented and retrieve the .orig.tar.gz.
>> > mine maintained on svn work that way.
>> 
>> This was a really usefull bit of information, thanks. Thou
>> get-orig-source of madwifi pulls the source to ../tarballs so some manual
>> work is still required.
> 
> No, because svn-buildpackage works, it looks for the tarballs in this
> directory. Which means the package is ready to build after that.
> 

But policy says this target should leave the tarball in the current directory,
not accommodate svn-buildpackage.

-- 

  Felipe Sateler


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

Re: dpatch -> quilt

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

>   Though the "need" for --not-timestamps is really important when you
> refresh a whole patch series, and don't want spurious timestamps changes
> generating useless changes in your $SCM, and I do use it for this very
> reason.

Yes.  Please use --no-timestamps so that interdiffs are easier to review.
Otherwise, diff introduces spurious changes every time you refresh a diff.
The information encoded in the timestamps really isn't useful.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

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

[Margarita Manterola]

Hi May Hwang!

On Jan 28, 2008 2:59 PM, May Hwang <[EMAIL PROTECTED]> wrote:

> These Hardware RAID controllers offer GPL licensed Linux Open Source driver
> and have been accepted into 2.6.25 main kernel tree but since this is not a
> stable kernel version yet so our Debian system integrators still have to go
> through driver compilation in every installation process. Therefore, our
> Debian customers request HighPoint must work with Debian developer to
> include our linux drivers into the latest Debian Distribution. HighPoint is
> always looking ways to provide friendly use experience for customers so we
> will assign a dedicated firmware interface to work with Debian developer on
> this project.

As Sean said, it's great that you are making this effort to provide a
better experience for your users.

Regarding Debian's latest distribution, once a distribution gets into
a "stable" form, it gets "frozen"; this means that Debian won't add
extra packages to it.  However, once you make the package, following
the guidelines that Sean gave you, you can provide that package to
your customers, for them to download.

The amount of effort for downloading a module from a different site
than the official Debian site, is almost nothing compared to the
effort of compiling and installing the module by hand, I think your
customers would be perfectly satisfied if you provide the package at
your site, until the next release (by then it will already be included
in the kernel).

-- 
Besos,
Marga


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

Bug#462975: ITP: kde4-style-qtcurve -- This is a set of widget styles for KDE4 based apps

[Salvatore Ansani]

Package: wnpp
Severity: wishlist
Owner: Salvatore Ansani <[EMAIL PROTECTED]>


* Package name: kde4-style-qtcurve
  Version : 0.55.2
  Upstream Author : Craig Drummond <[EMAIL PROTECTED]>
* URL : 
http://www.kde-look.org/content/show.php/QtCurve+%28KDE4%2C+KDE3%2C+%26+Gtk2+Theme%29?content=40492
* License : GPL
  Programming Lang: C, C++
  Description : This is a set of widget styles for KDE4 based apps

 This package together with gtk2-engines-qtcurve aim to provide a unified look
 and feel on the desktop when using KDE4 and GNOME applications

-- System Information:
Debian Release: lenny/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=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: Standard to indicate repacking in version numbers?

[Russ Allbery]

Andreas Tille <[EMAIL PROTECTED]> writes:

> I agree with that we should have a common pattern.  But I would vote for
> a neutral extension not trying to describe the reasons for repackaging.
> Some kind of _.repack.tar.gz comes to mind.  This makes
> clear that a changed upstream tarball is used.  Those tarballs should
> feature a mandatory debian/README.repack which states clearly the
> reasons for the repackaging and debian/rules should have a mandatory
> get-orig-source target.

We went back and forth on this several times on debian-mentors and I think
everyone finally agreed that debian/copyright is the correct place to
explain any repackaging of the upstream source.  Since debian/copyright is
the standard place to explain where the upstream source came from, it's
the logical place for that information to go.  Please let's not add a new
documentation file that isn't automatically collected by the PTS,
packages.d.o, etc.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

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

[sean finney]

Hi May,

(This should all be prefaced with the statement that i don't have a great deal 
of experience with kernel module packaging, someone from debian-kernel may 
have more insight than me)

First I should say it is very thoughtful of you to contact the debian 
community regarding your drivers, if only more members in the industry would 
do so!

Regarding packaging the kernel module: i suppose the best way to package the 
module for kernel versions before the mainline inclusion of your driver is to 
make a module-assistant-compatible package, which is about the easiest way 
one can install kernel modules in debian systems.

take a look at the documentation for module-assistant, specifically:

 /usr/share/doc/module-assistant/HOWTO-DEVEL.gz

(though this assumes a certain level of familiarity with debian packaging).  
and maybe use a couple other module source packages for reference as well.  
more information is also available at:

http://wiki.debian.org/ModuleAssistant

though this is more user-oriented.

after you have created an initial version of your package, you can always feel 
free to request feedback or review (via debian-devel/debian-kernel, or via 
IRC), and eventually sponsorship of your package for inclusion into debian if 
you feel it's relevant.  typically this last step is done by filing an RFS 
bug against the pseudo package wnpp via reportbug.

if you need help with packaging basics, there's also the debian-mentors list, 
which is also a good place to find a package sponsor.


anyway, hope that information is helpful,

sean



On Monday 28 January 2008 05:59:10 pm May Hwang wrote:
> Dear Debian Developer,
>
>
>
> This is May Hwang, Product Manager from HighPoint Technologies.  HighPoint
> have launched a new series of H/W RAID controllers based on Intel 2nd
> generation PCI-express I/O processor, one main advantage is we are the only
> manufacturer integrate this Intel Fastest SATA I/O processor on HighPoint 4
> and 8 ports controllers compares to others RAID controllers use 1st
> generation PCI-express of I/O Processor.
>
>
>
> These Hardware RAID controllers offer GPL licensed Linux Open Source driver
> and have been accepted into 2.6.25 main kernel tree but since this is not a
> stable kernel version yet so our Debian system integrators still have to go
> through driver compilation in every installation process. Therefore, our
> Debian customers request HighPoint must work with Debian developer to
> include our linux drivers into the latest Debian Distribution. HighPoint is
> always looking ways to provide friendly use experience for customers so we
> will assign a dedicated firmware interface to work with Debian developer on
> this project.
>
>
>
> We are looking forward to provide better support for Debian customers, let
> us know how to move forward?
>
>
>
>
>
> Best Regards,
>
>
>
> May Hwang
>
>
>
> HighPoint Technologies,Inc.
>
>
>
> Tel:408-240-6118
>
> Fax-408-942-5800
>
>
>
>   www.highpoint-tech.com
>
>   www.hptmac.com
>
>
>
> Distribution Partners: ASI, BellMicro, D&H, Malabs
>
> "RocketRAID - Terabyte Storage Technologies"


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

RE: HighPoint- GPL Licensed Controller wants To be Include In Debian Distribution

[May Hwang]

Dear Margarita,

Can you resend Sean's email because I didn't receive his email?

Up to this point, we are offering binary package based on customer request,
because binary driver package only support one specific kernel version.
Hence it is inconvenience for customer and time consuming.

Please advice when is the next release update and which kernel version?

Can I send you and Sean our Linux open source driver?


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


-Original Message-
From: Margarita Manterola [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 28, 2008 11:03 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-devel@lists.debian.org
Subject: Re: HighPoint- GPL Licensed Controller wants To be Include In
Debian Distribution

Hi May Hwang!

On Jan 28, 2008 2:59 PM, May Hwang <[EMAIL PROTECTED]> wrote:

> These Hardware RAID controllers offer GPL licensed Linux Open Source
driver
> and have been accepted into 2.6.25 main kernel tree but since this is not
a
> stable kernel version yet so our Debian system integrators still have to
go
> through driver compilation in every installation process. Therefore, our
> Debian customers request HighPoint must work with Debian developer to
> include our linux drivers into the latest Debian Distribution. HighPoint
is
> always looking ways to provide friendly use experience for customers so we
> will assign a dedicated firmware interface to work with Debian developer
on
> this project.

As Sean said, it's great that you are making this effort to provide a
better experience for your users.

Regarding Debian's latest distribution, once a distribution gets into
a "stable" form, it gets "frozen"; this means that Debian won't add
extra packages to it.  However, once you make the package, following
the guidelines that Sean gave you, you can provide that package to
your customers, for them to download.

The amount of effort for downloading a module from a different site
than the official Debian site, is almost nothing compared to the
effort of compiling and installing the module by hand, I think your
customers would be perfectly satisfied if you provide the package at
your site, until the next release (by then it will already be included
in the kernel).

-- 
Besos,
Marga


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

Re: preparing sid/lenny to build with GCC-4.3

[Bastian Blank]

On Mon, Jan 28, 2008 at 07:53:19AM +0100, Mike Hommey wrote:
> On Sun, Jan 27, 2008 at 10:53:59PM +0100, Matthias Klose wrote:
> > (...) so that we have
> > the chance to drop gcc-4.2 for the next release (together with
> > gcc-3.4/g++-3.4/gcc-4.0).
> Except if you want to remove qemu and kvm from the archive, there are
> currently no chances of removing gcc-3.4.

This is incorrect. The s390 port needs at least 3.4 to do something and
4.0 to work correctly.

Bastian

-- 
Warp 7 -- It's a law we can live with.


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

Re: Standard to indicate repacking in version numbers?

[Andreas Tille]

On Mon, 28 Jan 2008, Russ Allbery wrote:


We went back and forth on this several times on debian-mentors and I think
everyone finally agreed that debian/copyright is the correct place to
explain any repackaging of the upstream source.  Since debian/copyright is
the standard place to explain where the upstream source came from, it's
the logical place for that information to go.  Please let's not add a new
documentation file that isn't automatically collected by the PTS,
packages.d.o, etc.


OK, I hav not read these threads and perfectly accept enhancements of
my raw proposal.  The basic idea was to mark repackaged source archives
in the name of these archives and then find a reasonable mandatory place
to comment on the reasons.  I'm perfectly fine to do this in copyright.

Kind regards

   Andreas.

--
http://fam-tille.de


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

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

[Wouter Verhelst]

On Mon, Jan 28, 2008 at 11:24:55AM -0800, May Hwang wrote:
> Dear Margarita,
> 
> Can you resend Sean's email because I didn't receive his email?
> 
> Up to this point, we are offering binary package based on customer request,
> because binary driver package only support one specific kernel version.
> Hence it is inconvenience for customer and time consuming.
> 
> Please advice when is the next release update and which kernel version?

There is an "etch-n-half" planned pretty soon, which is to include a new
kernel with new drivers (at present, it is likely that this new kernel
will be 2.6.24). It would appear to me (though my opinion is in no way
authoritative in this matter) that a package with new HighPoint drivers
would be suitable for inclusion in etch-n-half, too. I'm sure people on
debian-kernel will be able to provide more insight into that matter.

Having said that: while a package with drivers for a hard drive
controller would easily allow a Debian user to *use* the system with
those drivers, it would not provide them with a way to actually
*install* the system yet. If your hardware cannot be used in a
"compatible" way, wherein the hardware will work, even if not at the
highest performance which it would support with those drivers, then this
is a problem that would need to be addressed by providing an updated
debian-installer image.

Luckily, this is not very hard; once you have a modules package with
your drivers, what you would need to do would include:
- creating a "udeb" (a debian-installer module) containing your
  additional drivers (this can be easily done with the "kernel-wedge"
  package and your modules package)
- building a custom debian-installer image which would include your
  udeb.

Your customers could then download the debian-installer image from your
website (or wherever), boot from that, and then install Debian as usual.
You might also want to modify your installer image so that it would, if
your hardware is detected, install the modules package; the
debian-installer environment contains sufficient software to make this
possible.

> Can I send you and Sean our Linux open source driver?

It's probably best if you put them online somewhere, and post a link.
Then those who are interested could, at the very least, help you get
started, or do the work.

Thanks again for your support of Debian,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: rebuilding the archive in a dirty chroot: results

[Wouter Verhelst]

On Mon, Jan 28, 2008 at 07:20:47AM +0100, Lucas Nussbaum wrote:
> On 26/01/08 at 08:59 +, Roger Leigh wrote:
> > On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote:
> > 
> > > I'm not really sure of what we should do about those problems. The
> > > easiest way to fix them is to use source-only uploads (to avoid packages
> > > built on broken maintainer machines), and a better sbuild that can use
> > > lvm snapshots so that it can start all builds with a clean environment.
> > 
> > Routine testing of this sort would help to catch this sort of problem,
> > since always building in a clean chroot will "mask" the problem--but
> > clean chroots would effectively prevent this for Debian.
> > 
> > Just FYI, there is a patch currently being discussed on the
> > buildd-tools-devel list which would add union filesystem support in
> > addition to lvm-snapshots.  This would also provide a mechanism to
> > always ensure a clean build (by overlaying a temporary scratch
> > filesystem over a clean chroot).
>  
> I was under the impression that the packaged sbuild isn't the one used
> on buildds, and that the buildd-tools-devel list discusses the packaged
> tools, not the one from the buildds.

Correct.

> So this improvement would only be available for the users of the
> packaged sbuild?

Probably

> Are there any plans to move to the packaged versions on the buildds?

Not to my knowledge.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Bug#463002: ITP: doomsday -- GPL licensed engine for classic doom, heretic, hexen and strife which provides updated 3d graphics and network gameplay

[Hash C. Borger]

Package: wnpp
Severity: wishlist
Owner: "Hash C. Borger" <[EMAIL PROTECTED]>


* Package name: doomsday
  Version : 1.9.0-beta5.2
  Upstream Author : Jaakko Keränen <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : GPL
  Programming Lang: C++
  Description : GPL licensed engine for classic doom, heretic, hexen and 
strife which provides updated 3d graphics and network gameplay


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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=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: Standard to indicate repacking in version numbers?

[Russ Allbery]

Bill Allombert <[EMAIL PROTECTED]> writes:
> On Mon, Jan 28, 2008 at 10:13:51AM -0800, Russ Allbery wrote:

>> We went back and forth on this several times on debian-mentors and I
>> think everyone finally agreed that debian/copyright is the correct
>> place to explain any repackaging of the upstream source.  Since
>> debian/copyright is the standard place to explain where the upstream
>> source came from, it's the logical place for that information to go.
>> Please let's not add a new documentation file that isn't automatically
>> collected by the PTS, packages.d.o, etc.
>
> Personnally I put it in debian/README.sources with instruction on how
> to generate the tarball from the upstream one.
>
> debian/README.sources is mentionned in another policy proposal.

Which I am similarly opposed to.  I think Policy 12.5 is reasonably clear
here:

In addition, the copyright file must say where the upstream sources
(if any) were obtained.

To me at least, that includes information about how a custom pack of the
upstream sources is generated, if that's necessary.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: CDBS cmake.mk class

[Jiri Palecek]

Cyril Brulebois wrote:

> http://bugs.debian.org/cdbs will lead you to #450901.
> http://bugs.debian.org/cmake will lead you to #459207.
> 
> Since it's not being fixed right now, I personally embed a copy of
> cmake.mk, without setting the two (C and CXX) offending variables.

BTW, since #450901 is quite old and there is a simple workaround, wouldn't
it be NMU-able?

Regards
Jiri Palecek



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

Re: Sources of dak ?

[Roger Leigh]

On Sun, Jan 27, 2008 at 09:08:44AM +0100, Martin Zobel-Helas wrote:
> Hi, 
> 
> On Sun Jan 27, 2008 at 16:53:59 +0900, Charles Plessy wrote:
> > Dear Developpers,
> > 
> > I wanted to check if dak was case-sensitive when parsing the
> > DM-Upload-Allowed field, but I did not find this string in the sources
> > that I got from `apt-get source dak'. I then checked debian/copyright,
> > that pointed me to  http://cvs.debian.org/?cvsroot=dak, in which I did
> > not find anything either. Are there more recent sources available to
> > non-DDs?
> 
> http://ftp-master.debian.org/bzr/

Why isn't this on bzr.debian.org?


Regards,
Roger


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: preparing sid/lenny to build with GCC-4.3

[Aurelien Jarno]

Mike Hommey a écrit :
> On Mon, Jan 28, 2008 at 12:17:48PM -0200, Margarita Manterola <[EMAIL 
> PROTECTED]> wrote:
>> On Jan 28, 2008 4:53 AM, Mike Hommey <[EMAIL PROTECTED]> wrote:
>>> On Sun, Jan 27, 2008 at 10:53:59PM +0100, Matthias Klose wrote:
 (...) so that we have
 the chance to drop gcc-4.2 for the next release (together with
 gcc-3.4/g++-3.4/gcc-4.0).
>>> Except if you want to remove qemu and kvm from the archive, there are
>>> currently no chances of removing gcc-3.4.
>> Is there no way at all of fixing those so that they can be built with 4.3 ?
> 
> There are finally some patches [1], but it is still being discussed.
> 

Those patches have been rejected^Wignored by Fabrice Bellard, and anyway
don't really works with gcc-4.3. He is currently working on a new code
generator to replace dyngen, however I am not sure it will be finished
for Lenny.

Note however that qemu doesn't need g++, and I think it is the same for
the remaining programs using gcc-3.4, so this language could probably
dropped.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: table view wnpp page now on wnpp.debian.net

[Sebastian Pipping]

Holger Levsen wrote:

Could you add an explaination of "dust" on the page, too?


I have it in the tooltips ('title' attribute) but I agree that
a detailed legend would help. Any ideas where to put it best?
At the very bottom of the page? In an extra page/window?


I'm pretty sure it 
means "age in days", but as there seem to be 23 wnpp-bugs from today, I 
checked half of them as I couldnt believe there are so many on a monday 
morning already :)


Dust
  Number of days without changes
  (i.e. amount of dust stacking up on a bug)


Also, what do the different colors mean? Ah, got that. You could use them as  
background colors also in the "ITA/ITP = Intent to package/adopt . O = 
Orphaned . RFA/RFH/RFP = Request for adoption/help/packaging" line.


The colors were introduced for distinction, to speed up hopping from bug to
bug of a certain type. I decided against coloring the legend because it
(probably, didn't try) looks ugly and because in my view it was not
important which color ITP is. But that's just my view. I plan to
open up the source soon so you will be able to play with that :-)


Last, there is no explaination of what the good news and bad news feeds are 
(or the others). I can guess, but I dont want to have to :-)


For now please look here:
http://lists.debian.org/debian-devel/2008/01/msg00970.html



Besides that, great work!


Thank you!



IMO this should be mentioned in the developer news, adding it there.


Sounds good. Please send me a link so I can see where it went.



Sebastian


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

Re: preparing sid/lenny to build with GCC-4.3

[Margarita Manterola]

On Jan 28, 2008 4:53 AM, Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 27, 2008 at 10:53:59PM +0100, Matthias Klose wrote:
> > (...) so that we have
> > the chance to drop gcc-4.2 for the next release (together with
> > gcc-3.4/g++-3.4/gcc-4.0).
>
> Except if you want to remove qemu and kvm from the archive, there are
> currently no chances of removing gcc-3.4.

Is there no way at all of fixing those so that they can be built with 4.3 ?

-- 
Besos,
Marga


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

Re: Standard to indicate repacking in version numbers?

[Cyril Brulebois]

On 28/01/2008, Russ Allbery wrote:
> We went back and forth on this several times on debian-mentors and I
> think everyone finally agreed that debian/copyright is the correct
> place to explain any repackaging of the upstream source.  Since
> debian/copyright is the standard place to explain where the upstream
> source came from, it's the logical place for that information to go.

Agreed.

First (and that's why I keep -policy, and even add -doc to Cc), it might
be interesting to remove the README.Debian-source suggestion in devref
6.7.8.2 and specify debian/copyright there.

Second, I'm now wondering whether some modifications/additions to the
copyright format proposal[1] should be done so as to make it easy to
specify which files/directories were removed and for which reason (no
sources, no license, unsuitable license, etc.).

 1. http://wiki.debian.org/Proposals/CopyrightFormat

Cheers,

-- 
Cyril Brulebois


pgptBO9Ki7Bk3.pgp
Description: PGP signature

Re: changing the default syslog daemon for lenny?

[Patrick Winnertz]

Am Montag, 28. Januar 2008 01:55:23 schrieb Michael Biebl:
> rsyslog is also a drop in replacement, even more so, as it can
> understand the syntax of sysklogd. The default rsyslog config file
> /etc/rsyslog.conf is basically a copy of /etc/syslog.conf.
> So if you have a custom syslog.conf, you could either copy it to
> /etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf.
>
> rsyslog also allows to include other config files. The default
> /etc/rsyslog.conf is setup to include all files in
> /etc/rsyslog.d/*.conf.
I would go also for rsyslog. The feature to add configuration files to 
rsyslog without touching configuration files in postinst scripts of other 
packages is really important for some other Debian releated Groups (e.g. 
Debian Edu).

Greetings
Patrick Winnertz



-- 
 .''`.   Patrick Winnertz <[EMAIL PROTECTED]>
:  :' :  GNU/Linux Debian Developer
`. `'`   http://www.der-winnie.de http://d.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


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

Re: rebuilding the archive in a dirty chroot: results

[Roger Leigh]

On Mon, Jan 28, 2008 at 07:20:47AM +0100, Lucas Nussbaum wrote:
> On 26/01/08 at 08:59 +, Roger Leigh wrote:
> > On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote:
> > 
> > > I'm not really sure of what we should do about those problems. The
> > > easiest way to fix them is to use source-only uploads (to avoid packages
> > > built on broken maintainer machines), and a better sbuild that can use
> > > lvm snapshots so that it can start all builds with a clean environment.
> > 
> > Routine testing of this sort would help to catch this sort of problem,
> > since always building in a clean chroot will "mask" the problem--but
> > clean chroots would effectively prevent this for Debian.
> > 
> > Just FYI, there is a patch currently being discussed on the
> > buildd-tools-devel list which would add union filesystem support in
> > addition to lvm-snapshots.  This would also provide a mechanism to
> > always ensure a clean build (by overlaying a temporary scratch
> > filesystem over a clean chroot).
>  
> I was under the impression that the packaged sbuild isn't the one used
> on buildds, and that the buildd-tools-devel list discusses the packaged
> tools, not the one from the buildds. So this improvement would only be
> available for the users of the packaged sbuild?

Yes, for the moment.

> Are there any plans to move to the packaged versions on the buildds? The
> packaged sbuild has been doing a very good job for me.

Not that I'm aware of.  However, we have started merging buildd and
wanna-build into the sbuild sources.  Over the weekend, I added
wanna-build to the packaging.  wanna-build doesn't currently work--it
needs some tweaking to use the various perl modules it depends on such
as WannaBuild::Conf and Sbuild.pm.  Once these are done (and they are
just trivial refactoring), wanna-build will be available in the main
archive.  I've been merging WannaBuild.pm into Sbuild.pm (since they
were mostly identical), and this is just tidying up to complete the
reorganisation.

Following on, I have the same plan for buildd.  This is in the sources
right now, but is just not installed or packaged pending the same
refactoring work.  This is again just some basic reorgainisation and
renaming, plus FHS compliance and automation of the basic setup (unlike
upstream, the aim is to make as much work right out of the box as is
technically possible, and to script the rest to make it easy).  We
already did this for sbuild (e.g. sbuild-createchroot and
sbuild-adduser), so it's just more of the same.

Time allowing, and depending on if I have any help (which is most
welcome), we should have the whole of wanna-build and buildd in unstable
in the not too distant future.

If the buildd admins desire, this could be used on the real buildds.  I
would certainly like some testing in a real buildd situation on a trial
archive build or two before this happens.  Help testing will always be
appreciated.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Bug#463029: ITP: synce-sync-engine -- Synchronization Engine for Windows Mobile devices

[Jonny Lamb]

Package: wnpp
Severity: wishlist
Owner: Jonny Lamb <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: synce-sync-engine
  Version : 0.1
  Upstream Author : Ole André Vadla Ravnås <[EMAIL PROTECTED]>
John Gow <[EMAIL PROTECTED]>
* URL : http://www.synce.org/
* License : GPL
  Description : Synchronization Engine for Windows Mobile devices

 SyncEngine talks the to a Windows Mobile device through the ActiveSync
 protocol. It provides plugins for OpenSync for synchronization. SyncEngine
 talks to the device through the connection manager, odccm.

-- 
Jonny Lamb, UK   [EMAIL PROTECTED]
http://jonnylamb.com GPG: 0x2E039402


signature.asc
Description: Digital signature

Re: Standard to indicate repacking in version numbers?

[Luca Capello]

Hi all!

On Mon, 28 Jan 2008 21:22:43 +0100, Russ Allbery wrote:
> Bill Allombert <[EMAIL PROTECTED]> writes:
>> On Mon, Jan 28, 2008 at 10:13:51AM -0800, Russ Allbery wrote:
>>> We went back and forth on this several times on debian-mentors and I
>>> think everyone finally agreed that debian/copyright is the correct
>>> place to explain any repackaging of the upstream source.  Since
>>> debian/copyright is the standard place to explain where the upstream
>>> source came from, it's the logical place for that information to go.
>>> Please let's not add a new documentation file that isn't automatically
>>> collected by the PTS, packages.d.o, etc.
>>
>> Personnally I put it in debian/README.sources with instruction on how
>> to generate the tarball from the upstream one.
>>
>> debian/README.sources is mentionned in another policy proposal.
>
> Which I am similarly opposed to.  I think Policy 12.5 is reasonably clear
> here:
>
> In addition, the copyright file must say where the upstream sources
> (if any) were obtained.
>
> To me at least, that includes information about how a custom pack of the
> upstream sources is generated, if that's necessary.

I think there's a problem here, according to the facts below...


- debian-policy_3.7.3.0, § 12.5, reported above by Russ, doesn't sound
  so clear to me (but I'm not an English native speaker).

  Let's say that I grab foo from foo.alioth.d.o, then I remove some
  non-DFSG-free material and I repackage the orig.tar.gz: the upstream
  sources are still obtained from foo.alioth.d.o.


- developers-reference_3.3.8 (11 November, 2006, the version available
  on sid...), § 6.7.8.2:

A repackaged .orig.tar.gz

1. must contain detailed information how the repackaged source was
   obtained, and how this can be reproduced, in README.Debian-source
   or a similar file.


- developers-reference_3.3.9 (04 August, 2007, available *only* on
  www.d.o), § 6.7.8.2:

A repackaged .orig.tar.gz

1. must contain detailed information how the repackaged source was
   obtained, and how this can be reproduced in the debian/copyright.


- on 04 December, 2007, I asked on #debian-devel about where I should
  have explained how I repackaged thinkinger and the answer was duplex:
  debian/copyright if the explanation was simple or debian/README.Source
  if more complex (which I chose, since I prefer to be more verbose)


Thx, bye,
Gismo / Luca


pgpyngW1p997I.pgp
Description: PGP signature

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

[May Hwang]

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.

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!

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: Wouter Verhelst [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 28, 2008 12:56 PM
To: May Hwang
Cc: 'Margarita Manterola'; [EMAIL PROTECTED];
debian-devel@lists.debian.org
Subject: Re: HighPoint- GPL Licensed Controller wants To be Include InDebian
Distribution

On Mon, Jan 28, 2008 at 11:24:55AM -0800, May Hwang wrote:
> Dear Margarita,
> 
> Can you resend Sean's email because I didn't receive his email?
> 
> Up to this point, we are offering binary package based on customer
request,
> because binary driver package only support one specific kernel version.
> Hence it is inconvenience for customer and time consuming.
> 
> Please advice when is the next release update and which kernel version?

There is an "etch-n-half" planned pretty soon, which is to include a new
kernel with new drivers (at present, it is likely that this new kernel
will be 2.6.24). It would appear to me (though my opinion is in no way
authoritative in this matter) that a package with new HighPoint drivers
would be suitable for inclusion in etch-n-half, too. I'm sure people on
debian-kernel will be able to provide more insight into that matter.

Having said that: while a package with drivers for a hard drive
controller would easily allow a Debian user to *use* the system with
those drivers, it would not provide them with a way to actually
*install* the system yet. If your hardware cannot be used in a
"compatible" way, wherein the hardware will work, even if not at the
highest performance which it would support with those drivers, then this
is a problem that would need to be addressed by providing an updated
debian-installer image.

Luckily, this is not very hard; once you have a modules package with
your drivers, what you would need to do would include:
- creating a "udeb" (a debian-installer module) containing your
  additional drivers (this can be easily done with the "kernel-wedge"
  package and your modules package)
- building a custom debian-installer image which would include your
  udeb.

Your customers could then download the debian-installer image from your
website (or wherever), boot from that, and then install Debian as usual.
You might also want to modify your installer image so that it would, if
your hardware is detected, install the modules package; the
debian-installer environment contains sufficient software to make this
possible.

> Can I send you and Sean our Linux open source driver?

It's probably best if you put them online somewhere, and post a link.
Then those who are interested could, at the very least, help you get
started, or do the work.

Thanks again for your support of Debian,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Bug#463015: ITP: sylph-searcher -- full-text search program for Sylpheed or MH folders

[Hideki Yamane]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: sylph-searcher
Version: 1.0.0
Upstream Author: Hiroyuki Yamamoto <[EMAIL PROTECTED]>
URL: http://sylpheed.sraoss.jp
License: BSD
Description: full-text search program for Sylpheed or MH folders
 Sylph-Searcher (tentative name) is a full-text search program 
 for messages stored in the mailboxes of Sylpheed, or generic 
 MH folders.
 .
 It utilizes the full-text search feature of PostgreSQL 8.2 
 or later.


pgpylFwk3Ptkn.pgp
Description: PGP signature

Bug#463018: problem with cyrillic letter IO and letter case issue in utf8_general_ci

[vsevolod parfenov]

Package: general
Severity: normal

I have problem in mysql (5.0.32-Debian_7etch5-log Debian etch distribution)
Better to view it on a wide screen.

It's all about cyrillic characters:
Ёё comparing to Ее and
Йй comparing to Ии

characters (first code is cp1251):
е 0xE5 = U+0435 : CYRILLIC SMALL LETTER IE
Е 0xC5 = U+0415 : CYRILLIC CAPITAL LETTER IE
ё 0xB8 = U+0451 : CYRILLIC SMALL LETTER IO
Ё 0xA8 = U+0401 : CYRILLIC CAPITAL LETTER IO
и 0xE8 = U+0438 : CYRILLIC SMALL LETTER I
И 0xC8 = U+0418 : CYRILLIC CAPITAL LETTER I
й 0xE9 = U+0439 : CYRILLIC SMALL LETTER SHORT I
Й 0xC9 = U+0419 : CYRILLIC CAPITAL LETTER SHORT I 

from http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT

I compare several collations in cp1251 and utf8 character sets.
SQL SELECT looks like (cp1251 hex codes):
select 'ё' = 'Ё', 'й' = 'Й', 'z' = 'Z', 'е' = 'ё', 'и' = 'й', 'И' = 'Й', 'е' >= 
'ё', 'Е' = 'Ё', 'и' > 'й', 'Ё' > 'ё', 'Й' > 'й', 'Б' > 'б', 'L' > 'l';
B8A8   E9C9   7A5A   E5B8   E8E9   C8C9   E5
 B8   C5A8   E8E9   A8B8   C9E9   C1E1   4C6C

Compare case sensitive collations
-

mysql> set names cp1251 collate cp1251_general_cs;
mysql> select 'ё' = 'Ё', 'й' = 'Й', 'z' = 'Z', 'е' = 'ё', 'и' = 'й', 'И' = 'Й', 
'е' >= 'ё', 'Е' = 'Ё', 'и' > 'й', 'Ё' > 'ё', 'Й' > 'й', 'Б' > 'б', 'L' > 'l';
+---+---+---+---+---+---++---+---+---+---+---+---+
| 'ё' = 'Ё' | 'й' = 'Й' | 'z' = 'Z' | 'е' = 'ё' | 'и' = 'й' | 'И' = 'Й' | 'е' 
>= 'ё' | 'Е' = 'Ё' | 'и' > 'й' | 'Ё' > 'ё' | 'Й' > 'й' | 'Б' > 'б' | 'L' > 'l' |
+---+---+---+---+---+---++---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 |   
   0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---++---+---+---+---+---+---+
Correct

mysql> set names utf8 collate utf8_bin;
mysql> select 'ё' = 'Ё', 'й' = 'Й', 'z' = 'Z', 'е' = 'ё', 'и' = 'й', 'И' = 'Й', 
'е' >= 'ё', 'Е' = 'Ё', 'и' > 'й', 'Ё' > 'ё', 'Й' > 'й', 'Б' > 'б', 'L' > 'l';
+---+---+---+---+---+---++---+---+---+---+---+---+
| 'ё' = 'Ё' | 'й' = 'Й' | 'z' = 'Z' | 'е' = 'ё' | 'и' = 'й' | 'И' = 'Й' | 'е' 
>= 'ё' | 'Е' = 'Ё' | 'и' > 'й' | 'Ё' > 'ё' | 'Й' > 'й' | 'Б' > 'б' | 'L' > 'l' |
+---+---+---+---+---+---++---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 |   
   1 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---++---+---+---+---+---+---+
Wrong!

The 1 (true value) in second result is a error! It has to be 0 (false) (sorting 
issue)


Compare case insensitive collations
---

mysql> set names cp1251 collate cp1251_general_ci;
mysql> select 'ё' = 'Ё', 'й' = 'Й', 'z' = 'Z', 'е' = 'ё', 'и' = 'й', 'И' = 'Й', 
'е' >= 'ё', 'Е' = 'Ё', 'и' > 'й', 'Ё' > 'ё', 'Й' > 'й', 'Б' > 'б', 'L' > 'l';
+---+---+---+---+---+---++---+---+---+---+---+---+
| 'ё' = 'Ё' | 'й' = 'Й' | 'z' = 'Z' | 'е' = 'ё' | 'и' = 'й' | 'И' = 'Й' | 'е' 
>= 'ё' | 'Е' = 'Ё' | 'и' > 'й' | 'Ё' > 'ё' | 'Й' > 'й' | 'Б' > 'б' | 'L' > 'l' |
+---+---+---+---+---+---++---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | 0 | 0 |   
   0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---++---+---+---+---+---+---+
Correct

mysql> set names utf8 collate utf8_general_ci;
mysql> select 'ё' = 'Ё', 'й' = 'Й', 'z' = 'Z', 'е' = 'ё', 'и' = 'й', 'И' = 'Й', 
'е' >= 'ё', 'Е' = 'Ё', 'и' > 'й', 'Ё' > 'ё', 'Й' > 'й', 'Б' > 'б', 'L' > 'l';
+---+---+---+---+---+---++---+---+---+---+---+---+
| 'ё' = 'Ё' | 'й' = 'Й' | 'z' = 'Z' | 'е' = 'ё' | 'и' = 'й' | 'И' = 'Й' | 'е' 
>= 'ё' | 'Е' = 'Ё' | 'и' > 'й' | 'Ё' > 'ё' | 'Й' > 'й' | 'Б' > 'б' | 'L' > 'l' |
+---+---+---+---+---+---++---

Re: table view wnpp page now on wnpp.debian.net

[Sebastian Pipping]

Holger Levsen wrote:
It doesnt mean "age in days" but "days since last activity on the bug". The 
bugs I checked first, were indeed filed today, but then I saw #456640, which 
was filed in December but had activity today, so the dust was 0. 


Dust
  Number of days without changes
  (i.e. amount of dust stacking up on a bug)

Age
  Number of days since this bug's creation


Also "installs" seems to deserve more explaination. openoffice.org has 859223 
installs, which I believe is the installation number of all openoffice.org 
binary packages reported by popcorn combined.


Users
  Minimum number of people using this package on a regular basis
  (1:1 'vote' column from popcon, copied from [1])

Installs
  Minimum number of people having this package installed
  (1:1 'inst' column from popcon, copied from [1])



Sebastian


[1] http://popcon.debian.org/source/by_inst.gz


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

Re: Standard to indicate repacking in version numbers?

[Bill Allombert]

On Mon, Jan 28, 2008 at 10:13:51AM -0800, Russ Allbery wrote:
> Andreas Tille <[EMAIL PROTECTED]> writes:
> 
> > I agree with that we should have a common pattern.  But I would vote for
> > a neutral extension not trying to describe the reasons for repackaging.
> > Some kind of _.repack.tar.gz comes to mind.  This makes
> > clear that a changed upstream tarball is used.  Those tarballs should
> > feature a mandatory debian/README.repack which states clearly the
> > reasons for the repackaging and debian/rules should have a mandatory
> > get-orig-source target.
> 
> We went back and forth on this several times on debian-mentors and I think
> everyone finally agreed that debian/copyright is the correct place to
> explain any repackaging of the upstream source.  Since debian/copyright is
> the standard place to explain where the upstream source came from, it's
> the logical place for that information to go.  Please let's not add a new
> documentation file that isn't automatically collected by the PTS,
> packages.d.o, etc.

Personnally I put it in debian/README.sources with instruction on how
to generate the tarball from the upstream one.

debian/README.sources is mentionned in another policy proposal.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Standard to indicate repacking in version numbers?

[Russ Allbery]

Luca Capello <[EMAIL PROTECTED]> writes:

> - debian-policy_3.7.3.0, § 12.5, reported above by Russ, doesn't sound
>   so clear to me (but I'm not an English native speaker).
>
>   Let's say that I grab foo from foo.alioth.d.o, then I remove some
>   non-DFSG-free material and I repackage the orig.tar.gz: the upstream
>   sources are still obtained from foo.alioth.d.o.

Well, no, they're not -- they're obtained by combining your repackaging
work with a tarball from foo.alioth.d.o, and only saying that they come
from foo.alioth.d.o would be omitting some information about where the
upstream sources came from.

But I'm certainly not opposed to clarifying.

> - developers-reference_3.3.8 (11 November, 2006, the version available
>   on sid...), § 6.7.8.2:
>
> A repackaged .orig.tar.gz
>
> 1. must contain detailed information how the repackaged source was
>obtained, and how this can be reproduced, in README.Debian-source
>or a similar file.

> - developers-reference_3.3.9 (04 August, 2007, available *only* on
>   www.d.o), § 6.7.8.2:
>
> A repackaged .orig.tar.gz
>
> 1. must contain detailed information how the repackaged source was
>obtained, and how this can be reproduced in the debian/copyright.

Yeah, this was updated after the previous debian-mentors discussion.

> - on 04 December, 2007, I asked on #debian-devel about where I should
>   have explained how I repackaged thinkinger and the answer was duplex:
>   debian/copyright if the explanation was simple or debian/README.Source
>   if more complex (which I chose, since I prefer to be more verbose)

I don't see any reason not to put it in debian/copyright no matter how
long it is.  It's not like the length of a text explanation, even if
complex, is going to be a serious problem.

However, ideally the steps should be *automated* and put into debian/rules
get-orig-source, in which case you don't have to give detailed steps in
either location and can simply refer to the automated procedure in
debian/rules get-orig-source, which if used by the maintainer also has the
benefit of being tested.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: changing the default syslog daemon for lenny?

[Russ Allbery]

Holger Levsen <[EMAIL PROTECTED]> writes:

> Debian Edu will be switching its syslog for Lenny and as we want to
> differ the least possible from Debian, we are wondering, what the
> default syslog will be in Lenny.
>
> The main reason is that we need/want to configure syslogd via debconf
> (or any other policy complient way) for remote logging and the sysklogd
> maintainer doesn't want to provide it. See #370339 for details.
>
> So we decided to switch to syslog-ng for now. 

It sounds like there are other reasons to switch to syslog-ng or rsyslog
for Debian as well (and I certainly understand why Debian Edu switched).
I just wanted to note somewhere in this thread that if the problem were
just this single packaging feature (which I know is not actually the
case), that by itself isn't a reason to switch default syslog daemons.
Another possible course of action would be to appeal the maintainer's
decision to the Technical Committee.

Of course, since other syslog implementations are potentially better in
larger ways, there may still be good reason to switch the default syslog
to another implementation.  We're using syslog-ng for some hosts at
Stanford because the configuration language just lets you do more stuff
that sysklogd doesn't.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[Charles Plessy]

Le Mon, Jan 28, 2008 at 11:33:39PM +1100, Ben Finney a écrit :
> 
> It seems to me that you can only agree with the position that "you can
> check out the source to the package using 'apt-get source'. This
> allows examination and midification of the source to any package" if
> "the source to the package" is agreed upon.

Hi all,

In that case, I think that the man page of apt-get should be
authoritative on what is expected from running 'apt-get source': "source
causes apt-get to fetch source packages." The definition of the debian
source package in Policy C.3 does not mention that the upsteam sources
must bear all the modifications that the debian/rules makefile applies
to them before starting compilation and/or installation.

So for the moment there is no tool for people to examinate the patched
sources without having to know about the patch systems. Maybe a bit of
Policy on a 'patch' rule for 'debian/rules' and an option --patch for
'apt-get source', or 'dpkg-source', would solve this aspect of the
problem.

Have a nice day,

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


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

Re: How to cope with patches sanely

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> In that case, I think that the man page of apt-get should be
> authoritative on what is expected from running 'apt-get source': "source
> causes apt-get to fetch source packages." The definition of the debian
> source package in Policy C.3 does not mention that the upsteam sources
> must bear all the modifications that the debian/rules makefile applies
> to them before starting compilation and/or installation.

We can't get too rules-bound here.  It's hard to state the requirements in
a general and bulletproof form, since the build system itself may involve
patching files (to build them multiple times in different ways, for
instance), running autoconf and friends, or other actions that mean that
the sources as distributed aren't the absolutely final form.  The
absolutely final form is somewhat undefined -- is shipping bison source
which is processed by bison before gcc okay, for instance?  What about
adding a binary file, such as an image file, by shipping it uuencoded and
then decoding it in debian/rules?  There are a lot of arguments that we
could get into if we tried to make strict rules which feel like time
wasters to me.

> So for the moment there is no tool for people to examinate the patched
> sources without having to know about the patch systems. Maybe a bit of
> Policy on a 'patch' rule for 'debian/rules' and an option --patch for
> 'apt-get source', or 'dpkg-source', would solve this aspect of the
> problem.

See Bug#250202 for more discussion of this than any sane person would ever
want to read.  I think we're moving forward with a documentation
requirement for now, plus mildly standardizing the patch target.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[David Nusinow]

On Mon, Jan 28, 2008 at 04:54:47PM +0100, Daniel Leidert wrote:
> Am Samstag, den 26.01.2008, 19:05 +0100 schrieb Pierre Habouzit:
> > On Sat, Jan 26, 2008 at 04:34:27PM +, David Nusinow wrote:
> > > If we can't figure out a good and clean way to keep a large stack of
> > > long-lived patches in the vcs then I firmly believe we should standardize
> > > on quilt.
> > 
> >   Seconded. I'd add, that in fact we should standardize on quilt as an
> > exchange format for patches, because it's simple, and that there are
> > powerful tools to handle them.
> 
> A question that comes up again and again is, if quilt can handle
> debian-only VCS layouts? Is it able to handle this layout?

What exactly is a debian-only VCS layout? Just the debian directory?

 - David Nusinow


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

Re: How to cope with patches sanely

[Steve Langasek]

On Mon, Jan 28, 2008 at 07:26:41PM -0500, David Nusinow wrote:
> On Mon, Jan 28, 2008 at 04:54:47PM +0100, Daniel Leidert wrote:
> > Am Samstag, den 26.01.2008, 19:05 +0100 schrieb Pierre Habouzit:
> > > On Sat, Jan 26, 2008 at 04:34:27PM +, David Nusinow wrote:
> > > > If we can't figure out a good and clean way to keep a large stack of
> > > > long-lived patches in the vcs then I firmly believe we should 
> > > > standardize
> > > > on quilt.
> > > 
> > >   Seconded. I'd add, that in fact we should standardize on quilt as an
> > > exchange format for patches, because it's simple, and that there are
> > > powerful tools to handle them.
> > 
> > A question that comes up again and again is, if quilt can handle
> > debian-only VCS layouts? Is it able to handle this layout?

> What exactly is a debian-only VCS layout? Just the debian directory?

Yes.

And to answer the original question, sure, quilt can handle it; as well as
any patch management system can handle the fact that the things you're
applying the patches against are external to the VCS and require rain dances
of one sort or another to facilitate patch editing.

-- 
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: How to cope with patches sanely

[Lars Wirzenius]

On ma, 2008-01-28 at 16:05 -0800, Russ Allbery wrote:
> We can't get too rules-bound here. 

As someone who's occasionally done some bug fixing to random packages,
I'd really like to see some solution that allows us to mandate that the
following sequence must work for all source packages:

dpkg-source -x foo_1.2-3.dsc
cd foo-1.2
sensible-editor *
sensible-editor debian/changelog
dpkg-buildpackage -rfakeroot -us -uc

In other words: dpkg-source must unpack sources that can be directly
edited and then dpkg-buildpackage will build a new, modified package
that can be uploaded.

If it's an NMU, then the package's maintainers can get the NMU'd version
and include any changes in it in a way that suits their workflow.

More strict requirements than that is probably bad, since it will make
it harder to innovate in, say, patch systems, source package formats, or
such.




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

Re: How to cope with patches sanely

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> As someone who's occasionally done some bug fixing to random packages,
> I'd really like to see some solution that allows us to mandate that the
> following sequence must work for all source packages:
>
> dpkg-source -x foo_1.2-3.dsc
> cd foo-1.2
> sensible-editor *
> sensible-editor debian/changelog
> dpkg-buildpackage -rfakeroot -us -uc
>
> In other words: dpkg-source must unpack sources that can be directly
> edited and then dpkg-buildpackage will build a new, modified package
> that can be uploaded.
>
> If it's an NMU, then the package's maintainers can get the NMU'd version
> and include any changes in it in a way that suits their workflow.

This work flow simply doesn't work with our current source package format
and a patch management system.  Requiring this to work *with the current
source package format* essentially means outlawing using patch management
systems to manage Debian packages.  That's why this proposal is
controversial.

(No, this doesn't depend on whether one applies the patches in the clean
target.  Consider the NMUer modifying a file that's also modified by two
patches.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[Simon Huggins]

On Mon, Jan 28, 2008 at 05:45:24PM -0800, Russ Allbery wrote:
> Clint Adams <[EMAIL PROTECTED]> writes:
> > On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote:
> >> This work flow simply doesn't work with our current source package
> >> format and a patch management system.  Requiring this to work *with the
> >> current source package format* essentially means outlawing using patch
> >> management systems to manage Debian packages.  That's why this proposal
> >> is controversial.
> > I agree with Lars that we should move toward requiring it to work.
> What I'd like to see is a Debian source package format that supports
> essentially quilt metadata -- in other words, a series file and a set of
> patches.  It's a very minor addition to the current format, and I think
> it's very close to the intention of wig&pen.

Why do you need more than wig&pen?

The meta data can easily be in these version control systems that
everyone on these threads seems to love so much.

If you want to keep more patches than you expose through wig&pen then
just don't publish them in the dsc.

I think all Debian really needs is tools to generate a wig&pen source
package and the appropriate tools to then deal with it e.g. dak and
sbuild updates.

-- 
Simon Huggins  \ - Oh no.  It's closed.
\ - We're not pre-school toys Slinky; we can read.
http://www.earth.li/~huggie/htag.pl 0.0.22


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

Re: dpatch -> quilt (Was: How to cope with patches sanely)

[Paul Wise]

On Jan 28, 2008 8:36 PM, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 10:51:06AM +, Cyril Brulebois wrote:
> > On 28/01/2008, Paul Wise wrote:
> > > maybe edit debian/patches/*.patch to remove all the dpatch comments
> > > and just leave the patch descriptions and other human-readable info.
> > >
> > > QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index"
> >
> > Agreed on --no-index, not convinced by --no-timestamps and -p0.
>
>   -p0 allows patches to all be at the same level, which is just
> consistency but I agree it's not needed. I don't use it.

-p ab is basically equivalent to -p0 in motivation for using it (not
encoding the upstream version number in the filenames), just a matter
of preference which one to use.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: How to cope with patches sanely

[Russ Allbery]

Clint Adams <[EMAIL PROTECTED]> writes:
> On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote:

>> This work flow simply doesn't work with our current source package
>> format and a patch management system.  Requiring this to work *with the
>> current source package format* essentially means outlawing using patch
>> management systems to manage Debian packages.  That's why this proposal
>> is controversial.

> I agree with Lars that we should move toward requiring it to work.

What I'd like to see is a Debian source package format that supports
essentially quilt metadata -- in other words, a series file and a set of
patches.  It's a very minor addition to the current format, and I think
it's very close to the intention of wig&pen.

With that source package format, everyone using quilt or simple-patchsys
can trivially satisfy this requirement, and most uses of dpatch are
similarly trivial.  It doesn't provide all of the power of a git or bzr
package format, but it's a lot easier to implement and I would hope easier
to get consensus on.

I just don't know what's involved in finally deciding on something like
this and making it happen.  We've been having this discussion for years,
and so far we've not made a lot of forward progress.  :/

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[Clint Adams]

On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote:
> This work flow simply doesn't work with our current source package format
> and a patch management system.  Requiring this to work *with the current
> source package format* essentially means outlawing using patch management
> systems to manage Debian packages.  That's why this proposal is
> controversial.

I agree with Lars that we should move toward requiring it to work.


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

Bug#463041: ITP: osc -- OpenSUSE (buildsystem) commander

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: osc
  Version : 0.99
  Upstream Author : Peter Poeml <[EMAIL PROTECTED]>
* URL : http://download.opensuse.org/repositories/openSUSE:/Tools/
* License : GPL
  Programming Lang: Python
  Description : OpenSUSE (buildsystem) commander

Commandline client for the OpenSUSE build service which can be used to
build packages for various RPM and DEB based distributions.

See http://en.opensuse.org/Build_Service/CLI , as well as
http://en.opensuse.org/Build_Service_Tutorial for a general
introduction.

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (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)

iD8DBQFHnoe13DVS6DbnVgQRAq1tAJ42YSSWGJW8ztuGbl3gZi+dXv7v8ACgixNu
Vs0W/Yt1rzxIiJ4wUxeAfD4=
=kXzR
-END PGP SIGNATURE-

Re: Sources of dak ?

[Paul Wise]

On Jan 29, 2008 5:13 AM, Roger Leigh <[EMAIL PROTECTED]> wrote:

> > http://ftp-master.debian.org/bzr/
>
> Why isn't this on bzr.debian.org?

Best address that question directly to the ftpmasters.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Processed: reassign 463018 to mysql-server-5.0, found 463018 in 5.0.32-7etch5

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.13
> reassign 463018 mysql-server-5.0
Bug#463018: problem with cyrillic letter IO and letter case issue in 
utf8_general_ci
Bug reassigned from package `general' to `mysql-server-5.0'.

> found 463018 5.0.32-7etch5
Bug#463018: problem with cyrillic letter IO and letter case issue in 
utf8_general_ci
Bug marked as found in version 5.0.32-7etch5.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: How to cope with patches sanely

[Russ Allbery]

Simon Huggins <[EMAIL PROTECTED]> writes:
> On Mon, Jan 28, 2008 at 05:45:24PM -0800, Russ Allbery wrote:

>> What I'd like to see is a Debian source package format that supports
>> essentially quilt metadata -- in other words, a series file and a set
>> of patches.  It's a very minor addition to the current format, and I
>> think it's very close to the intention of wig&pen.

> Why do you need more than wig&pen?

If wig&pen provides a defined series, then I don't need more than that.  I
don't know enough about wig&pen to tell you whether all the pieces are
already there.

> I think all Debian really needs is tools to generate a wig&pen source
> package and the appropriate tools to then deal with it e.g. dak and
> sbuild updates.

How do we get that?  What do we do now to have this in place for lenny or
at the worst lenny+1?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[Clint Adams]

On Mon, Jan 28, 2008 at 06:58:10PM -0800, Russ Allbery wrote:
> If wig&pen provides a defined series, then I don't need more than that.  I
> don't know enough about wig&pen to tell you whether all the pieces are
> already there.

It does not. To programmatically convert from quilt to a wig&pen
debian.tar.gz, one would need to discard the series file and rename all
the patches.

I don't know whether the effort of adding a series or 00list file to a
dpkg format 2.1 is worthwhile, but it seems like it might make things
easier.


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

que haces bolas

[MAMMON INFO]

 QUÉ HACÉS BOLAS ?

Cómo va boludo, yo acá en la Bristol  "tashenodecabezacuchandocumbia" 
Te clavan la sombrilla arriba de la lona pero todo bien, de vacaciones todo me 
chupa.
Los chicos están con el barrenador en el agua y sho acá me compré un sámbuche 
de salame
y queso con puerto USB, así que "nada", tengo internet en la playa.
Me acabo de bajar gratis el disco de MAMMON, pero no en el emule, o sea los 
pelotudos
subieron el CD gratis en su página. 
Lo estoy escuchando, una cagada tras otra los temas, pero bueno, de vacaciones 
todo me chupa

BAJATE EL DISCO DE MAMMON GRATIS EN
  http://www.mammon.com.ar   
 Y DIFUNDILO ENTRE LOS PELOTUDOS QUE TE RODEAN

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 


 










este mail no es SPAM ya que existe forma de removerlo.
Si no queres mas info de mammon envia un mail vacio a [EMAIL PROTECTED] (con el 
subject: cap) y limpiate el culo con MINERVA




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

Re: changing the default syslog daemon for lenny?

[Michael Biebl]

Patrick Winnertz wrote:

Am Montag, 28. Januar 2008 01:55:23 schrieb Michael Biebl:

rsyslog is also a drop in replacement, even more so, as it can
understand the syntax of sysklogd. The default rsyslog config file
/etc/rsyslog.conf is basically a copy of /etc/syslog.conf.
So if you have a custom syslog.conf, you could either copy it to
/etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf.

rsyslog also allows to include other config files. The default
/etc/rsyslog.conf is setup to include all files in
/etc/rsyslog.d/*.conf.
I would go also for rsyslog. The feature to add configuration files to 
rsyslog without touching configuration files in postinst scripts of other 
packages is really important for some other Debian releated Groups (e.g. 
Debian Edu).




As a (simple) example:

If you want to filter out the messages of e.g. NetworkManager into a 
separate logfile, just drop a file networkmanager.conf into 
/etc/rsyslog.d, containing the line


:programname, contains, "NetworkManager" -/var/log/NetworkManager.log

Packages could ship such files themselves, which would allow for more 
fine-grained logging. rsyslog allows to filter based on a lot more 
properties (and also regexps) [1][2].



Cheers,
Michael

[1] http://www.rsyslog.com/module-Static_Docs-view-f-rsyslog_conf.html.phtml
[2] 
http://www.rsyslog.com/module-Static_Docs-view-f-property_replacer.html.phtml

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature