Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

openswan's latest ebuilds are for 2.4.13 while the latest source is for 2.6.16.
Could you please add them or is it that's too buggy?

Reproducible: Always

Steps to Reproduce:
1. /usr/portage/net-misc/openswan has ebuilds up to 2.4.13
2. http://www.openswan.org/download/ shows openswan-2.6.16.tar.gz as the latest
3.

Actual Results:  
openswan-2.4.13 merged

Expected Results:  
openswan-2.6.16 merged unless, of course, it's considered to be buggy

Portage 2.2_rc8 (default/linux/x86/2008.0, gcc-4.3.1, glibc-2.8_p20080602-r0,
2.6.26-tuxonice i686)
=================================================================
System uname:
Linux-2.6.26-tuxonice-i686-Genuine_Intel-R-_CPU_T2500_@_2.00GHz-with-glibc2.0
Timestamp of tree: Mon, 08 Sep 2008 18:35:01 +0000
app-shells/bash:     3.2_p39
dev-java/java-config: 1.3.7, 2.1.6-r1
dev-lang/python:     2.5.2-r7
sys-apps/baselayout: 2.0.0
sys-apps/openrc:     0.2.5
sys-apps/sandbox:    1.2.18.1-r3
sys-devel/autoconf:  2.62-r1
sys-devel/automake:  1.9.6-r2, 1.10.1-r1
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   2.2.4
virtual/os-headers:  2.6.26
ACCEPT_KEYWORDS="x86 ~x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=native -msse3 -O2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild
/etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=native -msse3 -O2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks parallel-fetch preserve-libs sandbox sfperms strict
unmerge-orphans userfetch"
GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/
http://ftp.uni-erlangen.de/pub/mirrors/gentoo
http://ftp.snt.utwente.nl/pub/os/linux/gentoo "
INSTALL_MASK="Changelog.gz TODO.gz Author.gz"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="en es"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="a52 aac acl acpi aiglx alsa apic avi berkdb bzip2 cddb cdr clflush cli
cmov constant_tsc cracklib crypt cups cx8 dbus de dga dri dts dvd dvdnav dvdr
dvdread est fortran fpu fxsr gdbm gif gpm hal ht iconv imlib isdnlog jpeg
jpeg2k kde kipi live matroska mca mce midi mmx monitor mp3 mpeg msr mtrr
mudflap ncurses nls nojoystick nptl nptlonly nsplugin nx oggvorbis opengl
openmp pae pam pat pbe pcmcia pcre perl pge pmu png pni pppd pse python
quicktime readline real reflection samba sdl sep session spl ss sse sse2 ssl
sysfs tcpd theora tiff tm tm2 tsc unicode usb v4l vme vmx vorbis win32codecs
wmf x86 xanim xcomposite xorg xtpr xv zlib" ALSA_CARDS="ali5451 als4000 atiixp
atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968
fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop
empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul
mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions
alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file
authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user
autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires
ext_filter file_cache filter headers include info log_config logio mem_cache
mime mime_magic negotiation rewrite setenvif speling status unique_id userdir
usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard synaptics evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="en es" USERLAND="GNU" VIDEO_CARDS="i810"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

  <herd>secure-tunneling</herd> (metadata.xml)
still doesn't have any maintainers...

(In reply to comment #2)
>   <herd>secure-tunneling</herd> (metadata.xml)
> still doesn't have any maintainers...

What doesn't have maintainers? The metadata part? Openswan, at least, was
maintained. Sorry if it's no longer the case

I tried to bump openswan to version 2.6.x two times: at version 2.6.13 and at
version 2.6.14. It took me a day to overcome compiling issues and, on top of
that, I couldn't make it work for my company VPN (4 net-to-net tunnels and
several L2TP roadwarriors) even after one full weekend spend in front of my
computer.

I will try to bump it, but don't hold your breath. I still need to recover
myself from the previous failures.

Hi Alin,
any luck yet? May I help you?

I'm working on it. Now I struggle with a bug in refine_host_connection().

I've submitted it to the tree, but I've p.masked it.

I couldn't make my L2TP roadwarrior connections to work and frankly I'm very
disappointed by the Xelerance product. Since they are supposed to offer L2TP
over IPsec solutions, I would have expected them to test basic L2TP scenarios
before releasing a major version. I'm going to have a couple of beers, trying
to forget my countless hours spent making this crap to work.

If you find how you could make it work for a NATed L2TP clients, just let me
know.

Thanks, I'll update my local portage, unmask it and give it a try. I don't need
the L2TP stuff so may be it's usefull for me anyway. If not, may be I'll go for
some beers too   :-)

Tried it, worked once then nothing but not sure I should blame OSW for this.
Now, to get it compiled I had to create a fake /usr/bin/xmlto that just does
nothing. Ohterwise I got a lot of XLM compilation issues for ipsec.conf.5.xml
and the installation aborts.

Strange, on my box it compiles just fine and I have xmlto-0.0.18 installed.
Care to fix the alleged XML problems in a patch?

  Just searched xmlto to check I'm using the latest and got to know it just got
updated   :-)
app-text/xmlto
      Latest version available: 0.0.21
      Latest version installed: 0.0.18
   BTW, I just installed and configured a much nicer, reliable and easy to
configure (it even has a GUI for that) client. May be you already know about
this one, it's in http://www.shrew.net. No ebuilds yet but would be great to
have them in portage. Only thing I had to do was to enable and modprobe TUN on
my kernel. Nothing else to get it working.
   However, lemme know if you want me to check what happens with OSW 2.6.16
after updating xmlto as others may want to have it working thoug.

Created an attachment (id=166664) [details]
Patch to change "xmlto" to "xmlto --skip-validation"

  I could manage to get it to compile fine just by instructing "xmlto" to not
to validate the files passed to it. Attached is the patch I saved as
"/usr/portage/net-misc/openswan/files/openswan-2.6.16-xmlto-skip_validation.patch"
to make it work. And of course I also added another "epatch" line to the ebuild
to be like this:
 epatch "${FILESDIR}"/${P}-gentoo.patch
 epatch "${FILESDIR}"/${P}-qa-fixes.patch
 epatch "${FILESDIR}"/${P}-refine-connection.patch
 epatch "${FILESDIR}"/${P}-xmlto-skip_validation.patch
then issued the command:
 ebuild /usr/portage/net-misc/openswan/openswan-2.6.16.ebuild digest
and added this line:
 =net-misc/openswan-2.6*
to "/etc/portage/package.unmask" before succesfully emerging it.
  The programs and version I got pulled are:
 app-text/build-docbook-catalog-1.4
 sys-apps/iproute2-2.6.26-r2  USE="berkdb -atm -minimal"
 sys-devel/automake-1.5 [1.7.9-r1, 1.9.6-r2, 1.10.1-r1]
 app-text/docbook-xsl-stylesheets-1.74.0
 app-text/sgml-common-0.6.3-r5
 app-text/docbook-xml-dtd-4.2-r2
 app-text/xmlto-0.0.21
 net-misc/openswan-2.6.16 USE="-curl -extra-algorithms -ldap
-nocrypto-algorithms -smartcard -weak-algorithms"
  I'll configure and try it now.

I've added your patch to the gentoo.patch of the version 2.6.18.

(In reply to comment #13)
> I've added your patch to the gentoo.patch of the version 2.6.18.

Fine, thanks. I gave it a try and it worked partially well. I faced some kernel
crashes regarding the IPsec stuff and the rightsubnets="a.0.0.0/8 b.c.0.0/16"
doesn't seem to work for me but these are OSW issues out of your scope.

Thank you for your ebuilds!!

Oups, sorry for the confusion, I was speaking about version 2.6.16. I just
realized you added (and was speaking about) 2.6.18, will try this latest one as
soon as I can.

(In reply to comment #15)
> Oups, sorry for the confusion, I was speaking about version 2.6.16. I just
> realized you added (and was speaking about) 2.6.18, will try this latest one as
> soon as I can.

Well, 2.6.18 just works for me.  Did not do anything special either.  Just
emerge and start.  Below is a Vista laptop connecting to the test machine
(xl2tpd with certificates):

Oct 16 10:02:05 south pluto[23693]: "l2tp-X.509-dmz"[2] 10.0.2.207 #2:
STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x2d36f05c <0xc8eb56c9
xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=<invalid>:500 DPD=enabled}

Original tar.gz from upstream compiled without problems as well before the
emerge.  I did not "make install" though.  Shout if you need anything.


south ~ # emerge --info
Portage 2.1.4.5 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0,
2.6.25-gentoo-r8 i686)
=================================================================
System uname: 2.6.25-gentoo-r8 i686 Pentium III (Coppermine)
Timestamp of tree: Wed, 15 Oct 2008 03:47:01 +0000
app-shells/bash:     3.2_p33
dev-lang/python:     2.4.4-r13, 2.5.2-r7
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.61-r2
sys-devel/automake:  1.10.1-r1
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf
/etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -march=pentium3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans
userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://10.0.2.23/gentoo-portage"
USE="berkdb cjk crypt ncurses nls nptl pam perl pic python readline ssl unicode
usb x86 xml" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106
cmipci emu10k1     emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel
intel8x0 intel8x0m       maestro3 trident usb-audio via82xx via82xx-modem
ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug
file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null
plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic
authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm
authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache
dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache
filter headers include info log_config logio mem_cache mime mime_magic
negotiation rewrite setenvif speling status unique_id userdir usertrack
vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint
i128 i740 i810 imstt         mach64 mga neomagic nsc nv r128 radeon rendition
s3 s3virge savage      siliconmotion sis sisusb tdfx tga trident tseng v4l vesa
vga via vmware      voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG,
LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

(In reply to comment #16)

Ok, thanks for your report. I succeded to upgrade it with no issues after Alin
updated to 2.6.18 and included the patch I suggested but still haven't time
enough to even launch OSW yet.

(In reply to comment #12)
> Created an attachment (id=166664) [edit] [details]
> Patch to change "xmlto" to "xmlto --skip-validation"

There is no need for this patch on my system.  xmlto works without skipping
validation.  version 0.0.21

Please recheck and revert if appropriate.

On my system it also work without that patch, but on Rolando's box it does not.
Are you serious? Do you really expect me to remove such a benign patch and risk
having problems on some boxes just because in your case it works without the
patch?

(In reply to comment #19)
> On my system it also work without that patch, but on Rolando's box it does not.
> Are you serious? Do you really expect me to remove such a benign patch and risk
> having problems on some boxes just because in your case it works without the
> patch?

With due respect, I expect you to check and understand why the patch is needed
in the first place. Communicate it to the upstream if it is really needed for
general consumption and not apply random patches just because it solves a
problem in one particular case.

But it is your call of course.

Does the anti-patch movement ever take a break? For your information, *all*
distros patch their packages and Gentoo is not an exception (far from it).
Without our patches, your box would have the same grade of usability as a brick
(e.g. net-dialup/ppp).

I don't really care why this patch is needed in Rolando's case and I'm not a
xml guru to figure it out (not without being able to reproduce the problem).
The guy found a problem, posted a patch and the patch don't affect other users,
so I've included it. Do you think you can do better? You only need to become a
Gentoo developer and I will pass this crap to you faster than you can blink.

(In reply to comment #21)
> Does the anti-patch movement ever take a break? 

I am not against patching.  I am against patching without able to explain the
need for the patch.

[...]
> I don't really care why this patch is needed in Rolando's case and I'm not a
> xml guru to figure it out (not without being able to reproduce the problem).
> The guy found a problem, posted a patch and the patch don't affect other users,
> so I've included it.

You should have asked Rolando to xmllint the offending man pages with verbose
output to debug further.  It took what, 30 secs, to figure out what
skip-validation does and check the man page of xmllint. 

> Do you think you can do better? You only need to become a
> Gentoo developer and I will pass this crap to you faster than you can blink.

Nobody is paying you to do this stuff.  Don't do it if you do not feel proud of
the end result.  Please don't just bang away at the keyboard, claiming victory
when the last error message is gone away.

For *your* info, we are running this "crap" on our servers.  It is my job on
the line if things go wrong.  And it will go wrong with code written with this
attitude.

I will send you my answers to the ebuild quiz.

For things that doesn't concern this bug report, I will answer you privately.

You want 2 things:
  1) unmask version 2.6.18 because you claim L2TP+X.509 works for you. However,
it doesn't work in my case (see http://bugs.xelerance.com/view.php?id=990) and
I will keep it masked until all problems are solved. 
  2) remove skip-validation patch. I agree it is not the best solution and I'm
willing to replace it with the one that fixes the xml docs. Do you have a patch
that fixes Rolando's problem? Until you have that, I'll keep it as is.

(In reply to comment #9)
> Tried it, worked once then nothing but not sure I should blame OSW for this.
> Now, to get it compiled I had to create a fake /usr/bin/xmlto that just does
> nothing. Ohterwise I got a lot of XLM compilation issues for ipsec.conf.5.xml
> and the installation aborts.

Rolando,

Can you please check the name of the file(s) that gives the XML compilation
errors please?  I do not have ipsec.conf.5.xml when 2.6.18 is untarred.

~/openswan-2.6.18 $ find -type f -name ipsec.conf.*.xml
~/openswan-2.6.18 $

Bump.  Rolanda, can you please check which file(s) give the errors with xmlto? 
Thanks.

(In reply to comment #25)
> can you please check which file(s) give the errors with xmlto? 
Yeap, but please give me some time to dig into it, I'm pretty busy at work by
these days.   :-(

Hi guys,

got 5 minutes and went back to it. At the same time I realized we've version
2.6.19 with the XMS' skip-validation patch still there.

Funny thing is even with that patch it still fails, now in 2.6.19, in another
part of the compilation process.

Please find attached the "build" and "environment" files for the failing
emerge. I could see on it that's now the "( cd
/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto ;
xmlto man pluto.8.xml ; mv ipsec_pluto.8 pluto.8; xmlto man
ipsec.secrets.5.xml)" line the offending one.

So, I issued the suggested xmlinit command to see if I could manage to get some
more info. The output of what I did is also attached (it's the xmltest file).

I think the problem in my case remains the same, the XML parser tries to load
some external references and as it can there a lot of errors for not-known
stuff. I remember I tried some time ago to solve this but I couldn't. May be
there is some more googling now. In any case, if you know how to solve this and
can share the info, I'll really appreciate it.

Rolando.

Created an attachment (id=176027) [details]
"environment" file of the failiing compilation

Created an attachment (id=176029) [details]
"build.log" file of the failiing compilation

Created an attachment (id=176031) [details]
test of the failing XML file

(In reply to comment #27)
> I think the problem in my case remains the same, the XML parser tries to load
> some external references and as it can there a lot of errors for not-known
> stuff.

  et al is not a default XML entity.  Without an external DTD, you are
getting the above warnings.  You can replace: 

&nbsp -> &#x160
&ldquo -> &#8220
&rdquo -> &#8221

and try again.  However, I doubt it will solve your problem.  The above should
be warnings only.

Anyway, please try compiling with the above substitution and let us know.

(In reply to comment #31)
> Anyway, please try compiling with the above substitution and let us know.

I tried above replacements for "pluto.8.xml" and I got a clear output for
"xmllint --noout pluto.8.xml" so it does work!

What I don't understand is why my system doesn't load the DTD, shouldn't it
connect and get them automatically as stated in the XML file itself as per:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">

Was digging a bit more into this and could find the solution. What happened is
"pluto.8.xml" requires "DTD DocBook XML V4.1.2" as it can be seen here:
RJZ-LNX pluto # head pluto.8.xml         
<?xml version="1.0" encoding="UTF-8"?>   
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">     
<!-- lifted from troff+man by doclifter -->                     
<refentry id="pluto8">                                          
  <refentryinfo>                                                
    <date>26 October 2006</date>                                
  </refentryinfo>                                               

  <refmeta>
RJZ-LNX pluto #

but my system was trying to use not that remote DTD but a locally copied one
instead:
RJZ-LNX pluto # grep "DTD DocBook XML V4.1.2" /etc/xml/docbook                  
  <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
uri="file:///usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd"/>
RJZ-LNX pluto # 

and since, in turn, that local copy was missing:
RJZ-LNX pluto # ls /usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd           
ls: cannot access /usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd: No such
file or directory                     
RJZ-LNX pluto # 

it failed:
RJZ-LNX pluto # xmllint --noout --valid --load-trace pluto.8.xml
Loaded URL="pluto.8.xml" ID="(null)"                            
pluto.8.xml:3: warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">                     
                                                           ^                    
pluto.8.xml:5: validity error : Validation failed: no DTD found !               
<refentry id="pluto8">                                                          
                     ^                                                          
RJZ-LNX pluto #

So, the solution for me was to create the
"/usr/share/sgml/docbook/xml-dtd-4.1.2" subdir and to copy into it the whole
content of "http://www.docbook.org/xml/4.1.2/" to have OSW merging fine:
RJZ-LNX ~ # emerge -pv openswan

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] net-misc/openswan-2.6.19  USE="-curl -extra-algorithms -ldap
-nocrypto-algorithms -smartcard -weak-algorithms" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
RJZ-LNX ~ #
RJZ-LNX ~ # emerge -q openswan
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-misc/openswan-2.6.19
>>> Installing net-misc/openswan-2.6.19
 * GNU info directory index is up-to-date.
RJZ-LNX ~ #

Not sure what package should get "/usr/share/sgml/docbook/xml-dtd-4.1.2"
installed. I already had these two:
RJZ-LNX ~ #  qfile /usr/share/sgml/docbook/xml-dtd-4.2/
app-text/docbook-xml-dtd (/usr/share/sgml/docbook/xml-dtd-4.2)
RJZ-LNX ~ #
RJZ-LNX ~ #  qfile /usr/share/sgml/docbook/xml-dtd-4.4/
app-text/docbook-xml-dtd (/usr/share/sgml/docbook/xml-dtd-4.4)
RJZ-LNX ~ #

but not even after updating app-text/docbook-xml-dtd to 4.5 (was [4.2-r2,
4.4-r1] before) had any 4.1.2 DTD's files on my PC. What's the output of "qfile
/usr/share/sgml/docbook/xml-dtd-4.1.2" on your systems? I'm asking because it
may be worth adding OSW a dependency for whatever package got it installed on
your PCs.

(In reply to comment #33)
> Was digging a bit more into this and could find the solution. What happened is
> "pluto.8.xml" requires "DTD DocBook XML V4.1.2" as it can be seen here:

Correct.

> but my system was trying to use not that remote DTD but a locally copied one
> instead:

That is the correct behaviour.  Otherwise, it would just result in a DDoS
against oasis-open.org everytime we installed openswan, used xmlto etc.

> and since, in turn, that local copy was missing:

That should not happen.

> RJZ-LNX pluto # ls /usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd           
> ls: cannot access /usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd: No such
> file or directory

That file belongs to app-text/docbook-xml-dtd which is a dependency for
app-text/xmlto which is a dependency for net-misc/openswan.

Check your system for broken dependencies.

(In reply to comment #34)
> That file belongs to app-text/docbook-xml-dtd which is a dependency for
> app-text/xmlto which is a dependency for net-misc/openswan.

I know, you can check it above.

> Check your system for broken dependencies.

I checked it and app-text/docbook-xml-dtd is on its latest version but I still
don't have /usr/share/sgml/docbook/xml-dtd-4.1.2 created and populated.

So, what's the output of " qfile /usr/share/sgml/docbook/xml-dtd-4.2/" on your
system?

(In reply to comment #35)
> So, what's the output of " qfile /usr/share/sgml/docbook/xml-dtd-4.2/" on your system?
Sorry, I meant for 4.1.2 instead

(In reply to comment #35)
> So, what's the output of " qfile /usr/share/sgml/docbook/xml-dtd-4.2/" on your
> system?

# which qfile
which: no qfile in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2)

Anyway, since you have docbookx.dtd now, ebuild should install openswan with or
without skip-validation patch.  It should give warnings but not error out.

If you want to get rid of warnings for missing entities, run:
emerge -va =app-text/docbook-xml-dtd-4.1.2-r6

> # which qfile
> which: no qfile in
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2)

you have to have app-portage/portage-utils installed for /usr/bin/qfile.

> Anyway, since you have docbookx.dtd now, ebuild should install openswan with or
> without skip-validation patch.  It should give warnings but not error out.
> 
> If you want to get rid of warnings for missing entities, run:
> emerge -va =app-text/docbook-xml-dtd-4.1.2-r6

I had errors and an aborted merge though until I had all the stuff under
"/usr/share/sgml/docbook/xml-dtd-4.1.2" installed.

Funny thing is OSW requires xmlto that in turns requires docbook-xml-dtd but
unless you specify 4.1.2 (the one OSW seems to need) you get the latest
docbook-xml-dtd that's 4.5.

May be worth adding a dependency or, at least, a recommendation on the ebuild
to run "emerge -1q =app-text/docbook-xml-dtd-4.1.2*" in case other users face
the same issue than me?

In any case, it's up to you but regardless of whether it's manually downloaded
or installed by "emerge -1q =app-text/docbook-xml-dtd-4.1.2*", the 4.1.2 has to
be there.

BTW, I'm moving the bug to closed anyways. Thank you very much for your support
and don't hesitate to get in touch again if needed even though I'm closing it.

(In reply to comment #38)
> In any case, it's up to you but regardless of whether it's manually downloaded
> or installed by "emerge -1q =app-text/docbook-xml-dtd-4.1.2*", the 4.1.2 has to be there.

No it doesn't.  As long as you have some version of docbook-xml-dtd, openswan
will install just fine.  docbook-xml-dtd-4.1.2 is needed only to get rid of the
warnings.

It seems to me that we still do not know the underlying reason for the ebuild
to fail on your system, but it works now so I guess it is OK.

I still think the skip-validation patch should be reverted btw.  It tries to
(unseccesfully?) cure the symptoms but not the underlying brokenness of the
system.

(In reply to comment #39)
> I still think the skip-validation patch should be reverted btw.  It tries to
> (unseccesfully?) cure the symptoms but not the underlying brokenness of the
> system.

I agree to remove it. If someone else faces a similar issue, should try to
install version 4.1.2 of DTDs.

To conclude, we need to add =app-text/docbook-xml-dtd-4.1.2* as compile time
dependency or what?

(In reply to comment #41)
> To conclude, we need to add =app-text/docbook-xml-dtd-4.1.2* as compile time dependency or what?

I had to as "app-text/docbook-xml-dtd" installs the 4.5 stuff and seems to not
to be the required one. At least that's what happen on my system.

Who is pulling 4.1.2 in yours? You could check it with "qfile
/usr/share/sgml/docbook/xml-dtd-4.2/" provided you have
app-portage/portage-utils installed.

(In reply to comment #41)
> To conclude, we need to add =app-text/docbook-xml-dtd-4.1.2* as compile time
> dependency or what?

* gets rid of a few screenfuls of warnings during emerge
* possibly help users with broken systems such as Rolando

but

* strictly speaking unneccesary DEPEND
* yet another dependency on dtd-4.1.2.  It will have to be maintained a long
time

Quick look through the tree shows a few uses of DEPEND on dtd-4.1.2 (although
it is depending on dos USE flag mostly).

Your call.  Personally, I would (unhappily) include it as
~app-text/docbook-xml-dtd-4.1.2 (mind the tilda)

(In reply to comment #43)
> Your call.  Personally, I would (unhappily) include it as
> ~app-text/docbook-xml-dtd-4.1.2 (mind the tilda)

I've replaced the xmlto --skip-validation patch with
app-text/docbook-xml-dtd:4.1.2 dependency atom.

Just a few comments:
1) It's not only warnings what I get, it's a failing emerge as it can be seen
in the attached "http://bugs.gentoo.org/attachment.cgi?id=176029" file
2) I don't think my system is broken. I ran this:
emerge --sync
emerge -DuN system world
emerge --depclean
revdep-rebuild
etc-update
and the emerge still failed since no any other package was pulling in 4.1.2
DTDs. This is why I was requesting you guys to check what package was alredy
installing it on your systems (can be checked with qfile) from portage-utils
3) I agree with the solution provided above. Other alternative may be to create
a new patch, this time for 2.6.19 as the one I created was working fine for the
previous version but not for this one. So, adding that dependency would
alleviate the task of, possibly, having to check/correct the patch for each new
version.

Any reason for 2.6.* to still be masked since this bug is closed?

(In reply to comment #46)
> Any reason for 2.6.* to still be masked since this bug is closed?

Just a guess but Alin cannot really unmask the 2.6 branch until 

http://bugs.xelerance.com/view.php?id=1004

is resolved.

(In reply to comment #46)
> Any reason for 2.6.* to still be masked since this bug is closed?

I've updated the p.mask explanation. Indeed, upstream bug 1004 is the reason
for it.