Package: matrix-synapse
Version: 0.99.2-1
Severity: normal
matrix-synapse installs several programs with fairly generic names to
/usr/bin, for example:
generate_config
hash_password
move_remote_media_to_new_store.py
I suggest that these are either moved to /usr/lib/matrix-synapse or
Steve McIntyre writes:
> Please unblock package fwupd
Please also unblock
fwupd-amd64-signed/1.2.5+2
fwupd-arm64-signed/1.2.5+2
fwupd-armhf-signed/1.2.5+2
fwupd-i386-signed/1.2.5+2
at the same time.
Ansgar
Steve McIntyre writes:
> Please unblock package fwupdate
Please also unblock
fwupdate-amd64-signed/12+4
fwupdate-arm64-signed/12+4
fwupdate-armhf-signed/12+4
fwupdate-i386-signed/12+4
at the same time.
Ansgar
Steve McIntyre writes:
> Please unblock package fwupd
Please also unblock
fwupd-amd64-signed/1.2.5+2
fwupd-arm64-signed/1.2.5+2
fwupd-armhf-signed/1.2.5+2
fwupd-i386-signed/1.2.5+2
at the same time.
Ansgar
Steve McIntyre writes:
> Please unblock package fwupdate
Please also unblock
fwupdate-amd64-signed/12+4
fwupdate-arm64-signed/12+4
fwupdate-armhf-signed/12+4
fwupdate-i386-signed/12+4
at the same time.
Ansgar
On Thu, 2019-03-21 at 13:17 +0100, Ansgar Burchardt wrote:
> Git in Debian actually links (L)GPL-3+ libraries:
>
> /usr/lib/git-core/git-remote-https links libtasn1.so.6; libtasn1.so.6
> is distributed under non-trivial terms (according to its Debian
> copyright file):
&
On Thu, 2019-03-21 at 10:04 +0100, Florian Weimer wrote:
> * Ansgar Burchardt:
>
> > People have argued before that this applies to Debian. In that
> > case
> > Debian wouldn't be able to distribute binaries of GPL-2-only
> > programs
> > linking against any G
Paul Jakma writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>> #include
>> int main(void) { zlog_rotate(); return 0; }
>>
>> is not an adaption of any GPL code. It is fully written by my
>> own.
>
> It is written by you, and you have copyright in it (in some way, I
> have the vague idea there
Dear debian-legal@,
suppose I compile the following trivial GPL-2-only program:
+---
| #include
| int main() { throw std::exception(); }
+---
Then the resulting binary program links (among other things) against
libstdc++6, licensed under GPL-3+ with runtime exception.
The GPL requires the
On Wed, 20 Mar 2019 15:59:40 + Dimitri John Ledkov
wrote:
> On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt wrote:
> > Hi,
> >
> > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> > than just libpq5: just looking at a small
On Wed, 20 Mar 2019 15:59:40 + Dimitri John Ledkov
wrote:
> On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt wrote:
> > Hi,
> >
> > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> > than just libpq5: just looking at a small
Hi,
On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote:
> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> than just libpq5: just looking at a small sample of the direct rdeps
> of
> libssl1.1, one can find the following GPL-licensed prog
Hi,
On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote:
> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> than just libpq5: just looking at a small sample of the direct rdeps
> of
> libssl1.1, one can find the following GPL-licensed prog
Hi,
the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
than just libpq5: just looking at a small sample of the direct rdeps of
libssl1.1, one can find the following GPL-licensed programs linking it:
cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete
Also amanda-client,
Hi,
the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
than just libpq5: just looking at a small sample of the direct rdeps of
libssl1.1, one can find the following GPL-licensed programs linking it:
cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete
Also amanda-client,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 18 Mar 2019 09:17:24 +0100
Source: mumps
Architecture: source
Version: 5.1.2-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers
Changed-By: Ansgar Burchardt
Changes:
mumps (5.1.2-5) unstable
Ben Hutchings writes:
> On Wed, 2019-03-13 at 12:07 +, Debian FTP Masters wrote:
>> linux source: lintian output: 'license-problem-gfdl-invariants
>> Documentation/media/uapi/fdl-appendix.rst invariant part is:
>> published by the free software .. foundation, with no invariant
>> sections, no
Package: openssh-client
Version: 1:7.9p1-6
Severity: normal
The file "This is a [file].txt" (w/o quotes) exists on `remote`.
The following does no longer work:
$ scp remote:'./"This is a [file].txt"' blubb
protocol error: filename does not match request
These however do still work:
$
Package: debian-policy
Version: 4.3.0.2
Severity: normal
Policy 10.5 (Symbolic links) currently has two classes of requirements:
Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).
The historic
Package: debian-policy
Version: 4.3.0.2
Severity: normal
Policy 10.5 (Symbolic links) currently has two classes of requirements:
Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).
The historic
Package: ftp.debian.org
Severity: normal
secure-boot-code-sign.py leaks database sessions. This leads to
failure when processing several packages.
I've attached the traceback.
Ansgar
ERROR:root:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line
Package: src:mandos
Version: 1.8.3-2
Severity: serious
d/rules modifes d/control during build:
```
override_dh_shlibdeps-arch:
[...]
dpkg --compare-versions $$gnutls_version lt 3.6.0 \
&& sed --in-place --expression='s/libgnutls28-dev (>= 3\.6\.6)
| //' debian/control
Package: src:mandos
Version: 1.8.3-2
Severity: serious
d/rules modifes d/control during build:
```
override_dh_shlibdeps-arch:
[...]
dpkg --compare-versions $$gnutls_version lt 3.6.0 \
&& sed --in-place --expression='s/libgnutls28-dev (>= 3\.6\.6)
| //' debian/control
Cyril Brulebois writes:
> Joerg Jaspert (2019-01-19):
>> On 15287 March 1977, Cyril Brulebois wrote:
>> > FTPmasters, please sync the installer from sid to testing:
>> >
>> > dak copy-installer 20190118
>>
>> [ ] dak@fasolo:~$ dak copy-installer 20190118
>>
>> Will copy installer version
Package: lists.debian.org
Severity: minor
Hi,
debian-private uses the following List-Archive field:
List-Archive:
It should be
file://master.debian.org/home/debian/archive/debian-private/
instead.
See also RFC 8089 and in particular the following parts:
+---
|Non-local files:
|
|
Paul Wise writes:
> On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote:
>> I could add a sensible-x-www-browser to be more nice to our user to
>> sensible-utils
>
> We already have a x-www-browser alternative, so sensible-x-www-browser
> would just duplicate that and is thus not needed.
Steve McIntyre writes:
> On Fri, Jan 04, 2019 at 08:37:24PM +0200, Graham Inggs wrote:
>>This sounds like #918157.
>
> Nod. I'm seeing similar behaviour in a few more packages since tihs
> point, too. :-(
As mentioned on IRC: if you want to make sure that it is a problem with
OpenMPI, you can
Steve McIntyre writes:
> On Fri, Jan 04, 2019 at 08:37:24PM +0200, Graham Inggs wrote:
>>This sounds like #918157.
>
> Nod. I'm seeing similar behaviour in a few more packages since tihs
> point, too. :-(
As mentioned on IRC: if you want to make sure that it is a problem with
OpenMPI, you can
Sean Whitton writes:
> On Wed 02 Jan 2019 at 12:29pm +0900, Ansgar Burchardt wrote:
>> I hereby propose to drop section 1.6 Translations and the following
>> sentence: "When translations of this document into languages other
>> than English disagree with the English te
Sean Whitton writes:
> On Wed 02 Jan 2019 at 12:29pm +0900, Ansgar Burchardt wrote:
>> I hereby propose to drop section 1.6 Translations and the following
>> sentence: "When translations of this document into languages other
>> than English disagree with the English te
Package: debian-policy
Version: 4.3.0.1
Severity: normal
Hi,
I hereby propose to drop section 1.6 Translations and the following
sentence: "When translations of this document into languages other
than English disagree with the English text, the English text takes
precedence."
If it is wrongly
Package: debian-policy
Version: 4.3.0.1
Severity: normal
Hi,
I hereby propose to drop section 1.6 Translations and the following
sentence: "When translations of this document into languages other
than English disagree with the English text, the English text takes
precedence."
If it is wrongly
Adam Borowski writes:
> Thus, the wording would be (as proposed by fsateler):
>
> logind: an org.freedesktop.login1 D-Bus API implementation
>
> default-logind: should be provided by the distribution's default logind
> provider (currently pam-systemd)
So any provider of logind would have to
Adam Borowski writes:
> Thus, the wording would be (as proposed by fsateler):
>
> logind: an org.freedesktop.login1 D-Bus API implementation
>
> default-logind: should be provided by the distribution's default logind
> provider (currently pam-systemd)
So any provider of logind would have to
Hi,
Ansgar Burchardt writes:
> emacs26 added support for systemd socket activation (which I'm looking
> forward to use).
I was asked on IRC to test this with the Debian package (1:26.1+1-2).
It works:
After starting the emacs.socket unit, systemd opens the socket:
+---
| [...] /ru
Hi,
Mo Zhou writes:
> Another fortnight has passed. Any update?
Sorry for taking so long; I wanted to put this on our meeting agenda,
but currently don't find much time...
Anyway, the package is now marked to be accepted.
There were some misunderstandings on our side why debug symbols weren't
Package: src:julia
Version: 1.0.2-1
Severity: normal
Hi,
libjuliaX installs files to usr/lib/.../julia and thus has to
Replaces/Breaks every other version libjuliaY. However the point of
package renaming on soname change is that libjuliaX and libjuliaY can
be coinstalled (otherwise a Provides:
Package: src:julia
Version: 0.7.0-2
Severity: serious
Hi,
the source for contrib/windows/7zS.sfx seems to be missing. As the
file is probably not needed for Debian, it could just be removed from
Debian's source tarball.
Ansgar
Package: src:julia
Version: 0.7.0-2
Severity: serious
Hi,
the source for contrib/windows/7zS.sfx seems to be missing. As the
file is probably not needed for Debian, it could just be removed from
Debian's source tarball.
Ansgar
Control: reassign -1 src:linux 4.19.9-1
On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> After an upgrade of linux-image-amd64, which now depends on
> linux-image-4.19.0-1-amd64, on one machine I got:
>
> linux-image-4.19.0-1-amd64 4.19.9-1
>
> but on another machine I got:
>
>
Control: reassign -1 src:linux 4.19.9-1
On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> After an upgrade of linux-image-amd64, which now depends on
> linux-image-4.19.0-1-amd64, on one machine I got:
>
> linux-image-4.19.0-1-amd64 4.19.9-1
>
> but on another machine I got:
>
>
Control: reassign -1 src:linux 4.19.9-1
On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> After an upgrade of linux-image-amd64, which now depends on
> linux-image-4.19.0-1-amd64, on one machine I got:
>
> linux-image-4.19.0-1-amd64 4.19.9-1
>
> but on another machine I got:
>
>
Control: reopen -1
Dmitry Bogatov writes:
> control: tags -1 wontfix
>
> [2014-09-16 18:00] Ansgar Burchardt
>> The symlinks in /etc/rc?.d/* and /etc/default/* are configuration files,
>> but init script themselves are not (and if admins are supposed to modify
>> th
Hi,
I got around to rebuild emacs with libsystemd-dev installed. That is
enough for socket activation to work (with custom emacs.socket file):
+---
| run/user/[...]/emacs [...]
users:(("emacs",pid=26360,fd=3),("systemd",pid=2487,fd=23)) <->
+---( from ss output )
Ansgar
Package: emacs
Version: 1:26.1+1-1
Severity: normal
Hi,
emacs26 added support for systemd socket activation (which I'm looking
forward to use). However looking at the buildd log it seems this
isn't enabled:
+---
| Does Emacs use -lsystemd? no
+---[
On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote:
> I've been looking at using the "Built-Using" tag for dh-fortran-mod.
Why not a
Fortran-Mod: gfortran-7, gfortran-8, flang-42
field or so?
As another example Python has `Python-Version: 3.6, 3.7` (for packages
where this matters;
Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
> dak copy-installer 20181206
Done.
Thanks for your work on d-i :-)
Ansgar
Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
> dak copy-installer 20181206
Done.
Thanks for your work on d-i :-)
Ansgar
Hi,
Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie wrote:
>> > - What is the problem? (broken build for which packages? Just R?)
>>
>> The problem we're aware of is:
>>
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl)
Hi,
Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie wrote:
>> > - What is the problem? (broken build for which packages? Just R?)
>>
>> The problem we're aware of is:
>>
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl)
Hi,
Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie wrote:
>> > - What is the problem? (broken build for which packages? Just R?)
>>
>> The problem we're aware of is:
>>
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl)
Hi,
Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie wrote:
>> > - What is the problem? (broken build for which packages? Just R?)
>>
>> The problem we're aware of is:
>>
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl)
Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean e
Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean e
Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean e
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrm
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrm
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrm
Source: ucspi-tcp
Version: 1:0.88-4
Severity: normal
Vcs-* ist set to https://salsa.debian.org/debian/ucspi-tcp which is a
private repository. Please make the repository publically accessible.
Ansgar
Source: ucspi-tcp
Version: 1:0.88-4
Severity: grave
>From /usr/bin/date@:
+---
| /build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/tcpclient
-RHl0 -- "${1-0}" 13 sh -c 'exec
/build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/delcr <&6' |
cat -v
+---
Similar for
Source: ucspi-tcp
Version: 1:0.88-4
Severity: grave
>From /usr/bin/date@:
+---
| /build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/tcpclient
-RHl0 -- "${1-0}" 13 sh -c 'exec
/build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/delcr <&6' |
cat -v
+---
Similar for
"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for ev
"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for ev
"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for ev
Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in
Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in
Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in
Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>>
>> 1. no usrmerge
>> 1a. no moves at all (no effort needed!)
>> 1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and
Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>>
>> 1. no usrmerge
>> 1a. no moves at all (no effort needed!)
>> 1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and
Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>>
>> 1. no usrmerge
>> 1a. no moves at all (no effort needed!)
>> 1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and
+0100
@@ -1,3 +1,10 @@
+xfce4-session (4.13.1-1.1) UNRELEASED; urgency=medium
+
+ * Explicit pass `RM=/bin/rm` to configure to make build reproducible
+between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Mon, 03 Dec 2018 19:46:56 +0100
+
xfce4-session (4.13.1-1) experimental
+0100
@@ -1,3 +1,10 @@
+xfce4-session (4.13.1-1.1) UNRELEASED; urgency=medium
+
+ * Explicit pass `RM=/bin/rm` to configure to make build reproducible
+between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Mon, 03 Dec 2018 19:46:56 +0100
+
xfce4-session (4.13.1-1) experimental
Package: libmdds-dev
Version: 1.4.3-1
Severity: minor
User: m...@linux.it
Usertags: usrmerge
Hi,
while investigating package builds producing different results on
merged-/usr vs. non-merged-/usr systems, I noticed that libmdds-dev
ships a `Makefile` in /usr/share/doc/libmdds-dev/examples which
Package: libmdds-dev
Version: 1.4.3-1
Severity: minor
User: m...@linux.it
Usertags: usrmerge
Hi,
while investigating package builds producing different results on
merged-/usr vs. non-merged-/usr systems, I noticed that libmdds-dev
ships a `Makefile` in /usr/share/doc/libmdds-dev/examples which
On Mon, 2018-12-03 at 16:35 +0100, Adam Borowski wrote:
> Use cases, for individual packages: (copied from a mail by smcv):
>
> """
> Packages that need to register their login sessions with logind
> (gdm3, lightdm, openssh-server):
> - remove libpam-systemd dependency
> - add
On Mon, 2018-12-03 at 16:35 +0100, Adam Borowski wrote:
> Use cases, for individual packages: (copied from a mail by smcv):
>
> """
> Packages that need to register their login sessions with logind
> (gdm3, lightdm, openssh-server):
> - remove libpam-systemd dependency
> - add
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
Package: anacron
Version: 2.3-26
Severity: normal
anacron.service currently uses KillMode=mixed. It probably should
not.
KillMode=mixed sends SIGTERM to anacron and then SIGKILL to any
processes started by anacron. The default (KillMode=control-group)
would send SIGTERM to all processes which
Package: anacron
Version: 2.3-26
Severity: normal
anacron.service currently uses KillMode=mixed. It probably should
not.
KillMode=mixed sends SIGTERM to anacron and then SIGKILL to any
processes started by anacron. The default (KillMode=control-group)
would send SIGTERM to all processes which
Hi,
please explain what components you are talking about and why they
shouldn't be allowed in Debian.
Ansgar
Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.
There is no "urgent action" required (unlike, say, for the last glibc
Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.
There is no "urgent action" required (unlike, say, for the last glibc
Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.
There is no "urgent action" required (unlike, say, for the last glibc
Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.
If anything then /usr would be the
Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.
If anything then /usr would be the
Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.
If anything then /usr would be the
Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>>
>> A merged-/usr has a /bin → /usr/bin
Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>>
>> A merged-/usr has a /bin → /usr/bin
Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>>
>> A merged-/usr has a /bin → /usr/bin
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what
Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was ena
Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was ena
Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was ena
Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was ena
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 01 Dec 2018 16:20:05 +0100
Source: nvi
Binary: nvi nvi-doc
Architecture: source
Version: 1.81.6-14
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Ansgar Burchardt
Description:
nvi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 01 Dec 2018 16:28:30 +0100
Source: apsfilter
Binary: apsfilter
Architecture: source
Version: 7.2.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Ansgar Burchardt
Description:
apsfilter
101 - 200 of 7426 matches
Mail list logo
