net-misc/neon-0.26.1 should be blocker for net-fs/davfs2 davsf2 doesn't work with neon-0.26.1 and needs 0.24.X or 0.25.X to build.
I changed the dep to <neon-0.26, waiting for upstream to fix this one, I have not been successfull :(
Reopening this bug, as neon-0.26.1 went stable recently, and now is in full conflict with davfs2. davfs2 should block >=neon-0.26.1, one of them needs to be put back in unstable, or they need to be SLOT'd somehow.
Eh, <net-misc/neon-0.26 works *exactly* as bad as !>net-misc/neon-0.26 if the block is one-way, if the block is both ways then you get hell more people ranting b/c of being forced to downgrade and possibly rebuild stuff depending on it (and the block will still not work correctly afterwards). Please, go force portage folks to fix Bug 48195 instead of requesting annoying hacks.
jakub - I wasn't aware of the relationship to bug #48195. I don't feel my suggestions were "annoying hacks" -- personally, I find it much more annoying that davfs2 is now completely broken and unusable because neon-0.26.1 went stable. Furthermore, I tested neon-0.26* against davfs2 and subversion-1.3* earlier this month (check the date the bug was opened), and filed a couple bugs about the issue. When that happened I was told, by you, that "Well, honestly that's what you get for mixing stable and ~arch ebuilds... ;)" bug #139318, comment #2. So what do we have now? "stable" apps that are completely broken. I used to be a gentoo dev, so I feel I really do understand what is going on. I also feel I understand your perspective. Fixing bug #48195 is the "right way" to fix this. What can I say, maybe in two more years, it'll be fixed. None of this makes this bug any less annoying for those of us that (used to) depend on davfs2, to any extent. If subversion had this issue, because davfs2 required the upgrade, you can imagine what kind of hell would break loose. I hope this has come across polite, I mean it to be so. I take part in Gentoo these days mainly through reporting bugs, so I really do want to be helpful, and not annoying.
Uhm, you are just requesting something that doesn't work. The blockers are dead annoying, users file bugs about them over and over again. Deps like <foo/bar-x.y are ignored. Tell usptream to fix davfs2 or package.mask the incompatible neon version - all we can offer here I'm afraid until Bug 48195 gets fixed. The ebuild is correct as it is, portage is broken.
Upstreams is working on this issue : https://sourceforge.net/tracker/?func=detail&atid=386750&aid=1488505&group_id=26275 I'm currently testing the version 1.0.2 v1 locally, found no problems until now.
nice to see upstream acting on this. Please create a tarball removing the .svn-dirs. Upload it somewhere (or attach it to the bug) and make an updated ebuild ready. I can then add those to portage and everyone will be happy :) Thanks!
Created attachment 94832 [details] davfs CVS version 1.0.2 v1 I produced the tarball in that way: tfoerste@n22 ~ $ cvs -d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav login Logging in to :pserver:anonymous@dav.cvs.sourceforge.net:2401/cvsroot/dav CVS password: tfoerste@n22 ~ $ cvs -z3 -d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav checkout -r v1 -P davfs2 cvs checkout: Updating davfs2 U davfs2/Makefile.in ... cvs checkout: Updating davfs2/tools tfoerste@n22 ~ $ tar -cjpf davfs2.tbz2 davfs2/
Created attachment 94833 [details] console log of make process I'm not very familar in creating an ebuild. Using the tarball I did an $> autogen.sh followed by an configure call I shameless copied 1:1 from that configure command what was produced during the configure step of the 0.2.8 ebuild, after that I made an make && make install and I'm happy. The full konsole lag is attached.
Created attachment 94843 [details] davfs2-1.0.2_p20060820.ebuild please test this.
Created attachment 94844 [details] davfs2-1.0.2_p20060820.ebuild please test this.
Copying the 2nd ebuild to my /usr/local/protage overlay and making: $> https://n22/davfs@n22/ && emerge -a davfs2 compiles and installs it fine, only this might be worth to notice: --------------------------------------------------- Congratulations! davfs2 is installed successfully. ---------------------------------------------------- rm: cannot remove `INSTALL': No such file or directory rmdir: /var/tmp/portage/davfs2-1.0.2_p20060820/image//usr/share/davfs2: Directory not empty Looking into /usr/share/davfs2 I have only: n22 /usr/local/portage/net-fs/davfs2 # ll /usr/share/davfs2 total 24 -rw-r--r-- 1 root root 24 Aug 22 16:26 BUGS -rw-r--r-- 1 root root 17983 Aug 22 16:26 GPL IIRC I had more files during manual install, but anyway... Both my local davfs test environment works fine, production DAV FS can be accessed, the only (minor) thing I saw immediately after mounting an remote DAVFS was: $> /sbin/mount.davfs: Connection failed, mounting anyway. File system will only be usable when connection comes up. but the directory content is readable :-)
well, the last error is an upstream one, I corrected the two others and committed the ebuild, thanks.
*** Bug 144829 has been marked as a duplicate of this bug. ***
