On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> older (2020-02-18) toolchain fails to load on an up-to-date sid system, with:
> undefined symbol: __atan2_finite
Because the binary was not linked
On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> older (2020-02-18) toolchain fails to load on an up-to-date sid system, with:
> undefined symbol: __atan2_finite
Because the binary was not linked
On Thu, Jul 16, 2020 at 05:27:40PM -0700, Sean Whitton wrote:
> On Thu 16 Jul 2020 at 05:19PM -07, Sean Whitton wrote:
> > You would need the buggy version of the software if you wanted to
> > make modified versions of the binary data to test for closely related
> > bugs, for example.
And there
On Fri, Jul 17, 2020 at 01:05:18PM +, Paul Littlefield wrote:
> Is there a way to ALLOW (perhaps with header_checks?) these .zip files
> through?
Remove the header check.
Bastian
--
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate
On Thu, Jul 16, 2020 at 08:42:24AM -0700, Sean Whitton wrote:
> I would remove the test data because it does not seem DFSG-conformant.
Care to explain? You can't claim DFSG violation without showing which
part.
Also please explain how you would make sure the code is tested.
Bastian
--
Hi
On Wed, Jul 08, 2020 at 06:23:23PM +0200, Geert Stappers wrote:
> Please let us known what you choose ( IRC , dummy account or friend )
> Letting known "fixed" is also fine.
It's fixed now. I also tried to document the problem in question:
On Tue, Jun 30, 2020 at 12:03:47PM +0200, Ola Lundqvist wrote:
> Does anyone know how to rebase the fork? Or is my way the way to do it?
git remote add upstream $url (once)
git fetch upstream
git checkout -b new-branch upstream/master
git push --set-upstream origin new-branch
> Not to rebase is
Hi Timo
On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote:
> 20.06.20 13:26 Bastian Blank:
> > Since the kernel supports overlayfs since some time now, what blocks
> > it's removal?
> There are Debian installations on filesystems that are incompatible with
> o
Hi Timo
On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote:
> 20.06.20 13:26 Bastian Blank:
> > Since the kernel supports overlayfs since some time now, what blocks
> > it's removal?
> There are Debian installations on filesystems that are incompatible with
> o
Hi Timo
On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote:
> 20.06.20 13:26 Bastian Blank:
> > Since the kernel supports overlayfs since some time now, what blocks
> > it's removal?
> There are Debian installations on filesystems that are incompatible with
> o
On Sun, Jun 28, 2020 at 09:40:12PM +0200, Mattia Rizzolo wrote:
> On Sun, Jun 28, 2020 at 05:32:05PM +0200, Lucas Nussbaum wrote:
> > The importer uses http://duck.debian.net/ which doesn't resolve anymore.
duck.d.n in the past pulled git repositories from salsa.d.o, not sure
what exactly it did
On Sun, Jun 28, 2020 at 09:40:12PM +0200, Mattia Rizzolo wrote:
> On Sun, Jun 28, 2020 at 05:32:05PM +0200, Lucas Nussbaum wrote:
> > The importer uses http://duck.debian.net/ which doesn't resolve anymore.
duck.d.n in the past pulled git repositories from salsa.d.o, not sure
what exactly it did
On Tue, Jun 23, 2020 at 08:21:45AM -0700, Noah Meyerhans wrote:
> OK, that makes sense. Thanks. Can you go ahead and move awscli and
> python-botocore from
> https://salsa.debian.org/python-team/modules/awscli and
> https://salsa.debian.org/python-team/modules/python-botocore to the
> cloud-team
On Tue, Jun 23, 2020 at 08:21:45AM -0700, Noah Meyerhans wrote:
> OK, that makes sense. Thanks. Can you go ahead and move awscli and
> python-botocore from
> https://salsa.debian.org/python-team/modules/awscli and
> https://salsa.debian.org/python-team/modules/python-botocore to the
> cloud-team
On Sat, Jun 20, 2020 at 12:53:01PM -0700, Noah Meyerhans wrote:
> On Sat, Jun 20, 2020 at 08:36:33PM +0200, Bastian Blank wrote:
> > > Thank you. I've forked both of these salsa projects into the cloud-team
> > > namespace. I'll prepare sid uploads adjusting the various pac
On Sat, Jun 20, 2020 at 12:53:01PM -0700, Noah Meyerhans wrote:
> On Sat, Jun 20, 2020 at 08:36:33PM +0200, Bastian Blank wrote:
> > > Thank you. I've forked both of these salsa projects into the cloud-team
> > > namespace. I'll prepare sid uploads adjusting the various pac
On Sat, Jun 20, 2020 at 10:49:24AM -0700, Noah Meyerhans wrote:
> On Thu, Jun 18, 2020 at 03:37:09PM +0900, TANIGUCHI Takaki wrote:
> > I agree your proposal. It's a good idea.
> Thank you. I've forked both of these salsa projects into the cloud-team
> namespace. I'll prepare sid uploads
On Sat, Jun 20, 2020 at 10:49:24AM -0700, Noah Meyerhans wrote:
> On Thu, Jun 18, 2020 at 03:37:09PM +0900, TANIGUCHI Takaki wrote:
> > I agree your proposal. It's a good idea.
> Thank you. I've forked both of these salsa projects into the cloud-team
> namespace. I'll prepare sid uploads
Hi Jan
On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote:
> At the moment aufs is nearly unmaintained since I do not have time due to
> personal issues. Therefore, I would be happy if there is somebody to
> co-maintain the package.
Since the kernel supports overlayfs since some
Hi Jan
On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote:
> At the moment aufs is nearly unmaintained since I do not have time due to
> personal issues. Therefore, I would be happy if there is somebody to
> co-maintain the package.
Since the kernel supports overlayfs since some
Hi Jan
On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote:
> At the moment aufs is nearly unmaintained since I do not have time due to
> personal issues. Therefore, I would be happy if there is somebody to
> co-maintain the package.
Since the kernel supports overlayfs since some
Package: src:squashfs-tools-ng
Version: 1.0.0-1
Severity: normal
The source defines libsquashfs1 (I haven't checked older versions) with
section kernel instead of the correct one libs. This can produce
headaches, as release team tooling and others assign special behaviour
to packages with libs
Package: mig
Version: 1.8-7
Severity: serious
mig mixes two incompatible licenses: GPL and a BSD derivative including
an advertisement clause (included in cpu.sym and message.h):
|and (3) all advertising
| materials mentioning features or use
Package: mig
Version: 1.8-7
Severity: serious
mig mixes two incompatible licenses: GPL and a BSD derivative including
an advertisement clause (included in cpu.sym and message.h):
|and (3) all advertising
| materials mentioning features or use
Package: mig
Version: 1.8-7
Severity: serious
mig mixes two incompatible licenses: GPL and a BSD derivative including
an advertisement clause (included in cpu.sym and message.h):
|and (3) all advertising
| materials mentioning features or use
Package: mig
Version: 1.8-7
Severity: important
mig is a development package. So installing it by default, by virtue of
being defined with priority "standard", is not appropriate. I've
overriden the priority already to "optional". Please fix the package
itself.
Bastian
--
Not one hundred
Package: mig
Version: 1.8-7
Severity: important
mig is a development package. So installing it by default, by virtue of
being defined with priority "standard", is not appropriate. I've
overriden the priority already to "optional". Please fix the package
itself.
Bastian
--
Not one hundred
On Wed, Jun 17, 2020 at 02:37:23PM +0200, Patrick Proniewski wrote:
> For some time now I notice that some messages, either originating from
> Internet or from internal servers are bounced when they arrive on the last
> hop: Exchange.
> Jun 17 12:34:20 postfix-mailgw/smtp[77347]: 57F56EB256:
>
On Tue, Jun 09, 2020 at 02:57:14PM +0200, Thomas Goirand wrote:
> In OpenStack, there's the possibility to rescue instances with a special
> image made for it.
You mean this? https://docs.openstack.org/nova/latest/user/rescue.html
According to the documentation, the default behaviour is to use
On Sat, Jun 06, 2020 at 07:16:59PM +0200, Bastian Blank wrote:
> That's exactly what this change does:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203
Now the remaining question is: GNU or BSD style checksum files?
GNU: "checksum filename"
- No i
On Sat, Jun 06, 2020 at 07:16:59PM +0200, Bastian Blank wrote:
> That's exactly what this change does:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203
Now the remaining question is: GNU or BSD style checksum files?
GNU: "checksum filename"
- No i
On Mon, May 18, 2020 at 11:56:15AM +0200, Thomas Lange wrote:
> I've checked some other distributions in may 2020. They all use hex.
Well, they ship a single file for consumption by "sha512sum", which we
currently don't.
> Maybe provide base64 and hex in our manifest but also sha{265,512}sum
>
On Mon, May 18, 2020 at 11:56:15AM +0200, Thomas Lange wrote:
> I've checked some other distributions in may 2020. They all use hex.
Well, they ship a single file for consumption by "sha512sum", which we
currently don't.
> Maybe provide base64 and hex in our manifest but also sha{265,512}sum
>
On Sat, Jun 06, 2020 at 11:16:42PM +1200, Andrew Ruthven wrote:
> Those are examples, and it notes that the formats available are
> configurable and none of them are specified as "must be available". The
> CLI docs also have a similar note.
> "Disk and container formats are configurable on a
On Wed, May 27, 2020 at 12:16:32PM +0100, kuLa wrote:
> Are you thinking about doing it within FAI or outside of it using new
> tool set for this?
Outside. FAI would in any case only create the directory tree, not the
filesystem is lives in or the image. So what it does would look the
same in
On Thu, Jun 04, 2020 at 01:06:29PM +0200, Thomas Lange wrote:
> >>>>> On Wed, 27 May 2020 12:01:53 +0200, Bastian Blank
> >>>>> said:
> >> Sadly it is not that easy. A whole bunch of temporary data is deleted
> >> in the final
Hi Marcin
On Sun, Apr 26, 2020 at 06:37:38PM +0100, Marcin Kulisz wrote:
> On 2020-04-22 16:35:25, Bastian Blank wrote:
> > What do you mean with "formating"? "GNU/Linux" is now irrelevant.
> But IMO a nice gesture to non Linux parts of our community and costs
Hi Thomas
I clearly does not help that you ignore one my questions several times.
Maybe you want to stop that.
On Wed, May 27, 2020 at 09:43:01AM +0200, Thomas Goirand wrote:
> On 5/26/20 9:26 PM, Bastian Blank wrote:
> > Please show me this existing 512MB image you are talk
On Wed, May 27, 2020 at 10:13:43AM +1200, Andrew Ruthven wrote:
> That may be the case, but not all *backends* can use qcow2 images.
Can you please show OpenStack documentation detailing this all? I fail
to find anything. And if the documentation does not tell clearly, I
have to assume that
On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
> Unfortunately the 250MB limit of artifacts prevent building a pipeline
> with multiple stages like
> create .box from raw -> test -> upload
> as I hit the artifact limit size between each of these stages.
Please take a deeper look
Hi
On Wed, Jun 03, 2020 at 10:40:05AM +0200, Martin Zobel-Helas wrote:
> We might need to explain this to Jonathan: Two or three years back the
> Debian Cloud team agreed on an internal policy during a face-to-face in
> Seattle that delegates should neither be employees of the cloud
> providers
fter the call to tasksel, waagent is not longer installed
and therefor not running. You can install waagent again afterwards.
I don't see a solution right now within the currently existing
constraints of dependencies and recommendations, with the way tasksel
uses apt.
Regards,
Bastian
--
Bastian Blank
B
On Wed, May 27, 2020 at 10:39:01AM +0200, Thomas Lange wrote:
> fai-diskimage has the option -S which specifies the raw disk size. We
> set this in debian_cloud_images/cli/build.py to 2G for genriccloud
> images. It should be easy to set this to maybe 550M.
Sadly it is not that easy. A whole
On Tue, May 26, 2020 at 07:50:26PM -0700, Ross Vandegrift wrote:
> We'd either need to find the common requirements for all providers (eg AWS
> requires 256MiB free), or limit the reduction to the generic images.
Free, when and where? Our file-system grow stuff runs pretty early in
the boot
as artifact on Salsa. Maybe this log will
enlighten you how it is created and stored:
https://salsa.debian.org/cloud-admin-team/debian-cloud-images-daily/-/jobs/765786
Regards,
Bastian Blank
--
Spock: We suffered 23 casualties in that attack, Captain.
On Mon, May 25, 2020 at 02:21:48AM +0200, Thomas Goirand wrote:
> >> So I was wondering if we could:
> >> 1/ Make the resulting extracted disk smaller. That'd be done in FAI, and
> >> I have no idea how that would be done. Thomas, can you help, at least
> >> giving some pointers on how we could
On Sun, May 24, 2020 at 11:26:40PM +0200, Thomas Goirand wrote:
> Currently, our scripts are generating files named for example:
> debian-11-genericcloud-amd64-daily-20200524-273.tar.xz
No, they generate this one:
Hi Reinhard
On Sat, May 23, 2020 at 04:09:42PM -0400, Reinhard Tartler wrote:
> Can you please elaborate on your use-case and ideally demonstrate with a
> minimal testcase? - What kind of namespaces are shared/unshared? The
> command-line looks like it was generated by some other proram. Please
Package: slirp4netns
Version: 1.0.1-1
Severity: important
slirp4netns fails with the following command line:
| /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox
--enable-seccomp -c -e 3 -r 4 --netns-type=path
/run/user/1000/netns/cni-b5f1fc5... tap0
Excerpt from strace
somehow:
- credativ:Debian:9:9.20200210.1
- Debian:debian-10:10:0.20200511.260
I did another publication run to restore them, so they are back now.
Regards,
Bastian
--
Bastian Blank
Berater
Telefon: +49 2166 9901-194
E-Mail: bastian.bl...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
On Thu, May 14, 2020 at 12:56:46PM -0400, Ian Evans wrote:
> As some test suite recommendations might be harsher than what is practical
> I thought I'd check with the people who actually work on Postfix.
The most important question is: are you talking about mandatory or
opportunistic TLS. All
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Consider the following simple case. I'm working on packaging
> amazon-ec2-utils, which I'd like to add to the default installation once
> it's available. To do that today, I'll need to add release specific
> configs to
On Tue, May 05, 2020 at 04:18:36PM -0400, Noah Meyerhans wrote:
> By fallback datasource, you mean "None"?
Yes.
> We could always reintroduce the use of debconf for datasource selection,
> and avoid depending on ds-identify at all. The nice thing about that is
> that we could then pre-fill that
On Tue, May 05, 2020 at 04:18:36PM -0400, Noah Meyerhans wrote:
> By fallback datasource, you mean "None"?
Yes.
> We could always reintroduce the use of debconf for datasource selection,
> and avoid depending on ds-identify at all. The nice thing about that is
> that we could then pre-fill that
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Does this seem sane? Any other ideas?
Nope, it is not really. The daily and release projects needs to use
current tools, without it diverging between the branches.
So we need to split tools and config space then and solve the
Package: cloud-init
Version: 20.1-2
Severity: wishlist
cloud-init does some basic tasks, like
- network config (currently completely shadowed by our own),
- ssh host keys.
I think the most sensible setup would always enable cloud-init, and if
it only runs with the fallback datasource.
Currently
Package: cloud-init
Version: 20.1-2
Severity: wishlist
cloud-init does some basic tasks, like
- network config (currently completely shadowed by our own),
- ssh host keys.
I think the most sensible setup would always enable cloud-init, and if
it only runs with the fallback datasource.
Currently
Hi Thomas
On Fri, Apr 03, 2020 at 11:04:06PM +0200, Thomas Goirand wrote:
> As much as I remember, there was a consensus of everyone against one
> (ie: Bastian himself) that it was ok to build a specific Octavia image.
> At the end of the discussion, either Bastian finally agreed or gave up
>
On Sat, May 02, 2020 at 11:40:52AM +0200, Patrick Proniewski wrote:
> It negates the benefit you were writing about as amavisd-milter will drop the
> message on the milter interface (postfix/cleanup[26401]: 87E5316135:
> milter-discard: END-OF-MESSAGE from localhost[127.0.0.1]: milter triggers
On Thu, Apr 30, 2020 at 11:41:44AM +0200, Bastian Blank wrote:
> The _other_ d-i parts are only looking in the specified directories in
> /usr/lib.
Okay, let's expand on this.
The following directories are part of the API of several d-i components:
- /usr/lib/post-base-installer.d/
- /u
On Thu, Apr 30, 2020 at 11:41:44AM +0200, Bastian Blank wrote:
> The _other_ d-i parts are only looking in the specified directories in
> /usr/lib.
Okay, let's expand on this.
The following directories are part of the API of several d-i components:
- /usr/lib/post-base-installer.d/
- /u
On Thu, Apr 30, 2020 at 11:41:44AM +0200, Bastian Blank wrote:
> The _other_ d-i parts are only looking in the specified directories in
> /usr/lib.
Okay, let's expand on this.
The following directories are part of the API of several d-i components:
- /usr/lib/post-base-installer.d/
- /u
Hi Mattia
On Wed, Apr 29, 2020 at 06:40:07PM +0200, Mattia Rizzolo wrote:
> On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> > ACK. d-i won't be looking in /usr/libexec. Please leave things where
> > they are...
> Good, then @lintian-maint: please exclude udebs from this check :)
Hi Mattia
On Wed, Apr 29, 2020 at 06:40:07PM +0200, Mattia Rizzolo wrote:
> On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> > ACK. d-i won't be looking in /usr/libexec. Please leave things where
> > they are...
> Good, then @lintian-maint: please exclude udebs from this check :)
Hi Mattia
On Wed, Apr 29, 2020 at 06:40:07PM +0200, Mattia Rizzolo wrote:
> On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> > ACK. d-i won't be looking in /usr/libexec. Please leave things where
> > they are...
> Good, then @lintian-maint: please exclude udebs from this check :)
On Sat, Apr 25, 2020 at 07:23:11PM +0100, Adam D. Barratt wrote:
> Please go ahead.
Uploaded.
Bastian
--
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.
On Sat, Apr 25, 2020 at 07:23:11PM +0100, Adam D. Barratt wrote:
> Please go ahead.
Uploaded.
Bastian
--
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.
On Wed, Apr 29, 2020 at 02:00:05PM +0300, EoflaOE wrote:
> * Package name: core-setup
core-setup is pretty generic as name. Please rename it to something
more descriptive. I don't now if the dotnet stuff got a naming schema.
Bastian
--
There's a way out of any cage.
--
On Wed, Apr 29, 2020 at 02:00:05PM +0300, EoflaOE wrote:
> * Package name: core-setup
core-setup is pretty generic as name. Please rename it to something
more descriptive. I don't now if the dotnet stuff got a naming schema.
Bastian
--
There's a way out of any cage.
--
On Wed, Apr 29, 2020 at 02:00:05PM +0300, EoflaOE wrote:
> * Package name: core-setup
core-setup is pretty generic as name. Please rename it to something
more descriptive. I don't now if the dotnet stuff got a naming schema.
Bastian
--
There's a way out of any cage.
--
On Tue, Apr 28, 2020 at 02:32:55PM +0200, Bernd Zeimetz wrote:
> If you use ssh, you can create an own account for the ssh key and give
> it very special permissions, if you need it for automatic pushes or
> similar things.
Or add it as writable deploy key to a project.
Bastian
--
I'm a
On Wed, Apr 22, 2020 at 02:19:48PM -0400, list+deb...@dishaw.org wrote:
> It appears that a Debian AMI released by the Debian cloud team does not exist
> on AWS GovCloud. While several options are provided in the AWS GovCloud
> Marketplace by commercial vendors, having an AMI provided by the
On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.
No, we don't enforce 2FA for everybody. And I don't consider it
appropriate to raise the option.
However, you may choose to enforce 2FA for all users of your groups.
Regards,
Hi Luca
On Mon, Apr 20, 2020 at 10:19:22AM +, Luca Boccassi wrote:
> Azure VMs can get accelerated networking for DPDK applications via the
> NETVSC driver (https://doc.dpdk.org/guides/nics/netvsc.html), but this
> requires enabling the Infiniband kernel modules.
I have to say, I'm not so
Hi Luca
On Mon, Apr 20, 2020 at 10:19:22AM +, Luca Boccassi wrote:
> Azure VMs can get accelerated networking for DPDK applications via the
> NETVSC driver (https://doc.dpdk.org/guides/nics/netvsc.html), but this
> requires enabling the Infiniband kernel modules.
I have to say, I'm not so
Hi Bernd
On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
> On 4/18/20 11:33 PM, Bastian Blank wrote:
> > You are encouraged to use Salsa as an authentication provider for Debian
> > services. GitLab supports plain OAuth2 and OpenID Connect as
> > authentiat
Package: grub-efi-amd64-signed
Version: 1+2.04+5
Severity: grave
grub-efi-amd64-signed got a strict = dependency on grub-common, but
those packages are from different source packages. This makes this
package uninstallable.
| The following information may help to resolve the situation:
|
| The
Package: grub-efi-amd64-signed
Version: 1+2.04+5
Severity: grave
grub-efi-amd64-signed got a strict = dependency on grub-common, but
those packages are from different source packages. This makes this
package uninstallable.
| The following information may help to resolve the situation:
|
| The
On Mon, Apr 20, 2020 at 07:57:19PM -0400, Noah Meyerhans wrote:
> Product title: For older releases, the title is listed as (e.g.) "Debian
> GNU/Linux 9 (Stretch)". For buster, it is "Debian 10 Buster". I prefer
> the formating used for stretch, and would like to update buster to
> match.
What
Hi Luca
On Wed, Apr 08, 2020 at 03:18:58PM +, Luca Filipozzi wrote:
> > - Salsa, how should it work together.
> Gitlab can use OIDC as an OmniAuth provider.
And here the problems begin.
Sure, just using it as OmniAuth provider works. But this only provides
authentication.
But, as Sam
Hi Zhu
On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?
No. The guest suffix was meant to avoid collisions with Debian
accounts. And the tool used to enforce it is
Hi Paul
On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote:
> It sounds like the answer is no, but does Salsa, Keycloak or
> LemonLDAP::NG support TLS client certs?
No, Salsa does not support TLS client certs.
> So it sounds like Debian would be switching our SSO authentication
>
Hi Luca
On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> That said, please consider an approach that would see keycloak used as
> an idenitity broker, allowing external users to create accounts using
> social identities that are then promoted to full Debian identities (in
> LDAP)
Dear Debian fellows
Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
following plan. At the same time we declare the following services as EOL:
- sso.debian.org and
- parts of the Salsa self service interface.
We asked DPL, NM, DSA and the Salsa admins already for
Package: cloud-init
Version: 20.1-X
Severity: important
Currently running debian/rules clean from git repository fails:
| % ./debian/rules clean
| py3versions: no X-Python3-Version in control file, using supported versions
| dh clean --with python3,systemd --buildsystem pybuild
|
Package: cloud-init
Version: 20.1-X
Severity: important
Currently running debian/rules clean from git repository fails:
| % ./debian/rules clean
| py3versions: no X-Python3-Version in control file, using supported versions
| dh clean --with python3,systemd --buildsystem pybuild
|
On Fri, Apr 03, 2020 at 09:32:01AM +0200, Emmanuel Kasper wrote:
> IIRC Digital Ocean and AWS have it, but for instance Vultr does not.
- DO
- AWS
- Azure
- Google on request
(https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances)
Bastian
--
Vulcans
Package: src:haproxy
Severity: serious
Mail to the maintainer address hapr...@tracker.debian.org bounces:
| host ticharich.debian.org [2607:f8f0:614:1::1274:64]
| SMTP error from remote mail server after RCPT
TO::
| 550 Unrouteable address
Do you mean
Package: src:haproxy
Severity: serious
Mail to the maintainer address hapr...@tracker.debian.org bounces:
| host ticharich.debian.org [2607:f8f0:614:1::1274:64]
| SMTP error from remote mail server after RCPT
TO::
| 550 Unrouteable address
Do you mean
Package: shim-helpers-amd64-signed
Version: 1.33+15+1533136590.3beb971-7
Severity: grave
Binary packages in shim-signed and shim-unsigned have = dependencies,
leading to them being uninstallable:
| The following information may help to resolve the situation:
|
| The following packages have
Package: shim-helpers-amd64-signed
Version: 1.33+15+1533136590.3beb971-7
Severity: grave
Binary packages in shim-signed and shim-unsigned have = dependencies,
leading to them being uninstallable:
| The following information may help to resolve the situation:
|
| The following packages have
On Mon, Mar 23, 2020 at 01:04:44PM -0500, Ranjan Maitra wrote:
> So, I am wondering if I it is possible to have a setup whereby postfix is
> delayed unless/until VPN is up and running. If VPN is down, then I would like
> postfix to be delayed until such time as it comes up. If it is possible,
Control: reassign -1 debian-cloud-images
Control: severity -1 minor
Control: tags -1 ipv6,help
Hi Bas
On Fri, Mar 20, 2020 at 09:00:08AM +0100, Bas Zoetekouw wrote:
> On these machines, ipv6 is disabled by setting
> /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1. This causes the network
> to
Control: reassign -1 debian-cloud-images
Control: severity -1 minor
Control: tags -1 ipv6,help
Hi Bas
On Fri, Mar 20, 2020 at 09:00:08AM +0100, Bas Zoetekouw wrote:
> On these machines, ipv6 is disabled by setting
> /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1. This causes the network
> to
Package: cloud-init
Version: 20.1-1
Severity: serious
cloud-init 20.1-1 fails to provision Azure:
| 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in
Package: cloud-init
Version: 20.1-1
Severity: serious
cloud-init 20.1-1 fails to provision Azure:
| 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in
Package: cloud-init
Version: 20.1-1
Severity: serious
cloud-init 20.1-1 fails to provision Azure:
| 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in
Source: igraph
Version: 0.8.0-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: ftpmas...@debian.org
debian/copyright on igraph is incomplete. Examples:
- src/drl_layout_3d.cpp (BSD-3)
- src/CHOLMOD/Modify/cholmod_rowdel.c (Timothy A. Davis)
Please verify the whole copyright status.
Source: igraph
Version: 0.8.0-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: ftpmas...@debian.org
debian/copyright on igraph is incomplete. Examples:
- src/drl_layout_3d.cpp (BSD-3)
- src/CHOLMOD/Modify/cholmod_rowdel.c (Timothy A. Davis)
Please verify the whole copyright status.
Source: runit
Version: 2.1.2-35
Severity: critical
An installation attempt on a default system (with recommends enabled) of
runit wants to replace the installed init:
| $ sudo apt install runit
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| The
1101 - 1200 of 14587 matches
Mail list logo
