Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work

2020-09-08 Thread Bastian Blank
Control: reassign -1 src:nvidia-graphics-drivers-legacy-390xx

On Tue, Sep 08, 2020 at 02:14:54PM +0200, Vincent Lefevre wrote:
> Sep 08 13:31:20 zira systemd-modules-load[408]: Error running install command 
> 'modprobe nvidia-modeset ; modprobe -i nvidia-legacy-390xx-drm ' for module 
> nvidia_drm: retcode 1

No module called nvidia-legacy-390xx-drm is shipped with the kernel.  So
no bug here.  I re-assigned the bug to the hopefully correct package.

Bastian

-- 
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3



Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work

2020-09-08 Thread Bastian Blank
Control: tag -1 moreinfo
Control: severity -1 important

On Tue, Sep 08, 2020 at 01:36:45PM +0200, Vincent Lefevre wrote:
> This version fails to load kernel modules (no issues with previous
> Linux kernels provided by Debian). As a consequence, X does not work.

> ** Loaded modules:
> rfcomm
> ipt_REJECT

Your system have a lot of loaded modules.  Please provide the real error
message.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6



Bug#968940: linux: please add patch to support virtualbox on kernel 5.8

2020-08-24 Thread Bastian Blank
Control: severity -1 important

On Mon, Aug 24, 2020 at 12:11:08PM +0200, Gianfranco Costamagna wrote:
> Hello, as explained on upstream ticket [1], the new kernel broke virtualbox, 
> and the only fix that has been found
> so far is to export map_kernel_range and __get_vm_area_caller to modules

Please talk to linux upstream.

Bastian

-- 
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
   stardate 3417.3



Bug#964812: linux: Pulling Google Compute Engine Virtual Ethernet Driver into Debian

2020-08-12 Thread Bastian Blank
Hi Zach

On Tue, Aug 11, 2020 at 01:26:42PM -0700, Zach Marano wrote:
> Yes there is a feature on the image resource which will (currently) enable
> the device instead of virtio-net. If you add the "GVNIC" guestOS feature to
> and image or disk resource it will do this.
> https://cloud.google.com/compute/docs/instances/create-vm-with-gvnic#manual-gvnic-setup

Thanks.  Will try to test that.

Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4



Bug#964812: linux: Pulling Google Compute Engine Virtual Ethernet Driver into Debian

2020-08-04 Thread Bastian Blank
Hi David

On Fri, Jul 10, 2020 at 06:21:14PM +, David Awogbemila wrote:
> Google would like to have its cloud networking driver, the Google
> Compute Engine Virtual Ethernet driver (GVE) pulled into Debian
> releases.

I'm just working on this.  Is there a way for me to actually test it?  I
assume I need to either specify some magic flag or be whitelisted to use
this feature.

Bastian

-- 
Live long and prosper.
-- Spock, "Amok Time", stardate 3372.7



Bug#908908: turn lvm2-dbusd Architecture: all

2020-08-02 Thread Bastian Blank
Hi Helmut

On Sun, Aug 02, 2020 at 07:25:50PM +0200, Helmut Grohne wrote:
> On Sun, Aug 02, 2020 at 06:15:39PM +0200, Bastian Blank wrote:
> > https://salsa.debian.org/lvm-team/lvm2/-/compare/master...lvmdbusd-arch-all
> Thank you very much for sitting down and implementing this.
> This looks good to me. It definitely solves the problem that I reported.
> I do like your technique of doing multi-flavour builds with debhelper.

It solves on thing that does not really survive the sniff test:
configuring the build differently between all-only and any+all.  While
it does not produce any differences right now, this might change in the
future and will be really hard to detect, as at least I don't do both
kinds of builds.

Regards,
Bastiaqn

-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7



Bug#908908: turn lvm2-dbusd Architecture: all

2020-08-02 Thread Bastian Blank
On Fri, Jul 31, 2020 at 05:59:48PM +0200, Helmut Grohne wrote:
> Beyond that, https://bootstrap.debian.net/botch-native/amd64/stats.html
> reports src:lvm2 -> python3-pyudev as a strong bridge.

I have no idea how to read that, but okay.

> Trust me, the python bindings need to be droppable for lvm2. I gave you
> a simple solution. I fear using build profiles will be slightly more
> complex. Do you prefer that?

I have an even more complex variant, also making lvm2-dbusd arch-all and
drop the build-deps for that.

https://salsa.debian.org/lvm-team/lvm2/-/compare/master...lvmdbusd-arch-all

Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7



Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

2020-07-29 Thread Bastian Blank
On Tue, Jul 28, 2020 at 12:33:48PM -0400, Noah Meyerhans wrote:
> Jul 28 16:14:54 debian systemd-growfs[271]: Partition size 8455699968 is not 
> a multiple of the blocksize 4096, ignoring 3584 bytes

That's normal, we may fix the initramfs grow stuff to make better
decisions.

> Jul 28 16:14:54 debian systemd-growfs[271]: Failed to resize "/" to 2064379 
> blocks (ext4): Read-only file system

This is weird.  systemd-growfs@.service waits for the real mount, at
least on any systemd versions I looked at:

| # /run/systemd/generator/systemd-growfs@-.service
| # Automatically generated by systemd-fstab-generator
| 
| [Unit]
| BindsTo=%i.mount
| After=%i.mount
| Before=shutdown.target local-fs.target

So it is an artefact of Debian being the only distro still starting the
real system with a read-only / (and with that making using first-boot
mode impossible).

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown



Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

2020-07-29 Thread Bastian Blank
On Tue, Jul 28, 2020 at 03:40:14PM -0700, Noah Meyerhans wrote:
> Actually, the problem seems to have been caused by
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/192/
> Prior to that MR, we weren't using systemd-growfs at all.

Prior to that we did not have any grow capability at all in several
setup, so reverting is not really an option.

> I've confirmed impact on amd64 instances as well as the arm64 instances
> on which originally observed it.  It also seems like this could impact
> our images on other cloud services besides Amazon EC2, but I haven't
> tested there.

I'll take a look later.  None of the instances I tested showed this
behaviour.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#908908: turn lvm2-dbusd Architecture: all

2020-07-26 Thread Bastian Blank
Hi Helmut

On Sat, Sep 15, 2018 at 09:01:02PM +0200, Helmut Grohne wrote:
>  * There is a longer dependency cycle between lvm2 (via systemd) through
>python3. Turning lvm2-dbusd Architecture: all means that all of the
>python depends can be moved to Build-Depends-Indep solving the cycle.

There is a clear build-dep cycle between lvm2 and systemd, via
cryptsetup.  Not sure what a possible cycle via python3 would be.

>  * We save approximately 450kb of mirror space. ;)

By making building way more complex, sure.

Bastian

-- 
Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1



Bug#859388: Bug#908908: lvm2 NMU

2020-07-26 Thread Bastian Blank
Control: tags -1 - pending

On Sun, Jul 26, 2020 at 07:21:38AM +0200, Helmut Grohne wrote:
> I've prepared a NMU fixing these long-standing bugs with patches. Thanks
> to all the contributors. I've uploaded it to delayed/15. Please let me
> know if I should defer it any longer. I'm attaching a .debdiff of the
> proposed changes.

Don't.  At least in this form.

> diff --minimal -Nru lvm2-2.03.07/debian/.gitignore 
> lvm2-2.03.07/debian/.gitignore
> --- lvm2-2.03.07/debian/.gitignore2020-01-07 14:46:03.0 +0100
> +++ lvm2-2.03.07/debian/.gitignore1970-01-01 01:00:00.0 +0100
> @@ -1,8 +0,0 @@
> -/autoreconf.*
> -/debhelper*
> -/files
> -/*.debhelper
> -/*.log
> -/*.substvars
> -/*/
> -!/bin/

.gitignore is git metadata.  How does this relate to anything?

> diff --minimal -Nru lvm2-2.03.07/debian/control lvm2-2.03.07/debian/control
> --- lvm2-2.03.07/debian/control   2020-01-07 14:46:03.0 +0100
> +++ lvm2-2.03.07/debian/control   2020-07-18 20:53:01.0 +0200
> @@ -5,7 +5,6 @@
>  Uploaders: Bastian Blank 
>  Build-Depends:
>   debhelper (>= 10.9.2),
> - dh-python,

Needed by python packages.

> @@ -59,8 +60,8 @@
>   regular block devices.
>  
>  Package: lvm2-dbusd
> -Architecture: linux-any
> -Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}, lvm2 (= 
> ${binary:Version}), dbus,
> +Architecture: all
> +Depends: ${python3:Depends}, ${misc:Depends}, lvm2 (>= ${source:Version}), 
> lvm2 (<< ${source:Version}.1), dbus,

Err, no hacks in dependencies.

> diff --minimal -Nru lvm2-2.03.07/debian/rules lvm2-2.03.07/debian/rules
> --- lvm2-2.03.07/debian/rules 2020-01-07 14:46:03.0 +0100
> +++ lvm2-2.03.07/debian/rules 2020-07-18 20:53:01.0 +0200
> @@ -27,7 +27,8 @@
>  endif
>  
>  %:
> - dh $@ --parallel --with python3
> + dh $@ --parallel $(DH_ADDONS)
> +build binary %-indep: DH_ADDONS+=--with=python3

No.

Bastian

-- 
Love sometimes expresses itself in sacrifice.
-- Kirk, "Metamorphosis", stardate 3220.3



Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm

2020-07-24 Thread Bastian Blank
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 with -lm, the linker never saw the
real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
to __atan2_finite.  At least dpkg-shlibdeps or so should warn about that.

> I've been trying to put together a standalone reproducer that only uses
> libdl and libm, but so far I have not been successful.

Something like that?

| % cat test.c 
| void __atan2_finite(void);
| void test(void) {
|   __atan2_finite();
| }
| % gcc --shared -o test.so test.c -Wall -W
| % objdump -x test.so | grep atan 
|  *UND*   __atan2_finite

Regards,
Bastian

-- 
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8



Bug#963191: RFH: aufs

2020-06-29 Thread Bastian Blank
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 
> overlayfs, for example xfs without d_type.
> I ran into this while trying to get rid of aufs.

So we need to document this problem in the release notes.  That's an
easy task.

Regards,
Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-28 Thread Bastian Blank
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 with them.  However it stopped pulling at least
three months ago.

>  * it turns out said code was not freely license and as such easily
>usable by a new maintainer in a new deployment

Nice, not really.

> Baptiste (CCed) volunteered to write it over again, but for now there is
> no clear timeline as for when the new project will be started.

Maybe you could add that to vcswatch?

Regards,
Bastian

-- 
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4



Bug#963191: RFH: aufs

2020-06-20 Thread Bastian Blank
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 time now, what blocks
it's removal?

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#963155: libsquashfs1 - Wrong Section: kernel

2020-06-19 Thread Bastian Blank
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 as section.

Also libsquashfs-dev should be libdevel.

Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#963090: mig - Undistributable (GPL + advertisement clause)

2020-06-18 Thread Bastian Blank
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 of this software display the following
| acknowledgement: ``This product includes software developed by the
| Computer Systems Laboratory at the University of Utah.''

See https://www.gnu.org/licenses/license-list.html#OriginalBSD

Bastian

-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4



Bug#963089: mig - Set priority to optional

2020-06-18 Thread Bastian Blank
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 percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8



Bug#932943: hex or base64

2020-06-06 Thread Bastian Blank
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 information which type, so filename need to show.
- Different types in different files.

BSD: "type (file) = checksum"
- Can contain different checksums for the same file.
- The *sum tools from coreutils read only the one exact variant.

Regards,
Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!



Bug#932943: hex or base64

2020-06-06 Thread Bastian Blank
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
> hex files in the download directory on our server (petterson).

That's exactly what this change does:

https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203

Regards,
Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0



Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

2020-05-23 Thread Bastian Blank
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 
> elaborate.

In the meantime I found out that it works in some cases.

I today tried some new stuff:
- podman (https://github.com/containers/libpod)
- usernetes (https://github.com/rootless-containers/usernetes)

With podman slirp4netns broke with the mentioned error.  With
rootlesskit, used by usernetes, it seems to work.  Let's see if I manage
to look again.

Bastian

-- 
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8



Bug#961363: slirp4netns - Fails on Linux 5.5: enable_seccomp failed

2020-05-23 Thread Bastian Blank
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 output:

| prctl(PR_CAPBSET_DROP, CAP_BLOCK_SUSPEND) = 0
| prctl(PR_CAPBSET_DROP, CAP_AUDIT_READ)  = 0
| prctl(PR_CAPBSET_DROP, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
| capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, 
{effective=1<

Bug#959486: cloud-init - Enable fallback data source if nothing is detected in ds-identify

2020-05-09 Thread Bastian Blank
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 answer in our cloud images and
> configure an explicit datasource there, too.
> (Note that I don't actually *like* the idea of reintroducing debconf...)

Well, this would require us to disable all network based datasource by
default, so no more EC2 or network-only-openstack.

My plan was just to make sure cloud-init does minimal setup all the
time, not to break the already working cases.

Bastian

-- 
"Beauty is transitory."
"Beauty survives."
-- Spock and Kirk, "That Which Survives", stardate unknown



Bug#959486: cloud-init - Enable fallback data source if nothing is detected in ds-identify

2020-05-02 Thread Bastian Blank
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 we are using ds-identify.  This tools does not have any way to
only enable the fallback data source.

Any ideas?

Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
pn  cloud-guest-utils   
ii  fdisk   2.34-0.1
ii  gdisk   1.0.5-1
ii  ifupdown0.8.35+b1
ii  locales 2.30-4
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.16-4
ii  python3 3.8.2-3
ii  python3-configobj   5.0.6-4
ii  python3-jinja2  2.10.1-2
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-oauthlib
ii  python3-requests2.23.0+dfsg-2
ii  python3-six 1.14.0-3
ii  python3-yaml5.3.1-1+b1
ii  util-linux  2.34-0.1

Versions of packages cloud-init recommends:
pn  cloud-guest-utils  
ii  eatmydata  105-7
ii  sudo   1.8.31p1-1

Versions of packages cloud-init suggests:
ii  btrfs-progs  5.6-1
ii  e2fsprogs1.45.6-1
ii  xfsprogs 5.4.0-1+b1



Bug#959037: lintian: FPOS? for executable-in-usr-lib

2020-04-30 Thread Bastian Blank
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/
- /usr/lib/pre-pkgsel.d/

The same is e.g. true for /usr/lib/apt/ (okay, maybe this was extended
to include /usr/libexec/apt/ as well in the meantime).

It is however irrelevant if this API is provided by a deb or udeb.  You,
as user of this API, can't just move a file from /usr/lib/x to
/usr/libexec/x and expect it to continue working.  This is an API
transition and needs to be coordinated.

I would assume this tag is in the pedantic pile for a reason:  You can't
just run, but need to think about it.

Bastian

-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3



Bug#959037: lintian: FPOS? for executable-in-usr-lib

2020-04-30 Thread Bastian Blank
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 :)
> (as I think used to be in the past, since I don't think I saw this tag
> years ago in this package, but I know it has been there for a while…)

Why?  The tag is completely correct.

The _other_ d-i parts are only looking in the specified directories in
/usr/lib.

Bastian

-- 
But Captain -- the engines can't take this much longer!



Bug#955547: buster-pu: package waagent/2.2.45-4~deb10u1

2020-04-30 Thread Bastian Blank
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.



Bug#959099: RFP: core-setup -- Helper library for MSbuild .NET Core support

2020-04-29 Thread Bastian Blank
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.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.



Bug#958300: linux: enable infiniband kconfig in cloud images for Azure/HyperV

2020-04-26 Thread Bastian Blank
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 sure this is actually the same thing.  This
linked documentation shows how to use DPDK on top of the netsvc device,
using uio_hv_generic.

What you are talking about is using DPDK on the Mellanox card, which is
documented here:
https://doc.dpdk.org/guides/nics/mlx4.html
https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk

This requires the following modules:
- mlx4_ib
- ib_uverbs

Regards,
Bastian

-- 
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4



Bug#958722: grub-efi-amd64-signed - Uninstallable

2020-04-24 Thread Bastian Blank
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 following packages have unmet dependencies:
|  grub-efi-amd64-signed : Depends: grub-common (= 2.04-6) but it is not going 
to be installed
| E: Unable to correct problems, you have held broken packages.

Please fix this by removing those strict dependency or move both
packages into a single source package.

Bastian


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#955620: cloud-init - debian/rules clean fails from git repo

2020-04-03 Thread Bastian Blank
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
|dh_auto_clean -O--buildsystem=pybuild
| I: pybuild base:217: python3.7 setup.py clean
| Traceback (most recent call last):
|   File "setup.py", line 293, in 
| version=get_version(),
|   File "setup.py", line 85, in get_version
| (ver, _e) = tiny_p(cmd)
|   File "setup.py", line 50, in tiny_p
| (cmd, ret, out, err))
| RuntimeError: Failed running ['/usr/bin/python3.7', 'tools/read-version'] 
[rc=1] (, git describe version (0.7.9-145-g12042ee9) differs from 
cloudinit.version (20.1)
| Please get the latest upstream tags.
| As an example, this can be done with the following:
| $ git remote add upstream https://git.launchpad.net/cloud-init
| $ git fetch upstream --tags
| )
| E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=1: 
python3.7 setup.py clean
| dh_auto_clean: error: pybuild --clean --test-nose -i python{version} -p "3.7 
3.8" returned exit code 13
| make: *** [debian/rules:7: clean] Error 13

Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
ii  fdisk   2.34-0.1
ii  gdisk   1.0.5-1
pn  ifupdown
ii  locales 2.30-2
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.16-4
ii  python3 3.8.2-2
pn  python3-configobj   
ii  python3-jinja2  2.10.1-2
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-oauthlib
ii  python3-requests2.22.0-2
ii  python3-six 1.14.0-2
ii  python3-yaml5.3.1-1
ii  util-linux  2.34-0.1

Versions of packages cloud-init recommends:
pn  cloud-guest-utils  
pn  eatmydata  
ii  sudo   1.8.31p1-1

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.45.6-1
pn  xfsprogs 



Bug#955553: haproxy - unreachable maintainer

2020-04-02 Thread Bastian Blank
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 team+hapr...@tracker.debian.org?

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#955356: shim-signed-* - Uninstallable

2020-03-30 Thread Bastian Blank
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 unmet dependencies:
|  shim-helpers-amd64-signed : Depends: shim-unsigned (= 
15+1533136590.3beb971-7) but 15+1533136590.3beb971-8 is to be installed
| E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

Please fix this by removing those strict dependencies or move into a
single source package.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.



Bug#954321: in the Debian AWS-images cloud-init network fails if ipv6 is disabled

2020-03-20 Thread Bastian Blank
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 fail:

No, our AWS images don't use disable_ipv6.  If you modify this setting,
you of course need to adopt the network config to cope with it.

Please provide a patch if you think we can do better.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown



Bug#954276: cloud-init - RuntimeError: dictionary keys changed during iteration

2020-03-19 Thread Bastian Blank
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 
_run_modules
| ran, _r = cc.run(run_name, mod.handle, func_args,
|   File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
| return self._runners.run(name, functor, args, freq, clear_on_fail)
|   File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 185, in run
| results = functor(*args)
|   File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", 
line 129, in handle
| update_disk_setup_devices(disk_setup, cloud.device_name_to_device)
|   File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", 
line 166, in update_disk_setup_devices
| for origname in disk_setup.keys():
| RuntimeError: dictionary keys changed during iteration

Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
pn  cloud-guest-utils   
ii  fdisk   2.34-0.1
ii  gdisk   1.0.5-1
pn  ifupdown
ii  locales 2.29-10
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.15-2+b1
ii  python3 3.7.5-3
pn  python3-configobj   
ii  python3-jinja2  2.10.1-2
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-oauthlib
ii  python3-requests2.22.0-2
ii  python3-six 1.14.0-2
ii  python3-yaml5.3-2
ii  util-linux  2.34-0.1

Versions of packages cloud-init recommends:
pn  eatmydata  
ii  sudo   1.8.31-1

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.45.5-2
pn  xfsprogs 



Bug#953941: igraph - Incomplete debian/copyright

2020-03-14 Thread Bastian Blank
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.

Bastian

-- 
Bones: "The man's DEAD, Jim!"



Bug#953875: runit - default installation wants to remove systemd

2020-03-14 Thread Bastian Blank
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 following packages were automatically installed and are no longer 
required:
|   libargon2-1 libc-ares2 libcryptsetup12 nodejs-doc systemd
| Use 'sudo apt autoremove' to remove them.
| The following additional packages will be installed:
|   initscripts insserv runit-sysv startpar sysuser-helper sysv-rc sysvinit-core
| Suggested packages:
|   bootchart2 bootlogd
| The following packages will be REMOVED:
|   libpam-systemd systemd-sysv
| The following NEW packages will be installed:
|   initscripts insserv runit runit-sysv startpar sysuser-helper sysv-rc 
sysvinit-core
| 0 upgraded, 8 newly installed, 2 to remove and 0 not upgraded.
| Need to get 563 kB of archives.
| After this operation, 639 kB of additional disk space will be used.

This is obviously not something a random user wants to do and have a
large probability of destroying the system beyond repair.

Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#950079: grub-cloud-amd64: prompting due to modified conffiles which were not modified by the user: /etc/default/grub

2020-02-17 Thread Bastian Blank
Control: severity -1 important

On Tue, Jan 28, 2020 at 09:25:28PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action. As there is no user input, this fails.
> But this is not the real problem, the real problem is that this prompt
> shows up in the first place, as there was nobody modifying this conffile
> at all, the package has just been installed and upgraded...

This is actually ucf vs conffile in different packages.

> This is a violation of policy 10.7.3, see
> https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
> which says "[These scripts handling conffiles] must not ask unnecessary
> questions (particularly during upgrades), and must otherwise be good
> citizens."

But this is about conffiles, not scripts.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown



Bug#950167: Acknowledgement (icinga2-bin - Racy timeout in API: No data received on new API connection)

2020-01-29 Thread Bastian Blank
Hi

It seems like I found a workaround: hard disable TLS 1.3 in OpenSSL:

/etc/ssl/openssl.conf:
| [system_default_sect]
| MinProtocol = TLSv1.2
| MaxProtocol = TLSv1.2
| CipherString = DEFAULT@SECLEVEL=2

Bastian

-- 
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4



Bug#950167: icinga2-bin - Racy timeout in API: No data received on new API connection

2020-01-29 Thread Bastian Blank
Package: icinga2-bin
Version: 2.10.3-2
Severity: important

Hi

I upgraded the master and one satelite of a larger Icinga2 setup to
Buster.  After the upgrade those two instances where unable to establish
a working API connection.  Connections between the new master and the
Stretch instances still works fine.

API connections between two Icinga2 2.10.3-2 instances fail with
timeout:

| Jan 29 18:27:11 X icinga2[10213]: [2020-01-29 18:27:11 +] 
information/ApiListener: New client connection for identity 'Y' from 
[2001:db8::1]:53626
| Jan 29 18:27:21 X icinga2[10213]: [2020-01-29 18:27:21 +] 
warning/ApiListener: No data received on new API connection for identity 'Y'. 
Ensure that the remote endpoints are properly configured in a cluster setup.
| Jan 29 18:27:21 X icinga2[10213]: Context:
| Jan 29 18:27:21 X icinga2[10213]: (0) Handling new API client 
connection

During this time the client should send an "icinga::Hello" message.
Wireshark confirms that packets (in TLS 1.3) are flowing and arriving on
the other side.  But the Icinga2 core seems to be unable to receive
them.

The problem disappears if I start icinga2 by hand or with debug log
level on the passive side of the API connection.  With notice log level
it get less frequent.

I haven't tested anything newer yet.

Regards,
Bastian

-- System Information:
Debian Release: buster
Architecture: amd64 (x86_64)



Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Bastian Blank
On Wed, Jan 29, 2020 at 05:06:31PM +0100, Svante Signell wrote:
> * E) systemd is not available on non-Linux

- You don't need an alternative for something that does not exist.
- Have you ever tried to build those parts of the systemd package on
  your favorite glibc non-Linux?

Bastian

-- 
There's another way to survive.  Mutual trust -- and help.
-- Kirk, "Day of the Dove", stardate unknown



Bug#949788: s390-dasd FTCBFS: strips with the build architecture strip

2020-01-24 Thread Bastian Blank
Moin

On Sat, Jan 25, 2020 at 05:50:40AM +0100, Helmut Grohne wrote:
> s390-dasd fails to cross build from source, because it strips using the
> build architecture strip during build. Beyond breaking cross
> compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
> generation of -dbgsym packages. It is best to defer all stripping to
> dh_strip. Please consider applying the attached patch.

This is the wrong fix.  Take a look at the Makefile.

Bastian

-- 
Time is fluid ... like a river with currents, eddies, backwash.
-- Spock, "The City on the Edge of Forever", stardate 3134.0



Bug#948041: impossible to update libbpf without updating the kernel

2020-01-18 Thread Bastian Blank
On Wed, Jan 15, 2020 at 12:50:16PM +, Sudip Mukherjee wrote:
> On Wed, Jan 15, 2020 at 06:12:05AM +, Jonathan Nieder wrote:
> > I agree --- if upstream development were happening in
> > https://github.com/libbpf/libbpf then this would be a no-brainer.  It
> > appears to instead be a mirror of the source that's in the kernel
> > repo, though.
> That will be difficult as all of them are dependent on the ftrace hooks
> that are in the kernel.

What will be difficult?

> > > Why should we switch from kernel sources to GH is a frequently asked
> > > question so the reason was explained in libbpf README [1].

Let's go through it one by one.

"Consistent versioning across distributions."

Maybe, but the kernel is also versioned consistently.

"No ties to any specific kernel, transparent handling of older kernels."

What?  Either they are upstream for it or patch the source.  But this
point means it can't be a direct mirror.  So what is it?

"Continuous integration testing via TravisCI."
"Static code analysis via LGTM and Coverity."

Both are not restricted to this repo.

> > If I'm reading that correctly, the intent appears to be that it would
> > allow faster libbpf upgrades.
> Yes, one of my intent. Faster and independent.

And how does it do that, without being upstream of the source?

Sorry, but I intend to end this discussion here.

Bastian

-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3



Bug#948041: impossible to update libbpf without updating the kernel

2020-01-12 Thread Bastian Blank
Hi Sudip

On Sun, Jan 12, 2020 at 12:28:20AM +, Sudip Mukherjee wrote:
> On Fri, Jan 03, 2020 at 08:23:58PM +, Sudip Mukherjee wrote:
> > > What are the benefits of doing so?
> > The only benefit will be that we will be able to update the libraries
> > irrespective of kernel update. libbpf v0.0.6 has been released in
> > December but we will not be able to move to that version. The
> > userspace application using this library is deprived of the benefit of
> > the fixes that v0.0.6 brings.

But updating independently does not provide any benefit.  As the kernel
repo is still upstream, all upstream chnages will flow into the Debian
archive.  An extra package will always lag behind, as changes needs to
flow from kernel to external repo.

> It might be better if we decide now what we want to do and tell them
> accordingly.

Why should we?  If the upstream developers decide to maintain it
independently, aka don't use the kernel repo as true source, or better,
remove the source from it, then we have something to do.

Bastian

-- 
The more complex the mind, the greater the need for the simplicity of play.
-- Kirk, "Shore Leave", stardate 3025.8



Bug#947220: lvm2: System unbootable with cached root and latest kernel

2020-01-09 Thread Bastian Blank
Control: reassign -1  thin-provisioning-tools
Control: forcemerge 931514 -1

Moin

On Mon, Dec 23, 2019 at 03:05:15AM +, Stefanos Harhalakis wrote:
> Justification: breaks the whole system

No, it does not.

However, this is fixed in thin-provisioning-tools.

Bastian

-- 
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown



Bug#948041: impossible to update libbpf without updating the kernel

2020-01-03 Thread Bastian Blank
Hi Marco

On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> On Jan 03, Sudip Mukherjee  wrote:
> > Do we package libbpf from their github repo independent of the kernel
> > update? Then we will need to remove the libbpf building bits from the
> > Debian kernel source and create a separate package for libbpf.
> This is what some of the upstream libbpf developers requested us to do.

What I don't understand is, if the kernel git tree is the primary
location for this library, why should we use an external copy?

What are the benefits of doing so?

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty



Bug#925411: Removing kernel-package? (was: kernel-package: Not suitable for release)

2019-12-25 Thread Bastian Blank
Hi Manoj

Do you oppose that we finally shoot kernel-package dead, aka remove it
from the archive?

Regards,
Bastian

-- 
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
   stardate 5928.5.



Bug#947340: linux-base: can't be upgraded

2019-12-25 Thread Bastian Blank
Hi Christoph

On Wed, Dec 25, 2019 at 03:06:19AM +0100, Christoph Anton Mitterer wrote:
> Since last April, the package can't be upgraded as it conflicts with
> the current version of kernel-common.

kernel-common was neither released in Stretch, nor in Buster.

> but then this should be reflected in kernel-common, or it should have
> been coordinated with its maintainer in the first place.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925411

Regards,
Bastian

-- 
Either one of us, by himself, is expendable.  Both of us are not.
-- Kirk, "The Devil in the Dark", stardate 3196.1



Bug#947024: ipxe-qemu: grub2 tests fail after upgrade to 1.0.0+git-20190125.36a4c85-2

2019-12-19 Thread Bastian Blank
Control: tags -1 pending

Hi Colin

On Thu, Dec 19, 2019 at 05:14:11PM +, Colin Watson wrote:
> OK, I bisected this to this commit:
>   
> https://salsa.debian.org/waldi/ipxe/commit/56212b3037321d709184c5aed48b91b0a1bbd06e
> Happy to try further tests if you have any suggestions.

I feared it would be something like that.  And after re-reading the
change, the cause is found:

qemu loads rom files, which are supposed to include roms for all
environments, currently efi-x86_64 and pcbios.  By accident they now
only contain efi-x86_64.  So booting with OVMF works, but seabios does
not.

Regards,
Bastian

-- 
Dammit Jim, I'm an actor, not a doctor.



Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-30 Thread Bastian Blank
Hi Russ

On Fri, Nov 29, 2019 at 10:35:04AM -0800, Russ Allbery wrote:
> Procedurally in Debian neither of these are justifications for setting the
> severity to serious.  This is not a Policy requirement that has reached
> consensus, and the release team is the team in Debian that has the
> delegated responsibility to determine which bugs are release-critical for
> the next release.

My plan was to get the problem acknowledged and then accept the
remaining waiting Rust packages from NEW.

This problem is already listed since a long time in
https://ftp-master.debian.org/REJECT-FAQ.html.

> I realize that you're frustrated, and I suspect you're feeling like the
> Rust package maintainers are not respecting something that you think is
> obvious, but I don't think that fighting over the bug severity is the
> right way to approach this disagreement in Debian.  If you feel that
> you've reached an impasse in this discussion, this is what the Technical
> Committee is for.

The problem is not about severities, but about the Rust team to
acknowledge that there is a problem.

Bastian

-- 
Deflector shields just came on, Captain.



Bug#945542: [Pkg-rust-maintainers] Bug#945542: Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-29 Thread Bastian Blank
On Fri, Nov 29, 2019 at 02:49:21PM +0100, Sylvestre Ledru wrote:
> Le 29/11/2019 à 14:07, Bastian Blank a écrit :
> > The output of debcargo breaks the Debian archive by increasing the
> > Package file much more then it needs to do.
> Breaks seems a strong word, no?

It adds bloat to the Packages file in a volume that is not longer
considered acceptable.

I assume you know the difference between doing something once or doing
something a thousand times.

> We have at least 680 rust source packages in the archive currently, we 
> shipped buster with more than 500 Rust packages.

So would setting a limit to 500 rust source packages in the archive
at the same time help?

> What solution would make you happy here? (or at least acceptable).

Stick to one binary package per source package.

The only point that shows up again and again are cycles, which don't
pose a problem in the dpkg world.

> > Plus it can create oversized Provides lines.
> This is extremely rare. Not sure it is deserve a serious severity.
> There are only 3 packages with Provides longer than 5k: oca-core, 
> librust-web-sys-dev, librust-winapi-dev

Sure, but the 256k example that showed up shows that the algorithm used
to generate it can produce problematic output.

Regards,
Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, "Errand of Mercy", stardate 3198.4



Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-29 Thread Bastian Blank
Hi Ximin

On Fri, Nov 29, 2019 at 12:24:38PM +, Ximin Luo wrote:
> > On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
> > Please stop fiddling with severities.
> The maintainer of a package decides the severities and whether things are 
> bugs or not. Neither have you provided a justification for "serious", it is 
> not breaking anything.

The output of debcargo breaks the Debian archive by increasing the
Package file much more then it needs to do.  Plus it can create
oversized Provides lines.

> Manual cost, nobody is going to want to do this work. Do you want to do this 
> work?

No idea what manual work you are talking about.  Of course I can modify
debcargo and rip the code out to create the surplus packages.

I would have preferred it if you would do that yourself, but if you ask:
yes, I will delete that code from debcargo.

Regards,
Bastian

-- 
You're dead, Jim.
-- McCoy, "The Tholian Web", stardate unknown



Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-29 Thread Bastian Blank
Hi Ximin

On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
> Control: severity -1 normal

Please stop fiddling with severities.

> The more precise reason, as I have explained many times already, is because 
> the cargo package manager supports crates having optional dependencies. It is 
> not feasible to automatically merge optional-dependency-sets together because 
> it results in dependency loops that would not otherwise exist. It is not 
> economically feasible to manually merge these sets together either, because 
> it is boring and time-consuming work, error-prone (hard to manually tell if 
> you did or did not introduce a cycle) and of questionable benefit.

Yes, I got that.  And it seems cargo does not support recursive
dependencies.

However Debian does not use cargo, it uses dpkg and apt.  apt and dpkg
actually support recursive dependencies.  Due to some downsides in
regards of the handling of maintainer scripts they are discuraged.  But
as long as you don't have any of those, which all those packages don't
have, that's not much of a problem.

> I do not see any users complaining about this behaviour of our automatic 
> tooling. We would be happy to work towards a patch on any Debian 
> infrastructure to make these processes smoother. There is no reason why 
> adding and removing empty metadata-only packages should require manual 
> oversight, and if one is (and one should be) interested in automating the 
> amount of manual work involved in maintaining Debian infrastructure, this is 
> one obvious tedious task to automate away.

Sylvestre as rust team member asked the ftp team, which is responsible
for the archive content, to change their handling of binary-NEW.  So you
expect the ftp team to do the work you don't want to do.

This bug is about members of the ftp team asking you to change your
solution to that problem.  Re-iterating why it's not possible does not
help.

> We are all volunteers, there is no "job security" here, why are we manually 
> reviewing empty packages and we are we trying to conserve a process that 
> involves manually reviewing empty packages?

Because the ftp team is responsible for the content of the archive,
including package names etc.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-29 Thread Bastian Blank
Control: severity -1 serious

On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
> The more precise reason, as I have explained many times already, is because 
> the cargo package manager supports crates having optional dependencies. It is 
> not feasible to automatically merge optional-dependency-sets together because 
> it results in dependency loops that would not otherwise exist. It is not 
> economically feasible to manually merge these sets together either, because 
> it is boring and time-consuming work, error-prone (hard to manually tell if 
> you did or did not introduce a cycle) and of questionable benefit.

We told you several times that cycles in Debian packages are supported.

> We are all volunteers, there is no "job security" here, why are we manually 
> reviewing empty packages and we are we trying to conserve a process that 
> involves manually reviewing empty packages?

So is the ftp team.

Regards,
Bastian

-- 
Dismissed.  That's a Star Fleet expression for, "Get out."
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"



Bug#945542: debcargo -- Adds and removes binary packages

2019-11-26 Thread Bastian Blank
Hi Sylvestre

On Tue, Nov 26, 2019 at 07:31:05PM +0100, Sylvestre Ledru wrote:
> > I'm filling this as bug now.  Please discuss this issue there.
> First, this isn't random. This is generated from the features of the crate.
> I am not sure to understand what is wrong with that? It isn't uncommon to 
> add/remove
> binaries from a source package (I am doing that often with llvm-toolchain).

No.  But is not common to do that automatically, on thousands of source
packages.  So much you even asked the ftp team to drop part of their
checks on new binary packages.

> > I'm setting it to serious as several ftp team members told you not to do
> > that.
> Could you please explain what you mean by "that"?

Adding new binary packages automatically.  This whole thread was about
the problems of adding new binary packages all the time and you wanted
to way around binary-NEW for them.  Not making the scope clear was my
bad and I want to apologize for it.

> AFAIK, it happens just twice (librust-web-sys-dev & librust-winapi-dev) on 
> Rust packages (on 681 packages).
> But I don't have the knowledge to fix that issue... :/

Okay.  Who does?  Please remove the wontfix from the bug about the
Provides, to declare it needs to be fixed.

Regards,
Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9



Bug#945542: debcargo -- Randomly adds and removes binary packages

2019-11-26 Thread Bastian Blank
Package: debcargo
Severity: serious

Hi Sylvestre

I'm filling this as bug now.  Please discuss this issue there.

I'm setting it to serious as several ftp team members told you not to do
that.

On Thu, Oct 17, 2019 at 06:57:33PM +0200, Sylvestre Ledru wrote:
> Le 17/10/2019 à 18:52, Ansgar a écrit :
> > Sylvestre Ledru writes:
> > > Moreover, the creation (or deletion) of new packages is automatically
> > > managed by debcargo (our tooling).
> > Why do you need to automatically create/remove binary packages?
> Because it is the way it is managed in Rust packages. This is done to
> express what
> the package provides. For now, it has been working very well.
> 
> But this isn't an issue specific to Rust. Having to go through NEW when it
> is the same
> source isn't a good use of our time and introduces some unnecessary latency
> and frustration.
> 
> >  From looking at the package with the insane large Provides field, it
> > seems like it creates empty binary packages to avoid some dependencies
> > on other development packages to safe ~50k of downloads?  I would
> > suggest to just accept the 50k extra downloads for packages for people
> > using the rust development packages rather than creating extra binary
> > packages.
> 
> Sure but this isn't directly related to this discussion. I also do agree
> that we should
> address this issue.

-- 
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7



Bug#944920: Revise terminology used to specify requirements

2019-11-17 Thread Bastian Blank
On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is intended to provide flexibility to balance the
> +quality standards of the distribution against the release schedule and the
> +importance of making a stable release.

I don't think this aligns to the current release team practice, which
provides a canonical list of points that are considered policy
requirements:[1]

| The purpose of this document is to be a correct, complete and canonical
| list of issues that merit a "serious" bug under the clause "a severe
| violation of Debian policy".

Bastian

[1]: https://release.debian.org/bullseye/rc_policy.txt
-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3



Bug#944839: linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned: issues for application crash with this kernel

2019-11-16 Thread Bastian Blank
On Fri, Nov 15, 2019 at 11:23:09PM -0500, westlake wrote:
> When this kernel is used, the latest version of chrome crashes saying it
> can't launch because it is not able to create its own sandbox.
>  (chrome "Version 78.0.3904.97 (Official Build) (64-bit)")

Please try:

| sysctl -w kernel.unprivileged_userns_clone=1

Bastian

-- 
Bones: "The man's DEAD, Jim!"



Bug#944039: ITP: docker-systemctl-replacement -- daemonless "systemctl" command to manage services without SystemD

2019-11-03 Thread Bastian Blank
Hi Dmitry

On Sun, Nov 03, 2019 at 07:33:59PM +1100, Dmitry Smirnov wrote:
>Package name: docker-systemctl-replacement

"docker" only shows up in the name of the package.  What is this about?
Also "docker" is the trademark of the software called "moby".

> Description: daemonless "systemctl" command to manage services without 
> SystemD

The name of the referenced software is "systemd", not "SystemD" or
similar.  Those variants have been usually used to insult, so please
don't.

>  "systemctl" is a replacement command to control system daemons without
>  SystemD. "systemctl" is useful in application containers where SystemD is
>  not available to start/stop services.
>  .
>  This script can also be run as init of an application container (i.e. the
>  main "CMD" on PID 1) where it will automatically bring up all enabled
>  services in the "multi-user.target" and where it will reap all zombies
>  from background processes in the container. When stopping such a container
>  it will also bring down all configured services correctly before exit.

I still don't know when I want to install this.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.



Bug#943536: lintian: Stop shipping profile 'debian/ftp-master-auto-reject'

2019-10-25 Thread Bastian Blank
On Fri, Oct 25, 2019 at 02:37:33PM -0700, Felix Lechner wrote:
> Based on information from #debian-ftp, which is recorded in part below, the
> profile is no longer being used. It will be removed in the near future.

How will this command line option work afterwards?

| -F, --ftp-master-rejects
| Run only the checks that issue tags that result in automatic rejects
| from the Debian upload queue.  The list of such tags is refreshed with
| each Lintian release, so may be slightly out of date if it has changed
| recently.
| This is implemented via a profile and thus this option cannot be used
| together with --profile.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3



Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

2019-10-24 Thread Bastian Blank
Hi Ansgar

On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
> We could look into either
>  - writing MD5sum in a separate file only used by debian-cd (if present,
>otherwise debian-cd should fall back to using Packages), or

We still do that, see /indices/md5sum.gz.

Bastian

-- 
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown



Bug#942576: RM: icinga2 [armel mips64el mipsel s390x] -- ROM; Unblock testing migration

2019-10-18 Thread Bastian Blank
Control: reassign -1 src:icinga2
Control: retitle -1 icinga2 - FTBFS on release architectures
Control: severity -1 serious

Hi Bas

On Fri, Oct 18, 2019 at 02:22:17PM +0200, Sebastiaan Couwenberg wrote:
> On 10/18/19 2:11 PM, Bastian Blank wrote:
> > On Fri, Oct 18, 2019 at 01:53:22PM +0200, Bas Couwenberg wrote:
> >> Please remove icinga2 from armel, mips64el, mipsel & s390x to unblock 
> >> testing migration due to missing builds.
> > 
> > Those builds fail with different errors.  Please handle them properly
> > first.
> Why?

Because it's your responsibility as maintainer to make sure your
packages are properly maintained.

> These are architectures where icinga2 is unlikely to actually be used.

I beg to differ.  DSA uses icinga (currently version 1, but still).

> Partial removal is the best option in my not so humble opinion.

"Unblock testing migration" is no reason for a removal.  There may be
some, but that's not up for me to tell you.

Right now I see FTBFS, which is a serious bug on the package.  So I'm
assigning the bug again.  Stop playing with it.

Regards,
Bastian

-- 
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5



Bug#942576: RM: icinga2 [armel mips64el mipsel s390x] -- ROM; Unblock testing migration

2019-10-18 Thread Bastian Blank
Control: reassign -1 src:icinga2
Control: retitle -1 icinga2 - FTBFS on release architectures
Control: severity -1 serious

Hi Bas

On Fri, Oct 18, 2019 at 01:53:22PM +0200, Bas Couwenberg wrote:
> Please remove icinga2 from armel, mips64el, mipsel & s390x to unblock testing 
> migration due to missing builds.

Those builds fail with different errors.  Please handle them properly
first.

Bastian

-- 
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0



Bug#942456: python-flask-marshmallow - Incomplete debian/copyright

2019-10-16 Thread Bastian Blank
Source: python-flask-marshmallow
Version: 0.10.1-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: ftpmas...@debian.org, guptautkarsh2...@gmail.com, 
python-modules-t...@lists.alioth.debian.org

I just accepted python-flask-marshmallow from NEW.

docs/_themes/flask/static/flasky.css_t lists as license:
| * :copyright: Copyright 2010 by Armin Ronacher.
| * :license: Flask Design License, see LICENSE for details.

This license is not listed in debian/copyright.

Bastian

-- 
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7



Bug#942326: debugging

2019-10-16 Thread Bastian Blank
On Wed, Oct 16, 2019 at 06:32:31PM +0200, Thomas Lange wrote:
> When creating the generic image using
> files/etc/apt/sources.list.d/backports.list/BACKPORTS

This file stays in this image.

> files/etc/apt/sources.list/BUSTER_BUILD

This file is overriden later by:
config_space/scripts/DEBIAN/10-files:fcopy -riSM /

> Should both references to backports be removed in the cleanup script?

One is already, the other should stay, or we have a bug somewhere.

Bastian

-- 
The sooner our happiness together begins, the longer it will last.
-- Miramanee, "The Paradise Syndrome", stardate 4842.6



Bug#942325: /etc/hosts not updated in the generic image

2019-10-14 Thread Bastian Blank
On Mon, Oct 14, 2019 at 05:47:04PM +0200, Thomas Goirand wrote:
> The /etc/hosts isn't getting updated by cloud-init.
> Normally, the hostname of the VM should appear there
> after boot.

Please explain what the /etc/hosts update fixes.  All the environments
do DNS for exactly this name.

Bastian

-- 
It is more rational to sacrifice one life than six.
-- Spock, "The Galileo Seven", stardate 2822.3



Bug#942325: /etc/hosts not updated in the generic image

2019-10-14 Thread Bastian Blank
On Mon, Oct 14, 2019 at 07:13:34PM +0200, Thomas Goirand wrote:
> On 10/14/19 5:58 PM, Bastian Blank wrote:
> > Which exact image did you use?  What is the log output?
> Both the daily generic and genericcloud image have the issue.
> Logs attached.

The log shows:

> 2019-10-14 15:58:52,057 - cc_update_etc_hosts.py[DEBUG]: Configuration option 
> 'manage_etc_hosts' is not set, not managing /etc/hosts in module 
> update_etc_hosts

Bastian



Bug#942325: /etc/hosts not updated in the generic image

2019-10-14 Thread Bastian Blank
Control: reassign -1 cloud-init

On Mon, Oct 14, 2019 at 05:47:04PM +0200, Thomas Goirand wrote:
> The /etc/hosts isn't getting updated by cloud-init.
> Normally, the hostname of the VM should appear there
> after boot.

This is handled by cloud-init.

Which exact image did you use?  What is the log output?

Bastian

-- 
Every living thing wants to survive.
-- Spock, "The Ultimate Computer", stardate 4731.3



Bug#938962: Bug#941720: linux-headers-4.19.0-0.bpo.6-amd64 depends on linux-headers-4.19.0-0.bpo.6-common=4.19.67-2+deb10u1~bpo9+1 but only linux-headers-4.19.0-0.bpo.6-amd64=4.19.67-2~bpo9+1 is avail

2019-10-13 Thread Bastian Blank
On Sun, Oct 13, 2019 at 07:20:35PM +0530, Ritesh Raj Sarraf wrote:
> It is maintained. It is just that the latest upload is blocked by DBug:
> #938962

No, it is not maintained.  It depends on packages not longer in the
archive.

Regards,
Bastian

-- 
Bones: "The man's DEAD, Jim!"



Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict

2019-10-10 Thread Bastian Blank
On Wed, Oct 09, 2019 at 05:51:53PM +0200, Ansgar Burchardt wrote:
> While checking the upgrade checklist I noticed this new requirement:
> +---
> | 4.9
> |Required targets must not write outside of the unpacked source
> |package tree, except for TMPDIR, /tmp and /var/tmp.
> +---
> The wording is a bit too strict and should be relaxed.  There are
> other paths that should be fine to be written to during the build
> process, for example /dev/shm, /run/lock[1], or possibly anything
> below /proc/ for processes spawned by the build process.

Why do you think package builds should be allowed to use /run/lock?  It
records system state.

The use of /dev/shm is an implementation detail of the shm
implementation in libc.  I don't think using the shm stuff counts as
writing.

If you take the strict approach, then writing to stdout and stderr would
be forbidden as well.

Regards,
Bastian

-- 
Ahead warp factor one, Mr. Sulu.



Bug#940801: missing virtio block Kernel Objects

2019-09-19 Thread Bastian Blank
On Thu, Sep 19, 2019 at 10:56:55PM +0200, Geert Stappers wrote:
> The netboot tarball misses virtio block drivers.
> This makes it unnessecary tiresome
> to install Debian VMs on not-Internet-connected server.

This is intentional.  netboot is for booting from _network_.  On the
network you got a distribution mirror, otherwise you have problems
installing Debian anyway.

Bastian

-- 
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8



Bug#939258: RM: tortoisehg -- RoQA; Unmaintained, RC buggy, obsolete libs (python2)

2019-09-17 Thread Bastian Blank
On Tue, Sep 17, 2019 at 01:46:42PM +0200, Andrej Shadura wrote:
> I’m going to reintroduce it ASAP.

So you are adopting the package and porting it to Python 3?

Regards,
Bastian

-- 
There's coffee in that nebula!
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"



Bug#940307: libevent - excessive-priority-for-library-package

2019-09-15 Thread Bastian Blank
Source: libevent
Severity: normal

The library package libevent-2.1-6 (and the newly uploaded
libevent-2.1-7) have exessive priority defined.  Please change to
"normal".  I've overriden it while accepting from NEW.

See https://lintian.debian.org/tags/excessive-priority-for-library-package.html

Regards,
Bastian

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work

2019-08-13 Thread Bastian Blank
Hi Sven

On Thu, Jun 27, 2019 at 02:38:53PM +0200, Sven Bartscher wrote:
> The specified network-config doesn't seem to have any actual effect on
> what actually happens when the system boots. From what I see,
> cloud-init generates a configuration file from my specified
> configuration in /etc/network/interfaces.d/50-cloud-init.cfg with the
> following contents:

Thanks for bringing this up.  However I have bad news: this can not work
with ifupdown.  Reasons:

- cloud-init write the config file using a name that is ignored by
  ifupdown.  The filename is "50-cloud-init.cfg" and everything with "-"
  or "_" in it is ignored. (wtf?)
- ifupdown can't handle duplicated network definitions.  It will try to
  setup both static ips and use dhcp, and fail.

The first could be fixed pretty easily.  However the second can not
really without reinventing everything.

Regards,
Bastian

-- 
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
   stardate 5928.5.



Bug#908678: Update on the security-tracker git discussion

2019-08-06 Thread Bastian Blank
Moin

On Tue, Jul 02, 2019 at 01:38:10PM +0200, Moritz Muehlenhoff wrote:
> On Tue, Jul 02, 2019 at 01:25:43PM +0200, Salvatore Bonaccorso wrote:
> > p.s.: Question is if we should do a split as well for the other types of
> >   files which are supported (DSA, TDSA, ...) while at it.
> We can axe out DTSA/* while we're at it.
> For DSA/list (and DLA/list) we can initially keep it as a single file, it can
> still be split later on if necessary.

Following up to 

| Please provide a plan how and when to fix this before 2019-06-30.

We have now one month later.  Please provide the plan.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5



Bug#932943: Missing SHA512 and gpg signature

2019-08-05 Thread Bastian Blank
On Sun, Aug 04, 2019 at 10:05:32PM +0100, Chris Boot wrote:
> On 04/08/2019 17:29, Bastian Blank wrote:
> > Only one of them.  And I would go directly to SHA3 for new stuff.
> 
> Buster doesn't have any SHA3 tools in coreutils. While I don't have
> anything against calculating such checksums in addition to the usual
> suspects, I want to make sure people with current distros can easily
> check them.

Okay, let's stay with sha-512 for now.  Turns out it is also faster.

> >> 3. Add a new mapping within the "data" mapping called "checksums" with
> >> keys for each algorithm, e.g. "data.checksums.sha256".
> > 
> > The usual way would be something like this:
> > 
> > | data:
> > |   verify:
> > |   - name: sha3_256
> > | content: ABC=
> > |   - name: gpg
> > | content: AAA=
> 
> That kind of structure works for me. That way we *can*[1] have checksums
> for multiple image formats and multiple algorithms, e.g. the raw image,
> qcow2, compressed tarball, or whatever.

We have one upload manifest per image file.  I'm not sure yet why we
would want to have different checksums.

> > No, don't.  Use base64 like everyone else.
> I strongly disagree with this. Practically everyone else uses
> hexadecimal for plain checksums. A GPG signature is its own thing but is
> (generally) plaintext (I'm assuming clearsign). This is what we (as in
> the project) use for the archive and for ISOs.

Everything current switches to base64.  It's shorter and easier to see
changes.  Hex only survives where people tend to read it.

Regards,
Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3



Bug#932943: Missing SHA512 and gpg signature

2019-08-04 Thread Bastian Blank
On Sat, Aug 03, 2019 at 09:23:58PM +0100, Chris Boot wrote:
> Currently the build tools generate the raw image using FAI, then wrap it
> into a tarball. The tarball is then xz compressed outside
> debian-cloud-images in the GitLab CI job.
> Is there any reason to keep it that way? Why don't we move the
> compression into debian-cloud-images?

The output of the build process is uncompressed.  This is by design, as
compression is inherent expensive.

The stuff is only compressed with xz because the artifacts would be too
large otherwise, as zip does not feature really useful compression.

> Without this I don't see how debian-cloud-images can calculate a useful
> set of checksums for the cloud images. We either checksum the raw image
> itself or the tarball but neither is what ends up on patterson.

The checksum of the stuff after build is not that useful.  Only the
converted and compressed output on the storage is relevant.

Bastian

-- 
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, "Space Seed", stardate 3142.8



Bug#932943: Missing SHA512 and gpg signature

2019-08-04 Thread Bastian Blank
On Sat, Aug 03, 2019 at 03:06:39PM +0100, Chris Boot wrote:
> - Which checksums should we include? Our Apt repos use MD5 and SHA-256,
> and our ISOs use MD5, SHA-1, SHA-256 and SHA-512. I'd be inclined to
> suggest SHA-256 and SHA-512 only, personally.

Only one of them.  And I would go directly to SHA3 for new stuff.

> 1. Add labels of the form "checksum.cloud.debian.org/${ALGO}" under
> metadata.labels, for example "checksum.cloud.debian.org/sha256".

Labels are to search for stuff, not describe the content.

> 3. Add a new mapping within the "data" mapping called "checksums" with
> keys for each algorithm, e.g. "data.checksums.sha256".

The usual way would be something like this:

| data:
|   verify:
|   - name: sha3_256
| content: ABC=
|   - name: gpg
| content: AAA=

> In each case I expect the values to be hex strings, effectively the same
> as the first column of the output from sha1sum, sha256sum, sha512sum,
> etc... from coreutils.

No, don't.  Use base64 like everyone else.

Bastian

-- 
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
   stardate 3468.1.



Bug#932163: RM: ossim [mips64el] -- ROM; FTBFS on mips64el

2019-07-15 Thread Bastian Blank
On Tue, Jul 16, 2019 at 07:26:02AM +0200, Bas Couwenberg wrote:
> Please remove ossim from mips64el where it FTBFS.

Why?

Please follow the instructions given:

| Please submit a full bug report,
| with preprocessed source if appropriate.
| See  for instructions.

Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8



Bug#931341: linux-image-4.19.0-5-cloud-amd64 does not have /dev/rtc, used by GCE images

2019-07-02 Thread Bastian Blank
Control: severity -1 important

On Tue, Jul 02, 2019 at 04:50:09PM +0200, Santiago Vila wrote:
> On a virtual machine running buster on Google Compute Engine, where
> this kernel package is the default, I get the following messages:

I remember a different report about this, but don't know where.

We should fix this, but this have to wait until r1.

Regards,
Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2



Bug#930856: autopkgtest-build-qemu: captures something from host

2019-06-30 Thread Bastian Blank
On Sat, Jun 29, 2019 at 04:44:32PM +0200, Bastian Blank wrote:
> On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> > Note that APT tries to use Devuan keyring to validate Debian release and
> > fail. How does `debootstrap' decides, which keyring to use?
> "dpkg -s debootstrap"?  How did that keyring get on the system in the
> first place?

Devuan includes a patched version of debootstrap.  See
https://pkginfo.devuan.org/stage/ascii/ascii/debootstrap_1.0.89+devuan2.1.html

Please show that you use an unpatched version on a system without a
Devuan key.

Bastian

-- 
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3



Bug#930856: autopkgtest-build-qemu: captures something from host

2019-06-29 Thread Bastian Blank
On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> Note that APT tries to use Devuan keyring to validate Debian release and
> fail. How does `debootstrap' decides, which keyring to use?

"dpkg -s debootstrap"?  How did that keyring get on the system in the
first place?

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4



Bug#930905: unblock: lvm2/2.03.02-3

2019-06-22 Thread Bastian Blank
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lvm2.  It makes sure a removed daemon is actually
stopped.

diff --git a/debian/changelog b/debian/changelog
index de265380d..acfe305a9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+lvm2 (2.03.02-3) unstable; urgency=medium
+
+  * Stop lvm2-lvmetad on upgrade. (closes: #929080)
+
+ -- Bastian Blank   Fri, 21 Jun 2019 12:29:17 +0200
+
 lvm2 (2.03.02-2) unstable; urgency=medium
 
   * Remove lvm2-lvmetad init script as well. (closes: #917159)
diff --git a/debian/lvm2.postinst b/debian/lvm2.postinst
index 5d22a627f..5df34881c 100644
--- a/debian/lvm2.postinst
+++ b/debian/lvm2.postinst
@@ -15,7 +15,7 @@ case "$1" in
 deb-systemd-helper purge lvm2-activation-early.service 
lvm2-activation.service >/dev/null
 deb-systemd-helper unmask lvm2-activation-early.service 
lvm2-activation.service >/dev/null
 fi
-if dpkg --compare-versions "$2" lt "2.03.02-2~"; then
+if dpkg --compare-versions "$2" lt "2.03.02-3~"; then
 deb-systemd-helper purge lvm2-lvmetad.socket >/dev/null
 deb-systemd-helper unmask lvm2-lvmetad.socket >/dev/null
 update-rc.d -f lvm2-lvmetad remove
diff --git a/debian/lvm2.preinst b/debian/lvm2.preinst
index ddf4bd12c..bfe7809e4 100644
--- a/debian/lvm2.preinst
+++ b/debian/lvm2.preinst
@@ -10,6 +10,9 @@ case "$1" in
 deb-systemd-helper unmask lvm2-activation.service 
lvm2-activation-early.service >/dev/null
 fi
 fi
+if dpkg --compare-versions "$2" lt "2.03.02-3~"; then
+invoke-rc.d lvm2-lvmetad stop || true
+fi
 ;;
 esac

unblock lvm2/2.03.02-3

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#925545: busybox: please provide runscript file

2019-06-15 Thread Bastian Blank
Hi Dmitry

On Sat, Jun 15, 2019 at 06:37:03PM +, Dmitry Bogatov wrote:
> But, after all, we all volonteers here. So hereby I inform you,
> following advice in Developer reference, section 5.11, that I plan to
> do non-maintainer upload in two weeks or so.

As we are before a release, NACK.

Bastian

-- 
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0



Bug#929214: release.debian.org - Add package constraint for cloud images

2019-06-13 Thread Bastian Blank
Hi

On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote:
> On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote:
> > If you create such a package, having a binary per architecture as you
> > describe, should do what you want. It can be added to the list as soon as it
> > is in testing.
> Okay, thank you.

A quick question:

Will britney choke if we list conflicting packages as dependencies?

Something like this:
| Depends: exim4, postfix

Regards,
Bastian

-- 
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7



Bug#929214: release.debian.org - Add package constraint for cloud images

2019-06-12 Thread Bastian Blank
Hi Paul

On Wed, Jun 12, 2019 at 08:42:27PM +0200, Paul Gevers wrote:
> On 12-06-2019 20:01, Bastian Blank wrote:
> > I'm also not sure if the Debian autopkgtest infrastructure would be able
> > to do that and build images.  The actual testing runs via the Gitlab
> > CI.[1]
> You could very probably do it. Depending on how long such a build takes,

One build takes 3 minutes if it runs native and 13 minutes if it runs
via qemu-user.  However it needs awefull amount of network and disk IO.

Does the Debian autopkgtest instance support "needs-root" and
"breaks-testbed"?  The image build uses loop devices, hence
"needs-root", which can't be cleaned up properly, hence
"breaks-testbed".

> I slightly wonder if you should, but the advantage is that it is
> integrated with the migration software.

Yes.

Regards,
Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8



Bug#929214: release.debian.org - Add package constraint for cloud images

2019-06-12 Thread Bastian Blank
Hi

On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote:
> If you create such a package, having a binary per architecture as you
> describe, should do what you want. It can be added to the list as soon as it
> is in testing.

Okay, thank you.

> Also, just as a suggestion: if it is feasible, you could add an autopkgtest to
> that source to build (or even test) the cloud images. That would prevent
> migration to testing of packages that break your images.

The code in the package is not used to actually build the images we
release for Debian.  We use the unreleased code from the git repository
to do all the automated stuff.

I'm also not sure if the Debian autopkgtest infrastructure would be able
to do that and build images.  The actual testing runs via the Gitlab
CI.[1]

Regards,
Bastian

[1]: https://salsa.debian.org/cloud-team/debian-cloud-images/pipelines
-- 
Dismissed.  That's a Star Fleet expression for, "Get out."
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"



Bug#929557: Please revert LTS kernel change that will break ZFS for Buster point releases

2019-06-03 Thread Bastian Blank
Control: severity -1 wishlist

On Mon, Jun 03, 2019 at 06:39:39PM -0700, Mo Zhou wrote:
> I believe this is a kernel bug. Instead of submitting
> a grave RC for the 10.1 release, we'd better sort it out
> right now before the Buster release.

We already stated that we wont change it by marking this bug as wontfix.
We also told youd that it is your turn to pursuade upstream.

The export of this low-level functions was revoked because it was often
used in a wrong way.  The safe alternative is still exported, however
marked as gpl-only.  It is up to you to pursuade upstream to change the
still existing export, which should be possible, but this needs do be
done by you.  After upstream applied it we can cherry pick this chane.

Regards,
Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3



Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet]

2019-05-26 Thread Bastian Blank
Hi Chris

On Sat, May 25, 2019 at 10:03:07PM -0400, Chris Zubrzycki wrote:
> GKH has been purging __kernel_fpu_{begin,end}() from all kernels
> including LTS (4.19/5) and it's needed for AES-NI/AVX support in the zfs
> package.

The commit also tells you why this was done.  Please bring this up to
upstream and Greg, not to us.

>Arch Linux has already reverted the offending commit in their
> distro. Patch available at
> https://raw.githubusercontent.com/Mic92/nixpkgs/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch

How is this change not a copyright violation?

Regards,
Bastian

-- 
Punishment becomes ineffective after a certain point.  Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7



Bug#929214: release.debian.org - Add package constraint for cloud images

2019-05-19 Thread Bastian Blank
Package: release.debian.org
Severity: normal

Hi release team

To make your and our work easier, we would like to ask you to add a
package constraint for all the packages included into the official
Debianm cloud images.

>From what I read, the easiest way for you would be to specify a single
package as constraint, a package that depends on all the other binary
package we explicitely include in the images.

I intend to add one binary package per architecture we currently build
images for: amd64, arm64 and ppc64el.  The dependencies will be arch
dependent and auto-generated from our own list.

The package would look like this:

| Package: debian-cloud-images-packages
| Architecture: amd64
| Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, 
google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, 
linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, 
python-boto, python3-boto, sudo, unattended-upgrades, waagent

Please acknowledge that such a package would be okay for using as
constraint.  After that I'll upload that change.

Regards,
Bastian

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#929195: ITP: golang-github-bradfitz-iter -- Range over integers [0,n). Seriously, that's it.

2019-05-19 Thread Bastian Blank
On Sun, May 19, 2019 at 03:12:01PM +0800, Drew Parsons wrote:
> This package was intended to be an educational joke when it was
> released in in 2014. People didn't get the joke part and started
> depending on it. That's fine, I guess. (This is the Internet.) But
> it's kinda weird. It's one line, and not even idiomatic Go style. I
> encourage you not to depend on this or write code like this, but I do
> encourage you to read the code and think about the representation of
> Go slices and why it doesn't allocate.

Please merge this code into the using one.

Bastian

-- 
Emotions are alien to me.  I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3



Bug#929013: closed by Mattia Rizzolo (Bug#929013 fixed in jenkins.debian.org)

2019-05-16 Thread Bastian Blank
Hi Mattia

On Thu, May 16, 2019 at 09:50:50AM +0200, Mattia Rizzolo wrote:
> On Wed, May 15, 2019 at 08:51:14PM +0200, Bastian Blank wrote:
> > Please add the word "Bot" in it and add contact information.
> I can do that, but could you please explain why you find the word "Bot"
> so important?

It should trigger the automatic process detection of our log checker.
"Bot" is one of the trigger words.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty



Bug#929013: closed by Mattia Rizzolo (Bug#929013 fixed in jenkins.debian.org)

2019-05-15 Thread Bastian Blank
Control: reopen 929013

On Wed, May 15, 2019 at 03:21:07PM +, Debian Bug Tracking System wrote:
> 
> set a special userAgent for git, so server can more easily recognize us
> 
> Closes: #929013
> Signed-off-by: Mattia Rizzolo 
> 

Please add the word "Bot" in it and add contact information.

Regards,
Bastian

-- 
Well, Jim, I'm not much of an actor either.



Bug#929014: Stop polling salsa.d.o

2019-05-15 Thread Bastian Blank
Hi Mattia

On Wed, May 15, 2019 at 05:01:05PM +0200, Mattia Rizzolo wrote:
> On Wed, May 15, 2019 at 11:07:13AM +0200, Bastian Blank wrote:
> > Please stop polling git repositories on salsa.debian.org.
> Could you please provide more data?

I'm not sure what exactly the relation between jenkins.d.org and
jenkins.d.net is, but h01ger asked for a bug against this
pseudo-package, so I assume I reached the correct people.

I see from 46.16.76.207 every minute git-upload-pack, aka fetch, for:
- https://salsa.debian.org/perl-team/modules/packages/debsums.git
- https://salsa.debian.org/release-team/debian-archive-keyring.git

Every six minutes for:
- https://salsa.debian.org/haskell-team/package-plan.git

Some are erratic, but not synchronized with repo activity:
- https://salsa.debian.org/helmutg/rebootstrap.git

Bastian

-- 
"... freedom ... is a worship word..."
"It is our worship word too."
-- Cloud William and Kirk, "The Omega Glory", stardate unknown



Bug#929013: Set user-agent for git

2019-05-15 Thread Bastian Blank
Package: jenkins.debian.net

Please set a useful user-agent for git to identify yourself and identify
it as a bot.

| git config --system http.userAgent "jenkins.d.n git Bot (jenkins.debian.net; 
$email)"

Regards,
Bastian

-- 
Warp 7 -- It's a law we can live with.



Bug#929014: Stop polling salsa.d.o

2019-05-15 Thread Bastian Blank
Package: jenkins.debian.net

Please stop polling git repositories on salsa.debian.org.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#908678: security-tracker - Breaks salsa.d.o

2019-05-13 Thread Bastian Blank
Hi Salvatore

On Thu, Sep 13, 2018 at 01:37:35PM +0200, Salvatore Bonaccorso wrote:
> On Wed, Sep 12, 2018 at 03:10:56PM +0200, Bastian Blank wrote:
> > As the problems caused by the state of this repo now causes user visible
> > outages, this needs to be fixed.

Please provide a plan how and when to fix this before 2019-06-30.

Just for the record: you must drop the complete project before importing
the rewritten repository.  GitLab keeps all the revisions around, as 
they are associated with jobs.

Regards,
Bastian

-- 
Captain's Log, star date 21:34.5...



Bug#923091: That merged-usr is mandatory is RC

2019-05-13 Thread Bastian Blank
Control: severity -1 wishlist

Hi Ian

On Mon, May 13, 2019 at 11:22:35AM +0100, Ian Jackson wrote:
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.

No, he did not mention dpkg.  But as always, please provide a patch and
answer kibi's questions.

Regards,
Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2



Bug#919621: lvm2: Update unexpectedly activates system ID check, bypassing impossible

2019-05-05 Thread Bastian Blank
Hi Colin

On Sun, May 05, 2019 at 12:12:00AM +0100, Colin Watson wrote:
> > I also ran into this on upgrading from stretch to buster.  Fortunately I
> > was keeping enough of an eye on console output from the upgrade that I
> > was able to find this bug and I worked around it as you describe here.
> In case it's useful information to anyone, since the system ID appears
> to contain a seconds-since-epoch value, I can deduce that I created the
> VG on 2004-05-18, which makes sense given the sorts of things I was
> doing at the time.  I would have been running either woody or the
> current state of sarge in development at the time.

Is is possible this VG was converted from lvm1?  In the year 2004 lvm2
existed but was rather new.  I found code to generate exactly this
format of system id in the lvm1 support code of lvm2/2.01.14 (the oldest
version I was able to find easily).

| lvm_snprintf(s, NAME_LEN, "%s%s%lu", prefix, cmd->hostname, time(NULL)

Support to make any use of this value was is rather new and was added
for stretch.

Regards,
Bastian

-- 
No one may kill a man.  Not for any purpose.  It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6



Bug#928382: unblock: waagent/2.2.34-4

2019-05-03 Thread Bastian Blank
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package waagent.  It fixes one wrong sed call.

diff --git a/debian/changelog b/debian/changelog
index 06df3b6..99e11ff 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+waagent (2.2.34-4) unstable; urgency=medium
+
+  * Fix stray backup file due to incorrect sed call. (closes: #928179)
+
+ -- Bastian Blank   Mon, 29 Apr 2019 16:45:57 +0200
+
 waagent (2.2.34-3) unstable; urgency=medium
 
   * Set proper access rights on swap file.
diff --git a/debian/share/apt-setup b/debian/share/apt-setup
index e87fef5..a0a249e 100755
--- a/debian/share/apt-setup
+++ b/debian/share/apt-setup
@@ -15,7 +15,7 @@ touch /var/lib/waagent/provisioned_apt-setup
 PROTOCOL=$(cat /var/lib/waagent/Protocol)
 
 if [ "$PROTOCOL" = "WireProtocol" ]; then
-   sed -ie 
's#http://deb.debian.org#http://debian-archive.trafficmanager.net#' 
/etc/apt/sources.list
+   sed -i -e 
's#http://deb.debian.org#http://debian-archive.trafficmanager.net#' 
/etc/apt/sources.list
 fi
 
 apt-get update

unblock waagent/2.2.34-4

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



  1   2   3   4   5   6   7   8   9   10   >