Portage 2.2.0_alpha110 (default/linux/amd64/10.0, gcc-4.7.1, glibc-2.15-r2, 3.4.2-hardened x86_64) ================================================================= System uname: Linux-3.4.2-hardened-x86_64-AMD_Opteron-TM-_Processor_6272-with-gentoo-2.1 Timestamp of tree: Sat, 16 Jun 2012 07:30:01 +0000 app-shells/bash: 4.2_p29 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.8-r3 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.10.3 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.5, 1.12.1 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.3-r2, 4.7.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo Installed sets: ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -ggdb -march=native -ftracer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" 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/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -ggdb -march=native -ftracer" DISTDIR="/var/cache/portage/distfiles" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict test test-fail-continue unknown-features-warn unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j24" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/var/cache/portage/tree" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri ffmpeg fortran gdbm gpm iconv ipv6 mmx modules mudflap multilib ncurses nls nptl openmp pam pcre pppd qt3support readline session sse sse2 sse3 sse4 ssl ssse3 tcpd unicode vhosts xorg zlib" 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" 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 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" 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 ubx" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 jruby ruby19 ree18" USERLAND="GNU" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Taking care upstream no longer develops it and current version in the tree doesn't even start, I think it's time to treeclean this
Hey, what is this nonsense about Sancho? It starts on my system (~amd64) every day, and works fine. And development didn’t “cease”. They are simply waiting for the development in mldonkey. The software is perfectly fine for use with the current mldonkey. There simply was no need for pointless updates for the sake of updates. It is not KDE. And it is the ONLY full-featured GUI for mldonkey, which is the ONLY *headless* multi-protocol file-sharing software. So there *really* isn’t a choice here. Pointlessly completely banning it because of one little bug, is waaayyy over the top here. Imagine we’d ban KDE for having a bug. They’d be *always* banned forever. And worst of all, this bug doesn’t even contain any actual information about what’s supposed to be the problem. All Sancho does, is connect to mldonkey anyway. Over a secure line (either LAN or through an ssh tunnel). So where exactly is this security attack point? How about contacting the developer, and letting him know. I’m sure he’ll fix it. If you have to be a crazy person about a security problem with no possible implications, go and mask it until then. But removal is *not* an option. This is beyond ridiculous.
It's not nonsense, you say development has not ceased but, in fact, it's stalled as that changes they are waiting for mldonkey won't probably land ever. Also it has multiple problems for a long time waiting for a solution: https://bugs.gentoo.org/show_bug.cgi?id=298731 -> this shows that, even not affecting to you, there are some people affected And this bug Simply read what they show in they homepage: "sancho patiently waits for: • mldonkey: to find a developer that can continue development • gcj: a fix for its bad reference bug (locks up/high cpu after a long uptime) sancho has become tired of dealing with the previous webhost's problems, so he intrepidly forges ahead... let's see how well this distribution system works. Maybe on to a real web host some day. The latest version has been recompiled to avoid an XP SP3 issue, and contains the latest SWT library which should fix some issues with XULrunner, table jumping to selection, and some other minor changes." and that message is there for months (at least since I started noticing its unresolved bugs here downstream), probably even more
(In reply to comment #3) > It's not nonsense, Yes, it is nonsense. > you say development has not ceased So, I did not say that at all. I said, development has not stalled. There is a difference. > but, in fact, it's stalled No, it has not. It is on hold. There is a difference. > as that changes they are waiting for mldonkey won't probably land ever. Wow. I know exactly that you (deliberately) didn’t even check, let alone being up-to-date on the mldonkey development status. Otherwise you’d know that development has started again, with new versions (3.1.x) having come out, and problems being fixed. (Slowly, but steadily.) Yet you chose to deliberately lie, to get rid of Sancho, and support your argument, even though you know you are wrong. This is low. Really low. (Did you think I wouldn’t notice?) > Also it has multiple problems for a long time waiting for a solution: > https://bugs.gentoo.org/show_bug.cgi?id=298731 -> this shows that, even not > affecting to you, there are some people affected Well, that user should fix is system! It’s not like there are any use flags that could result in different code for him. How about asking me how it runs fine here (and everywhere else), so you can work out what’s different on his buggy box. And since when is that an argument for masking? This is not even related to this bug or your argument for removal. > Simply read what they show in they homepage: > "sancho patiently waits for: > • mldonkey: to find a developer that can continue development > • gcj: a fix for its bad reference bug (locks up/high cpu after a long > uptime) *YOU DON’T SAY!* (http://knowyourmeme.com/memes/you-dont-say) That is *my exact point*. He waits for mldonkey. Which is in progress of fixing things. Until then, there simply was nothing to do. Imaginary bugs based on buggy systems don’t count. Did you even try to contact the developer? I contacted him just now. Let’s find out… > and that message is there for months (at least since I started noticing its > unresolved bugs here downstream), probably even more So? What is it with you and this crazy need for constant code changes without any need for them, and without even talking to the developer about bugs you found? This is ridiculous. Why is there always this unprofessional nonsense going on?
+1 for removal, I don't see net-p2p@ having time for this, needs a dedicated maintainer
(In reply to comment #5) > +1 for removal, I don't see net-p2p@ having time for this, needs a dedicated > maintainer I’m dedicated. What do you need me to do?
(In reply to comment #6) > (In reply to comment #5) > > +1 for removal, I don't see net-p2p@ having time for this, needs a dedicated > > maintainer > > I’m dedicated. What do you need me to do? Based on minute of inspection: How about a patch, that possible uses app-admin/chrpath, to get rid of the insecure rpath(s) as mentioned in this bug? (See URL: field for log)
CC proxy-maint@g.o for Comment #6
Some reading: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
(In reply to comment #4) > (In reply to comment #3) > > It's not nonsense, > > Yes, it is nonsense. > > > you say development has not ceased > > So, I did not say that at all. I said, development has not stalled. There is > a difference. You textually said: "And development didn’t “cease”", simply re-read comment #2 and the private mail you sent me. > > > but, in fact, it's stalled > > No, it has not. It is on hold. There is a difference. It doesn't include any bug fix, that is what really matter, how do we call it is not so important. > > > as that changes they are waiting for mldonkey won't probably land ever. > > Wow. I know exactly that you (deliberately) didn’t even check, let alone > being up-to-date on the mldonkey development status. Otherwise you’d know > that development has started again, with new versions (3.1.x) having come > out, and problems being fixed. (Slowly, but steadily.) But the problems they are waiting for (from mldonkey and gcj) look to be still unresolved as sancho development is still paused and no release at all since a long time. > > Yet you chose to deliberately lie, to get rid of Sancho, and support your > argument, even though you know you are wrong. This is low. Really low. > (Did you think I wouldn’t notice?) > Seriously, please think before talking to prevent you from telling stupid things, I have many other things to do that "deliberately lie" to drop a package, we are not kids. > > Also it has multiple problems for a long time waiting for a solution: > > https://bugs.gentoo.org/show_bug.cgi?id=298731 -> this shows that, even not > > affecting to you, there are some people affected > > Well, that user should fix is system! It’s not like there are any use flags > that could result in different code for him. How about asking me how it runs > fine here (and everywhere else), so you can work out what’s different on his > buggy box. If I don't misremember, that bug has at least two affected users telling current version in tree (from 2007) is broken for them, net-p2p didn't looked to the problem and the bug got stalled. I didn't even know you before this, I don't understand how would you expect me to try to consult you before (?!). Also, don't forget about this bug that is also affecting sancho and should be fixed. > > And since when is that an argument for masking? This is not even related to > this bug or your argument for removal. > > > Simply read what they show in they homepage: > > "sancho patiently waits for: > > • mldonkey: to find a developer that can continue development > > • gcj: a fix for its bad reference bug (locks up/high cpu after a long > > uptime) > > *YOU DON’T SAY!* (http://knowyourmeme.com/memes/you-dont-say) > > That is *my exact point*. > > He waits for mldonkey. Which is in progress of fixing things. Until then, > there simply was nothing to do. Imaginary bugs based on buggy systems don’t > count. > > Did you even try to contact the developer? I contacted him just now. Let’s > find out… > > > and that message is there for months (at least since I started noticing its > > unresolved bugs here downstream), probably even more > > So? > > What is it with you and this crazy need for constant code changes without > any need for them, and without even talking to the developer about bugs you > found? > > This is ridiculous. Why is there always this unprofessional nonsense going > on? Simply re-read all the bugs and you will see the reasons for masking it for removal, I have explained them multiple times, also in mask message itself. (In reply to comment #6) > (In reply to comment #5) > > +1 for removal, I don't see net-p2p@ having time for this, needs a dedicated > > maintainer > > I’m dedicated. What do you need me to do? Prepare an updated ebuild to bump it to latest version (#255490) and, at least, get this bug fixed (since it doesn't starting could be solved in latest released version, I would also check it and, if it works for us, would try to bump it and keep it). Please also look to: http://www.gentoo.org/proj/en/qa/proxy-maintainers/
Futhermore an ebuild for bug 255490 would be an enchancement that should propably be taken care of at the same time with this bug. No ebuild (patch) has been attached there yet.
Navid, you also should not take the package removal process for any package so personally, also the treecleaners project in currently understaffed and it's not reasonable to assume they/we have time to investigate every bug to the atoms. If no maintainer responds on the bug, the package is likely to get removed, as the final investigation should be up to the maintainer -- not the treecleaners. Luckily Gentoo is so flexible you can easily add local overlays... Just my 1 cent.
Also, if you are able to provide an updated ebuild fixing this insecure rpaths bug, I can be your proxy for maintaining sancho
(In reply to comment #11) > Futhermore an ebuild for bug 255490 would be an enchancement that should > propably be taken care of at the same time with this bug. No ebuild (patch) > has been attached there yet. That should be no problem. I’ll do that first. (In reply to comment #7) > How about a patch, that possible uses app-admin/chrpath, to get rid of the > insecure rpath(s) as mentioned in this bug? (See URL: field for log) If that’s still the case with the new version, I will focus on that first. Should be easy. I know Java, and could actually even change Sancho itself if necessary. Can’t do anything about bug #298731 though, since I can’t reproduce it. So then, Sancho should be good again. (And let’s see what happens when the upstream developer responds.)
(In reply to comment #12) > Navid, you also should not take the package removal process for any package > so personally, Don’t worry. I’m very rarely taking things personally. I just can’t stand seeing (willful) ignorance/delusion. It is the root of all evil. > also the treecleaners project in currently understaffed and > it's not reasonable to assume they/we have time to investigate every bug to > the atoms. No worries here either. I do not expect anyone to do anything, just because I want it. (Let alone for free.) Unless there is an actual contract/promise and I’m giving something in return. Just: Why did he create all those false arguments, and not just say so? People can smell when somebody already has decided before considering the evidence, and is only looking for arguments to support what is already set in stone… and it’s not cool. Would he just have said “Sorry, this is too much of a hassle and simply not worth it for me. So unless somebody else steps up (Anyone?), I have to remove this from the tree, to prevent rot.” I would have completely understood and offered to step in. > If no maintainer responds on the bug, the package is likely to get removed, > as the final investigation should be up to the maintainer -- not the > treecleaners. Correct. It is very important though, to note here, that people have to hear an acceptable reason. I’ve had packages before, where the comment was just what I recommended above. Here though… It is very irritating to get told that a program doesn’t compile or run, has big bugs, and is not maintained, when you know for a fact, that none of this is true, since the damn thing is running on your box *right now*, compiled fine, and know the project and its dependencies are in a good state. I hope you can understand that… > Luckily Gentoo is so flexible you can easily add local overlays... Well… The question is, if you’d like it, when the overlays would become more of a fork of Gentoo as a whole, and would start to take over the project… ;) Here’s another 1 cent from me. Now we have the full 2 cents. :)
(In reply to comment #13) > Also, if you are able to provide an updated ebuild fixing this insecure > rpaths bug, I can be your proxy for maintaining sancho Sorry, I have no interest in working with you personally. I’m sure you understand.
No, I don't understand why you have a personal problem with me thinking I was lying and creating false arguments when I was always referring to already reported bugs, but ok, you are free to refuse my help and think I don't have better things to do than hurting you
Please guys dial it down. If anyone is willing to maintain it (and address the problems of course) then contact proxy-maint@gentoo.org. Otherwise the package will be removed on the given date
Alright. All problems solved. The rpath problem and the library mismatch only occurred with the native binary. Which is now removed in the updated ebuild. See bug #255490.
About the rpath: The actual binary was placed at /opt/sancho/sancho-bin. Inaccessible from $PATH. And there was a tiny shell script at /opt/bin/sancho, which did nothing else than cd to /opt/sancho, and run ./sancho-bin. That script was also, what the .desktop file called. So logically, the rpath was never a problem, and it was a false alarm for the rare occasion of somebody running /opt/sancho/sancho-bin directly, from another path, without using the script. Or am I wrong with this? I don’t think that is a problem. Let alone a security risk.
(In reply to comment #19) > Alright. All problems solved. The rpath problem and the library mismatch > only occurred with the native binary. Which is now removed in the updated > ebuild. > See bug #255490. You missed my point that a dedicated maintainer is required ( or proxy ). Otherwise solving the problems and let the package rot in the tree is not good for our QA. Are you willing to step up and maintain it?
(In reply to comment #20) the RPATH is broken for no good reason. it should be using $ORIGIN and $ORIGIN/../lib, not . and ../lib.
(In reply to comment #21) > You missed my point that a dedicated maintainer is required ( or proxy ). > Otherwise solving the problems and let the package rot in the tree is not > good for our QA. Are you willing to step up and maintain it? Actually, you missed the point. Me being the maintainer now was implied, since my mail to proxy-maint@gentoo.org made it plenty obvious. But frankly, I just got over it. I’m greeted by nothing but dickishness, stupid bickering and general craziness in here. Empathic skills: Below measurable levels. (With the exception of Samuli Suominen.) Hence, I have no interest in further interaction with all the troglodytes in this cave. I will now maintain my own overlay, to work around your mess, until project OzonS is finished.
(In reply to comment #23) sadly, i'm sure the irony in your position/statements are completely lost on you
(In reply to comment #23) > (In reply to comment #21) > > You missed my point that a dedicated maintainer is required ( or proxy ). > > Otherwise solving the problems and let the package rot in the tree is not > > good for our QA. Are you willing to step up and maintain it? > > Actually, you missed the point. Me being the maintainer now was implied, > since my mail to proxy-maint@gentoo.org made it plenty obvious. > > But frankly, I just got over it. I’m greeted by nothing but dickishness, > stupid bickering and general craziness in here. > Empathic skills: Below measurable levels. (With the exception of Samuli > Suominen.) > > Hence, I have no interest in further interaction with all the troglodytes in > this cave. > > I will now maintain my own overlay, to work around your mess, until project > OzonS is finished. :O
gone
