MENU DEFAULT64 support for syslinux

[Ryan Finnie]

On Mon, Jun 9, 2008 at 1:08 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> * Installer images for i386 and amd64 have a new boot menu using
>  syslinux's vesamenu. This allows for a more user-friendly selection
>  of for example the regular or graphical installer. For the multi-
>  architecture CD/DVD images this change means the 64-bits version of
>  the installer needs to be selected manually from the menu. See the
>  Installation Guide [2] for details on how to use the new menu.

Beta 2 is looking nice, but not having multi-arch boot detection was a
bummer.  So I took it upon myself to add the missing functionality to
menu.c32/vesamenu.c32.  I'm posting the patch here first because I Am
Not A C Programmer(TM), and I really need more set of eyes on it.
Functionally it seems to be working well, as I converted my own
distro's[0] straight isolinux setup to a vesamenu system[1], and it's
been guessing correctly on everything I've thrown at it so far.

RF

[0] http://www.finnix.org/
[1] http://www.finnix.org/Image:Finnix_dev_boot_menu.png
diff -ruN syslinux-3.63+dfsg-orig/com32/menu/menu.h syslinux-3.63+dfsg/com32/menu/menu.h
--- syslinux-3.63+dfsg-orig/com32/menu/menu.h	2008-04-10 10:30:35.0 -0700
+++ syslinux-3.63+dfsg/com32/menu/menu.h	2008-06-10 00:48:38.424152595 -0700
@@ -163,6 +163,8 @@
   struct color_table *color_table;
 
   struct fkey_help fkeyhelp[12];
+
+  int has_default64;
 };
 
 extern struct menu *root_menu, *start_menu, *hide_menu, *menu_list;
diff -ruN syslinux-3.63+dfsg-orig/com32/menu/readconfig.c syslinux-3.63+dfsg/com32/menu/readconfig.c
--- syslinux-3.63+dfsg-orig/com32/menu/readconfig.c	2008-04-10 10:30:35.0 -0700
+++ syslinux-3.63+dfsg/com32/menu/readconfig.c	2008-06-10 01:01:58.937589284 -0700
@@ -66,6 +66,28 @@
   NULL
 };
 
+#define cpuid(func,ax,bx,cx,dx)\
+	__asm__ __volatile__ ("cpuid":\
+	"=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));
+
+/*
+ * Determine if a CPU is x86_64 capable
+ */
+int is_64bit(void) {
+  unsigned int eax,ebx,ecx,edx;
+
+  cpuid(0x8000,eax,ebx,ecx,edx);
+  /* if 0x8001 is available, it's an AMD and/or x86_64 CPU */
+  if(eax >= 0x8001) {
+cpuid(0x8001,eax,ebx,ecx,edx);
+/* Bit 29 of 0x8001_edx specifies x86_64 */
+if((edx&(1<<29)) == (1<<29)) {
+  return 1;
+}
+  }
+  return 0;
+}
+
 /*
  * Search the list of all menus for a specific label
  */
@@ -206,6 +228,7 @@
   unsigned int ipappend;
   unsigned int menuhide;
   unsigned int menudefault;
+  unsigned int menudefault64;
   unsigned int menuseparator;
   unsigned int menudisabled;
   unsigned int menuindent;
@@ -273,6 +296,8 @@
   struct menu_entry *me;
   const struct syslinux_ipappend_strings *ipappend;
 
+  int cpu_is_64bit = is_64bit();
+
   if (!ld->label)
 return;			/* Nothing defined */
 
@@ -361,8 +386,26 @@
   break;
 }
 
-if ( ld->menudefault && me->action == MA_CMD )
+/* If this ld has DEFAULT on it, it's a candidate for the default entry.
+ * But if a 64-bit default has already been set, we know that A) the CPU
+ * is 64-bit, and B) a DEFAULT64 has already occurred, so we don't even
+ * want to attempt 32-bit defaults anymore.  If it's a 64-bit CPU,
+ * regular DEFAULTs can of course be considered for the default,
+ * but any past or future DEFAULT64 (with a corresponding 64-bit CPU)
+ * will eventually win.
+ */
+if ( ld->menudefault && me->action == MA_CMD && !m->has_default64 )
   m->defentry = m->nentries-1;
+
+/* If the CPU is 64-bit and DEFAULT64 is set for this ld, set it as
+ * default.  However, if DEFAULT64 is set and the CPU is NOT 64-bit,
+ * don't even consider it for a default.
+ */
+if ( ld->menudefault64 && me->action == MA_CMD && cpu_is_64bit ) {
+  m->defentry = m->nentries-1;
+  m->has_default64 = 1;
+}
+
   }
 
   clear_label_data(ld);
@@ -620,6 +663,8 @@
 	}
   } else if ( looking_at(p, "default") ) {
 	ld.menudefault = 1;
+  } else if ( looking_at(p, "default64") ) {
+	ld.menudefault64 = 1;
   } else if ( looking_at(p, "hide") ) {
 	ld.menuhide = 1;
   } else if ( looking_at(p, "passwd") ) {
@@ -875,6 +920,7 @@
   ld.ipappend  = ipappend;
   ld.menudefault = ld.menuhide = ld.menuseparator =
 	ld.menudisabled = ld.menuindent = 0;
+  ld.menudefault64 = 0;
 } else if ( (ep = is_kernel_type(p, &type)) ) {
   if ( ld.label ) {
 	refstr_put(ld.kernel);

O Maior Evento Empresarial do Ano

[K.L.A. Eventos Empresariais]

Olá

No dia 19 de julho realizaremos o 14º Encontro dos Maiores Conferencistas do 
Brasil no Hotel Transamérica em São Paulo.

Serão 07 conferencias com 10 horas de treinamento com os melhores 
Conferencistas do País: Waldez Ludwig, Leila Navarro, César Souza, Carlos 
Alberto Júlio, Prof. Gretz, César Romão e Alfreto Rocha

Lições de Liderança, Motivação. Gestão e Estratégias de Sucesso.

Valor promocional de R$ 499,00 para 01 inscrição e para grupos a partir de 10 
inscrições - R$ 399 por participante

Acesse o site abaixo e Aproveite esta Oportunidade

www.klatreinamentos.com.br/14encontro/n

Muito obrigado

Silvio Ferucio
Gerente Comercial
K.L.A. Educação Empresarial

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Guus Sliepen]

On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:

> * URL : http://www.ircd-charybdis.net
> * License : GPL
> 
> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> seems to care about that, I'm going to assume that it's OK.

People DO care, and it is not OK. Linking with OpenSSL is only allowed
if there is an exemption to the license of charybdis that explicitly
allows linking to the OpenSSL. See for example this page which gives a
nice summary and links to some related debian-legal emails:

http://www.gnome.org/~markmc/openssl-and-the-gpl.html

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Miriam Ruiz]

2008/6/10 Guus Sliepen <[EMAIL PROTECTED]>:
> On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
>
>> * URL : http://www.ircd-charybdis.net
>> * License : GPL
>>
>> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
>> seems to care about that, I'm going to assume that it's OK.
>
> People DO care, and it is not OK. Linking with OpenSSL is only allowed
> if there is an exemption to the license of charybdis that explicitly
> allows linking to the OpenSSL. See for example this page which gives a
> nice summary and links to some related debian-legal emails:
>
> http://www.gnome.org/~markmc/openssl-and-the-gpl.html

I don't know if it's possible, but you might want to try to link it to
GNUTLS [1] instead.

Greetings,
Miry

[1] http://www.gnu.org/software/gnutls/


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

Re: Non-free IETF RFC/I-Ds in,source packages

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Brian May <[EMAIL PROTECTED]> writes:
>
>> No responses? No one cares enough to comment? Lets see if a change in
>> subject helps.
>>
>> Do the files created from the RFCs also have the same restrictive license
>> as the RFCs themselves?
>
> The text of the RFCs is copyrighted.  The mapping tables in the RFCs
> cannot be under US copyright law, and I believe copyright law in other
> countries is similar.  I'm guessing (I haven't looked closely) that what's
> happening here is that the build process is generating code from the
> tables in the RFC appendices.
>
> It should be fine if you strip the text of the RFC out in the Debian
> upstream source tarball and include only the tables that are used in the
> code generation process.  You can probably steal code from the Heimdal
> code generation process itself to do that automatically, and then run that
> script on new upstream tarballs to generate the Debian *.orig.tar.gz.

What you describe is roughly what my Libidn does, which also generates
code from the data tables in RFC 3454.  See the copyright related
discussion in the file itself:

http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=blob;f=doc/specifications/rfc3454.txt;hb=HEAD

It contains some e-mail discussions with [EMAIL PROTECTED]

/Simon


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

Re: Debian Installer lenny beta 2 released

[Frans Pop]

Didier Raboud wrote:
> as of now, the *.torrent files are missing for multi-arch cd's.
> http://cdimage.debian.org/cdimage/lenny_di_beta2/multi-arch/bt-cd/

They are available now.

Cheers,
FJP


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

Re: libnss-ldap/libpam-ldap security issue

[Russ Allbery]

Brian May <[EMAIL PROTECTED]> writes:

> Is there anyway to configure the ldap libraries not to read from
> $HOME/.ldaprc?

Well, you can set LDAPNOINIT or LDAPCONF.  It's even documented in
ldap.conf(5):

Users may create an optional configuration file, ldaprc or .ldaprc, in
their home directory which will be used to override the system-wide
defaults file.  The file ldaprc in the current working directory is
also used.

The last bit is particularly awesome.

I tried to convince upstream that this was a security concern and got
yelled at for my trouble until I gave up (although to be fair, upstream
did agree at least that reading files out of the current working directory
was a broken idea and they wouldn't do it if they were starting from
scratch now, but they didn't want to change the existing code).  As I
recall, the theory was that any software that cared about security needed
to override the library defaults anyway so it wouldn't matter if the
library read an untrusted initialization file, and I think I verified that
and that is indeed correct.  (Of course, that doesn't help against
segfaults in the config file parser.)  The NSS module got all the
necessary initializations the last time this came up, which addressed the
immediate concerns at the time the bug was raised, so nothing further
happened with the Debian OpenLDAP package.

This was a while back, so my memory may be wrong on the details.  Steve
might remember more.

The problem with just removing this code in the library is that it's also
how ldapsearch and friends get their defaults, which is actively used and
will break people's scripts if it goes away.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Debian Installer lenny beta 2 released

[Didier Raboud]

Le mardi 10 juin 2008 12:26:05 Frans Pop, vous avez écrit :
> Didier Raboud wrote:
> > as of now, the *.torrent files are missing for multi-arch cd's.
> > http://cdimage.debian.org/cdimage/lenny_di_beta2/multi-arch/bt-cd/
>
> They are available now.
>
> Cheers,
> FJP

Seen. Thank you.

Regards, 
OdyX

-- 
Didier Raboud, proud Debian user.
CH-1802 Corseaux
[EMAIL PROTECTED]


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

Re: [xml/sgml-pkgs] Bug#482140: docbook-xml: Package does not install: update-xmlcatalog: error: entity, already registered

[Daniel Leidert]

Am Dienstag, den 10.06.2008, 04:05 -0400 schrieb Akira:
> Same error upgrading from Etch to Lenny on i686 (Core2 Duo). Worked around 
> the issue by running the following two commands.
> 
> update-xmlcatalog --del --type public --id '-//OASIS//DTD DocBook XML 
> V4.1//EN' --package docbook-xml
> update-xmlcatalog --del --type public --id '-//OASIS//DTD XML Exchange Table 
> Model 19990315//EN' --package docbook-xml

These commands are part of the prerm script of the docbook-xml etch
package (4.4-5). So this shouldn't be necessary.

I clearly need help and I get the impression, that the problem only
appears on the amd64 architecture.

CCing debian-release, debian-devel for help

Hello guys,

Some users reported an issue upgrading docbook-xml from Etch to
Lenny/Sid. I'm unable to reproduce it and I currently have no idea,
what's going on. From reading the reports it might be an amd64-specific
issue - which is some kind of surprising, because docbook-xml is
Arch:all. But maybe the package has been corrupted on the amd64
installation CD/DVDs. The fact, that after a reinstallation of the
docbook-xml package, the issue seems to disappear could be a hint, that
this is the case. I really have no clue (and not much time till the end
of next week). So I hereby request your help.

I really appreciate any information, which helps to track down the issue
and fix it. An NMU is of course allowed if you find the cause.

Regards, Daniel


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[William Pitcock]

Hi,

On Tue, 2008-06-10 at 11:21 +0200, Guus Sliepen wrote:
> On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
> 
> > * URL : http://www.ircd-charybdis.net
> > * License : GPL
> > 
> > Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> > seems to care about that, I'm going to assume that it's OK.
> 
> People DO care, and it is not OK. Linking with OpenSSL is only allowed
> if there is an exemption to the license of charybdis that explicitly
> allows linking to the OpenSSL. See for example this page which gives a
> nice summary and links to some related debian-legal emails:

It is likely impossible to add an exemption to most IRCd notable
exceptions include ngircd or inspircd, because some of the original
"ircd 2.8" contibutors are now dead.

Due to packet interception and logging, SSL support in IRC daemons is
becoming a hot topic. Without OpenSSL, packaging charybdis is pointless
for me, as the whole idea of packaging it would be to make it easier to
install on my systems. And without OpenSSL, it isn't easier for me to
install because I would have to rebuild the package with OpenSSL.

So, in a nutshell, nobody in the current IRCd development community
cares about perceived GPL+OpenSSL compatibility issues, so only Debian
does, which is "ok", but that's not so useful when Debian is already
shipping packages linked against OpenSSL with no exception (see below).

Here's some packages which are linked against OpenSSL and should not be
(this is not an all exhaustive list, you should grep-dctrl on a Sources
or something):

- epic4 (impossible to get an exception, dead contributors)
- inspircd would but I chose not to build that module because they ship
a gnutls one instead (charybdis is basically stuck with openssl due to
using libcrypto directly)
- oftc-hybrid (impossible to get an exception, dead contributors)
- openvpn (may or may not have exception, more checking needed)
- xchat (might be possible to get an exception, but author doesn't care
about GPL anyway, see also: Shareware XChat for win32)
- znc (status unknown, but i see no exception in the source)

So, in the grand scheme of things, I don't really think one more package
linked against OpenSSL is going to hurt anything.

If it makes you happy, I could bolt an exception on the code, but I
doubt it would hold water due to the fact that there are dead copyright
holders. But at the moment, porting to GnuTLS is really not an option,
as I would have to port to GCrypt too for the cert exchange, and that
couldn't be easily done with libgnutls-extra. I suppose using
libgnutls-extra and not supporting X.509 cert auth for gaining admin
access is an acceptable compromise provided that libgnutls-extra
implements enough of the OpenSSL API.

William


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Giacomo A. Catenazzi]

William Pitcock wrote:

- epic4 (impossible to get an exception, dead contributors)


You are wrong to the "impossible to get an exception, dead 
contributors", in this sentence and in other sentences:


The copyright go to the heirs, so you could contact the
heirs.

Anyway, we should follow the copyright law.
If we do exception to GPL, other people will
think they could also make esceptions to GPL,
losing the value of the GPL, and all people will
lose.

Don't think only on these project, where it would
be very convenient to make exceptions, but if you
broke in one place the GPL, why our users should not
make additional exceptions and not disclose sources?

So this annoyance will allow us to sue people violating
the GPL. Think: it is a great advantage!

ciao
cate


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Stephen Gran]

This one time, at band camp, William Pitcock said:
> Hi,
> 
> On Tue, 2008-06-10 at 11:21 +0200, Guus Sliepen wrote:
> > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
> > 
> > > * URL : http://www.ircd-charybdis.net
> > > * License : GPL
> > > 
> > > Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> > > seems to care about that, I'm going to assume that it's OK.
> > 
> > People DO care, and it is not OK. Linking with OpenSSL is only allowed
> > if there is an exemption to the license of charybdis that explicitly
> > allows linking to the OpenSSL. See for example this page which gives a
> > nice summary and links to some related debian-legal emails:
> 
> So, in a nutshell, nobody in the current IRCd development community
> cares about perceived GPL+OpenSSL compatibility issues, so only Debian
> does, which is "ok", but that's not so useful when Debian is already
> shipping packages linked against OpenSSL with no exception (see below).

Upstreams being brain dead about licensing issues is not something
really new, unfortunately.  This issue has been done to death already,
and it seems to me that protesting that we have some other similar bugs
is not a justification to introduce a new one.

For GPLv3, it does seem like AJ's idea of putting openssl in essential
is a reasonable one, and I'd quite like to see it.  That doesn't help
GPLv2 only apps, though, so I think we're just going to have to live
with the status quo on that one.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

GPL+OpenSSL, Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Guus Sliepen]

On Tue, Jun 10, 2008 at 06:38:19AM -0500, William Pitcock wrote:

> So, in a nutshell, nobody in the current IRCd development community
> cares about perceived GPL+OpenSSL compatibility issues, so only Debian
> does, which is "ok", but that's not so useful when Debian is already
> shipping packages linked against OpenSSL with no exception (see below).
[...]
> So, in the grand scheme of things, I don't really think one more package
> linked against OpenSSL is going to hurt anything.

There are lots of packages which have licensing issues, but we try to
resolve those issues. Adding a new one with known issues is not helping,
it is hurting our efforts to produce a distribution that is free from
licensing issues.

I think if you discuss the issue with the other main developers and you
agree to add the exemption to the upstream tarball, then it is OK for
Debian to distribute charybdis. I don't think dead authors or people who
contributed small patches will object, after all the intention was all
along that one could freely distribute charybdis linked to OpenSSL.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: MENU DEFAULT64 support for syslinux

[Robert Millan]

On Tue, Jun 10, 2008 at 01:38:43AM -0700, Ryan Finnie wrote:
> On Mon, Jun 9, 2008 at 1:08 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> > * Installer images for i386 and amd64 have a new boot menu using
> >  syslinux's vesamenu. This allows for a more user-friendly selection
> >  of for example the regular or graphical installer. For the multi-
> >  architecture CD/DVD images this change means the 64-bits version of
> >  the installer needs to be selected manually from the menu. See the
> >  Installation Guide [2] for details on how to use the new menu.
> 
> Beta 2 is looking nice, but not having multi-arch boot detection was a
> bummer.  So I took it upon myself to add the missing functionality to
> menu.c32/vesamenu.c32.  I'm posting the patch here first because I Am
> Not A C Programmer(TM), and I really need more set of eyes on it.
> Functionally it seems to be working well, as I converted my own
> distro's[0] straight isolinux setup to a vesamenu system[1], and it's
> been guessing correctly on everything I've thrown at it so far.

Hi Ryan,

Thanks for your help.  I'm also interested in this feature (I updated the
patch which was being currently used, 02-64bit-autodetection.dpatch, but it
seems that it has no effect when using the menu).  I have two comments:

  - Would you please open a bug report (see bugs.debian.org) against syslinux
package for this?  debian-devel is not the most indicate place.

  - Have you based your code on the currently existing check in
02-64bit-autodetection.dpatch?  It is best to reuse known-working code
for this.  If you want a C-friendly version, you can use cpuid.c from
the win32-loader package (it derives from GCC and has been widely
tested).

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Joerg Jaspert]

On 11412 March 1977, William Pitcock wrote:

> So, in a nutshell, nobody in the current IRCd development community
> cares about perceived GPL+OpenSSL compatibility issues, so only Debian
> does, which is "ok", but that's not so useful when Debian is already
> shipping packages linked against OpenSSL with no exception (see below).

> Here's some packages which are linked against OpenSSL and should not be
> (this is not an all exhaustive list, you should grep-dctrl on a Sources
> or something):

> So, in the grand scheme of things, I don't really think one more package
> linked against OpenSSL is going to hurt anything.

Feel free to file bugs, thats why the BTS is open for everyone.

But thanks that you told us which package to not accept but just reject
from NEW. Always good to have people help us.

-- 
bye, Joerg
Contrary to common belief, Arch:i386 is *not* the same as Arch: any.


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Steve Greenland]

On 10-Jun-08, 06:38 (CDT), William Pitcock <[EMAIL PROTECTED]> wrote: 
> - openvpn (may or may not have exception, more checking needed)

The copyright file has the necessary exceptions. 

Steve


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Steve Langasek]

On Tue, Jun 10, 2008 at 06:38:19AM -0500, William Pitcock wrote:
> Here's some packages which are linked against OpenSSL and should not be
> (this is not an all exhaustive list, you should grep-dctrl on a Sources
> or something):

And what is grep-dctrl supposed to tell anyone?  There are lots of packages
that build-depend on openssl.  How do you intend for anyone to draw
conclusions based on the build-depends alone, without reference to license?

Or are you just trying to send anyone who disagrees with you on a fool's
errand, so they won't interfere with your ITP?

> - epic4 (impossible to get an exception, dead contributors)

debian/copyright shows a BSD license.

> - inspircd would but I chose not to build that module because they ship
> a gnutls one instead (charybdis is basically stuck with openssl due to
> using libcrypto directly)

... therefore not analogous, so why do you include it in this list?

> - oftc-hybrid (impossible to get an exception, dead contributors)

 *  As a special exception, the authors give permission to link the code of this
 *  release of oftc-hybrid with the OpenSSL project's "OpenSSL" library (or
 *  with modified versions of it that use the same license as the "OpenSSL"
 *  library), and distribute the linked executables.  You must obey the GNU
 *  General Public License in all respects for all of the code used other than
 *  "OpenSSL".  If you modify the code, you may extend this exception to your
 *  version of the files, but you are not obligated to do so.  If you do not
 *  wish to do so, delete this exception statement from your version.

> - openvpn (may or may not have exception, more checking needed)

Has an exception, already mentioned.

> - xchat (might be possible to get an exception, but author doesn't care
> about GPL anyway, see also: Shareware XChat for win32)

 License:
 
 This program is released under the GPL v2 with the additional exemption
 that compiling, linking, and/or using OpenSSL is allowed. You may
 provide binary packages linked to the OpenSSL libraries, provided that
 all other requirements of the GPL are met. 
 See file COPYING for details.

The debian/copyright on this one is rather horrid looking, it lists 6
licenses in a row with no indication of which license applies to what
components.  This probably warrants a bug report for clarification; but at
first look, it appears that the effort has already been made to secure an
exception for the components that require it.

> - znc (status unknown, but i see no exception in the source)

  In addition, as a special exception, the copyright holders give
  permission to link the code of portions of this program with the
  OpenSSL library under certain conditions as described in each
  individual source file, and distribute linked combinations
  including the two.
  You must obey the GNU General Public License in all respects
  for all of the code used other than OpenSSL.  If you modify
  file(s) with this exception, you may extend this exception to your
  version of the file(s), but you are not obligated to do so.  If you
  do not wish to do so, delete this exception statement from your
  version.  If you delete this exception statement from all source
  files in the program, then also delete it here.

> So, in the grand scheme of things, I don't really think one more package
> linked against OpenSSL is going to hurt anything.

No, you're the only one who seems to be playing fast and loose with
licensing here.  *None* of the examples you've cited to try to support your
position appear to have the licensing problem in question; everyone else is
making a good-faith effort to get this right.

> If it makes you happy, I could bolt an exception on the code, but I
> doubt it would hold water due to the fact that there are dead copyright
> holders.

There are dead /authors/, not dead copyright holders.  Dead people can't
hold copyright; copyright transfers to the heirs when the author dies.

The reason it wouldn't hold water is that exceptions have to be granted by
the copyright holders.  You can't bolt an exception on *for* them, you need
to get this approved by the people who actually hold copyright on this code.

You can of course provide an exception for any of your own code, but that
doesn't result in a distributable binary package unless yours is the only
code used in the program that links to OpenSSL.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[William Pitcock]

On Tue, 2008-06-10 at 10:46 -0700, Steve Langasek wrote:
> > - oftc-hybrid (impossible to get an exception, dead contributors)
> 
>  *  As a special exception, the authors give permission to link the
> code of this
>  *  release of oftc-hybrid with the OpenSSL project's "OpenSSL"
> library (or
>  *  with modified versions of it that use the same license as the
> "OpenSSL"
>  *  library), and distribute the linked executables.  You must obey
> the GNU
>  *  General Public License in all respects for all of the code used
> other than
>  *  "OpenSSL".  If you modify the code, you may extend this exception
> to your
>  *  version of the files, but you are not obligated to do so.  If you
> do not
>  *  wish to do so, delete this exception statement from your version.

You've been conned. OFTC-Hybrid is based on Hybrid which is based on 2.8
and therefore cannot add such an exception; it is effectively in the
same boat that charybdis is in. I could lie and add the same exception
to my debian/copyright too, but it wouldn't be true and it wouldn't be
right to do so.

Furthermore, a grep of that string in the source brings no results other
than debian/copyright, which demonstrates that nothing actually HAS this
exception anyway:

[EMAIL PROTECTED]:~/oftc-hybrid-1.6.3.dfsg$ grep "As a special exception,
the authors give permission" * -R
debian/copyright: *  As a special exception, the authors give permission
to link the code of this
[EMAIL PROTECTED]:~/oftc-hybrid-1.6.3.dfsg$ 

At any rate, I intend to wait until version 3.1 of charybdis anyway now,
which has a GNUTLS backend (I've written it, and it just needs to be
debugged).

William


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Joey Hess]

William Pitcock wrote:
> - znc (status unknown, but i see no exception in the source)

Wow, you had me thinking I was a copyright fool for a minute there
(and wondering how such a mistake got past the ftpmasters),
until I took a look at znc's debian/copyright and LICENSE.OpenSSL:

 In addition, as a special exception, the copyright holders give
 permission to link the code of portions of this program with the
 OpenSSL library under certain conditions as described in each
 individual source file, and distribute linked combinations
 including the two.
[...]

-- 
see shy jo


signature.asc
Description: Digital signature

Debian Lenny on Blu-Ray

[Bolee Menee]

Hello,

Will Debian distribute Lenny as Blu-Ray ISO image?

It will need only one standard disk (single layer ~25gb) to store everything
(Lenny beta needs 18 gb only).

Bulk prices for BD-Rs are only 10.99 USD, and many upcoming mainstream
laptop models have BD-ROM as option.

May be its not very interesting right now, but I believe it will be
interesting for many peoples next year.

Personally, I dont have BD-ROM yet, but I think it will be very good to have
everything on one disk.

Best regards,
B.M

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[Robert Millan]

On Tue, Jun 10, 2008 at 11:50:47AM +0200, Miriam Ruiz wrote:
> 2008/6/10 Guus Sliepen <[EMAIL PROTECTED]>:
> > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
> >
> >> * URL : http://www.ircd-charybdis.net
> >> * License : GPL
> >>
> >> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> >> seems to care about that, I'm going to assume that it's OK.
> >
> > People DO care, and it is not OK. Linking with OpenSSL is only allowed
> > if there is an exemption to the license of charybdis that explicitly
> > allows linking to the OpenSSL. See for example this page which gives a
> > nice summary and links to some related debian-legal emails:
> >
> > http://www.gnome.org/~markmc/openssl-and-the-gpl.html
> 
> I don't know if it's possible, but you might want to try to link it to
> GNUTLS [1] instead.

GNUTLS has an OpenSSL portability layer, but it is not complete.  It would
require some porting work.

Btw, the build system in ircd-charybdis considers OpenSSL an optional
dependency.  If it's an optional feature, why not just disable it untill a
better solution is found?

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[William Pitcock]

Hi,

On Tue, 2008-06-10 at 15:04 -0400, Joey Hess wrote:
> William Pitcock wrote:
> > - znc (status unknown, but i see no exception in the source)
> 
> Wow, you had me thinking I was a copyright fool for a minute there
> (and wondering how such a mistake got past the ftpmasters),
> until I took a look at znc's debian/copyright and LICENSE.OpenSSL:
> 
>  In addition, as a special exception, the copyright holders give
>  permission to link the code of portions of this program with the
>  OpenSSL library under certain conditions as described in each
>  individual source file, and distribute linked combinations
>  including the two.
> [...]
> 

That list was, among other things, based on comments made by upstream
authors about usage of OpenSSL and this problem.

I'm glad to hear that psychon has changed his mind though. I've filed
bugs on the actual packages that don't hold water, now.

William


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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server

[William Pitcock]

Hi,

On Tue, 2008-06-10 at 21:18 +0200, Robert Millan wrote:
> On Tue, Jun 10, 2008 at 11:50:47AM +0200, Miriam Ruiz wrote:
> > 2008/6/10 Guus Sliepen <[EMAIL PROTECTED]>:
> > > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
> > >
> > >> * URL : http://www.ircd-charybdis.net
> > >> * License : GPL
> > >>
> > >> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> > >> seems to care about that, I'm going to assume that it's OK.
> > >
> > > People DO care, and it is not OK. Linking with OpenSSL is only allowed
> > > if there is an exemption to the license of charybdis that explicitly
> > > allows linking to the OpenSSL. See for example this page which gives a
> > > nice summary and links to some related debian-legal emails:
> > >
> > > http://www.gnome.org/~markmc/openssl-and-the-gpl.html
> > 
> > I don't know if it's possible, but you might want to try to link it to
> > GNUTLS [1] instead.
> 
> GNUTLS has an OpenSSL portability layer, but it is not complete.  It would
> require some porting work.
> 
> Btw, the build system in ircd-charybdis considers OpenSSL an optional
> dependency.  If it's an optional feature, why not just disable it untill a
> better solution is found?

Because SSL is a requirement for my requirements. I wish to replace
inspircd with something that is more suited for my requirements (e.g.
something I can use CGI:IRC with, without having ban-evasion issues).

We've already found a temporary solution (although I certaintly don't
like the side effect that it makes the daemon binary GPLv3), which is to
use the portability layer until a native backend for GNUTLS is written
(and just simply not have the certificate-based opering feature until
it's properly abstracted -- right now it's dependent on libcrypto
availability).

Obviously a native GNUTLS backend is the best solution, but releasing
charybdis 3.0.2 with an openssl.c that can build against gnutls-extra is
fine for the immediate future.

William


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

Re: Bug#393837: Raising severity

[Josselin Mouette]

tag 393837 + help
thanks

Le jeudi 15 mai 2008 à 08:02 +0100, Neil Williams a écrit :
> This bug now prevents the removal of known compromised key(s) involved
> in the recent openssh problems.
> 
> http://lists.debian.org/debian-security-announce/2008/msg00152.html

It seems that the solution to this issue is to add an implementation of
nsIWindowCreator[0] to epiphany.

This should not be too complicated for a C++ developer taking
inspiration in the rest of the implementation (in embed/mozilla/*.cpp),
especially for someone familiar with Gecko. As I’m not very familiar
with C++, I’m not sure to find the time to do it soon, so it would be
very nice if someone could give a hand and provide even the beginning of
an implementation.

[0] http://developer.mozilla.org/en/docs/nsIWindowCreator

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


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

Re: Debian Lenny on Blu-Ray

[Frans Pop]

Bolee Menee wrote:
> Will Debian distribute Lenny as Blu-Ray ISO image?

Exactly the same question was also posted on the d-cd list where it is 
probably more on-topic. I suggest to not discuss this here.

B.M: please do not cross-post questions this way, unless you first wait 
some decent time (at least one week for a low-traffic list like 
debian-cd, can be a bit shorter for high-traffic lists) for replies on 
the list you first posted to.

Cheers,
FJP


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

Re: libnss-ldap/libpam-ldap security issue

[Brian May]

Russ Allbery wrote:
> I tried to convince upstream that this was a security concern and got
> yelled at for my trouble until I gave up (although to be fair, upstream
> did agree at least that reading files out of the current working directory
> was a broken idea and they wouldn't do it if they were starting from
> scratch now, but they didn't want to change the existing code).  As I
> recall, the theory was that any software that cared about security needed
> to override the library defaults anyway so it wouldn't matter if the
> library read an untrusted initialization file, and I think I verified that
> and that is indeed correct.  (Of course, that doesn't help against
> segfaults in the config file parser.)  The NSS module got all the
> necessary initializations the last time this came up, which addressed the
> immediate concerns at the time the bug was raised, so nothing further
> happened with the Debian OpenLDAP package.
>   
In my case, it looks like the NSS module is getting its certificates
based on the defaults in $HOME/.ldaprc. I expect this, because I have
the certificates configured in /etc/ldap/ldap.conf and nowhere else.
This is presumable why it is segfaulting, because it is picking up the
wrong certificates. This in turn would mean if somebody was able to
interfere somehow with the network, they could trick sudo into
authenticating against the wrong ldap server.

Sure, I could override all the defaults in /etc/ldap.conf (config file
used by ldap-nss and ldap-pam), but this strikes me as (a) unnecessarily
duplication of config settings in /etc/ldap.conf and /etc/ldap/ldap.conf
and (b) risky because  I  might miss a config setting that needs to be
overridden. It also doesn't appear to be documented anywhere.

In fact the comments in /etc/ldap.conf would suggest it is OK to use the
LDAP defaults:

# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap's default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting.  The default for
# OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
#tls_checkpeer yes

> The problem with just removing this code in the library is that it's also
> how ldapsearch and friends get their defaults, which is actively used and
> will break people's scripts if it goes away.
>   
On my computers I would rather break this functionality, which I hardly
ever use anyway (and on the one time I did use it caused random programs
to segfault when I forgot about it several years later).

Brian May


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

Bug#485703: ITP: libratbox -- portable runtime for ircd-ratbox and charybdis

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

* Package name: libratbox
  Version : 3.0.0~svn25529
  Upstream Author : Aaron Sethman <[EMAIL PROTECTED]>,
Jilles Tjoelker <[EMAIL PROTECTED]>
* URL : http://www.ircd-ratbox.org/
* License : GPL
  Programming Lang: C
  Description : portable runtime for ircd-ratbox and charybdis
 Libratbox is the portable runtime used by ircd-ratbox and
 ircd-charybdis. It features an abstractable design allowing for
 SSL support and high performance I/O.
 .
 In Debian, SSL support is provided by GNUTLS and should be considered
 experimental at the moment.

Support may be added to allow for local users to rebuild using OpenSSL
if desired instead of GNUTLS. This is still being considered; the official
Debian version will always use GNUTLS.

-- System Information:
Debian Release: lenny/sid
Architecture: amd64 (x86_64)

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



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

Bug#485708: ITP: ant-contrib -- Additional libraries for use with the ant build tool

[Mike O'Connor]

Package: wnpp
Severity: wishlist
Owner: "Mike O'Connor" <[EMAIL PROTECTED]>


* Package name: ant-contrib
  Version : 1.0~b3+20080610
  Upstream Author : Ant-Contrib Project
* URL : http://ant-contrib.sourceforge.net/
* License : Apache 2.0
  Programming Lang: Java
  Description : Additional libraries for use with the ant build tool

 Ant is a Java based build tool like 'make' which uses XML files as
 "Makefiles".  
 .
 This package enhances the ant package by making more tasks available.



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

Re: Changes to the ddpo-by-mail service

[Raphael Geissert]

Emilio Pozuelo Monfort wrote:

> Raphael Geissert wrote:
>> Emilio Pozuelo Monfort wrote:
>> 
>>> Raphael Hertzog wrote:
 And the fact that he sends one mail per e-mail instead of one mail per
 package makes it even better (far less annoying).
>>> Agreed, specially for people or teams who maintain lots of packages.
>>>
>>> Raphael, would it be possible for you to do the same with DEHS mails?
>> 
>> I really don't understand your request.
> 
> I mean: whenever DEHS sends mails about new upstream releases, I get a lot
> (20 mails on may 28th) of mails in the pkg-gnome-maintainers list, one for
> each package, but when for DDPO I get just one mail with the info for all
> the packages.
> 
> I think it would be nice if DDPO sent one mail to the maintainer, say once

I guess you mean s/DDPO/DEHS

> a week, instead of the current behaviour. Or otherwise if it would be
> possible to blacklist packages, as I don't think any Debian GNOME
> maintainer finds that information useful, as we are subscribed to the
> gnome-changes list and we have overview pages saying what packages are
> outdated et al.

DEHS sends the notifications to the summary PTS keyword. Only addresses
subscribed to that tag will receive the notifications.

If you don't like that behaviour please contact the PTS owners and explain
your reasons, and if a concensus is reached I will be more than happy to
send the email to a different keyword. Please refer to #356826 for more
information.

Personally, I see of little use to notify once a week instead of 'when it's
out'. But like I said, please refer to that bug report, and contact the
right party :) Very few people have complained about the current behaviour
so far. 

> 
> Cheers,
> Emilio

Cheers,
Raphael


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

Re: libnss-ldap/libpam-ldap security issue

[Russ Allbery]

Brian May <[EMAIL PROTECTED]> writes:

> In my case, it looks like the NSS module is getting its certificates
> based on the defaults in $HOME/.ldaprc. I expect this, because I have
> the certificates configured in /etc/ldap/ldap.conf and nowhere else.
> This is presumable why it is segfaulting, because it is picking up the
> wrong certificates. This in turn would mean if somebody was able to
> interfere somehow with the network, they could trick sudo into
> authenticating against the wrong ldap server.

> Sure, I could override all the defaults in /etc/ldap.conf (config file
> used by ldap-nss and ldap-pam), but this strikes me as (a) unnecessarily
> duplication of config settings in /etc/ldap.conf and /etc/ldap/ldap.conf
> and (b) risky because I might miss a config setting that needs to be
> overridden. It also doesn't appear to be documented anywhere.

Basically, you're preaching to the choir and I think this should be
changed, but I don't have the time or energy to work on it.  :/  I'm listed
as an OpenLDAP package maintainer because I'm willing to try to work on it
when Stanford can spare some of my time for it, but that hasn't been often
lately and isn't the case at the moment.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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