Uploading of libjpeg-turbo 2.0.x to unstable

[Mike Gabriel]

Hi all,

(as an unregular reader of debian-devel, please Cc: me so that I don't  
miss your replies)


I have uploaded libjpeg-turbo 2.0.x to experimental several months ago  
(August 2019). I feel, it is time to get 2.0.x into testing/unstable  
now.


However, I have never really done a transition of such a core'ish  
shared library package and I'd love to receive some guidance with this  
before I do the actual upload.


First of all, I don't think that a classical transition is required as  
there has not been an SONAME change for the shared libs in  
libjpeg-turbo. Package names haven't changed, either.


Simply uploading and waiting for things to break (at runtime) is  
neither a good approach, I sense. I have done some usual smoke tests  
(running this and that desktop environment, viewing JPEG images,  
etc.), but that feels insufficient.


People experienced with transitions of core packages with libjpeg  
testings, how would you approach sanity checks of libjpeg-turbo 2.0.x  
before uploading?

https://salsa.debian.org/debian/libjpeg-turbo

Thanks in advance for any kind of input,
Mike

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpdBXH9C8Nxy.pgp
Description: Digitale PGP-Signatur

Re: default firewall utility changes for Debian 11 bullseye

[Iustin Pop]

On 2019-12-19 12:29:59, Roberto C. Sánchez wrote:
> Hi Arturo!
> 
> I know that this discussion took place some months ago, but I am just
> now getting around to catching up on some old threads :-)

Same here :)

> On Tue, Jul 30, 2019 at 01:52:30PM +0200, Arturo Borrero Gonzalez wrote:
> > > 2) introduce firewalld as the default firewalling wrapper in Debian, at 
> > > least in
> > > desktop related tasksel tasks.
> > > 
> > 
> > There are some mixed feelings about this. However I couldn't find any strong
> > opinion against either.
> > 
> > What I would do regarding this is (just a suggestion):
> > * raise priority of firewalld
> > * document in-wiki what defaults are, and how to move away from them
> > * include some documentation bits in other firewalling wrappers on how to 
> > deal
> > with this default, i.e what needs to be changed in the system for ufw to 
> > work
> > without interferences (disable firewalld?)
> > 
> I like the idea of documenting this all in a wiki.

Yes, please. I was also bit by nftables migration when moving to buster
for some of my home-grown firewal scripts (running just fine for 10+
years, but now - looking forward to migrate to nft), so having this
documented would be very welcome, to see what alternatives are there.

iustin

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Russ Allbery]

Zbigniew Jędrzejewski-Szmek  writes:

> we talked this over in systemd upstream, and decided to make the promise
> a bit more official [0]. Independent operation of a bunch of programs is
> now explicitly covered, and the stability promise has been extended to
> more interfaces. The old wiki page with the stability/portability charts
> [1,2] is now replaced by an in-repo page [3], which is the new official
> location for this data [4].

Thank you!  This is very helpful.

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

Re: https://tracker.debian.org/pkg/dballe

[Wouter Verhelst]

On Mon, Dec 30, 2019 at 02:47:45AM +, Paul Wise wrote:
> On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote:
> 
> > [1] Source packages that build binaries unknown to the archive currently
> > need these binaries to be uploaded by the maintainers for reviewing by
> > ftp-master in NEW. IIRC there have been multiple proposals to avoid
> > these binaries from either being needed or being uploaded to the Debian
> > archive, but so far the current tooling requires this.
> 
> There has been some recent work on this part of the problem, I
> focussed on throwing away binaries for all sourceful uploads and ivodd
> focussed on doing that for NEW uploads only. Since ivodd's patch is
> further along than mine, I hope he will extend it to all sourceful
> uploads.

You'll make it unnecessarily harder to bootstrap environments that need
themselves to build if you do that.

Throwing it away for NEW makes sense, but not for regular uploads, IMO.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 02, 2020 at 10:04:28AM -0800, Russ Allbery wrote:
> Matthias Klumpp  writes:
> 
> > I find that statement quite encouraging. Of course they don't commit
> > to not having those depend on systemd-as-PID1, but there really isn't
> > a reason to create that dependency, and if for whatever reason there
> > will be one at some point, we can switch away on systems that don't
> > support that change rather easily.
> 
> I specifically asked that question in a follow-up to that message and
> Zbyszek said that this is very likely to continue to work indefinitely.

Hi,

we talked this over in systemd upstream, and decided to make the
promise a bit more official [0]. Independent operation of a bunch of
programs is now explicitly covered, and the stability promise
has been extended to more interfaces. The old wiki page with the
stability/portability charts [1,2] is now replaced by an in-repo
page [3], which is the new official location for this data [4].

[0] 
https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs
[1] 
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
[2] https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
[3] https://systemd.io/PORTABILITY_AND_STABILITY/

Zbyszek

Bug#948776: ITP: ocaml-astring -- alternative String module for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ocaml-astring
  Version : 0.8.3
  Upstream Author : Daniel Bünzli
* URL : http://erratique.ch/software/astring
* License : ISC
  Programming Lang: OCaml
  Description : alternative String module for OCaml

Astring exposes an alternative String module for OCaml. This module
tries to balance minimality and expressiveness for basic, index-free,
string processing and provides types and functions for substrings,
string sets and string maps.

Remaining compatible with the OCaml String module is a non-goal. The
String module exposed by Astring has exception safe functions, removes
deprecated and rarely used functions, alters some signatures and
names, adds a few missing functions and fully exploits OCaml's
newfound string immutability.

This is a new (indirect) dependency of ocaml-ipaddr. It will be
maintained in the OCaml team.