Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.general,gmane.linux.debian.devel.release as well. Chris Hofstaedtler writes: > you are probably aware of the time_t-64bit migration :-) > However, this does not magically transition all data formats to 64bit > times. One such instance is the set of utmp/wtmp and lastlog files. > > Thorsten Kukuk and others have been working on replacements for the > existing file formats and interfaces [1]; these are called wtmpdb > and lastlog2. > > Some parties have requested that we do something in Debian [2]. If > we use Thorsten's work (and why not?) > Thorsten's code introduces new PAM modules to manage the new files, > so it should transparently work with most packages. Later, the > old interfaces can probably be turned off. > On the wiki [0] I have summarized what I know; a list of initial > work items; and some open questions mostly concerned with upgrading. > > I invite you to read the wiki page and the background info, to > identify gaps the chkrootkit package provides several utilities for examining some of these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does not use pam but reads the files in /var/log How would I test these against the new files - i assume the new versions are compatable but might need bigger variables in those utilities? (any assistance with that review is welcome - C is not my thing!) [a] You can read these here --- https://salsa.debian.org/pkg-security-team/chkrootkit but nb that there are many patches in debian/patches that touch these (use gbp pq import to see the patched versions) > [0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb > [1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/ > [2] https://bugs.debian.org/1068017 Richard
Bug#1064394: release-notes: English language output for the commands into script session
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.documentation as well. Franco writes: > " If you are comfortable with English language it's strongly > recommended that you run the following command as soon as you start > the 'script' session: > > # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE > > This will allow you to get command output messages in English into > the script session. By doing so, it will help you for searching the > web, during discussions or to submit a bug report." Are we *sure* this is a good idea - i have some doubts? -- "strongly recommended" by who? where did anyone previously make this recommendation and why do they feel so strongly that it is needed in 2024 when it has not been suggested before? -- does anyone test the upgrade with this locale setting? telling people to use something less tested seems like a bad idea.eg, i have LANG=en_GB.UTF-8 would i still want to change locales? -- why are we suggesting non-english message are somehow less clear? if so, we should remove translations not hide them? -- why are we making the output harder to read for the user - that will make it harder for them to fix their own issue. isnt this is the opposite of what we want? -- isnt it better to say that if you get an error in non-english to search the web for the english vesion? it's not like you cant look-up the english version of the error message -- are we suggesting errors are likely? that isnt my experience with debian upgrades (maybe it makes more sense to do this if the upgrade fails and you can't debug)
Bug#1060006: ITP: brpc -- Apache's brpc - Industrial-grade RPC framework
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.general as well. Didier 'OdyX' Raboud writes: > * Package name: brpc > Version : 1.7.0 > Upstream Contact: d...@brpc.apache.org > * URL : https://brpc.apache.org/ > * License : Apache-2.0 > Programming Lang: C++ > Description : Industrial-grade RPC > Apache bRPC is often used in high performance systems such as Search, > Storage, Machine learning, Advertisement, Recommendation, etc > > (the short and long descriptions' are really bad; suggestions welcome! suggestions: - say what it is for - why would i install it? - See also guide at http://jbr.me.uk/linux/esl.html (section F) specifics: - avoid hyperbole like "industrial-grade", "high performance" - if it means something specific - fast? reliable? follows some standard? - say that, else avoid. I dont think "high performance systems such as X, Y, Z" with "such as" works unless "X, Y, Z" are the names of "high-performance systems" --- perhaps "Search" is (bad) shorthand for "systems for searching ", but "machine learning" is not really a "system". "Advertisement" could mean several things - is this software for producing adverts? (maybe "such as for" is better, but I think how people have used something is much less interesting that what features the something provides. And is "often" based on any data?) - avoid jargon - or at least explain what "RPC" means - unless it's to do with the apache web-server, or part of the name, the word "Apache" may be confusing. (if it's a module try and copy their descriptions).
Bug#932957: Please migrate Release Notes to reStructuredText
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.documentation as well. James Addison writes: > (someone who knows more may correct me, but I think it would be great to have > the package available for install using apt in addition to the website) Interesting idea, but who would use it - won't a release-notes package always be a whole release out of date? (and the build-dependencies take a huge amount of disk space for something you only read once a cycle, alhtough maybe sphinx fixes that)
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Ansgar writes: > On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote: >> My plan is therefore to ship i386 installer images >> for bookworm as normal (including bookworm point releases going >> forwards), but to disable those builds for testing/trixie >> ~immediately after the release. > > I suggest to already document this in the release notes for bookworm, > possibly in Section 2.1 (Supported architectures) or a subsection in > Section 5 (Issues to be aware of for bookworm). I suspect few would re-read 2.1 on upgrade... but is release-notes is the best place to document what new installs can use? (maybe doesnt matter as there wont be any new installs!) > Maybe something along these lines: > > +--- > | Debian 12 is expected to be the last Debian release providing > | full support for i386. Debian 13 will only partially support > | i386 and no longer provide installation media for i386. > | > | We recommend hosts still running the i386 port to be upgraded > | to amd64. Legacy i386 software can be run using multi-arch, > | chroot environments or containers. > +--- We already have a bit about i386 now meaning i686, but i think OK to keep separate as that one is bookworm, and this is for the future Adding links to explain jargon and adding markup: im hope ive got the right arch-related entities right here... Bookworm is the last Debian release with full support for The next release, trixie, will not have full support for the architecture, for example there will be no official installer. Debian recommends converting systems using the architecture to the 64-bit PC architecture (known as amd64) before bookworm becomes unsupported: most computers manufactured since 2000 can use amd64. You can still run legacy 32-bit software on 64-bit systems using containers or in multi-arch chroots. (but shld use the entity for wiki links) Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no longer supports 32-bit Xen PV guests) also relevent to the last para.
Bug#1023596: bookworm: document changes in default rsyslog configuration
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.
Michael Biebl writes:
> The rsyslog configuration changed significantly in bookworm.
Hi, I'd potentially be happy to contribute some text for release-notes
on rsyslog. Some questions based on what i'd want to know as an
interested user:
Are both rsyslog and systemd's journal still both the default in bookworm?
I see rsyslog is still priority: important - any plans to reduce that in
future releases?
(Have reordered the below based on what seems most important to me):
> * Enable high precision timestamps with timezone information.
> Use the default rsyslog file format, which provides several benefits
> like:
> - sortable
> - time zone information
> - sub-second time resolution
> (Closes: #475303)
(this would seem to break every single logcheck rule too)
> * Stop splitting up mail.*
> This avoids having mail related messages duplicated in mail.log and
> mail.{info,warn,err}. (Closes: #508376)
I think the impact here depends on the mta:
- debian's default mta is exim4
- postfix is a popular alternative
- /var/log/mail.{info,warn,err}* can be deleted after the upgrade (or is this
done by the upgade?)
Details:
For exim4, logging was in /var/log/exim4 (and mail.err was duplicating
paniclog,
others not used but are created as empty files)
For postfix, logging was in /var/log/mail.log and duplicated in all/some
of /var/log/syslog and mail.{info,warn,err}* (unchecked - based on the
bug report)
Other mtas are likely to be similar to either exim or postfix - but is
there any mta that only uses mail.*?
(For all these we should be clear that the user dosnt need to delete
anything and should check what is being used)
> * Stop splitting lpr facility into its own log file.
> The default printing system CUPS is not using this facility so its
> basically unused nowadays.
Am i right that
- cups is installed by the default gnome desktop task: anyone using that is
not affected as the /var/log/lpr.log is not created
- systems without any printing systems are likely not affected
(lpr.log will not exist)
- people who have installed some alternative printing system (is there any?)
can now delete /var/log/lpr.log* and find log messages about printing
in syslog (or do other systems expect lpr.log to exist?)
> * Drop catch-all log files /var/log/{messages,debug}
> * Stop splitting daemon facility into its own log file.
Similarly (but nothing to do with mtas) users can delete these logs -
the second being /var/log/daemon.log
> * Split cron facility into its own log file /var/log/cron.log.
> The cron facility is widely used and limited enough in scope to have it
> split out separately. (Closes: #625483)
This one affects everyone using cron (including anacron). but isnt
there some lintian warning that anaccron is no longer installed for
desktop users? (which should be in release-notes i assume)
I assume that for bookwork, systemd timers are not yet ready to replace
cron jobs by default
Regards
Bug#1018943: release-notes: document systemd packaging changes for Bookworm
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.
Some thoughts on clarity - from a user pov, given that people reading
release-notes will not be familiar with details:
Luca Boccassi writes:
> systemd-resolved has been split into a separate package.
> This new systemd-resolved package will not be installed automatically
s/This/The
> on upgrades. If you are using systemd-resolved, please install this
s/are/were
s/this/the
> new package manually
after manually i'd suggest adding "after the upgrade"
and does this change impact people who were using systemd-resolved and
are upgrading over ssh or other remote ways: will they be at risk of
losing their DNS until they install the new package?
>. By installing this package, systemd-resolved will
> take over control of /etc/resolv.conf automatically.
Found the above sentence a little cryptic - think the word "over" is
redundant. Ideally, i'd suggest what it needs is one sentence
explanation of what systemd-resolved is (its man page is a bit of a
jargon-fest - is it just "manages the settings in /etc/resolv.conf"?)
I think it might also help to explain what the debian "default" here is
(even if it didnt change): Is it that resolve.conf is managed "by hand"
unless network manager is installed?
> systemd-boot has been split into a separate package.
> This new systemd-boot package will not be installed automatically on
> upgrades. If you are using systemd-boot, please install this new
> package manually.
As above - "the new package" and "were using" (or - "if you want to use"
might be clearer (here and above)
> The default boot loader in Debian is grub2.
should this end "is still grub2, but systemd-boot can be used instead"?
and is grub2 the right package - on my (current stable) system, "apt
show grub2" tells me it is a transitional package that is going to be
removed - should it say "grub-pc" instead of grub2 here?
> If you have not set up systemd-boot manually, no action is required on
> your side.
"on your side" is not idiomatic/clear - better to end the sentence at
"no action is required".
but is "set up manually" different from "installed"? ("set up" sounds
like some positive action has been taken to edit configuration files,
and "manually" might even mean "not using apt" - but i'm not sure that
is what is meant...)
as above, can it explain (briefly) what a "boot loader" is for those
that don't know (like me) - and how do i tell which one i am using? is
there some reason to prefer systemd-boot over grub or vice-versa?
I'd suggest something like: "A bootloader is responsible for starting
the kernel when the system boots"?
(it says "bootloader" rather than "boot loader" in the description of
grub-pc - not sure which is standard)
And i suggest that this stanza needs to be _very_ explicit about whether
or not systems that were using systemd-boot will become unbootable until
the user installs the new systemd-boot package? (seems pretty important
to clarify to me, even if the answer is that there is no risk!).
> systemd-journal-gatewayd and systemd-journal-remote are now built
> without the --trust option, in order to be able to switch away from
> gnutls to openssl.
Does it need a new heading: "Changes to the systemd journal"? (I almost
missed this the first time i read it)
it's also not very transparent: what command is '--trust' an option for?
(i didnt see it in 'journalctl(1)') and what impact does removing it have?
Eg, is it saying that the systemd journal was using gnutls and is now
using openssl, or is it saying that this change will be done in the
future? (as a user, i'm not sure that such a change is important enough
for the release notes - seems more like something for debian/changelog,
but perhaps i am missing something?)
Thanks for considering
Bug#745082: chfn and fakechroot
write me a qa script?
RL/rl
On 02/21/2015 06:08 PM, jhcha54008 wrote:
Le samedi 21 février à 03h 50mn 23s (+0100), John Paul Adrian Glaubitz a écrit :
On 02/21/2015 12:24 AM, jhcha54008 wrote:
May I ask if debootstrap ran in a fakechroot environment or as real root ?
I haven't tried fakechroot, but the debootstrap call was done using the
real root user. What makes you so sure this is actually an issue with
fakechroot? I just tried --variant=fakechroot on my main amd64 machine
and that worked without any issues.
Adrian
I guess you encountered a different bug : 774332, 745082, 763391
occur when running debootstrap as an unprivileged user
with option --variant=fakechroot
(And the chfn error gives a line
chfn: PAM: System error
in file debootstrap/debootstrap.log)
Does
# perl -e 'system(/usr/bin/chfn,-f,systemd Time
Synchronization,systemd-timesync);'
works as real root in a chroot on sh4 ?
(It seems that in functions sh_gecos file /usr/sbin/adduser lines 924-944
and systemcall file /usr/share/perl5/Debian/AdduserCommon.pm lines 158-166
all quotes are removed in the diagnostic
my $c = join(' ', @_);
print ($c\n) if $verbose==2;
but were kept in the actual call line 161 of
/usr/share/perl5/Debian/AdduserCommon.pm :
if (system(@_)) {
)
I just tried --variant=fakechroot on my main amd64 machine
and that worked without any issues.
I cannot reproduce this (I still encouter the bug).
May I ask if your ran debootstrap --variant=fakechroot
as real root or as an unprivileged user ?
I hope it will help !
Regards,
JH Chatenet
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#64141: See What You Missed Out In 2008
Make your lady squeal with desire with your brand new pecker http://www.purrpletele.com/ So wet and pink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
