Bug 17217 - rpm filetrigger scripts are run outside of the chroot
Summary: rpm filetrigger scripts are run outside of the chroot
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard: 6dev1
Keywords:
: 17236 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-24 23:28 CET by Bit Twister
Modified: 2016-03-20 23:49 CET (History)
9 users (show)

See Also:
Source RPM: urpmi, rpm
CVE:
Status comment:


Attachments
report.bug.xz (350.91 KB, application/x-xz)
2015-11-25 18:03 CET, Bit Twister
Details
drakinstaller report (187.24 KB, application/x-xz)
2015-12-19 13:52 CET, xboxboy
Details

Description Bit Twister 2015-11-24 23:28:27 CET
Description of problem:

Ran a network install, picked all package groups and after package installs had a pop up with numerous "ERROR:'script' failed for" messages without rpm name 

Two did show up, systemd_227-2.mga6 and pm-fallback-policy-0.1-14.mga5 remaining 100+ failures did not

Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. pull all-nonfree.rdz, all.rdz, vmlinuz  from
http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/isolinux/x86_64/
2. create network stanza in /boot/grub/menu.lst with something like
title Network_install
kernel (hd0,7)/vmlinuz root=/dev/ram3 ramdisk_size=32000 noresume  vga=791
initrd (hd0,7)/all--nonfree.rdz

3. re-boot pick Network_install

4. During package selection phase. pick all package groups.


I would suggest the package installer create a log in /root/


Reproducible: 

Steps to Reproduce:
Comment 1 Marja Van Waes 2015-11-25 13:02:52 CET
If you still have a report.bug.xz from when it went wrong, then please attach it.

Or would you have time to reproduce the problem, and get the needed report.bug?

https://wiki.mageia.org/en/Triage_guide#Traditional_installer

CC: (none) => marja11, thierry.vignaud
Keywords: (none) => NEEDINFO

Comment 2 David Walser 2015-11-25 14:12:34 CET
Probably these ones:
https://ml.mageia.org/l/arc/dev/2015-11/msg00360.html

During the Mageia 5 development cycle, these errors would show the wrong package name, and now I guess they aren't showing a name at all.
Comment 3 Bit Twister 2015-11-25 18:03:44 CET
Created attachment 7236 [details]
report.bug.xz
Comment 4 Bit Twister 2015-11-25 18:05:13 CET
attached  report.bug.xz

Keywords: NEEDINFO => (none)

Comment 5 Bit Twister 2015-11-26 00:40:23 CET
Looking through report.bug it might be better to use gdisk instead of fdisk.
That way you can see the code/flags. gdisk snippet follows:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        83888127   40.0 GiB    0700  mga5
   2        83888128       171864063   42.0 GiB    0700  mga4
   3       171864064       257384447   40.8 GiB    0700  mga5
   4       257384448       342192127   40.4 GiB    0700  cauldron
   5       342192128       387309567   21.5 GiB    0700  local
   6       387309568       434296831   22.4 GiB    0700  accounts
   7       434296832       558874623   59.4 GiB    0700  misc
   8       558874624       712286207   73.2 GiB    0700  spare
   9       712286208      1471924223   362.2 GiB   0700  vmguest

fdisk snippet
Device         Start        End   Sectors   Size Type
/dev/sda1       2048   83888127  83886080    40G Microsoft basic data
/dev/sda2   83888128  171864063  87975936    42G Microsoft basic data
/dev/sda3  171864064  257384447  85520384  40.8G Microsoft basic data
/dev/sda4  257384448  342192127  84807680  40.5G Microsoft basic data
/dev/sda5  342192128  387309567  45117440  21.5G Microsoft basic data
/dev/sda6  387309568  434296831  46987264  22.4G Microsoft basic data
/dev/sda7  434296832  558874623 124577792  59.4G Microsoft basic data
/dev/sda8  558874624  712286207 153411584  73.2G Microsoft basic data
/dev/sda9  712286208 1471924223 759638016 362.2G Microsoft basic data
Comment 6 Martin Whitaker 2015-12-05 23:36:47 CET
Same issue seen here using boot-nonfree.iso installing from local disk. Although I ended up with a bootable system, I couldn't log into my selected DE (Cinnamon) until I forcibly reinstalled one of packages that failed to install.

(In reply to Bit Twister from comment #0)
> I would suggest the package installer create a log in /root/

See /root/drakx/install.log

(In reply to David Walser from comment #2)
> Probably these ones:
> https://ml.mageia.org/l/arc/dev/2015-11/msg00360.html

Looks like it:

# grep failed /root/drakx/install.log | wc -l
108
# grep failed /root/drakx/install.log | sort -u
%post(pm-fallback-policy-0.1-14.mga5.noarch) scriptlet failed, exit status 1
%triggerin(desktop-common-data-1:3.10-2.mga6.noarch) scriptlet failed, exit status 127
%triggerin(desktop-file-utils-0.22-9.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(fontconfig-2.11.94-1.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(GConf2-3.2.6-13.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(glib2.0-common-2.47.3-1.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(shared-mime-info-1.5-1.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(systemd-227-2.mga6.x86_64) scriptlet failed, exit status 1
%triggerin(systemd-227-2.mga6.x86_64) scriptlet failed, exit status 127

CC: (none) => mageia

Comment 7 papoteur 2015-12-06 13:23:29 CET
Hello,
I have similar errors with an already installed cauldron, when trying to install some packages or updating.
The installation didn't end. I need ^C.

# LANGUAGE=C urpmi --auto-update --auto-select
medium "Core Release" is up-to-date
medium "Core Updates" is up-to-date
medium "Nonfree Release" is up-to-date
medium "Nonfree Updates" is up-to-date
medium "core_src" is up-to-date
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release")
  abiword                        3.0.1        6.mga6        x86_64  
  acpid                          2.0.25       2.mga6        x86_64  
  cpupower                       4.3.0        5.mga6        x86_64  
 [...]
  virtualbox-guest-additions     5.0.10       5.mga6        x86_64  
  wayland-protocols-devel        1.0          1.mga6        noarch  
  x11-driver-input-wacom         0.32.0       1.mga6        x86_64  
  x11-driver-video-vboxvideo     5.0.10       5.mga6        x86_64  
106MB of additional disk space will be used.
204MB of packages will be retrieved.
Proceed with the installation of the 181 packages? (Y/n) y


    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64glib2.0-devel-2.47.3-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libgcc1-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64glib2.0_0-2.47.3-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64krb53-1.14-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64cups2-2.1.1-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/krb5-1.14-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-cpp-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/lib64gio2.0_0-2.47.3-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libstdc++-devel-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/gcc-c++-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/libstdc++6-5.3.0-2.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/glib2.0-common-2.47.3-1.mga6.x86_64.rpm
    http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list: media/core/release/glib-gettextize-2.47.3-1.mga6.x86_64.rpm
installing glib2.0-common-2.47.3-1.mga6.x86_64.rpm libstdc++6-5.3.0-2.mga6.x86_64.rpm gcc-c++-5.3.0-2.mga6.x86_64.rpm glib-gettextize-2.47.3-1.mga6.x86_64.rpm libstdc++-devel-5.3.0-2.mga6.x86_64.rpm lib64gio2.0_0-2.47.3-1.mga6.x86_64.rpm krb5-1.14-1.mga6.x86_64.rpm gcc-5.3.0-2.mga6.x86_64.rpm lib64cups2-2.1.1-1.mga6.x86_64.rpm gcc-cpp-5.3.0-2.mga6.x86_64.rpm lib64glib2.0_0-2.47.3-1.mga6.x86_64.rpm lib64glib2.0-devel-2.47.3-1.mga6.x86_64.rpm libgcc1-5.3.0-2.mga6.x86_64.rpm lib64krb53-1.14-1.mga6.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #####################################
    1/181: lib64glib2.0_0        #####################################
    2/181: lib64gio2.0_0         #####################################
    3/181: glib2.0-common        #####################################
    4/181: gcc-cpp               #####################################
    5/181: krb5                  #####################################
    6/181: lib64krb53            #####################################
    7/181: glib-gettextize       #####################################
    8/181: libgcc1               #####################################
    9/181: libstdc++6            #####################################
   10/181: libstdc++-devel       #####################################
   11/181: gcc                   #####################################
   12/181: gcc-c++               #####################################
   13/181: lib64cups2            #####################################
   14/181: lib64glib2.0-devel    #####################################
     1/14: removing lib64glib2.0-devel-2.47.1-1.mga6.x86_64
                                 #####################################
     2/14: removing lib64cups2-2.1.0-3.mga6.x86_64
                                 #####################################
     3/14: removing gcc-c++-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
     4/14: removing gcc-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
     5/14: removing glib2.0-common-2.47.1-1.mga6.x86_64
                                 #####################################
     6/14: removing libstdc++-devel-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
     7/14: removing libgcc1-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
     8/14: removing libstdc++6-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
     9/14: removing glib-gettextize-2.47.1-1.mga6.x86_64
                                 #####################################
    10/14: removing lib64gio2.0_0-2.47.1-1.mga6.x86_64
                                 #####################################
    11/14: removing lib64krb53-1.12.2-12.mga6.x86_64
                                 #####################################
    12/14: removing krb5-1.12.2-12.mga6.x86_64
                                 #####################################
    13/14: removing lib64glib2.0_0-2.47.1-1.mga6.x86_64
                                 #####################################
    14/14: removing gcc-cpp-5.2.1-0.20151110.1.mga6.x86_64
                                 #####################################
^Cwarning: %triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, signal 2
ERROR: 'script' failed for

CC: (none) => yves.brungard_mageia

Comment 8 Samuel Verschelde 2015-12-07 12:49:19 CET
As far as I understand the individual script errors have to be fixed individually in the appropriate packages. 

Keeping this bug report for the fact that the installer wouldn't give the package names, though.

Assignee: bugsquad => thierry.vignaud

Comment 9 Olav Vitters 2015-12-07 23:09:26 CET
From http://www.rpm.org/wiki/FileTriggers:
> Triggers with priority greater than 100000 will be executed before standard
> scriptlets and the other triggers will be executed after standard scriptlets.
> If you don't specify priority, the default priority is 1000000.

I'm wondering if this documentation is correct or not. Once it talks about 100.000, another time about 1.000.000. Maybe the ldconfig glibc trigger should be priority 2.000.000?

CC: (none) => olav

psyca 2015-12-07 23:22:00 CET

CC: (none) => linux

Comment 10 Bit Twister 2015-12-07 23:28:20 CET
(In reply to Samuel VERSCHELDE from comment #8)
> As far as I understand the individual script errors have to be fixed
> individually in the appropriate packages. 

Yes. and while there the dev/packager might consider a
    systemctl stop ...
    systemctl start ...
instead of a systemctl start in the event the service is already running.
That would prevent a incorrect/invalid/false trigger event.

Better yet, maybe a macro that checks if active, then stop/start.
That way install package will not start services which the system admin has stopped.


> Keeping this bug report for the fact that the installer wouldn't give the
> package names, though.

  Thank you.  :)
Florian Hubold 2015-12-10 10:30:09 CET

CC: (none) => doktor5000

Comment 11 Olav Vitters 2015-12-15 18:07:17 CET
*** Bug 17236 has been marked as a duplicate of this bug. ***

CC: (none) => tarazed25

Comment 12 Thierry Vignaud 2015-12-16 15:50:43 CET
(In reply to Olav Vitters from comment #9)
> I'm wondering if this documentation is correct or not. Once it talks about
> 100.000, another time about 1.000.000. Maybe the ldconfig glibc trigger
> should be priority 2.000.000?

Well, that doesn't matter: ldconfig would still be run once per transaction so eg mandb wouldn't fail on every transaction

Anyways, this can be tested with "urpmi --root T --debug-librpm"
Comment 13 Olav Vitters 2015-12-16 16:08:39 CET
How to debug these commands from the Live USB? E.g. if I choose "install" option from the live USB, how do I get it to log the installation of packages and which triggers it is execution + timestamps?

I now have an empty slow HDD so I could now try getting a log of this.
Comment 14 xboxboy 2015-12-19 13:52:35 CET
Created attachment 7289 [details]
drakinstaller report
Comment 15 xboxboy 2015-12-19 13:56:06 CET
see above attachment 7289 [details]

I used the cauldron boot.iso. It took 3 attempts, I suspect the first two failed attempts were mirror issues.

I had the same behaviour, many, many failed scripts, only a few of which had a name, most were blank.

I was able to log in to x, but the desktop was sparse, and I could not open/start any program.

Switching to tty2, I could use rpm and urpmi and mcc.

rpm -VA showed pages of package issues.
I removed and installed drakconf, but I could only start it in text, never in x.
Olav Vitters 2015-12-21 12:09:02 CET

Attachment 7289 mime type: text/plain => application/x-xz

Comment 16 Olav Vitters 2015-12-21 12:12:34 CET
From that attachment:

/var/tmp/rpm-tmp.RQ0qEh: 1: /var/tmp/rpm-tmp.RQ0qEh: fc-cache: not found
%triggerin(fontconfig-2.11.94-1.mga6.x86_64) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.IHDfbK: 1: /var/tmp/rpm-tmp.IHDfbK: /usr/bin/gio-querymodules-64: not found
%triggerin(glib2.0-common-2.47.4-1.mga6.x86_64) scriptlet failed, exit status 127
%triggerin(desktop-file-utils-0.22-9.mga6.x86_64) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.P1cnXc: 1: /var/tmp/rpm-tmp.P1cnXc: update-menus: not found
%triggerin(desktop-common-data-1:3.10-2.mga6.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.VgqUqW: 1: /var/tmp/rpm-tmp.VgqUqW: /usr/bin/mandb: not found
%triggerin(man-db-2.7.5-1.mga6.x86_64) scriptlet failed, exit status 127
Comment 17 Olav Vitters 2015-12-21 12:14:06 CET
Maybe it doesn't run these from the chroot?
Comment 18 Thierry Vignaud 2015-12-21 15:17:33 CET
Please try with glibc-2.22-13.mga6
Comment 19 Frank Griffin 2015-12-21 20:47:45 CET
(In reply to Thierry Vignaud from comment #18)
> Please try with glibc-2.22-13.mga6

Unfortunately not.  I just tried a fresh install with all package categories selected and got the usual full screen of ERRORs with no package names, followed by a screen saying that 198 transactions failed install for various reasons, mostly conflicts.The install would not complete, but dropped me back to repository selection. 

I have the files from /root/drakx (install.log, ddebug.log) if needed.

CC: (none) => ftg

Comment 20 Olav Vitters 2015-12-21 21:23:53 CET
Thierry: I think my earlier guess about ldconfig was wrong (or maybe there's two problems?)

There are two filetriggers in glib2.0-common:

# automatic gschema compilation on rpm installs/removals
%transfiletriggerin -n %{name}-common --  %_datadir/glib-2.0/schemas/
if [ -x /usr/bin/glib-compile-schemas ]; then
    /usr/bin/glib-compile-schemas --allow-any-name %_datadir/glib-2.0/schemas/
fi

# automatic update of gio module cache
%transfiletriggerin -n %{name}-common --  %{_libdir}/gio/modules/
%{_bindir}/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules


In the report.bug log there are various "command not found" errors, e.g.:
/var/tmp/rpm-tmp.dZUQPH: 1: /var/tmp/rpm-tmp.dZUQPH: /usr/bin/gio-querymodules-64: not found

However, there are no errors _at all_ regarding /usr/bin/glib-compile-schemas. The report.bug also mentions the installer calls ldconfig a few times.

As the glib2.0-common checks for the program before executing and there are no errors that it couldn't execute, that's why I think it is not running it from the chroot. The paths are basically wrong.

Severity: major => enhancement

Comment 21 Bit Twister 2015-12-22 13:25:42 CET
(In reply to Thierry Vignaud from comment #18)
> Please try with glibc-2.22-13.mga6

Used Dec 22 01:56 boot.iso clean VirtualBox install. Problem still there.
Comment 22 psyca 2015-12-22 22:26:58 CET
When i run the installer i get the following message before the gui installer runs (typed from VirtualBox) :

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/%{ <-- HERE ARCH}/ at /usr/lib/libDrakX/install/media.pm line 83.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 257.
Comment 23 psyca 2015-12-22 22:41:56 CET
Forgot one line:

Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.22.0/Gtk3.pm line 525.
Comment 24 Frank Griffin 2015-12-22 23:23:28 CET
(In reply to psyca from comment #22)
> When i run the installer i get the following message before the gui
> installer runs (typed from VirtualBox) :
> 
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/%{ <-- HERE ARCH}/ at /usr/lib/libDrakX/install/media.pm
> line 83.
> Ignore the following Glib::Object::Introspection & Gtk3 warnings
> Too late to run INIT block at
> /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi/Glib/Object/
> Introspection.pm line 257.

Old stuff, never fixed from some perl upgrade from years back.
Rémi Verschelde 2016-01-05 22:05:57 CET

Whiteboard: (none) => 6dev1

Comment 25 Thierry Vignaud 2016-01-06 12:26:28 CET
Dispite what I understand when looking at rpmlib code, sadly, the current filetriggers doesn't honour rpm's chroot.
Thus it works fine with urpmi for online updates.

But not with the drakx installer which installs packages in a chroot or with urpmi when using a chroot.

Example: we've a ldconfig file trigger in glibc package:

$ rpm -q --filetriggers glibc
transfiletriggerin scriptlet (using /bin/sh) -- /lib/, /lib64/
grep -F '.so.' | ldconfig -X
transfiletriggerin scriptlet (using /bin/sh) -- /etc/ld.so.conf.d/
ldconfig -X


Let's test in a chroot with and without /sbin/ldconfig out of the chroot:
mkdir TL2
mv /sbin/ldconfig{,.tv}; urpmi --no-recommends --root TL2 basesystem-minimal 2>&1|tee LOG.chroot2
mkdir TL1
mv /sbin/ldconfig{.tv,}; urpmi --no-recommends --root TL1 basesystem-minimal 2>&1|tee LOG.chroot1
diff -u LOG.chroot?|grep -1 ldconfig >ldconf.diff

Source RPM: (none) => rpm
Status: NEW => ASSIGNED

Comment 26 Thierry Vignaud 2016-01-09 02:58:49 CET
Fixed in rpm-4.13.0-0.rc1.16.mga6 (& then in drakx-installer-stage2-17.13-2.mga6 which is rebuild with fixed rpm)

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

Comment 27 Bit Twister 2016-02-03 04:29:24 CET
clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files.

Still had a blank script names,

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

Thierry Vignaud 2016-03-18 13:30:59 CET

Summary: numerous ERROR: 'script' failed for messages without rpm name => urpmi doesn't identify trigger errors (numerous ERROR: 'script' failed for messages without rpm name)
Source RPM: rpm => urpmi, rpm

Comment 28 Olav Vitters 2016-03-20 16:58:56 CET
(In reply to Bit Twister from comment #27)
> clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files.
> 
> Still had a blank script names,

Please provide proper details. This isn't good enough. You're reopening a bugreport that seemingly had nothing to do with you issue. This bugreport was about scripts not being started in a chroot. It was verified to be fixed. If there is some other issue, then file a _new_ bugreport with _clear_ details so something can actually be done!

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED
Summary: urpmi doesn't identify trigger errors (numerous ERROR: 'script' failed for messages without rpm name) => rpm filetrigger scripts are run outside of the chroot

Comment 29 Bit Twister 2016-03-20 23:30:19 CET
(In reply to Olav Vitters from comment #28)
> (In reply to Bit Twister from comment #27)
> > clean network install using 01-Feb-2016 21:58 vmlinuz, all.rdz files.
> > 
> > Still had a blank script names,
> 
> Please provide proper details.

I am sorry that you seem to have your panties in a twist. Might I suggest trying a clean pair.

I have provided all the required "proper details"

> This isn't good enough.

Well, that would be _your_ _issue_ and not my _problem_.

> You're reopening a bugreport that seemingly had nothing to do with you issue.

I disagree. My _problem_ was stated in the original Summary: and in the Description section.

> This bugreport was about scripts not being started in a chroot.

I disagree. The investigation of my problem has indicated several scripts create failure messages which need to be resolved plus the problem you have indicated has been resolved. 

> It was verified to be fixed.

Well, obviously that is not true at the time I reopened the bug report. 
I followed the same test procedure and had the same _problem_.

> If there is some other issue, then file a _new_ bugreport with
> _clear_ details so something can actually be done!

Frap. Seems I can not please anyone at any time. I have people jumping on my ass about not using the bug reporting system to if full advantage, too much detail in steps to reproduce, you bitching I am not providing enough information,.... and I know for a fact I would get chewed out again for opening the same exact _problem_ report if I can reproduce the problem.

Trust me. I started out as a Hardware Engineer's Aide building hardware from from schematics, debugging their design mistakes. Next job was designing interface hardware to test cards from production lines and write software to tell the repair tech which ic was bad on the card or what area they had to look at. Moved on to Software Quality assurance. Got tired manually running test plans, wrote an interpret to automatically test the software. After that worked my way up through software coder, designer, system designer, system analyst.
Rest of the time I was help desk and maintenance programmer for several mission critical applications in the IT department.

I can tell you for a fact. YOU should have opened a bug report about the chroot problem and not high jack _my_ _problem_ report and marked it Resolved.

Your remark about "Please provide proper details. This isn't good enough." would seem to indicate you have an _issue_ with Thierry Vignaud.

Being the methodical dev I believe Thierry to be, I assumed the proper procedure was followed by proving the _problem_ was producible, corrected the problem, tested it, checked in the changes, reran the install procedure and verified my _problem_ was indeed fixed, then marked my _problem_ resolved.

Since I received the resolved notice, I then followed the same test procedure again and it failed with the same _problem_. The same screen with the title
"ERROR:'script' failed for" was still blank for numerous errors.

I suggest you take _your_ lack of _information_ _issue_ up with Thierry.
If Thierry decided "ERROR:'script' failed for" was good enough title for the screen name then you need to talk to Thierry. 

Or better yet, get together with development team leaders and suggest some rule that all screens should have descriptive titles, preferably containing application name[-module name] which would a great help who, what, where for everyone involved in reporting, triage, repair, test process.

Think about it, less than 2 minutes of dev time to add app[-module] to screens or report output and same test time to check it when dev is testing whatever bugreport is being squashed.

Big win for everyone.
Comment 30 Olav Vitters 2016-03-20 23:49:12 CET
I didn't highjack this bugreport. I provided analysis for why these script errors occurred and tv wrote a brilliant patch. Thierry marked it as fixed.

You did _NOT_ speak up at all during all the analysis, nor when the bugreport was marked as fixed.

You seem entitled to think you know what I think about Thierry. He's awesome, sometimes we have misunderstandings. In this bugreport he fixed the chroot problem I thought occurred. As explained in the comment I wrote to you.

Reread comment 25. There was a problem that the filetriggers running outside of the chroot. That is what work was done in this bugreport and the reason that _Thierry_closed_it_.

Instead of complaining and driving wedges, maybe look at your reading skills? At the moment it seems Thierry and me are paid by you? You write a bugreport; ignore everything and then when it is fixed ignore everything that happened and what people said. If that leads to a miscommunication, obviously go out in full force and blame everyone except yourself.

Yeah, originally you wanted something else and some other problem was fixed. Keep this open will make it confusing what it is about.

In case you wonder: If I reply to you I don't have a problem with either you, nor with unrelated people. E.g. I don't have a problem with Linus Torvalds.

Again, Thierry clearly mentioned everything.

Note You need to log in before you can comment on or make changes to this bug.