Re: SVG icons

[Mike Hommey]

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.


If you tell your som, "You must not go play in the rain", it's the best
way to be sure he'll be doing it ;)


> Thus, "may" in this context is ambiguous.  "Should" is only slightly
> less so.

See RFC 2119. I think usages of may, should, must and stuff should
follow these explanations.

Mike

Re: SVG icons

[Ron Johnson]

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 play in the rain.", he knows 
> > that he can't go play in the rain.
> 
> 
> If you tell your som, "You must not go play in the rain", it's the best
> way to be sure he'll be doing it ;)
> 

The best way to be sure he'll *want* to do it.  He knows the 
consequences of disobeying a direct order can be "unpleasant".

> > Thus, "may" in this context is ambiguous.  "Should" is only slightly
> > less so.
> 
> See RFC 2119. I think usages of may, should, must and stuff should
> follow these explanations.

There's an RFC for words???

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

Clueless "tech" journalists drive geeks crazy



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

Re: Linux Core Consortium

[Scott James Remnant]

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!(*"!$*_(!$*"($*!("*$_*!"*$("

That is all.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Re: SVG icons

[Mike Hommey]

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, especially when people in a project doesn't share the same mother
tongue. For instance, mine is french, and distinction between "may" and
"should" is sometimes awkward to me.

Mike

Re: dpkg-reversion: how about debedit?

[martin f krafft]

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 list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: dpkg-reversion: how about debedit?

[Mike Hommey]

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, so I am not
> sure how much use the debhelper suite will be.

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.

Mike

Re: Backups in maintainer scripts

[Frank Küster]

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 backup file, and I routinely delete them
when I find some. I would suggest to use an extension that clearly
indicates "Whodunit" - I use ".postinst-bak" (or ".preinst-bak" etc.). 

> I would also like to know if dpkg makes any backups
> when installing packages, and if I can rely on them
> being present when removing a package.

It takes care that no files are lost in the unpacking phase - if
unpacking fails for some reason, dpkg stops and you end up with only the
old files installed. But after that, all memory of older versions are
removed, except that files that were conffiles in the old version and
are nonexistant in the new one are kept.

The .dpkg-old and .dpkg-new files come from conffile handling, see 10.7
in the Policy.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dpkg-reversion: how about debedit?

[martin f krafft]

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 data.tar.gz, and these two are already properly
unpacked to ./DEBIAN and . respectively.

Just try it out:

  dpkg-reversion -k sh some_file.deb

This will execute a shell and allow you to modify to your heart's
content.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: SVG icons

[Bill Allombert]

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:
> > 
> >  Debian package maintainers should ensure that any icons they include
> >  for use in the Debian menus conform to the following points:
> > 
> >  1.   The icons should be in xpm format.
> > 
> >  2.   The icons may not be larger than 32x32 pixels, although smaller
> >   sizes are ok.
> 
> Note that's a "may" and a "should", not a "must". IIRC they only trigger
> lintian warnings, not errors.

Should I *really* upload a new menu manual with s/should/must ?

Debian policy convention are that violating a should is a normal bug,
violating a must is a serious bug:

 In the normative part of this manual, the words _must_, _should_ and
 _may_, and the adjectives _required_, _recommended_ and _optional_,
 are used to distinguish the significance of the various guidelines in
 this policy document.  Packages that do not conform to the guidelines
 denoted by _must_ (or _required_) will generally not be considered
 acceptable for the Debian distribution.  Non-conformance with
 guidelines denoted by _should_ (or _recommended_) will generally be
 considered a bug, but will not necessarily render a package unsuitable
 for distribution.  Guidelines denoted by _may_ (or _optional_) are
 truly optional and adherence is left to the maintainer's discretion.

 These classifications are roughly equivalent to the bug severities
 _serious_ (for _must_ or _required_ directive violations), _minor_,
 _normal_ or _important_ (for _should_ or _recommended_ directive
 violations) and _wishlist_ (for _optional_ items).  [2]

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

Imagine a large red swirl here. 

Re: Still no 3D acceleration in Sarge..

[Björn Johansson]

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 wrote:
> >> >>
> >> >> Hello!
> >> >>
> >> >> I still have problems getting 3D acceleration in Sarge.
> >> >> I've attached the log file.
> >> >>
> >> >> Anybody who has any suggestions?
> >> >>
> >> >> Computer: Apple Powerbook G3 "Lombard"
> >> >> Graphics: ATi Rage 16MB
> >> >> X-server: Xfree86 4.3
> >> >>
> >> >> I think I need unofficial drivers or something, I don't know.
> >> >
> >> >Try configuring correctly your X server, the below log says that your
> >> >configuration file is broken, and not much more. Please provide it 
also.
> >> >
> >> >Friendly,
> >> >
> >> >Sven Luther
> >>
> >> Ok, now it's working, again, but with no 3d acceleration.
> >> I've attached the log file.
> >
> >You are missing the kernel mach64 drm module it seems. I think this 
module
> >is
> >not available in the current kernel :
> >
> >CONFIG_AGP=m
> >CONFIG_AGP_UNINORTH=m
> >CONFIG_DRM=y
> >CONFIG_DRM_TDFX=m
> ># CONFIG_DRM_GAMMA is not set
> >CONFIG_DRM_R128=m
> >CONFIG_DRM_RADEON=m
> >CONFIG_DRM_MGA=m
> >CONFIG_DRM_SIS=m
> >
> >I would consider asking this question on the dri-devel mailing list (on
> >sourceforge i think), and fill a bug report against the debian kernels
> >
> >> When I used Debian on my Amiga4000 I had to enable glint to get
> >> 2D acceleration. Is 2D acceleration default nowadays? :-/
> >
> >Sure. 3D acceleration is not available on glint though.
> >
> >Friendly,
> >
> >Sven Luther

What do you guys know about this?
Björn Johansson

ITP: g-wrap -- Scripting interface generator for C

[Andreas Rottmann]

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]>
Christopher Lee <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/g-wrap
* License : LGPL
  Description : Scripting interface generator for C

A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.

G-Wrap takes a set of interface declarations (written in Scheme) and
wraps the described interface for Guile.



This is the sucessor of G-Wrap 1.3.4 (packaged as libgwrapguile-dev and 
libgwrapguile). It is packaged as a new source package since G-Wrap 1.3.4
is still needed to build GnuCash, although GnuCash CVS has received patches
to allow building with G-Wrap 1.9.x, so the old G-Wrap packages can be 
faded out sometime after the release of GnuCash 1.8.10.

The source package g-wrap will procduce the following binary packages:

Package: g-wrap
Architecture: any
Depends: guile-1.6, guile-1.6-slib, guile-library (>= 0.1.1), 
libgwrap-runtime0-dev (= ${Source-Version})
Conflicts: gwrapguile-dev
Description: Scripting interface generator for C
 A tool (and Guile library) for generating function wrappers for
 inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 G-Wrap takes a set of interface declarations (written in Scheme) and
 wraps the described interface for Guile.

Package: libgwrap-runtime0-dev
Section: libs
Architecture: any
Depends: libgwrap-runtime0 (= ${Source-Version}), libffi3-dev, libc6-dev
Description: Scripting interface generator for C - runtime
 A tool (and Guile library) for generating function wrappers for
 inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 This package contains the development files for the runtime shared
 libraries.

Package: libgwrap-runtime0
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - runtime
 A tool (and Guile library) for generating function wrappers for
 inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 This package contains the runtime shared library.

Package: guile-g-wrap
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - Guile runtime
 A tool (and Guile library) for generating function wrappers for
 inter-language calls. It currently only supports generating Guile
 wrappers for C functions.
 .
 This package contains the Guile standard wrapset, needed by Guile
 bindings generated by G-Wrap.

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Hamish Moffatt]

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
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file

[Tollef Fog Heen]

* 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 integration into dpkg, then reversion should be too.

Three wrongs does not make a right (or one and a half right or
anything.)

| I really think reversion should be available.

I think it's useless, but if you're going to upload it anyhow, please
don't use the dpkg-* namespace.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: binary NMUs and version numbers

[Andreas Metzler]

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 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.orig.tar.gz
> -rw-rw-r--   16 katiedebadmin   412082 Nov 17 10:17
>pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz
> 
> It seems to result in rather large diffs, and I can't really see the 
> benefit?
[...]

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
upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915.
   cu andreas

Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file

[martin f krafft]

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 <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: binary NMUs and version numbers

[Jeroen van Wolffelaar]

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 large diffs, and I can't really see the 
> > benefit?
> 
> 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
> upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915.

This bandwith consideration is nice, but IMHO in no way is anywhere near
as important as the property that you can find Debian-specific changes
in the .diff.gz, and upstream sources in the .orig.tar.gz. It's quite
difficult to find out what was changed in Debian and what's directly
from upstream CVS this way. .orig.tar.gz size only matters (marginally)
for mirrors and developers downloading mutt's sources. As bandwith &
diskspace is cheap compared to developer time, I think it's much more
important to keep the upstream/Debian specific separation that is
intended with .orig.tar.gz/.diff.gz.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Bug#284909: ITP: vbetool -- run real-mode video BIOS code to alter hardware state

[Matthew Garrett]

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 state

vbetool uses lrmi in order to run code from the video BIOS. Currently, 
it is able to alter DPMS states, save/restore video card state and 
attempt to initialize the video card from scratch.

vbetool is primarily useful for attempting to recover from ACPI S3, 
since most hardware leaves the video card in an undefined state. 
Since it uses vm86, it will currently only work on x86 hardware - in the 
long run, I'd hope to move it over to Scitech's x86emu and give it more 
portability. It's also currently in the form of three separate tools, 
but I'll merge those in the near future.

Currently, the combination of:

switch away from X
vbetool savestate >foo
vbetool dpms off
(suspend)
vbetool post
vbetool restorestate 

Re: binary NMUs and version numbers

[Anthony Towns]

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.orig.tar.gz
-rw-rw-r--   16 katiedebadmin   412082 Nov 17 10:17
  pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz
It seems to result in rather large diffs, and I can't really see the 
benefit?
It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead
  ^^
(trade off)
of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can
upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915.
Hrm, there seem to have been nine versions since the 1.5.6 orig was 
uploaded in May. The total sizes of the version (source, and all debs 
for all architectures), and the size of the .diff.gz's seem to be:

1.5.6-1:  17109678  59577
1.5.6-20040523+1:  1382297 102196 +3M -  40k
1.5.6-20040523+2: 15671819 102236 -  40k
1.5.6-20040722+1: 14633689 154874 +3M - 100k
1.5.6-20040722+2: 11890401 155978 - 100k
1.5.6-20040803+1: 14647304 301927 +3M - 250k
1.5.6-20040818+1: 14940217 313439 +3M - 250k
1.5.6-20040907+1: 15118784 409724 +3M - 350k
1.5.6-20040907+2: 15131102 412082 - 350k
Uploading a new 3M .orig.tgz for each CVS update would introduce 3M 
uploads every now and then, but reduce the .diff down to 60k (or less?), 
so doing it that way would cost 15MB in orig.tgz uploads, and save 
something like 1.5MB in diffs. So 13.5MB extra from a total of 120MB, so 
that's about an extra 11%.

Dunno that that's really worth it. Pity we don't support more than two 
files to build up the source we want in a more fine grained way.

Cheers,
aj

Re: binary NMUs and version numbers

[Daniel Kobras]

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
> > upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915.
> 
> This bandwith consideration is nice, but IMHO in no way is anywhere near
> as important as the property that you can find Debian-specific changes
> in the .diff.gz, and upstream sources in the .orig.tar.gz. It's quite
> difficult to find out what was changed in Debian and what's directly
> from upstream CVS this way. .orig.tar.gz size only matters (marginally)
> for mirrors and developers downloading mutt's sources. As bandwith &
> diskspace is cheap compared to developer time, I think it's much more
> important to keep the upstream/Debian specific separation that is
> intended with .orig.tar.gz/.diff.gz.

I tend to agree for vanilla diff.gz files. A lot of packages are using
patch systems these days, however, that provide alternative means to
distinguish the origins of patches. The mutt package, for instance,
separates them in upstream/patches, debian/patches etc. For my own
packages, I usually add a "CVS" suffix to the patch name and a note to
the comment section. Which should be clear enough for anyone looking at
the package source, and keeps the orig.tar.gz always at a released
upstream version.

Regards,

Daniel.

Re: SVG icons

[John Hasler]

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 when the intent is to state that
something is not permitted.  If the intent is to say that one has the
choice of doing or not doing something structure the sentence so as to use
"may" or "optional".  Don't use "may not" to mean "you can leave this out
if you want to".  It might be best to not use it at all as it seems to
engender some confusion.

Note also that the RFC says the the imperatives it defines should be used
sparingly.
-- 
John Hasler

"Why is package X not in testing yet" - where's the page

[Frank Küster]

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 Developer

Re: ITP: g-wrap -- Scripting interface generator for C

[cascardo]

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 signature

Re: "Why is package X not in testing yet" - where's the page

[Andreas Barth]

* 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 (which are just one ip-adresses next to each other) are
not found currently.

If the author wants, I'd offer secondary DNS servers. Also, we might
perhaps consider to integrate these scripts into pts or on release.d.o.



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: "Why is package X not in testing yet" - where's the page

[Andreas Metzler]

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 no idea what the status of the /site/ actually is
because the nameservers for haxx.se seem to be down.
   cu andreas

Re: Linux Core Consortium

[Ian Murdock]

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, RPM-based package management, etc.) to join forces to
address a common problem; it's quite another for a decentralized
community project that evolved very differently over the years. Still,
I contend Debian shares those common problems (most notably, lack of
support from ISVs and IHVs), and furthermore, that the "common
cause" is much more achievable with Debian's support than without it.

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 constitute an implementation of the LSB
standard; to use that single set of binaries as a "common core"
for as many Linux distributions as possible; and to develop the
common core in an open and collaborative fashion, so the end result
is owned by the community, not by one or two commercial players.

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
LSB does, which Debian can already address). The LCC doesn't mandate
what "compatibility" means as regards package naming or library
versioning or anything else--it only says we need to agree on
*something*, because agreeing on something buys us a lot, whereas
continuing to differ on such minor things doesn't serve any purpose
other than to divide us and set the stage for one or two companies
to run away with commercial Linux via ISV/IHV certification lock-in.

If you're having trouble picturing how Debian might engage the LCC,
here's my ideal scenario: the source packages at the core of
Debian are maintained in collaboration with the other LCC members,
and the resulting binaries built from those source packages are made
available in both RPM and .deb format. Care would have to be taken to
ensure that the resulting RPM- and Debian-based versions of the common
core are compatible. The two main problems I anticipate here are package
namespace and file system differences--the RPM-based distros might call
the package that contains /lib/libacl.so.1.1.0
"acl", whereas the Debian-based distros might call it "libacl1", both
for reasons of historical compatibility; and differences in such
things as network configuration (Debian's /etc/network vs.
RH's /etc/sysconfig/network) would need to be addressed as well.

Furthermore, both sets of binary packages would need to understand what
the other expects for compatibility between the two sets--e.g., the
Debian packages would need to understand that "acl" == "libacl1", and
the RPM packages would need to be able to deal with programs that want
to configure the network via /etc/network/interfaces. I see many of
these issues as being addressed in a "compatibility layer" of sorts.
Note that this last set of issues is not unique to the RPM vs. Debian
question--it also exists within the RPM world as well. The RPM distros
have evolved in different directions as well, albeit for a shorter
period of time--Conectiva does things differently than Mandrakesoft,
and Mandrakesoft does things differently than Turbolinux, etc. etc..

Of course, my ideal scenario is a huge step, and it can't be taken all
at once. As Bruce points out, though, it doesn't *have* to be taken all
at once. The LCC is in the early stages, and many of the decisions that
will affect the ultimate ability to reach the ideal scenario are being
made now; furthermore, the vast majority (if not all) of these decisions
will happen at the "compatibility layer" level. Finally, because the LCC
is a collaborative effort, the groups involved will ultimately
determine the direction of the effort as a whole. With more Debian
voices at the table, who knows what that direction might be...

Technical details aside, it all comes down to the question: Is getting
involved worthwhile? As I said at the outset, the LCC has a lot to
offer Debian, and likewise, Debian has a lot to offer the LCC as well.

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
these certifications that's preventing Debian from standing alongside
Red Hat and Novell/SuSE in the commercial space despite comparable
(and arguably greater) popularly. The industry simply doesn't know how
to engage us, and LCC provides them with a vehicle for doing that.

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 ensu

Re: Linux Core Consortium

[William Ballard]

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 you'll be any more successful than when the Unix 
Consortium tried to do the same thing for Unix?

Re: Linux Core Consortium

[Ian Murdock]

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 indefinitely if necessary.
> > 
> ?!??!?!?!?!?!?!"PO!(*"!$*_(!$*"($*!("*$_*!"*$("
> 
> That is all.

Well, that's certainly constructive.

Can someone provide an example of where the name of a dynamic
library itself (i.e., the one in the file system, after the
package is unpacked) would change? I'd be surprised if this was
a big issue. The LSB/FHS should take care of file system level
incompatibilities already (though Debian may put some things in
/lib that RPM-based distros put in /usr/lib due to more strict policy
about such things), so I'd think the main issue wouldn't so much be
about the names of the dynamic libraries themselves, but the names of
the packages they come in (acl vs. libacl1, as per my last message).

The bottom line is that the differences between the distributions
are much smaller than you might think. Remember, we all share the
same upstream sources for our software. And, after an initial
rough comparison of Conectiva, Mandrakesoft, Turbolinux, and
Debian sarge, we're surprisingly close to not only using the same
upstream sources, but also the same versions of those upstream
sources too. So, increasing compatibility is mostly about using
the same versions of stuff, and making sure we have the glue
in place to deal with any differences in file system layout
and package namespace in the binary packages built from them.

I expect configuration issues to be more significant than namespace
issues such as this (mostly /etc stuff).

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence

Re: Linux Core Consortium

[Bruce Perens]

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 nature of the software.

About the worst occurrance in the entire saga was the day that the X 
Consortium got together and decided that there would be no canonical X 
widget set, so that they could all differentiate from each other at that 
level. So, everyone had to turn to Microsoft to provide a canonical 
widget set on top of other manufacturer's hardware, and MS ate the X 
consortium's lunch.

   Thanks
   Bruce


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Linux Core Consortium

[Jim Gettys]

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 development teams funded by such payers, are a
major trap.

Equally important, however, was that UNIX went to the high end, where
there was profit to be made in the short term (but no volume), and M$
went to the low end, where there was volume, and eventual major profit.

That being said, certainly UNIX's disunity was a major aid to Microsoft.
Repeating that history would not be good.

- Jim


On Thu, 2004-12-09 at 10:53 -0800, Bruce Perens wrote:
> 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 nature of the software.
> 
> About the worst occurrance in the entire saga was the day that the X 
> Consortium got together and decided that there would be no canonical X 
> widget set, so that they could all differentiate from each other at that 
> level. So, everyone had to turn to Microsoft to provide a canonical 
> widget set on top of other manufacturer's hardware, and MS ate the X 
> consortium's lunch.
> 
> Thanks
> 
> Bruce

Re: Linux Core Consortium

[Bruce Perens]

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

Re: Linux Core Consortium

[Michael K. Edwards]

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.  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
ISVs resolve issues that the test kit missed (and add them as new test
cases), that's even better.  But if two competent packagers, working
on different distros, can't get the same ABI out of the same source
code, then upstream's build procedures are badly broken -- and I don't
want that papered over by passing binaries around!

>From the point of view of a user of commercial software, I want to do
business with ISVs that take responsibility for the proper functioning
of their software on a system that is "reasonably compatible" with
their anticipated target environment.  Exposed ABIs, as verified by a
test kit, are an appropriate standard of "reasonably compatible". 
It's in everyone's interest for that test kit to be correct and
thorough, which is a good thing, because it's a lot of work to build
and maintain it.

I prefer open source platforms for a number of reasons.  One is that
it's the source code, not any particular binary, that is authoritative
about how things should work.  In principle, one can bug-fix and
rebuild any components in any order without breaking the system.  My
experience has been that the more faithful a distro is to this
principle, and the more work is put into abiding by it, the more
likely it is that I will be able to use its binaries unaltered! 
That's one reason why I choose Debian when I have the option.

ISVs and IHVs who think that binaries shared among distros will help
them manage tech support costs and quality issues aren't thinking
along these lines, perhaps because testimonials like mine tend to be
anecdotal.  Maybe they could be persuaded by quantitative evidence. 
I'm not in a great position to gather that evidence; perhaps someone
else is?

Cheers,
- Michael

Re: dselect survey

[Bernd Eckenfels]

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

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Linux Core Consortium

[Bruce Perens]

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
ISVs resolve issues that the test kit missed (and add them as new test
cases), that's even better.  But if two competent packagers, working
on different distros, can't get the same ABI out of the same source
code, then upstream's build procedures are badly broken -- and I don't
want that papered over by passing binaries around!
If we could all share the same source packages and a tool set with the 
same calling conventions, we'd be very far in the direction of what LCC 
wishes to achieve. The fact is that Debian would have to stop there for 
most of its architectures, simply because most of our architectures are 
not in common with the rest of LCC.

I think it would be great to get this far. At that point we could decide 
if there is any purpose in using the same compile as other folks.

   Thanks
   Bruce


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file

[Adam Heath]

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-www are intended
> for integration into dpkg, then reversion should be too.

Probably yes on dpkg-repack.  Definately not for dpkg-www.  Which is a sucky
name, btw.

Re: Linux Core Consortium

[Daniel Jacobowitz]

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 constitute an implementation of the LSB
> standard; to use that single set of binaries as a "common core"
> for as many Linux distributions as possible; and to develop the
> common core in an open and collaborative fashion, so the end result
> is owned by the community, not by one or two commercial players.
> 
> 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
> LSB does, which Debian can already address). The LCC doesn't mandate
> what "compatibility" means as regards package naming or library
> versioning or anything else--it only says we need to agree on
> *something*, because agreeing on something buys us a lot, whereas
> continuing to differ on such minor things doesn't serve any purpose
> other than to divide us and set the stage for one or two companies
> to run away with commercial Linux via ISV/IHV certification lock-in.

Disclaimer: I have not gone looking for any information about the Linux
Core Consortium outside of this thread.  It would have been nice to
include a link:
  http://www.mandrakesoft.com/lcc
Of course, there's not much there.  Oh, here's some more:
  http://componentizedlinux.org/lsb

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 - everyone needs working libraries and tools - but the details
we consider worth fixing are not.

Common binaries are only useful with fixed releases and versioning of
the common binaries, because otherwise you have a dozen different sets
of your "common" binaries running around.  So during the sarge release
cycle, when we need to make updates to fix an RC bug in glibc that
doesn't affect any platform shipped by any other member of the LCC,
which has moved on to new development according to some other member's
release schedule, what would we do?  We'd have to rebuild them anyway.
There goes our "common binaries" advantage.

>From the web site, I see that LCC has a limited set of architectures
targeted anyway.  Debian will continue to use common source for all
architectures.  That will make working with the LCC difficult.

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.

I'm sure other members of the LCC have similar concerns - or will. 
What are they doing about them?

Are the other companies listed as "supporting" the Linux Core
Consortium interested in this "common binaries" plan?  Their support
quotes only explicitly support the Linux Standard Base.

I see primarily scheduling, maintenance, coordination, and change
control problems.

> Technical details aside, it all comes down to the question: Is getting
> involved worthwhile? As I said at the outset, the LCC has a lot to
> offer Debian, and likewise, Debian has a lot to offer the LCC as well.
> 
> 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
> these certifications that's preventing Debian from standing alongside
> Red Hat and Novell/SuSE in the commercial space despite comparable
> (and arguably greater) popularly. The industry simply doesn't know how
> to engage us, and LCC provides them with a vehicle for doing that.

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.

There's plenty more than certification keeping Debian from standing
along side enterprise distributions in the commercial space.

If there is merit to the common binaries, I think we would get more
mileage from it by supporting them as we do the LSB: with separate
packages on top of the Debian base system.

-- 
Daniel Jacobowitz

Re: Status of this ITP?

[Greg Folkert]

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.
> > > 
> > > Ah. I see. Courtesy is not your strong point.
> > 
> > His parents must not have taught him manners.  Or he knows that
> > he can't get beat up by people who don't see him face-to-face.
> 
> Here, go find him:
> 
> http://www.acs.rutgers.edu/directory/

Why thank you.

> LUIS R. RODRIGUEZ 
> (STUDENT) 
>
>
>
>
>  IID:
> LRR32
>
>
>
>
> EMAIL ADDRESS:
>
>
> Student:
>   [EMAIL PROTECTED]
>
>
>
>
>POSTAL ADDRESS:
>
> Student:
> 34739 RPO WAY
>
>
>
>
>STUDENT
>  INFORMATION:
>
>  School:
>Rutgers College
>
> Academic
>   Major(s):
>English
>
> Academic
>   Minor(s):
>  P Rican Hisp
>  Carib Study
>
>
> Cinema Studies
>
>  Year of
>  Graduation:
>   05

-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster: Linux


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

Re: Linux Core Consortium

[Marco d'Itri]

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
> certifications that Debian has always lacked, and it is the lack of
And which I doubt we will get with LCC, since the kernel is the most
important piece which needs to be certificated.

-- 
ciao, |
Marco | [9673 deUYnWbve8slc]


signature.asc
Description: Digital signature

Re: Linux Core Consortium

[Ian Murdock]

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 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
> ISVs resolve issues that the test kit missed (and add them as new test
> cases), that's even better.  But if two competent packagers, working
> on different distros, can't get the same ABI out of the same source
> code, then upstream's build procedures are badly broken -- and I don't
> want that papered over by passing binaries around!

You've just described the way the LSB has done it for years, which thus
far, hasn't worked--while there are numerous LSB-certified distros,
there are exactly zero LSB-certified applications. The reason for this
is that "substantially the same" isn't good enough--ISVs want *exactly
the same*, and there's a good reason for that, as evidenced by the fact
that while Debian is technically (very nearly) LSB compliant, there are
still a lot of edge cases like file system and package namespace
differences that fall outside the LSB that vastly complicate the
"certify to an ABI, then support all distros that implement
the ABI as defined by whether or not it passes a test kit" model.

I'm not knocking the LSB--by definition, the LSB codifies existing
standards, i.e., things everyone already agree with. The things
we're talking about here (package naming differences, network
configuration differences, all that) are clearly points of disagreement
between distributions (perhaps backed more by inertia than by anything
else). The LCC aims to complement the LSB by agreeing on a single set of
solutions for these edge cases, then by putting the necessary glue in
place to make sure whatever inertia or otherwise has propagated
the differences for so long doesn't remain an insurmountable obstacle.
And with enough mass, the edge cases become "stuff we agree on".

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence

Re: Linux Core Consortium

[John Hasler]

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.  I also haven't seen a convincing argument
that they are beneficial.  Why don't standard ABIs suffice?
-- 
John Hasler

Re: Linux Core Consortium

[Ian Murdock]

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, the flow can only be unidirectional?

> > 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
> 
> And which I doubt we will get with LCC, since the kernel is the most
> important piece which needs to be certificated.

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 Linux distributions as
each vendor incorporates its own potentially incompatible patch sets."

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence

Re: Linux Core Consortium

[Michael K. Edwards]

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 illusion that "exactly the same" was a reasonable
thing to ask for.  Once I got things working in my chroot, and
automated the construction of the chroot, I switched back to the
kernel I wanted to use; the ISV and I haven't troubled one another
since.

If the LSB only attempts to certify things that haven't forked, then
it's a no-op.  Well, that's not quite fair; I have found it useful to
bootstrap a porting effort using lsb-rpm.  But for it to be a software
operating environment and not just a software porting environment, it
needs to have a non-trivial scope, which means an investment by both
ISVs and distros.

As a strategy for defining and extending the scope of consensus
preparatory to a release of a test suite, sharing binaries is fine. 
But as a strategy for making ISVs and their customers happy, I think
it's a chimera.

Cheers,
- Michael

Bug#284964: ITP: autoconf-doc -- automatic configure script builder documentation

[Henrique de Moraes Holschuh]

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 documentation for the autoconf package

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.28-rc1-debian5+skas+lmsensors+3c59xvlan+lmlbt4x
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Linux Core Consortium

[Otavio Salvador]

|| 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://componentizedlinux.org/lsb/: "Importantly, the LCC platform
im> will include a common kernel, eliminating one of the largest sources
im> of incompatibilities between Linux distributions as
im> each vendor incorporates its own potentially incompatible patch sets."

Ok but how will be deal with unsupported hardware? Will be applied
patches to add support on it?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: ITP: g-wrap -- Scripting interface generator for C

[Andreas Rottmann]

[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 for exporting C...
>
I prefer to have them open until GnuCash is built against G-Wrap 1.9.3
and the gwrapguile source package can be removed. 

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. Note that I have
not yet done extensive testing with the G-Wrap 1.9.3-built GnuCash, so
there *might* be problems, so I'm not sure if we want this to be a
pre-Sarge change (although probably any problems would show up quick
enough to fix them before Sarge). You can download G-Wrap 1.9.3 .debs
by adding this to your /etc/apt/sources.list:

deb http://people.debian.org/~rotty/debian/ unstable/
deb-src http://people.debian.org/~rotty/debian/ unstable/

? app-file/gnome-glib.log
? app-utils/gnome-glib.log
? business/business-core/gnome-glib.log
? business/business-gnome/gnome-glib.log
? business/dialog-tax-table/gnome-glib.log
? engine/gnome-glib.log
? gnome/gnome-glib.log
? gnome-search/gnome-glib.log
? gnome-utils/gnome-glib.log
? report/report-gnome/gnome-glib.log
Index: engine/gw-engine-spec.scm
===
RCS file: /home/cvs/cvsroot/gnucash/src/engine/gw-engine-spec.scm,v
retrieving revision 1.73
diff -u -p -r1.73 gw-engine-spec.scm
--- engine/gw-engine-spec.scm	13 Jun 2004 20:01:29 -	1.73
+++ engine/gw-engine-spec.scm	8 Oct 2004 16:03:28 -
@@ -97,8 +97,6 @@
 (gw:wrap-as-wct ws ' "QofIdType" "QofIdTypeConst")
 (gw:wrap-as-wct ws ' "Account*" "const Account*")
 (gw:wrap-as-wct ws ' "Account**" "const Account**")
-(gw:wrap-as-wct ws ' "InvAcct*" "const InvAcct*")
-(gw:wrap-as-wct ws ' "AccInfo*" "const AccInfo*")
 (gw:wrap-as-wct ws ' "AccountGroup*" "const AccountGroup*")
 (gw:wrap-as-wct ws ' "QofBook*" "const QofBook*")
 (gw:wrap-as-wct ws ' "GNCLot*" "const GNCLot*")
Index: gnome-search/dialog-search.h
===
RCS file: /home/cvs/cvsroot/gnucash/src/gnome-search/dialog-search.h,v
retrieving revision 1.11
diff -u -p -r1.11 dialog-search.h
--- gnome-search/dialog-search.h	23 Oct 2003 04:32:57 -	1.11
+++ gnome-search/dialog-search.h	8 Oct 2004 16:03:28 -
@@ -24,6 +24,8 @@
 #ifndef _GNC_DIALOG_SEARCH_H
 #define _GNC_DIALOG_SEARCH_H
 
+#include 
+
 #include "GNCId.h"
 #include "QueryNew.h"
 
Index: report/report-gnome/dialog-column-view.h
===
RCS file: /home/cvs/cvsroot/gnucash/src/report/report-gnome/dialog-column-view.h,v
retrieving revision 1.2
diff -u -p -r1.2 dialog-column-view.h
--- report/report-gnome/dialog-column-view.h	22 Feb 2003 08:13:23 -	1.2
+++ report/report-gnome/dialog-column-view.h	8 Oct 2004 16:03:28 -
@@ -20,8 +20,14 @@
  * Boston, MA  02111-1307,  USA   [EMAIL PROTECTED]   *
  /
 
+#ifndef GNC_DIALOG_COLUMN_VIEW_H
+#define GNC_DIALOG_COLUMN_VIEW_H
+
 #include 
+#include 
 
 typedef struct gncp_column_view_edit gnc_column_view_edit;
 
 GtkWidget * gnc_column_view_edit_options(SCM options, SCM view);
+
+#endif

Regards, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Software Patents: Where do you want to stifle inovation today?

Re: Linux Core Consortium

[Ian Murdock]

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 - everyone needs working libraries and tools - but the details
> we consider worth fixing are not.

Can you provide examples? I'm not trying to be dense--I'm simply
trying to understand what, if anything, is so irreconcilable, as
some of you seem to be suggesting is the case here.

> So during the sarge release
> cycle, when we need to make updates to fix an RC bug in glibc that
> doesn't affect any platform shipped by any other member of the LCC,
> which has moved on to new development according to some other member's
> release schedule, what would we do?  We'd have to rebuild them anyway.
> There goes our "common binaries" advantage.
> 
> >From the web site, I see that LCC has a limited set of architectures
> targeted anyway.  Debian will continue to use common source for all
> architectures.  That will make working with the LCC difficult.

First, because the four founding members are commercial entities,
we're mainly interested in the architectures that are predominant
in commercial environments. That's all about aligning resources
with relative priorities and certainly isn't a statement that we
will never support anything else. If resources and priorities
change, the set of supported architectures could change as well.

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.

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

I'm not sure I follow--we all have to build packages from source, and
the LCC will be no different, so where's the problem exactly?

> I'm sure other members of the LCC have similar concerns - or will. 
> What are they doing about them?

Well, for one, we're trying to open a dialog with the Debian
community. :-)

> Are the other companies listed as "supporting" the Linux Core
> Consortium interested in this "common binaries" plan?  Their support
> quotes only explicitly support the Linux Standard Base.

Yes. (And you'd better re-read the quotes--all but one, IIRC, explicitly
mentions the LCC too.)

> 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 include a common kernel.

> If there is merit to the common binaries, I think we would get more
> mileage from it by supporting them as we do the LSB: with separate
> packages on top of the Debian base system.

That's certainly an option I've thought a lot about--the main
question is, is this good enough to get the ISV support? It probably
isn't to get the tier 1 ISVs (Oracle etc.), but it might be to
get some of the smaller ISVs, and that's better than nothing at all.

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence

Re: Linux Core Consortium

[Greg Folkert]

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
> decisions from the top and that already have a great deal in common
> (Red Hat lineage, RPM-based package management, etc.) to join forces to
> address a common problem; it's quite another for a decentralized
> community project that evolved very differently over the years. Still,
> I contend Debian shares those common problems (most notably, lack of
> support from ISVs and IHVs), and furthermore, that the "common
> cause" is much more achievable with Debian's support than without it.

ISVs and IHVs want Binary, mainly that is because Microsoft and Apple
have been dealing binary for decades. Binary is not what Debian is all
about. For myself I will strongly oppose any shared binaries. I don;t
want any RPM shoved down my throat. I would like to use see a shared
usage of the same Source Core, built on the apropos systems for those
supported archs. Debian Might be okay with that. But to demand Binary?
Pfeh!

> 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 constitute an implementation of the LSB
> standard; to use that single set of binaries as a "common core"
> for as many Linux distributions as possible; and to develop the
> common core in an open and collaborative fashion, so the end result
> is owned by the community, not by one or two commercial players.

Let us change this somewhat and see what you may think.

The end goal of the LCC is actually very simple: to create a
single set of source-packages that constitute an implementation
of the LSB standard(with or without RPM) and strict policies; to
use that single set of source-packages as a "common core" for as
many Linux distributions as possible, again with a strict set of
policies; to produce a implementation test kit to verify these
"common cores"; and to develop the common core in an open and
collaborative fashion, so the end result is owned by the
community, not by any commercial players.

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

PUT THE BRAKES ON. Single set of Binaries, right there I'll be 110%
opposed to this. As I am sure many in the Gentoo crowd and perhaps even
some others (Linux From Scratch is another) will be against this.

Repeat after me:
Binary is not the way. Binary is not the way.

> The LCC doesn't mandate the use of RPM (only to the extent the
> LSB does, which Debian can already address).

Which is exactly why Debian is not REALLY considered an LSB Distro. RPM
and the "big players" policies are so inadequate thereby removing RPM as
a viable alternative to package management for the LCC. My gosh tar.gz
or tar.bz2 binaryballs would be immensely better than RPM in that
regard. But let me keep saying Binary is not the way. Source for the
core-packages, with an ABI/API/OTHER Test Kit to test compliance, should
be what happens.

>  The LCC doesn't mandate
> what "compatibility" means as regards package naming or library
> versioning or anything else--it only says we need to agree on
> *something*, because agreeing on something buys us a lot, whereas
> continuing to differ on such minor things doesn't serve any purpose
> other than to divide us and set the stage for one or two companies
> to run away with commercial Linux via ISV/IHV certification lock-in.

ISV/IHV don't quite understand what it really means to use these
standards, they THINK they want these standards... but in reality they
want thing mandated into the systems. That in and of itself hampers what
really Debian, for that matter Linux is all about. It stifles
revolutionary disruptive evolution. Debian is all about Stifling on
Stable, but not elsewhere. Where you are leading Microsoft has already
gone down that path. Look at how much of a NIGHTMARE it is to deal with
different versions of the same Libraries with the same interfaces... but
reacting differently and breaking many things.

> If you're having trouble picturing how Debian might engage the LCC,
> here's my ideal scenario: the source packages at the core of
> Debian are maintained in collaboration with the other LCC members,
> and the resulting binaries built from those source packages are made
> available in both RPM and .deb format. Care would have to be taken to
> ensure that the resulting RPM- and Debian-based versions of the common
> core are compatible.

Okay, he we are as Debian, with strict policies about packaging. If we
could get the RPM based

Re: Linux Core Consortium

[Goswin von Brederlow]

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 with the old names 
>> > could be maintained indefinitely if necessary.
>> > 
>> ?!??!?!?!?!?!?!"PO!(*"!$*_(!$*"($*!("*$_*!"*$("
>> 
>> That is all.
>
> Well, that's certainly constructive.
>
> Can someone provide an example of where the name of a dynamic
> library itself (i.e., the one in the file system, after the
> package is unpacked) would change? I'd be surprised if this was
> a big issue. The LSB/FHS should take care of file system level
> incompatibilities already (though Debian may put some things in
> /lib that RPM-based distros put in /usr/lib due to more strict policy
> about such things), so I'd think the main issue wouldn't so much be
> about the names of the dynamic libraries themselves, but the names of
> the packages they come in (acl vs. libacl1, as per my last message).

When multiarch hits all (core) libs will move around
drastically:

/lib/* -> /lib/`gcc -dumpmachine`/
/usr/lib/* -> /usr/lib/`gcc -dumpmachine`/
/usr/X11R6/lib/* -> /usr/X11R6/lib/`gcc -dumpmachine`/

If you aim at having the same path to libs (which only broken rpath
needs) then this will be your nightmare.

MfG
Goswin

PS: The above lib dirs are the best and only practical solution we
have for multiarch.

Re: Linux Core Consortium

[Steinar H. Gunderson]

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 Debian's release schedule once again slips past 18 months, do
we have to wait another 18 months to get etch out?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: dselect survey

[Florent Rougon]

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 selections
> one has made manually is also pretty confusing.

Er, these are shortcuts. *shrug*

Uppercase is often used, relatively consistently, for things that you
really don't want to do inadvertently.

I learnt the most useful shortcuts, I know them, and I don't find them
particularly confusing. Very few are needed to do basic package
management (I would say, 10 or so). If in doubt, you can always invoke
the online help, which is bound to the question mark, so again, I don't
see a problem (oh, wait, some "industry standard" says it should be F1.
Well, frankly, I don't care.).

For people who are allergic to keyboard shortcuts, I would suggest some
point-and-click frontend; that is simply not dselects's target audience,
AFAICT.

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 years (I don't know how dselect was
 before slink)
 (d) didn't bother to read the "dselect for beginners" tutorial or any
 similar introductory document
 (e) have had problems with packages that didn't install, upgrade or
 configure correctly and wrongly blamed dselect for these problems.

[ Quizz of the day: which cases do you think are the most common? ]

Once you understand the basics, I find dselect to be a very useful and
efficient program.

-- 
Florent

Re: Linux Core Consortium

[Goswin von Brederlow]

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
>> 
>> And which I doubt we will get with LCC, since the kernel is the most
>> important piece which needs to be certificated.
>
> 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 Linux distributions as
> each vendor incorporates its own potentially incompatible patch sets."

And how will you get the other members to support architectures they
do not support? A common kernel sounds good but we haven't even
managed to common-ify the kernel inside of debian.

And that is without mentioning the non-free ness and license issues
coming up after sarge. The firmware blobs and the like.


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.

MfG
Goswin

Re: Linux Core Consortium

[Bruce Perens]

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, let's work on that for now. Perhaps we will all find that we should 
stop at that.

Okay, he we are as Debian, with strict policies about packaging. If we
could get the RPM based Distros to "get that" we could get along much
much better as well. Smaller more numerous packages (Like for Samba:
samba-common, smbclient, smbfs, swat, winbind, samba, samba-doc,
libsmbclient, libsmbclient-dev... etc), not just samba and samba-devel.
 

This does not sound unreasonable, but they won't do it if we're not 
there asking for it to be done.

If we are so sure we want interoperability, why not Invite the
BSDs as well. I know I'd like to see that. Some of the BSDs already
provide much of the compatibility right now.
 

Well, why not invite the AIX, Solaris, and HP-UX folks too :-) Let's 
bite off a managable piece for now.

I'd be glad to help on any front to get more applications from
Commercial Entities for Linux and BSD, even down to the negotiations
about how this. I for one use Linux 99.95% of the time. I'd like to see
that at 100%. If this LCC would be something that even RedHat and Novell
would Follow as well as the packaging and policy (even for just the Core
pieces) and as long as source for these and a test kit is made available
and improved by a technical committee/task-force, I'd like to see more
of this.
 

I can tell you for sure that if we don't build a strong community for 
LCC, the only thing that business people will ever care about is RH 
certification and Novell certification. We need to take this to the 
point that RH and Novell customers and the hardware vendors will insist 
that RH and Novell adopt it.

Debian has Policy and packaging constraints, if more Linux Distros at
least experienced those and really, how easy it is to just do it... I
think Debian could help tremendously.
 

Yes, I don't believe any other distro has done such an excellent job on 
policy.

Those Certifications would be given to the CORE, right? If a given
Distro proves, through the Testing Kit, that it complies, Certification
is inherited?
 

Thats what they are planning.
   Thanks
   Bruce

Re: Linux Core Consortium

[Bruce Perens]

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 
am hoping that once Sarge releases, we can continue to have weekly 
reports on RC bugs, continue bug-squashing parties, and in general do 
the most we can to keep the distribution on a ready-to-release footing 
on a continual basis.

   Thanks
   Bruce

Re: ITP: g-wrap -- Scripting interface generator for C

[Thomas Bushnell BSG]

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 *any* pre-Sarge
changes. 

Re: Linux Core Consortium

[Maciej Dems]

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 possible to have the kernel-xyz-lcc packages (with the 
warning in the others that they do not fit LCC standard). So it will be 
up to the user to decide what he wants.

And I will always build my very custom kernel anyway ;)

Cheers
Maciek


-- 
M.Sc. Maciej Dems  [EMAIL PROTECTED]
-
C o m p u t e r   P h y s i c s   L a b o r a t o r y
Institute of Physics,Technical University of Lodz
ul. Wolczanska 219, 93-005 Lodz, Poland, +48426313649

Re: dselect survey

[David Schmitt]

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 it for more than 5 years (I don't know how dselect was
>  before slink)
>  (d) didn't bother to read the "dselect for beginners" tutorial or any
>  similar introductory document
>  (e) have had problems with packages that didn't install, upgrade or
>  configure correctly and wrongly blamed dselect for these problems.
> 
> [ Quizz of the day: which cases do you think are the most common? ]
> 
> Once you understand the basics, I find dselect to be a very useful and
> efficient program.

Amen! Well said.


Regards, David
-- 
  * Customer: "My palmtop won't turn on."
  * Tech Support: "Did the battery run out, maybe?"
  * Customer: "No, it doesn't use batteries. It's Windows powered."
-- http://www.rinkworks.com/stupid/cs_power.shtml

LCC and blobs

[Bruce Perens]

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 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 thinking about the blob problem for a while. I propose to 
remove blobs from the driver, and store them as files in  initramfs (the 
kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) 
or initrd.img. At boot time, the drivers would look for the blobs and 
load them if they are present, and fail gracefully or fall back if they 
are not. This gets around some GPL issues, because rather than be 
treated as code, the blobs become external files that are just sent to 
the device by the driver.

Doing the above doesn't necessarily solve the problem for Debian, 
because we would still not want to distribute the blobs. but it allows 
the kernel to be GPL-compliant, which I don't feel it is while the blobs 
live in drivers.

An alternative is to make blobs their own loadable modules, but then we 
are treating them as code rather than as just a file that the kernel 
sends to some device, and we get GPL issues.

   Thanks
   Bruce

Re: dselect survey

[Roger Lynn]

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 I used aptitude (about six months ago, from Testing), I
found it difficult to specify how I wanted dependencies (including
recommends and suggests) to be satisfied. I like that fact that when I
select a package in dselect which has several ways of satisfying its
dependencies, dselect lets me choose what gets installed. Just because a
package depends on a web server doesn't mean I want apache installed.
While aptitude does tell you what it's going to install, and gives you
an opportunity to change it, I couldn't get it to give me a list of
acceptable alternatives. I am willing to accept that this might just be
down to my own stupidity though.

Roger

(Sorry if I've broken the thread; I'm reading the web archive.)

Re: Linux Core Consortium

[Steinar H. Gunderson]

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

> But some of us don't want to see Debian's release schedule slip again.

I doubt anybody wants to see Debian's release schedule slip, but it still
happens. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: Linux Core Consortium

[Bruce Perens]

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 
everything modulo 18 months.

   Thanks
   Bruce

Bug#284978: general: libgmp segfaults on generating 48402688-bit random number

[Thomas Womack]

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, 48402688);
  mpz_urandomb(B, state, 845*32);
  mpz_gcd(C,A,B);
}

compiled with gcc = gcc-2.95.4, gmp = gmp-4.0.1

segfaults in the mpz_urandomb() function
with a back-trace
#0  0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3
#1  0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3
#2  0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3
#3  0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#4  0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14

-- System Information
Debian Release: 3.0
Kernel Version: Linux chiark 2.4.28 #2 SMP Mon Nov 22 15:56:31 GMT 2004 i686 
unknown

Re: Linux Core Consortium

[Ron Johnson]

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

Re: dselect survey

[Bernd Eckenfels]

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 would say, 10 or so). If in doubt, you can always invoke
> the online help, which is bound to the question mark

And which is left with enter, just like you need to do to install (unless
you really want to ignore the conflict, which means you have to use "Q" to
install, then :)

Gruss
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: dselect survey

[Bernd Eckenfels]

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)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Linux Core Consortium

[Christoph Hellwig]

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 ensure that Linux remains open and
> free in the face of increased commercialization (this was, after all,
> Debian's founding goal)? I've long argued that, as the Linux world's
> leading non-commercial, community-driven free software distributor,
> Debian can and should lead the way against the
> elements of our community that seek to own Linux all to themselves.

In fact I'm using Debian exactly because it doesn't try to apeal ISVs,
IHVs, OEMs and other business-driven three-letter acronyms.  As soon
as you ty to please them quality of implementation goes down.

Besides that the LCC sounds like an extraordinarily bad idea, passing
around binaries only makes sense if you can't easily reproduce them from
the source (which I defined very broadly to include all build scripts
and depencies), and that case is the worst possible thing a distribution
can get into.

> 

Re: Linux Core Consortium

[Christoph Hellwig]

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

Re: Linux Core Consortium

[Matthew Palmer]

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 two ABI-compatible
versions of this, one that adds it's arguments and one that multiplies them. 
ABI compatible, but different results.

I'm not expecting that there'll be anything different to that degree in the
LCC-defined packages, but pretty much any change in a library would have the
effect of changing the way that library operates in some fashion -- and
who's to say that some program isn't relying on the former (buggy) operation
of the library?

- Matt


signature.asc
Description: Digital signature

Re: Linux Core Consortium

[Christoph Hellwig]

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 Linux distributions as
> each vendor incorporates its own potentially incompatible patch sets."

Which already shows that either they're going to play the UL-like
rebrand a single distro game or they are totally disconnected from
reality.

Re: Linux Core Consortium

[John Hasler]

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 program isn't relying on the former (buggy)
> operation of the library?

How could the program do that without being buggy itself?
-- 
John Hasler

Bug#284978: general: libgmp segfaults on generating 48402688-bit random number

[Goswin von Brederlow]

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?

> 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, 48402688);
>   mpz_urandomb(B, state, 845*32);
>   mpz_gcd(C,A,B);
> }
>
> compiled with gcc = gcc-2.95.4, gmp = gmp-4.0.1

With gcc-3.3 and libgmp3-dev_4.1.4-5_amd64.deb

[EMAIL PROTECTED]:~% gcc -g -O2 -W -Wall -o foo foo.c -lgmp
foo.c: In function `main':
foo.c:6: warning: unused parameter `argc'
foo.c:6: warning: unused parameter `argv'
[EMAIL PROTECTED]:~% ./foo 
zsh: segmentation fault  ./foo

Program received signal SIGSEGV, Segmentation fault.
0x002a95673f00 in __gmp_rand () from /usr/lib/libgmp.so.3
(gdb) bt
#0  0x002a95673f00 in __gmp_rand () from /usr/lib/libgmp.so.3
#1  0x002a95673eba in __gmp_rand () from /usr/lib/libgmp.so.3
#2  0x002a95687164 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#3  0x00400782 in main (argc=4196299, argv=0x9e) at foo.c:14

Same with gcc-3.4.

> segfaults in the mpz_urandomb() function
> with a back-trace
> #0  0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3
> #1  0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3
> #2  0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3
> #3  0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
> #4  0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14
>
> -- System Information
> Debian Release: 3.0
> Kernel Version: Linux chiark 2.4.28 #2 SMP Mon Nov 22 15:56:31 GMT 2004 i686 
> unknown

Kernel Version: Linux frosties 2.6.8-frosties-1 #2 Sun Oct 3 22:06:03 CEST 2004 
x86_64 GNU/Linux

MfG
Goswin

Re: LCC and blobs

[Goswin von Brederlow]

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 thinking about the blob problem for a while. I propose to
> remove blobs from the driver, and store them as files in  initramfs
> (the kernel-internal filesystem created by the stuff in
> /usr/src/linux*/usr) or initrd.img. At boot time, the drivers would
> look for the blobs and load them if they are present, and fail
> gracefully or fall back if they are not. This gets around some GPL
> issues, because rather than be treated as code, the blobs become
> external files that are just sent to the device by the driver.
>
> Doing the above doesn't necessarily solve the problem for Debian,
> because we would still not want to distribute the blobs. but it allows
> the kernel to be GPL-compliant, which I don't feel it is while the
> blobs live in drivers.
>
>  An alternative is to make blobs their own loadable modules, but then
> we are treating them as code rather than as just a file that the
> kernel sends to some device, and we get GPL issues.
>
> Thanks
>
> Bruce

Blobs can be made binary files and stored in the initrd. Since no
linking is involved and the kernel-image without the blobs is still
fully functional (except for a very very few hardware constelations)
that should get the GPL issue settled.

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 clause. Even putting some in non-free
works fine.

But presonaly I think even distributing such blobs as GPL is fine as
they are the source "as recieved" from upstream. Only an author could
sue us for obfuscating the source but the author released the source
as is. No obfuscating is done on our part.

Where I see problems is firmware and sources that were not explicitly
released as GPL by the authors but somehow sneaked their way into the
kernel just the same. Many of the problem cases fall under this.

But enough said. It's all put off till sarge is out.

MfG
Goswin

PS: Having the firmware as GPL would allow reverse engeneering to get
a more readable source format.

Re: Linux Core Consortium

[Michael K. Edwards]

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 Kit would help organize this
process.  Suppose that sarge validates against DTK 1.0, the vendor of
"bar" contributes a new test case which is accepted into DTK 1.0.1,
and DTK 1.0.1 runs against sarge + libfoo 1.7.  Then we'd be in no
worse a position than Other-Distro 14.7 which also included libfoo 1.6
and validated against DTK 1.0 -- except insofar as commercial distros
are more likely to silently roll DTK 1.0.1 and libfoo 1.7 into
14.7-updates, which isn't the way Debian handles stable.

This could be handled with "overlay" repositories that handle bug
fixes within a DTK minor version.  In the case described, "bar"
depends on validated-with-dtk (>= 1.0.1, < 1.1), validated-with-dtk
1.0.1-1 depends on libfoo (=1.7-1), and you need to have packages from
the validated-with-dtk 1.0.1 repository in order to install "bar".  A
security fix to libfoo 1.6 (in stable) would need re-validating
against DTK 1.0, and might also need to be done on libfoo 1.7,
resulting in validated-with-dtk 1.0.1-2 (built to depend on libfoo
1.7-2).

I actually think trying to handle this with a validated-with-dtk
package is a kludge, but it doesn't require any new development
(except, of course, the DTK, and perhaps automation of propagation
into the overlay repositories).  One of these days I will get around
to doing a more competent job of proposing "Signed Package Integrity
Tokens" (my last effort wasn't worth SPIT :-) as a way for ISVs to
self-service (or delegate self-servicing) at the level of functional
test and validation.

Either approach partitions the problem of security/bug-fix management
so that ISVs and their customers can contribute to things that matter
to them.  The DTK needs to be re-run, and the validated-with-dtk
dependencies updated or the PITs re-signed, any time there is a
security update to the relevant packages.  Security updates themselves
multiply because they may hit the versions in the overlay repositories
as well.  But at least it's possible to estimate the resource cost of
maintaining the various overlays, and it's clear what the criterion
for adding an overlay package is -- a DTK update that fails without
the overlay.

Note that many of the core packages we are talking about already have
extensive test suites, so the DTK could get off the ground by adapting
them into tests of the package in its installed state instead of
build-time tests.  This would make it pretty easy for an ISV to
prototype a test within the DTK, send it to upstream (the same test
runs in the build-time test framework), and get the bug fixed (or
feature added).

Obviously there aren't any new ideas in this (DejaGNU, anyone?) and
it's not a panacea.  The LCC's proposal is just a special case of this
-- a DTK that verifies the checksums of the common binaries :-).  But
I prefer an approach in which I can verify when and why the contract
between distro and ISV changed, so that I can make reasonable
decisions about whether and how to replace distro binaries with builds
that meet my own needs better.

Cheers,
- Michael

Re: LCC and blobs

[Don Armstrong]

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 clause. Even putting some
> in non-free works fine.

They'd pretty much have to go into non-free, as I'd imagine most of
them wouldn't be able to satisfy DFSG 2 if they were unable to satisfy
the GPL's source code requirement.


Don Armstrong

-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realised that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: dselect survey

[Miles Bader]

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 years (I don't know how dselect was
>  before slink)
>  (d) didn't bother to read the "dselect for beginners" tutorial or any
>  similar introductory document
>  (e) have had problems with packages that didn't install, upgrade or
>  configure correctly and wrongly blamed dselect for these problems.

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.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: dselect survey

[Daniel Burrows]

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 dependencies? (Kind of same as in
> dselect)

  If you want to find alternatives for a virtual package, you can use 'd' and 
'r' to navigate the dependency lists.  It's not as convenient as dselect, but 
it works.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   "Do you know why the prisoner in the|
|tower watches the flight of birds?"|
| -- Terry Pratchett, _Reaper_Man_  |
\-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/


pgptaUbdTIxuT.pgp
Description: PGP signature

Re: Linux Core Consortium

[Russ Allbery]

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 this is a hideously bad idea, and I say this as a representative
of an institutional user of Debian that has been hurt by the lack of ISV
support.  Having Oracle support Debian would be great, but not if it comes
at the cost of Debian's ability to make its own fixes and releases of core
libraries and toolchain components.

One of the reasons why we chose Debian in the first place is that the
packages that come out of the Debian project are simply higher quality, in
large part because they themselves are maintained in an open-source
fashion rather than as proprietary packages maintained by single vendors
controlled by commercial and economic restraints.  If I wanted Red Hat's
broken libc maintenance process, I know where to find it.  We explicitly
chose Debian because it's *better* than Red Hat in the core system
maintenance that we care about.

I think that tying core Debian packages to the Red Hat boat anchor is a
horrible, horrible idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Linux Core Consortium

[John Goerzen]

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 participate in this organization even if we didn't take
their packages?  That is, perhaps we could influence the direction to
a more useful one?

If that is the case, it seems zero risk to me.

-- John

Re: dselect survey

[Gunnar Wolf]

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!

I liked dselect very much, and would have no problems using it... Only
that I found aptitude was standard the first time I installed using
d-i, decided to give it a spin, didn't really love it the first
time... But by the third use, it really stuck, and now I am an
aptitude convert.

Far more usable, friendly, navigable has more
colors, lets me play minesweeper.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Linux Core Consortium

[Daniel Jacobowitz]

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 from experience.  The core needs are conceptually
> > the same - everyone needs working libraries and tools - but the details
> > we consider worth fixing are not.
> 
> Can you provide examples? I'm not trying to be dense--I'm simply
> trying to understand what, if anything, is so irreconcilable, as
> some of you seem to be suggesting is the case here.

I'll try.  My first concern is the architectures issue.  Bruce made a
comment along the lines of "LCC would have to accept patches for
architectures it didn't care about, but would not be required to build
them".  But it's not that simple; there are always tradeoffs.  Some of
the issues are rate of change (esp. w.r.t. release schedules),
modifications to common code, and increased pressure on patch
review/approval.

Debian has a different set of use cases than most Linux distributions. 
The first example that comes to mind is in-place upgrading, and some
packages have horrible hacks in them to support this.  Other LCC
members might reasonably object to the baggage.

> > So during the sarge release
> > cycle, when we need to make updates to fix an RC bug in glibc that
> > doesn't affect any platform shipped by any other member of the LCC,
> > which has moved on to new development according to some other member's
> > release schedule, what would we do?  We'd have to rebuild them anyway.
> > There goes our "common binaries" advantage.
> > 
> > >From the web site, I see that LCC has a limited set of architectures
> > targeted anyway.  Debian will continue to use common source for all
> > architectures.  That will make working with the LCC difficult.
> 
> First, because the four founding members are commercial entities,
> we're mainly interested in the architectures that are predominant
> in commercial environments. That's all about aligning resources
> with relative priorities and certainly isn't a statement that we
> will never support anything else. If resources and priorities
> change, the set of supported architectures could change as well.

Of course.  I understand the point of supporting commercially viable
architectures; Debian is the alternate extreme.

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

Precisely.  You've signed Debian up for "externally" (quotes, because
we would be participants, but there will be strong external pressures)
managed schedules for dozens of core packages.  And some external
pressure on overall release schedule, because of the sharp dropoff in
staleness.

For example, suppose GNOME is part of this managed set.  The other
members, primarily commercial distributions with greater control over
their schedules than Debian has, want to wait off on upgrading to GNOME
3.4 until their next release cycle.  Debian is going to be releasing in
three months and two dozen active GNOME developers are heartbroken by
the idea.

It's not an idle example - that happened for this release cycle.  Heroic
effort on the part of both GNOME maintainers and release managers got
it in under the wire, and it will make an IMHO big difference to the
out-of-the-box usability of sarge.


Right now, if you have a brilliant idea that you want to implement and
integrate all through Debian, there's a clear set of the relevant
maintainers to convince.  Expanding that set to include lots more
people, and people with sharply different needs and pressures, is not
something I consider good for the future of Debian.  The reason I am a
Debian developer is because Debian is responsive to my needs; it's
(relatively speaking) easily swayed onto a better course when one
presents itself.  As long as there's someone willing to do the work,
the work can be done.


Also, the multiple-architectures issue is a big one for the imposed
schedules.  Architectures that only Debian, out of all the LCC members,
cares about will be only lightly tested by the time any given LCC
release is made.  I estimate a dozen or more substantial changes to any
"released" packages before Debian could use them, taking many months to
come together.

> > 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.
> 
> I'm not sure I follow--we all have to build packages from source, and
> the LCC will be no different, so where's the problem exactly?

Autobuilders.

Security updates.

Build testing in Debian environments.

None of this is new...

> > We would never have a common kernel with these vendors anyway - they
> > don't even h

Re: Linux Core Consortium

[Gunnar Wolf]

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 didn't take
> their packages?  That is, perhaps we could influence the direction to
> a more useful one?
> 
> If that is the case, it seems zero risk to me.

Then we would be non-participants, we would be just bitchers, telling
everybody how fucked-up their process and QA are. We would gain
nothing, and we would lose as everybody would say that Debian refuses
to play together with the guys after giving an initial 'yes'. And no,
no ISV would certify Debian just because Debian sits and bitches.

I don't have a real position on whether we should join LCC or not -
But if we do, we should _really_ join LCC, not just sit at the LCC
table and watch them play.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Linux Core Consortium

[Gunnar Wolf]

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 include a common kernel.

Ummm... Wait a second on this one. Do you think that Mandrake (I
wanted to make the example with RedHat or SuSE, but it seems they also
have not commited, and without them mostly any attempt to do something
this big will probably fail) would want to have a kernel with less,
slower or less complete hardware support? Because I know Debian does
not want a kernel with propietary firmware in it.

> > If there is merit to the common binaries, I think we would get more
> > mileage from it by supporting them as we do the LSB: with separate
> > packages on top of the Debian base system.
> 
> That's certainly an option I've thought a lot about--the main
> question is, is this good enough to get the ISV support? It probably
> isn't to get the tier 1 ISVs (Oracle etc.), but it might be to
> get some of the smaller ISVs, and that's better than nothing at all.

Ok, so here is where exactly companies like yours come into play. I
don't think the LCC (as a commercial entity, with commercial interest
as you said) would be benefitted at all by supporting m68k or mips
(they would be more hindered than pushed by it - It does not surprise
me at all most Linux distributions pulled the plug on older or less
common architectures one by one). Progeny provides a Debian-based
distribution meant to be closer to the commercial world than
Debian. Why shouldn't Progeny provide for this set of needs? Of
course, if you are in the right mood, you can push your packages into
Debian as well, although they would not be base packages.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Linux Core Consortium

[Philip Miller]

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 out there, and I will never have to use an untrusted binary package to 
install it conveniently. Even when it comes to installing software that's not in the 
Archive, I can safely install it from source, with the assurance that none of its files 
will be mixed in with any files installed by the package management system (not the case 
with most 3rd-party RPMS).

I am doing some sysadmin work involving RedHat Enterprise Linux 3 systems, and I will tell 
you that they do a terrible job of maintaining a binary distribution. Standing by 
themself, let alone compared to Debian, they do no integration testing of the packages 
they release and distribute. For example, this past summer, after a new server 
installation, we had to build and install a local copy of Perl, because the version they 
distributed was completely incompatible with both mailscanner and amavisd-new due to 
module bugs. This sort of brown-paper-bag error in a release is unthinkable in Debian, 
precisely because of the QA that our exact distributed binaries go through (and this 
particular issue was actually caught in testing, as it should have been).

Philip Miller

Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)

[Philippe De Swert]

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 to distribute, and tell other people about it.

3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005
===
 
26 - 27 February 2005, Brussels

Call for papers


The 2005 edition of FOSDEM (Free and Open Source Developers' European
Meeting; http://www.fosdem.org) will take place in Brussels, Belgium 
on 26 and 27 February 2005. For the third time, a track on Embedded 
Systems and Operating Systems will be organized. The second edition 
was quite succesful and attracted up to 150 attendants for certain
topics.

For last year's program see: 
http://www.embedded-kernel-track.org/2004/papers.html

The use of Free Software in the infrastructure of embedded systems 
is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS 
and many other Free Software components. More companies are supporting
embedded Free Software each day because of the reliability and cheap
licensing.

Operating system development has always been a very important topic in
Free Software. 
As embedded and real-time systems typically have special OS
requirements, we 
organise this Free Embedded and OS development track at FOSDEM.

This track provides a remarkable opportunity to present and
discuss the ongoing work in these areas, and we invite developers to 
present their current projects. Technical topics of the conference 
include but are not limited to :

* OS Development : kernel architecture and implementation, libraries
  (e.g. Linux, BSD, uClinux, uClibc, newlib, ...)

* Practical experiences in implementing Free Software in embedded
systems
  (e.g. reverse engineering, porting  too (and adapting of) commercial
devices 
   (IPAQ, Linksys WRT54G,...), ...)

* Toolchain and build environment 
  (e.g. crosstool, emdebian, openembedded, PTX dist, packaging,
scratchbox, Eclipse, Valgrind,...)

* GUIs for embedded systems
  (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...)

* Multimedia applications for embedded systems
  (e.g. integer-only decoders, Opieplayer, ... )

* Real-time extensions, nanokernels and hardware virtualization software
  (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, ...)
 
* Hard real-time OS's
  (eCos, RTEMS, ...)

* Open hardware and softcores
  (e.g opencores.org, OpenRISC, LEON SPARC, FPGA's, specific design
restrictions for free systems...)

* Safety and security certifications applied to Free software
   (e.g. security measures in Embedded systems, SSL libraries, ...)

* Free software licenses and embedded systems

Authors are requested to submit their abstracts online to
[EMAIL PROTECTED] before 3/1/2005. Notification of receipt 
will be sent within 48 hours. Authors wishing to submit a full
paper (between 6 and 12 A4 pages), can do so in PS or PDF format.

The program committee will evaluate the abstracts and consists of:

* Herman Bruyninckx, Professor at K.U.Leuven, Belgium
* Geert Uytterhoeven, Sony NSCE, Belgium
* Karim Yaghmour, Opersys, Canada
* Peter De Schrijver (P2), Mind, Belgium
* Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd

See you at Fosdem,

Philippe
-- 

| Philippe De Swert 
|
| Stag developer http://stag.mind.be/
| Emdebian developer: http://www.emdebian.org
|
| Please do not send me documents in a closed format.(*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)
| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/   


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

Re: Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)

[Peter Vandenabeele]

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
^^^
to

> devices 
>(IPAQ, Linksys WRT54G,...), ...)

>   (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...)

kdrive ?

> * Real-time extensions, nanokernels and hardware virtualization software
>   (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, ...)

Xen ?

> * Open hardware and softcores
>   (e.g opencores.org, OpenRISC, LEON SPARC, FPGA's, specific design
> restrictions for free systems...)

IIRC, the prefered public name for the Leon core is "Leon" and not 
"Leon Sparc".


> Authors are requested to submit their abstracts online to
> [EMAIL PROTECTED] before 3/1/2005. Notification of receipt 
 
 3 January 2005

> will be sent within 48 hours. Authors wishing to submit a full
> paper (between 6 and 12 A4 pages), can do so in PS or PDF format.
> 
> The program committee will evaluate the abstracts and consists of:
> 
> * Herman Bruyninckx, Professor at K.U.Leuven, Belgium
> * Geert Uytterhoeven, Sony NSCE, Belgium
> * Karim Yaghmour, Opersys, Canada
> * Peter De Schrijver (P2), Mind, Belgium
^^
p2 (?)

> * Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd