Processed: closing 757882
Processing commands for cont...@bugs.debian.org: > close 757882 0.255 Bug #757882 [cdebconf] pkgsel: [text frontend] No feedback right after selecting the software tasks Marked as fixed in versions cdebconf/0.255. Bug #757882 [cdebconf] pkgsel: [text frontend] No feedback right after selecting the software tasks Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 757882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757882 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed (with 1 error): Re: Bug#757882: pkgsel: [text frontend] No feedback right after selecting the software tasks
Processing control commands: > reassign -1 cdebconf Bug #757882 [pkgsel] pkgsel: [text frontend] No feedback right after selecting the software tasks Bug reassigned from package 'pkgsel' to 'cdebconf'. No longer marked as found in versions pkgsel/0.42. Ignoring request to alter fixed versions of bug #757882 to the same values previously set > done -1 0.255 Unknown command or malformed arguments to command. -- 757882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757882 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#757882: pkgsel: [text frontend] No feedback right after selecting the software tasks
Control: reassign -1 cdebconf Control: done -1 0.255 Samuel Thibault, le lun. 11 août 2014 23:53:02 +0200, a ecrit: > Right after answering the "Software selection" tasksel question, one > does not get any feedback, so the user is wondering whether it's > installing anything. I fixed this within cdebconf, forcing progress feedback after questions. Samuel
Bug#856060: Please don't use obsolete libsysfs-dev any more
Hi! On Sun, 2017-04-09 at 10:17:41 +0200, Philipp Kern wrote: > On 02/24/2017 11:05 PM, Michael Biebl wrote: > > Some years ago libsysfs (source package: sysfsutils) was written as an > > abstraction layer for accessing /sys/. However, this turned out to be > > a historical error and evolutionary dead end: It does not actually > > abstract anything (it's just as specific to the Linux kernel and a > > particular version thereof as /sys itself), and just adds unnecessary > > complexity, RAM overhead, and bugs. Thus its development has ceased > > years ago, in favor of programs just using /sys as it is. Upstream development for sysfsutils is still going, they have f.ex. merged all patches Debian was carrying, plus several cleanup patch series I've sent, and have done new upstream releases. As the current maintainer in Debian I do not consider it obsolete, and would encourage anyone to use it, in preference of having to manually parse stuff from /sys. > > In fact, most applications probably don't want to access /sys at all, > > but use libudev [1] or gudev [2] instead. These provide a better API > > for device enumeration, properties, and callbacks for hardware > > changes. > > I can see how we ended up here, but it still does abstract something > away: access to sysfs, avoiding bugs in accessing it from C in the process. Indeed. So from my side, if you'd like to switch to something else, for whatever reason, that's fine, but if you'd rather keep using libsysfs, then that should also be fine. Thanks, Guillem
Bug#905793:
Please check your email and reply to my previous email thanks.
Re: Should /boot be ext2, instead of ext4?
On Sat, 2021-08-07 at 16:24 +0200, John Paul Adrian Glaubitz wrote: > Hi Hideki! > > > On Aug 7, 2021, at 4:12 PM, Hideki Yamane > wrote: > > > > I've found that d-i creates /boot as ext2 for guided partioning > > with LVM. I think ext4 is better but is there any reason to do so? > > (e.g. some architecture or bootloader cannot recognize ext4 for it) > > It’s normally a bootloader compatibility issue but since we switched > many architectures over to GRUB where possible, it might no longer be > necessary to use ext2 for /boot. > > I will have to go through the list of bootloaders currently in use > and I’ll let you know. [...] This is bug #985463. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#992034: init choice in Debian installation instructions
Hi, as the content for the release notes was suggested to be put into the Wiki (instead?) anyway, how about, to lower translator burden, there *will* be put a section about this into the installation guide, but one that is mostly comprised of a link to the Wiki, with a short intro. @Matthew: that’s most certainly an em dash there; normally, you render an em dash as U+2014 surrounded by U+200A (hair space) on both sides (some US-american publishers seem to omit the hair spaces; in Tₑχ/LᴬTᴇΧ I personally realise them as ⅙em which may be slightly wider than the hair spaces of some publishers but find this makes it easier to read). Now I have no idea how this is best done in the sources for the Debian installation guide… bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
