Bug#941893: RFA: pam-dbus
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, pam-dbus (which allows you to configure a guest account where people can log in when you approve it by approving a notification popup) was a fun experiment from me years ago, but I never used it, and have not touched it in a while. Since this is somewhat security-related, this really shouldn’t be in the archive without an active maintainer. The UI part needs porting to gtk3 (this kicks it off testing right now). Is anyeone interest in taking it over (upstream and packaging)? Else I’ll ask for its removal at some point in the future. Cheers, Joachim -BEGIN PGP SIGNATURE- iHEEARECADEWIQQxTjstYFpus1p9gRn2KOuTR0MgbAUCXZrynhMcbm9tZWF0YUBk ZWJpYW4ub3JnAAoJEPYo65NHQyBsBQ0AoMieNUq0xpL03WQClQexpuyZbZ/AAJsG 3ItfHjbETUarrkS4tXmbPNFDKg== =nTJc -END PGP SIGNATURE-
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 1:23 PM Johannes Schauer wrote: > > Quoting Paul Wise (2019-10-07 03:38:55) > > On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > > > FYI, this is because autopkgtest has an abstraction for multiple > > > container/virtualization mechanisms (lxc, lxd, qemu, schroot) > > It seems like this abstraction should be split out of the autopkgtest > > source and then depended on by autopkgtest. Do any other such > > abstraction layers exist? > > I do not know of any other such abstraction layers but would warmly welcome > them not only for the purpose of including them in sbuild. > Not sure if containerd[1] and cri[2] are such abstraction layers. They are widely used in cloud/container area. For containerd, it supports both container and virtualization[3] backends. [1] https://containerd.io/ [2] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md [3] https://katacontainers.io/ -- Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote: > Specifically, currently autopkgtest is limited to providing a read-only layer > for certain backends and its upstream has no intention of widening the scope > of > the software [1]. This means that to upgrade an autopkgtest backend, the user > has to apply backend-specific actions I think "re-bootstrap, don't upgrade" is an equally good principle for autopkgtest and sbuild? Both will be equally susceptible to accumulating cruft during upgrades that wouldn't have been there in a fresh debootstrap, which is undesired if you want the invariant that you are (building|testing) in "today's" minimal environment. smcv
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>
> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
> > Specifically, currently autopkgtest is limited to providing a read-only
> > layer
> > for certain backends and its upstream has no intention of widening the
> > scope of
> > the software [1]. This means that to upgrade an autopkgtest backend, the
> > user
> > has to apply backend-specific actions
>
> I think "re-bootstrap, don't upgrade" is an equally good principle
Why not have a repository for it, like dockerhub. So this becomes
"pull latest build env", which saves lots of time("re-bootstrap" is
still slow nowadays).
--
Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>>
>> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
>>> Specifically, currently autopkgtest is limited to providing a read-only
>>> layer
>>> for certain backends and its upstream has no intention of widening the
>>> scope of
>>> the software [1]. This means that to upgrade an autopkgtest backend, the
>>> user
>>> has to apply backend-specific actions
>>
>> I think "re-bootstrap, don't upgrade" is an equally good principle
>
> Why not have a repository for it, like dockerhub. So this becomes
> "pull latest build env", which saves lots of time("re-bootstrap" is
> still slow nowadays).
In that case it'd probably be better to make bootstrapping faster rather
than trusting random binaries on the internet. (Unless we grow an
"assemble an image from debs" service on, say, ftp-master.)
Kind regards
Philipp Kern
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 7:21 PM Philipp Kern wrote: > In that case it'd probably be better to make bootstrapping faster rather > than trusting random binaries on the internet. (Unless we grow an > "assemble an image from debs" service on, say, ftp-master.) > We already have such, the cloud image service.(I think these images only include minbase variant, not buildd variant). https://cloud.debian.org/images/cloud/ -- Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
Hi,
shameless plug for mmdebstrap incoming.
Quoting Philipp Kern (2019-10-07 13:21:36)
> On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> > On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
> >> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
> >>> Specifically, currently autopkgtest is limited to providing a read-only
> >>> layer
> >>> for certain backends and its upstream has no intention of widening the
> >>> scope of
> >>> the software [1]. This means that to upgrade an autopkgtest backend, the
> >>> user
> >>> has to apply backend-specific actions
> >> I think "re-bootstrap, don't upgrade" is an equally good principle
> > Why not have a repository for it, like dockerhub. So this becomes
> > "pull latest build env", which saves lots of time("re-bootstrap" is still
> > slow nowadays).
> In that case it'd probably be better to make bootstrapping faster rather
> than trusting random binaries on the internet. (Unless we grow an
> "assemble an image from debs" service on, say, ftp-master.)
creating a working sbuild chroot takes 10 seconds on my system:
$ time mmdebstrap --variant=essential unstable debian-unstable.tar
[...]
mmdebstrap [...] 8.35s user 1.73s system 99% cpu 10.166 total
Do we need to spend engineering effort to become faster than that?
Downloading "random binary from the internet" is less of a problem if we can
create images which are bit-by-bit identical to checksums that we can verify
through a trusted service. This is also already provided by mmdebstrap:
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - |
sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - |
sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
Lastly: yes, maybe "re-bootstrap, don't upgrade" is an equally good principle.
It has the advantage of not accumulating cruft. The sbuild-createchroot command
could gain an option which allows one to replace an existing chroot. Currently,
it refuses to work on already existing chroots.
Thanks!
cheers, josch
signature.asc
Description: signature
Potrzebujesz strony WWW, a nie chcesz zapłacić fortuny za realizację? Sprawdź nas.
Planujesz zmianę swojej *Strony* lub *Sklepu internetowego*? A może interesuje Cię nowy projekt? Jedno jest pewne, trafiłeś w dobre ręce. Odpowiedz do nas maila z informacją* Tak*, a my przygotujemy dla Ciebie bezpłatną wycenę. Nasz Doradca Klienta wytłumaczy Ci sposób działania, po czym zaproponuje optymalne rozwiązania dla Twojego biznesu. _ _ _ Strony i Sklepy WWW na dobrych warunkach!
Re: Debian and our frenemies of containers and userland repos
On 2019-10-07 13:43, Johannes Schauer wrote:
Quoting Philipp Kern (2019-10-07 13:21:36)
On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
>>> Specifically, currently autopkgtest is limited to providing a read-only
layer
>>> for certain backends and its upstream has no intention of widening the
scope of
>>> the software [1]. This means that to upgrade an autopkgtest backend, the
user
>>> has to apply backend-specific actions
>> I think "re-bootstrap, don't upgrade" is an equally good principle
> Why not have a repository for it, like dockerhub. So this becomes
> "pull latest build env", which saves lots of time("re-bootstrap" is still
> slow nowadays).
In that case it'd probably be better to make bootstrapping faster
rather
than trusting random binaries on the internet. (Unless we grow an
"assemble an image from debs" service on, say, ftp-master.)
creating a working sbuild chroot takes 10 seconds on my system:
$ time mmdebstrap --variant=essential unstable debian-unstable.tar
[...]
mmdebstrap [...] 8.35s user 1.73s system 99% cpu 10.166 total
Do we need to spend engineering effort to become faster than that?
I suppose that also depends on deb caching/pipe bandwidth? But yes, I
find that totally fine.
Downloading "random binary from the internet" is less of a problem if
we can
create images which are bit-by-bit identical to checksums that we can
verify
through a trusted service. This is also already provided by mmdebstrap:
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential
unstable - | sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
$ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential
unstable - | sha256sum
[...]
f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6 -
I think that's required, but not sufficient. That still depends on
someone actually verifying this fact and publishing their proofs.
Otherwise you need to do it yourself or risk getting a binary served to
your build process only if not checked interactively[0].
Lastly: yes, maybe "re-bootstrap, don't upgrade" is an equally good
principle.
It has the advantage of not accumulating cruft. The sbuild-createchroot
command
could gain an option which allows one to replace an existing chroot.
Currently,
it refuses to work on already existing chroots.
At work we always regenerate unless when you test multiple times locally
in quick succession. Assuming that the result is not totally wasteful
(e.g. by caching bootstrap debs locally) that seems like a good way to
get predictable local build environments.
Kind regards and thanks
Philipp Kern
[0] It seems to be a standard tool these days to serve exploits only
when the caller looks like the target environment. I.e. if you check the
script you pipe into bash from a browser it looks fine, if you curl it
into bash[1], it looks different.
[1] Yes, it seems like even that case can be identified.
Re: Debian and our frenemies of containers and userland repos
Paul Wise writes ("Re: Debian and our frenemies of containers and userland
repos"):
> On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote:
> > FYI, this is because autopkgtest has an abstraction for multiple
> > container/virtualization mechanisms (lxc, lxd, qemu, schroot)
>
> It seems like this abstraction should be split out of the autopkgtest
> source and then depended on by autopkgtest.
I agree. I was the original designer of this interface and the
original author of autopkgtest. I put the virtualisation abstractions
in src:autopkgtest just because it was convenient, not for any
principled reason. I chose the name pattern "adt-virt-*". I put
"adt" in it to avoid it being too much of a namespace grab, not
because this interface was intended only for the use of autopktest.
I think the current autopkgtest maintainer is not so keen on this
abstraction. I would love it if we could split it out from the
autopkgtest package and I would volunteer to maintain it.
Martin, would such a move have your support ?
> Do any other such abstraction layers exist?
The closest I was aware of at the time was libvirt, which is not
really useable in the same way. I think the interface I designed and
which has subsequently been significantly improved, is a good one, and
we should continue to develop and enhance it.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
ITP: libdata-url-java -- Support for the data protocol as specified in RFC 2397.
Package: wnpp Severity: wishlist Owner: Felix Natter * Package name: libdata-url-java Version : 1.0.1 Upstream Author : Rob Spoor * URL : https://github.com/robtimus/data-url/ * License : Apache-2.0 Programming Lang: Java Description : Support for the data protocol as specified in RFC 2397. The data-url library adds support for the data protocol as specified in RFC 2397. This is a dependency of freeplane-1.7.10. It will be maintained within the java team. Felix Natter
Re: Debian and our frenemies of containers and userland repos
On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote: > I think "re-bootstrap, don't upgrade" is an equally good principle for > autopkgtest and sbuild? Both will be equally susceptible to accumulating > cruft during upgrades that wouldn't have been there in a fresh debootstrap, > which is undesired if you want the invariant that you are (building|testing) > in "today's" minimal environment. debootstrap uses a fair bit more time and resources than apt upgrade, so I think that both are needed. I don't want to be rebuilding sbuild/pbuilder chroots before each package build, but an apt update and upgrade before each build starts installing build-dependencies is reasonable. At work we upgrade build containers interactively if needed, upgrade them automatically daily and rebuild them from scratch weekly, this feels like a reasonable compromise to me. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Summary: Git Packaging Round 2 [comments by 11/05/2019]
This is a summary of discussions we had in August and September around how we want to use salsa. Presented so those involved in the discussion can see if I'm calling consensus correctly and as a last opportunity for others to comment. A few tweaks from my original proposed recommendations. If you were OK with that version you can likely skip this entirely, although I'd appreciate it if you'd search for "HOW YOU CAN HELP" and glance at that section at least. This message focuses on the areas of the original recommendation that received significant comment and includes the current recommendation at the end. As a reminder, this recommendation is purely optional; it is intended to help those looking for best practices or newcomers searching for a recommendation. If it doesn't fit your needs, then find something that does. Discussion Comments Teams * We were reminded at several points that the best practice is to find a team and to maintain your package using their practices. That was always the intent, but I'm proposing to update and clarify this from the top just to be extra clear. Debian Group When no Specific Team ** TL; DR: I think there is consensus behind recommending the Debian group on Salsa when there is not an existing team to use. This consensus is not complete; some disagreed. If after reading the summary people want to have a quick vote, I think that would be fine. In more detail: I proposed that the debian group would be a sensible default if there is not a team project to use. We had a wide ranging discussion. There are two big concerns with the debian group. Technically, any DD has push access to any repository in the group. Also, as Ansgar pointed out, the wiki page [1] says that it is reasonable to commit with no prior discussion. [1]: https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group My original text implied that the Debian group was a lot closer to low-threshhold NMUs than a complete free-for-all. In practice, I think that's true: I think that the actual social conventions that get used in practice are more conservative than the permissions granted technically and by that wiki page. Russ agreed that Debian is a sensible default [2]. Enrico agreed. After re-reading the proposal, Jonas agreed that this was a reasonable recommendation. He would not have supported something stronger like a policy which limited maintainers' flexibility when this recommendation does not meet their needs. [2]: https://lists.debian.org/msgid-search/875zm0or60@hope.eyrie.org Ian Jackson thought that recommending the debian group would be reasonable if we did three things: * Document which maintainer branch format a maintainer is using * Update documentation on when it is reasonable to push to the debian group * document the above David Bremner is uncomfortable with the idea of having all DDs have push access to thousands of packages. He doesn't think we have the social conventions for that. However he said he would be OK with the recommendation if we did as Ian proposed (documenting branch format, documenting when to push). Ansgar argued that documenting the branch format is unnecessary given all the work you need to do to contribute to a package. Several disagreed arguing that it helped them do their work. Bernd Zeimetz argued we didn't need a recommendation. We could just list places people could host with advantages and disadvantages. Matt Zagrabelny and Enrico argued that having specific recommendations lowered the bar to contributing because you did not need to evaluate the advantages and disadvantages for your environment. This is consistent with feedback we received during the dh discussion and during the DPL campaign. (Enrico's message was posted to a related thread on -project, not to debian-devel) Ansgar argued that a recommendation could be harmful because we take a long time to update documentation/recommendations and it would get out of date. Several people pointed out that under that argument we wouldn't have documentation at all. Even if the slope is not that slippery, the arguments about lowering the bar to entry apply here too. However having the recommendation become out of date remains a residual risk. Scott Kitterman is concerned that we are loosening the boundaries of individual responsibility around what it means to be a maintainer too far. He's concerned that if we weaken the maintainer model too much, that everyone will have responsibility. He believes that is the same as no one having responsibility. It became clear in the discussion that the alternative to the debian group is repositories hosted under individual salsa accounts. The debian group is widely used today. It certainly dominates any individual salsa account. It also dominates (at least in terms of vcs-git in unstable) individual (non-team) accounts combined. There are some tea
Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]
On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote: > [...] as a last opportunity for > others to comment. what's the deadline to grok this 20k and respond? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
