Bug 16567

Summary: mercurial-server rpm install writes to stdout/stderr
Product: Mageia Reporter: Frank Griffin <ftg>
Component: RPM PackagesAssignee: Philippe Makowski <makowski.mageia>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Normal CC: jani.valimaa, marja11
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: mercurial-server CVE:
Status comment:

Description Frank Griffin 2015-08-10 22:24:30 CEST
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:
Marja Van Waes 2015-08-24 20:35:07 CEST

CC: (none) => marja11
Assignee: bugsquad => makowski.mageia
Summary: rpm install writes to stdout/stderr => mercurial-server rpm install writes to stdout/stderr

Comment 1 Jani Välimaa 2015-08-30 17:45:24 CEST
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

Comment 2 Frank Griffin 2015-08-30 19:02:15 CEST
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 => RESOLVED
Resolution: (none) => INVALID

Comment 3 Frank Griffin 2015-09-01 01:08:25 CEST
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 => REOPENED
Resolution: INVALID => (none)

Comment 4 Philippe Makowski 2015-09-01 19:19:16 CEST
done in Cauldron, I don't think it need an update in mga5 , as it is a small cosmetic bug
Comment 5 Frank Griffin 2015-09-01 21:53:53 CEST
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.
Comment 6 Philippe Makowski 2015-09-03 20:26:14 CEST
d(In reply to Frank Griffin from comment #5)
> This appears not to be specific to mercurial.  
so open another bug

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED