Bug#610918: exim4 fails to start without ipv6

[Sven C. Dack]

Hello,

I'm seeing the same bug here now. For some reason did this not matter in the 
past, but as of last update does Debian fail to install exim4 due to the 
disabled ipv6.


Why does exim4 all of a sudden require ipv6? I'm not interested in ipv6 and 
would appreciate it if Debian didn't make this a requirement.



Setting up exim4-daemon-light (4.89-1) ...
Job for exim4.service failed because of unavailable resources or another system 
error.

See "systemctl status exim4.service" and "journalctl -xe" for details.
invoke-rc.d: initscript exim4, action "start" failed.
● exim4.service - LSB: exim Mail Transport Agent
   Loaded: loaded (/etc/init.d/exim4; generated; vendor preset: enabled)
   Active: failed (Result: resources) since Thu 2017-04-13 17:58:50 BST; 5ms ago
 Docs: man:systemd-sysv-generator(8)
  Process: 4192 ExecStart=/etc/init.d/exim4 start (code=exited, 
status=0/SUCCESS)

Apr 13 17:58:50 debian-linux systemd[1]: Starting LSB: exim Mail Transport A…...
Apr 13 17:58:50 debian-linux exim4[4192]: Starting MTA: exim4.
Apr 13 17:58:50 debian-linux exim4[4192]: ALERT: exim paniclog /var/log/exim…ken
Apr 13 17:58:50 debian-linux systemd[1]: exim4.service: PID file /run/exim4/…ory
Apr 13 17:58:50 debian-linux systemd[1]: exim4.service: Daemon never wrote i…ng.
Apr 13 17:58:50 debian-linux systemd[1]: Failed to start LSB: exim Mail Tran…nt.
Apr 13 17:58:50 debian-linux systemd[1]: exim4.service: Unit entered failed …te.
Apr 13 17:58:50 debian-linux systemd[1]: exim4.service: Failed with result '…s'.

...

2017-04-13 17:58:50 IPv6 socket creation failed: Address family not supported by
 protocol

Note, this was working in the past and without ipv6. It produced the error 
message, but didn't cause an abort of the installation procedure.


Could this be a problem of systemd?

Bug#842184: policykit-1: synaptic-pkexec no more work

[Sven C. Dack]

On Thu, 27 Oct 2016 12:11:20 +0200 KeyofBlueS  wrote:
> I am on Xfce so yes, using policykit-1-gnome here. And again yes, after
> running /usr/lib/x86_64-linux-gnu/polkit-gnome-authentication-agent-1 from
> a terminal, authentication works fine.
>
> Good job!
> Thanks
>
> 2016-10-27 11:00 GMT+02:00 Simon McVittie :
>
> > Control: reassign 842184 policykit-1-gnome 0.105-4
> > Control: severity 842184 serious
> >
> > On Thu, 27 Oct 2016 at 07:27:05 +, Grand T wrote:
> > > The error is in policykit-1-gnome 0.105-4
> > >
> > > /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop refer to
> > >
> > > Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
> > >
> > > but it don't exist so it is not started !
> > >
> > > The exec is now at/usr/lib/x86_64-linux-gnu/polkit-gnome-authentication-
> > agent-1
> > >
> > > I modified
> > >
> > > /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop to set up
> > > Exec=/usr/lib/x86_64-linux-gnu/polkit-gnome-authentication-agent-1
> >
> > Good catch! It looks as though this was caused by modernizing the
> > packaging of policykit-1-gnome from debhelper 8 to 10, which changed its
> > ${libexecdir}, without also updating
> > debian/polkit-gnome-authentication-agent-1.desktop to use the new
> > value of ${libexecdir}.
> >
> > So this is not actually a policykit-1 bug, but rather policykit-1-gnome,
> > which is a separate source package. Contrary to its name, pk-1-gnome
> > is not actually used in "full" GNOME any more (because GNOME Shell has
> > its own built-in polkit agent), but it does get used in XFCE, Unity and
> > GNOME Flashback.
> >
> > Brian (and anyone else who is seeing #841878), are you using
> > policykit-1-gnome as your implementation of a polkit agent? If you
> > run /usr/lib/x86_64-linux-gnu/polkit-gnome-authentication-agent-1
> > "by hand" from a terminal, does authentication work normally for you?
> >
> > (If you have edited /etc/xdg/autostart/polkit-
> > gnome-authentication-agent-1.desktop
> > as a workaround, you will probably need to edit it again, or go back to
> > the version provided by the package maintainer, after this bug is fixed -
> > we will probably choose a different location for the authentication agent,
> > or go back to its old location, because the architecture-dependent path is
> > awkward to use in the packaging.)
> >
> > Thanks,
> > S
> >

Safest and easiest work-around is probably the following:

1. In Xfce4 open the menu "Settings" -> "Session and Startup" and select the tab 
"Application Autostart".

2. There scroll to "PolicyKit Authentication Agent" and disable it.
3. Add a new entry with the "+ Add" button with a name like "Polkit Work-Around" 
and the command "/usr/lib/x86_64-linux-gnu/polkit-gnome-authentication-agent-1"

4. Click "Ok" and "Close".

So basically does one disable the default auto-start of the currently broken 
service and replaces it with a private service to start it manually, which can 
later be removed easily once it's been properly fixed.


Also note that not only synaptic seems to be affected, but gparted as well and 
also the gvfs samba plugin for the file manager for browsing Windows shares on 
the LAN needs this, too, and currently fails as well. There will likely be a few 
more.


Sven

Bug#841420: --enable-default-pie breaks kernel builds

[Sven C. Dack]

On Sun, 30 Oct 2016 14:41:18 + "Sven C. Dack" <sven.c.d...@sky.com> wrote:
> On Fri, 21 Oct 2016 08:07:03 -0500 "S. R. Wright" <srw6...@gmail.com> wrote:
> > I agree with Eric; while the workaround is to back rev the gcc and its
> > associated packages, I also build kernels straight from kernel.org,
> > usually within hours of their availability and this has been working for
> > me for many years, and it is not sufficient to justify this change by
> > saying doing so "isn't a good idea." A change of functionality of this
> > scope warrants a minor version number increase, this change was not
> > merely a bug fix.
> >
> > As the kernel is the most important code gcc is ever likely to compile
> > on debian or any other distro for that matter, this change should be
> > backed out, and not reintroduced UNTIL the *official* kernel source is
> > ready for it.
> >
> > -- sRw
>
> I'm seeing the same failure and agree with the above statements.
>
> Please note that a vanilla gcc-6 can compile a vanilla kernel, and so should
> Debian's gcc-6.
>
> Sven C.
>

To add to this, enabling -fpie and -fPIE per default for *ALL* compilations can 
only be a mistake.


Position independent code when generated with -fpic, -fPIC, -fpie or -fPIE, is 
commonly slower (by 3%-5%) than normal code. Enabling it as the default for 
everything will certainly lead to a performance regression for the entire Debian 
distribution and beyond.


Sven C.

Bug#841420: --enable-default-pie breaks kernel builds

[Sven C. Dack]

On Fri, 21 Oct 2016 08:07:03 -0500 "S. R. Wright"  wrote:
> I agree with Eric; while the workaround is to back rev the gcc and its
> associated packages, I also build kernels straight from kernel.org,
> usually within hours of their availability and this has been working for
> me for many years, and it is not sufficient to justify this change by
> saying doing so "isn't a good idea." A change of functionality of this
> scope warrants a minor version number increase, this change was not
> merely a bug fix.
>
> As the kernel is the most important code gcc is ever likely to compile
> on debian or any other distro for that matter, this change should be
> backed out, and not reintroduced UNTIL the *official* kernel source is
> ready for it.
>
> -- sRw

I'm seeing the same failure and agree with the above statements.

Please note that a vanilla gcc-6 can compile a vanilla kernel, and so should 
Debian's gcc-6.


Sven C.