Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[James Clarke]

On 17 Oct 2017, at 22:39, Samuel Thibault  wrote:
> 
> Hello,
> 
> It seems I missed the whole thread, so found the same issue
> independently :)
> 
> Simon McVittie, on mar. 17 oct. 2017 16:21:06 +0100, wrote:
>> Thanks. Hmm, so the error is:
>> 
>>sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not 
>> going to be installed
>> 
>> which is amazingly helpful.
> 
> Adding  -o Debug::pkgProblemResolver=yes provides the useful
> information:
> 
> Investigating (0) dconf-service:hurd-i386 < none -> 0.26.1-1 @un uN Ib >
> Broken dconf-service:hurd-i386 Depends on default-dbus-session-bus:hurd-i386 
> < none @un H >
>  Considering dbus-user-session:hurd-i386 0 as a solution to 
> dconf-service:hurd-i386 7
>  Holding Back dconf-service:hurd-i386 rather than change 
> default-dbus-session-bus:hurd-i386
> ...

Indeed, that's how I debugged it too.

>> The dependency chain:
>> 
>>libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend
>>dconf-gsettings-backend Depends dconf-service
>>dconf-service Depends d-d-s-b | d-s-b
>> 
>> so we already have two layers of "if you accepted the alternative you'd
>> be fine". I thought sbuild's allergy to alternatives only extended as
>> far as direct dependencies?
> 
> That wouldn't be acceptable anyway, for the same reason as the direct
> dependencies.

Agreed. Note that in this case it's not sbuild ignoring the alternatives
as Simon mentioned, but apt itself; this is the default behaviour you get
from `apt-get install libgtk-3-dev`.

Regards,
James

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Samuel Thibault]

Hello,

It seems I missed the whole thread, so found the same issue
independently :)

Simon McVittie, on mar. 17 oct. 2017 16:21:06 +0100, wrote:
> Thanks. Hmm, so the error is:
> 
> sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not 
> going to be installed
> 
> which is amazingly helpful.

Adding  -o Debug::pkgProblemResolver=yes provides the useful
information:

Investigating (0) dconf-service:hurd-i386 < none -> 0.26.1-1 @un uN Ib >
Broken dconf-service:hurd-i386 Depends on default-dbus-session-bus:hurd-i386 < 
none @un H >
  Considering dbus-user-session:hurd-i386 0 as a solution to 
dconf-service:hurd-i386 7
  Holding Back dconf-service:hurd-i386 rather than change 
default-dbus-session-bus:hurd-i386
...

> The dependency chain:
> 
> libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend
> dconf-gsettings-backend Depends dconf-service
> dconf-service Depends d-d-s-b | d-s-b
> 
> so we already have two layers of "if you accepted the alternative you'd
> be fine". I thought sbuild's allergy to alternatives only extended as
> far as direct dependencies?

That wouldn't be acceptable anyway, for the same reason as the direct
dependencies.

Samuel

Re: wget: FTBFS on hurd-i386

[Svante Signell]

Cc: debian-hurd

Another ping, almost two months later.


On Sun, 2017-08-27 at 10:30 +0200, Svante Signell wrote:
> found 858995 1.19.1-4
> thanks
> 
> ping again
> 
> The upstream patch has already been added to grep and findutils
> (#867120).
> 

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Simon McVittie]

On Tue, 17 Oct 2017 at 15:46:27 +0100, James Clarke wrote:
> On 17 Oct 2017, at 15:12, Simon McVittie  wrote:
> > I can't help wondering whether the non-Linux ports should configure their
> > buildds to use the aptitude dependency resolver (as used in -backports)
> > or the aspcud resolver (as used in experimental) to get out of this
> > situation. Surely this can't be the first time this has happened?
> 
> They could, but then the resolvers differ across architectures, and that will
> likely cause its own set of confusing problems. I'm not aware of many cases
> where using apt has been a problem like this, though I could be wrong.

The resolvers already differ between suites and cause different confusing
problems, but I get your point.

> > Can you point me to an example of buildd logs where the Linux build
> > succeeded and !Linux builds failed as a result of this?
> 
> OpenCV currently suffers from this[0] (hence why Mattia is Cc'ed).

Thanks. Hmm, so the error is:

sbuild-build-depends-opencv-dummy : Depends: libgtk-3-dev but it is not 
going to be installed

which is amazingly helpful. Some versions of sbuild run a solver or
dose-depcheck to try to work out why, but it looks like this one doesn't.

This buildd appears to be running sbuild 0.65.2, which is oldstable. Is
this a known issue on kFreeBSD? I would have assumed that porters
would want to stay close to what the release architectures have, which
is 0.73.0?

The dependency chain:

libgtk-3-dev Depends dconf-gsettings-backend | gsettings-backend
dconf-gsettings-backend Depends dconf-service
dconf-service Depends d-d-s-b | d-s-b

so we already have two layers of "if you accepted the alternative you'd
be fine". I thought sbuild's allergy to alternatives only extended as
far as direct dependencies?

> it's a shame
> wanna-build's use of dose-builddebcheck doesn't match apt's behaviour)

It is. If the buildd was running a newer sbuild, I think its log would
at least explain the situation in more detail.

smcv

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Simon McVittie]

On Tue, 17 Oct 2017 at 15:12:11 +0100, Simon McVittie wrote:
> On Tue, 17 Oct 2017 at 13:41:31 +0100, James Clarke wrote:
> > Please modify dbus, either with more complicated Provides
> 
> This requires dbus-user-session to become Architecture: linux-any
> instead of all

Seems to work, so I've pushed it to git. In the next upload, we'll
have:

dbus-user-session (Architecture: linux-any) Provides: d-d-s-b
dbus-x11 (Architecture: any) Provides: d-d-s-b [!linux-any]

so every architecture will have exactly one d-d-s-b implementation.

Build-time tests are still responsible for starting a dbus-daemon
if they need one: the API guarantee of the dbus-session-bus virtual
package is only for "normal" GUI logins (deliberately left a bit vague
so that dbus-x11 can be an implementation of it), and buildds are not
one of those. The preferred interfaces for this are to use the
dbus-run-session "adverb":

dbus-run-session -- make check

or invoke dbus-daemon directly if more control is needed:


https://sources.debian.net/src/flatpak/0.8.5-2%2Bdeb9u1/tests/libtest.sh/#L259

Regards,
smcv

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[James Clarke]

On 17 Oct 2017, at 15:12, Simon McVittie  wrote:
> 
> Control: tags -1 confirmed pending
> Control: severity -1 wishlist
> 
> On Tue, 17 Oct 2017 at 13:41:31 +0100, James Clarke wrote:
>> Please modify dbus, either with more complicated Provides
> 
> This requires dbus-user-session to become Architecture: linux-any
> instead of all (lots of duplicate per-Linux-architecture copies of
> the same thing), but at least it doesn't involve going through NEW,
> and arguably making it linux-any is more correct. In principle I'm OK
> with doing this, although I'll need to try a build on a porterbox to
> check I've done the architecture specifier syntax correctly.
> 
> It's a pity we don't have a way to express "this is
> architecture-independent, but should only appear in a subset of the
> apt Packages files". If we did, dbus-user-session could be
> "all [linux-any]" or whatever the syntax was, and continue to provide
> d-d-s-b.
> 
> Alternatively, I'd review patches if someone wants to teach
> dbus-user-session how to support non-systemd, although that would almost
> certainly mean someone writing a PAM module to do the work (an alternative
> to libpam-systemd) and being its upstream and Debian maintainer. Sorry,
> I'm not willing to maintain that part, only "glue" analogous to what's
> already in the package for systemd.
> 
> The design requirements for dbus-user-session are:
> 
> * one `dbus-daemon --session` per uid
> * after the PAM login stack has run, either or both (preferably both):
>  - XDG_RUNTIME_DIR must be set to a unique directory per uid on a
>tmpfs (or non-Linux equivalent) with a listening socket at
>$XDG_RUNTIME_DIR/bus
>  - DBUS_SESSION_BUS_ADDRESS must be set to the right thing
> * connecting to the given address must result in a connection to the
>  `dbus-daemon --session` (it can be started lazily with socket
>  activation, like systemd does, or eagerly, like dbus-launch does)
> * after the PAM logout stack has run, if and only if this was the uid's
>  last parallel login session, the dbus-daemon should be terminated
>  and the XDG_RUNTIME_DIR should be deleted
> 
> In systemd-land, pam_systemd (which is misnamed, it's really part of
> logind) notifies logind about the login/logout, logind creates/destroys
> the XDG_RUNTIME_DIR if this is the first login/last logout, logind tells
> systemd-as-pid-1 to start `systemd --user` if this is the first login or
> stop it if this is the last logout, and `systemd --user` loads the
> dbus.socket and dbus.service provided by dbus-user-session.
> 
> Ubuntu used to have a PAM module to set up and tear down XDG_RUNTIME_DIR,
> but they were its upstream, so now that they use systemd-logind it's
> unmaintained.
> 
>> or by making default-dbus-session-bus an actual
>> meta-package
> 
> When I proposed (default-)dbus-session-bus I was told not to use a
> real package, for reasons that were never particularly clear to me.
> (Thread: ,
> related Policy bug documenting the metapackages:
> )
> 
> If I had used real packages, the real package would have been
> dbus-session-bus, which would have had alternative dependencies
> on dbus-user-session | hypothetical-future-kdbus-thing | dbus-x11
> (with [linux-any] scattered around where appropriate). However,
> the virtual package approach has been widely adopted now, so I'll
> go the other way.

It seems to me from looking at that thread that the main reason for using a
virtual package is that it's simpler. The example given was for the default
MTA, which works because Debian has the same default across all architectures,
but for something like this it isn't so simple and you then have to mess about
with spreading the Provides across different packages and making them
conditional, rather than just a single meta-package with the relevant
conditional Depends in one place.

>> This has recently become a problem because dconf-service
>> 0.26.1-1 now depends on default-dbus-session-bus | dbus-session-bus,
>> making it uninstallable on the buildds for non-Linux unless their build
>> deps happen to have something else depending on dbus-session-bus (or
>> dbus-x11).
> 
> I can't help wondering whether the non-Linux ports should configure their
> buildds to use the aptitude dependency resolver (as used in -backports)
> or the aspcud resolver (as used in experimental) to get out of this
> situation. Surely this can't be the first time this has happened?

They could, but then the resolvers differ across architectures, and that will
likely cause its own set of confusing problems. I'm not aware of many cases
where using apt has been a problem like this, though I could be wrong.

> Can you point me to an example of buildd logs where the Linux build
> succeeded and !Linux builds failed as a result of this?

OpenCV currently suffers from this[0] (hence why Mattia is Cc'ed).

Thanks,
James

[0] 
https://buildd.de

Re: Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Simon McVittie]

Control: tags -1 confirmed pending
Control: severity -1 wishlist

On Tue, 17 Oct 2017 at 13:41:31 +0100, James Clarke wrote:
> Please modify dbus, either with more complicated Provides

This requires dbus-user-session to become Architecture: linux-any
instead of all (lots of duplicate per-Linux-architecture copies of
the same thing), but at least it doesn't involve going through NEW,
and arguably making it linux-any is more correct. In principle I'm OK
with doing this, although I'll need to try a build on a porterbox to
check I've done the architecture specifier syntax correctly.

It's a pity we don't have a way to express "this is
architecture-independent, but should only appear in a subset of the
apt Packages files". If we did, dbus-user-session could be
"all [linux-any]" or whatever the syntax was, and continue to provide
d-d-s-b.

Alternatively, I'd review patches if someone wants to teach
dbus-user-session how to support non-systemd, although that would almost
certainly mean someone writing a PAM module to do the work (an alternative
to libpam-systemd) and being its upstream and Debian maintainer. Sorry,
I'm not willing to maintain that part, only "glue" analogous to what's
already in the package for systemd.

The design requirements for dbus-user-session are:

* one `dbus-daemon --session` per uid
* after the PAM login stack has run, either or both (preferably both):
  - XDG_RUNTIME_DIR must be set to a unique directory per uid on a
tmpfs (or non-Linux equivalent) with a listening socket at
$XDG_RUNTIME_DIR/bus
  - DBUS_SESSION_BUS_ADDRESS must be set to the right thing
* connecting to the given address must result in a connection to the
  `dbus-daemon --session` (it can be started lazily with socket
  activation, like systemd does, or eagerly, like dbus-launch does)
* after the PAM logout stack has run, if and only if this was the uid's
  last parallel login session, the dbus-daemon should be terminated
  and the XDG_RUNTIME_DIR should be deleted

In systemd-land, pam_systemd (which is misnamed, it's really part of
logind) notifies logind about the login/logout, logind creates/destroys
the XDG_RUNTIME_DIR if this is the first login/last logout, logind tells
systemd-as-pid-1 to start `systemd --user` if this is the first login or
stop it if this is the last logout, and `systemd --user` loads the
dbus.socket and dbus.service provided by dbus-user-session.

Ubuntu used to have a PAM module to set up and tear down XDG_RUNTIME_DIR,
but they were its upstream, so now that they use systemd-logind it's
unmaintained.

> or by making default-dbus-session-bus an actual
> meta-package

When I proposed (default-)dbus-session-bus I was told not to use a
real package, for reasons that were never particularly clear to me.
(Thread: ,
related Policy bug documenting the metapackages:
)

If I had used real packages, the real package would have been
dbus-session-bus, which would have had alternative dependencies
on dbus-user-session | hypothetical-future-kdbus-thing | dbus-x11
(with [linux-any] scattered around where appropriate). However,
the virtual package approach has been widely adopted now, so I'll
go the other way.

> This has recently become a problem because dconf-service
> 0.26.1-1 now depends on default-dbus-session-bus | dbus-session-bus,
> making it uninstallable on the buildds for non-Linux unless their build
> deps happen to have something else depending on dbus-session-bus (or
> dbus-x11).

I can't help wondering whether the non-Linux ports should configure their
buildds to use the aptitude dependency resolver (as used in -backports)
or the aspcud resolver (as used in experimental) to get out of this
situation. Surely this can't be the first time this has happened?

Can you point me to an example of buildd logs where the Linux build
succeeded and !Linux builds failed as a result of this?

smcv

Still Failing: g-i-installation_debian_sid_daily_hurd_lxde/431

[jenkins]

See 
https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/431/ 
and 
https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/431//console
 and 
https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/431//artifact/results/
 if there are any.