Created attachment 369334 [details] build.log It seems, that sitecopy needs an old version of net-libs/neon See attached build.log
Created attachment 369336 [details] emerge --info
Unfortunately, this would break the dependency chain in stable. Dunno how it got stabled in the first place.
This is an old package I was listed as a maintainer. Quite soon there after, I was finally able to substitute a concatenation of other more recent and popular software tools, and have not used sitecopy ever since. Matter of fact, during the time I was added as maintainer, this specific bug occurred and supposedly fixed. Think the reason I was listed as maintainer, nobody else wanted this package, and they were considering dropping due to it hasn't seen any changes since 2004. My personal opinion, sitecopy is still very likely useful for some requiring such a tool. (ie. Dial-up servers using no standard means for uploading Web material.) Bug #141514, "stabilize net-misc/sitecopy-0.16.3 for neon-0.26.1" Bug #141827 "net-misc/sitecopy-0.16.0 is incompatiblet-misc/neon-0.26.1" (Duplicate of Bug #141514)
Bug #351637 "net-misc/sitecopy-0.16.6_p3 version bump" contains some additional notes on the Debian neon patches, and my last known activity with the Sitecopy Ebuild.
Correction: Sitecopy's last changes were in 2008. (Inline sitecopy changelog seems to state 2004.)
A sitecopy binary which I built in January 2011 --- probably with USE="nls ssl zlib -expat -rsh -webdav -xml" --- still works fine for me on a box which has net-libs/neon-0.30.0 installed. Looks like it builds and runs unaltered with neon 0.30: http://anonscm.debian.org/gitweb/?p=collab-maint/sitecopy.git;a=commitdiff;h=f4989180116e44f9c822a924623071b886cee6c7
I'm all for doing whatever needs to be done, or stripping-off neon support. Just attach or push a patch, and get it done. I keep getting a "configure: incompatible neon library version 0.30.0: wanted 0.24 25 26 27 28", even after stripping neon depends out of the ebuild. Also note, there's a patch being applied to neon-29, or neon-29.patch, for which I don't know what neon does or what the patch does. To build here, I have to go as far as manually deleting the "use_with xml libxml2" USE flag stuff for sitecopy to even start building. Then I get an ssl build time error, so I'm actually ending-up doing USE="-ssl -xml" Like I said, I haven't had the need to use sitecopy for a long time now, but do recognize the need for it as some are still on remote dial-up servers still using such protocols. I basically saved this sitecopy from Portage deletion. If it doesn't build by default, it could be listed for deletion once again! So the best options appear to be, either disable/comment-out the conflicting USE flags with an attached patch, or attach a patch fixing the neon stuff as well.
Created attachment 375550 [details, diff] let sitecopy-0.16.6_p3 build against neon-0.30.0 Attached: 0.16.6_p3-neon-30.patch Build-tested on amd64 with USE="nls ssl zlib -expat -rsh -webdav -xml". Runtime-tested with plain FTP. In order to test this, I locally modified sitecopy-0.16.6_p3.ebuild to apply this patch as last one. Better would be to create an ebuild which simply takes the latest Debian-packaged sitecopy, without further patches. Let's see whether I figure this out; never created ebuilds before.
Created attachment 375556 [details] sitecopy-0.16.6_p5.ebuild Attached a proposed ebuild which updates to Debian's sitecopy_0.16.6-5. No Gentoo-specific patch needed. Build-tested on amd64 with USE="nls ssl zlib -expat -rsh -webdav -xml" and runtime-tested for plain FTP transfer. Also build-tested on amd64 with USE="nls ssl zlib expat -rsh -webdav -xml" USE="nls rsh ssl zlib -expat -webdav -xml" USE="nls ssl webdav zlib -expat -rsh -xml" USE="nls ssl xml zlib -expat -rsh -webdav" USE="-expat -nls -rsh -ssl -webdav -xml -zlib" These variants I merely checked for successful completion of emerge, not what emerge does in detail. Also build-tested on x86 with USE="nls ssl zlib -expat -rsh -webdav -xml" and minimally runtime-tested on x86 (just evaluate .sitecopyrc, but then exit due to absent local files). I stripped KEYWORDS down to "~amd64 ~x86" but it is likely that the other formerly working architectures still work.
Eh. The sitecopy ebuild is pulling not just the patches, but even the original sources from Debian, instead of using the original SiteCopy page for the original sources. First three items here are only my mere suggestions: 1) First of all, the EBuild should be pulling the original sources from the original provider. (A change I would make, is pull from the original source published location, and then comment-out of Debian mirrors within the EBuild in the case the original source is no longer available.) 2) If Debian has C/Makefile patches, I think it's more preferable to see the patch researched or copied, and then applied in then further imported into the EBuild file/ folder. Upon looking over some of those patches, it almost looks as if sitecopy is now being maintained through Debian, versus maintaining directly. In other words, probably best not to pull directly from a competing distribution, but it's been done here as well as I think elsewhere. I did look over the debian/copyright file, and all files still appear to be under GPL-2+ and LGPL-2+. So probably legal, but not in good taste. And, I see no reason why we cannot just copy those debian/patches/* into our own tree. Each patch is well documented at the top with the original author's name and email address, as well as under GPL/LGPL? 3) Additional note: Build (AKA configure) rules are within debian/rules. Due to the low interest of sitecopy (but may still be needed by a few), I would do as Debian (and what you did) and just omit all the optional USE flags as well, as I think this is what is breaking the EBuild! (I was considering this several years ago, but hesitate deleting others' work, and then found I no longer required sitecopy.) Other than this, I downloaded your sitecopy-0.16.6_p5.ebuild (which omits all the optional USE flags) and everything compiles here on amd64 fine. TODO: Delete the "let sitecopy-0.16.6_p3 build against neon-0.30.0" because I think it's not even being used within your sitecopy-0.16.6_p5.ebuild. (As that neon-0.30 patch is already applied via Debian's patches?) So just mark it superseded/delete. Other than my first three mere suggestions above (which can be ignored because everything looks legal to me), I have no gripes. The ChangeLog should probably also note optional USE flags were removed, in favour of just using Debian's static rules or configure flags for simplicity of maintaining the sitecopy ebuild.
And I suggest marking this =net-misc/sitecopy-0.16.6_p5 version as stable, as older stable versions may have bugs with building with the newer neon, etc.
Comment on attachment 375550 [details, diff] let sitecopy-0.16.6_p3 build against neon-0.30.0 This is only needed for 0.16.6_p3 and _p4, but not anymore for _p5.
In the case sitecopy-0.16.6_p5.ebuild is not accepted (or ignored) due to Debian dependencies; I've started porting a vanilla sitecopy ebuild build, removing all the Debian related stuff. (ie. sitecopy-0.16.6-r1.ebuild) 1) Reverts to standard -r? Gentoo private release versioning suffixes. 2) Pulls all sources directly from SiteCopy's homepage. 3) If you want patches or USE flags, properly include them within the files/ folder and probably best not to directly pull Debian material. I'm out of time to further complete and test sitecopy-0.16.6-r1.ebuild. I would set the goals to just build the vanilla copy of sitecopy, omitting the neon stuff for simplicity. This way, sitecopy remains within portage. Users requiring further enhanced USE (or configure compile time) options can then properly submit the proper patches enabling such features later.
I should add I reviewed all the Debian related material, and you can likely copy (all) those Debian patches for sitecopy as they all appear to be submitted under the GPL from various authors into the sitecopy/files folder, maintaining the patch headers consisting of the original author's identification information.
Created attachment 376676 [details] sitecopy-0.16.6-r1.ebuild A vanilla sitecopy-0.16.6-r1.ebuild ebuild, in the case the above sitecopy-0.16.6_p5.ebuild (or -p? Debian copied) maintained package is not accepted. TODO: 1) Add gtk flag, for building gnome gtk frontend 2) If you want neon, xml, or any of the previous USE flags or patches, then port them over to Gentoo format instead of depending on the Debian maintained packages. This works and provides users with a stable package, and a stable EBUILD file foundation for building upon.
Created attachment 376680 [details] sitecopy-0.16.6-r1.ebuild Because I'm tired today, I invested a little more free time with an EBuild I don't use but wish to save. (I lived in a rural area once requiring old software tools, so I sympathize with those in similar circumstances. Or I may again need this tool myself.) This version of sitecopy-0.16.6-r1.ebuild adds the previous USE flags. So what basically occurred here with the -r1 version, I cut or ripped-out only the Debian related material. I then ported each patch within the Debian sitecopy archive into Gentoo's files/ folder. (ie. sitecopy_0.16.6-5.debian.tar.gz or *debian.tar.gz source tarball contains all patches and other info for building the Debian package, acquired from Debians http://ftp.debian.org/debian/pool/main/s/sitecopy/ mirror.) Everything else within this -r1 version pretty much remains the same within the Ebuild compared to previous -p? versions, except we're no longer pulling sources or patches from Debian! The only relying factor we're performing upon Debian, is manually copying the GPL provided patches from Debian into Gentoo. With this method, we're more politically correct and if Debian disappears, we still have a usable Gentoo package! NOTE: I've used static package name and version prefixes (ie. sitecopy-0.16.6-01-remote-dynamic-rc.patch) so future ebuilds do not merrily assume to use old patches which may no longer be needed. (ie. ${P}-remote-dynamic-rc.patch) NOTE: There are some brief TODO and NOTE sections within the EBuild to make future ebuild maintenance much easier! (ie. Similar to C coding.)
Created attachment 376682 [details, diff] sitecopy-0.16.6-01-remote-dynamic-rc.patch
Created attachment 376684 [details, diff] sitecopy-0.16.6-02-french-po-fix.patch
Created attachment 376686 [details, diff] sitecopy-0.16.6-03-wrong-memory-397155.patch
Created attachment 376688 [details, diff] sitecopy-0.16.6-04-manpages-addition-fixes.patch
Created attachment 376690 [details, diff] sitecopy-0.16.6-06-sftpdriver.c-fix-for-new-openssh.patch
Created attachment 376692 [details, diff] sitecopy-0.16.6-10-bts410703-preserve-storage-files-sigint.patch
Created attachment 376694 [details, diff] sitecopy-0.16.6-20-bts549721-add-compatibility-for-neon-0.29.0.patch
Created attachment 376696 [details, diff] sitecopy-0.16.6-30-bts320586-manpage-document-sftp.patch
Created attachment 376698 [details] sitecopy-0.16.6-r1.ebuild.20140510 Added a brief description of the file naming for patches. (ie. files/package_name - package_version - patch_order - patch_description) Retaining the Debian "patch_order" number is required, because I do not know if changing the order of the application of patches may break the application of another patch. Anyways, it's always a good idea to apply patches in the order that they are submitted or by chronological order, for which the Debian orders don't do anyways. Remember, you need to also download all sitecopy-0.16.6-*.patch files for this *-r1 ebuild! If you have no problems using this EBuild, please mark your sitecopy-0.16.6_p5.ebuild (and possibly other files) as obsolete to prevent confusion for Gentoo Developers! I would also then like to mark all previous sitecopy*ebuild versions as deprecated and removed from Portage, as they pull direction from Debian and their suffix version field will conflict with with Gentoo's version field.
Created attachment 376700 [details] sitecopy-0.16.6-r1.ebuild Oops. Uploaded an old file! This is the correct one!
Created attachment 376718 [details] sitecopy-0.16.6-r1.ebuild Fixed an inaccurate comment. This ebuild only requires EAPI=2, and not EAPI=5. (Maybe saves a little CPU/memory? ;-)
My above attached rewritten sitecopy-0.16.6-r1.ebuild along with above attached patches fixes this bug. Or if you prefer the older sitecopy ebuild which depended on Debian packages, then you can use the user above attached & user submitted sitecopy-0.16.6_p5.ebuild. However, my vote is for my completely rewritten sitecopy-0.16.6-r1.ebuild stripping all Debian dependencies. (And, I'm tempted to mark sitecopy-0.16.6_p5.ebuild as deprecated because I haven't heard much feedback.) If you're going to commit my attached sitecopy-0.16.6-r1.ebuild with attached patches, then omit the above attached sitecopy-0.16.6_p5.ebuild, and remember to include the above attached patches! (If there's no feedback from Stefan Richter within the next week, I'll just go ahead and mark his EBuild as deprecated in favor of my rewrite, as I think his implemented more of the older Debian dependencies. I don't want to yank something if my rewrite doesn't work, but pretty sure mine has zero problems.)
Comment on attachment 375556 [details] sitecopy-0.16.6_p5.ebuild Back in May I looked through sitecopy-0.16.6-r1.ebuild and the associated patches and they looked fine to me. I now did a single build test with USE="nls ssl zlib -expat -rsh -webdav -xml" and a quick runtime-test of the result, and it works for me. So I'm OK with skipping 0.16.6_p5 in favor of 0.16.6-r1. Thanks.
still a problem with 0.16.6_p3: checking for neon-config... /usr/bin/neon-config checking linking against neon... yes configure: incompatible neon library version 0.30.1: wanted 0.24 25 26 27 28 29 configure: error: could not use external neon library !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-misc/sitecopy-0.16.6_p3/work/sitecopy-0.16.6/config.log * ERROR: net-misc/sitecopy-0.16.6_p3::gentoo failed (configure phase): * econf failed * This chroot image is located at a hardened amd64 system. Portage 2.2.14 (python 2.7.8-final-0, default/linux/amd64/13.0, gcc-4.8.3, glibc-2.20, 3.17.3-hardened x86_64) ================================================================= System uname: Linux-3.17.3-hardened-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16166892 total, 7663680 free KiB Swap: 16777212 total, 16777212 free Timestamp of tree: Sat, 15 Nov 2014 18:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.3_p30-r1 dev-lang/perl: 5.20.1-r2 dev-lang/python: 2.7.8, 3.3.5-r1 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.3-r2 sys-devel/make: 4.1-r1 sys-kernel/linux-headers: 3.17-r1 (virtual/os-headers) sys-libs/glibc: 2.20 Repositories: gentoo ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner --tree --quiet-build --deep --jobs 1" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.leaseweb.com/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 mbox mmx modules multilib ncurses nls nptl openmp pam pax_kernel pcre readline session sse sse2 ssl tcpd unicode zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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 cgi cgid 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" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
sitecopy-0.16.6_p3 is masked. The past *_p? versions had embedded Debian patches and dependencies, for which I won't support. So I rewrote the sitecopy EBuild and designated it as sitecopy-0.16.6-r1.ebuild. This should cure your problem, as well as create a more readily patchable sitecopy EBuild. sitecopy-0.16.6-r1.ebuild above along with patches is the new version. Shrugs as to why it hasn't been pushed into the tree. Testing would be appreciated to verify sitecopy-0.16.6-r1.ebuild compiles & works as expected. (Likely the portage tree needs to be cleaned of the older *_p? versions.)
Since my comment 29, I have been using sitecopy-0.16.6-r1 from attachment 376718 [details] without issues. For other users who never used an out-of-tree ebuild before, here is how I tested it: - added the line 'PORTDIR_OVERLAY="/usr/local/portage"' to /etc/portage/make.conf (or /etc/make.conf on older installations) - stored sitecopy-0.16.6-{01,02,03,04,06,10,20,30}-*.patch at /usr/local/portage/net-misc/sitecopy/files/ - stored sitecopy-0.16.6-r1.ebuild at /usr/local/portage/net-misc/sitecopy/ - ran 'ebuild /usr/local/portage/net-misc/sitecopy/sitecopy-0.16.6-r1.ebuild manifest' - added the line '=net-misc/sitecopy-0.16.6-r1' to /etc/portage/package.keywords - made sure that no other versions than this one remained whitelisted in /etc/portage/package.keywords - ran 'emerge -av sitecopy' Side note: Current emerge logs the following warning: "This package has a configure.in file which has long been deprecated. Please update it to use configure.ac instead as newer versions of autotools will die when it finds this file. See https://bugs.gentoo.org/426262 for details."
the stable amd64 package is broken too : hecking for x86_64-pc-linux-gnu-ar... /usr/bin/x86_64-pc-linux-gnu-ar checking for x86_64-pc-linux-gnu-ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib checking for neon-config... /usr/bin/neon-config checking linking against neon... yes configure: incompatible neon library version 0.30.1: wanted 0.24 25 26 27 28 29 configure: error: could not use external neon library !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-misc/sitecopy-0.16.3_p17/work/sitecopy-0.16.3/config.log * ERROR: net-misc/sitecopy-0.16.3_p17::gentoo failed (configure phase): * econf failed This chroot image is located at a hardened amd64 system. Portage 2.2.14 (python 2.7.7-final-0, default/linux/amd64/13.0, gcc-4.8.3, glibc-2.19-r1, 3.17.7-hardened x86_64) ================================================================= System uname: Linux-3.17.7-hardened-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16166920 total, 4337224 free KiB Swap: 16777212 total, 16777212 free Timestamp of tree: Fri, 19 Dec 2014 11:45:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p53 dev-lang/perl: 5.18.2-r2 dev-lang/python: 2.7.7, 3.3.5-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 ...
Toralf Förster: The only build I'm supporting as currently stable is the above attached sitecopy-0.16.6-r1.ebuild. The current sitecopy ebuilds within portage (designated as suffixed version "_pNUM") includes Debian sources and Debian patches. The sitecopy-0.16.6-r1.ebuild removes these dependencies, ensuring all patches are provided by Gentoo. I also quickly reviewed the licenses of the (Debian) patches when porting.
(In reply to Andre Hinrichs from comment #0) > Created attachment 369334 [details] > build.log > > It seems, that sitecopy needs an old version of net-libs/neon > See attached build.log why is the attachment test/x-log and not text/plain ?
"build.log (6.06 KB, text/x-log)" Submitted "2014-02-02 11:48 UTC, Andre Hinrichs" are in ASCII or plain text. The prefixed characters you see are designations for terminal color or are terminal color codes. You can either safely ignore them or delete them if need be. (These can be turned off using the 'emerge --color n' flag.) Matter of fact, those attached build.log & "emerge --info" files are really just clutter now on this bug report, as I've already created a fully working sitecopy-0.16.6-r1.ebuild (attached) along with the attached required patches. (Follow the dates appended to each attachment!) I basically ported the existing sitecopy ebuild which were amazingly just merrily copied Debian packages (with EBuild versions suffixed with "_p[num]" or "_p1") which pulled all sources and patches from the Debian mirrors! Now the above attached sitecopy EBuild has all sources and patches included within the Gentoo tree. And everything should just work now using the above attached sitecopy-0.16.6-r1.ebuild. I have no idea how those copied Debian packages (with EBuild versions suffixed with "_p[num]" or "_p1") made it into the Gentoo Portage tree, and likely probably shouldn't have been. They should likely be cleaned from the Gentoo Portage tree. (ie. sitecopy-0.16.3_p17.ebuild, net-misc/sitecopy-0.16.6_p3.ebuild) And as to why people keep posting that they too see this old bug without even noting the bug is fixed with the attached fixed EBuilds & patches above, shrugs. I'm a simple volunteer with no need of attaining a developer status in order to push EBuilds to Portage, which incurs additional liability and more work on my part! ;-)
ok I'll dare to ask. 1. Why has this ebuild sitecopy-0.16.6-r1.ebuild never been added to portage. especially since it was added in May last year? 2. I have no idea how those copied Debian packages (with EBuild versions suffixed with "_p[num]" or "_p1") made it into the Gentoo Portage tree *sitecopy-0.16.6_p3 (16 Jan 2011) 16 Jan 2011; Markos Chandras <hwoarang@gentoo.org> +sitecopy-0.16.6_p3.ebuild, metadata.xml: Version bump. Bug #351637. Thanks to Roger Zauner <rogerx.oss@gmail.com> 3. EAPI This ebuild only requires EAPI=2, and not EAPI=5. (Maybe saves a little CPU/memory? ;-) Between keeping up with the most recent EAPI and saving a little CPU/memory, I am sure the former wins out here. 4. Out of interest would you care to have the sitecopy-0.16.6-r1.ebuild added to portage. Also would you like to have the others purged? 5. A minor point here. One of the features of eutils is that it comes with PATCHES=( ). Considering there are 8 of them, would it not be worthy to consider shifting all patching to PATCHES=( ) ??
>>> 1. Why has this ebuild sitecopy-0.16.6-r1.ebuild never been added to portage. especially since it was added in May last year? I don't have permission to commit to Portage. I'm just a (well known) volunteer. >>> 2. I have no idea how those copied Debian packages (with EBuild versions suffixed with "_p[num]" or "_p1") made it into the Gentoo Portage tree *sitecopy-0.16.6_p3 (16 Jan 2011) 16 Jan 2011; Markos Chandras <hwoarang@gentoo.org> +sitecopy-0.16.6_p3.ebuild, metadata.xml: Version bump. Bug #351637. Thanks to Roger Zauner <rogerx.oss@gmail.com> EBuild sitecopy-0.16.6_p3 was a version bump or version upgrade, from a previous likely sitecopy-0.16.6_p2. Simply copied and fixed. I have no intentions of tracking the original commit, just bringing to notice the original EBuild included Debian statically linked sources and patches, likely in conflict with licensing? The -r[num] suffix is rewritten and should provide exactly the similar experience, if not better. >>> 3. EAPI This ebuild only requires EAPI=2, and not EAPI=5. (Maybe saves a little CPU/memory? ;-) Between keeping up with the most recent EAPI and saving a little CPU/memory, I am sure the former wins out here. From memory, you're exactly correct. The more extensive functions provided by the higher EAPI version numbers are not needed. (ie. If you're on a limited resource platform, you'll likely be thankful the scripter or programmer thought of being conservative with resources or optimized the code.) >>> 4. Out of interest would you care to have the sitecopy-0.16.6-r1.ebuild added to portage. Also would you like to have the others purged? Yes please, unless anybody objects, or you see something funny or odd. (If people object, then probably best not to ruffle any feathers, but looks like everybody is happy with the current performance of my sitecopy-0.16.6-r1.ebuild rewrite?) >>> 5. A minor point here. One of the features of eutils is that it comes with PATCHES=( ). Considering there are 8 of them, would it not be worthy to consider shifting all patching to PATCHES=( ) ?? Looks like using PATCHES=() would then only provide one call to "patch", or maybe at the very least reading just one patch line within the EBuild by Portage. So yes, probably wise, but at this point I haven't used SiteCopy for the past decade and still only provide assistance with the SiteCopy EBuild based on past experience with it's history. I say instead of wasting more time on this, just push it into the tree as long as it's acceptable! There's always going to be something always performed differently within the future! This will likely be one of the last times SiteCopy is pushed into the tree except for maybe very minor future fixes. Thanks for your time and hopefully your questions were answered well.
sitecopy-0.16.6-04-manpages-addition-fixes.patch and only it is failing for me. It's size is 48564bytes. The package builds and installs without this patch run. I have no idea how or why. To my understanding the package and patches haven't changed. What I know is this patch when it does work is so big I'll have to shunt it to my dev space to take the pressure off the cvs tree. Please revise and re-test this patch then I can add it to the tree
(In reply to Ian Delaney from comment #39) > sitecopy-0.16.6-04-manpages-addition-fixes.patch and only it is failing for > me. It's size is 48564bytes. [...] Are you sure the issue with this patch is its size, and not perhaps the fact that it contains 8 bit characters? Among else, the patch changes the encoding of several special characters from UTF-8 to ISO 8859-1 (or -15).
If I'm not mistaken, I've have edited none of the patches, and simply copied those patches out of the existing Debian tree, or copied from other sites and/or mailing lists. I scanned over the licensing for the patches back in May 2014 and they were all licensed GPL or publicly submitted. The man page patch is much smaller than other files. Personally, I do not see how patch size can effect the performance of diff/patch unless there's a bug in patch. I think the UTF characters might be giving you a problem though. And if I'm not mistaken, you'll have a similar issue with the already in-tree sitecopy if it contains the same patch.
Edit: Oops. The man page patch is not smaller than the others. (I typed this while looking at the second man page patch, and forgot to remove this comment after seeing the first man page patch.)
Created attachment 395196 [details] patch out (In reply to Stefan Richter from comment #40) > (In reply to Ian Delaney from comment #39) > > sitecopy-0.16.6-04-manpages-addition-fixes.patch and only it is failing for > > me. It's size is 48564bytes. [...] > > Are you sure the issue with this patch is its size, and not perhaps the fact > that it contains 8 bit characters? Among else, the patch changes the > encoding of several special characters from UTF-8 to ISO 8859-1 (or -15). I am sure the size has nothing to do with the patch failing. I never said it did. Have you ever done /path/to/net-misc/sitecopy $ ebuild sitecopy-0.16.6-r1.ebuild clean prepare because I did. For the sake of seeing all other patches pass I merely shifted the 'offending' patch to last. What I know is this patch is big and it fails. I never said this patch fails because it is big. Forget it being big. IT FAILS. That it comes from debian shouldn't effect its tech merit. I just know it fails. Plan. Fix the patch so it passes on my std gentoo system or tell me the package can survive without it and I can add the ebuild minus this patch. I suspect this all would have happened last May.
(In reply to Ian Delaney from comment #43) I for one cannot reproduce any sort of failure with sitecopy-0.16.6-r1.ebuild. Particularly, all of the patches including sitecopy-0.16.6-04-manpages-addition-fixes.patch are successfully applied. I do get the following warnig message: "This package has a configure.in file which has long been deprecated. Please update it to use configure.ac instead as newer versions of autotools will die when it finds this file. See https://bugs.gentoo.org/426262 for details." Aside from this, the prepare stage goes through perfectly here (and configure, build, install too). (I am on amd64 and on x86, with only a few packages at ~amd and ~x86, stock portage tree except for net-misc/sitecopy, profile is default/linux/{amd64,x86}/13.0, LANG=en_US.utf8 on the amd64 box and LANG="" on the x86 box if any of that matters.)
(In reply to Ian Delaney from comment #39) > sitecopy-0.16.6-04-manpages-addition-fixes.patch and only it is failing for > me. > It's size is 48564bytes. Oops. This is what I downloaded, and what works for me: $ ll /usr/local/portage/net-misc/sitecopy/files/sitecopy-0.16.6-04-manpages-addition-fixes.patch -rw-r--r-- 1 root root 46803 Jun 24 2014 /usr/local/portage/net-misc/sitecopy/files/sitecopy-0.16.6-04-manpages-additio $ md5sum /usr/local/portage/net-misc/sitecopy/files/sitecopy-0.16.6-04-manpages-addition-fixes.patch 91c9bb5f38f608c9db5db11474a2817b /usr/local/portage/net-misc/sitecopy/files/sitecopy-0.16.6-04-manpages-addition-fixes.patch
well, Stefan Richter thx for replies. I don't know what's going on here, unitl now. The confusion appears to be from nano or scite. The file size difference was a clue. testuser@archtester ~/improvise/net-misc/sitecopy $ ls -ld files/sitecopy-0.16.6-04-manpages-addition-fixes.patch -rw-r--r-- 1 testuser testuser 46803 Jan 30 18:25 files/sitecopy-0.16.6-04-manpages-addition-fixes.patch I had done a copy paste from the browser of the patch's content. It hasn't copy pasted cleanly apparently. I acquired the file by wget and substituted the file d'loaded and it now works. testuser@archtester ~/improvise/net-misc/sitecopy $ ebuild sitecopy-0.16.6-r1.ebuild clean prepare * sitecopy-0.16.6.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking sitecopy-0.16.6.tar.gz to /mnt/gen2/TmpDir/portage/net-misc/sitecopy-0.16.6-r1/work >>> Source unpacked in /mnt/gen2/TmpDir/portage/net-misc/sitecopy-0.16.6-r1/work >>> Preparing source in /mnt/gen2/TmpDir/portage/net-misc/sitecopy-0.16.6-r1/work/sitecopy-0.16.6 ... * Applying sitecopy-0.16.6-01-remote-dynamic-rc.patch ... [ ok ] * Applying sitecopy-0.16.6-02-french-po-fix.patch ... [ ok ] * Applying sitecopy-0.16.6-03-wrong-memory-397155.patch ... [ ok ] * Applying sitecopy-0.16.6-06-sftpdriver.c-fix-for-new-openssh.patch ... [ ok ] * Applying sitecopy-0.16.6-10-bts410703-preserve-storage-files-sigint.patch ... [ ok ] * Applying sitecopy-0.16.6-20-bts549721-add-compatibility-for-neon-0.29.0.patch ... [ ok ] * Applying sitecopy-0.16.6-30-bts320586-manpage-document-sftp.patch ... [ ok ] * Applying sitecopy-0.16.6-04-manpages-addition-fixes.patch ... [ ok ] * This package has a configure.in file which has long been deprecated. Please * update it to use configure.ac instead as newer versions of autotools will die * when it finds this file. See https://bugs.gentoo.org/426262 for details. * Running autoconf ... [ ok ] >>> Source prepared. I'll finish it off later
Created attachment 395216 [details] sitecopy-0.16.6-r1.ebuild Added a comment within the EBuild addressing Bug #426262 "rename configure.in to configure.ac internally (automake-1.14 compatibility)". The comment includes a reference to the bug as well as a working commented quick fix.
big patch shifted to devspace, half stabled version purged, the sitecopy-0.16.6-r1.ebuild added to portage with new addition, EAPI updated. A few minor syntax / order changes but all 'cosmetic'. *sitecopy-0.16.6-r1 (31 Jan 2015) 31 Jan 2015; Ian Delaney <idella4@gentoo.org> +files/sitecopy-0.16.6-01-remote-dynamic-rc.patch, +files/sitecopy-0.16.6-02-french-po-fix.patch, +files/sitecopy-0.16.6-03-wrong-memory-397155.patch, +files/sitecopy-0.16.6-06-sftpdriver.c-fix-for-new-openssh.patch, +files/sitecopy-0.16.6-10-bts410703-preserve-storage-files-sigint.patch, +files/sitecopy-0.16.6-20-bts549721-add-compatibility-for-neon-0.29.0.patch, +files/sitecopy-0.16.6-30-bts320586-manpage-document-sftp.patch, +sitecopy-0.16.6-r1.ebuild, -sitecopy-0.16.6_p3.ebuild: bump subsequent to bug #500070, new patches to match, bump EAPI, removed -0.16.6_p3, all wrt bug #500070 NOTE: RepoMan scours the neighborhood... KEYWORDS.dropped 1 net-misc/sitecopy/sitecopy-0.16.6-r1.ebuild: amd64-linux ppc ppc-macos sparc x86-linux Do you want these keywords re-added. Just need make the request in a std keyword request bug except for {amd64-linux x86-linux} which are prefix arches and not stable arches. I can add those any time. Now, this bug is actually about sitecopy-0.16.3_p17 which, stated in comments, is no longer supported by Roger. To purge it, Roger need await >= 30 days then submit a full stable req for the newly added sitecopy-0.16.6-r1. THEN I can purge it without breaking portage and its extensive protocol. I cannot close this FIXED but rather WONTEVERFIX because of above cited comments. I leave it open as is and await suggestions re what conditions under which to finally close it, ans when.
1) I have no preference on keywords, except that this builds fine on 64 bit Intel. (AKA AMD64) Others whom actually use this package, will need to report on stability, whom are likely dial-up users or using servers not blessed with RSync capabilities. 2) I've noted the purge request for the sitecopy-0.16*_p? containing Debian stuff request, but only after waiting 30 days to verify the above submitted sitecopy-0.16.6-r1.ebuild is proven stable within the Portage tree. If for some reason I forget or I cease to exist, the notes are here on my (or others') intentions. Thanks for you time Ian. Those stuck with having to use SiteCopy (not that SiteCopy is bad) instead of having the luxury of using RSync likely love you now. This is why I volunteer and don't mind spending a little time on this package, as I know it's value from being stuck on dial-up every now and then. Cheers.
well the question to my mind is how they ever got added in the past. Once dropped they need a request to re-keyword. I have no way of knowing the history that saw them acquire the keywords that have been dropped. They don't get re-added by auto pilot by the minor arch teams. As for ceasing to exist, well the less expanded on that the better. Anyone can close this bug as they see fir. Technically re-keywording and a stable req are 2 separate bugs to this
NOTE: Per comment #48, it's almost 30 days since 2015.01.31, or approximate inclusion of sitecopy-0.16.6-r1. So myself or anybody still monitoring, ensure a stabilization request is posted. Or more specifically, bug requesting stabilization of sitecopy-0.16.6-r1 is posted. This is need so we can purge the older "_p17" suffixed stuff having Debian static sources and patches.
*** Bug 542350 has been marked as a duplicate of this bug. ***
sitecopy-0.16.6-r1.ebuild is now in portage and marked stable. sitecopy-0.16.3_p17.ebuild still remains within portage and needs to be masked for removal, or maybe just keyworded to prevent default install and warn current intermittent users. Just in case we have users that somehow have it working for them.
24 Apr 2015; Ian Delaney <idella4@gentoo.org> -files/0.16.3_p17-neon-29.patch, -sitecopy-0.16.3_p17.ebuild: purge outdated snapshot and the disused patch NOTE: Normally this would be closed RESOLVED FIXED but this bug was always about net-misc/sitecopy-0.16.3_p17. The topic never having changed makes the final state require either OBSOLETE or WONTFIX
