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 attachment 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] > 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 attachment 176027 [details] "environment" file of the failiing compilation
Created attachment 176029 [details] "build.log" file of the failiing compilation
Created attachment 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:   -> Š &ldquo -> “ &rdquo -> ” 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.
