In watching this package install via urpmi, I noticed that the hashtags used by urpmi as as progress indicator were interspersed with the characters of error messages from the install. Since almost every other package I've watched during installation doesn't do this, I assume that there is some MGA convention for using or not using stdout or stderr that this package is not observing. Reproducible: Steps to Reproduce:
CC: (none) => marja11Assignee: bugsquad => makowski.mageiaSummary: rpm install writes to stdout/stderr => mercurial-server rpm install writes to stdout/stderr
Which version of rpm are you using? 4.12.90 (which existed only a short time in core/release) or 4.12.0.1? If you are using the first mentioned, please disable core/updates_testing and downgrade rpm [1] to 4.12.0.1 and see if the issue still happens. [1] urpmi --downgrade rpm
CC: (none) => jani.valimaa
I'm a little confused. The current version in cauldron (just synced) is mercurial-server-1.3-11.mga5.noarch.rpm, and I don't have any of the testing repositories enabled. However, I removed the package on one machine and reinstalled it, and no extra characters appeared in the progress bar. So I thought perhaps it was mercurial and not mercurial-server, so I removed mercurial-3.4.2-2.mga6.x86_64 and installed the current cauldron mercurial-3.5-1.mga6.x86_64.rpm, and the error didn't appear there either. Closing as invalid.
Status: NEW => RESOLVEDResolution: (none) => INVALID
OK, round two.... Le 31/08/2015 01:19, David Walser a écrit : > philippe makowski wrote: >> Any one have a clue about this : >> https://bugs.mageia.org/show_bug.cgi?id=16567 >> >> thanks > > There is at least one other bug he filed like this. For another one I checked and there were no scriplets at all, so it was invalid. > > mercurial-server (bug 16567) has a postinstall script with a message to stdout rpm -qp --scripts mercurial-server-1.3-11.mga5.noarch.rpm ... postinstall scriptlet (using /bin/sh): # .mercurial-server needs to be in the hg user directory: [ ! -e ~hg/.mercurial-server ] && /usr/bin/su hg -s /bin/bash -c "install -m 600 /usr/share/mercurial-server/init/dot-mercurial-server ~hg/.mercurial-server [ -d /var/hg ] && [ ! -d /var/hg/repos ] && \ chown -R hg:hg /var/hg && \ /bin/su -s /bin/bash hg -c "/usr/share/mercurial-server/init/hginit /usr/share/mercurial-server" cat <<EOF ------------------------------------------------------------------------------- Place the SSH public key(s) of the user(s) who require access to the repository in the directory /etc/mercurial-server/keys/root and run /usr/share/mercurial-server/refresh-auth while logged in as the user hg. ------------------------------------------------------------------------------- EOF ... This message should be put either in a README in doc, or in a README.urpmi. https://wiki.mageia.org/en/Packagers_RPM_tutorial#Interaction_with_urpmi_and_rpmdrake regards, Luc -- Luc Menut
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
done in Cauldron, I don't think it need an update in mga5 , as it is a small cosmetic bug
This appears not to be specific to mercurial. I'll enter another bug report for this once I get more information, but here's the gist... I have a post-fresh-install script that (among other things) basically reinstalls all of the packages that were installed on a previous system, and the script runs with ">file 2>&1". It was in the course of running this that I got the error reported here. Since, at the lowest level, C libraries do stream I/O a byte at a time, it could be argued that this is to be expected if output is being written to stdout and stderr in tandem without doing a flush() after each line. However, if urpmi is internally catching stdout and stderr, this should happen well before the ">file 2>&1" comes into play. I mention this because on a just-performed run of this script had several instances of this error for other packages, e. g. 3/2397: php-channel-phpunit ####################################################################################################################################### PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your t im e z4o/n2e3.9 7i:n p/eurslr-/PsahtahrTeo/oplesa r / P E A R / Registry.php on line 1012 ####################################################################################################################################### Notice the corruption towards the bottom. In other cases it is more pronounced: 23/2397: php-pear-channel-symfony2 ####################################################################################################################################### PWHaPr nWianrgn:i ndga:t e (d)a:t eI(t) :i sI tn oits nosta fsea fteo troe lrye onl yt hoen styhset esmy'sst etmi'mse ztoinmee zsoentet isnegtst.i nYgosu. aYroeu *arreeq u*irreeqdu*i rteod *u steo tuhsee dtahtee .dtaitmee.ztoinmee zsoentet isnegt toirn gt hoer dtahte ed_atdee_dfeafauulltt__ttiimmeezzoonnee__sseett(()) ffuunnccttiioonn.. IInn ccaassee yyoouu uusseedd aannyy ooff tthhoossee mmeetthhooddss aanndd yyoouu aarree ssttiillll ggeettttiinngg tthhiiss wwaarrnniinngg,, yyoouu mmoosstt lliikkeellyy mmiissssppeelllleedd tthhee ttiimmeezzoonnee iiddeennttiiffiieerr.. WWee sseelleecctteedd tthhee ttiimmeezzoonnee ''UUTTCC'' ffoorr nnooww,, bbuutt pplleeaassee sseett ddaattee..ttiimmeezzoonnee ttoo sseelleecctt yyoouurr ttiimmeezzoonnee.. iinn /PuEsArR//sRheagries/tpreya.rp/hPpE AoRn/ Rleignies t1r0y1.2p hApd doinn gl iCnhea n1n0e1l2 "pear.symfony.com" succeeded So this could be a generic urpmi bug in how stdout/stderr are captured. Or, it could just be a result of urpmi doing byte-by-byte capture instead of caching data until a newline is seen, which of course it isn't required to do.
d(In reply to Frank Griffin from comment #5) > This appears not to be specific to mercurial. so open another bug
Status: REOPENED => RESOLVEDResolution: (none) => FIXED