https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/app-editors%3Acurses-hexedit-0.9.7%3A20141111-065258.html Portage 2.2.14_rc1 (python 2.7.8-final-0, default/linux/amd64/13.0, gcc-4.9.1-asneeded, glibc-2.20, 3.15.5-hardened-r2 x86_64) ================================================================= System uname: Linux-3.15.5-hardened-r2-x86_64-AMD_Opteron-TM-_Processor_6272-with-gentoo-2.2 KiB Mem: 65962672 total, 16391156 free KiB Swap: 0 total, 0 free Timestamp of tree: Unknown ld ld di GNU (Gentoo 2.24 p1.4) 2.24 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.9 [disabled] app-shells/bash: 4.2_p53 dev-java/java-config: 2.2.0 dev-lang/perl: 5.18.2-r2 dev-lang/python: 2.7.8, 3.2.5-r6, 3.3.5-r1, 3.4.1 dev-util/ccache: 3.1.9 dev-util/cmake: 2.8.12.2-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.4_p6-r1, 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6, 1.13.2, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.6.4, 4.7.4, 4.8.3, 4.9.1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.1 sys-kernel/linux-headers: 3.17 (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 -ggdb -march=native -ftracer -frecord-gcc-switches" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/entropy /opt/openjms/config /usr/share/bufrtables /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf /usr/share/themes/oxygen-gtk/gtk-2.0 /var/bind /var/lib/hsqldb /var/lib/neatx/home /var/spool/torque /var/yp/Makefile" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/games/angband/edit/ /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -ggdb -march=native -ftracer -frecord-gcc-switches" DISTDIR="/var/cache/portage/distfiles" FCFLAGS="-O2 -pipe -ggdb -march=native -frecord-gcc-switches" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fail-clean fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict test test-fail-continue unknown-features-warn unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe -ggdb -march=native -frecord-gcc-switches" GENTOO_MIRRORS="http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.mirrors.hoobly.com/ http://gentoo.llarian.net/" LANG="en_US.utf8" LC_ALL="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j24" 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="/tmp" PORTDIR="/var/cache/tinderbox/tree" PORTDIR_OVERLAY="" SYNC="rsync://excelsior.flameeyes.eu/gentoo-portage" USE="3dnow 3dnowex acl amd64 berkdb blas bzip2 cli cracklib crypt cxx doc dri emacs ffmpeg fortran freetype iconv icu intl introspection ipv6 lapack mmx modules multilib ncurses nls nptl openmp pam pax_kernel pcre pdf plasma qt3support readline semantic-desktop session snmp sse sse2 sse3 sse4 ssl ssse3 tcmalloc tcpd truetype udev unicode vhosts xft 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" 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" 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, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
stop wasting time with your junk bugs
Created attachment 389824 [details] build.log Hi, I copy/pasted this into a text file for you.
(In reply to Michael Orlitzky from comment #2) thanks, but we shouldn't be wasting developer time with something that is trivial to automate
(In reply to SpanKY from comment #3) > (In reply to Michael Orlitzky from comment #2) > > thanks, but we shouldn't be wasting developer time with something that is > trivial to automate If it is trivial, please go ahead and contribute the little code it needs to solve the whole situation. Thanks.
Also, AxS is running a script with a cron to attach this files automatically, then, I would also wait a bit more to let the script to catch up them
Mike, also, please take care this is a volunteers work. Personally I have never seen so much problem of Flameeyes providing the logs the way he does as soon as they are available (if at some point they become unavailable (that doesn't look to occur anytime soon), I would understand to close the bugs as NEEDINFO, but that is not the case now. The logs are accessible and, then, the info is indeed provided. But, even with that in mind, Ian did the job of making a script he runs with a cron to attach the files automatically a bit after the are sent by flameeyes (not sure if he has had any problem running it or the cron is a bit longer... will try to contact him to see if he needs help for running it as I could help because my laptop is mostly up all the time). What I am trying to tell you is that we are all volunteers and we need to try to collaborate a bit between us to share efforts and try to take advantage of the kind of contributions we are able to do. For example, I doubt I could help much due to my technical knowledge with base-system/toolchain packages, on the other hand, I could probably help you to handle this kind of "bugzilla" issues (even manually), for that, you can send me a mail to let me know some bugs need "tuning" and that way I can review them and make them more friendly... :/ Thanks
(In reply to Pacho Ramos from comment #6) > for that, you can > send me a mail to let me know some bugs need "tuning" and that way I can > review them and make them more friendly... :/ > -> other (probably easier option), I can list myself in the metadatas of your maintained packages for this kind of task, that way I would being CCed and would be notifies about this much faster. @vapier, are you ok with this approach? (I would do it for the packages you are the only maintainer as, for base-system/toolchain and other teams I guess other people on them will be able to handle this kind of issues)
(In reply to SpanKY from comment #1) > stop wasting time with your junk bugs If you don't collaborate, please remove yourself as maintainer and stop wasting our time.
(In reply to Justin Lecher from comment #4) as Diego is well aware, there is already code to do this that people have already written (In reply to Pacho Ramos from comment #6) i already explained in the past that missing historical logs is a problem and relying on infra not hosted by Gentoo doesn't fly. i've had to splunk things in the past to do research on new problems and having those missing is a problem. (In reply to Pacho Ramos from comment #7) there's no point in wasting your time to do what scripts can do properly in the first place (In reply to Julian Ospald (hasufell) from comment #8) take your stupid trolling elsewhere
(In reply to SpanKY from comment #9) I think almost any developer would have been kicked, banned or suspended by comrel multiple times if he behaved like you (ignoring QA, methods and regularly ignoring other developers). Sadly, you have your buddies everywhere. "Trolling" doesn't even describe what you do, so I won't give this compliment back to you.
(In reply to Julian Ospald (hasufell) from comment #10) your comments are meaningless to the issue at hand, and obviously meant to be purely specious. so yes, that is trolling.
(In reply to SpanKY from comment #9) [...] > (In reply to Pacho Ramos from comment #7) > > there's no point in wasting your time to do what scripts can do properly in > the first place [...] My aim is to try to handle this in a way it doesn't end up with some people wanting to attach and kick one party and the opposite. As looks like it's not possible to either get the logs directly attached from the first time neither the logs from amazonws being accepted, I think it's worth to try to lose a bit of my time to try to reach an intermediate situation that helps all the team to keep the best from all parties that clearly benefits the whole project :) Then, there is no need to worry about my time as I am willing to invest it for this if needed ;)
(In reply to Pacho Ramos from comment #12) your skills are better spent solving real bugs. Ian has written a script to do it apparently so you're already obsolete ;). there's no need for the attachment to be in the initial submission ... simply doing it automatically after creating the bug is fine. but that's not happening and Diego for some reason is refusing to do that. this is already easy to do with pybugz. "i don't know python" is a red herring when the command line interface is fully functional. if you know shell, you can use pybugz.
(In reply to SpanKY from comment #11) > (In reply to Julian Ospald (hasufell) from comment #10) > > your comments are meaningless to the issue at hand, and obviously meant to > be purely specious. so yes, that is trolling. well it seems SpanKY knows best. That it is trolling is your assessment, and who are we to argue?? After all, see sentence 1. P Ramos is bending over backwards to effect a better outcome for all. And your reply (In reply to SpanKY from comment #13) > (In reply to Pacho Ramos from comment #12) > > your skills are better spent solving real bugs. Ian has written a script to > do it apparently so you're already obsolete ;). > An insensitive and unashamed put down. What happened to thanks Pachos, perhaps we could ..... however considering ...... but then..... Nah. Let's just, see sentence 1. Have you ever even heard of the term conciliation, or conciliatory tones? I thought not. but then <but that's not happening and Diego for some reason is refusing to do that.> so you greet intransigence with, a grenade. (What else). Perhaps fight fire with fire? Trying to trump Diego's shortcomings with your own is, well, intransigent. Does neither of you any favours here... To attempt to be comprehensive, the remainder of that final paragraph floats pertinent and relevant point to the topic at hand. Oh, do I anticipate an "idella4 spare us your trolling"? Alternately, a variation of the theme.... This brand of hard line lecturing I assure you all disheartens, disappoints and drives away keen users who are 'would have been' potential devs of the gentoo community. again
Before I reply with a simple four letter words let me restate one thing and than that will be it, and my next move unless council/devrel stops this for good my time will be spent better: playing Baldur's Gate. The problem is not that I don't know python. Because I do know python (now). The problem is that pybugz DOES NOT SOLVE A FREAKING THING. I scan between 100 to 500 logs a day, any second it takes me to open a new bug adds to the likeliness I have no time to do so. Right now the filing is done purely through the browser so my Bugzilla authentication never leaves it. I get the failed log, I click on the "open bug" button, it prefills it, I leave a proper summary to point out what the problem is and block the proper bug. If the app were to just open the bug for me, the app would have to have the credentials, which means I have to have the app behind authentication. And as I pointed out multiple time I have no time or interest in supporting a properly authenticated app FOR ONE PERSON REFUSING TO READ A LOG. Because sure, it's not an impossible amount of work, but it's a disproportionate amount of work when only one person requires it, and another 200 are perfectly fine with clicking on a link to read a log. Same thing with pybugz as a CLI tool; sure I could have it store a copy of my credentials on my laptop and now copy-paste the bug ID after opening and the log URL. But no thanks because it makes opening a bug a >40 seconds operation and prone to more mistakes and, once again, this is disproportioned to ONE person refusing to accept a setup. So really, I'm tired to be insulted, and this was the last drop. Goodbye.
Why are we having a 16-comment flamewar over an issue that was COMPLETELY resolved in comment #2, and non-ideally resolved from the initial filing? This is a waste of everybody's time. Stop the bugspam. Council already agreed that bugs shouldn't be closed over this in the first place, and somebody already stepped up to automate attaching the bugs. Quit finding stuff to complain about. Of the now 16 comments in the bug plus the original report, exactly two have done anything constructive, which were the original report and the subsequent attachment that made this more useful for archival. Everything else (including this) amounts to hot air as far as actually fixing the problem goes.
(In reply to Richard Freeman from comment #16) > Why are we having a 16-comment flamewar over an issue that was COMPLETELY > resolved in comment #2, and non-ideally resolved from the initial filing? > > This is a waste of everybody's time. Stop the bugspam. Council already > agreed that bugs shouldn't be closed over this in the first place, and > somebody already stepped up to automate attaching the bugs. Quit finding > stuff to complain about. > > Of the now 16 comments in the bug plus the original report, exactly two have > done anything constructive, which were the original report and the > subsequent attachment that made this more useful for archival. Everything > else (including this) amounts to hot air as far as actually fixing the > problem goes. I strongly disagree. This is just another conflict with long history and known reasons. You are just trying to deescalate while hoping it will not happen again. No, it will. And from the limited time I am in gentoo, I've seen these kind of conflicts with the same people over and over again. Is it just coincidence or is there something that actually has to change?
--- a/configure.in +++ b/configure.in @@ -101,6 +101,8 @@ echo "Hexedit requires the curses library" echo "Ncurses is freely available: ftp://ftp.gnu.org/pub/gnu/" exit 1) - +AC_SEARCH_LIBS(stdscr, tinfo,, + echo "Cannot find a library providing stdsrc" + exit 1) AC_OUTPUT(Makefile docs/Makefile gnu/Makefile src/Makefile)
(In reply to Jeroen Roovers from comment #18) > --- a/configure.in > +++ b/configure.in > @@ -101,6 +101,8 @@ > echo "Hexedit requires the curses library" > echo "Ncurses is freely available: ftp://ftp.gnu.org/pub/gnu/" > exit 1) > - > +AC_SEARCH_LIBS(stdscr, tinfo,, > + echo "Cannot find a library providing stdsrc" > + exit 1) > > AC_OUTPUT(Makefile docs/Makefile gnu/Makefile src/Makefile) For the sake of bike-shedding, lets make that AC_SEARCH_LIBS(stdscr, tinfo,, AC_MSG_ERROR([Cannot find a library providing stdsrc]) )
Shouldn't that be "Cannot find a library providing stdscr" (mind the order of the last two letters!) as stdscr is the 1st argument to AC_SEARCH_LIBS on the line above? Or is it exactly the other way round, 1st argument needs to be changed?
So this one's obsolete for now.
