Lang: Rust
Description : access control for Microsoft Azure link-local network
services
The Azure guest proxy agent provides access control to potentially sensitive
wireserver and instance metadata link-local HTTP endpoints within the Microsoft
Azure cloud environment.
This packaged will be
programs, and boot was used to start vmunix. Debian inherited this for
> > > > compatibility, but the situation has changed a lot. Today, boot is
> > > > stored in the root directory as a directory, which already contains the
> > > > kernel files vmlinuz and init
On Thu, Nov 14, 2024 at 04:39:28PM +0100, Iustin Pop wrote:
Indeed. But even the comment, by itself, I think raises a question - why
do we (still) do this?
Because there's very little incentive to change it.
, but the situation has changed a lot. Today, boot is
> stored in the root directory as a directory, which already contains the
> kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
> vmlinuz and initamfs to the root directory, so the best way is to remove
> them fr
ot was used to start vmunix. Debian inherited this for
> > > compatibility, but the situation has changed a lot. Today, boot is
> > > stored in the root directory as a directory, which already contains the
> > > kernel files vmlinuz and initramfs. Therefore, it makes no sense to
On Nov 12, Iustin Pop wrote:
> The question is why on a default install with grub, which doesn't need
> nor use the symlinks, are they still created. For most systems, they're
> superfluous.
>
> iustin, who also dislikes these and always needs to disable them
Agreed.
--
ciao,
Marco
signature
ty, but the situation has changed a lot. Today, boot is
> > stored in the root directory as a directory, which already contains the
> > kernel files vmlinuz and initramfs. Therefore, it makes no sense to link
> > vmlinuz and initamfs to the root directory, so the best way is to
directory as a directory, which already contains
the kernel files vmlinuz and initramfs. Therefore, it makes no sense
to link vmlinuz and initamfs to the root directory, so the best way is
to remove them from the root directory.
You may alter /etc/kernel-img.conf however you wish.
Hi!
On Tue, 2024-11-12 at 11:02:53 +0100, Johannes Schauer Marin Rodrigues wrote:
> Quoting Hans (2024-11-12 09:35:08)
> > However, maybe a link is alo no more needed, even with a seperated /boot
> > partition.
>
> It's just a symlink. What's the harm?
For
Quoting Hans (2024-11-12 09:35:08)
> However, maybe a link is alo no more needed, even with a seperated /boot
> partition.
It's just a symlink. What's the harm?
Having the symlink is very practical for bootloaders that are not grub.
Pointing an extlinux.conf or a boot.scr to /vm
On Tue, Nov 12, 2024 at 09:35:08AM +0100, Hans wrote:
> Am Dienstag, 12. November 2024, 07:14:34 CET schrieb kindusmith:
> In very early linux, as far as I remember in SuSE-Linux, the kernel was
> installed in a small partition /boot (about 3 or 4 sizes of the kernel) and a
> link po
Am Dienstag, 12. November 2024, 07:14:34 CET schrieb kindusmith:
In very early linux, as far as I remember in SuSE-Linux, the kernel was
installed in a small partition /boot (about 3 or 4 sizes of the kernel) and a
link ponting to the kernel on the root-partitiion (the one, mounted to "/&qu
Geert Stappers writes:
> Chesters fence
Chesterton's?
Bjørn
gt; the root directory as a directory, which already contains the kernel files
> vmlinuz and initramfs. Therefore, it makes no sense to link vmlinuz and
> initamfs to the root directory, so the best way is to remove them from the
> root directory.
Chesters fence
files vmlinuz and initramfs. Therefore, it makes no sense to link
vmlinuz and initamfs to the root directory, so the best way is to remove
them from the root directory.
On Fri, 2024-08-16 at 16:54 +0100, Colin Watson wrote:
> On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> > I think it probably was just a coincidence, since it looks like the
> > change was made in order to fix #1064795 which was reported on
> > 25 Feb 2024.
>
> Ah, good to know, t
Hello,
Anyone not interested in ancient history can skip this mail.
On Thu, Aug 15, 2024 at 11:20:47PM +0100, Colin Watson wrote:
> On 2024-07-14 (five days before the iproute2 change was made), there was
> this conversation on #debian-devel:
>
> 19:14 Is there a reason why iproute2 ships a s
On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote:
Quite. If nothing else, I think the code actually in the Debian archive
that relies on the old path ought to be changed _first_, e.g. via an
MBF. I see a bunch of cases that are relatively subtle and might suck a
lot of other people'
On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> I think it probably was just a coincidence, since it looks like the
> change was made in order to fix #1064795 which was reported on
> 25 Feb 2024.
Ah, good to know, thanks. I didn't notice that since it wasn't
mentioned in the iprou
Colin Watson writes:
> On Thu, Aug 15, 2024 at 11:14:41PM +0530, Nilesh Patra wrote:
>> On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
>> > At 2024-08-15T13:20:02-0400, Michael Stone wrote:
>> > > It's just so depressing that this is how debian works now. We used to
>> > > t
On Thu, Aug 15, 2024 at 11:14:41PM +0530, Nilesh Patra wrote:
> On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> > At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > It's just so depressing that this is how debian works now. We used to
> > > try to not break things, now t
On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote:
> At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > > This change was noted in NEWS.
> > >
> > > I would suggest hooking your config into something that uses the
> > > network-online.target target, with a timeout like network
At 2024-08-15T13:20:02-0400, Michael Stone wrote:
> > This change was noted in NEWS.
> >
> > I would suggest hooking your config into something that uses the
> > network-online.target target, with a timeout like network-manager
> > and networkd do, so that the boot process doesn't hang. If it's a
The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that failed the network was not
configured. This meant having to boot into single use
Package: wnpp
Severity: wishlist
Owner: Matthias Geiger
X-Debbugs-Cc: debian-devel@lists.debian.org, team+...@tracker.debian.org,
werdah...@riseup.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: vim-link-vim
Version : 1.0.3+git20240514
Upstream Contact
package: www.debian.org
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
hi,
On Mon, Mar 06, 2023 at 07:46:43PM +, Holger Levsen wrote:
> [...], there's a single page HTML version available again, eg on
> https://www.debian.org/doc/manuals/developers-reference/developers-referen
-2.0
Programming Lang: golang
Description : Link controllers with executors across a mesh of nodes
Receptor is an overlay network intended to ease the distribution
of work across a large and dispersed collection of workers.
Receptor nodes establish peer-to-peer connections with each other
: Python
Description : Finds remote link-local IPv6 address in point-to-point IPv6
network
`lsip6` is a `ls` for link-local IPv6 addresses
This is very handy in finding e.g. USB connected mobile phone
even without DHCP set up.
.
It sends a ICMPv6 (ping) to ff02::1
(all devices on link
On Tue, Jul 19, 2022 at 05:15:32PM +, Thorsten Glaser wrote:
> Matthias Klose dixit:
> >The goal is to enable this optimization by default in an upcoming
> >Debian release in dpkg-buildflags for 64bit architectures. The goal
> >is to get this package to build with link t
Matthias Klose dixit:
>The goal is to enable this optimization by default in an upcoming
>Debian release in dpkg-buildflags for 64bit architectures. The goal
>is to get this package to build with link time optimizations, or to
>explicitly disable link time optimizations for this p
Adrian Bunk:
> On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote:
...
>
> >...
> > Link time
> > optimizations are also at least turned on in other distros like Fedora,
> > OpenSuse (two years) and Ubuntu (one year).
> >...
> > The idea is
On Fri, Jun 17, 2022 at 12:40:34PM +0300, Nicholas Guriev wrote:
> LTO significantly increase memory requirements for buildd machines. Do we
> have
> enough RAM and swap on each build server?
>
> > Link time optimizations are also at least turned on in other distros like
&g
On Fri, Jul 01, 2022 at 07:52:16PM +0300, Adrian Bunk wrote:
> On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote:
> > The proposal is to turn on LTO by default on most 64bit release
> > architectures.
>
> By what factor does -ffat-lto-objects increase disk space usage during
> packag
Hi Matthias,
* Matthias Klose [2022-06-17 10:18]:
The proposal is to turn on LTO by default on most 64bit release
architectures. Not proposing to do this on 32bit architectures because
of the limited address space at link time, and up to now nobody tested
LTO on 32bit archs. In test
ure that the buildds on these
architectures have sufficient diskspace.
amd64 buildds have/had(?) only 74 GB of diskspace, which has even
without LTO already forced some packages to do manual cleanup steps
during the build to stay within the limited disk space.
>...
> Link time
> optimizati
LTO significantly increase memory requirements for buildd machines. Do we have
enough RAM and swap on each build server?
> Link time optimizations are also at least turned on in other distros like
> Fedora, OpenSuse (two years) and Ubuntu (one year).
I know Ubuntu has builders with 8 GB R
Link time optimizations are an optimization that helps with a single digit
percent number optimizing both for smaller size, and better speed. These
optimizations are available for some time now in GCC. Link time optimizations
are also at least turned on in other distros like Fedora, OpenSuse
Programming Lang: Python
Description : Plugin for MkDocs to automatically link across pages
MkDocs is a fast, simple and downright gorgeous static site generator
that's geared towards building project documentation. Documentation
source files are written in Markdown, and configured w
iHTH https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652
Hi Florian,
On Sat, Dec 04, 2021 at 01:59:14PM +0100, Florian Weimer wrote:
> It is as architecture-independent as ldconfig or getconf. Perhaps a bit
> more so than getconf.
Both of those are bad examples as both are lies. An amd64 ldconfig
really does not handle arm64 libraries at all. I'd rath
dy an ld.so manual page, although it's in section 8 and 1.
>> (I think /usr/bin is still appropriate because running ld.so does not
>> require special privileges.)
>>
>> The initial implementation will be just a symbolic link. This means
>> that multi-arch suppo
x27;s already an ld.so manual page, although it's in section 8 and 1.
> (I think /usr/bin is still appropriate because running ld.so does not
> require special privileges.)
>
> The initial implementation will be just a symbolic link. This means
> that multi-arch support will be m
* Helmut Grohne:
> Hi Florian,
>
> On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
>> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
>> mentioned below. I think this is the way to go. Some care will be
>> needed to avoid endless loops, but that should be it
Hi Florian,
On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
> mentioned below. I think this is the way to go. Some care will be
> needed to avoid endless loops, but that should be it.
Can I ask you to go int
On Fri, Dec 03, 2021 at 05:59:17PM +0100, Florian Weimer wrote:
> * Theodore Y. Ts'o:
>
> > * How does ld.so --preload *work*?
>
> The dynamic loader has an array of preloaded sonames, and it processes
> them before loading the dependencies of the main program. This way,
> definitions in the pre
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
> We
so saying it's
> architecture-agnostic is still a bit of a stretch.
We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
mentioned below. I think this is the way to go. Some care will be
needed to avoid endless loops, but that should be it.
Things will break if people lin
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote:
> Some stupid questions that I couldn't answer by reading the man page
> or doing a quick google search
> * How does ld.so --preload *work*?
ld.so is the ELF interpreter. If you run a normal binary, the kernel
rewrites this req
On Fri, Dec 03, 2021 at 04:16:04PM +0200, Timo Lindfors wrote:
> Just a random thought: If you have configured a restricted shell (e.g.
> rbash) that only lets you execute commands in PATH, will this make it
> possible to bypass the restriction with "ld.so /tmp/some-random-binary"?
> This is not ne
* Theodore Y. Ts'o:
> * How does ld.so --preload *work*?
The dynamic loader has an array of preloaded sonames, and it processes
them before loading the dependencies of the main program. This way,
definitions in the preloaded objects preempt definitions in the shared
objects.
> * Does it modify
t; The initial implementation will be just a symbolic link. This means
> that multi-arch support will be missing: the amd64 loader will not be
> able to redirect execution to the s390x loader.
... or to the i386 loader, which is probably a concern for more people
(that affects Red Hat-style m
On Fri, Dec 03, 2021 at 02:46:27PM +0100, Bastian Blank wrote:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> > Right, thanks for providing a concrete example. A (somewhat) portable
> > version would look like this:
> > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/
Hi,
On Fri, 3 Dec 2021, Florian Weimer wrote:
No objects to /usr/bin/ld.so then?
Just a random thought: If you have configured a restricted shell (e.g.
rbash) that only lets you execute commands in PATH, will this make it
possible to bypass the restriction with "ld.so /tmp/some-random-binary
* Bastian Blank:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
>> Right, thanks for providing a concrete example. A (somewhat) portable
>> version would look like this:
>> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
>
> You mean
> ld.so --preload libeatmydata
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> Right, thanks for providing a concrete example. A (somewhat) portable
> version would look like this:
> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
You mean
ld.so --preload libeatmydata.so.1.3.0 /bin/ls
?
ld.so i
* Paul Wise:
> Florian Weimer wrote:
>
>> I'd like to provide an ld.so command as part of glibc.
>
> Will this happen in glibc upstream or just in Debian?
Upstream, and then Debian. The symbolic link would likely and up in
libc-bin in Debian.
>> Today, ld.so can b
Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.
Will this happen in glibc upstream or just in Debian?
> Today, ld.so can be used to activate preloading, for example.
> Compared to LD_PRELOAD, the difference is that it's specific to one
> process, and won't be inhe
lly okay. And today,
there's already an ld.so manual page, although it's in section 8 and 1.
(I think /usr/bin is still appropriate because running ld.so does not
require special privileges.)
The initial implementation will be just a symbolic link. This means
that multi-arch support will be
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Perl Group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: libhttp-link-perl
Version : 0.001
Upstream Author : David Zurborg
* URL
#
# bts-link upstream status pull for source package general
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#
user debian-bts-l...@lists.debian.org
# remote status report for #992503 (http://bugs.debian.org/992503
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package general
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l..
Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: nbsphinx-link
Version : 1.3.0
Upstream Author : Vidar Tonaas Fauske
* URL : https://github.com/vidartf/nbsphinx-link.git
* License : BSD-3
Hi Sven,
On Sun, Nov 22, 2020 at 11:44:42AM +0100, Sven Joachim wrote:
> On 2020-11-22 11:29 +0200, Wouter Verhelst wrote:
> > What am I missing?
>
> I think this happens because g++ passes --as-needed to the linker in
> unstable, but not in stable. Your test program is compiled with
>
> g++ -o
On 2020-11-22 11:29 +0200, Wouter Verhelst wrote:
> For the past year, I've been (on and off) working with ola upstream on
> getting new-gcc (first 9, then 10) and python3 issues resolved, so that
> I would be able to get it into bullseye again. We're almost there,
> except for one thing that myst
Hi,
For the past year, I've been (on and off) working with ola upstream on
getting new-gcc (first 9, then 10) and python3 issues resolved, so that
I would be able to get it into bullseye again. We're almost there,
except for one thing that mystifies me.
As part of the autopkgtest, I build a small
res to bits/predefs.h, but no "bits" link
or dir in /usr/include
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If
: Prometheus exporter for TP-Link Smart plug metrics
Prometheus exporter for TP-Link Smart Plugs that provide power measurements.
Programming Lang: Go
Description : provides a way to atomically create or replace a file or
symbolic link
The renameio Go package provides a way to atomically create or replace a
file or symbolic link.
.
Atomicity vs durability
---
.
renameio concerns itself only with
Programming Lang: Ruby
Description : Jekyll plugin to add mentionable link support
This is a Jekyll plugin to turn mentions into links. It does not notify the
mentioned user. It is possible to use a social networks, even your own.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA
: GPL-3.0
Programming Lang: C++
Description : Codec for audio on AMBE3000-based devices in packet mode
over a serial link
This library can control the serial interface to the AMBE3000 chip in packet
mode. There are several devices or hardware blocks that implement it. A popular
and easy to
Package: wnpp
Severity: wishlist
Owner: Pirate Praveen
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name : node-apollo-link
Version : 1.2.11
Upstream Author : Evans Hauser
* URL : https://github.com/apollographql/apollo-link#readme
* License : Expat
Programming Lang: JavaScript
On Thu, Dec 13, 2018 at 03:39:40PM +0200, Tommi Höynälänmaa wrote:
> Should the linker option "-Wl,--as-needed" be used for plugins, e.g. guile
> plugins? Debmake suggests using the option for the linker.
Are they actually buildable with that option?
--
WBR, wRAR
signature.asc
Description: PGP
Should the linker option "-Wl,--as-needed" be used for plugins, e.g.
guile plugins? Debmake suggests using the option for the linker.
- Tommi Höynälänmaa
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package general
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l..
Programming Lang: PHP
Description : Link between promises and streams in ReactPHP
-BEGIN PGP SIGNATURE-
iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlr9mH0xGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
Description : network link status notification for Go
ifplugo delivers network interface link information and link
changes. It does this (on Linux) by using code from ifplugd
(http://0pointer.de/lennart/projects/ifplugd/) to gather the necessary
status information, then emits a status summary
escription : OpenSource ST-Link tools replacement
Open source version of the STMicroelectronics Stlink JTAG/SWD flashing
and debugging tools for STM32VL and STM32L. The transport
layers STLINKv1 and STLINKv2 are supported.
A shared library for developers, a command line and a GUI (GTK) tool
are p
Programming Lang: JavaScript
Description : It is a standalone library for "gently" remove or link
directories. Performs filesystem operations "gently".
.
Node.js is an event-based server-side JavaScript engine.
Praveen agreed to sponsor this package.
On Tue, Jun 06, 2017 at 01:01:29PM +0100, Steve McIntyre wrote:
>[ Note Reply-To: set to d-devel ]
>
>Hey,
>
>For a number of years, we've been linking to the amd64/i386 netinst
>installer image from the front page. I think it's time to just switch
>that to just an amd64 image for stretch now. The
On Wed, Jun 07, 2017 at 03:12:54PM +0200, Marc Haber wrote:
> On Tue, 6 Jun 2017 13:41:31 +, Holger Levsen
> wrote:
> >On Tue, Jun 06, 2017 at 09:38:29AM -0400, Nikolaus Rath wrote:
> >> Personally, I would only ever download a DVD image if I was on a *slow*
> >> connection and knew that I had
On Tue, 6 Jun 2017 17:39:42 -0500, Gunnar Wolf
wrote:
>I'll chime in to what others have said. I think DVD images should not
>be the default/main download venue. Even though the careful package
>ordering by (alleged?) popularity, I am sure a great deal of Debian
>installs use under half of the pac
On Tue, 6 Jun 2017 13:41:31 +, Holger Levsen
wrote:
>On Tue, Jun 06, 2017 at 09:38:29AM -0400, Nikolaus Rath wrote:
>> Personally, I would only ever download a DVD image if I was on a *slow*
>> connection and knew that I had to install to multiple machines.
>
>still then, I would rather use n
On Tue, Jun 06, 2017 at 06:43:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Jun 2017, Adam Borowski wrote:
> > No one installs i386 new -- machines that are non-amd64-capable are:
> > * mainstream machines from 2004 and earlier
>
> That date is incorrect. I can't give you a precise
I'll chime in to what others have said. I think DVD images should not
be the default/main download venue. Even though the careful package
ordering by (alleged?) popularity, I am sure a great deal of Debian
installs use under half of the packages provided by the first DVD (and
many that are not ther
On Tue, Jun 06, 2017 at 06:43:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Jun 2017, Adam Borowski wrote:
> > No one installs i386 new -- machines that are non-amd64-capable are:
> > * mainstream machines from 2004 and earlier
>
> That date is incorrect. I can't give you a precise
> [ Note Reply-To: set to d-devel ]
(answering only to said list)
> Hey,
Hiya,
> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page. I think it's time to just switch
> that to just an amd64 image for stretch now. The vast majority of the
>
On Tue, 06 Jun 2017, Adam Borowski wrote:
> No one installs i386 new -- machines that are non-amd64-capable are:
> * mainstream machines from 2004 and earlier
That date is incorrect. I can't give you a precise date, but the
Thinkpad T43 with a 32-bit Centrino Pentium-M was **launched** in
April/2
On Jun 06, Steve McIntyre wrote:
> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page. I think it's time to just switch
> that to just an amd64 image for stretch now. The vast majority of the
> machines out there are now amd64, and we're aski
m, you're reinstalling a buggered up
system thus know what you're doing. It's no different from installing on
alpha, mips or powerpc. Thus, secondary architectures should be kept out
of the view of newbies (with a convenient link for the rest).
> I'm *also* tempted to
On Tue, Jun 06, 2017 at 09:38:29AM -0400, Nikolaus Rath wrote:
> Personally, I would only ever download a DVD image if I was on a *slow*
> connection and knew that I had to install to multiple machines.
still then, I would rather use netinst plus a proxy…
--
cheers,
Holger
signature.
On Jun 06 2017, Steve McIntyre wrote:
> I'm *also* tempted to switch from the netinst to the first DVD image
> instead - network connections have improved a lot.
Why is that relevant? Is installing+downloading the DVD image faster
than downloading netint + installing from network?
Personally, I
On 06/06/17 13:01, Steve McIntyre wrote:
> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page. I think it's time to just switch
> that to just an amd64 image for stretch now.
Seems sensible.
> I'm *also* tempted to switch from the netinst to
On Tue, Jun 6, 2017 at 8:01 PM, Steve McIntyre wrote:
> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page.
Seems reasonable, perhaps with a small link for other options.
> I'm *also* tempted to switch from the netin
[ Note Reply-To: set to d-devel ]
Hey,
For a number of years, we've been linking to the amd64/i386 netinst
installer image from the front page. I think it's time to just switch
that to just an amd64 image for stretch now. The vast majority of the
machines out there are now amd64, and we're asking
On Fri, Jan 6, 2017 at 3:27 AM, Sean Whitton wrote:
> Could you explain "lower bus factor" a bit more, please?
Don already explained this for the BTS, but in general, many if not
most of the services Debian provides are maintained by 0.5 person (one
busy person who already has lots of other respo
On Thu, 05 Jan 2017, Sean Whitton wrote:
> Right, but I'd like to hear a bit more from Paul about this is
> relevant for the spam issue.
Currently only Blars and myself are doing anything with the spam in the
BTS. [And I have very limited time which I'm spending primarily on BTS
development and ke
Hello Christian,
On Thu, Jan 05, 2017 at 08:51:01PM +0100, Christian Seiler wrote:
> On 01/05/2017 08:27 PM, Sean Whitton wrote:
> > On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
> >> The solution is simply a lower bus factor in all Debian services,
> >> including the BTS [...]
> >
>
On 01/05/2017 08:27 PM, Sean Whitton wrote:
> On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
>> The solution is simply a lower bus factor in all Debian services,
>> including the BTS [...]
>
> Could you explain "lower bus factor" a bit more, please?
https://en.wikipedia.org/wiki/Bus_f
Hello Paul,
On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
> The solution is simply a lower bus factor in all Debian services,
> including the BTS [...]
Could you explain "lower bus factor" a bit more, please?
--
Sean Whitton
signature.asc
Description: PGP signature
On Tue, Jan 3, 2017 at 5:38 PM, Abou Al Montacir wrote:
> What about requiring signed mail for closing a bug report?
We have sponsored maintainers, who theoretically could get by entirely
without an OpenPGP key. I don't know if any exist but I don't think
they should be blocked from -done. Also,
1 - 100 of 467 matches
Mail list logo
