Bug#951189: ITP: opensurge -- Fun 2D retro platformer inspired by Sonic games

[Carlos Donizete Froes]

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: opensurge
  Version : 0.5.1.2-1
  Upstream Author : Alexandre Martins 
* URL : https://opensurge2d.org
* License : GPL-3+
  Programming Lang: C
  Description : Fun 2D retro platformer inspired by Sonic games

 Open Surge is a fun 2D retro platformer inspired by Sonic games
 and a game creation system that lets you unleash your creativity!
 Play, create games & share!

 I plan to keep the OpenSurge package on the Debian Games team.

 Thanks!

--
 Carlos Donizete Froes [a.k.a coringao] 

Bug#951184: RFP: libfido2 -- communicate with a FIDO device over USB

[Colin Watson]

Package: wnpp
Severity: wishlist

* Package name: libfido2
  Version : 1.3.0
  Upstream Author : Yubico AB
* URL : https://github.com/Yubico/libfido2
* License : BSD-2-clause
  Programming Lang: C
  Description : communicate with a FIDO device over USB

libfido2 provides library functionality and command-line tools to
communicate with a FIDO device over USB, and to verify attestation and
assertion signatures.

libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols.


This is going to be an optional dependency of OpenSSH 8.2 (optional at
build time, I think, though it seems sufficiently useful that I'd be
inclined to link against it by default if it doesn't impose an
unreasonable run-time footprint), needed for U2F/FIDO support which is
the principal new feature in that release.  As such I'd like to be able
to enable it.

I do have a Yubikey 5 NFC which would be suitable for testing this with,
and in principle I'd probably be able to maintain this package
reasonably well, but I also have a lot to do and would rather give
somebody else the chance to take it on first.  I expect I'll start work
on it in a week or two if nobody else picks this up.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Tue, Feb 11, 2020 at 9:10 PM Florian Weimer  wrote:
> * Ansgar:
> > Arnd Bergmann writes:
> >> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
> >>> There's going to be a _TIME_BITS selector, similar to
> >>> _FILE_OFFSET_BITS.
> >>>
> >>> There was a proposal to have only one API before, but I think the
> >>> agreement was that it wouldn't save much complexity.
> >>
> >> It should be easy to force the _TIME_BITS selection by patching the
> >> glibc headers in Debian though if we want.
> >>
> >> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
> >> but leaving the libc default at 32 bits is that anything that users build
> >> themselves or that ignores the buildflags ends up with a broken ABI
> >> when linking against one of the many libraries that expose time_t
> >> in their ABI.
> >
> > It breaks the other way too:
> >
> > If you have an old library with a time_t in some public ABI, but an
> > application using it sets _TIME_BITS=64, the headers suddenly define a
> > different ABI from the one implemented by the compiled library.
> >
> > If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> > breaks reverse dependencies (ignoring special handling like libc does
> > with versioned symbols). So you cannot just change it by default.
> >
> > I don't understand how this can work unless time_t is *never* exposed by
> > any library other than libc.

I think Steve explained this already in the initial email: in approach A,
rebuilding any library that exposes a modified time_t implies an incompatible
library update and updating anything that depends on it to be built with
the time64 interface as well, which quickly gets out of hand when you do this
recursively.

With approach B, there is no attempt at binary compatibility, instead
a new armhf_time64 port would use the same package names and
versions as the existing armhf port, but have an incompatible ABI
for anything exposing time_t based interfaces. Changing the target
triplet then allows a multiarch installation to coexist with armhf, the
same way that you can have armel and armhf coexisting today, with
an incompatible ABI.

> Correct.  We have this problem with off_t today, which is used in some
> header files.  The problem is particularly thorny because like
> off64_t, time64_t will never be a standard type, so some projects
> don't want to use it in headers.  And using time64_t would still be an
> ABI break on i386.

AFAIU time64_t is not even going to be exposed in the glibc headers
in the first place, you just pick which ABI you get when compiling an
application and hope it matches the other libraries.

Arnd

Bug#951176: ITP: mate-hud -- Run menubar commands, much like the Unity 7 HUD

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: mate-hud
  Version : 19.10.1
  Upstream Author : Martin Wimpress 
* URL : https://github.com/ubuntu-mate/mate-hud/
* License : GPL-2+
  Programming Lang: Python
  Description : Run menubar commands, much like the Unity 7 HUD

 A Heads-Up Display (HUD) allows you to search through an application's
 appmenu. So if you're trying to find that single filter in Gimp but
 can't remember which filter category it fits into or if you can't
 recall if preferences sits under File, Edit or Tools on your favourite
 browser, you can just search for it rather than hunting through the
 menus.
 .
 This package will be maintained under the umbrella of the Debian+Ubuntu
 MATE Packaging Team.

Bug#951166: ITP: shortwave -- Find and listen to internet radio stations

[David Heidelberg]

Package: wnpp
Severity: wishlist
Owner: David Heidelberg 

* Package name: shortwave
  Version : 0.0.2
  Upstream Author : Felix Häcker 
* URL : https://gitlab.gnome.org/World/Shortwave
* License : GPL-3.0-or-later
  Programming Lang: Rust
  Description : Find and listen to internet radio stations

GNOME application for listening internet radio streams.


 - it's modern, clean and functional radio player for GNOME, it also
   features ability to save previously played songs
 - I need a sponsor

Bug#951162: ITP: php-dragonmantank-cron-expression -- cron expression parser for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-dragonmantank-cron-expression
  Version : 2.3.0
  Upstream Author : Chris Tankersley 
* URL : https://github.com/dragonmantank/cron-expression
* License : MIT
  Programming Lang: PHP
  Description : cron expression parser for PHP

PHP library implementing a cron expression parser.

The PHP cron expression parser can parse a cron expression, determine if it is
due to run, calculate the next run date of the expression, and calculate the
previous run date of the expression.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951163: ITP: php-vlucas-phpdotenv -- environment variable file loader for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-vlucas-phpdotenv
  Version : 3.6.0
  Upstream Author : Vance Lucas 
* URL : https://github.com/vlucas/phpdotenv
* License : BSD
  Programming Lang: PHP
  Description : environment variable file loader for PHP

PHP library implementing an environment variable file (.env) loader for PHP.

The environment file loader will load environment variables from .env files to
getenv(), $_ENV and $_SERVER automagically.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951164: ITP: php-phpoption -- Option type for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-phpoption
  Version : 1.7.2
  Upstream Author : Johannes M. Schmitt 
* URL : https://github.com/schmittjoh/php-option
* License : Apache-2.0
  Programming Lang: PHP
  Description : Option type for PHP

PHP library implementing an Option type for PHP.

The Option type is intended for cases where you sometimes might return a value
(typically an object), and sometimes you might return a base value (typically
null) depending on arguments, or other runtime factors.

This package is a dependency of php-vlucas-phpdotenv (ITP #951163).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951159: ITP: php-laravel-framework -- web application framework for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-laravel-framework
  Version : 6.15.0
  Upstream Author : Taylor Otwell 
* URL : https://github.com/laravel/framework
* License : MIT
  Programming Lang: PHP
  Description : web application framework for PHP

Laravel is a web application framework for PHP with expressive, elegant syntax.

This package will be a multi-binary package building the many php-illuminate-*
library components that make up the Laravel framework, but that are also used
by other PHP frameworks and applications.

It will replace the separate php-illuminate-* source packages that are already
in Debian.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951156: ITP: php-laravel-lumen-framework -- micro-framework for building web applications in PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-laravel-lumen-framework
  Version : 6.3.3
  Upstream Author : Taylor Otwell 
* URL : https://github.com/laravel/lumen-framework
* License : MIT
  Programming Lang: PHP
  Description : micro-framework for building web applications in PHP

Laravel Lumen is a stunningly fast PHP micro-framework for building web
applications with expressive, elegant syntax. Lumen attempts to take the pain
out of development by easing common tasks used in the majority of web projects,
such as routing, database abstraction, queueing, and caching.

This library contains the core code of the Laravel Lumen framework.

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Re: Heads up: persistent journal has been enabled in systemd

[Anthony DeRobertis]

On February 11, 2020 6:28:08 PM UTC, Ansgar  wrote:
>
>The downside is that magic like [rsyslog disabling persistent journal] might 
>not be easily discoverable
>and confuse people who for some reason want a persistent journal and
>syslog.

A lot of my machines are configured like that, mainly because of how much 
faster things like tail -f /var/log/syslog are vs. journalctl -f. So I keep a 
short amount of logs in traditional syslog format (quick access), and much 
longer history in journald (better search/filter). I get the best of both 
worlds.

It'd be very surprising if rsyslog disabled the persistent journal on upgrade. 
Or when installing it.

I think it'd be fine for it to give me the option, default do not disable, via 
debconf, not sure if that'd be low or medium.

There's the obvious point that enabling the persistent journal could be 
surprising, too. But I think the harm there is relatively minimal (increased 
disk usage, but journald will not fill a filesystem) and is easily fixed with 
rm. The lack of a persistent journal isn't necessarily noticed until you try to 
check the logs, and at that point may be unfixable: the data is gone.

I would more worry about the harm on systems where there are intentionally no 
persistent logs, neither journal nor syslog. There could be privacy 
implications. But hopefully the release notes cover that use case.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ansgar:

> Arnd Bergmann writes:
>> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>>> There's going to be a _TIME_BITS selector, similar to
>>> _FILE_OFFSET_BITS.
>>>
>>> There was a proposal to have only one API before, but I think the
>>> agreement was that it wouldn't save much complexity.
>>
>> It should be easy to force the _TIME_BITS selection by patching the
>> glibc headers in Debian though if we want.
>>
>> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
>> but leaving the libc default at 32 bits is that anything that users build
>> themselves or that ignores the buildflags ends up with a broken ABI
>> when linking against one of the many libraries that expose time_t
>> in their ABI.
>
> It breaks the other way too:
>
> If you have an old library with a time_t in some public ABI, but an
> application using it sets _TIME_BITS=64, the headers suddenly define a
> different ABI from the one implemented by the compiled library.
>
> If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> breaks reverse dependencies (ignoring special handling like libc does
> with versioned symbols). So you cannot just change it by default.
>
> I don't understand how this can work unless time_t is *never* exposed by
> any library other than libc.

Correct.  We have this problem with off_t today, which is used in some
header files.  The problem is particularly thorny because like
off64_t, time64_t will never be a standard type, so some projects
don't want to use it in headers.  And using time64_t would still be an
ABI break on i386.

Re: Heads up: persistent journal has been enabled in systemd

[Ansgar]

Hi,

On Sat, 2020-02-01 at 13:36 +, Steve McIntyre wrote:
> Michael Biebl wrote:
> > with today's upload of systemd 244.1-2 I finally enabled persistent
> > journal by default [1]. It has been a long requested feature.
> > 
> > The package will create a directory /var/log/journal on upgrades and new
> > installs, which enables persistent journal in so called auto mode.
> 
> Fine for new installations, but please *don't* do this for
> upgrades. Those people with existing logging setups will be surprised
> by this.

I generally prefer upgraded systems to behave more like newly installed
ones, but I wonder if here syslog daemons like rsyslog should ship a
journald.conf dropin in lib/systemd/journald.conf.d/00-rsyslog.conf
setting `Storage=volatile`. If you have installed a syslog daemon, you
likely don't want a persistent journal as well.

Upgraded systems that have rsyslog installed won't get a persistent
journal this way.

The downside is that magic like this might not be easily discoverable
and confuse people who for some reason want a persistent journal and
syslog.

Ansgar

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Tue, Feb 11, 2020 at 12:07 PM Marco d'Itri  wrote:
>
> On Feb 11, Arnd Bergmann  wrote:
>
> > I agree that changing the i386 port is probably a bad idea at the moment,
> > let's see how the armhf port turns out and fix all the bugs first, as this
> > is clearly needed anyway. Once there is a working armhf version with
> > full time64 user space, there can be a separate discussion about what
> > to do with the i386 port (phase out i386 before y2038, migrate all of
> > i386 to time64 quickly, have two separate i386 ports, or something
> > else).
>
> I have still not seen any explanation about why we expect that 32 bit
> ARM systems will still be popular (as non-embedded) ~15 years from now.

I think most installations of Debian on 32-bit ARM are already for embedded
systems, but that doesn't make them less important IMHO. In some deeply
embedded systems, you'd be looking at installing a current version of Debian
(because why not) and then running it for decades beyond the end of support
without updates. While this is often no problem in the absence of attack
vectors, the time32 problem means that a piece of industrial equipment
may be created for a 40 year lifetime today and work flawlessly for the first
18 years before suddenly breaking. The sooner time64 gets supported in
Debian, the more of them have a  chance of surviving.

I did some research last year to see how long these systems tend to
live before they are obsolete, here is a rough summary for each architecture
version:

* ARMv4 based chips were released between ~1997 and 2007, the last
  supported released was Debian Lenny, originally in 2009, with support
  ending in 2012.
* ARMv4T based chips were more popular and came out during the
  same timeframe (1997 to 2007), last supported in Debian Stretch,
  released in 2017 and LTS support ending in 2022.
* ARMv5 was introduced in ~2002 and is still supported, with a few
  new chips still being taped out (Microchip SAM9X60, Allwinner
  F-Series) and being actively deployed in large numbers for several
  years to come. I expect the last Debian release with ARMv5 support
  between 2025 and 2030, with the last users relying on Debian LTS
  powering the hardware off well before 2038.
* ARMv6 was less popular, most chips (i.MX3, S3C64xx, OMAP2)
  from 2005 to 2014 are obsolete or never ran Debian in the first
  place (e.g. AST2500). The main exception is probably Raspbian
  on BCM2835, which surely will be used as long as you can
  fit Debian into 512MB of RAM, plus several years after support
  ends, probably beyond 2038.
* ARMv7 chips came out between 2005 and 2015 but were more
  popular than the above combined. Since Cortex-A5 is now part of
  Arm's DesignStart program, we will see new tapeouts for years to
  come, and some of them are likely to run Debian for longer than the
  existing chips.
* ARMv7VE (first introduced in 2012) is still the most common
  architecture for embedded designs today, we'll probably see new
  Cortex-A7 based chips for another 5 to 10 years, followed by several
  years of new boards based on those chips and a very long time
  before these finally get powered off.
* ARMv8 is surely taking over the lead in the embedded space from
  ARMv7/ARMv7VE over the next few years. Almost all of these
  can run 64-bit code, but when shipping enough of them, the cost
  of the on-board RAM means you are stuck with a single 4Gbit DDR3
  chip (512MB), which in turn means you want to run 32-bit user
  space to lower the memory consumption for the application.
  The next sensible step up from 512MB DDR3 (on a single chip) is
  probably 2GB of LP-DDR4 with 64-bit user space, but it will likely
  take many years before that is actually cheap enough completely
  obsolete DDR3 memory and 32-bit mode with it.

  Arnd

Re: Y2038 - best way forward in Debian?

[Steve McIntyre]

On Tue, Feb 11, 2020 at 12:01:28PM +0100, Marco d'Itri wrote:
>On Feb 11, Arnd Bergmann  wrote:
>
>> I agree that changing the i386 port is probably a bad idea at the moment,
>> let's see how the armhf port turns out and fix all the bugs first, as this
>> is clearly needed anyway. Once there is a working armhf version with
>> full time64 user space, there can be a separate discussion about what
>> to do with the i386 port (phase out i386 before y2038, migrate all of
>> i386 to time64 quickly, have two separate i386 ports, or something
>> else).
>I have still not seen any explanation about why we expect that 32 bit 
>ARM systems will still be popular (as non-embedded) ~15 years from now.

That's a fair question to ask!

We're already seeing quite a number of people embedding small-ish
ARMv7 boards in infrastructure, and AIUI a lot of them are using
Debian as a base already - see the Civil Infrastructure Platform as an
example: https://www.cip-project.org/

As these people are already engaging in ELTS work, I don't expect that
this setup is going to go away any time soon.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#951126: ITP: microsoft-authentication-library-for-python -- Microsoft Authentication Library (MSAL) for Python

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 949763 by -1

* Package name: microsoft-authentication-library-for-python
  Version : 1.1.0
  Upstream Author : Microsoft Corporation
* URL : 
https://github.com/AzureAD/microsoft-authentication-library-for-python
* License : MIT
* Programming Lang: Python
* Description : Microsoft Authentication Library (MSAL) for Python

The Microsoft Authentication Library for Python enables applications to
integrate with the Microsoft identity platform. It allows you to sign
in users or apps with Microsoft identities (Azure AD, Microsoft
Accounts and Azure AD B2C accounts) and obtain tokens to call Microsoft
APIs such as Microsoft Graph or your own APIs registered with the
Microsoft identity platform. It is built using industry standard OAuth2
and OpenID Connect protocols

It is required as a new dependency of the new version of python-azure.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#951122: ITP: tiledb -- Store and access very large multi-dimensional array data

[Adam Cecile]

Package: wnpp
Severity: wishlist
Owner: Adam Cecile 

* Package name: tiledb
  Version : 1.7.5
  Upstream Author : TileDB, Inc
* URL : https://tiledb.com/
* License : Expat
  Programming Lang: C++
  Description : Store and access very large multi-dimensional array data

TileDB allows you to store and access very large multi-dimensional array data,
the data currency of Data Science.

It is a powerful storage engine that introduces a novel format that can
effectively store both dense and sparse array data with support for fast
updates and reads.

on beating dead horses (Re: Debian With Alternate Init Systems)

[Holger Levsen]

On Mon, Feb 10, 2020 at 06:36:08PM +0100, Samuel Thibault wrote:
> (leaving the other parts of threads to later, when I'll get time to
> think what useful answer I can give, beyond just apologizing)
 
please dont reply later, everyone is sick of init system discussions on
debian-devel@l.d.o. - discussions also don't change anything here.

(instead please file bugs, write patches, have a walk outside, read a book,
 start some other more interesting discussion, work on some uploads, whatever.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet. (Also many other things but people mostly
seem to care about jobs.)


signature.asc
Description: PGP signature

Bug#951118: ITP: purple-carbons -- XEP-0280: Message Carbons for libpurple

[Olivier Mehani]

Package: wnpp
Severity: wishlist
Owner: Olivier Mehani 

* Package name: purple-carbons
  Version : 0.2.2
  Upstream Author : Richard Bayerle 
* URL : https://github.com/gkdr
* License : GPL
  Programming Lang: C
  Description : XEP-0280: Message Carbons for libpurple

Useful in combination with purple-lurch (XEP-0384) to support 
multi-device encryption; RFP/ITP at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905883

Bug#905883: ITP: purple-lurch

[Olivier Mehani]

Package: wnpp
Followup-For: Bug #905883
Owner: Olivier Mehani 

Hi,

I'm just trying my hand at building a package for this.

I have previously done some work on this library to make it run with 
Adim on OS X. It should be fairly straightforward (famous last 
words...).

Re: Y2038 - best way forward in Debian?

[Marco d'Itri]

On Feb 11, Arnd Bergmann  wrote:

> I agree that changing the i386 port is probably a bad idea at the moment,
> let's see how the armhf port turns out and fix all the bugs first, as this
> is clearly needed anyway. Once there is a working armhf version with
> full time64 user space, there can be a separate discussion about what
> to do with the i386 port (phase out i386 before y2038, migrate all of
> i386 to time64 quickly, have two separate i386 ports, or something
> else).
I have still not seen any explanation about why we expect that 32 bit 
ARM systems will still be popular (as non-embedded) ~15 years from now.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#951113: ITP: webp-pixbuf-loader -- WebP Image format GdkPixbuf loader.

[David Heidelberg]

Package: wnpp
Severity: wishlist
Owner: David Heidelberg 

* Package name: webp-pixbuf-loader
  Version : git
  Upstream Author : Alberto Ruiz 
* URL : https://github.com/aruiz/webp-pixbuf-loader/
* License : LGPL-2.0-or-later
  Programming Lang: C
  Description : WebP Image format GdkPixbuf loader.

WebP Image format GdkPixbuf loader.
webp-pixbuf-loader integrates libwebp library into GDK image processing
framework, so GDK based application can use WEBP format natively.


- this package makes GNOME and GDK/GTK apps understandt webp, so after
  instalation of this loader, GNOME is able show up webp in all
  application where is pixbuf used.
- I need sponsor (Mike Gabriel?).

Bug#951110: ITP: cyrus-timezones -- Timezone information for the Cyrus IMAP Server

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: cyrus-timezones
  Version : 0.0~git20190710.1a0107a
  Upstream Author : Cyrus-Imapd maintainers 
* URL : https://github.com/cyrusimap/cyrus-timezones
* License : GPL-2+
  Programming Lang: C
  Description : Timezone information for the Cyrus IMAP Server

cyrus-timezones provides timezone information for the Cyrus IMAP Server.
By use of the vzic timezone compiler it compiles VTIMEZONEs based on the
latest IANA timezone database (https://www.iana.org/time-zones).

The generated timezones are installed at /usr/share/cyrus-timezones/zoneinfo
and their absolute path is defined as a pkg-config variable:

$ pkg-config --variable=zoneinfo_dir cyrus-timezones

This library improves cyrus-imapd ≥ 3.2. I'm maintainer of cyrus-imapd
and will maintain this package.

Re: Y2038 - best way forward in Debian?

[Ansgar]

Arnd Bergmann writes:
> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>> There's going to be a _TIME_BITS selector, similar to
>> _FILE_OFFSET_BITS.
>>
>> There was a proposal to have only one API before, but I think the
>> agreement was that it wouldn't save much complexity.
>
> It should be easy to force the _TIME_BITS selection by patching the
> glibc headers in Debian though if we want.
>
> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
> but leaving the libc default at 32 bits is that anything that users build
> themselves or that ignores the buildflags ends up with a broken ABI
> when linking against one of the many libraries that expose time_t
> in their ABI.

It breaks the other way too:

If you have an old library with a time_t in some public ABI, but an
application using it sets _TIME_BITS=64, the headers suddenly define a
different ABI from the one implemented by the compiled library.

If you rebuild the library with _TIME_BITS=64, it changes ABI too and
breaks reverse dependencies (ignoring special handling like libc does
with versioned symbols). So you cannot just change it by default.

I don't understand how this can work unless time_t is *never* exposed by
any library other than libc.

Ansgar

Re: Bug#951104: ITP: node-markdown-it -- FIX_ME write the Debian package description

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: retitle -1 ITP: node-markdown-it -- fast and easy to extend markdown 
parser

On Ma, 11 feb 20, 13:05:08, Sakshi Sangwan wrote:
> Package: markdown-it
> Severity: wishlist
> Owner: Sakshi Sangwan 
> 
> * Package name: node-markdown-it
>   Version : 10.0.0
>   Upstream Author : Vitaly Puzrin, Alex Kocharin
> * URL : https://github.com/markdown-it/markdown-it#readme
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Fast and easy to extend markdown parser
> 
>  Follows the CommonMark spec, adds syntax extensions and sugar (URL
>  autolinking, typographer). Provides configurable syntax, can add new
>  rules and even replace existing ones, and high speed
>  .
>  Node.js is an event-based server-side JavaScript engine.
> 
> This is a dependency of Gitlab.
> 
> Best,
> Sakshi

Hello,

You might want to use X-Debbugs-Cc (instead of regular Cc) to copy in 
other recipients.

Kind regards,
Andrei
-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>
> * Ben Hutchings:
>
> > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> >> * Ben Hutchings:
> >>
> >> > If I recall correctly, glibc *will* provide both entry points, so there
> >> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
> >> > dev is fixed at glibc build time.
> >>
> >> Is this a Debian-specific decision?
> >
> > I though that was the *upstream* decision, but perhaps that's still not
> > decided after all?
>
> There's going to be a _TIME_BITS selector, similar to
> _FILE_OFFSET_BITS.
>
> There was a proposal to have only one API before, but I think the
> agreement was that it wouldn't save much complexity.

It should be easy to force the _TIME_BITS selection by patching the
glibc headers in Debian though if we want.

The problem with setting _TIME_BITS=64 only using dpkg-buildflags
but leaving the libc default at 32 bits is that anything that users build
themselves or that ignores the buildflags ends up with a broken ABI
when linking against one of the many libraries that expose time_t
in their ABI.

 Arnd

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Fri, Feb 7, 2020 at 10:21 PM Florian Weimer  wrote:
>
> * Steve McIntyre:
>
> > The kernel is *basically* fixed now. Internally, data structures
> > should now be safe. There are a small number places where 32-bit time
> > is still a thing, but it's in hand. A number of syscalls, ioctls,
> > etc. have needed updates for the user-kernel interface level.
>
> XFS is the elephant in the room, though.

XFS is one of the main concerns for 64-bit kernels, but the patches
are likely to get merged in one of the next releases.

For 32-bit, all the ABI issues need to be solved first to have
a working system at all, so let's get that sorted. Obviously all
problems that 64-bit has also need to be solved on 32-bit.

> > glibc is the place that needs to care about most of this.
>
> I'm not so sure.  I really do not want glibc to parse and rewrite
> ioctl arguments and return values, or ancillary socket data.

For a new distro target, it's easy to mandate a minimum kernel
version that has all the ioctls. Users that are stuck on old kernels
for a particular hardware can keep using the existing armhf user
space until that is discontinued.

> >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >default* to use 32-bit time_t to keep compatibility with existing
> >code. This will *not* be safe as we approach 2038.
> >
> >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> >upwards, but this will of course affect the ABI. Embedded uses of
> >time_t in libraries will change size, etc. This *will* be safe for
> >2038.
> >
> > So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> > need to basically rebuild the world to be 2038-safe.
>
> The question is whether anyone wants an i386 port where this has
> happened.
>
> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.  Otherwise they would
> have rebuilt them for x86-64 by now.  Under this worldview, i386 is
> for backwards compatibility with existing software.  Users will want
> to run these old programs in a time namespace with shifted time, too.

I agree that changing the i386 port is probably a bad idea at the moment,
let's see how the armhf port turns out and fix all the bugs first, as this
is clearly needed anyway. Once there is a working armhf version with
full time64 user space, there can be a separate discussion about what
to do with the i386 port (phase out i386 before y2038, migrate all of
i386 to time64 quickly, have two separate i386 ports, or something
else).

  Arnd