Re: Bits from the Release Team: bookworm freeze dates (preliminary)
Did you mean 2023? Regards Stephan
Re: Bits from the Release Team: bookworm freeze dates (preliminary)
Sorry, the follow-up mails loaded only after I wrote my response. Regards Stephan
Re: Bits from the Release Team: bookworm freeze dates (preliminary)
Leandro Cunha wrote on 15/03/2022 at 23:18:37+0100: > Hi, > > On Tue, Mar 15, 2022 at 7:05 PM Pierre-Elliott Bécue wrote: >> >> >> Leandro Cunha wrote on 15/03/2022 at >> 22:57:39+0100: >> >> > On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue >> > wrote: >> > >> > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: >> > >> > > Dear all, >> > > >> > > We are currently considering the following dates as our freeze >> > > dates. If you are aware of major clashes of these dates with anything >> > > we depend on please let us know. We also like to stress again that we >> > > really would like to have a short Hard and Full Freeze (counting in >> > > weeks, rather than months), so please plan accordingly. If serious >> > > delays turn up during any of the Freeze steps, we rather (partially or >> > > completely) thaw bookworm again than staying frozen for a long time. >> > > >> > > 2023-01-12 - Milestone 1 - Transition and toolchain freeze >> > > 2023-02-12 - Milestone 2 - Soft Freeze >> > > 2023-03-12 - Milestone 3 - Hard Freeze - for key packages and >> > > packages without autopkgtests >> > > To be announced - Milestone 4 - Full Freeze >> > > >> > > On behalf of the Release Team, >> > >> > Hi, >> > >> > OOC, isn't that a bit "too short"? We started to work again in August >> > 2021, it'll be less than two years until the freeze. >> > >> > Less than 1 year to go to milestone 1 starts in January. >> >> I was referring to the delay between the end of the freeze and the next >> hard freeze. > > Ok. Debian has been releasing versions every 2 years for a long time. > I was looking at the site here to remember the dates. > It is a cycle that is being continued. > > https://www.debian.org/releases/ I always have been under the impression it was around 2.5 years between releases, but indeed, this impression was false. Thanks! -- PEB signature.asc Description: PGP signature
Bug#1007766: ITP: mppp -- C++11/14/17/20 library for multiprecision arithmetic
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mppp Version : 0.26 Upstream Authors: 2016-Francesco Biscani URL : https://github.com/bluescarni/mppp * License : MPL-2.0 Description : C++11/14/17/20 library for multiprecision arithmetic Built on top of the GNU multiprecision stack (GMP, MPFR, MPC), mp++ was initially conceived as a GMP wrapper with special focus on performance with small operands. In particular, a small buffer optimisation and custom implementations of basic mathematical primitives are instrumental in achieving a performance increase, with respect to GMP and other integer multiprecision libraries, which can be substantial.
How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
Hi,
the MBF announcement inspired me to check some packages that might be
relevant for me (and started fixing these). I also found some packages
where I was asking myself whether these might be interesting for anyone.
Just to give some example (maintainer in CC - Erik, its not specifically
against your package it was just some example).
The description of imgvtopgm reads:
PalmPilot/III Image Conversion utility
This program can convert, compress, and decompress up to 4-bit grayscale
images for displaying on the PalmPilot. It can take any pbm, pnm, pgm file
generated by the netpbm package and convert it into a suitable image
for the Pilot.
.
Together with netpbm many image formats, including JPEG, PNG, GIF, TIFF
and BMP, could be converted into PDB format. This can be displayed on
PalmPilot/III by viewers like "ImageViewer", "TinyViewer" or "Spec".
I'm not sure whether there are any PalmPilot devices out there. At
least the actual *votes* in popcon[1] is down to zero now. The package
was not uploaded by its maintainer for >10 years. It received an NMU by
Adrian Bunk (in CC as well):
[2022-01-02] imgvtopgm 2.0-9.1 MIGRATED to testing (Debian testing watch)
[2021-12-27] Accepted imgvtopgm 2.0-9.1 (source) into unstable (Adrian Bunk)
[2011-02-23] imgvtopgm 2.0-9 MIGRATED to testing (Debian testing watch)
[2011-02-13] Accepted imgvtopgm 2.0-9 (source i386) (signed by: Erik Schanze)
The changelog of that NMU was:
* Non-maintainer upload.
* debian/rules: Add build-{arch,indep}. (Closes: #999003)
>From my naive perspective this package caused some work from a quite
busy maintainer for no obvious user base. May be I'm wrong in this
specific case but this observation raises my question: Do we have any
means to get rid of packages that should be rather removed from the
distribution than draining resources.
If the answer is no should we possibly use the list of packages that are
not topic of the heated debate around the source format 1.0 (where
maintainers are obviously are caring about their packages just disagree
with format 3.0 format) to pick some packages that should be rather
removed than fixed?
Kind regards
Andreas.
[1] https://qa.debian.org/popcon-graph.php?packages=imgvtopgm
--
http://fam-tille.de
Re: Bug#1007766: ITP: mppp -- C++11/14/17/20 library for multiprecision arithmetic
On 16/03/2022 13:44, Gürkan Myczko wrote: Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : mppp Version : 0.26 Upstream Authors: 2016-Francesco Biscani URL : https://github.com/bluescarni/mppp * License : MPL-2.0 Description : C++11/14/17/20 library for multiprecision arithmetic Built on top of the GNU multiprecision stack (GMP, MPFR, MPC), mp++ was initially conceived as a GMP wrapper with special focus on performance with small operands. In particular, a small buffer optimisation and custom implementations of basic mathematical primitives are instrumental in achieving a performance increase, with respect to GMP and other integer multiprecision libraries, which can be substantial. What is the advantages of mp++ over mpfrc++ which is already packaged ? Chhers, Jerome OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1007766: ITP: mppp -- C++11/14/17/20 library for multiprecision arithmetic
Hi Jerome, What is the advantages of mp++ over mpfrc++ which is already packaged ? Exactly the question I have been waiting for. Actually I can't tell, but forwarded the question that was asking to use mp++... if I know more, I'll update the answer. Chhers, Jerome Thanks,
Re: Seeking consensus for some changes in adduser
Hi, this is the summary follow-up to the adduser discussion we had in the last eight days, and I hope that I was successful in working all of your suggestions in the new text. Original Message Text: > (1) > #202943, #202944, #398793, #442627, #782001 > The bug reporters are requesting the default for DIR_MODE to be changed > from 0755 to 0700, making home directories readable for the user only. > Policy 10.9 states that directories should be 0755, but the policy > editors probably didn't have user home directories in mind when they > wrote that. > > (1a) would it be necessary to handle --system accounts differently? I > think yes. > (1b) should we stay with 0755 for --system accounts? > (1c) does a change to 0700 for user accounts make sense? > (1d) should it be 0751 (#398793)? > (1e) how about ~/public_html that would break with 0750? > > All those bugs referenced have more or less heated exchanges ranging > from "it's fine" to "we should issue a DSA ASAP", most of them a decade > old, so the times might have changed since then. Please note that the > DIR_MODE _IS_ configurable in adduser, we're just discussing the > default (which also applies for home directories created while still > inside the Installer before a local admin can properly configure > adduser). The answer to question (1a) is yes. A possible consensus would be to augment the DIR_MODE setting with a SYSTEM_DIR_MODE setting that would apply to --system accounts, allowing to handle system accounts and user accounts in a different way. The answer to question (1b) is "yes, as the default". The default of SYSTEM_DIR_MODE would be 0755, and we would document that changing this default setting might affect the function of the system since most packages expect their account's home directory to have mode 0755. This gives the local administrator maximum freedom while not requiring changes to packages and keeping their behavior in sync with policy. If SYSTEM_DIR_MODE is too restrictive, some packages will break, if it's too permissive, some packages will become insecure. I do intend to have SYSTEM_DIR_MODE in the manual page, but not in the default configuration file. My post-discussion answer to question (1c) is yes, but I am still open for arguments. If noone convinces me, the default for DIR_MODE will be changed to 2700 (see (4) below). Currently, on a freshly installed system, /root is root:root 0700 and has umask 022, while normal user accounts have their /home/user user:user 0755 and have umask 022 as well. While the root group is somewhat special (my brain refuses to consider this a regular usergroup), I think that having /root restrictive is a good example of what we actually want. The user having their own per-user group AND I have checked that if /home/user is 0700, the entire subtree under /home/user is unaccessible and the system doesn't care any more what the permissions of the directories under /home/user are. This is something I keep getting wrong so I wanted to be sure. A setgid bit on a non-group-readable directory might seem strange though. Are there arguments against doing so aside from the ugly "S" in ls output? (1e) has become a uncommon configuration, so we don't need to cater for that any more by default. Users expert enough to have a public_html directory can be held responsible to appropriately set up permissions and/or ACLs. I have a new question. Currently, adduser has a single Debconf question regarding system-wide readable home directories. Should we take the opportunity of removing this question and just assuming that a local administrator will reset DIR_MODE if they feel like that? The caveat of this is that the value can no longer be preseeded in the installer, but that will only affect the _single_ account created during installation. I feel that this may be worth the reduced complexity. What do you think? > (2) > #774046 #520037 > Which special characters should we allow for account names? > > People demand being able to use a dot (which might break scripts using > chown) and non-ASCII national characters in account names. The regex > used to verify non-system accounts is configurable, so the policy can be > locally relaxed at run-time. > > For system-accounts, I'd like to stick to ASCII letters, numbers, > underscores. Adduser should be more orthogonal in handling of system and user accounts. The following paragraphs describe how adduser should behave in my opinion, and if it doesn't do right now, it will be changed. There should be different regexp settings to define which account names are allowed for system and user accounts. Both regexps should be configurable at run time, and there should be command line options to override the check. If overridden, the checks are disabled in their entirety, relying on underlying tools (useradd) to reject really unacceptable names. For system accounts, the allowed chars are an optional leading underscore, lower case letters, numbers, underscores, dashe
Debian DSA-5095-1 : linux - security update
Hi Team, We are having High level threat in our Debian systems detected by our vulnerability scanners Debian DSA-5095-1 : linux - security update Debian DSA-4994-1 : bind9 - security update We tried to upgrade our Debian systems using the Debian repo but the affected packages didn’t received the package upgrade which takes care of the vulnerability. Below packages are affected and are not getting upgraded: linux-headers-5.10.0-10-amd64_5.10.84-1 libirs-export161_1:9.11.19+dfsg-2.1 Best regards, Sona Das --- +91 7021926734 / 9768458639 CONFIDENTIALITY. This email and any attachments are confidential to Alef Edge, and may also be privileged, except where the email states it can be disclosed. If this email is received in error, please do not disclose the contents to anyone, notify the sender by return email, and delete this email (and any attachments) from your system. -- CONFIDENTIALITY. This email and any attachments are confidential to Alef Edge Inc., and may also be privileged, except where the email states it can be disclosed. If this email is received in error, please do not disclose the contents to anyone, notify the sender by return email, and delete this email (and any attachments) from your system.
Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
On Wed, Mar 16, 2022 at 02:11:09PM +0100, Andreas Tille wrote:
>...
> I'm not sure whether there are any PalmPilot devices out there. At
> least the actual *votes* in popcon[1] is down to zero now.
This is less convincing than it sounds, since popcon data is based only
on a tiny and non-representative fraction of our users.
You cannot claim a package is unused solely based on popcon data.
Debian Med also has packages with zero popcon votes, users of software
for exotic/ancient hardware or uncommon usecases (like Debian Med) are
not generating high popcon numbers.
> The package
> was not uploaded by its maintainer for >10 years. It received an NMU by
> Adrian Bunk (in CC as well):
>
> [2022-01-02] imgvtopgm 2.0-9.1 MIGRATED to testing (Debian testing watch)
> [2021-12-27] Accepted imgvtopgm 2.0-9.1 (source) into unstable (Adrian Bunk)
> [2011-02-23] imgvtopgm 2.0-9 MIGRATED to testing (Debian testing watch)
> [2011-02-13] Accepted imgvtopgm 2.0-9 (source i386) (signed by: Erik Schanze)
>
> The changelog of that NMU was:
>
>* Non-maintainer upload.
>* debian/rules: Add build-{arch,indep}. (Closes: #999003)
>
>
> >From my naive perspective this package caused some work from a quite
> busy maintainer for no obvious user base. May be I'm wrong in this
> specific case but this observation raises my question: Do we have any
> means to get rid of packages that should be rather removed from the
> distribution than draining resources.
You are getting it wrong what was draining the resources.
It was not the package that was draining the resources,
it was the MBF that was draining the resources.
And these MBFs usually fail to make a convincing case that the benefits
are worth all the resources that are drained by the MBF.
> If the answer is no should we possibly use the list of packages that are
> not topic of the heated debate around the source format 1.0 (where
> maintainers are obviously are caring about their packages just disagree
> with format 3.0 format) to pick some packages that should be rather
> removed than fixed?
How do you define "rather removed"?
According to the BTS there was and is no known user-visible problem in
the package that needed or needs fixing in the package you are using
as example.
I am still a regular user of my 15 year old iPod, and I was pretty
annoyed when I had to do an emergency adoption (changing nothing but the
maintainer field) of a package I use for it after seeing that someone
thought it would be a good idea to do "RM: RoQA; Upstream not active, orphaned".
As DD I can do that if I notice, the average user cannot do anything and
won't even notice until the next release in 1.5 years.
I do consider it a regression when we no longer ship a package in a
release that was in the previous Debian release.
It is not a problem for us to continue shipping imgvtopgm.
And that's why I'd like to see a case made why it is better for our
users when a package is no longer shipped.
It might or might not be possible to make the case for removal of this
specific package, but "low popcon" or "abandoned upstream" alone are not
convincing points.
> Kind regards
>
> Andreas.
>...
cu
Adrian
cmake: get rid of -fno-fat-lto-objects
Hello, One of my package builds with cmake. All is fine except that the built static library gets the no-code-sections error complaint from lintian. It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces -fno-fat-lto-objects unconditionally for GCC + IPO What is the easiest way to revert the -fno-fat-lto-objects flags ? Thanks in advance, Jerome [1] https://gitlab.kitware.com/cmake/cmake/-/issues/21696 [2] https://stackoverflow.com/questions/70806677/why-does-cmake-set-no-fat-lto-objects-when-i-enable-lto-ipo -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Re: cmake: get rid of -fno-fat-lto-objects
Hi Jerome, * Jerome BENOIT [2022-03-16 22:37]: Hello, One of my package builds with cmake. All is fine except that the built static library gets the no-code-sections error complaint from lintian. It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces -fno-fat-lto-objects unconditionally for GCC + IPO What is the easiest way to revert the -fno-fat-lto-objects flags ? I recommend you explicitly disable LTO for the static library with: set_target_properties(staticlib PROPERTIES INTERPROCEDURAL_OPTIMIZATION OFF) LTO does not really achieve anything for static libraries: They are merely an archive of object files, so the linker is never invoked on them. You might think that LTO is useful when the static library is linked with an executable eventually. Alas, the LTO intermediate code is very compiler-specific, so it will not work with a different compiler and most likely not even with a different version of the same compiler. Alternatively, you could add a snippet such as if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang") target_compile_options(staticlib PRIVATE -ffat-lto-objects) endif() This will work because the target-specific compile options happen to end up after the LTO compile options on the command line right now. However, dh_strip will remove the intermediate code anyway, for the reasons outlined above. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: cmake: get rid of -fno-fat-lto-objects
Hi Timo, thanks a lot for the hint. Cheers, Jerome On 16/03/2022 23:21, Timo Röhling wrote: Hi Jerome, * Jerome BENOIT [2022-03-16 22:37]: Hello, One of my package builds with cmake. All is fine except that the built static library gets the no-code-sections error complaint from lintian. It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces -fno-fat-lto-objects unconditionally for GCC + IPO What is the easiest way to revert the -fno-fat-lto-objects flags ? I recommend you explicitly disable LTO for the static library with: set_target_properties(staticlib PROPERTIES INTERPROCEDURAL_OPTIMIZATION OFF) LTO does not really achieve anything for static libraries: They are merely an archive of object files, so the linker is never invoked on them. You might think that LTO is useful when the static library is linked with an executable eventually. Alas, the LTO intermediate code is very compiler-specific, so it will not work with a different compiler and most likely not even with a different version of the same compiler. Alternatively, you could add a snippet such as if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang") target_compile_options(staticlib PRIVATE -ffat-lto-objects) endif() This will work because the target-specific compile options happen to end up after the LTO compile options on the command line right now. However, dh_strip will remove the intermediate code anyway, for the reasons outlined above. Cheers Timo -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Re: Debian DSA-5095-1 : linux - security update
On Wed, 2022-03-16 at 23:46 +0530, Sona Das wrote: > Hi Team, > > We are having High level threat in our Debian systems detected by our > vulnerability scanners > Debian DSA-5095-1 : linux - security update > > Debian DSA-4994-1 : bind9 - security update > > We tried to upgrade our Debian systems using the Debian repo but the affected > packages didn’t received the package upgrade which takes care of the > vulnerability. Below packages are affected and are not getting upgraded: > linux-headers-5.10.0-10-amd64_5.10.84-1 This was replaced by linux-headers-5.10.0-11-amd64. So long as you install the metapackage linux-headers-amd64, replacements like this should be upgraded automatically. > libirs-export161_1:9.11.19+dfsg-2.1 This is the only version available in Debian. It is built separately from bind9 and is only used by the ISC DHCP server. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On Tue, 2022-03-15 at 15:32 +0100, Philip Hands wrote: > Michael Biebl writes: > > > Am 15.03.22 um 03:31 schrieb Paul Wise: > > > On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > > > > > > > Yes, this is true. These are the unit and script that I use, > > > > and I think > > > > that Debian would benefit from having something like this > > > > available in > > > > some common package. > > > ... > > > > $(systemctl status "$FAILED_UNIT" --full --lines=100) > > > > > > Unfortunately for my cron jobs I need the entire output of the > > > command > > > invocation, don't want any output from prior runs of the command > > > and > > > don't want any of the output to end up in the systemd journal. > > > > > > So I need something like StandardOutput=mail or to add some sort > > > of > > > wrapper script to each of the relevant systemd timers. > > > > I might be mistaken here, but Luca hinted at > > $MONITOR_INVOCATION_ID in his email which means one could easily > > filter > > journal output for the last failed invocation using this > > $MONITOR_INVOCATION_ID. > > Luca, is this understanding correct? > > Afaics this would cover Paul's use case > > Except for the "don't want any of the output to end up in the systemd > journal" bit. > > Cheers, Phil. See other reply to pabs w.r.t. LogNamespace=. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On Wed, 2022-03-16 at 08:01 +0800, Paul Wise wrote: > On Tue, 2022-03-15 at 13:28 +, Luca Boccassi wrote: > > > Yes indeed, logs can be filtered by invocation id, eg: > > > > journalctl INVOCATION_ID=abcdefg > > That sounds useful. > > > Also to make a unit's log "private" (not stored in the system > > journal) > > LogNamespace= can be used, see: > > > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LogNamespace= > > That sounds useful too but not for my use-case due to: > > This option is only available for system services and is not > supported for services running in per-user instances of the > service manager. > > I guess the reason for this is that it uses mount namespaces to > override the journald socket, rather than just pointing the process > at > a different socket via another mechanism. That will actually work from v251 too (as long as PrivateUsers=yes and TemporaryFileSystem=/run are also configured), with one caveat: given the journald instance is a system unit rather than a user one, a user unit won't have privileges to start it automagically. But it's very trivial to start it manually if you are configuring the user unit, since it's just a template based on the chosen namespace. Ie, for a unit with LogNamespace=foo, a 'systemctl start systemd-journald@foo.service' once at boot will do the trick. I'll see if I can make it work safely and automagically, without the manual start, before the next release, but no promises. Journal files will be stored under /[var|run]/log/journal/.foo/ and be separated from the system ones. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1007806: ITP: libencode-eucjpascii-perl -- Perl module supporting eucJP-ascii character encoding
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libencode-eucjpascii-perl Version : 0.03 Upstream Author : Hatuka*nezumi - IKEDA Soji * URL : https://metacpan.org/release/Encode-EUCJPASCII * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module supporting eucJP-ascii character encoding Encode::EUCJPASCII provides support for eucJP-ascii character encoding, an eucJP-open mapping. The following encodings are supported: - eucJP-ascii - x-iso2022jp-ascii (7-bit counterpart) Note: x-iso2022jp-ascii is an unofficial encoding name. It has never been registered by any standards bodies. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
