Hey.
Just for the records and those who stumble over this and are interested
in the outcome.
upstream clarified fstab syntax in:
https://github.com/util-linux/util-linux/commit/43a6b183d8945cc91307f21adc8070254eb925b5
- whether the 4th field is mandatory is now in kind of a limbo... the
manpag
On Wed, 2023-03-29 at 15:46 +0200, Cyril Brulebois wrote:
> Closing as not a bug. If you want an actual bug to get fixed, please
> file a specific bug report, describing what's not working correctly.
Well you could call usage of a non-documented option a bug, but if
improvement is apparently not d
On Wed, 2023-03-29 at 03:38 +, David wrote:
> I think the formal specification of the fstab format would be
> 'man 3 getfsent' because that is the canonical method to
> parse /etc/fstab.
Uhm, but that doesn't really describe which fields are necessary
either. So it would be the actual code whi
On Wed, 2023-03-29 at 02:25 +, David wrote:
> My thought process is as follows:
> Field 4 is for mount options. This is just the same as providing
> options to the 'mount' command issued at the command line.
> And it is ok to use the 'mount' command without options.
Well that's clear and it pr
On Wed, 2023-03-29 at 01:41 +, David wrote:
> Yes, for many years using Debian stable, my swap lines in
> /etc/fstab look like this:
> none swap
Hmm, I'm not sure whether strictly speaking it's allowed to skip the
4th field.
The manpage explicitly documents so for the 5th and the 6th, but n
On Wed, 2023-03-29 at 00:49 +, David wrote:
> In that situation, field 4 has to be non-blank, which is when setting
> it
> to "defaults" becomes useful.
>
> Otherwise, putting "defaults" in field 4 achieves nothing, because
> defaults
> are defaults so there is no reason to specify them.
Does
Source: debian-installer
Version: 20230217
Severity: minor
Hey.
In the end this is probably anyway completely ignored, so consider this
just a cosmetic issue:
AFAICS, the installer cretes swap entries in fstab as:
none swap sw 0 0
https://salsa.debian.org/installer-team/partman-basicfilesyst
On Wed, 2022-01-12 at 16:55 +, Chris Boot wrote:
> I was going to vimdiff the configs
> to see what we might need to change and harmonise between them.
That sounds like a good idea... and I guess it would be reasonable to
keep everything identical, and for the cases where this is really not
d
Hey Chris.
Shouldn't this also done in at least the config for the static
busybox... and likely also the udeb?
(I can of course make a PR if that helps.)
Similarly, udeb doesn't set CONFIG_DESKTOP=y which affects POSIX
correctness (see #995833).
Cheers,
Chris.
Package: busybox
Version: 1:1.30.1-7+b2
Severity: wishlist
Hey.
Today, 1.35 was released.
Would be nice to see that upgraded :-)
Thanks,
Chris.
Strange, I thought I had replied to this:
> This is bug #981302 (which I thought we'd actually fixed already).
> I don't think busybox needs to change.
The two are not really the same. The other ticket is just about the
missing symlinks... but uudecode is really not even intended to use
that fil
On Fri, 2021-11-19 at 20:02 +0100, Ben Hutchings wrote:
> This is bug #981302 (which I thought we'd actually fixed already). I
> don't think busybox needs to change.
I think that would only be a workaround... and a potentially unsafe
one, as the files could still be not around (or have been accid
Package: busybox
Version: 1:1.30.1-7+b1
Severity: wishlist
Hi.
Could you please enable CONFIG_BASE64?
base64 is normally guaranteed to be avialble because it's part of coreutils.
But it is not in e.g. the initramfs.
While Debian’s busybox has in principle uuencode/uudecode as alternatives
enab
Package: busybox
Version: 1:1.30.1-7+b1
Severity: important
Hey.
Unlike mandated by POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tr.html
busybox' tr in Debian doesn't seem to understand any of the character
classes,...
and I'd guess neither the other formats given in the E
Package: busybox
Version: 1:1.30.1-7+b1
Severity: normal
Tags: upstream patch
Hey.
Since it's unclear whether and when upstream will react and how long it then
takes that this actually lands in Debian, could you possibly consider to
cherry pick the patch I provided at:
https://bugs.busybox.net/s
Package: os-prober
Severity: wishlist
Hey.
I think the following would be a nice feature for os-prober when
it detects other Linuxes:
Also extract their kernel parameters, so that it can be added to
the e.g. grub menu entries.
This sounds easier than may be:
There is no canonical place where
Package: os-prober
Severity: critical
Justification: causes serious data loss
Hey.
AFAIU, os-prober still falls back to using the non grub-mount based probing,
when the later isn't available.
Also os-prober doesn't in anyway depend on grub, so there is absolutely no
guarantee it would be availab
Package: os-prober
Severity: wishlist
Hey.
Given that there are quite a number of bugs open where os-proper
apparently caused critical data loss and destroyed filesystems it
seems to me that it's modus operandi of scanny all block devices
is generally inapparopriate and far to risky.
Not sure w
Control: tags -1 + wontfix
Seeing this "solved" by an opt-in for being secure switch is simply
embarrassing for Debian's already not so shining security philosophies
and paradigms.
There's basically no reason that speaks against doing it properly, i.e.
vice-versa: requiring verification by defaul
On Wed, 2014-10-22 at 01:28 +0100, Steve McIntyre wrote:
> Then you have no clue about what that means.
What exactly do yo refer to?
Not providing a default DE? I rather thought about a solution like the
one the EU enforced on Microsoft with the browser selector:
The interactive debian installa
Hey.
Shouldn't one change then the default rather to something that's
actually working on ALL our platforms,... and not making special
exceptions for GNOME all the way (or would any other software in Debian
be allowed to get that default-status, if it only supports a fraction of
systems (exim for
Package: os-prober
Version: 1.64
Severity: normal
Hi.
On purge, the package doesn't clean up correctly:
Removing os-prober (1.64) ...
dpkg: warning: while removing os-prober, directory '/var/lib/os-prober' not
empty so not removed
$ ls -al /var/lib/os-prober/
total 13k
drwxr-xr-x 2 root root
Hey Joey
On Sat, 2013-06-29 at 14:57 -0400, Joey Hess wrote:
> I'm not talking about building debootstrap to bootstrap some other linux
> distribution. I'm talking about the common practice of using it to
> bootstrap debian from other linux distributions.
Sure... I did the same...
If you use debo
On Sat, 2013-06-29 at 13:43 -0400, Joey Hess wrote:
> debootstrap is used on a wide variety of non-debian systems, which do
> not have it installed, and probably have no trust path to securely
> install the debian keyring.
I don't see why this should cause a problem... AFAIU, right now it must
have
forcemerge 432309 610753 515938
severity 432309 important
stop
Hi.
AFAICS, all these issues (two of them actually reported by myself) are
the same, therefore forcemerging.
It seems that since 1.0.30:
* Recommend debian-archive-keyring, and if it is installed,
default to checking gpg signat
Package: debootstrap
Version: 1.0.52
Severity: wishlist
Tags: upstream
Hi.
It would be nice to have bash completion for debootstrap,
not only for the parameters, but also e.g. for the suites,
the architectures and perhaps taking mirrors out from
/etc/apt/sources.list and /etc/apt/sources.list.d
On Sat, 2013-06-29 at 04:03 +0200, Christoph Anton Mitterer wrote:
> b) Wouldn't it make some sense to use 4 MiB... so that could help a bit
> for better alignment on 4K sector devices?
That part was obviously stupid ^^ ... 1MiB will also be correctly
aligned to 4K sector devices...
Hi folks.
I was making some tests with UEFI and BIOS based systems about how the
Debian installer behaves.
Some questions/ideas:
1) BIOS Boot Partition... it seems you always create it with about 1MiB?
How did you choose that?
a) It seems like a lot, but is it sure that it will be enough in the
Package: debootstrap
Version: 1.0.52
Severity: wishlist
Hi.
Perhaps it would make sense if:
/etc/mtab -> /proc/mounts
was created by debootstrap as a dangling symlink.
Seems not to be worse than not having mtab at all, and when one
bind mounts /proc to the chroot, than it works "out of the box"
Package: console-setup
Version: 1.55
Severity: minor
Hi.
Perhaps this is a non-issue, but maybe you just forgot it :)
The generated /etc/default/console-setup does:
if [ -f /etc/default/keyboard ]; then
. /etc/default/keyboard
fi
while the example /usr/share/doc/console-setup/examples/conso
Hi.
I've basically the same problem,... running sid,.. rebooted...
Config-file:
BMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT="nodeadkeys"
XKBOPTIONS="compose:caps,terminate:ctrl_alt_bksp"
However, ctrl+alt+backspace doesn't kill X
Any ideas?
Cheers,
Chris.
Package: debootstrap
Version: 1.0.10lenny1
Severity: wishlist
Hi.
Although I've chosen wishlist as priority I'd consider this very important:
debootstrap should check Release files by default, and only allow
unsigned Release files, if a special parameter is given.
In that case it would be ni
Package: console-setup
Version: 1.21
Severity: normal
*** Please type your report below this line ***
Hi I've set up console-setup on my laptop with the configuration below.
As soon as /etc/init.d/console-setup start/restart is executed the
Terminus font is loaded correctly, but when I switch t
Does anybody investigate in this bug?
It actually happens twice when booting (both time the same messages).
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2007-07-09 at 14:56 +0200, Frans Pop wrote:
> On Monday 09 July 2007 13:38, Christoph Anton Mitterer wrote:
> > - I think it would be an improvement if debootstrap would per default
> > use the standard debian-archive-keyring for validating the Release
> > files.
Hi Frans.
That happens when I make long lists with headwords about possible
bugs/enhancements that i finally submit all at one rainy day like today
*G*
After having a closer look at debootstrap again I remember what I really
wanted to suggest *G*:
- I think it would be an improvement if debootstr
Package: debootstrap
Version: 1.0.0
Severity: wishlist
Hi.
Most packages in the Debian archive depend/suggest/recommend on
deboostrap an no
t on cdebootstrap. Thus it is somewhat like the "default" bootstrapping
tool.
It should provide support for signed release files as cdebootstrap
does.
Or it
37 matches
Mail list logo
