Bug#1063327: ITP: librtpi -- realtime capable pthread locking primitives

2024-02-06 Thread Felix Moessbauer
Package: wnpp
Severity: wishlist
Owner: Felix Moessbauer 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: librtpi
  Version : 1.0.0
  Upstream Contact: Gratian Crisan 
* URL : https://gitlab.com/linux-rt/librtpi/
* License : LGPL
  Programming Lang: C, C++
  Description : realtime capable pthread locking primitives

The Real-Time Priority Inheritance Library (librtpi) is
intended to bridge the gap between the glibc pthread
implementation and a functionally correct priority inheritance
for pthread locking primitives, such as pthread_mutex and
pthread_condvar. Specifically, priority based wakeup is required
for correct operation, in  contrast to the more time-based
ordered wakeup groups in the glibc pthread condvar implementation.

Why is this needed:
This library is needed to implement realtime capable waiting on
condition variables, due to glibc bug 11588 [1] which will not be fixed.

Who will maintain it:
I'm not yet a Debian maintainer, so a co-maintainer / sponsor will be
needed anyways. In general, it would be good if this package could be
maintained by a team. The expected effort is pretty low, as the library
is easy to package.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=11588

Best regards,
Felix Moessbauer
Siemens AG



Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

2024-02-06 Thread Helmut Grohne
Package: libselinux1t64
Version: 3.5-2.1~exp1
Severity: grave
X-Debbugs-Cc: vor...@debian.org, debian-devel@lists.debian.org

Hi,

I was looking into performing an upgrade test of libselinux1 with
piuparts and that didn't go well. I spare you the piuparts stuff and go
into crafting a minimal reproducer using mmdebstrap:

mmdebstrap --variant=apt unstable /dev/null "deb http://deb.debian.org/debian 
unstable main" "deb http://deb.debian.org/debian experimental main" 
--chrooted-customize-hook="apt-get -y install libselinux1t64"

This looks fairly innocuous. We create a minimal sid chroot and install
libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
that it would be a good idea to avoid coinstalling breaking packages and
first removes libselinux1 before proceeding to install libselinux1t64.
Unfortunately, libselinux1 is transitively essential and dpkg links it,
so this is what you get:

| Reading package lists... Done
| Building dependency tree... Done
| The following packages will be REMOVED:
|   libselinux1
| The following NEW packages will be installed:
|   libselinux1t64
| 0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
| Need to get 75.2 kB of archives.
| After this operation, 4096 B of additional disk space will be used.
| Get:1 http://deb.debian.org/debian experimental/main amd64 libselinux1t64 
amd64 3.5-2.1~exp1 [75.2 kB]
| Fetched 75.2 kB in 0s (6067 kB/s)
| debconf: delaying package configuration, since apt-utils is not installed
| dpkg: libselinux1:amd64: dependency problems, but removing anyway as you 
requested:
|  util-linux depends on libselinux1 (>= 3.1~).
|  tar depends on libselinux1 (>= 3.1~).
|  sed depends on libselinux1 (>= 3.1~).
|  libpam-modules-bin depends on libselinux1 (>= 3.1~).
|  libpam-modules:amd64 depends on libselinux1 (>= 3.1~).
|  libmount1:amd64 depends on libselinux1 (>= 3.1~).
|  findutils depends on libselinux1 (>= 3.1~).
|  dpkg depends on libselinux1 (>= 3.1~).
|  coreutils depends on libselinux1 (>= 3.1~).
|  base-passwd depends on libselinux1 (>= 3.1~).
| 
| (Reading database ... 6230 files and directories currently installed.)
| Removing libselinux1:amd64 (3.5-2) ...
| /usr/bin/dpkg: error while loading shared libraries: libselinux.so.1: cannot 
open shared object file: No such file or directory
| E: Sub-process /usr/bin/dpkg returned an error code (127)

At that point stuff is fairly broken and we cannot easily recover as
both dpkg and tar are now broken. This is pretty bad. To make matters
worse, the situation arises from the combination of Breaks + Provides
and there is nothing libselinux1t64 could do in maintainer scripts to
prevent this from happening, because no libselinux1t64 maintainer script
has been run by the time damage has happened.

I also looked into whether I could reproduce a similar failure with
other packages such as libpam0t64 or libaudit1, but in no other case, I
was able to construct a comparable outcome.

I also looked into why libselinux was being time-bumped. Do I understand
correctly that libselinux is entirely unaffected by time64?
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libselinux1-dev/lfs_to_time_t/compat_report.html
It still is affected by LFS due to using ino_t in the public ABI of
matchpathcon_filespec_add:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libselinux1-dev/base_to_lfs/compat_report.html
Since we also complete the LFS transition here, not bumping it would
result in an ABI break regarding this symbol. If we were to opt
libselinux out of the LFS transition (e.g. by removing the flags in
debian/rules), then other packages being rebuilt against libselinux-dev
with these flags enabled would be ABI-incompatible though.

An option I see here is to provide ABI-duality for libselinux:

-extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file);
+typedef unsigned long libselinux_ino_t;
+typedef uint64_t libselinux_ino64_t;
+extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const 
char *file);
+#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned 
long) < 8
+extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, 
const char *file);
+#define matchpathcon_filespec_add matchpathcon_filespec_add64
+#endif

Looking at the implementation, it would be fairly possible to implement
this. Of course, doing this comes at its own cost: We are extending the
libselinux1 ABI in a Debian-specific way and thus programs built on
Debian will not run on non-Debian.

Another option of course is doing a proper soname bump of libselinux1 to
a Debian-specific soname.

I really hope, I am missing something.

Helmut



Bug#1063347: ITP: td -- telegram client library

2024-02-06 Thread Ying-Chun Liu (PaulLiu)

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: td
  Version : 1.8.0
  Upstream Contact: https://github.com/tdlib/td
* URL : https://core.telegram.org/tdlib
* License : Boost Software License 1.0
  Programming Lang: C++
  Description : telegram database library
  TDLib (Telegram Database Library) is a cross-platform, fully functional
  Telegram client. This library helps third-party developers create their
  own custom apps using the Telegram platform.



OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Transparency into private keys of Debian

2024-02-06 Thread Hans-Christoph Steiner




Simon Josefsson:

Hans-Christoph Steiner  writes:


Thanks for digging in here, its very important work!  I'd be happy to
contribute where I can.  I'm a DD and a core contributor to F-Droid,
where we wrestle with basically the same issues.  So we've thought a
lot about these kinds of things, but definitely do not have all the
answers.  Since F-Droid started much later than Debian, we were able
to build in some nice protections from the beginning, like requiring
HTTPS.  We've also made the decision to stick with a single
jurisdiction for the singing keys, even though it is not the best one
for our needs.  We'd of course love to move them to the best
jurisdiction but that is actually quite a bit of work, so we have to
stay grounded in reality.

For me the hard part of all this is how to be transparent as possible
without putting a giant target on the heads of the people who control
the keys.  I think it is clear that publishing private key usage
information is safe, like this key signed these things at these times.
Publishing all the details about how the key was generated could help
those who want to attack it more than those who rely on it.  But that
kind of information would be good to share internally to the project
at the very least.


Good aspect -- and indeed this is a trade-off, and thanks for caring
about these issues for f-droid!  It seems that if you would verify
signatures via a transparency log, you would reduce the risk on the
people controlling the keys?  Then you (and they) could feel more
comfortable publishing information how your process work. That would be
valuable to publish (even de-personalized or generalized) as a best
practices approach.  The reason is that anyone stealing the keys from
these persons would ALSO have to upload signatures of whatever they
wanted to use these keys for into the transparency log, which would
provide evidence to what they did, so they may be less likely to follow
through on their plans.


Yes, I agree, and am familiar with this architecture.  The hard part is the 
availability of the transparency log needs to be as good as the signed index's 
availability, otherwise attackers can just block the transparency log to stop 
the whole process.  The official F-Droid client does a lot of things 
automatically in order to find a working mirror.  And we're expanding on that. 
I have yet to see a transparency log set up for decentralized, flexible 
distribution.  F-Droid's mirror handling will automatically choose from:


* f-droid.org
* Any of the official mirrors
* Any mirrors that the user has added locally
* Files hosted on IPFS
* Mirrors on local storage (SD cards, thumb drives, etc)

We're expanding to:
* Mirrors on cloud file storage like Nextcloud, Google Drive, etc.
* Signed JSON on public code distribution platforms and CDNs

(As a side note: I would like to see Debian/apt adopt this approach, at least 
optionally.  The key part is automatic operation and dead simple setup, e.g. for 
non-technical users.)



What would be involved is to 1) during signing of artifacts, also sign
and upload into Sigstore/Sigsum, and 2) during verification in the
f-droid app, also verify that the signature has been committed to the
Sigstore/Sigsum logs.  Both projects have clients written in Go which
should work on Android, but the rest of the details are sketchy to me.
I'm happy to continue discuss and help with design if you are
interested, to understand what the limitations of your environments are
and how to resolve them.


I've looked at Sigstore, it looks nice.  It seems to be architected for use 
cases that assume highly reliable and unblocked single domains.  That's a 
showstopper for us.  Also, the official client app is 100% JVM code right now 
(Java+Kotlin), so integrating Go binaries would really be an option of last 
resort.  Its almost a no go for many reasons.


Hans



/Simon


And publishing the jurisdictions could be enough info to deanonymize
the key holder, e.g. if it is Germany, then there are many DDs there.
If it is Iceland, then govs can easily find who to target.

.hc


Hi
I'm exploring how to defend against an attacker who can create valid
signatures for cryptographic private keys (e.g., PGP) that users need to
trust when using an operating system such as Debian.  A signature like
that can be used in a targetted attacks against one victim.
For example, apt does not have any protection against this threat
scenario, and often unprotected ftp:// or http:// transports are used,
which are easy to man-in-the-middle.  Even with https:// there is a
large number of mirror sites out there that can replace content you get.
There is a risk that use of a compromised trusted apt PGP key will not
be noticed.  Attackers are also in a good position to deny themselves
out of their actions if they are careful.
Part of my effort is to inventory all trusted private keys that a
distribution needs to manage on their own, or depend on that are managed
by others, and gai

Bug#1063352: ITP: ngspetsc -- a PETSc interface for NGSolve

2024-02-06 Thread Drew Parsons
Package: wnpp
Severity: wishlist
Owner: Drew Parsons 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org, 
francesco.balla...@unicatt.it

* Package name: ngspetsc
  Version : git HEAD
  Upstream Contact: Umberto Zerbinati 
* URL : https://github.com/NGSolve/ngsPETSc
* License : MIT
  Programming Lang: Python
  Description : a PETSc interface for NGSolve

ngsPETSc is a PETSc interface for NGSolve. It extends the utility of
meshes generated by netgen and interfaces with finite element solvers
such as dolfinx (fenicsx) as well as NGSolve, Firedrake.

To be maintained by the Debian Science team alongside netgen.
Co-maintained with Francesco Ballarin.



Re: Transparency into private keys of Debian

2024-02-06 Thread Jeremy Stanley
On 2024-02-06 14:35:34 +0800 (+0800), Simon khng wrote:
[...]
> 3) Use 'password enabled key store' to prevent unauthorized access to
> digital keys.
> 4) Use 'password enabled signing' to prevent unauthorized usage of digital
> keys.
> The use of number 3 and 4 are the steps for developers to upload
> application packages as part of the
> verification process by Google for the 'Play store' used in Android OS
> devices.
[...]

This is already a standard practice for anyone using OpenPGP/GnuPG
keys. I personally know no one who keeps their developer private
keys or subkeys unencrypted. That said, it's not enforceable (or
detectable), so it can at best only be part of documented workflow
process. There is no way to actually guarantee everyone follows it.

In business, such things are confirmed (often badly) by independent
audit. For a volunteer-driven community effort, we have to rely on
everyone to exercise their best judgement in these sorts of matters.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Transparency into private keys of Debian

2024-02-06 Thread Simon Josefsson
tis 2024-02-06 klockan 16:50 +0100 skrev Hans-Christoph Steiner:
> 
> 
> Simon Josefsson:
> > Hans-Christoph Steiner  writes:
> > 
> > > Thanks for digging in here, its very important work!  I'd be
> > > happy to
> > > contribute where I can.  I'm a DD and a core contributor to F-
> > > Droid,
> > > where we wrestle with basically the same issues.  So we've
> > > thought a
> > > lot about these kinds of things, but definitely do not have all
> > > the
> > > answers.  Since F-Droid started much later than Debian, we were
> > > able
> > > to build in some nice protections from the beginning, like
> > > requiring
> > > HTTPS.  We've also made the decision to stick with a single
> > > jurisdiction for the singing keys, even though it is not the best
> > > one
> > > for our needs.  We'd of course love to move them to the best
> > > jurisdiction but that is actually quite a bit of work, so we have
> > > to
> > > stay grounded in reality.
> > > 
> > > For me the hard part of all this is how to be transparent as
> > > possible
> > > without putting a giant target on the heads of the people who
> > > control
> > > the keys.  I think it is clear that publishing private key usage
> > > information is safe, like this key signed these things at these
> > > times.
> > > Publishing all the details about how the key was generated could
> > > help
> > > those who want to attack it more than those who rely on it.  But
> > > that
> > > kind of information would be good to share internally to the
> > > project
> > > at the very least.
> > 
> > Good aspect -- and indeed this is a trade-off, and thanks for
> > caring
> > about these issues for f-droid!  It seems that if you would verify
> > signatures via a transparency log, you would reduce the risk on the
> > people controlling the keys?  Then you (and they) could feel more
> > comfortable publishing information how your process work. That
> > would be
> > valuable to publish (even de-personalized or generalized) as a best
> > practices approach.  The reason is that anyone stealing the keys
> > from
> > these persons would ALSO have to upload signatures of whatever they
> > wanted to use these keys for into the transparency log, which would
> > provide evidence to what they did, so they may be less likely to
> > follow
> > through on their plans.
> 
> Yes, I agree, and am familiar with this architecture.  The hard part
> is the 
> availability of the transparency log needs to be as good as the
> signed index's 
> availability, otherwise attackers can just block the transparency log
> to stop 
> the whole process.  The official F-Droid client does a lot of things 
> automatically in order to find a working mirror.  And we're expanding
> on that. 
> I have yet to see a transparency log set up for decentralized,
> flexible 
> distribution.  F-Droid's mirror handling will automatically choose
> from:
> 
> * f-droid.org
> * Any of the official mirrors
> * Any mirrors that the user has added locally
> * Files hosted on IPFS
> * Mirrors on local storage (SD cards, thumb drives, etc)
> 
> We're expanding to:
> * Mirrors on cloud file storage like Nextcloud, Google Drive, etc.
> * Signed JSON on public code distribution platforms and CDNs

I believe sigsum allows for offline verification of the inclusion
proof.  Just include the transparency checksum proof with the app or
meta-data around the app.  Not sure about Sigstore.

> (As a side note: I would like to see Debian/apt adopt this approach,
> at least 
> optionally.  The key part is automatic operation and dead simple
> setup, e.g. for 
> non-technical users.)

+1

> > What would be involved is to 1) during signing of artifacts, also
> > sign
> > and upload into Sigstore/Sigsum, and 2) during verification in the
> > f-droid app, also verify that the signature has been committed to
> > the
> > Sigstore/Sigsum logs.  Both projects have clients written in Go
> > which
> > should work on Android, but the rest of the details are sketchy to
> > me.
> > I'm happy to continue discuss and help with design if you are
> > interested, to understand what the limitations of your environments
> > are
> > and how to resolve them.
> 
> I've looked at Sigstore, it looks nice.  It seems to be architected
> for use 
> cases that assume highly reliable and unblocked single domains. 
> That's a 
> showstopper for us.  Also, the official client app is 100% JVM code
> right now 
> (Java+Kotlin), so integrating Go binaries would really be an option
> of last 
> resort.  Its almost a no go for many reasons.

Agreed -- having a C, perl or python client for Sigstore or Sigsum
would be nice.  I'll bring this up with them.

/Simon

> 
> Hans
> 
> > 
> > /Simon
> > 
> > > And publishing the jurisdictions could be enough info to
> > > deanonymize
> > > the key holder, e.g. if it is Germany, then there are many DDs
> > > there.
> > > If it is Iceland, then govs can easily find who to target.
> > > 
> > > .hc
> > > 
> > > > Hi
> > > > I'm exploring how to defend ag

Re: Transparency into private keys of Debian

2024-02-06 Thread Simon Josefsson
> > I've looked at Sigstore, it looks nice.  It seems to be architected
> > for use 
> > cases that assume highly reliable and unblocked single domains. 
> > That's a 
> > showstopper for us.  Also, the official client app is 100% JVM code
> > right now 
> > (Java+Kotlin), so integrating Go binaries would really be an option
> > of last 
> > resort.  Its almost a no go for many reasons.
> 
> Agreed -- having a C, perl or python client for Sigstore or Sigsum
> would be nice.  I'll bring this up with them.

I should have checked before sending the previous email, there is this
client:

https://git.glasklar.is/sigsum/core/sigsum-py

I suppose for apt python is more relevant, and if the sigsum proof is
included alongside apt metadata, it would allow offline verification
inside apt.  If apt doesn't support this natively, the proof would have
to be distributed through some other channel, but that is relatively
easy to do as a Proof-of-Concept (i.e., how apt-sigstore +
debdistcanary already works via gitlab) but scaling it to decentralized
etc remains to be resolved, if relevant.

/Simon

> 
> /Simon
> 
> > 
> > Hans
> > 
> > > 
> > > /Simon
> > > 
> > > > And publishing the jurisdictions could be enough info to
> > > > deanonymize
> > > > the key holder, e.g. if it is Germany, then there are many DDs
> > > > there.
> > > > If it is Iceland, then govs can easily find who to target.
> > > > 
> > > > .hc
> > > > 
> > > > > Hi
> > > > > I'm exploring how to defend against an attacker who can
> > > > > create
> > > > > valid
> > > > > signatures for cryptographic private keys (e.g., PGP) that
> > > > > users need to
> > > > > trust when using an operating system such as Debian.  A
> > > > > signature like
> > > > > that can be used in a targetted attacks against one victim.
> > > > > For example, apt does not have any protection against this
> > > > > threat
> > > > > scenario, and often unprotected ftp:// or http:// transports
> > > > > are used,
> > > > > which are easy to man-in-the-middle.  Even with https://
> > > > > there
> > > > > is a
> > > > > large number of mirror sites out there that can replace
> > > > > content
> > > > > you get.
> > > > > There is a risk that use of a compromised trusted apt PGP key
> > > > > will not
> > > > > be noticed.  Attackers are also in a good position to deny
> > > > > themselves
> > > > > out of their actions if they are careful.
> > > > > Part of my effort is to inventory all trusted private keys
> > > > > that
> > > > > a
> > > > > distribution needs to manage on their own, or depend on that
> > > > > are managed
> > > > > by others, and gain some insight how these keys are handled.
> > > > > Does the Debian project, or any members, publish information
> > > > > on
> > > > > these
> > > > > topics?  Has this been discussed before?
> > > > > Some questions that I think would be useful to answer
> > > > > include:
> > > > > 1) List of relevant private keys, held by the organization,
> > > > > its
> > > > > members,
> > > > >     or someone else.  As far as I can tell from Debian, the
> > > > > list includes
> > > > >     the following PGP trust anchors:
> > > > >    B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
> > > > >    05AB 9034 0C0C 5E79 7F44  A8C8 254C F3B5 AEC0 A8F0
> > > > >    4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
> > > > >    1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
> > > > >    AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
> > > > >    A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
> > > > >    80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
> > > > >    5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
> > > > >    6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517
> > > > >     Compromising any single key on this list leads to
> > > > > trouble.
> > > > > However I
> > > > >     don't think this list is complete.  What other keys are
> > > > > there?
> > > > >     I believe there are keys used to sign some component of
> > > > > the
> > > > > boot
> > > > >     phase, compare the 'shim-signed' and 'grub-efi-amd64-
> > > > > signed'
> > > > >     packages.  What private keys held by Debian are involved
> > > > > here?  What
> > > > >     keys held by others are involved?  What other similar
> > > > > packages
> > > > >     exists?
> > > > > 2) For each private key, information about its management and
> > > > > lifecycle.
> > > > >     Relevant questions include:
> > > > >   a) How was the key generated?  By whom?  On what hardware? 
> > > > > What
> > > > >  software?  In what environment?  What legal jurisdiction
> > > > > apply to
> > > > >  people involved?
> > > > >   b) How is the key stored and protected during its
> > > > > lifetime? 
> > > > > What
> > > > > media
> > > > >  is used?  Who control the physical storage of the key? 
> > > > > How are they
> > > > >  stored and transported?  What jurisdiction?
> > > > >   c) Under what policy is the key used?  What

Bug#1063354: ITP: h2orestart -- LibreOffice import filter for Hancom HWP document

2024-02-06 Thread Changwoo Ryu
Package: wnpp
Severity: wishlist
Owner: Changwoo Ryu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-l10n-kor...@lists.debian.org

* Package name: h2orestart
  Version : 0.6.0
  Upstream Contact: https://github.com/ebandal/H2Orestart
* URL : https://github.com/ebandal/H2Orestart
* License : GPL-3.0-or-later
  Programming Lang: Java
  Description : LibreOffice import filter for Hancom HWP document

This enhances LibreOffice Writer to read Hancom Office documents,
as known as HWP, which are widely used especially by South Korean
government organizations.
.
It supports the HWP v5 format or the HWPx format only. It doesn't work
for the ancient HWP v3 format.



Re: Bug#698988: O: nvi - 4.4BSD re-implementation of vi

2024-02-06 Thread Andreas Metzler
On 2024-02-05 Tobias Heider  wrote:
[...]
> As an active nvi user I would love to step up and help, but the biggest
> problem I see is that the choice of upstream project. Since the original
> is gone there isn't a clear successor.

> The BSDs all have their own forks which diverged over time (and those don't
> build on Linux).
> The other two options there are today are https://repo.or.cz/nvi.git which
> d/control currently points to and more recently 
> https://github.com/lichray/nvi2.

> The first has a very low commit frequency (last commit was 2020, before
> that 2016) and sticks very closely to the original source. nvi2 has added
> new features such as multibyte support and is starting to receive bug fixes
> and features from the different *BSD forks.

> I have been thinking of proposing a new package for nvi2 but maybe it
> would make more sense to move this one to the more active upstream.
> It looks like some of the issues we are carrying patches for in Debian
> might be fixed there already and if not they seem active enough to
> merge our fixes.

> What would be the best way forward here? ITA and eventually switch the
> upstream or start a new package and let this one continue its slow
> death?

Hello Thomas,

On one hand it depends on whether there is significant value in keeping the
other nvi around, i.e. a significant part of the userbase would be
reluctant to switch. (I have no opinion on that I use vim ;-)

On the other hand reducing the number of QA-maintained packages is a
strong argument for switching.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Re: 64-bit time_t transition in progress

2024-02-06 Thread Alberto Garcia
On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> In fact, none of the t64 binaries currently being uploaded
> to experimental have the final ABI either, we're just using
> experimental to clear binary NEW.

I was having a look at two of the packages that I maintain that have
t64 binaries in experimental and I noticed that while the binary
package does have a different name the .so files themselves are the
same. Is this expected when we're talking about an ABI break?

Berto



Re: O: nvi - 4.4BSD re-implementation of vi

2024-02-06 Thread Paride Legovini
Hi Tobias!

On 2024-02-05 10:43, Tobias Heider wrote:
> On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote:
>>
>> The maintainer for the "nvi" package has indicated that he is unable to
>> maintain this package for the time being. I'm marking this package as 
>> orphaned
>> now.
>
> Looks like this is still orphaned over ten years later.
> 
> As an active nvi user I would love to step up and help, but the biggest
> problem I see is that the choice of upstream project. Since the original
> is gone there isn't a clear successor.
> 
> The BSDs all have their own forks which diverged over time (and those don't
> build on Linux).
> The other two options there are today are https://repo.or.cz/nvi.git which
> d/control currently points to and more recently 
> https://github.com/lichray/nvi2.
> 
> The first has a very low commit frequency (last commit was 2020, before
> that 2016) and sticks very closely to the original source. nvi2 has added
> new features such as multibyte support and is starting to receive bug fixes
> and features from the different *BSD forks.
> 
> I have been thinking of proposing a new package for nvi2 but maybe it would
> make more sense to move this one to the more active upstream.  It looks like
> some of the issues we are carrying patches for in Debian might be fixed there
> already and if not they seem active enough to merge our fixes.
> 
> What would be the best way forward here? ITA and eventually switch the 
> upstream
> or start a new package and let this one continue its slow death?

I think making the O bug and ITA and switching upstream is right thing to
do here, maybe explaining the history of the package in README.source.

I can't think think of a reasonable use case where nvi2 would not be
a suitable drop-in replacement for nvi; if neither can you (knowing
the editor way better than me!), then I'd say go for the switch.

I'll be happy reviewing/sponsoring if needed.

Cheers,

Paride



Re: 64-bit time_t transition in progress

2024-02-06 Thread Andreas Metzler
On 2024-02-06 Alberto Garcia  wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.

> I was having a look at two of the packages that I maintain that have
> t64 binaries in experimental and I noticed that while the binary
> package does have a different name the .so files themselves are the
> same. Is this expected when we're talking about an ABI break?

Hello Alberto,

It is expected for this ABI break yes. Essentially we are just doing a
rebuild-everything-involved while making sure the package
interdependencies avoid a (breaking) mixture. This is similar what we
did when the C++ ABI changed.[1]

cu Andreas
https://lists.debian.org/debian-release/2005/04/msg00153.html
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'