Bug#999612: exim 4.94.5 installation configures IPv6 by default on IPv4 only machines
Package: exim4 Version: 4.94.5 Severity: grave On installation, Exim 4.94.5 will enable IPv6 *by default*, ignoring several mechanisms in place to explicitly disable IPv6: 1. A kernel command line explicitly disabling ipv6: [code] ipv6.disable=1 [/code] 2. An /etc/hosts file with no machine readable IPv6 lines: [code] user@chuck:~$ cat /etc/hosts # 127.0.0.1 localhost debian # # remmed to disable ip6 #::1 localhost ip6-localhost ip6-loopback #fe00::0 ip6-localnet #fe00::0 ip6-mcastprefix #fe02::1 ip6-allnodes #fe02::1 ip6-allrouters user@chuck:~$ [/code] 3. An /etc/ssh/ssh_config file explicitly disabling ipv6: [code] user@chuck:~$ cat /etc/ssh/ssh_config --- snip --- AddressFamily inet # instead of 'any' or 'inet6' --- snip --- user@chuck:~$ [/code] This in turn creates this paniclog message: [code] IPv6 socket creation failed: Address family not supported by protocol [/code] On a machine with a DNS server (Unbound) running on a VBox virtual machine which is also explicitly configured disable IPv6, there will also be a rather annoying 30s delay at boot time. This seems to be due to Exim talking directly to the DNS resolver which will not answer queries as the machine it runs on is not configured to use IPv6. After waiting for 30s, Exim will continue loading. This can be avoided by adding this line to the 'Main' section of exim4.conf.template: [code] disable_ipv6 = true [/code] Once update-exim4.conf is run and the machine reboots, the delay has gone away and there is no paniclog message. To reproduce the problem, rolling back the edit of the exim4.conf.template will bring back the 30s delay and the paniclog message. At the very least, add the disable_ipv6 = true (or false) to the exim4.conf.template file, with the proper comments so that the issue will not be hard to fix. I had to add the line, it was not there by default in any of its possible variants: ie: disable_ipv6 = true ; disable_ipv6 = false ; disable_ipv6 = The *best* solution would be to have the installer check for the existence of the ipv6.disable=1 stanza in the kernel command line and then ask for IPv6 confirmation if the line is not there. A very small portion of the web runs on IPv6 and it will be some years before IPv6 becomes the default option. Thanks in advance.
Bug#990344: Additional information
On 15 Jul 2021 at 8:40, Marc Haber wrote: > This has nothing to do with exim. If you intended to file a new > bug for the backintime package, please use the reportbug tool. Yes. It was a typo. I immediately sent notice to ow...@bugs.debian.org. --- Good afternoon: Please delete/disregard the last entry (Message #50) received at 990...@bugs.debian.org due to an rather unfortunate typo on my behalf. It obviously was intended to reach 990...@bugs.debian.org. --- Sorry for the inconvenience caused. Best,
Bug#990343: Additional information
Package: backintime
Version: 1.1.24-0.1
Severity: normal
I have received yet another notification in my system mail related
to an unhandled exception in a backintime Python script.
Here is the transcript:
---
Date: Wed, 14 Jul 2021 16:45:01 -0300
Unhandled exception in thread started by
Traceback (most recent call last):
File "/usr/share/backintime/common/tools.py", line 1458, in
__log_keyring_warning
TypeError: 'NoneType' object is not callable
---
As you will gather from the transcript, it is the same problem (line
1458) in file "/usr/share/backintime/common/tools.py".
FYI, here are the last 12 lines from the file file metioned above:
[code]
1456
1457 def __log_keyring_warning():
1458 from time import sleep
1459 sleep(0.1)
1460 logger.warning('import keyring failed')
1461
1462 if keyring is None and keyring_warn:
1463 #delay warning to give logger some time to import
1464 import _thread
1465 _thread.start_new_thread(__log_keyring_warning, ())
1466 # logger.warning('import keyring failed')
1467
[/code]
Thanks in advance,
sawbona
Bug#990344: Additional information
Package: backintime
Version: 1.1.24-0.1
Severity: normal
I have received yet another notification in my system mail related to
an unhandled exception in a backintime Python script.
Here is the transcript:
---
Date: Wed, 14 Jul 2021 16:45:01 -0300
Unhandled exception in thread started by
Traceback (most recent call last):
File "/usr/share/backintime/common/tools.py", line 1458, in
__log_keyring_warning
TypeError: 'NoneType' object is not callable
---
As you will gather from the transcript, it is the same problem (line
1458) in file "/usr/share/backintime/common/tools.py".
FYI, here are the last 12 lines from the file file metioned above:
[code]
1456
1457 def __log_keyring_warning():
1458 from time import sleep
1459 sleep(0.1)
1460 logger.warning('import keyring failed')
1461
1462 if keyring is None and keyring_warn:
1463 #delay warning to give logger some time to import
1464 import _thread
1465 _thread.start_new_thread(__log_keyring_warning, ())
1466 # logger.warning('import keyring failed')
1467
[/code]
Thanks in advance,
sawbona
Bug#990972: coolmail 1.3-12 - sound plays distorted
Package: coolmail Version: 1.3-12 Severity: normal Using the available option to play a sound file istead of using the system beep as indicated in the /etc/X11/app-defaults/Coolmail file results in the application playing a highly distorted sound and not the intended *.au file. ie: --- coolmail.soundFile: /usr/local/bin/sounds/youvegotmail.au --- When run from a terminal with coolmail -v, the application wants to write to /dev/audio but complains about not being able to do it. --- ~$ coolmail -v Coolmail 1.3 watching file: /var/spool/mail/groucho Coolmail: Error writing to /dev/audio. ~$ --- The same file can be properly played by the aplay, VLC and Audacious applications so I think it is safe to conclude that there's not problem with the *.au file being used. My system has ALSA and the alsa-aoss package installed. Starting the application with aoss coolmail -v gets me the same (distorted audio/printout) results. Other texts I have seen online have only make reference to the *.au format, so it would seem that it is what the application expects. All the same, I tried with a *.wav file but got output saying that it is the wrong file format. Thanks in advance, JHM
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: Thank you very much for taking the time to write. On 29 Jun 2021 at 19:05, Marc Haber wrote: > The "exim installer" is called dpkg and is a core package ... Yes, I am quite aware of that. Which is *exactly* the reason I did not file a bug against dpkg. If anything, in the many years I have been using Linux, dpkg has always worked seamlessly every time and never shown me a bug. Kudos for that. 8^) But the bug I filed is against exim 4.94.2. > You have a point ... Yes, I *do* have a point. But unfortunately I am not being able to get it across. That dpkg pop up a *different* warning was meant to be an example of sorts, not to be taken literally. To drive home the concept, so to speak. Maybe the wrong example as I am not versed in the inner workings of dpkg (or anything Linux for that matter) although today I learnt something about how dpkg works. Like I have said previously: The problem is with the exim 4.94.2 package. It should *not* be able/allowed to use *any* of a previously installed version's configuration files when updated. Much less (and yes, it *is* a bug) offer the user the choice of keeping *any* of them when it gets installed by dpkg. Now, *how* it does that, whether through a well written script, a previous [c]apt-get purge exim4[/c] or dev-magic (joke!) should be absolutely transparent to the end user and result in a properly installed MTA. And not a hopelessly broken one piling up warnings in paniclog. > I apologize, but there is nothing the Debian exim maintainers ... So I gather. Well, that's that. I did my part and reported the problem. It is now up to the exim maintainers to do what they think is best. Greetings. CIV
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: Thank you for taking the time to write. > ... exim packages do not change/edit the file, if it was changed > then manually. Right. The userland cannot change it, it's only through *manual* edition. Now I'm *sure* I didn't change anything. I had never seen the insides of an exim config file till I had this problem. > > ... related to (at least one) of the settings that need to be > > changed for the exim4 configuration to be compatible > > with exim 4.94.2. > Sounds reasonable, yes. I thought as much also. > If you are not sure what you did change ... No. What I wrote was that I did not remember *ever* changing anything. But that I was *not absolutely certain* of not having done it. Not the same thing. I any case, it is a moot point. ie: it has no relevance with respect to the case I have been attempting to make which is this: Whether *any* of the configuration files were changed or not, a basic fact (which you find attendable/reasonable) remains: *Any* configuration file belonging to a version *previous* to exim 4.94.2, modified or not, will effectively break exim 4.94.2. eg: any configuration file containing *$local_part* instead of *$local_part_data*. If the dpkg installer considers no config file have been modified, it will overwrite then and everything will be allright. But ... If (for whatever reason) the dpkg installer considers some config file has been modified, it will recommend a default option that will break the MTA. If I may suggest: It would make a lot more sense (and would have saved me a lot of grief) if the exim 4.94.2 installer would have popped up something like this: - WARNING All exim versions prior to version 4.94.2 are now obsolete. As a result, *all* existing configurations set up with versions prior to exim 4.94.2 will effectively break this installation. The exim installation being updated is prior to exim version 4.94.2. It is emphatically recommended that you do not keep the present configuration. What do you want to do? 1. Replace the present configuration (recommended default) 2. Keep the present configuration 3. Open a terminal and compare the configuration files Thanks for your input.
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: On 26 Jun 2021 at 15:12, Andreas Metzler wrote: > I think that assumption is not correct. dpkg will (should) only ask > about the confffile if it *was* locally changed, otherwise the files are > overwritten without asking. I see ... The thing is that I don't remember *ever* changing any exim configuration. Unfortunately I cannot be categorical about it. ie: I am not absolutely certain. Right. Please bear with me, I'll try to be as brief as possible. Let us assume for the sake of the argument that I (on purpose or inadvertently) changed something in the configuration. What could I have possibly changed? Is there any user/userland configurable setting which would be then reflected or change *anything* in the exim4.conf.template file itself? Specifically, any of the settings mentioned in the readme.updating file: https://git.exim.org/exim.git/blob/HEAD:/src/README.UPDATING --- snip ---> Exim version 4.94 --- Some Transports now refuse to use tainted data in constructing their delivery location; this WILL BREAK configurations which are not updated accordingly. In particular: any Transport use of $local_part which has been relying upon check_local_user far away in the Router to make it safe, should be updated to replace $local_part with $local_part_data. <--- snip --- eg: $local_part I have checked and my pre-4.94.2 version reads *$local_part* and the 4.94.2 version reads *$local_part_data*. So, if the original configuration file *was* changed by me (on purpose or inadvertently), whatever change I could have made does not seem to be related to (at least one) of the settings that need to be changed for the exim4 configuration to be compatible with exim 4.94.2. Thank you very much for your input.
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Hello: Please excuse me, it happens that english is not my native language so it is quite probable that I may not have expressed myself correctly. > Overwriting local customizations is not an option. I was referring to whatever files are installed by *default* by the exim-config package. As I understand it, these files are *not* local customizations. Of these files, the one probably used my most desktop installations is the /etc/exim4/exim4.conf.template file used for the basic non-split configuration. Using an exim4.conf.template file from any version prior to exim 4.94.2 *will* break exim 4.94.2. Now, when I upgraded to exim 4.94.2 the installer asked me to make a choice with respect to the configuration. I chose the *default* (recommended) option. ie: to keep the existing configuration. But this *existing configuration* included the default exim4.conf.template file from the previous version of exim4. Making that choice (recommended) resulted in the installer keeping back the updated exim-config 4.94.2 package and leaving the installed version in place. Leaving the installed version in place broke the exim 4.94.2. Thanks in advance,
Bug#990343: backintime 1.1.24 - unhandled exception
Package: backintime Version: 1.1.24-0.1 Severity: normal I have recently received a notification in my system mail related to an unhandled exception in a backintime Python script. Here is the transcript: - Unhandled exception in thread started by Traceback (most recent call last): File "/usr/share/backintime/common/tools.py", line 1458, in __log_keyring_warning TypeError: 'NoneType' object is not callable - This is the first time I have seen (or noticed) such a message. It has not happened again since. The notification was sent by the cron daemon on date Mon, 21 Jun 2021 11:00:02 -0300. The last backintime log entry was for a snapshot taken at Mon Jun 21 07:15:01 2021 local time and does not show any errors. The crontab script is a system entry generated by the GUI and the python script is part of the application's installation. [code] #Back In Time system entry, this will be edited by the gui: 60 */15 * * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null [/code] Python installed version is 2.7.16 (default, Oct 10 2019, 22:02:15). I have reported this issue to https://github.com/bit-team/backintime/issues: [url]https://github.com/bit-team/backintime/issues/1169[/url] Later on I found that it had *also* been reported back in 10/2017: [url]https://github.com/bit-team/backintime/issues/820[/url] The OP's report is virtually identical to the one I filed and included messages from --debug: [code] Unhandled exception in thread started by Traceback (most recent call last): File "/usr/share/backintime/common/tools.py", line 1463, in __log_keyring_warning File "", line 2237, in _find_and_load File "", line , in _find_and_load_unlocked File "", line 2150, in _find_spec TypeError: 'NoneType' object is not callable [/code] The OP's report did not have any subsequent follow-up from the maintainers of the backintime package. Thanks in advance, sawbona
Bug#990344: exim 4.94.2 update default configuration option breaks MTA
Package: exim4 Version: 4.94 Severity: grave Half way through the update to exim 4.94.2, the installer pops up a warning in the terminal informing that the configuration file being installed is different to the one in place and prompts to choose what to do: 1. keep the installed configuration (default) 2. install the new configuration 3. check and compare the differences in order to choose. In most default Debian installations the installer will be referring to the [c]/etc/exim4/exim4.conf.template[/c] which is used by the default non-split configuration scheme used by most anyone running a Debian desktop box. Most users will choose the (recommended) default option. In doing so they will unknowingly break their exim4 installation. The result is a non-working MTA, with system mail being held. ie: not delivered to /var/mail/user folder while at the same time /var/log/exim4/paniclog slowly grows in size. With all versions of exim previous to version 4.94.2 now rendered obsolete, exim 4.94.2 will break any and all configurations set up with previous versions of the package. This happens whether it uses the default configuration ie: the non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file or the split configuration scheme used in more complex installations and which you can eventually opt for when installing Debian or by running dpkg-reconfigure exim4-config later on. --- exim 4.94.2 is absolutely incompatible with any configuration files used/generated with versions previous to version 4.94.2. Worse yet, it is absolutely incompatible with *any* configuration file contained in the exim-config package from versions preceding exim 4.94.2. Presenting the option to keep *any* existing configuration file when updating to exim version 4.94.2 generates a big problem. --- Presenting the options to keep installed files is *always* quite reasonable but not in *this* very significant update. Thanks in advance,
Bug#876303: Question regarding status
Good morning: Could you tell me the status of this bug (876303)? ie: will it be fixed for 5.0? Thanks in advance. Best,Carlos Izzo Videla
Bug#855646: linux-image-4.9.0-9-686-pae: [i915] kernel oops on Asus 1000HE
This bug is also present in linux-image-4.9.0-9-686-pae. Kernel log: May 19 13:34:12 devuan kernel: [8.079680] [ cut here ] May 19 13:34:12 devuan kernel: [8.079844] WARNING: CPU: 0 PID: 6 at /build/linux-6uB1fl/linux-4.9.168/drivers/gpu/drm/i915/intel_fbdev.c:414 intel_fb_initial_config+0x3fc/0x5f0 [i915] May 19 13:34:12 devuan kernel: [8.079881] WARN_ON(!connector->state->crtc) May 19 13:34:12 devuan kernel: [8.079890] Modules linked in: May 19 13:34:12 devuan kernel: [8.079909] cfg80211(+) psmouse crc_ccitt rfkill lpc_ich ata_generic mfd_core atl1e ehci_hcd sg i915 snd_hda_codec_realtek ata_piix usbcore drm_kms_helper rng_core snd_hda_codec_generic wmi drm snd_hda_intel snd_hda_codec i2c_algo_bit usb_common snd_hda_core video battery snd_hwdep button ac shpchp snd_pcm snd_timer snd soundcore acpi_cpufreq ext4 crc16 jbd2 crc32c_generic fscrypto ecb xts lrw gf128mul ablk_helper cryptd aes_i586 mbcache sd_mod ahci libahci evdev libata serio_raw scsi_mod thermal May 19 13:34:12 devuan kernel: [8.080205] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.9.0-9-686-pae #1 Debian 4.9.168-1+deb9u2 May 19 13:34:12 devuan kernel: [8.080238] Hardware name: ASUSTeK Computer INC. 1000HE/1000HE, BIOS 110410/14/2009 May 19 13:34:12 devuan kernel: [8.080278] Workqueue: events_unbound async_run_entry_fn May 19 13:34:12 devuan kernel: [8.080301] f5d19d40 dd2ff602 f5d19d54 dd06a30a f8cfddc6 f5d19d74 0006 May 19 13:34:12 devuan kernel: [8.080349] f8cf1370 019e f8c9ff0c 019e 0009 f8c9ff0c 0001 f76f6400 May 19 13:34:12 devuan kernel: [8.080395] f5d19d60 dd06a376 0009 f5d19d54 f8cfddc6 f5d19d74 May 19 13:34:12 devuan kernel: [8.080442] Call Trace: May 19 13:34:12 devuan kernel: [8.080469] [] ? dump_stack+0x55/0x73 May 19 13:34:12 devuan kernel: [8.080496] [] ? __warn+0xea/0x110 May 19 13:34:12 devuan kernel: [8.080643] [] ? intel_fb_initial_config+0x3fc/0x5f0 [i915] May 19 13:34:12 devuan kernel: [8.080787] [] ? intel_fb_initial_config+0x3fc/0x5f0 [i915] May 19 13:34:12 devuan kernel: [8.080815] [] ? warn_slowpath_fmt+0x46/0x60 May 19 13:34:12 devuan kernel: [8.080957] [] ? intel_fb_initial_config+0x3fc/0x5f0 [i915] May 19 13:34:12 devuan kernel: [8.080986] [] ? __kmalloc+0xef/0x500 May 19 13:34:12 devuan kernel: [8.081124] [] ? gen2_write16+0x130/0x130 [i915] May 19 13:34:12 devuan kernel: [8.081265] [] ? intelfb_create+0x4d0/0x4d0 [i915] May 19 13:34:12 devuan kernel: [8.081298] [] ? drm_setup_crtcs+0x1a6/0x950 [drm_kms_helper] May 19 13:34:12 devuan kernel: [8.081327] [] ? try_to_wake_up+0x45/0x370 May 19 13:34:12 devuan kernel: [8.081352] [] ? wake_up_q+0x2e/0x60 May 19 13:34:12 devuan kernel: [8.081384] [] ? drm_fb_helper_initial_config+0xc1/0x410 [drm_kms_helper] May 19 13:34:12 devuan kernel: [8.081422] [] ? pick_next_task_fair+0x490/0x520 May 19 13:34:12 devuan kernel: [8.081565] [] ? intel_fbdev_fini+0xd0/0xd0 [i915] May 19 13:34:12 devuan kernel: [8.081704] [] ? intel_fbdev_initial_config+0x16/0x30 [i915] May 19 13:34:12 devuan kernel: [8.081730] [] ? async_run_entry_fn+0x3a/0x180 May 19 13:34:12 devuan kernel: [8.081754] [] ? deactivate_task+0x20/0xf0 May 19 13:34:12 devuan kernel: [8.081778] [] ? __schedule+0x268/0x770 May 19 13:34:12 devuan kernel: [8.081802] [] ? process_one_work+0x146/0x390 May 19 13:34:12 devuan kernel: [8.081827] [] ? worker_thread+0x39/0x480 May 19 13:34:12 devuan kernel: [8.081853] [] ? kthread+0xb7/0xd0 May 19 13:34:12 devuan kernel: [8.081876] [] ? process_one_work+0x390/0x390 May 19 13:34:12 devuan kernel: [8.081901] [] ? kthread_park+0x50/0x50 May 19 13:34:12 devuan kernel: [8.081926] [] ? ret_from_fork+0x1b/0x3c May 19 13:34:12 devuan kernel: [8.081975] ---[ end trace ed569afeede51ae9 ]--- May 19 13:34:12 devuan kernel: [8.097894] fbcon: inteldrmfb (fb0) is primary device May 19 13:34:12 devuan kernel: [8.099120] [ cut here ] May 19 13:34:12 devuan kernel: [8.099145] WARNING: CPU: 0 PID: 6 at /build/linux-6uB1fl/linux-4.9.168/drivers/gpu/drm/drm_atomic_helper.c:783 drm_atomic_helper_update_legacy_modeset_state+0x22a/0x260 [drm_kms_helper] May 19 13:34:12 devuan kernel: [8.099227] Modules linked in: pcspkr(+) cfg80211(+) psmouse crc_ccitt rfkill lpc_ich ata_generic mfd_core atl1e ehci_hcd sg i915 snd_hda_codec_realtek ata_piix usbcore drm_kms_helper rng_core snd_hda_codec_generic wmi drm snd_hda_intel snd_hda_codec i2c_algo_bit usb_common snd_hda_core video battery snd_hwdep button ac shpchp snd_pcm snd_timer snd soundcore acpi_cpufreq ext4 crc16 jbd2 crc32c_generic fscrypto ecb xts lrw gf128mul ablk_helper cryptd aes_i586 mbcache sd_mod ahci libahci evdev libata serio_raw scsi_mod thermal May 19 13:34:12 devuan kernel: [8.099236] CPU: 0 PID: 6 Comm:
