On Thu 20 Dec 2018 at 20:28:08 +0100, Bernhard Übelacker wrote: > Hello Brian Potkin, > > > Does the efficient and correct operation of a program depend on whether > > the system is amd64 or i386? Most of my machines are i386 only and, to > > my knowledge, Debian has not abandoned this architecture. > > > > I was probably incorrect in thinking I had tested the offending directive > > previously. I have now tested with Debian 9.3 on i386. The same thing > > happens. > > > > When I summon up the energy I'll see what happens on an am64 OS. > > No, you don't need to.
Yes, I do; it is imperative. I dislike not knowing what the outcome of a certain technique or process is, whether or not I can dissect its innards. Computers are predictable machines or they are not. > > The problem is just if the reporter has not all debug symbols installed > I need to know the exact package version and architecture to get > something out of a backtrace. And as coredumpctl wrote > 0x00000000b747e1d7 instead of 0xb747e1d7 I just assumed it to be amd64. You got exactly what I was shown. > So that bit of information was just missing, and the program reportbug > would have had added it to the bug report in the first place. Do you really think reportbug would have added an imortant clue? It was clear that my original report was based on an unstable installation. > There is nothing wrong with i386. That is what I thought. But, anyway..... 1. The mini.iso for amd64 was downloaded and a sid installation put on the machine. Base system only. 2. Rebooted; then 'apt install cups-browsed'. 3. Uncommented "BrowseFilter pdf postscript" and restarted cups-browsed. 4. The outcome was as described in the first post in this report. It is not exactly the bug of the year, but, as far as I am concerned, there is a misbehaviour here. I know it is present, so can choose to not use the option. Regards, Brian.
