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

[Steve Langasek]

On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > Yes, I'm not sure I understand either. This is what symbol versioning
> > makes possible, even providing different variants for the same symbol,
> > see for example glibc or libbsd.

> I think symbol versioning is subtly different and glibc does not use
> symbol versioning for e.g. gettimeofday selection. With symbol
> versioning, you select a default version at release time and stick to
> it. In other words, building against the updated libselinux does not
> allow you to use the older 32bit variant of the symbol even if you opt
> out of lfs and time64 and you always get the 64bit symbol. What glibc
> does is a little more fancy than my simplistic #define in that it uses
> asm("name") instead. Still this approach allows for selecting which
> symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
> me if I am misrepresenting this as my experience with symbol versioning
> is fairly limited.

Agreed.  libselinux as it happens does use a symbol version map so there is
symbol versioning involved in some sense? but not the sense you really mean.

(We could make the symbol map expose the two different function variants
under the same name but different symbols; that's fine but I'll leave that
for upstream to decide.)

> > In any case, if going the bi-ABI path, I think upstream should get
> > involved, and the shape of this decided with them. In addition
> > the library should also be built with LFS by the upstream build
> > system, which it does not currently, to control its ABI.

> I agree that involving upstream is a good idea and my understanding is
> that someone from Canonical is doing that already, which is why the
> schedule was delayed.

Well, "already" is not exactly correct, but the need to resolve this
critical showstopper bug in libselinux before making changes to the
toolchain behavior in unstable and breaking the world has affected the
timeline, yes.

I now have a tested patch that I've raised as an MP in salsa:

  https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9

I welcome review from the Debian libselinux maintainers prior to opening a
discussion with upstream.  (Which I will plan to do sometime Thursday
US/Pacific)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:
> On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:

>> I'm sorry, this is probably a really obvious question, but could you
>> explain the connection between the subject of your mail message and the
>> body of your mail message?  I can't see any relationship, so I guess I
>> need it spelled out for me in small words.

>> (I believe /etc/shells enforcement is done via PAM or in specific
>> programs that impose this as an additional non-POSIX restriction.  This
>> is outside the scope of POSIX.)

> What's the point of having a standard if programs are allowed to
> reject user settings for arbitrary and undocumented reasons?

I have literally no idea what you're talking about.  It would be really
helpful if you would describe what program rejected your setting and what
you expected to happen instead.

You mentioned /etc/shells in your previous message, but /etc/shells on my
system contains both the /usr/bin and the /bin paths, so I'm still at a
complete loss.

-- 
Russ Allbery (r...@debian.org)  

Bug#1063929: ITP: golang-github-go-quicktest-qt -- Quick helpers for testing Go applications using generics.

[Loren M. Lang]

Package: wnpp
Severity: wishlist
Owner: Loren M. Lang 

* Package name: golang-github-go-quicktest-qt
  Version : 1.101.0-1
  Upstream Author : 
* URL : https://github.com/go-quicktest/qt
* License : Expat
  Programming Lang: Go
  Description : Quick helpers for testing Go applications using generics.

 qt: quicker Go tests
 .
 go get github.com/go-quicktest/qt
 .
 Package qt provides a collection of Go helpers for writing tests. It
 uses generics, so requires Go 1.18 at least.
 .
 For a complete API reference, see the package documentation
 (https://pkg.go.dev/github.com/go-quicktest/qt).
 .
 Quicktest helpers can be easily integrated inside regular Go tests, for
 instance:
 .
   import "github.com/go-quicktest/qt"
 .
   func TestFoo(t *testing.T) {
   t.Run("numbers", func(t *testing.T) {
   numbers, err := somepackage.Numbers()
   qt.Assert(t, qt.DeepEquals(numbers, []int{42, 47})
   qt.Assert(t, qt.ErrorMatches(err, "bad wolf"))
   })
   t.Run("nil", func(t *testing.T) {
   got := somepackage.MaybeNil()
   qt.Assert(t, qt.IsNil(got), qt.Commentf("value: %v",
 somepackage.Value))
   })
   }
 .
 Assertions
 .
 An assertion looks like this, where qt.Equals could be replaced by any
 available checker. If the assertion fails, the underlying t.Fatal method
 is called to describe the error and abort the test.
 .
   qt.Assert(t, qt.Equals(someValue, wantValue))
 .
 If you don’t want to abort on failure, use Check instead, which calls
 Error instead of Fatal:
 .
   qt.Check(t, qt.Equals(someValue, wantValue))
 .
 The library provides some base checkers like Equals, DeepEquals,
 Matches, ErrorMatches, IsNil and others. More can be added by
 implementing the Checker interface.
 .
 Other helpers
 .
 The Patch helper makes it a little more convenient to change a global or
 other variable for the duration of a test.


This package is being added to support cilium/pwru which is RFP in BTS
#1063031.

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > POSIX says:
> 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> 
> > There is no requirement to match one of the /etc/shells pathnames.
> > The user or scripts should be free to use any arbitrary pathname to
> > the command language interpreter available on the system, and Debian
> > should ensure that this is allowed, in particular the one give by
> > the realpath command.
> 
> I'm sorry, this is probably a really obvious question, but could you
> explain the connection between the subject of your mail message and the
> body of your mail message?  I can't see any relationship, so I guess I
> need it spelled out for me in small words.
> 
> (I believe /etc/shells enforcement is done via PAM or in specific
> programs that impose this as an additional non-POSIX restriction.  This is
> outside the scope of POSIX.)

What's the point of having a standard if programs are allowed to
reject user settings for arbitrary and undocumented reasons?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 19:46:58 +0100, Ansgar 🙀 wrote:
> Hi Vincent,
> 
> On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> > POSIX says:
> > 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> > 
> > There is no requirement to match one of the /etc/shells pathnames.
> 
> I have hopefully good news for you! You can set the SHELL variable
> yourself to your preferred value. For example:
> 
> export SHELL=/home/user/.bin/the-best-shell-of-all
> 
> (The details might vary depending on the shell you are currently in.)
> usrmerge does not affect this at all.

This is invalid. See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: 64-bit time_t transition in progress

[Bill Allombert]

On Fri, Feb 02, 2024 at 08:23:44PM +0100, Bill Allombert wrote:
> > > Relying on dpkg-buildflags alone cannot be sufficient.
> > 
> > I don't see any practical reason why not.
> 
> Because packages are not required to use dpkg-buildflags.

Also currently, there are about 20 lib*t64 packages in experimental
that are missing the actual library file: 

compare:
https://packages.debian.org/sid/amd64/libbigwig0/filelist
with
https://packages.debian.org/experimental/amd64/libbigwig0t64/filelist

and
https://packages.debian.org/sid/amd64/libbpp-core4/filelist
with
https://packages.debian.org/experimental/amd64/libbpp-core4t64/filelist

etc. (List below).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

--
libbigwig0t64
libbpp-core4t64
libbpp-phyl12t64
libbpp-phyl-omics3t64
libbpp-popgen8t64
libbpp-qt2t64
libbpp-raa4t64
libbpp-seq12t64
libbpp-seq-omics3t64
libcamp0.8t64
libcapi20-3t64
libc-client2007t64-dev
libhighwayhash0t64
libmems1t64
libpari-gmp-tls8t64
librostlab3t64
libslow5-0t64
libtabixpp0t64
libtecla1t64
libterralib3t64
libxqdbm3t64

Bug#1063919: ITP: python-pyu2f -- pure python U2F host library

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 
X-Debbugs-Cc: debian-devel@lists.debian.org, hlieber...@debian.org

* Package name: python-pyu2f
  Version : 0.1.5
  Upstream Contact: Google 
* URL : https://www.github.com/google/pyu2f
* License : Apache-2.0
  Programming Lang: Python
  Description : pure python U2F host library

pyu2f is a python based U2F host library for Linux, Windows, and MacOS. It
provides functionality for interacting with a U2F device over USB.
.
pyu2f uses ctypes to make system calls directly to interface with the USB HID
device. This means that no platform specific shared libraries need to be
compiled for pyu2f to work.

Bug#1063917: ITP: python-pylatex -- Python library for creating LaTeX files and snippets

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com

* Package name: python-pylatex
  Version : 1.4.2
  Upstream Contact: Jelte Fennema 
* URL : https://github.com/JelteF/PyLaTeX
* License : Expat
  Programming Lang: Python
  Description : Python library for creating LaTeX files and snippets

PyLaTeX is a Python library for creating and compiling LaTeX files or
 snippets. The goal of this library is being an easy, but extensible
 interface between Python and LaTeX. This package is depends for some of
 the scientific packages. Planning to maintain under Debian Python Team
 and need sponsorship.

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Jeffrey Walton]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: freenginx
  Version : 1.24.0
  Upstream Author : Maxim Dounin and the development community
  Section: web
* URL : http://freenginx.org/
* License : GPL
  Programming Lang: C
  Description : a fork of nginx maintained by Maxim Dounin and the
development community

-

In February 2024, Maxim Dounin forked Nginx and created the freenginx
project. According to Maxim's announcement on the nginx-users mailing
list 
():


Hello!

As you probably know, F5 closed Moscow office in 2022, and I no
longer work for F5 since then.  Still, we’ve reached an agreement
that I will maintain my role in nginx development as a volunteer.
And for almost two years I was working on improving nginx and
making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently
decided that they know better how to run open source projects.  In
particular, they decided to interfere with security policy nginx
uses for years, ignoring both the policy and developers’ position.

That’s quite understandable: they own the project, and can do
anything with it, including doing marketing-motivated actions,
ignoring developers position and community.  Still, this
contradicts our agreement.  And, more importantly, I no longer able
to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and
maintained for the public good.

As such, starting from today, I will no longer participate in nginx
development as run by F5.  Instead, I’m starting an alternative
project, which is going to be run by developers, and not corporate
entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate
actions.  Help and contributions are welcome.  Hope it will be
beneficial for everyone.

-- 
Maxim Dounin
http://freenginx.org/

Bug#1063912: ITP: pass-extension-update -- pass extension that provides an easy flow for updating passwords

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pass-extension-update
  Version : 2.1
  Upstream Contact: Alex roddhjav
* URL : https://github.com/roddhjav/pass-update
* License : GPL-3
  Programming Lang: Shell
  Description : pass extension that provides an easy flow for updating 
passwords

pass update extends the pass utility with an update command providing
an easy flow for updating passwords. It supports path, directory and
wildcard update. Moreover, you can select how to update your passwords
by automatically generating new passwords or manually setting your
own.

pass update assumes that the first line of the password file is the
password and so only ever updates the first line unless the
--multiline option is specified.

By default, pass update prints the old password and waits for the user
before generating a new one. This behaviour can be changed using the
provided options.



I need something like this for work so I'll take a look at how
reasonable this is. There's already a Debian package in the upstream
source too.$

Re: usrmerge breaks POSIX

[Ansgar 🙀]

Hi Vincent,

On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> POSIX says:
> 
>   SHELL   This variable shall represent a pathname of the user's
>   preferred command language interpreter. If this interpreter
>   does not conform to the Shell Command Language in XCU
>   Chapter 2 (on page 2345), utilities may behave differently
>   from those described in POSIX.1-2017.
> 
> There is no requirement to match one of the /etc/shells pathnames.

I have hopefully good news for you! You can set the SHELL variable
yourself to your preferred value. For example:

export SHELL=/home/user/.bin/the-best-shell-of-all

(The details might vary depending on the shell you are currently in.)
usrmerge does not affect this at all.

Ansgar

Re: usrmerge breaks POSIX

[Russ Allbery]

Vincent Lefevre  writes:

> POSIX says:

>   SHELL   This variable shall represent a pathname of the user's
>   preferred command language interpreter. If this interpreter
>   does not conform to the Shell Command Language in XCU
>   Chapter 2 (on page 2345), utilities may behave differently
>   from those described in POSIX.1-2017.

> There is no requirement to match one of the /etc/shells pathnames.
> The user or scripts should be free to use any arbitrary pathname to
> the command language interpreter available on the system, and Debian
> should ensure that this is allowed, in particular the one give by
> the realpath command.

I'm sorry, this is probably a really obvious question, but could you
explain the connection between the subject of your mail message and the
body of your mail message?  I can't see any relationship, so I guess I
need it spelled out for me in small words.

(I believe /etc/shells enforcement is done via PAM or in specific
programs that impose this as an additional non-POSIX restriction.  This is
outside the scope of POSIX.)

-- 
Russ Allbery (r...@debian.org)  

usrmerge breaks POSIX

[Vincent Lefevre]

POSIX says:

  SHELL   This variable shall represent a pathname of the user's
  preferred command language interpreter. If this interpreter
  does not conform to the Shell Command Language in XCU
  Chapter 2 (on page 2345), utilities may behave differently
  from those described in POSIX.1-2017.

There is no requirement to match one of the /etc/shells pathnames.
The user or scripts should be free to use any arbitrary pathname to
the command language interpreter available on the system, and Debian
should ensure that this is allowed, in particular the one give by
the realpath command.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#1010746: ITP: docker-squash -- Squashing helps with organizing docker images in logical layers

[Jonathan Dowland]

Hi,

Are you still working on a Debian package of docker-squash[1]?

I would like it packaged as a dependency of Cekit[2], so if
you have stopped working on it I can take over this ITP.

Note that Docker/Moby API version 1.25 has introduced a new,
experimental, similar feature "--squash" argument for builds;
I don't know how well it works, whether it will stay in Docker
longer term (and become not experimental) and for the time
being Cekit doesn't use it.

[1] https://bugs.debian.org/1010746
[2] https://bugs.debian.org/1055584


Thanks,


-- 
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: 64-bit time_t transition in progress

[Bill Allombert]

Le Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek a écrit :
> In my view, it's fine then to upload libfoo2 to unstable without the t64
> suffix as ABI compatibility with experimental is not really required.  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.

But then libfoo2t64 will need to clear binary NEW again.

Would not have been possible to send the list of new t64 package names
to approve to the ftp-master team directly, instead of using the NEW
queue and interferring with the maintainers use of experimental ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1063906: ITP: monitoring-plugins-check-smart -- check S.M.A.R.T. storage system monitoring plugin for nagios compatible monitoring systems

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: monitoring-plugins-check-smart
  Version : 6.14.1
  Upstream Contact: Claudio Kuenzler
* URL : 
https://www.claudiokuenzler.com/monitoring-plugins/check_smart.php
* License : GPL
  Programming Lang: Perl
  Description : check S.M.A.R.T. storage system monitoring plugin for 
nagios compatible monitoring systems

The check_smart monitoring plugin uses smartmontools to monitor the
health of physical hard drives via a central nagios based monitoring
system.

Ideally it should be maintained within the Debian Nagios Maintainer
Group. It could alternatively be added to monitoring-plugins-contrib,
adding extra sugests for smartmontools and sudo.

Bug#1063899: ITP: auxilium -- tool for parse args in many shell (bash, ksh,zsh)

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: auxilium
  Version : 0.0.9
  Upstream Contact: Philippe Seraphin 
* URL : https://salsa.debian.org/openstack-team/third-party/auxilium
* License : Apache-2.0
  Programming Lang: Bash
  Description : tool for parse args in many shell (bash, ksh,zsh)

 This help you to parse command-line arguments. 
 You can source it in your shell script and use different function to add
 argument, print usage and parse arguments