Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-21 06:51:08) > On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote: > > > I am (very) willing to act as service maintainer. > > Please get in touch with the debtags team about this. > > https://wiki.debian.org/Teams/DebTags > https://salsa.debian.org/groups/debtags-team/-/group_members > > > I have interest myself in continued use of debtags, but don't have C++ > > coding skills needed to work intimately on the programming parts of the > > project. > > It does not seem to use C++, just Python/Shell/HTML/CSS/JavaScript: > > https://salsa.debian.org/debtags-team/debtagsd/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-vocabulary/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tagdb/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tools/-/graphs/master/charts Thanks - I am not comfortable with Python either, but that's certainly less scary to me. > You may be thinking of libept, which got adopted by the apt team. It was a mixture of thinking of goplay (see bug#930676) and reducing "languages I am not fluent in" to "C++". > In case you want collaborators, 5 people forked debtags git repos: > > https://salsa.debian.org/search?search=debtag > > Additionally apt-xapian-index needs a maintainer and the debtags > package needs to be updated from the debtags-tools git repository. > > Some of the debtags related wiki pages may need to be updated: > > https://wiki.debian.org/?action=fullsearch&context=180&value=debtag&titlesearch=Titles Thanks a lot! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Editor extensions to help editing debian/* files?
Hi!
What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?
I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.
I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.
- Otto
[1]
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html
[2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
[3] https://web.pulsar-edit.dev/packages/language-debian
PS. Related, these are commands I frequently run manually but don't
have any editor integration for:
wrap-and-sort --wrap-always --verbose
make --dry-run --makefile=debian/rules
codespell --write --check-filenames --check-hidden debian/
find debian/ -type f | xargs spellintian --picky
aspell --mode=debctrl -c debian/control
duck -v --color=always
find -name *.pot -exec i18nspector "{}" +; find -name *.po -exec
i18nspector "{}" +;
shellcheck -x --shell=bash $(shell grep -Irnw -e '^#!.*/bash' | sort
-u |cut -d ':' -f 1 | xargs)
shellcheck -x --shell=sh $(shell grep -Irnw -e '^#!.*/sh' | sort -u
|cut -d ':' -f 1 | xargs)
if [ "$(find debian/patches/ -type f -not -name series | wc -l)" !=
"$(wc -l < debian/patches/series)" ]
then
echo "Contents of debian/patches/series does not match number of
patches in debian/patches"
fi
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, On 20-01-2024 23:22, Steve Langasek wrote: So I think an algorithm for deciding the uploads to experimental looks like this: - download source from unstable. - apply the packagename conversion to the source. - grab the debdiff. - submit the NMU diff to the BTS. - download the source again from experimental (possibly a no-op). - apply the debdiff to the source. Except with a *lower* version number than you submitted to the BTS or in two steps below, with a higher version than you submitted to the BTS. (I assume everybody reading this realized that, but just in case.) - if it fails to apply (meaning: debian/control has changed), skip. otherwise, build and upload to experimental. - after packages have cleared binary NEW, upload sourceful NMUs to unstable for all these packages with the same debdiff as before. - if there are any packages included in the uploads to unstable that were skipped for experimental because of different sonames there, deal with binary NEW then in unstable. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote: > I am (very) willing to act as service maintainer. Please get in touch with the debtags team about this. https://wiki.debian.org/Teams/DebTags https://salsa.debian.org/groups/debtags-team/-/group_members > I have interest myself in continued use of debtags, but don't have C++ > coding skills needed to work intimately on the programming parts of the > project. It does not seem to use C++, just Python/Shell/HTML/CSS/JavaScript: https://salsa.debian.org/debtags-team/debtagsd/-/graphs/master/charts https://salsa.debian.org/debtags-team/debtags-vocabulary/-/graphs/master/charts https://salsa.debian.org/debtags-team/debtags-tagdb/-/graphs/master/charts https://salsa.debian.org/debtags-team/debtags-tools/-/graphs/master/charts You may be thinking of libept, which got adopted by the apt team. In case you want collaborators, 5 people forked debtags git repos: https://salsa.debian.org/search?search=debtag Additionally apt-xapian-index needs a maintainer and the debtags package needs to be updated from the debtags-tools git repository. Some of the debtags related wiki pages may need to be updated: https://wiki.debian.org/?action=fullsearch&context=180&value=debtag&titlesearch=Titles -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sun, Jan 07, 2024 at 09:30:37AM +0100, Rene Engelhard wrote:
> Am 07.01.24 um 02:01 schrieb Steve Langasek:
> > If you say you are going to fix eventual breakage (and not ignoring the
> > test results!) and if that means fixing asm on all affected archs, then
> > it's OK :)
> > Well, yes; though I hope we would see some help from e.g. arm porters if
> > there were actually breakage of this nature.
> Hope doesn't help when it got to the actual problem and this doesn't happen.
Relying on me or any *other* non-ARM porter to fix (hypothetical)
ARM-specific asm issues is also aspirational.
But also, I don't know what else you would propose here. We can't
practically hold libreoffice back from the time_t transition with
dpkg-buildflags overrides, it depends on other libraries that are also
affected (e.g. poppler); and 32-bit time_t is already on borrowed time. It
fails not when the *current* date reaches 2038, but when *any dates you want
to work with on the system* reach 2038. There are known instances already
of software failures due to this limitation, and this will only accelerate
with time. I don't think it's reasonable to postpone the transition.
(Also, the intention here was first posted to debian-devel 6 months ago, and
you didn't raise any objections then? So I don't think a hypothetical
concern in libreoffice asm should block things now.)
> > Alternatively, maybe it would
> > be better to stop shipping libreoffice on 32-bit archs, in that case? I'm
> I'd like to avoid this. Getting rid of i386 is fine, noone needs it, armhf
> is a bit different.
> (rpis etc - even though they could run arm64, but..)
I understand wanting to avoid it, but I think that should be the fallback
position if there are intractable porting problems. Losing libreoffice on
armhf is better than carrying 32-bit time_t forward.
As a data point, Ubuntu will only ship arm64 for raspi in 24.04, not armhf.
> > > > > > - the source packages which need an ABI change
> > > > > > ("source-packages"+"lfs-and-depends-time_t" will have
> > > > > > sourceful NMUs to
> > > > > I get that you probably want NMUs for not needing to ping every
> > > > > maintainer,
> > > > > but this is bad.
> > > > > That e.g. would cause me to upload libreoffice 24.2 rc2 to sid
> > > > > immediately
> > > > > when tagged end of next week to not have this caught in the
> > > > > transition. (see
> > > > > also below for the comment about new upstream versions in
> > > > > experimental.)
> > > > What about the suggestion to not push changes to experimental for
> > > > packages
> > > > that already have new versions in experimental, and do the binary
> > > > package
> > > > renames in unstable instead, leaving the package in experimental alone?
> > > If at all - *both*. At the same time.
> > Most of these packages that are staged in experimental are going to be there
> > because of library transitions...
> And ignore those who use experimental as a testbed of major new upstreams?
> Doesn't sound good.
The purpose of uploading to experimental is twofold.
- to clear binary NEW in an orderly fashion, and minimize the window of
possible misbuilds in unstable once dpkg lands there
- to let the usrmerge tooling run against the packages in experimental and
check for any issues there.
Of course, the second of these doesn't apply to libreoffice.
I hear you that you would like libreoffice to be included because of the
second point.
In another subthread I identified that 130 of the binary packages currently
in experimental are runtime libraries requiring name changes (from 64 source
packages). Since these are explicitly runtime library packages staged in
experimental whose binary package names have NOT changed, they do all need
source NMUs (i.e.: we can't simply promote these packages from experimental
to unstable and rebuild with new dpkg without changing the binary package
names).
This is enough packages that it seems fair to expect them to also have the
binary NEW handling done in experimental, not in unstable.
So I am convinced that we should do NMUs of these to experimental as well,
rather than uploading them straight to unstable.
Packages that already have new sonames in experimental should still NOT have
NMUs uploaded to experimental, because we don't want to add package name
annotations for the new not-yet-in-unstable soname.
So I think an algorithm for deciding the uploads to experimental looks like
this:
- download source from unstable.
- apply the packagename conversion to the source.
- grab the debdiff.
- submit the NMU diff to the BTS.
- download the source again from experimental (possibly a no-op).
- apply the debdiff to the source.
- if it fails to apply (meaning: debian/control has changed), skip.
otherwise, build and upload to experimental.
- after packages have cleared binary NEW, upload sourceful NMUs to unstable
for all these packages with the same debdiff as before.
- if there are any packages includ
Bug#1061199: ITP: python-mbedtls -- Cryptographic library for Python with Mbed TLS backend
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-mbedtls Version : 2.8.0 Upstream Contact: Mathias Laurin * URL : https://github.com/Synss/python-mbedtls * License : MIT/expat Programming Lang: Python Description : Cryptographic library for Python with Mbed TLS backend mbedtls is an open source library that implements lightweight and efficient solutions for security protocols, including TLS (widely used in security between network communications) . Library Key Features: - TLS/SSL: Provides support for implementing the TLS/SSL protocol, which is widely used to ensure secure communications over the internet. - Cryptography: Offers a variety of cryptographic algorithms for symmetric and asymmetric encryption, hashing, and digital signatures - Network Protocol Support: Implements security protocols for secure communication, such as DTLS (Datagram Transport Layer Security) for real-time communication. - TLS Server and Client: Allows the creation of both secure servers and clients using the TLS protocol. - Clean and Simple C API: Features a C-language API designed to be clear, concise, and easy to use.
Bug#1061195: ITP: libgeo-wkt-simple-perl -- Simple utils to parse/build Well Known Text(WKT) format string
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libgeo-wkt-simple-perl Version : 0.05 Upstream Contact: Yuto KAWAMURA * URL : https://metacpan.org/release/KAWAMURAY/Geo-WKT-Simple-0.05 * License : Perl Programming Lang: Perl Description : Simple utils to parse/build Well Known Text(WKT) format string This module can parse/build WKT format string into/from pure Perl data structure. It is simpler than Geo::WKT and does not depend on the Proj library, and even support MULTI(LINE|STRING|POLYGON) objects. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Re: Please help test the PAM in experimental
Hi, you don't seem to address: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029097 why? On Fri, 2024-01-19 at 11:40 -0700, Sam Hartman wrote: > > There are a number of changes, and I'd just like a bit more > confidence > that it works as expected before uploading to unstable in about a > week. > > Changes include: > > * Running pam_umask with usergroups support by default. > > * libpam-modules now depends on libsystemd0 because utmp is not > y2038-clean and upstream has decided to depend on elogind for that. > > * New PAM upstream and thus newly rebased patches. > > So, it would be helpful especially if you would install libpam- > modules > and libpam0g from experimental.
Re: Please help test the PAM in experimental
On Fri, 19 Jan 2024 at 18:41, Sam Hartman wrote: > > > There are a number of changes, and I'd just like a bit more confidence > that it works as expected before uploading to unstable in about a week. > > Changes include: > > * Running pam_umask with usergroups support by default. > > * libpam-modules now depends on libsystemd0 because utmp is not > y2038-clean and upstream has decided to depend on elogind for that. > > * New PAM upstream and thus newly rebased patches. > > So, it would be helpful especially if you would install libpam-modules > and libpam0g from experimental. Thanks for the update, looks good in my testing VM, will check on my testing desktop later. I see one warning due to pam_lastlog being deprecated but still in the default config: [495799.050948] login[55]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory [495799.051113] login[55]: PAM adding faulty module: pam_lastlog.so I guess this needs to be filed against the login package, as that's shipping the rule enabling it?
Re: Mini-DebConf Belo Horizonte (Brazil) 2024: registration and CfP are open
Debian is a brilliant OS; I use it daily on my Raspberry Pi! 😉
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-20 07:32:14) > On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote: > > > I want to use debtags metadata for a research project > > The debtags service is planned to be shutdown and the data no longer > published, as there is no-one in Debian who wants to maintain it. > > https://lists.debian.org/msgid-search/20231126160111.7nr56b7oje6uw...@enricozini.org > > > I started contributing, by adding and removing some tags using the > > online tag editor, but the "Checks and hints" part seems wrong to me > > in several cases. > > Sounds like there may be bugs that need fixing, but first there would > need to be a new maintainer who could take over the project. If you > were willing to be the primary code maintainer, perhaps you could find > some Debian member willing to be the service maintainers and review and > deploy all of the changes you could make, at least until you become a > Debian member on the basis of your debtags and other contributions. I am (very) willing to act as service maintainer. I have interest myself in continued use of debtags, but don't have C++ coding skills needed to work intimately on the programming parts of the project. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
