On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote:
> Among others, "command -v"
[...]
> * built-ins get reported as available. And busybox has even "dpkg"
> built-in, with a pretty bad implementation.
Like this?
+---
| % which which
| which: shell built-in command
+---
I suggest to
David Steele writes:
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote:
>> Given topydo just provides/conflicts with devtodo to provide the "todo"
>> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
>> the same functionality.
[...]
> From where I stand, I would expect the
David Steele writes:
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote:
>> Given topydo just provides/conflicts with devtodo to provide the "todo"
>> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
>> the same functionality.
[...]
> From where I stand, I would expect the
As requested on IRC.
===
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.
___
Pkg-utopia-maintainers mailing list
Package: debian-policy
9.1.2 recommends the following to create a directory under /usr/local:
```
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if test -e /etc/staff-group-for-usr-local ; then
if chown root:staff
Package: debian-policy
9.1.2 recommends the following to create a directory under /usr/local:
```
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if test -e /etc/staff-group-for-usr-local ; then
if chown root:staff
Ben Hutchings writes:
> The code signing service logs every file it signs, along with a hash of
> the detached signature, but I don't know where the logs are so I can't
> comapre with that.
I checked the audit log, but I don't think it will help much. It
currently records that:
- 2019-10-21
Ben Hutchings writes:
> The code signing service logs every file it signs, along with a hash of
> the detached signature, but I don't know where the logs are so I can't
> comapre with that.
I checked the audit log, but I don't think it will help much. It
currently records that:
- 2019-10-21
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 23 Oct 2019 19:13:24 +0200
Source: dune-pdelab
Architecture: source
Version: 2.6~20180302-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Changes:
dune-pdelab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 14 Oct 2019 23:27:35 +0200
Source: dune-common
Architecture: source
Version: 2.6.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Closes: 936456
Changes:
dune
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 13 Oct 2019 15:17:06 +0200
Source: dune-grid
Architecture: source
Version: 2.6.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Changes:
dune-grid (2.6.0-5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 13 Oct 2019 11:58:26 +0200
Source: alberta
Architecture: source
Version: 3.0.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Closes: 878199
Changes:
alberta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 09 Oct 2019 17:57:13 +0200
Source: dune-grid
Architecture: source
Version: 2.6.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Closes: 942000
Changes:
dune
Package: debian-policy
Version: 4.4.1.1
Severity: minor
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
Package: debian-policy
Version: 4.4.1.1
Severity: minor
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
Package: texlive-fonts-extra
Version: 2019.20190930-2
Severity: serious
Hi,
when upgrading in Debian testing I saw the following error message:
+---
| Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ...
| dpkg: error processing archive
Package: texlive-fonts-extra
Version: 2019.20190930-2
Severity: serious
Hi,
when upgrading in Debian testing I saw the following error message:
+---
| Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ...
| dpkg: error processing archive
Package: clamav-daemon
Version: 0.101.4+dfsg-1
Severity: normal
After a user asked something about clamav on IRC, I noticed that
clamav-daemon's postinst creates a file
/etc/systemd/system/clamav-daemon.service.d/extend.conf with static
content:
+---
| echo "#Automatically Generated by
Package: clamav-daemon
Version: 0.101.4+dfsg-1
Severity: normal
After a user asked something about clamav on IRC, I noticed that
clamav-daemon's postinst creates a file
/etc/systemd/system/clamav-daemon.service.d/extend.conf with static
content:
+---
| echo "#Automatically Generated by
Package: src:runit
Version: 2.1.2-34
Severity: serious
I noticed that the last runit build is already taking over 13h on
buildds. The hppa build log[1] looks like the build failed due to an
endless loop.
I asked the other builds to be killed.
Ansgar
[1]
Package: src:runit
Version: 2.1.2-34
Severity: serious
I noticed that the last runit build is already taking over 13h on
buildds. The hppa build log[1] looks like the build failed due to an
endless loop.
I asked the other builds to be killed.
Ansgar
[1]
Control: reassign -1 debian-policy
The section on initscripts has too much implementation details about
/etc/rcn.d; these are better explained by external documentation.
Also the rationale for why `DISABLED=yes` (or similar) fits better
into a footnote than the main text (IMHO).
(Policy also
Package: bugs.debian.org
Severity: minor
Tags: upstream
It looks like debbugs always appends the bug report's msgid to the
`References` field when sending a follow-up message to the bug. This
should not be done when the msgid is already listed there.
(I noticed because this broke DKIM
Control: reassign -1 debian-policy
The section on initscripts has too much implementation details about
/etc/rcn.d; these are better explained by external documentation.
Also the rationale for why `DISABLED=yes` (or similar) fits better
into a footnote than the main text (IMHO).
(Policy also
Package: bugs.debian.org
Severity: normal
Tags: patch
The section on initscripts has too much implementation details about
/etc/rcn.d; these are better explained by external documentation.
Also the rationale for why `DISABLED=yes` (or similar) fits better
into a footnote than the main text
Package: gnome-terminal
Version: 3.34.0-1
Severity: minor
Tags: upstream
Changing the font size in one tab has an effect of other tabs: when
switching from tab A (with larger font size) to tab B (regular font
size), I can see that tab B gets restored with the larger font size
and is only then
Package: gnome-terminal
Version: 3.34.0-1
Severity: normal
Tags: upstream
I have a laptop with an external screen; internal and external screen
have different resolutions and DPI.
Since a recent update gnome-terminal and other GNOME applications use
the DPI from the wrong screen when the window
Johannes Ernst writes:
> I've been running the same systemd-nspawn container for some time, always
> with the same options:
>
> systemd-nspawn -b -n -D dir -M name --bind /home -x
>
> It would always bring up the virtual ethernet link immediately during
> boot of the container. But since a
Package: dkimpy-milter
Version: 1.0.1-1
Severity: wishlist
Tags: upstream
Hi,
a recent mail to -devel@ resulted in the following header from dkimpy-milter:
Authentication-Results: [...]; dkim=fail (Bad 1024 bit rsa-sha256
signature.) header.d=[...] header.a=rsa-sha256
However the domain
Control: tag -1 moreinfo
Control: retitle -1 ftp.debian.org: `dak process-policy new` loses .buildinfo
files
The title says "loses .buildinfo files", but the IRC log says:
> tar tf /srv/ftp-master.debian.org/queue/done/2019/02.tar.xz | grep
> liblogger-simple-perl
>
Russ Allbery writes:
> Scott Kitterman writes:
>> Except that we have different requirements than git. Git isn't looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related
Package: tor
Version: 0.3.5.8-1
Severity: normal
Tags: upstream
Hi,
I found the following warning in my log files:
+---
| Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at
../src/core/or/channeltls.c:. Stack trace: (on Tor 0.3.5.8 )
| Tor[2185]: Bug:
the same way as tag2upload does, AFAICT.
That is true and I don't like it. I should probably add a sha2 hash
somewhere. (Note that we *can* just change it...)
> On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:
> > It also has one downside: `git tag` alone won't be enough to gene
Russ Allbery writes:
> Ansgar Burchardt writes:
>> The client tool could possibly also just create the .dsc and .changes,
>> except for hashes of the compressed files, and the web service just
>> recreate the tarball and compress them.
>
> I think experience
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Russ Allbery writes:
>>> If so, I think that security model is roughly equivalent to the
>>> automatic signing of binary packages by buildds, so probably doesn't
>>> introduce a new vulnerability,
>
>
Russ Allbery writes:
> If so, I think that security model is roughly equivalent to the automatic
> signing of binary packages by buildds, so probably doesn't introduce a new
> vulnerability,
It doesn't rely on strong cryptographic hashes to guarantee integrity.
To quote Wikipedia:
+---
|
Russ Allbery writes:
> Matthias Klumpp writes:
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process
Curt Howland writes:
> I know some kinks will work out, but seriously, /sbin is not in root's
> path by default?
/sbin is in root's path by default. However Debian now uses a different
implementation of `su` which no longer changes PATH by default:
+---
| - new 'su' (with no args, i.e. when
On Thu, 2019-07-11 at 17:58 -0300, Antonio Terceiro wrote:
> > We designed and implemented a system to make it possible for DDs to
> > upload new versions of packages by simply pushing a specially
> > formatted git tag to salsa.
[...]
> If the uploads will be done by a service, this means that all
Package: gnupg
Version: 2.2.12-1
Severity: normal
Tags: upstream
>From man:gpg(1):
+---
| This format is deduced from the length of the string and its content
| or the 0x prefix. Note, that only the 20 byte version fingerprint
| is available with gpgsm (i.e. the SHA-1 hash of the certificate).
On Thu, 11 Jul 2019 13:26:34 +0200 Laurent Bigonville wrote:
> My understanding of the policy is that, if a package supports an
> alternative init (other than systemd) it must also support sysvinit.
>
> Also note that if the check is actually correct, this will create false
> positive for all the
On Thu, 11 Jul 2019 13:26:34 +0200 Laurent Bigonville wrote:
> My understanding of the policy is that, if a package supports an
> alternative init (other than systemd) it must also support sysvinit.
>
> Also note that if the check is actually correct, this will create false
> positive for all the
Package: release-notes
Severity: normal
For bullseye, the security suite is now named bullseye-security
instead of buster/updates and users should adapt their sources.list
accordingly when upgrading.
People should probably use something like
deb http://security.debian.org/debian-security
Package: release-notes
Severity: normal
For bullseye, the security suite is now named bullseye-security
instead of buster/updates and users should adapt their sources.list
accordingly when upgrading.
People should probably use something like
deb http://security.debian.org/debian-security
Package: release-notes
Severity: normal
For bullseye, the security suite is now named bullseye-security
instead of buster/updates and users should adapt their sources.list
accordingly when upgrading.
People should probably use something like
deb http://security.debian.org/debian-security
Package: popularity-contest
Version: 1.67
Severity: wishlist
Hi,
it would be nice if popularity-contest would report which foreign
architecture are enabled, i.e. the list `dpkg
--print-foreign-architectures` should report.
In particular I'm interested in seeing how many people have enabled
i386
Package: ftp.debian.org
Removing packages from experimental when a newer version is available in
unstable should only happen after the package has been in unstable for a
few days.
This works around https://bugs.debian.org/865304 (too early removal of
overrides). It also keep binaries available
Aidan Gauland writes:
> I have a user service for running xautolock that does not start on login
> reliably, and I have no idea why, because there is no error message,
> just an exit code of 1. (Unit file and output of systemctl status
> attached.) Any suggestions on what to do next to
Philipp Kern writes:
> 20/06/2019 20:22, Ansgar Burchardt wrote:
>> You look up which uid the _apt user inside the chroot has and use that.
>
> Yeah, but that scales poorly if you have a centralized firewall
> policy. It means that you need to maintain dynamic rules. I know it's
Philipp Kern writes:
> 20/06/2019 20:22, Ansgar Burchardt wrote:
>> You look up which uid the _apt user inside the chroot has and use that.
>
> Yeah, but that scales poorly if you have a centralized firewall
> policy. It means that you need to maintain dynamic rules. I know it's
Hans writes:
> I am running denbian/testing and dicovered, that /var/log/auth.log is got
> spammed with the message, that /lib/security/pam_ck_connector.so is missing.
>
> And yes, it is really missing. However, libpam-ck-connector can not be
> installed (due to dependencies of systemd).
Trek writes:
> Ansgar Burchardt wrote:
>> For limiting network access, I would recommend instead using network
>> namespaces (to only provide limited network access for all processes)
>> and/or user namespaces (if filtering for single UIDs is really
>> needed). Th
Trek writes:
> Ansgar Burchardt wrote:
>> For limiting network access, I would recommend instead using network
>> namespaces (to only provide limited network access for all processes)
>> and/or user namespaces (if filtering for single UIDs is really
>> needed). Th
Package: apt,dselect
Severity: normal
Hi,
[ X-Debbugs-Cc'ed -boot@ for debootstrap ]
today I learned that debootstrap as special code to create the file
/var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
setup_dselect_method in functions. It seems wrong that debootstrap
has
Package: apt,dselect
Severity: normal
Hi,
[ X-Debbugs-Cc'ed -boot@ for debootstrap ]
today I learned that debootstrap as special code to create the file
/var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
setup_dselect_method in functions. It seems wrong that debootstrap
has
Package: apt,dselect
Severity: normal
Hi,
[ X-Debbugs-Cc'ed -boot@ for debootstrap ]
today I learned that debootstrap as special code to create the file
/var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
setup_dselect_method in functions. It seems wrong that debootstrap
has
On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote:
> This reminds me of something that popped up in a dinner discussion a few
> days ago: mandate documenting workflow in debian/README.source no matter
> what, and allow to symlink that file to a repository in
> /usr/share/doc/somewhere/ as we do
Michael Biebl writes:
> On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote:
>> I'm just a GNOME user, but from gdm3's changelog the default was
>> switched to Wayland in July 2017 (or August 2017 for unstable). I
>> myself only noticed the switch after reading
Michael Biebl writes:
> On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote:
>> I'm just a GNOME user, but from gdm3's changelog the default was
>> switched to Wayland in July 2017 (or August 2017 for unstable). I
>> myself only noticed the switch after reading
Ansgar Burchardt writes:
> (I don't maintain debootstrap.)
>
> I don't think it is a good idea to require debootstrap to know about
> such details.
>
> For limiting network access, I would recommend instead using network
> namespaces (to only provide limited network acc
Ansgar Burchardt writes:
> (I don't maintain debootstrap.)
>
> I don't think it is a good idea to require debootstrap to know about
> such details.
>
> For limiting network access, I would recommend instead using network
> namespaces (to only provide limited network acc
Michael Schaller writes:
> At the end of the 'apt' package installation the '_apt' user will be
> created without specifying a fixed uid. This typically results in a
> differing '_apt' uid between the host system and the bootstrapped
> system. The differing '_apt' uid is problematic in case the
Michael Schaller writes:
> At the end of the 'apt' package installation the '_apt' user will be
> created without specifying a fixed uid. This typically results in a
> differing '_apt' uid between the host system and the bootstrapped
> system. The differing '_apt' uid is problematic in case the
Russ Allbery writes:
> Colin Watson writes:
>> Is it at all likely that the ftpmaster api service might migrate away
>> from Let's Encrypt at this point? I would assume probably not. In that
>> case, you could at least make the situation substantially better with no
>> further DSA work required
Jonathan Dowland writes:
> So far as I am aware there is still radio silence from active GNOME
> packaging team members regarding this issue. No comment yet on the
> patch I adapted, positive or negative; this bug (#927667) remains
> at an RC severity.
>
> I've not yet read all the thread that
Jonathan Dowland writes:
> So far as I am aware there is still radio silence from active GNOME
> packaging team members regarding this issue. No comment yet on the
> patch I adapted, positive or negative; this bug (#927667) remains
> at an RC severity.
>
> I've not yet read all the thread that
Jonathan Dowland writes:
> So far as I am aware there is still radio silence from active GNOME
> packaging team members regarding this issue. No comment yet on the
> patch I adapted, positive or negative; this bug (#927667) remains
> at an RC severity.
>
> I've not yet read all the thread that
Mattia Rizzolo writes:
> On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
>> The .buildinfo files are referred to in the .changes files; renaming
>> them would require updating the .changes file. The .changes files are
>> used to upload the security
Mattia Rizzolo writes:
> On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
>> The .buildinfo files are referred to in the .changes files; renaming
>> them would require updating the .changes file. The .changes files are
>> used to upload the security
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote:
> > This behaviour is really causing issues for the security-archive so in
> > one way or the other there needs to be a solution. Regularly we need
> > to fetch the buildd changes and build binary packages, resign them and
> > reupload
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote:
> > This behaviour is really causing issues for the security-archive so in
> > one way or the other there needs to be a solution. Regularly we need
> > to fetch the buildd changes and build binary packages, resign them and
> > reupload
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote:
> > This behaviour is really causing issues for the security-archive so in
> > one way or the other there needs to be a solution. Regularly we need
> > to fetch the buildd changes and build binary packages, resign them and
> > reupload
Package: libopenblas-base
Version: 0.3.5+ds-3
Severity: important
File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0
Tags: upstream
OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually
available, causing programs to crash with SIGILL:
+---
| Thread 1 "cholmodtest" received signal
Package: libopenblas-base
Version: 0.3.5+ds-3
Severity: important
File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0
Tags: upstream
OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually
available, causing programs to crash with SIGILL:
+---
| Thread 1 "cholmodtest" received signal
Package: src:coinor-ipopt
Version: 3.11.9-2.1
Severity: wishlist
The Debian version of IPopt lags quite a bit behind upstream: Debian
still ships 3.11.9 (released 2014-08-16); the current upstream release
is 3.12.13 (released 2019-04-08), but there were several releases in
between that were not
Package: src:coinor-ipopt
Version: 3.11.9-2.1
Severity: normal
I had some problems with IPopt using the sequential version of MUMPS
recently: as MUMPS provides dummy `MPI_*` functions, my program ended
up using some of them or MUMPS used some of the real MPI functions.
As mentioned in IPopt's
:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstr
:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstr
Paul Wise writes:
> On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote:
>> Instead, if there is indeed consensus, we should change it so that it
>> no longer says that doc-base registration is recommended.
>
> We need a cross-distro cross-desktop standard for an index of
> docs before we can
Paul Wise writes:
> On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote:
>> Instead, if there is indeed consensus, we should change it so that it
>> no longer says that doc-base registration is recommended.
>
> We need a cross-distro cross-desktop standard for an index of
> docs before we can
Hi,
On Mon, 2019-05-13 at 12:38 +0200, Maximilian Batz wrote:
> I believe to have found a typo in the following line:
>
> Users can also install a complete unit file
> to /etc/systemd/system/foo.service. Systemd then uses it instead
> of /lib/systemd/systemd/foo.service.
>
> I believe it should
Ian Jackson writes:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
>> `ar` needs to be replaced for the file size limitation mentioned in the
>> initial mail: ar represents file size as a 10 digit decimal number[1]
>> which limits the members (control.tar.*, data.tar.*) to
Vipul writes:
> I've been using Debian from couples of years but haven't contributed
> yet back to community. I want to contribute to Debian by maintaining
> packages and fixing bugs. Since I'm using Debian for work purpose also
> so, I don't want to mess-up with my system by installing unstable
>
Sam Hartman writes:
>> "Ansgar" == Ansgar writes:
>
> Ansgar> Sam Hartman writes:
> >> I'm having a bit of trouble here and am hoping you can help us
> >> out. Ian asked what git workflow it is that you're talking about
> >> where people can deal with commit push and pull
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote:
> [ Ansgar: If you still can reproduce the assertion failure, please
> file
> a new bug. It's better not to mix different issues in the same report ].
The other assertion failure I had also disappeared this week. Not sure
if there is a
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote:
> [ Ansgar: If you still can reproduce the assertion failure, please
> file
> a new bug. It's better not to mix different issues in the same report ].
The other assertion failure I had also disappeared this week. Not sure
if there is a
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote:
> [ Ansgar: If you still can reproduce the assertion failure, please
> file
> a new bug. It's better not to mix different issues in the same report ].
The other assertion failure I had also disappeared this week. Not sure
if there is a
Harald Dunkel writes:
> I am running a local mirror of the security.debian.org
> repository for in-house use. It seems to be available for
> Buster as well, except that there is an error message
>
> ERROR: Condition '7638D0442B90D010' not fulfilled for
>
On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
>
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
>
> > As an example: to update to a new upstream release, I ideally just have
> > to drop the new upstream tarball, update d/changelog and am done.
> > Compare with [1] which is much more
Control: reassign -1 src:dune-pdelab 2.6~20180302-1
Control: retitle -1 dune-pdelab: testpk fails with assertion failure
On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote:
> This is a bug in dune-istl, though I'm not quite sure I understand
> what
> is exactly wrong.
Control: reassign -1 src:dune-pdelab 2.6~20180302-1
Control: retitle -1 dune-pdelab: testpk fails with assertion failure
On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote:
> This is a bug in dune-istl, though I'm not quite sure I understand
> what
> is exactly wrong.
Keith Bainbridge writes:
> I see the point that people who like gnome should be allowed to use it
> -
> so withdraw the drop gnome from debian. I believe the change to the
> subject line will keep the discussion together. I'll re-send if it
> opens a new topic.
Why should GNOME not stay the
Gene Heskett writes:
> On Tuesday 16 April 2019 13:32:38 Ansgar Burchardt wrote:
>> Gene Heskett writes:
>> > Where the heck in its confusing menu's can I find a tab supporting
>> > terminal so I can get something done? Go ahead, find it, my coffee
>> > ne
Gene Heskett writes:
> Where the heck in its confusing menu's can I find a tab supporting
> terminal so I can get something done? Go ahead, find it, my coffee needs
> to cool anyway..
You press the magic Super key, then type "Terminal" on the keyboard (or
at least the beginning), then press
Niels Thykier writes:
> We need new archive signing keys for buster, so we can include them in
> a debian-archive-keyring upload before the buster release.
The two keys are prepared; I'm waiting for a few more signatures from
other ftp masters.
FWIW they will be:
pub rsa4096 2019-04-14 [SC]
Niels Thykier writes:
> We need new archive signing keys for buster, so we can include them in
> a debian-archive-keyring upload before the buster release.
The two keys are prepared; I'm waiting for a few more signatures from
other ftp masters.
FWIW they will be:
pub rsa4096 2019-04-14 [SC]
On Thu, 2019-04-11 at 11:49 +0200, Guido Günther wrote:
> E.g. for amd64 and stretch we'd have a file
>
>http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo
>
> looking like
>
> [checksums]
> current/images/netboot/mini.iso = sha256:...
>
Control: reassign -1 src:dune-istl 2.6.0-2
Control: affects -1 src:dune-pdelab
Santiago Vila writes:
> /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches
> 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const
> Dune::Amg::AggregatesMap&,
Control: reassign -1 src:dune-istl 2.6.0-2
Control: affects -1 src:dune-pdelab
Santiago Vila writes:
> /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches
> 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const
> Dune::Amg::AggregatesMap&,
Control: reassign -1 src:dune-istl 2.6.0-2
Control: affects -1 src:dune-pdelab
Santiago Vila writes:
> /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches
> 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const
> Dune::Amg::AggregatesMap&,
1 - 100 of 7426 matches
Mail list logo
