Debian Buster release to partially drop non-systemd support

[Holger Levsen]

On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
> > Has policy changed regarding support for multiple inits, or is it just that
> > no one is maintaining the shim and sysvinit-core?
> 
> The latter.  systemd-shim has been orphaned for over 2 years, and has
> RC bugs.   sysvinit currently has two maintainers, but they've only
> ever made one upload (over a year ago).

It seems that these facts are either largely ignored or unknown and I
wonder if some noise should be made so that interested people can pick
up the work now and not only complain later.



Please reply to debian-devel@lists.d.o if you have to, but probably
replying to those RC bugs is more effective. Also please avoid cc:ing me.


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Re: A problem with a watch file

[Tommi Höynälänmaa]

Hi


On 12.10.2018 04:40, Sergio Durigan Junior wrote:

Complementing what Jonas said, you have a few more errors:
1) The "theme-d-gnome*" packages are not listed in
.  Instead, they're at
.

URL www.iki.fi/tohoyn is a link to www.tohoyn.fi.

2) Upstream uses "_" as the "NAME_VERSION" separator (instead of
"NAME-VERSION").  Your regex doesn't match that.  Also, you have to be
careful because upstream provides both "NAME_VERSION.tar.gz" and
"NAME_VERSION.orig.tar.gz".

The filename is theme-d-gnome-0.7.0.tar.gz. I checked it in the server.



3) Upstream doesn't seem to offer GPG signatures for the tarballs, so
you don't need "pgpsigurlmangle".

I have uploaded theme-d-gnome-0.7.0.tar.gz.sig into the server.


Having said all that, and using uscan v4's substitution strings:

   version=4
   http://www.tohoyn.fi/theme-d/theme-d-gnome.html 
theme-d-gnome_(\d[\d.]*)@ARCHIVE_EXT@

Thanks,


I tried the following:
---cut-here---
version=4
opts="pgpsigurlmangle=s/$/.sig/" 
http://www.tohoyn.fi/theme-d/theme-d-gnome.html 
theme-d-gnome-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)

---cut-here---

Now uscan doesn't complain anything but nothing gets downloaded.

Thanks for help,

 Tommi Höynälänmaa

Re: A problem with a watch file

[Adam D. Barratt]

On Sat, 2018-10-13 at 15:23 +0300, Tommi Höynälänmaa wrote:
> Hi
> 
> 
> On 12.10.2018 04:40, Sergio Durigan Junior wrote:
> > 2) Upstream uses "_" as the "NAME_VERSION" separator (instead of
> > "NAME-VERSION").  Your regex doesn't match that.  Also, you have to
> > be
> > careful because upstream provides both "NAME_VERSION.tar.gz" and
> > "NAME_VERSION.orig.tar.gz".
> 
> The filename is theme-d-gnome-0.7.0.tar.gz. I checked it in the
> server.

That file apparently does exist on the server. However, it is not
linked from anywhere on http://www.tohoyn.fi/theme-d/ or http://www.toh
oyn.fi/theme-d/theme-d-gnome.html , so uscan can't be expected to
simply imagine that it might exist.

Regards,

Adam

Re: A problem with a watch file

[Joël Krähemann]

Hi,
Might be you should rename the signature having .asc suffix instead of .sig

Bye,
Joël

On Sat, Oct 13, 2018 at 2:33 PM Adam D. Barratt
 wrote:
>
> On Sat, 2018-10-13 at 15:23 +0300, Tommi Höynälänmaa wrote:
> > Hi
> >
> >
> > On 12.10.2018 04:40, Sergio Durigan Junior wrote:
> > > 2) Upstream uses "_" as the "NAME_VERSION" separator (instead of
> > > "NAME-VERSION").  Your regex doesn't match that.  Also, you have to
> > > be
> > > careful because upstream provides both "NAME_VERSION.tar.gz" and
> > > "NAME_VERSION.orig.tar.gz".
> >
> > The filename is theme-d-gnome-0.7.0.tar.gz. I checked it in the
> > server.
>
> That file apparently does exist on the server. However, it is not
> linked from anywhere on http://www.tohoyn.fi/theme-d/ or http://www.toh
> oyn.fi/theme-d/theme-d-gnome.html , so uscan can't be expected to
> simply imagine that it might exist.
>
> Regards,
>
> Adam
>

Bug#910936: ITP: praelector -- helps one to read a latin phrase in a "natural" way

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: praelector
  Version : 0.1
  Upstream Author : Yves Ouvrard 
* URL : https://github.com/ycollatin/Praelector
* License : GPL-3+
  Programming Lang: C++
  Description : helps one to read a latin phrase in a "natural" way

 William G. Hale (1849-1928) explained in "The Art Of Reading Latin"
 principles of such a "natural" way of reading latin sentences, which is
 radically different of the way of reading our modern languages.

 - this package enriches Debian with a tool to study latin language
   it is a good fellow for the packages collatinus and felix-latin already
   available in Debian.

 - I shall maitain it on the behalf of my friend Yves Ouvrard, the packaging
   work is in salsa.debian.org

Re: Limiting the size of installed changelogs

[Ben Hutchings]

On Thu, 2018-09-13 at 09:06 -0400, Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 8:53 AM Boyuan Yang  wrote:
> > If Debian wants to limit changelog size as well, it may be better if we keep
> > similar / identical behaviour / implementation as Ubuntu.
> 
> More specifically, Ubuntu packages keep changelog entries for 10
> Debian/Ubuntu package versions.
> 
> At the bottom of the changelog, there is a comment like:
> 
> # For older changelog entries, run 'apt-get changelog libnautilus-extension1a'
> 
> apt-get changelog works on Debian systems too; it requires Internet
> access to fetch the complete changelog.

It worked on 0 out of the 2 systems I tried it on.

One is running jessie (in LTS), so none of the changelogs for security
updates are available.  (This problem doesn't occur for stretch because
security updates get copied into proposed-updates.)

The other is running unstable, and the package I tried was slightly
older than the version in the archive.

I think we would need to fix these back-end problems before relying on
apt-get changelog.

Ben.

> The changelog stripping is done by pkgstripfiles, a bash script in the
> pkgbinarymanagler package. That package is not available in Debian.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken




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

Re: Limiting the size of installed changelogs

[Ben Hutchings]

On Thu, 2018-09-13 at 11:22 +0100, Ben Hutchings wrote:
[...]
> - A large part of the changelog is listing the changes in upstream
> stable updates.  These are mostly important changes, and we already try
> to leave out those that are clearly irrelevant to Debian.  Should we
> continue to include these, or limit to those that address CVEs or
> Debian bug reports?

There was one comment in favour of keeping these lists, and none for
excluding them.  I intend to continue including them.

> - Would it make sense to split the changelog, leaving older entries
> only in the source package?  If so, should this be done manually, or
> would it make sense to have dh_installchangelogs split at some age or
> size limit?

There seemed to be consensus that this would be reasonable, but
differing opinions about how to do it.

Several people mentioned Ubuntu's automatically truncated changelogs. 
These would require packaging a new tool and improving the handling of
source changelogs on metadata.ftp-master.debian.org.  I don't have time
to work on this but someone else could.

I've committed a manual change in the linux source package, moving all
entries up to the stretch branch-point into changelog.old.  This will
mean that in a buster installation the changelog will include all
changes since stretch.

> - Does it make sense to compress changelogs with xz?  For src:linux,
> this achieves about a 20-25% reduction over gzip.

There was some support for this, but differing results for compression.
It wasn't clear that the gain would be worth it.  I don't have time to
work on investigating this or proposing a policy change, but someone
else could.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken




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

Bug#910951: ITP: python-trustme -- fake certificate authority for test use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-trustme
  Version : 0.4.0
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/trustme
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : fake certificate authority for test use

 trustme is a tiny Python package that gives you a fake certificate authority
 (CA) that you can use to generate fake TLS certificates to use in tests. Its
 only useful purpose is as a dependency of test suites.

This is a (test) dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910956: ITP: python-sniffio -- detect which async Python library is in use

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-sniffio
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/sniffio
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : detect which async Python library is in use

 Python libraries that support multiple async packages (like Trio, asyncio,
 etc) need to know which is in use. This library provides this information.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Bug#910960: ITP: python-outcome -- capture the outcome of Python function calls

[Robie Basak]

Package: wnpp
Severity: wishlist
Owner: Robie Basak 

* Package name: python-outcome
  Version : 1.0.0-1
  Upstream Author : Nathaniel J. Smith 
* URL : https://github.com/python-trio/outcome
* License : Apache-2.0 or Expat
  Programming Lang: Python
  Description : capture the outcome of Python function calls

 Outcome provides a function `capture' for capturing the outcome of a Python
 function call, so that it can be passed around - even if the function raises
 an exception. It also provides the async equivalent function `acapture'.

This is a dependency of trio, ITP bug #900296

I intend to join the DPMT and then maintain it there, but as I'm not a
member right now, I will take things a step at a time and get it into
unstable first.


signature.asc
Description: PGP signature

Re: Re-evaluating architecture inclusion in unstable/experimental

[Jonathan Dowland]

On Fri, Oct 12, 2018 at 11:13:30PM +, Thorsten Glaser wrote:

As a (lapsed) porter for x32 here in Debian, I don't think it's worth
keeping.  Despite all the touted benefits, no one uses the arch.  There's a


That’s wrong. I’ve crossgraded my desktop at work to x32, with
M-A to i386 for a continuously smaller-becoming number of things.


Strictly it's wrong, but he likely meant "nearly no-one".


Thus: I propose to drop x32, and reallocate your tuits to other archs.


That would inconvenience me quite a bit, *and* tell me that all
the effort I invested, all the time spent hacking, debugging,
learning and teaching, is worth nothing.


The same is true for any dropped port, but beware of the sunk cost
fallacy.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.