.1) UNRELEASED; urgency=medium
+
+ * Explicit pass MKDIR_P, GREP and SED to configure to make build
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 15:00:28 +0100
+
bsdowl (2.2.2-1) unstable; urgency=medium
* Initial release. (Closes: #760592)
to make build reproducible
+between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 14:20:56 +0100
+
maildrop (2.9.3-2) unstable; urgency=medium
* Migrate VCS from alioth to salsa.
diff -Nru maildrop-2.9.3/debian/rules maildrop-2.9.3/debian/rules
--- maildrop
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:41:09 +0100
+
nvi (1.81.6-13) unstable; urgency=medium
* QA upload.
diff -Nru nvi-1.81.6/debian/rules nvi-1.81.6/debian/rules
--- nvi-1.81.6/debian/rules 2016-12-31 05:03:39.0
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:41:09 +0100
+
nvi (1.81.6-13) unstable; urgency=medium
* QA upload.
diff -Nru nvi-1.81.6/debian/rules nvi-1.81.6/debian/rules
--- nvi-1.81.6/debian/rules 2016-12-31 05:03:39.0
) UNRELEASED; urgency=medium
+
+ * Explicit pass path to {u,}mount to configure to make build
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:40:31 +0100
+
disk-manager (1.1.1-2) unstable; urgency=low
* Add Build-Depends-Indep on menu
-7.2.6/debian/changelog
@@ -1,3 +1,10 @@
+apsfilter (7.2.6-1.4) UNRELEASED; urgency=medium
+
+ * Explicit pass `--with-shell=/bin/bash` to configure to make build
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:20:25 +0100
+
apsfilter
to configure to make build reproducible
+between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:07:16 +0100
+
libsmi (0.4.8+dfsg2-15) unstable; urgency=medium
* Add /var/lib/snmp/mibs/site to the default search path for MIB files.
diff -Nru libsmi-0.4.8
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
>
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by
> default now, or are you OK letting the TC decide on this subject?
There were discussions about enabling
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
>
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by
> default now, or are you OK letting the TC decide on this subject?
There were discussions about enabling
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
>
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by
> default now, or are you OK letting the TC decide on this subject?
There were discussions about enabling
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
>
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by
> default now, or are you OK letting the TC decide on this subject?
There were discussions about enabling
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not co
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not co
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not co
Package: ftp.debian.org
Severity: normal
Please remove systemd-shim from the archive. It is dead upstream,
unmaintained, uninstallable and broken.
AFAIU people who like systemd-logind's features, but don't want to run
systemd-init for some reason plan to use elogind instead which has now
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping
2017-12-09 00:07:05.0 +0100
+++ bumblebee-3.2.1/debian/changelog2018-11-29 10:19:19.0 +0100
@@ -1,3 +1,9 @@
+bumblebee (3.2.1-18) UNRELEASED; urgency=medium
+
+ * Remove obsolete conffile /etc/init/bumblebeed.conf
+
+ -- Ansgar Burchardt Thu, 29 Nov 2018 10:19:19 +0100
Lorenz writes:
> Ansgar Burchardt:
>>As a possible alternative: ship the runscript and some metadata (which
>>systemd service(s) and/or sysvinit script(s) this corresponds with;
>>which system users would be needed; ...) either in the service package
>>(preferred
Dmitry Bogatov writes:
> I believed (and still believe, despite of REJECT), that best way is
>
> 0. One source package, providing single binary package per runscript.
>
>src:{foo}-run -> bin:{foo}-run -> /etc/sv/{foo}
We generally try to avoid tiny packages in the archive; having 1000+
On Wed, 2018-11-28 at 09:45 +, Holger Levsen wrote:
> On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov
> wrote:
> As long as there is one Debian Developer (or any other person who has the
> > right to upload binary packages) who has a merged /usr on his system used
> > for
On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to no
Source: kmc
Version: 2.3+dfsg-6
Severity: normal
kmc installs programs to /bin. For a bioinformatics tool this seems
not correct; the programs should be installed to /usr/bin instead.
Ansgar
Package: ttygif
Version: 1.4.0-1
Severity: normal
The ttygif program is installed as /bin/ttygif. From the description
it should be installed as /usr/bin/ttygif instead.
Ansgar
PS: The Build-Depends: gcc-8 also looks incorrect as only `gcc` is
called by the Makefile.
Package: gaffitter
Version: 0.6.0-2
Severity: normal
The package install gaffitter to /bin, but it should be installed to
/usr/bin. From looking at the Makefile, passing prefix=/usr when
calling `make install` might be enough for this.
Ansgar
Package: gaffitter
Version: 0.6.0-2
Severity: normal
The package install gaffitter to /bin, but it should be installed to
/usr/bin. From looking at the Makefile, passing prefix=/usr when
calling `make install` might be enough for this.
Ansgar
On Thu, 2018-11-22 at 13:56 +, Ian Jackson wrote:
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > On Nov 22, Ian Jackson wrote:
> > > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > > So far nobody reported anything significant.
> > >
> > > I hear there was a major free
Package: systemd
Version: 239-11
Severity: minor
File: /bin/systemd
Running `systemd` in an interactive shell is not a good idea. To
avoid this happening by accident, the /bin/systemd ->
/lib/systemd/systemd symlink should no longer be shipped.
Documentation such as [1] still suggests to use
Package: systemd
Version: 239-11
Severity: minor
File: /bin/systemd
Running `systemd` in an interactive shell is not a good idea. To
avoid this happening by accident, the /bin/systemd ->
/lib/systemd/systemd symlink should no longer be shipped.
Documentation such as [1] still suggests to use
On Tue, 2018-11-06 at 09:14 +0800, Paul Wise wrote:
> AFAICT the Debian Secure Boot packages are not designed for the
> scenario where only Debian keys or per-user keys are trusted by the
> firmware, if they were then shim-signed would be named
> shim-signed-microsoft and there would be a
On Tue, 2018-11-06 at 10:42 +, Holger Levsen wrote:
> On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
> > On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> > > But only the stock kernel, which turns it non-free software.
> > What is non-free? Signing stuff does
Hi,
Steve McIntyre writes:
> On Mon, Sep 03, 2018 at 09:45:39AM +0200, intrigeri wrote:
>>Hi,
>>
>>Sven Joachim:
>>> The package priorities on security.debian.org differ from the ones in
>>> the main archive
>>
>>Here's another brand new example:
>>
>>$ apt-cache show mutt | grep -E
Hi,
"Adam D. Barratt" writes:
> - November 10th
This would work if needed, though I don't mind someone else doing the
archive side (still have some things to sort out *sigh*).
Ansgar
Hi,
"Adam D. Barratt" writes:
> - November 10th
This would work if needed, though I don't mind someone else doing the
archive side (still have some things to sort out *sigh*).
Ansgar
Hi,
"Adam D. Barratt" writes:
> - November 10th
This would work if needed, though I don't mind someone else doing the
archive side (still have some things to sort out *sigh*).
Ansgar
Paul Wise writes:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
>> As long as people choose to strip of dependencies to libsystemd from
>> packages like util-linux, avoiding a fork would not work with how Debian
>> and Debian based distributions are built.
>
> It might be feasible to
Paul Wise writes:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
>> As long as people choose to strip of dependencies to libsystemd from
>> packages like util-linux, avoiding a fork would not work with how Debian
>> and Debian based distributions are built.
>
> It might be feasible to
On Fri, 2018-10-19 at 11:35 +0200, Martin Steigerwald wrote:
> Martin Steigerwald - 19.10.18, 10:57:
> > That written, I estimate or guess that the people preferring to use
> > another initialization system than the initialization system in
> > Systemd are in the minority. Yet, this minority might
Package: slrnpull
Version: 1.0.3+dfsg-2
I can confirm that slrnpull's cronjob still fails with "This account is
currently not available." in Debian testing (buster).
I'm also using RUNFROM='manually', but I'm not sure that is relevant
(the check for RUNFROM only occurs later in the cronjob).
Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> That exception does not exist in Policy; there is only an exception for
>> packages provided by the init implementation itself. Policy currently
>> requires the "Loose coupli
Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> That exception does not exist in Policy; there is only an exception for
>> packages provided by the init implementation itself. Policy currently
>> requires the "Loose coupli
On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote:
> So my question is more like "is it okay to not change Debians default
> NTP server selection", so the initial setup and those lazy enough to
> not change the default get a sane time?
I don't think Debian can answer that question and suggest
Russ Allbery writes:
> Ansgar Burchardt writes:
>> So shipping a daemon without init scripts is better than shipping one
>> with only a systemd unit?
>
> I don't believe such a daemon package (with no init script) should be
> included in Debian at *all*, as a matter of
Russ Allbery writes:
> Ansgar Burchardt writes:
>> So shipping a daemon without init scripts is better than shipping one
>> with only a systemd unit?
>
> I don't believe such a daemon package (with no init script) should be
> included in Debian at *all*, as a matter of
free...@tango.lu writes:
> If Debian drops sysVinit support I will drop Debian
[...]
> This is your last chance to do the right thing and announce the
> removal of this fucking piece of shit malware(D) from Debian and go
> back to sysVinit or openrc!
So dropping sysvinit support will make you go
Russ Allbery writes:
> Ansgar Burchardt writes:
>
>> a. tor@.service has no init script with the same name. This should be
>>fine. (Note: there is also both a "tor.service" and "tor" init
>>script.)
>
> Presumably this is fine for the sa
Russ Allbery writes:
> Ansgar Burchardt writes:
>
>> a. tor@.service has no init script with the same name. This should be
>>fine. (Note: there is also both a "tor.service" and "tor" init
>>script.)
>
> Presumably this is fine for the sa
Josh Triplett writes:
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.
It's a configuration file that is not supposed to ever be changed. If
there are local changes, an admin will likely not include updates
provided by newer packages.
Josh Triplett writes:
> Which effectively means the admin should never delete any existing entry
> in the file, only add their own.
It's a configuration file that is not supposed to ever be changed. If
there are local changes, an admin will likely not include updates
provided by newer packages.
Ansgar Burchardt writes:
> c. It is better to ship integration with some init systems than
>no integration at all. (Including sysvinit scripts at all is not
>required, only when any other integrations are provided.)
As a special example:
DBus can start services on-demand. O
Ansgar Burchardt writes:
> c. It is better to ship integration with some init systems than
>no integration at all. (Including sysvinit scripts at all is not
>required, only when any other integrations are provided.)
As a special example:
DBus can start services on-demand. O
On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is
> the package buggy if it does not contain an init script but a systemd
> unit and it seems to be the case. Note that there are a *lot* of useful
> options in a systemd unit that would need emulation to make properly
On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is
> the package buggy if it does not contain an init script but a systemd
> unit and it seems to be the case. Note that there are a *lot* of useful
> options in a systemd unit that would need emulation to make properly
Package: debian-policy
Version: 4.2.1.2
Severity: normal
This requirement is currently included in Debian Policy:
+---
| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and
Package: debian-policy
Version: 4.2.1.2
Severity: normal
This requirement is currently included in Debian Policy:
+---
| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and
On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is
> the package buggy if it does not contain an init script but a systemd
> unit and it seems to be the case. Note that there are a *lot* of useful
> options in a systemd unit that would need emulation to make properly
On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote:
> Ansgar Burchardt - 16.10.18, 08:53:
> > If some people consistently call others a "cancer", accuse them of
> > "vandalizing" open source, spread obvious FUD and so on, then I don't
> > think t
Martin Steigerwald writes:
> Ansgar Burchardt - 15.10.18, 16:03:
>> Please no. I don't think it would help Debian to have toxic people
>> maintain packages.
>>
>> (As an example, Devuan's infobot has fun facts like this one:
>> "<+infobot> 'sth is po
On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote:
> On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:
> > I believe Andreas Henriksson is right, the packages are going to be
> > removed unless someone with time and interest show up to take care of
> > them. A good
Control: tag -1 moreinfo
Dmitry Smirnov writes:
> Please remove "golang-github-docker-engine-api" from "unstable".
>
> golang-github-docker-engine-api is an obsolete Docker client that has been
> incorporated into Docker a while ago. Remaining reverse build dependencies
> don't matter and they
Control: tag -1 moreinfo
Dmitry Smirnov writes:
> Please remove "docker-runc" from "unstable".
There is still a package build-depending on docker-runc:
# Broken Build-Depends:
kubernetes: golang-github-opencontainers-docker-runc-dev
Ansgar
Jessie LTs no longer updated on ftp-master
===
Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
Package: lists.debian.org
X-Debbugs-Cc: debian-...@lists.debian.org
The web archive for debian-efi@ at https://lists.debian.org/debian-ci/
do not seem to get updated since this month. There have been at least two
messages that went over the list this month, but they aren't shown in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 28 Sep 2018 21:05:16 +0200
Source: dune-istl
Binary: libdune-istl-dev libdune-istl-doc
Architecture: source
Version: 2.6.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar
On Wed, 2018-09-19 at 10:07 +0200, Wouter Verhelst wrote:
> On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote:
> > for example when files are overwritten. This is not case and Breaks
> > "is enough".
>
> "Breaks" means "will cause the other package to fail". That isn't the
> case here.
Package: libc6
Version: 2.27-6
Severity: normal
libc6.preinst includes:
-e's/\bsamaba\b/smbd/g'
This looks like a typo to me. I assume it should be samba instead of
samaba?
Ansgar
Package: libc6
Version: 2.27-6
Severity: normal
libc6.preinst includes:
-e's/\bsamaba\b/smbd/g'
This looks like a typo to me. I assume it should be samba instead of
samaba?
Ansgar
On Sat, 2018-09-15 at 14:04 +0200, Adam Borowski wrote:
> It would be nice if we had an official ftpmasters' position. So far, all
> we have are remarks on IRC.
>
> The case here is the package "parallel" having recentlish grown a demand for
> either a citation or 1€. This is explicitely
On Sat, 2018-09-15 at 14:04 +0200, Adam Borowski wrote:
> It would be nice if we had an official ftpmasters' position. So far, all
> we have are remarks on IRC.
>
> The case here is the package "parallel" having recentlish grown a demand for
> either a citation or 1€. This is explicitely
Package: grub-efi-amd64-signed-template
Version: 2.02+dfsg1-5
Severity: serious
The `Built-Using` field of the source template refers to binary
packages instead of source packages. This makes dak reject the upload
of the signed packages:
+---
| grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.deb:
Package: grub-efi-amd64-signed-template
Version: 2.02+dfsg1-5
Severity: serious
The `Built-Using` field of the source template refers to binary
packages instead of source packages. This makes dak reject the upload
of the signed packages:
+---
| grub-efi-amd64-signed_1+2.02+dfsg1+5_amd64.deb:
Package: fwupd-amd64-signed-template
Version: 1.1.1-1
Severity: important
>From the build log on amd64:
+---
| drwxr-xr-x root/root 0 2018-08-13 13:08 ./
| drwxr-xr-x root/root 0 2018-08-13 13:08 ./usr/
| drwxr-xr-x root/root 0 2018-08-13 13:08 ./usr/share/
| drwxr-xr-x
Package: src:grub2
Version: 2.02+dfsg1-5
Severity: important
The source template in grub-efi-amd64-signed-template _amd64.deb and
_i386.deb builds the same source package: grub-efi-amd64-signed.
That is not possible.
Same for the ia32 version.
I suggest to only build the signed version for the
Control: tag -1 fixed-upstream confirmed
Control: forwarded -1
https://gitlab.dune-project.org/core/dune-istl/merge_requests/216
Santiago Vila writes:
> /usr/include/c++/8/bits/stl_tree.h:457:21: error: static assertion failed:
> comparison object must be invocable as const
>
Control: tag -1 fixed-upstream confirmed
Control: forwarded -1
https://gitlab.dune-project.org/core/dune-istl/merge_requests/216
Santiago Vila writes:
> /usr/include/c++/8/bits/stl_tree.h:457:21: error: static assertion failed:
> comparison object must be invocable as const
>
Control: tag -1 fixed-upstream confirmed
Control: forwarded -1
https://gitlab.dune-project.org/core/dune-istl/merge_requests/216
Santiago Vila writes:
> /usr/include/c++/8/bits/stl_tree.h:457:21: error: static assertion failed:
> comparison object must be invocable as const
>
Ben Hutchings writes:
> On Sat, 2018-08-18 at 15:00 +0000, Ansgar Burchardt wrote:
>> Jessie no longer maintained on ftp-master
>
> This was uploaded to security-master so I don't know why you're seeing
> it on ftp-master as well.
The security-master -> ftp-master sync ha
PICCA Frederic-Emmanuel writes:
> I would like to know if you are ok, if I grant a Developer acces to
> salsa-pipeline-guest for the science-team.
> I would like to use this [1], for my packages.
> [1] https://salsa.debian.org/salsa-ci-team/pipeline
Why does a CI system need to push branches and
Jessie no longer maintained on ftp-master
===
Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
Jessie no longer maintained on ftp-master
===
Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
John Paul Adrian Glaubitz writes:
>>> Or imagine an attendee commits a felony, you need to be able to
>>> identify them as well.
>>
>> Talk to the police.
>
> Even the police cannot identify a foreigner without passport documents.
They can. Why do you think they collect photos and fingerprints
Package: fwupd-amd64-signed-template
Version: 1.1.0-6
Severity: serious
There is still one syntax error in the `Depends` field of the source
package template (the `}`):
Depends: ..., fwupd (= 1.1.0-6})
^^^
This resulted in a build failure for
Package: fwupd-amd64-signed-template
Version: 1.1.0-6
Severity: serious
There is still one syntax error in the `Depends` field of the source
package template (the `}`):
Depends: ..., fwupd (= 1.1.0-6})
^^^
This resulted in a build failure for
Package: fwupd-amd64-signed-template
Version: 1.1.0-5
Severity: serious
>From the code signing service:
+---
| dpkg-source: error: source package has two conflicting values -
fwupd-amd64-signed and fwupd-signed-amd64
+---
d/changelog and d/control use different source package names.
This
Package: fwupd-amd64-signed-template
Version: 1.1.0-5
Severity: serious
>From the code signing service:
+---
| dpkg-source: error: source package has two conflicting values -
fwupd-amd64-signed and fwupd-signed-amd64
+---
d/changelog and d/control use different source package names.
This
Package: fwupd-amd64-signed-template
Version: 1.1.0-4
Severity: serious
The source template for code signing contains invalid Build-Depends:
Build-Depends: ... fwupd (= ) [amd64]
The version is missing. The same problem occurs in `Depends` too:
Depends: ... fwupd (= })
Ansgar
Package: fwupd-amd64-signed-template
Version: 1.1.0-4
Severity: serious
The source template for code signing contains invalid Build-Depends:
Build-Depends: ... fwupd (= ) [amd64]
The version is missing. The same problem occurs in `Depends` too:
Depends: ... fwupd (= })
Ansgar
Ian Jackson writes:
> Apropos of discussion in #813471:
> Paul writes:
>> In addition, d-i relies on access to the apt repo for the system.
>> I can imagine other uses of that, so I added a carve-out for that.
>
> In general I think this should be done by saying that packages may
> access the apt
Ian Jackson writes:
> Apropos of discussion in #813471:
> Paul writes:
>> In addition, d-i relies on access to the apt repo for the system.
>> I can imagine other uses of that, so I added a carve-out for that.
>
> In general I think this should be done by saying that packages may
> access the apt
Todd Fleisher writes:
> I’m seeing this as well and suspect it is due to the GPG sub-key
> ADD6B7E2 having been revoked. I am not sure why this has been done,
> perhaps ftpmaster can provide some context?
ADD6B7E2 is an encryption subkey. As this is not used, it was revoked
later (in 2014).
Package: pdftk-java
Version: 0.0.0+20180620.1-1
+---
| Files: java/pdftk/com/*
|...
| License: LGPL-2+ or MPL-1.1
+---[ debian/copyright ]
But there is no mention of MPL-1.1 in the source files. There is
however a script to remove the MPL-1.1 dual-license (as allowed):
Control: reopen -1
Control: reassign -1 spl 0.7.9-3
Control: retitle -1 spl: conflicts with splat, but should not
"D. R. Evans" writes:
> Marked as important, since this problem prevents installation here, so the
> program cannot be used.
>
> Synaptic reports that installation of this package
Hi Jonathan,
On Fri, 2018-07-20 at 07:47 +0100, Jonathan Dowland wrote:
> On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote:
> > On Friday, 20 July 2018 12:50:12 AM AEST Jonathan Dowland wrote:
> > > Have you read Matthew Vernon's reply to OP in this thread? Does
> > > that not
> > >
Matthew Vernon writes:
> We shouldn't need to have numbers of people having to justify why a
> particular thing is offensive before we (as a project) try and fix
> it.
That works if Debian was a non-diverse groups where everyone had similar
views on what is offensive. In that case the maintainer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 18 Jul 2018 23:21:57 +0200
Source: valgrind
Binary: valgrind valgrind-dbg valgrind-mpi
Architecture: source
Version: 1:3.13.0-2.1
Distribution: unstable
Urgency: high
Maintainer: Alessandro Ghedini
Changed-By: Ansgar
Hi,
I can confirm that the patch referenced at [1] seems to fix the problem
(upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).
I'll try to prepare a NMU for valgrind; maybe already this evening if I
have time. The package isn't usable in the current state.
Ansgar
[1]
Hi,
I can confirm that the patch referenced at [1] seems to fix the problem
(upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).
I'll try to prepare a NMU for valgrind; maybe already this evening if I
have time. The package isn't usable in the current state.
Ansgar
[1]
Control: reassign -1 qa.debian.org
Control: user qa.debian@packages.debian.org
Control: usertag -1 + udd
On Thu, 2018-07-05 at 15:40 +0200, Georges Khaznadar wrote:
> I got a notification, Message-Id: org>,
> that:
>
> ---8<--
> expeyes 4.3.7+dfsg-2 is
201 - 300 of 7426 matches
Mail list logo
