Re: XDG_RUNTIME_DIR points to non-existing path

[Aurelien Jarno]

Hi,

On 2018-03-19 12:31, Sandro Knauß wrote:
> Hey,
> 
> I am currently packaging kdepim for Debian and unfortunately test failing for 
> many archs, because XDG_RUNTIME_DIR is pointing to non-existing path. If I 
> understand the documentation from freedesktop [1] correctly, it is in the 
> responsibility of the system to provide a valid path:
> 
> "XDG_RUNTIME_DIR defines the base directory relative to which user-specific 
> non-essential runtime files and other file objects (such as sockets, named 
> pipes, ...) should be stored. The directory MUST be owned by the user, and he 
> MUST be the only one having read and write access to it. Its Unix access mode 
> MUST be 0700.
> 
> The lifetime of the directory MUST be bound to the user being logged in. It 
> MUST be created when the user first logs in and if the user fully logs out 
> the 
> directory MUST be removed. If the user logs in more than once he should get 
> pointed to the same directory, and it is mandatory that the directory 
> continues to exist from his first login to his last logout on the system, and 
> not removed in between. Files in the directory MUST not survive reboot or a 
> full logout/login cycle. "

You actually pointed to the problem there, the buildd user never login
in the chroot, so it never gets created.

> Currently the tests failing for kdav [2]:
> QWARN  : DavItemFetchJobTest::runSuccessfullTest() QStandardPaths: 
> XDG_RUNTIME_DIR points to non-existing path '/run/user/2952', please create 
> it 
> with 0700 permissions.
> 
> Several archs show the same behaviour: arm64, armel,armhf, i386, mips, 
> mips64el, mipsel, ppc64el and s390x. Maybe also amd64 but as I uploaded amd64 
> packages and the buildds haven't build them. See [3] version 17.12.2-1. 

They all use the same software so that's normal they fail the same way.
That kind of issue should probably be fixed directly in the sbuild
package, which is used by the build daemons.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Aurelien Jarno]

Hi,

On 2018-03-07 12:08, Hector Oron wrote:
> Hello,
> 
> 2018-03-07 12:01 GMT+01:00 Philipp Kern :
> > Has it been tested? Well, lightly. Unfortunately I'm not really allowed to
> > touch the buildds as root so it's kinda hard to replace the existing ones
> > given that stuff is enforced by Puppet. So I did a few builds on zemlinsky.
> > Should it be tested on one or two? Yes. In theory it should work. :)
> >
> >>> There were concerns about how DSA wanted this to be packaged (essentially
> >>> not at all).
> >>
> >>
> >> Sorry I missed those concerns, could you expand on them or link to
> >> discussion?
> >
> >
> > I mostly worked on this with Aurelien and the concern seems to have been
> > that DSA would prefer user-based services with linger rather than packages.
> 
> There are two ways to deploy it:
> 1. Get the code in buildd via DSA puppet.
> 2. Create Debian package, upload it, make a backport. Then it can be
> deployed via backport.

Can we move forward on that issue? Discussions on IRC suggested that
using apt.buildd.debian.org, like it's done for the current packages
is not the right choice. The suggested way to run things would be to
just deploy things in ~buildd. As pybuildd uses systemd services, it
means we need to enable lingering on buildds. Is it fine?

The alternative as suggested by Hector is to use the package from
backports. This means less flexibility if we need to update the code, as
it will take at minimum 5 days following the policy.

To do more tests I agree that we should deploy it on more buildds. For
*this phase*, I believe enabling lingering and deploying it by hand is
the best. Is it something acceptable?

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature