Bug#996762: ITP: precious -- one code quality tool to rule them all

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: precious
  Version : 0.1.2
  Upstream Author : Dave Rolsky 
* URL : https://github.com/houseabsolute/precious
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : one code quality tool to rule them all

 Precious is a command-line tool to unify
 the execution of source code tidiers and validators.
 .
 With Precious you can configure
 all of your code quality tool rules in one place
 and easily run `precious` from your commit hooks and in CI.
 .
 Several tidier+validator unifiers/orchestraters exists,
 including perl-based TidyAll (the predecessor of Precious),
 Python-based pre-commit,
 Go-based lefthook,
 NodeJS-based husky and lint-staged,
 and Ruby-based overcommit.
 For comparison, Precious is Rust-based with these notable features:
  * handles directory-wide and project-wide tasks
(unlike TidyAll)
  * stores task settings locally
(unlike pre-commit)
  * cannot cache tasks
(unlike TidyAll)
  * supports incremental linting
(unlike lefthook, husky, lint-staged or overcommit)
 .
 For a more detailed comparison,
 see .

This package will be team-maintained at
.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFtWkwACgkQLHwxRsGg
ASHbCA//VMT0aT/F59ZVhI7hisfOWwWJlqcwGCPsEDH+Kg25IG4CWh5kKwAw98/A
9Wm0iPThzPZ9yn4XoIqpcZ+15QR9CsbNb3STGWd/LGuaWRA79BRNjRUx6hm7u+dY
aQqMLOqMyLF0jShIu3KiNsyhEcBkzk17zms/lGFi1j5IyKVqv/pcUi0zq61n1rHl
hjHN/4qLXOeAVeSBgSShulWKDo+hr9mM94Op/bE4xmc8agNWFTqlhFkOcdneIq+b
+atTe2uE7ZpCtQjkzPYCQPFZThncIsFX7OPcTdoXuuXq3ZFG7rdxg2+mNqpEPLlj
UOMOas8wmqBQyccndyCbvl0i1RaaqH6xqfzTIq788Ah5DKGDshIJyriQ/vQG8ynj
Qww4T0u4KQ0EHbSvD/k+Cg+S74reO2L1yE6qH1b6BFt60+5X7CU/iHXU2wDc4C1F
zXtl45aHias6YnkvwiEZ2fFB9Z2CGBbi7Gq43RXqSmByqZUmhqtRtxEN6u37Hmbv
YdDBs+S3BXLH8K1QouRhh9YQ7/eyG0ac+H8L8XyvpMJbiOhrfViXfMhPDOYObsSv
xu75F4HTAMX5h9rKX/VHR9CnTgc1WCvL2EXtKJEEuQc5zoWVbqpqz//PBrYWAV1L
epHmeGN10ImAXzitjlBu/onl0ZpmSdGlViHyd41jfoMmQO4FO8w=
=L8uv
-END PGP SIGNATURE-

Bug#996768: ITP: fs-uae-arcade -- Fullscreen game browser for FS-UAE

[John Paul Adrian Glaubitz]

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

* Package name: fs-uae-arcade
  Version : 3.0.5
  Upstream Author : Frode Solheim 
* URL : https://fs-uae.net/
* License : GPL-2+
  Programming Lang: Python
  Description : Fullscreen game browser for FS-UAE

FS-UAE is a cross-platform Amiga emulator based on updated emulation code
from WinUAE. FS-UAE uses SDL for input, OpenAL for audio and OpenGL
for graphics.
.
This package contains the launcher, a graphical user interface for
setting up FS-UAE.

This package used to be part of the fs-uae source package but has been split
into a separate package by upstream. The Debian package was split for version
3.1.35 which is why fs-uae-arcade is now being submitted as a new source
package.

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996769: ITP: fs-uae-launcher -- Launcher and configuration program for FS-UAE

[John Paul Adrian Glaubitz]

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

* Package name: fs-uae-launcher
  Version : 3.0.5
  Upstream Author : Frode Solheim 
* URL : https://fs-uae.net/
* License : GPL-2+
  Programming Lang: Python
  Description : Launcher and configuration program for FS-UAE

FS-UAE is a cross-platform Amiga emulator based on updated emulation code
from WinUAE. FS-UAE uses SDL for input, OpenAL for audio and OpenGL
for graphics.
.
This package contains the launcher, a graphical user interface for
setting up FS-UAE.

This package used to be part of the fs-uae source package but has been split
into a separate package by upstream. The Debian package was split for version
3.1.35 which is why fs-uae-launcher is now being submitted as a new source
package.

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Debian's branches and release model

[Peter Hoist]

Hi,

I am enjoying Debian's testing branch as a reasonably stable and up-to-date
'rolling' release, and I have to say it satisfies all my desires, almost.
The one thing that bothers me is that every two years, the unstable/testing
branches are frozen to certain extent because of the stable releases. This
means the testing branch can be quite lagged behind upstream releases. One
example is gcc, with gcc-11 released almost 6 months ago, and it is still
not default in debian testing - I know it is being worked on right now and
probably only a couple days away, but still...

So the question is, why not cut a release branch every two years, and at
the same time keep the unstable/testing alive? Is it because debian
developers think it's too much work to reconcile the differences later, so
they prefer freezing?

Some ppl recommend arch for this reason, but I am already familiar with
apt's way of things, and would hold off switching before I have a better
understanding of the bigger picture.

I am certainly not qualified to make recommendations here, just wondering
what is the reason behind it and if there is some proposal to make testing
a better/closer 'rolling' release that ppl like me can enjoy better:)

cheers,

P

Re: Debian's branches and release model

[Simon McVittie]

On Mon, 18 Oct 2021 at 12:29:55 -0400, Peter Hoist wrote:
> So the question is, why not cut a release branch every two years, and at the
> same time keep the unstable/testing alive?

We have this conversation about once a year. Essentially, the freeze makes
sure that the versions we are proposing to put in the next stable get as
much testing from our developers and prerelease users as possible. It
also aligns the incentives for enough people to make sure that we can
successfully make a release in a finite time - even developers who
don't really care about releases and just want the latest versions
are incentivized to fix enough things to make the next release happen,
so that the freeze will end and they can get back to uploading the latest
versions to unstable.

The purpose of the testing distribution is exactly that it is what will
be the next stable, so by definition it is not possible to freeze the
next stable without freezing testing. We could invent a new suite, for
which the name "rolling" has been proposed in the past, and keep updating
unstable and "rolling", while continuing to freeze "testing".

However, the problem with freezing testing but not freezing unstable is
that if you do that, all updates to testing during the freeze (to fix the
release-critical bugs that stop it from already being ready for release)
have to go into testing via testing-proposed-updates, which approximately
nobody uses.

Having code changes for our next stable release be essentially untested
is not great from a QA perspective - if nobody is trying out those new
versions except for their maintainer, then nobody can find and report the
(potentially serious) bugs that only happen in system configurations that
differ from the maintainer's system. That's why the release team strongly
discourages packages going into testing via testing-proposed-updates, and
encourages packages going into testing via unstable.

Before the "testing" suite was invented in 2000, we *did* freeze the "next
release" branch without freezing unstable - you can see this in very
old packages' changelogs, with packages that were uploaded to "frozen",
or to both "frozen" and "unstable". Information about that from around the
time "testing" was implemented:
https://lists.debian.org/debian-devel/2000/08/msg00906.html

smcv

tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Sean Whitton]

Hello,

On Wed 15 Sep 2021 at 11:46AM +01, Simon McVittie wrote:

> As discussed in our last meeting, I think we should issue more specific
> advice about merged-/usr, and in particular about what #978636 means for
> maintainers right now.

With five votes cast in favour of the text by Simon, Niko, Gunnar, Marga
and myself, the outcome is no longer in doubt.  Thus, in accordance with
the Debian Constitution, the voting period has now concluded.

Therefore, using its powers under section 6.1.5 of the Debian
Constitution, the Technical Committee issues the following advice:

Summary
===

There are currently Debian 11 installations with both the merged-/usr
and non-merged-/usr filesystem layouts. All of these installations
should successfully upgrade via normal upgrade paths to a merged-/usr
Debian 12.  Only after the release of Debian 12 can packages assume that
all installations will be merged-/usr.

Main points:

- We have recommended merged-/usr for Debian 12.
- Moving individual files is not merged-/usr.
- "Symlink farms" are not merged-/usr.
- Upgrading a non-merged-/usr system to Debian 12 needs to work.
- Upgrading a merged-/usr system to Debian 12 needs to work.
- Packages cannot assume all systems are merged-/usr until the Debian 13
  development cycle begins.
- Upgrading via apt in the usual way should work.
- Testing and QA systems should be able to avoid this transition, but if
  they do, they cannot be upgraded beyond Debian 12.
- A package building incorrectly on a non-merged-/usr system is a bug.
- A package building incorrectly on a merged-/usr system is a bug.
- Please stop moving individual packages' files from the root filesystem
  into /usr, at least for now.

Definitions and current status
==

libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
such as lib64 on the amd64 architecture.

Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
/libQUAL that exists are symbolic links to the corresponding directories
below /usr. This results in aliasing between /bin and /usr/bin, and so
on.

In the merged-/usr layout, files whose canonical logical location is in
one of the affected directories on the root filesystem, such as
/bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
the corresponding path below /usr, such as /usr/bin/bash. Each file in
one of the affected directories is accessible via two paths: its
canonical logical location (such as /bin/bash or /usr/bin/env), and the
other path implied by the aliasing (such as /usr/bin/bash or /bin/env).

There are two supported categories of Debian 11 installation, which are
currently considered equally-supported:

- Merged-/usr installations. These were installed with debian-installer
  from Debian 10 or later, or installed with debootstrap --merged-usr,
  or converted from the non-merged-/usr layout by installing the
  usrmerge package, or installed or converted by any similar
  procedure. They have the merged-/usr layout.

- Non-merged-/usr installations. These were installed with
  debian-installer from Debian 9 or earlier and subsequently upgraded
  without converting to merged-/usr, or installed with debootstrap
  --no-merged-usr, or converted from the merged-/usr layout with dpkg's
  "dpkg-fsys-usrunmess" utility or any similar procedure. They have the
  traditional, non-merged-/usr layout in which /bin/bash and
  /usr/bin/env have exactly those physical paths, and /usr/bin/bash and
  /bin/env do not exist.

Merged-/usr is not the only filesystem layout that has been proposed for
unifying the root filesystem with /usr. For avoidance of doubt, we do
not consider other filesystem layouts to be implementations of
merged-/usr.  In particular, we do not consider these to be
implementations of merged-/usr:

- all affected files physically located in /bin, /sbin, /lib and
  /libQUAL, with /usr/bin as a symlink to /bin, etc. (this is the
  reverse of merged-/usr, and was historically used in the hurd-i386
  port)

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with
  individual symbolic links such as /bin/bash -> /usr/bin/bash for only
  those files that historically had their canonical logical location on
  the root filesystem

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with
  individual symbolic links such as /bin/env -> /usr/bin/env for all
  files in the affected directories, regardless of whether they
  historically had their canonical logical location on the root
  filesystem

[1]: 
https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential

Upgrade path from Debian 11 to Debian 12


The technical committee resolved in #978636 [2] that Debian 12
'bookworm' should only support the merged-/usr layout. This resolution
describes the implications of that decision in more detail.

Debian installations have traditionally had a straightforward upgrade
path 

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Marco d'Itri]

On Oct 18, Sean Whitton  wrote:

Thank you: this is great work and, even if it requires maintaining 
support for unmerged systems for yet another release, I fully agree with 
the results.

> - Debian contributors who are interested in merged-/usr are invited to
>   implement a straightforward migration path from non-merged-/usr to
>   merged-/usr. The Technical Committee will not design this migration
>   path in detail. If disputes arise related to this migration path, or
>   if advice on this migration path is requested, we will resolve those
>   by following our usual procedures.
> 
> + One example of a migration path that might be used is for an
>   Essential package to add a dependency on the usrmerge package, so
>   that it will be installed automatically during upgrades. We do not
>   require this to be the migration path that is chosen; it is
>   presented here merely to demonstrate that such a migration path
>   can exist.
This looks like a good plan. I am not sure that alternative ones 
which fit the other requirements have ever been proposed, but I would 
still like to hear about them if anybody has better ideas.

This is a rough sketch of a possible solution:

Package: foo
Essential: yes
Depends: usrmerge | usr-is-merged

Source: usrmerge
Package: usrmerge
Provides: usr-is-merged

Source: usrmerge
Package: usr-is-merged
Description: this is an empty transitional package
 It can be removed as soon as no other package depends on it.
 .
 It fails in preinst if /{bin,sbin,lib*} are not a symlink.
 .
 It is useful to satisfy the dependency without bloating already
 converted systems.

An open question: how do we make debootstrap and its clones install 
usr-is-merged instead of usrmerge?

So, who is willing to be the maintainer of "foo"?
There are not too many candidates:

grep-available -s Package -F Essential yes | uniq | less

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Question about source tarballs for packaging

[Paul Wise]

On Sun, 2021-10-10 at 21:40 +, Joshua Peisach wrote:

> I'm packaging the V programming language for Debian. However, V is  bit
> weird at the moment. It's not really ready for stable production/use.
> so for a while it will live in experimental. Currently the way building
> it works is that there is a repo that is the compiler translated to C
> automatically that you have to clone and compile to build V, and then
> all the actual libraries and everything to make V work. The cloning is
> done through git via Makefile.

That is not a proper bootstrap process ala Bootstrappable Builds.

https://bootstrappable.org/

Is the code that generates the C code possible to run without V built
yet? If so I suggest that you run that code from the Debian package
build. If not, personally I would not add V to Debian yet.

> What is the proper way to get the source?

Jonas' suggestion of using uscan to get tarballs of the git branch
seems reasonable.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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