On Wed, Dec 08, 2004 at 09:16:06PM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > Note that's a "may" and a "should", not a "must". IIRC they only trigger
> > lintian warnings, not errors.
>
> If I tell my son, "You may not go play in the rain.", he knows
> that he can't go play in the rain.
On Thu, 2004-12-09 at 15:49 +0900, Mike Hommey wrote:
> On Wed, Dec 08, 2004 at 09:16:06PM -0600, Ron Johnson <[EMAIL PROTECTED]>
> wrote:
> > > Note that's a "may" and a "should", not a "must". IIRC they only trigger
> > > lintian warnings, not errors.
> >
> > If I tell my son, "You may not go p
On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
> The main technical effect that I see would be that the names of some
> dynamic libraries would change. And compatibility with the old names
> could be maintained indefinitely if necessary.
>
?!??!?!?!?!?!?!"PO!(*"!$*_(!$*"($*!("*$_*!"*$("
On Thu, Dec 09, 2004 at 12:56:23AM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > See RFC 2119. I think usages of may, should, must and stuff should
> > follow these explanations.
>
> There's an RFC for words???
Yes, there is one, to make sure everybody use the words for the same
thing, especi
also sprach Mike Hommey <[EMAIL PROTECTED]> [2004.12.09.0359 +0100]:
> Sounds good.
> Could it be used for dh_striping the content of a package ?
It is an unpacked DEB file, not a Debian source package, so I am not
sure how much use the debhelper suite will be.
--
Please do not send copies of li
On Thu, Dec 09, 2004 at 09:29:57AM +0100, martin f krafft <[EMAIL PROTECTED]>
wrote:
> also sprach Mike Hommey <[EMAIL PROTECTED]> [2004.12.09.0359 +0100]:
> > Sounds good.
> > Could it be used for dh_striping the content of a package ?
>
> It is an unpacked DEB file, not a Debian source package,
Diogo Kollross <[EMAIL PROTECTED]> schrieb:
> I'm replacing files in the maintainer script of a
> package, but I would like to maintain backups of these
> files. Is there any good practice about that (eg: like
> renaming the old file to filename~ or filename.old)?
filename~ looks like an Emacs ba
also sprach Mike Hommey <[EMAIL PROTECTED]> [2004.12.09.0951 +0100]:
> Well, let's say strip, then, wrapped in a little script. If i understood
> correctly what your tool aims at, it would be possible to do that.
Absolutely, yes. You are basically free to change anything within
control.tar.gz and
On Thu, Dec 09, 2004 at 11:55:41AM +0900, Mike Hommey wrote:
> On Wed, Dec 08, 2004 at 11:49:49PM +0100, Bill Allombert <[EMAIL PROTECTED]>
> wrote:
> > The authoritative document is the menu _manual_:
> > (/usr/share/doc/menu/menu.txt.gz), section 3.7
> >
> > An extract from that section:
> >
>
At 10:32 2004-12-09, you wrote:
On Thu, Dec 09, 2004 at 09:24:37AM +0100, Björn Johansson wrote:
> At 16:48 2004-12-08, you wrote:
> >On Wed, Dec 08, 2004 at 04:00:48PM +0100, Björn Johansson wrote:
> >> At 15:46 2004-12-08, you wrote:
> >> >On Wed, Dec 08, 2004 at 02:40:34PM +0100, Björn Johansson
Package: wnpp
Severity: wishlist
Subject: ITP: g-wrap -- Scripting interface generator for C
Package: wnpp
Severity: wishlist
* Package name: g-wrap
Version : 1.9.3
Upstream Author : Andreas Rottmann <[EMAIL PROTECTED]>
Rob Browning <[EMAIL PROTECTED]>
On Wed, Dec 08, 2004 at 01:34:58PM -0800, Scott Robinson wrote:
> As long as Debian is a distribution - a precomposed packaging of as much
> software as possible - then there will be conflicts like this.
Perhaps that's the crux of the problem - an emphasis on quantity
rather than quality.
Hamish
* martin f krafft
| also sprach Scott James Remnant <[EMAIL PROTECTED]> [2004.12.08.0909 +0100]:
| > Generally the dpkg-* namespace is reserved for features that are
| > intended for integration into dpkg at some point.
|
| well, by all means then. If dpkg-repack and dpkg-www are intended
| for
Anthony Towns azure.humbug.org.au> writes:
> Goswin von Brederlow wrote:
[...]
> > Another case that should be considered is the existing use of + for
> > revisions of a cvs snapshot (e.g. mutt uses a + but always does so):
> > 1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1
>
> Hrm, why i
also sprach Tollef Fog Heen <[EMAIL PROTECTED]> [2004.12.09.1351 +0100]:
> | I really think reversion should be available.
>
> I think it's useless,
it's not.
I will probably rename it to debedit.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <
On Thu, Dec 09, 2004 at 01:13:09PM +, Andreas Metzler wrote:
> Anthony Towns azure.humbug.org.au> writes:
> > Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the
> > upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or whatever.
> >
> > It seems to result in rather
Package: wnpp
Severity: wishlist
* Package name: vbetool
Version : 0.1
Upstream Author : Matthew Garrett <[EMAIL PROTECTED]>
* URL : http://www.srcf.ucam.org/~mjg59/laptops/
* License : GPL
Description : run real-mode video BIOS code to alter hardware stat
Andreas Metzler wrote:
Anthony Towns azure.humbug.org.au> writes:
Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the
upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or whatever.
-rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004
pool/main/m/mutt/mutt_1.5.6.ori
On Thu, Dec 09, 2004 at 02:24:33PM +0100, Jeroen van Wolffelaar wrote:
> On Thu, Dec 09, 2004 at 01:13:09PM +, Andreas Metzler wrote:
> > It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead
> > of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can
>
Ron Johnson wrote:
> > See RFC 2119. I think usages of may, should, must and stuff should
> > follow these explanations.
Note that RFC 2119 does not mention the phrase "may not". In American
english it clearly means "is not permitted". For clarity in policy
documents "must not" should be used wh
Hello,
I used to check testing migration with the link
http://bjorn.haxx.se/debian/testing.pl
but the host is no longer found. Does anybody know whether this is just
a temporary problem? Or is there an alternative site?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian
Please, check the following bugs, rename or close them, however you prefer.
1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into Scheme int
2) #263127: O: gwrapguile -- g-wrap: Tool for exporting C libraries into Sche
Thanks,
Thadeu Cascardo
signature.asc
Description: Digital
* Frank Küster ([EMAIL PROTECTED]) [041209 17:25]:
> I used to check testing migration with the link
>
> http://bjorn.haxx.se/debian/testing.pl
>
> but the host is no longer found. Does anybody know whether this is just
> a temporary problem? Or is there an alternative site?
Both nameservers (wh
Frank KÃster debian.org> writes:
> I used to check testing migration with the link
>
> http://bjorn.haxx.se/debian/testing.pl
>
> but the host is no longer found. Does anybody know whether this is just
> a temporary problem? Or is there an alternative site?
Hello,
It worked yesterday, and I've
Hi everyone,
Let me first say unequivocally that the LCC is very interested in
getting Debian involved. The question has always been: How do we do
that? It's one thing for a bunch of companies that can push down
decisions from the top and that already have a great deal in common
(Red Hat lineage,
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> There's only one preconceived notion: that we need a single set of
> binaries, because that's what ISVs and IHVs require for the result to be
> viable. The LCC doesn't mandate the use of RPM (only to the extent the
What makes you think
On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
> On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
>
> > The main technical effect that I see would be that the names of some
> > dynamic libraries would change. And compatibility with the old names
> > could be maintained indef
William Ballard wrote:
What makes you think you'll be any more successful than when the Unix
Consortium tried to do the same thing for Unix?
The members considered that they had proprietary value at the level at
which they were collaborating. We conclusively do not, because of the
Open Source
Bruce,
The history there is much more complex that that; you are
oversimplifying. In fact, with my perspective, the failure occurred
before that, but (un)intended consequences of the Consortium agreement,
which disenfranchised the flourishing community we had built. Pay for
say, and centralized de
Jim Gettys wrote:
Pay for say, and centralized development teams funded by such payers, are a major trap.
Let's make sure to keep giving OSDL that message.
Thanks
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Name changes are a superficial design flaw that obscures the
fundamental design flaw in this proposal -- sharing binaries between
Linux distributions is a bad idea to begin with.
Fixing ABI forks, and articulating best known practices about managing
ABI evolution going forward, that's a good idea.
On Wed, Dec 08, 2004 at 08:30:50PM -0800, Blunt Jackson wrote:
>Having
> "enter" exit the
> selection process (rather than simply selecting the entry) is
> perennially surprising,
And the need to use upper-Q in conflict resolution to keep the selections
one has made manually is also pretty confus
Michael K. Edwards wrote:
Fixing ABI forks, and articulating best known practices about managing
ABI evolution going forward, that's a good idea. Building an open
source test kit that exercises the shared ABIs, validating that the
test kit builds substantially the same on each distro, and helping
On Wed, 8 Dec 2004, martin f krafft wrote:
> also sprach Scott James Remnant <[EMAIL PROTECTED]> [2004.12.08.0909 +0100]:
> > Generally the dpkg-* namespace is reserved for features that are
> > intended for integration into dpkg at some point.
>
> well, by all means then. If dpkg-repack and dpkg-
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> I've been thinking about the "obstacles" for a long time, and I'm
> convinced they're not as large as they might appear at first glance.
> The end goal of the LCC is actually very simple: to create a single
> set of binaries that consti
On Wed, 2004-12-08 at 19:36 -0800, Brian Nelson wrote:
> On Wed, Dec 08, 2004 at 09:26:00PM -0600, Ron Johnson wrote:
> > On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote:
> > > On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > > Get off your ass.
>
On Dec 09, Ian Murdock <[EMAIL PROTECTED]> wrote:
> Let me first say unequivocally that the LCC is very interested in
> getting Debian involved. The question has always been: How do we do
> that?
As usual: by sending patches.
> How does Debian benefit from LCC? It's a route to the ISV and IHV
> c
On Thu, 2004-12-09 at 11:23 -0800, Michael K. Edwards wrote:
> Name changes are a superficial design flaw that obscures the
> fundamental design flaw in this proposal -- sharing binaries between
> Linux distributions is a bad idea to begin with.
>
> Fixing ABI forks, and articulating best known p
Daniel Jacobowitz writes:
> Using binaries from LCC would also run against the Debian principle of
> always building Debian packages from their source before uploading them.
> That's a big deal.
Big enough that I think common binaries should be completely out of the
question for that reason alone.
On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote:
> On Dec 09, Ian Murdock <[EMAIL PROTECTED]> wrote:
>
> > Let me first say unequivocally that the LCC is very interested in
> > getting Debian involved. The question has always been: How do we do
> > that?
> As usual: by sending patches.
So,
If ISVs want "exactly the same", they are free to install a chroot
environment containing the binaries they certify against and to supply
a kernel that they expect their customers to use. That's the approach
I've had to take when bundling third-party binaries built by people
who were under the ill
Package: wnpp
Severity: wishlist
* Package name: autoconf-doc
Version : 2.59
Upstream Author : FSF
* URL : http://www.gnu.org/software/autoconf/
* License : GPL+GFDL
Description : automatic configure script builder documentation
This is the non-free GFDL
|| On Thu, 09 Dec 2004 15:51:15 -0500
|| Ian Murdock <[EMAIL PROTECTED]> wrote:
>> And which I doubt we will get with LCC, since the kernel is the most
>> important piece which needs to be certificated.
im> The common core will include a common kernel. See the FAQ at
im> http://componentizedlinu
[CC'ed Thomas Bushnell, since he has filed an ITA on gwrapguile]
[EMAIL PROTECTED] writes:
> Please, check the following bugs, rename or close them, however you prefer.
>
>
> 1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into...
>
> 2) #263127: O: gwrapguile -- g-wrap: Tool fo
On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote:
> As one of the maintainers involved in Debian's toolchain, I think this
> is a terrible idea. Our needs are different than other distributions,
> we already know that from experience. The core needs are conceptually
> the same - everyon
The most high and most honorable Ian Murdock wrote:
> Hi everyone,
Hi Back at you.
> Let me first say unequivocally that the LCC is very interested in
> getting Debian involved. The question has always been: How do we do
> that? It's one thing for a bunch of companies that can push down
> decisio
Ian Murdock <[EMAIL PROTECTED]> writes:
> On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
>> On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
>>
>> > The main technical effect that I see would be that the names of some
>> > dynamic libraries would change. And compatibility wi
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote:
> Second, the common core will have a release schedule corresponding to
> the release schedule of the LSB standard (roughly every 12-18 months),
> and the members' release schedules will be synchronized to match that.
So given that Debia
Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 08, 2004 at 08:30:50PM -0800, Blunt Jackson wrote:
>>Having
>> "enter" exit the
>> selection process (rather than simply selecting the entry) is
>> perennially surprising,
>
> And the need to use upper-Q in conflict resolution to keep the s
Ian Murdock <[EMAIL PROTECTED]> writes:
> On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote:
>> On Dec 09, Ian Murdock <[EMAIL PROTECTED]> wrote:
>> > How does Debian benefit from LCC? It's a route to the ISV and IHV
>> > certifications that Debian has always lacked, and it is the lack of
>>
Greg Folkert wrote:
I will strongly oppose any shared binaries. I don't want any RPM shoved down my
throat.
One is not equal to the other. It's entirely possible to have a single
package source that builds into both RPM and DEB.
I would like to use see a shared usage of the same Source Core
Yes
Steinar H. Gunderson wrote:
So given that Debian's release schedule once again slips past 18 months, do
we have to wait another 18 months to get etch out?
I don't see why, we don't do that for X or GNOME or anything else.
But some of us don't want to see Debian's release schedule slip again. I
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10
> will have the patch applied, as it is already in CVS, both in HEAD and
> the 1.8 branch) when you apply the attached patch.
Just so you know, it's really my intention not to have
Patrzę w ekran, a to Goswin von Brederlow pisze do mnie:
> Don't get me wrong, I think a common kernel would be great. I just
> don't think Debians standards will go well with the commercial
> distributions.
Not necessary. If the common kernel would not suit best for the debian it
would always be
On Thu, Dec 09, 2004 at 11:08:53PM +0100, Florent Rougon wrote:
> I've always thought that people who say they hate dselect (or, worse,
> that dselect is crap) fall into one of the following cases:
>
> (a) allergic to text-mode interfaces
> (b) type or click without thinking
> (c) haven't used
Goswin von Brederlow wrote:
And how will you get the other members to support architectures they do not support?
They would have to support merging in of source-code changes for all
architectures that any member builds. They would not be called upon to
compile those architectures.
And that i
Miles Bader <[EMAIL PROTECTED]> wrote:
> The current aptitude, by contrast, seems both powerful and elegant: it
> rarely gets in my way, deals well with problem situations, and offers
> powerful features should I want them (aptitude of years past could also
> be kinda cranky though).
The last time
On Thu, Dec 09, 2004 at 02:25:28PM -0800, Bruce Perens wrote:
>> So given that Debian's release schedule once again slips past 18 months, do
>> we have to wait another 18 months to get etch out?
> I don't see why, we don't do that for X or GNOME or anything else.
Then I don't see what you mean by
Steinar H. Gunderson wrote:
Then I don't see what you mean by "synchronization".
You use the LCC version available to you at the time you release,
whatever that is. It may make sense for you to schedule your release to
come some months after the LCC's, but I can't see that you have to do
ever
Package: general
Version: 20041209
Severity: normal
The program
#include
#include
#include
#include "gmp.h"
int main(int argc, char** argv)
{
mpz_t A,B,C;
gmp_randstate_t state;
gmp_randinit_default(state);
gmp_randseed_ui(state, 3);
mpz_urandomb(A, state
On Thu, 2004-12-09 at 14:33 -0600, John Hasler wrote:
> Daniel Jacobowitz writes:
> > Using binaries from LCC would also run against the Debian principle of
> > always building Debian packages from their source before uploading them
On Thu, Dec 09, 2004 at 11:08:53PM +0100, Florent Rougon wrote:
> > And the need to use upper-Q in conflict resolution to keep the selections
> > one has made manually is also pretty confusing.
> Er, these are shortcuts. *shrug*
Uh, so there is a non-shortcut method of operating?
> management (I
On Thu, Dec 09, 2004 at 10:27:50PM +, Roger Lynn wrote:
> The last time I used aptitude (about six months ago, from Testing), I
> found it difficult to specify how I wanted dependencies
You just use "g" and resolve the dependencies? (Kind of same as in dselect)
Greetings
Bernd
--
(OO)
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> I can imagine many of you are thinking, "What difference does it
> make if Debian has the support of proprietary software vendors?"
> Ok. If attracting ISV and IHV support to Debian isn't a worthwhile
> goal in itself, how about helping
On Thu, Dec 09, 2004 at 03:10:52PM -0500, Daniel Jacobowitz wrote:
> We would never have a common kernel with these vendors anyway - they
No does Debian with itself :P
On Thu, Dec 09, 2004 at 02:33:30PM -0600, John Hasler wrote:
> Why don't standard ABIs suffice?
Not that I'm necessarily arguing in favour of a set of common packages, but
defining an ABI is not a sufficient condition to ensure compatibility.
Consider a function int s(int, int) -- you can have tw
On Thu, Dec 09, 2004 at 03:51:15PM -0500, Ian Murdock wrote:
> The common core will include a common kernel. See the FAQ at
> http://componentizedlinux.org/lsb/: "Importantly, the LCC platform
> will include a common kernel, eliminating one of the largest sources
> of incompatibilities between Linu
Matthew Palmer writes:
> Consider a function int s(int, int) -- you can have two ABI-compatible
> versions of this, one that adds it's arguments and one that multiplies
> them. ABI compatible, but different results.
And different APIs. Is that really a serious risk?
> ...who's to say that some
Thomas Womack <[EMAIL PROTECTED]> writes:
> Package: general
> Version: 20041209
> Severity: normal
>
> The program
>
> #include
> #include
> #include
> #include "gmp.h"
Do you have libgmp2-dev or libgmp3-dev installed?
> in
Bruce Perens <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>
>>And that is without mentioning the non-free ness and license issues coming up
>>after sarge. The firmware blobs and the like.
>>
>>
> The whole system has to be DFSG-free. Debian won't compromise on that.
>
> I have been t
On Thu, 09 Dec 2004 17:20:00 -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> libfoo 1.7 fixes a non-security bug in v1.6. "bar" segfaults when
> running libfoo 1.6. But libfoo 1.6 is in Sarge, and the bug won't
> be fixed because it's not a security bug.
Having a formal GNU/Linux Distro Test Ki
On Fri, 10 Dec 2004, Goswin von Brederlow wrote:
> As for distributing the blobs itself they can be relicensed under
> BSD license or similar (if their aren't already) that doesn't have
> such a problem with a char data[] = { 0x17, ... } source file,
> something without the prefered source form cla
Florent Rougon <[EMAIL PROTECTED]> writes:
> I've always thought that people who say they hate dselect (or, worse,
> that dselect is crap) fall into one of the following cases:
>
> (a) allergic to text-mode interfaces
> (b) type or click without thinking
> (c) haven't used it for more than 5 yea
On Thursday 09 December 2004 06:35 pm, Bernd Eckenfels wrote:
> On Thu, Dec 09, 2004 at 10:27:50PM +, Roger Lynn wrote:
> > The last time I used aptitude (about six months ago, from Testing), I
> > found it difficult to specify how I wanted dependencies
>
> You just use "g" and resolve the dep
Bruce Perens <[EMAIL PROTECTED]> writes:
> You use the LCC version available to you at the time you release,
> whatever that is. It may make sense for you to schedule your release to
> come some months after the LCC's, but I can't see that you have to do
> everything modulo 18 months.
I think thi
On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote:
> Bruce Perens <[EMAIL PROTECTED]> writes:
>
> I think that tying core Debian packages to the Red Hat boat anchor is a
> horrible, horrible idea.
I tend to agree with sentiments like this, but didn't Bruce mention
that we could partici
Miles Bader dijo [Fri, Dec 10, 2004 at 11:52:05AM +0900]:
> Completely and utterly wrong in my case. I'm exactly the sort of person
> that you apparently think should like dselect, but I think aptitude is
> _far_ superior, for both experts and newbies. The competition isn't even
> close.
ME TOO!
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote:
> On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote:
> > As one of the maintainers involved in Debian's toolchain, I think this
> > is a terrible idea. Our needs are different than other distributions,
> > we already know that f
John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]:
> > I think that tying core Debian packages to the Red Hat boat anchor is a
> > horrible, horrible idea.
>
> I tend to agree with sentiments like this, but didn't Bruce mention
> that we could participate in this organization even if we di
Ian Murdock dijo [Thu, Dec 09, 2004 at 04:42:29PM -0500]:
> > We would never have a common kernel with these vendors anyway - they
> > don't even have a common kernel with each other. My experience tells
> > me that would be a big barrier to certification of any kind.
>
> The LCC core will includ
Greg Folkert wrote:
Many reasons people come to Debian... Distributed Binaries is not one of
them.
If you think this isn't a reason to use Debian, I, as a long-time user, will tell you that
you're dead wrong. I use Debian because there exist packages for most every popular piece
of free software
Hello all,
At the start of next year FOSDEM, the most important Belgian Free
Software event will be back again. As on the previous occasions there
will also be an embedded track, for which we are looking for speakers.
All the necessary info can be found in the following call for papers.
Feel free
On Thu, Dec 09, 2004 at 10:04:53PM +0100, Philippe De Swert wrote:
> Hello all,
Hi,
My eye just caught a few small items. For the rest, this is plain good work,
Peter
> (e.g. reverse engineering, porting too (and adapting of) commercial
^^^
83 matches
Mail list logo
