Opportunités de rejoindre Freexian et contribuer à Debian

[Raphael Hertzog]

Bonjour,

je voulais attirer votre attention sur l'annonce que l'on vient de poster
sur debian-jobs:
https://lists.debian.org/debian-jobs/2024/03/msg2.html

Freexian s'est pas mal développé ses dernières années et pour accompagner
notre croissance nous avons besoin d'aide sur des domaines plus administratifs
que techniques (ventes, marketing, gestion de projets/équipes, etc.).

Toutefois pour rester fidèle à nos valeurs, nous cherchons des
contributeurs Debian avec ces compétences, ou du moins des aficionados de
Debian qui sont prêts à devenir contributeurs puis membres du projet (sinon
que faire des 20% du temps de travail offerts pour contribuer à Debian?).

N'hésitez pas à partager ce message si vous pensez connaître quelqu'un
qui pourrait correspondre à un des profils recherchés.

Merci d'avance et bon week-end de Pâques!

PS: Les infos sont aussi sur le site Freexian:
https://www.freexian.com/about/join-us/
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Issues in the Patch Tagging Guidelines

[Raphael Hertzog]

Hi,

On Tue, 08 Aug 2023, Guillem Jover wrote:
> Lately I've been updating metadata in patches in packages I maintain and
> noticed several issues with the Patch Tagging Guidelines, and after Lucas
> created the new great patches UDD service [P] and we discussed some
> other issues there, it looked like the guidelines could do with some
> fixes and updates.

I agree that the DEP could benefit from a refresh. However I will not
have the time to coordinate this work, sorry.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Raphael Hertzog]

On Fri, 09 Jun 2023, Marco d'Itri wrote:
> On Jun 08, Raphael Hertzog  wrote:
> 
> > In the same spirit, I'd like to throw an idea... could we decide that
> > base-files is the first package to be configured as part of the bootstrap
> > protocol and change base-files maintainer's scripts into statically linked
> > executables so that they can work even if we don't have the library loader
> > on the ABI-compliant path?
> It could be even easier: base-files could be unpacked once without 
> running the maintainer scripts and then "reinstalled" again later as 
> usual.

I think you are missing the point here, that only works if the package is
shipping the symlinks. And the idea is to not do this immediately because
it breaks debootstrap: if I understood correctly unpacking base-files
with the symlinks would fail if debootstrap had already pre-created those
symlinks (due to a -k option that we should get rid of in
/usr/share/debootstrap/scripts/debian-common).

Hence the special maintainer script to create the required symlinks
without relying on /bin/sh or any dynamically linked executable.

> > And creating the required symlinks would be done by those (standalone)
> > maintainer scripts...
> > 
> > I don't know if we already have some rule/invariant in the configuration
> > order of the unpacked packages, but I doubt so.
>
> Indeed, this would be very simple and it has already been proposed.
> But somebody then complained that special-casing a package would violate 
> the design contraints he self-imposed to his own image building tool, 
> and as we all know every Debian maintainer can veto any systemic changes 
> that they do not like.

That's not very helpful. Nobody has vetoed anything here. But I agree that
it would be cleaner if we could reach a situation where we can just unpack
all packages and have a working system where we can just "dpkg --configure
-a" and be done.

You don't care about this goal, it's fine, but it's not a reason to paint
this as a black/white picture. We can have both, we just need an
intermediate step.

I understand some would rather just be done with this transition (so am
I...), but going the extra mile here doesn't seem unreasonable. 

---

Coming back to my initial suggestion, I realize however that while the
maintainer script can run, dpkg itself will not run in the chroot so if
debootstrap is relying on dpkg to do the initial base-files configuration,
this will not work.

So this looks like that we will have to continue to rely on debootstrap
to create the symlinks and we will have to fix it so that it can properly
unpack a base-files containing /bin and /lib as symlinks on top of
existing symlinks.

And the actual switch to include /bin and /lib symlinks in base-files can
be done once we have fixed debootstrap in all relevant releases. And after
we can stop pre-creating those symlinks in debootstrap for all future
releases.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Raphael Hertzog]

Hi,

On Wed, 17 May 2023, Helmut Grohne wrote:
> For completeness sake, there is one more entry in category 3: We can run
> the dynamic loader from its canonical location explicitly, so we'd
> modify maintainer scripts to start with:
> 
> #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/sh
> 
> This would only affect preinst scripts participating in bootstrap and
> we'd not bother with changing PT_INTERP in the toolchain nor in
> packages. Unfortunately, this completely breaks the DPKG_ROOT work and
> with that, I see no viable entries in category 3 for moving forward.
> 
> Moving on to category 4 feels rather obvious, especially because work
> has been done there in debootstrap. The approach in debootstrap however
> is one that I see as a dead end, because it causes us to maintain this
> code multiple times. It's the number of derivatives times the number of
> bootstrap tools and that doesn't scale.
> 
> Category 4 is wider though and we also have other prior art at
> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. In particular,
> making architecture bootstrap become chrootless would likely be a
> generic solution to this and other problems.  However, any change needs
> to propagate to a stable release in all bootstrapping tools.  Therefore
> we cannot reasonably finish the transition before forky.  This makes
> category 4 rather unattractive in a short term, but still worth pursuing
> in a long term.

In the same spirit, I'd like to throw an idea... could we decide that
base-files is the first package to be configured as part of the bootstrap
protocol and change base-files maintainer's scripts into statically linked
executables so that they can work even if we don't have the library loader
on the ABI-compliant path?

And creating the required symlinks would be done by those (standalone)
maintainer scripts...

I don't know if we already have some rule/invariant in the configuration
order of the unpacked packages, but I doubt so.

> Having ruled out categories 3 and 4 maybe category 2 would be good?  We
> could just ship those symlinks in base-files and be done, right?
> Unfortunately, we pass -k to tar in debootstrap, so when it extracts
> base-files and tries to unpack the bin -> usr/bin symlink, it sees that
> oh no, there already is a symlink at bin (as debootstrap placed it
> there) and thus fails. So in order to make this work, we also have to
> modify debootstrap (and thus are in a combination of category 3 and 4).

So when we will have fixed this, and waited for a release cycle, we can
get rid of the statically compiled maintainer scripts and simply ship the
symlinks in base-files.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

Hello,

On Tue, 02 May 2023, Helmut Grohne wrote:
> I think there is a caveat (whose severity I am unsure about): In order
> to rely on this (and on DEP 17), we will likely have versioned
> Pre-Depends on dpkg. Can we reasonably rule out the case where and old
> dpkg is running, unpacking a fixed dpkg, configuring the fixed dpkg and
> then unpacking an affected package still running the unfixed dpkg
> process?

I don't know APT well enough to answer that question but from my point of
view it's perfectly acceptable to document in the release notes that you
need to upgrade dpkg first.

> I think the file loss problem is one sufficient reason to have the
> moratorium. We didn't need other reasons once we knew this one. Now that
> we look into dropping the moratorium, we need to ensure that there are
> no reasons anymore and we learned that diversions are affected in a
> non-trivial way. So even if we were to fix just the file loss problem,
> the diversion problems would still be sufficient reason to keep the
> moratorium unless they were also fixed by the approach. Here you need
> both directions a) diverting a non-canonical location would have to
> divert a canonical file and b) diverting a canonical location would have
> to divert a non-canonical file. This is breaking the initial assumption.

Are you sure that we need anything for diversions except some documented
policy on how to deal with it?

AFAIK the following sequence performs no filesystem changes and should
be sufficient to move a diversion to its new location (I only consider the
case of an upgrade, not of a new installation that should just work
"normally" on the new location):

dpkg-divert --package $package --remove /bin/foo --no-rename
dpkg-divert --package $package --add /usr/bin/foo --divert 
/usr/bin/foo.diverted --no-rename

The case of update-alternatives is likely more tricky. You already looked
into it. That's a place where it will be harder to get things right
without some changes.

> In any case, this train of thought is definitely widening the solution
> space. Thank you very much.

You are welcome.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

Hello,

On Wed, 26 Apr 2023, Simon Richter wrote:
> > This and /bin/sh is the kind of files I'd consider important. And then
> > upon thinking further it became more and more difficult for me to make
> > sense of the objection. On a merged system, we can just move that file
> > to its canonical location without having any trouble even with an
> > unmodified dpkg. So from my pov, the question about important files can
> > be disregarded. I hope Simon Richter agrees.
> 
> Yes, the relevant code at
> 
> https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749
> 
> already handles moving a file inside the same package, and that has
> existed for some time, that's why I use two packages for the PoC.

Hum... why aren't we improving this part of the code?

We don't want to stat all the files in all packages but we could do better:
if we are about to remove an old file that is available through a
symlinked directory, we could check the new name of the file and see if
it's available in some package... and if yes just forget the file without
removing it.

This file removal is the reason of the moratorium and incuring some extra
cost in some specific cases (installation through directory symlinks which
is not the default case, and would not affect us after the migration is
complete) seems certainly fair.

The cost of analyzing directory components is a cost that we will have on
all dpkg invocations but it doesn't seem unreasonable to me. We could also
restrict it to the top-level directories to make it negligible as this
is the only transition that we care about here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

On Tue, 25 Apr 2023, Luca Boccassi wrote:
> Brilliant! Would never have thought of using divert like that.

+1 Nice trick.

> So, what work would need to happen to make this reality? Do we need
> tooling/scripts/build changes to support the divert scheme, or is it
> "simply" a matter of documenting and testing?

I would suggest to implement it with "dpkg-maintscript-helper" and
document what needs to be documented as part of the associated manual
page documentation.

After all it's a hack to work around a dpkg limitation and it fits
well with the purpose of that helper tool.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

Hello,

On Sat, 22 Apr 2023, Helmut Grohne wrote:
> This is looking at it from a performance point of view. Guillem also
> raised that this is changing the source of truth from the dpkg database
> to the actual filesystem, which Guillem considers wrong and I find that
> vaguely agreeable.

smcv already replied to that part.

> 
> > We don't add any new public interface to dpkg, but we also have the
> > possibility to remove to /var/lib/dpkg/aliases to force an new scan
> > (some sort of "dpkg --refresh-aliases" without an official name).
> 
> Can I rephrase this as your cache invalidation strategy is that any
> external entity (such as a maintainer script) introducing aliases should
> explicitly invalidate the cache.

Yes and no. Sticking to the idea that .deb should be the source of truth,
we make the assumptions that external entities should not do that and if
they do it, they use the already existing interfaces (either shipping
symlinks in a .deb or calling dpkg-maintscript-helper to convert a
directory in a symlink or the opposite, depending on the history of said
path).

> If you put it this way, it is not that different from the
> --add-alias/--remove-alias proposal. It is a different interface to
> dpkg, but the semantics are roughly the same:
> 
> In both cases, something external to dpkg is responsible for performing
> the moves and creating the symbolic links followed by informing dpkg
> about the alias (explicitly or implicitly via scanning directories).

I don't consider "dpkg-maintscript-helper" as external to dpkg. Quite
on the opposite, it's an ugly hack that is part of dpkg so that it can
evolve together with dpkg relying on internal implementation details that
nobody else can rely on.

> Would you agree with me that this is a minor adaption of DEP17? In

It is an adaptation of DEP17 that tries to not create a new public
interface for users. Whether that change is minor or not, I leave that
up to Guillem to decide. My hope is that the restricted scope makes
it acceptable to him.

> > The proposal I made above is not a real database in the sense that we
> > don't record what was shipped by the .deb when we installed the files...
> > it's rather the opposite, it analyzes the system to detect possible
> > conflicts with dpkg's view of the system.
> 
> I think that Guillem considers this a bad property as he has expressed
> in his reply on debian-dpkg, that .debs should be the source of truth.

I understood this but at the same time dpkg has supported an exception
already, this is only about improving how we detect issues related
to that supported exception.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

Hello,

I'd like to offer some food for thoughts on this issue.

>From what I have understood, Guillem would rather avoid committing
to a new public interface for this specific use-case, i.e. the
fact that the DEP is suggesting "dpkg --add-alias" is problematic
because that feature will be useless when we will have moved
to .deb shipping files in /usr only.

However the problem of file loss through aliased directories is a broader
problem, it is not specific to this transition. It's quite possible that a
package is shipping a symlink pointing to a directory and to have other
packages installing files through that symlink (and then move those files
between binary packages and between their two possible locations).

Let's try to tackle that problem in a generic way without requiring
any external information... it ought to be doable. You did consider
it partly already:

On Mon, 03 Apr 2023, Helmut Grohne wrote:
> Naive solution
> ==
> 
> In theory, `dpkg` could resolve this automatically.  For every file it
> touches, it could canonicalize the location using the actual filesystem
> and check whether any other installed file has the same canonicalized
> location.  Unfortunately, `dpkg` cannot know which filenames can
> collide, so it would check every filename in its database.  For
> canonicalization, it would `stat()` every component of every filename.
> This easily amounts to a million or more `stat()` calls on larger
> installations.  Caching could reduce the impact somewhat, but since
> Debian introduces aliases during maintainer scripts, it would have to
> invalidate the cache after maintainer scripts have been run.  The
> resulting performance would be unacceptable.

Here you are considering all files, but for the purpose of our issue,
we can restrict ourselves to the directories known by dpkg. We really
only care about directories that have been turned into symlinks (or
packaged symlinks that are pointing to directories). That's a a much lower
number of paths that we would have to check.

You are speaking of having some sort of cache and I certainly agree
that it would make sense to have such a cache.

We could decide that /var/lib/dpkg/aliases is that cache, it would
be the result of a scan of all directories known by dpkg (i.e. all
paths known by dpkg where files are installed through that path) and
it would list the target directory in case that path is a symlink.
The absence of a directory in that file would mean that, according to
dpkg, the directory ought to be a real directory.

Thus this time-consuming operation would be done once, the first
time that the updated dpkg starts and when /var/lib/dpkg/aliases
does not yet exist.

That cache file would be kept up-to-date by the various dpkg invocations:
- when you install a new .deb containing a symlink pointing to a
  directory, that new "aliased path" is added to this file
- when dpkg removes a symlink that is listed in the aliases file, we drop
  it too

We don't add any new public interface to dpkg, but we also have the
possibility to remove to /var/lib/dpkg/aliases to force an new scan
(some sort of "dpkg --refresh-aliases" without an official name).

It might still be cleaner to have that "dpkg --refresh-aliases" command
so that we can invoke it for example in "dpkg-maintscript-helper
symlink_to_dir/dir_to_symlink" when we are voluntarily turning a directory
into a symlink (or vice-versa).

In any case, now that you have a database of aliases, you can do the other
modifications to detect conflicting files and avoid file losses.

How does that sound?

> Implement aliasing after metadata tracking
> --
> 
> The [metadata
> tracking](https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking)
> feature enhances `dpkg` with knowledge about filesystem metadata for
> installed files.  This includes knowledge of symbolic links, which would
> help with tracking aliasing.  Unfortunately, progress on this is fairly
> slow and we think that aliasing support is more urgent.

The proposal I made above is not a real database in the sense that we
don't record what was shipped by the .deb when we installed the files...
it's rather the opposite, it analyzes the system to detect possible
conflicts with dpkg's view of the system.

It can be seen as complimentary to it. In any case, I don't see how
implementing metadata tracking would help to solve the problem that we
have today. dpkg would know that all .deb have /bin as a directory and
not as a symlink, and it would be able to conclude that the directory
has been replaced by a symlink by something external, but that's it.

It should still accept that replacement and do its best to work with it.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: DEP 17: Improve support for directory aliasing in dpkg

[Raphael Hertzog]

Hello,

On Mon, 03 Apr 2023, Helmut Grohne wrote:
> Please consider it to be a piece of best
> intentions at reconciling feedback wherever I could. At the time of this
> writing it certainly is not consensus, but consensus is what I seek
> here.  Without further ado, the full DEP text follows after my name
> while it also is available at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/5

I'd like to express some disappointment that nobody replied publicly
sofar. Last year's developer survey concluded that "Debian should complete
the merged-/usr transition" was the most important project for Debian [1]
(among those proposed in the survey). That's what we are trying to do
here and it would be nice to build some sort of consensus on what it means
in terms of changes for dpkg.

I know that Guillem (dpkg's maintainer) is generally opposed to the
approach that Debian has followed to implement merged-/usr but I have
yet to read his concerns on the changes proposed here (besides the fact
that they ought to not be needed because we should redo the transition
in another way, but that's a ship that has sailed a long time ago...).

The rough project consensus seems to be that we should modify dpkg to
avoid the cases where some files can disappear upon upgrades. Most people
don't really care how we modify dpkg for this, and I can't blame them, but
given that dpkg's maintainer seems unwilling to work on this problem,
someone else has to come up with a design, implement it and get it applied
on Debian's version of dpkg.

We are committed to work on the design and implementation but we want to
make sure the design is sound and agreed upon by the persons who are
technically knowledgeable on this issue and who have thought a lot on this
issue. There aren't that many persons in that set but it is also not empty.
So please read the DEP and share your feedback, even if it's just "I have
read it and it sounds fine", it will definitely help.

Thank you!

[1] page 28-32 of 
https://debian.pages.debian.net/dd-surveys/dd-survey-analysis-2022.pdf
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Rejoindre Freexian pour aider à améliorer Debian

[Raphael Hertzog]

Salut,

On Wed, 30 Mar 2022, Pierre-Elliott Bécue wrote:
> > [1] https://www.freexian.com/apropos/index.html#ambition
> > [2] https://www.freexian.com/apropos/index.html#mission
> > [3] https://www.freexian.com/apropos/join-us.html
> 
> Je pense que c'est cool de publier ce genre de choses ici, mais n'hésite
> pas aussi à voir côté frnog/frsag, non ?

Je ne sais pas à quoi tu fais référence (à vue de nez je dirai des
abréviations de newsgroup NNTP, mais je ne participe plus à cela depuis
bien longtemps) mais n'hésite pas à partager / relayer si tu penses
que c'est pertinent. Tu peux aussi simplement partager l'article
de blog:
https://raphaelhertzog.com/2022/03/29/join-freexian-to-help-improve-debian/

> > PS: En consultant les archives j'ai constaté que cette liste est quasi
> > inutilisée. Faut-il la supprimer ? Ou peut-on lui donner un second
> > souffle ?
> 
> Je pense que lui donner un second souffle ne serait pas de trop. On a
> des devs/contributeurs pour qui l'anglais n'est pas évident, et on est
> nombreux en tant que DDs à parler français.

Je ne suis pas sûr que la difficulté d'usage de l'anglais soit l'argument
principal en faveur de cette liste... mais peut-être a t'on des
développeurs dans cette situation.

Il me semble que cela peut aussi permettre aussi d'avoir des échanges dans
un contexte différent, avec un public plus homogène... les listes en anglais
ont parfois leur lot de "pénibles de service" ce qui fait que certains
désertent ces listes. Et la langue étrangère introduit une barrière de
plus qui augmente le risque d'incompréhension et donc de tensions.

Ca ne me déplairait pas que certains échanges commencent ici pour être
soumis sur les listes anglaises dans un second temps, après une première
passe d'amélioration/synthèse/débroussaillage.

A+
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Rejoindre Freexian pour aider à améliorer Debian

[Raphael Hertzog]

Bonjour,

je voulais vous informer que Freexian s'est fixé des objectifs
ambitieux[1] en soutien de Debian et que nous voulons étoffer l'équipe
pour atteindre ces objectifs. Nous avons rédigé un énoncé de mission[2]
pour clarifier notre raison d'être et nos valeurs, et nous espérons
attirer des développeurs, entrepreneurs et experts Debian talentueux au
sein de notre communauté.

Si Debian fait partie intégrante de votre vie, si améliorer Debian est
quelque chose que vous aimez faire, si vous avez les compétences et
l'expertise Debian pour correspondre à certains des rôles que l'on a
décrit sur notre page "Join us"[3], alors écrivez nous à
gera...@freexian.com afin que l'on étudie la possibilité de travailler
ensemble.

[1] https://www.freexian.com/apropos/index.html#ambition
[2] https://www.freexian.com/apropos/index.html#mission
[3] https://www.freexian.com/apropos/join-us.html

Cordialement,

PS: En consultant les archives j'ai constaté que cette liste est quasi
inutilisée. Faut-il la supprimer ? Ou peut-on lui donner un second
souffle ?

PPS: Cette information a aussi été publiée en anglais sur mon blog:
https://raphaelhertzog.com/2022/03/29/join-freexian-to-help-improve-debian/
Mais puisque Freexian est une société française, je voulais attirer
l'attention des contributeurs français avec ce message.
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com

Re: What are the most important projects that Debian ought to work on?

[Raphael Hertzog]

On Wed, 23 Feb 2022, Andreas Tille wrote:
> Am Tue, Feb 22, 2022 at 04:46:23PM +0100 schrieb Raphael Hertzog:
> > I have left out a few low-impact and really uncontroversial ideas (like
> > "port UDD to Python 3", we all agree on that, it's more a matter of
> > finding the right volunteer).
> 
> Since I added the idea I'd like to confirm that I agree that this is
> uncontroversal.  I understood the initial idea like a way to find the
> right volunteer for certain tasks. ;-)

I certainly hope that having useful widely-agreed tasks listed can help
to find volunteers.

But for the survey, I am more interested in big ideas that have been
floating around for a while and that nobody tackled. The idea is to try
to get a sense of which ideas have the most support and which projects
to prioritize when it comes to the use of the Freexian funding for
instance.

For your specific need, I would suggest to try to reach out to the Python
team and point out that there's useful Python development work to be done,
and if being funded for that work helps them to allocate the required
time, then they should submit a project proposal and request a grant via
https://salsa.debian.org/freexian-team/project-funding/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: What are the most important projects that Debian ought to work on?

[Raphael Hertzog]

Hello,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> As part of an upcoming survey that we are preparing, we plan to ask
> Debian developers to rank, by order of importance, the most popular
> ideas of improvements for Debian.

So I have finalized the question with all the choices. Given the large
number of choices, I opted to not require a ranking but to give a mark
between 0 to 10 to evaluate the importance of the idea:
https://salsa.debian.org/freexian-team/misc-drafts/-/commit/b0073480657fae493df905821ee01b4ca3547c7f

It looks like this:


For each of the ideas listed below, please rate its importance for Debian
from 1 (not important at all) to 10 (very important). If you are against
the idea, please rate it with 0 (unacceptable).

Ideas related to Debian's purpose:
* [Debian should track issues in user stories and not just 
packages](https://salsa.debian.org/debian/grow-your-ideas/-/issues/29)
* [Debian should provide high quality ansible roles (and/or salt formulas, 
etc.)](https://salsa.debian.org/debian/grow-your-ideas/-/issues/18)

Ideas related to packaging workflows:
* [Debian should allow to upload packages by pushing a signed git 
tag](https://salsa.debian.org/debian/grow-your-ideas/-/issues/9)
* [Debian should provide personal/extra package repositories for Debian 
developers/teams](https://salsa.debian.org/debian/grow-your-ideas/-/issues/6)
* [Debian should have a default standard packaging 
workflow](https://salsa.debian.org/debian/grow-your-ideas/-/issues/24)
* [Debian should rethink/clarify the objectives of the NEW queue 
review](https://salsa.debian.org/debian/grow-your-ideas/-/issues/11)
* [Debian should create a unified workflow for package review and use it 
everywhere 
applicable](https://salsa.debian.org/debian/grow-your-ideas/-/issues/19)
* [Debian should migrate packages without any VCS into 
salsa](https://salsa.debian.org/debian/grow-your-ideas/-/issues/10)
* [Debian should provide a better infrastructure to manage 
transitions](https://salsa.debian.org/debian/grow-your-ideas/-/issues/21)

Ideas of other organizational changes:
* [Debian should build a packaging team to maintain vital system 
components](https://salsa.debian.org/debian/grow-your-ideas/-/issues/30)
* [Debian should publicly support usage of the testing 
release](https://salsa.debian.org/debian/grow-your-ideas/-/issues/12)
* [Debian should have a unstable-proposed-updates suite for use during 
freeze](https://salsa.debian.org/debian/grow-your-ideas/-/issues/25)
* [Debian should formalize its reimbursement process to reduce extra 
paperwork](https://salsa.debian.org/debian/grow-your-ideas/-/issues/1)

Ideas of technical changes:
* [Debian should make it easy for blends and derivatives to build and host 
images](https://salsa.debian.org/debian/grow-your-ideas/-/issues/27)
* [Debian should make it easy to fork packages and/or the 
distribution](https://salsa.debian.org/debian/grow-your-ideas/-/issues/23)
* [Debian should further trim the base system for the benefits of containers 
and embedded 
systems](https://salsa.debian.org/debian/grow-your-ideas/-/issues/20)
* [Debian should complete the merged-/usr 
transition](https://salsa.debian.org/debian/grow-your-ideas/-/issues/22)
* [Debian should switch wiki.debian.org from MoinMoin to 
Mediawiki](https://salsa.debian.org/debian/grow-your-ideas/-/issues/2)
* [ports.debian.org should be managed with dak and 
britney](https://salsa.debian.org/debian/grow-your-ideas/-/issues/5)

Note that all the ideas are linked to a corresponding issue in the "grow your
ideas" project. Please consider upvoting the ideas there that you
consider worthwhile to pursue. You do that by clicking the "thumbs up"
button at the top of each issue on salsa.debian.org.


I have left out a few low-impact and really uncontroversial ideas (like
"port UDD to Python 3", we all agree on that, it's more a matter of
finding the right volunteer).

If you think I badly rephrased some of the ideas in there, please let me
know. Feel free to suggest improvements by mail reply or with a MR here:
https://salsa.debian.org/freexian-team/misc-drafts/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: What are the most important projects that Debian ought to work on?

[Raphael Hertzog]

Hi,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> However, there's no easy way to identify what are the most popular ideas
> of improvements that Debian ought to make. We know of the
> "grow-your-ideas" project on Salsa, but it's far from exhaustive:

I spent a couple of hours to put my own wishes in the system. If you
support those improvement ideas, please up-vote them:

* Better infrastructure to manage transitions:
  https://salsa.debian.org/debian/grow-your-ideas/-/issues/21

* We should trim the base system to be more container friendly
  https://salsa.debian.org/debian/grow-your-ideas/-/issues/20

* Unified workflow for package review
  https://salsa.debian.org/debian/grow-your-ideas/-/issues/19

* Debian should provide high quality ansible roles (and/or salt formulas, etc.)
  https://salsa.debian.org/debian/grow-your-ideas/-/issues/18


There are certainly more important ideas that are not recorded there
yet but I leave that up to others to file them if they care about
those:

- interactive (read-write) web-frontend for bugs.debian.org

- the Maintainer/Uploaders listing in debian/control should be replaced
  with something more dynamic/fluid, representing better the kind of
  commitments that each of us makes towards a given package (and the kind
  of control that we ask in exchange)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: What are the most important projects that Debian ought to work on?

[Raphael Hertzog]

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:

I have filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/21
which states:

Better infrastructure to manage transitions

# The problem

It's too much manual work to handle a big transition.

# Actual workflow

When you introduce a new major upstream version, you often have to handle
a transition because (many) other packages have to be updated to cope with
that new version. Ideally, you do a mass-rebuild of the reverse
dependencies (build- and runtime-dependencies) and you run their
autopkgtest to ensure that they are still working.

If you are a very good citizen, you might use `ratt` to do the rebuilds
and you might upload the package to experimental to figure out with
ci.debian.net if you break other packages. But more likely you don't know
about those, or you decide that you don't have the computer resources to
run those, and you do nothing (except possibly filing bugs or sending
mails to ask other maintainers to test their packages with your updated
package).

At some point, you upload your package because you decided that you left
enough time for others to fix their packages and you end up breaking their
packages... at least the bug will be raised to release critical and the
package will either be fixed or removed, which should eventually allow
your package to migrate to testing.

# Expected workflow

1. You upload the new version as usual, dak detects that it's breaking
   many packages and it thus decides to put the package in a dedicated
   package repository (think PPA) that will be used to handle the transition.

2. The required-binNMU are triggered and the resulting binaries are
   uploaded in the PPA.

3. The failing rebuilds appear in the dedicated transition tracker.

4. The failing autopkgtest appear in the dedicated transition tracker.

5. You click on a button to submit all the bug reports for the failing
   rebuilds and failing autopkgtest. The corresponding bugs and their status
   automatically show up in the transition tracker.

6. After a while, most of the bugs have been fixed and the transition
   tracker is looking much better. The system did automatically test the
   newest versions that were uploaded to unstable. The binNUM have been
   updated as well for the packages that have been updated in parallel.

7. That said the number of broken packages is still too high for your
   limited time, so you decide to ask for help to other team members.
   Together you manage to review all the failures. Sometimes you provide a
   fix and record the associated merge request in the system. Sometimes you
   decide to ignore the issue because it's better to remove the package and
   you add a note explaining this.

8. When you're done, the release team takes a look at your transition
   tracker, and gives you the green light to go ahead, you finalize all the
   uploads to the PPA for the packages that had a pending merge requests and
   you click on a button that uploads all the packages from the PPA directly
   to unstable.

9. All the packages migrate to testing in a few days.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Unified workflow for package review

[Raphael Hertzog]

On Tue, 08 Feb 2022, David Bremner wrote:
> Raphael Hertzog  writes:
> 
> > We should have a single web service that is able to handle all those
> > workflows and provide all the inputs that each team needs to make their
> > decision. It should have a nifty web interface (including with
> > authentication and restricted access for embargoed security updates) where
> > people can inspect the packages and approve/reject the packages if they
> > are part of the affected teams.
> 
> I know that many people would like more web interfaces, but if I _have_
> to use a web service to do my packaging work, I will stop. No accounting
> for taste I guess.

I fully expect such a service to have an API that can be used to build
a command line interface for people like you.

At the same time, we must recognize that our aging email-based workflows
and the multitude of different workflows are hurting our ability to
on-board new contributors.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

We should trim the base system to be more container friendly

[Raphael Hertzog]

Hi,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:

I filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/20 which
states:

We should trim the base system to be more container friendly

# The problem

Our base system is too big: building containers on top of Debian ends up
with huge containers even for trivial applications.

# Actual situation

Current Debian docker images are more than 50Mb compressed for the normal
variant, about 30Mb compressed for the slim variant. While it will never
be possible to reach the size of alpine (3Mb compressed), we can do much
better than this.

# Expected situation

We trim down our base system to get rid of perl and other parts that are
taking lots of space without adding any real value. We replace perl
scripts with C applications, we move bash out of the essential set, etc.

We end up with a much smaller docker images and Debian becomes more
popular to build containers thanks to its vast collection of packages.

This would also helps to reduce the footprint of Debian for VM/cloud
servers, for embedded systems, etc.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Unified workflow for package review

[Raphael Hertzog]

Hi,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:

I filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/19 which
states:

# Unified workflow for package review

## The problem

There are many processes in Debian where we want to review Debian packages
in some way:

* when you upload to Debian for the first time (the NEW queue)
* when you upload a stable update
* when you upload a security update (embargoed or not)
* when you upload a backports
* when you upload to mentors.debian.net
* when you sponsor a package for someone else
* when you review a merge request on salsa that changes your packaging rules

All of those have custom workflows, and different but somewhat overlapping
set of checks. Sometimes you have an associated web interface, sometimes
not, but it's never the same web interface.

## Expected situation

We should have a single web service that is able to handle all those
workflows and provide all the inputs that each team needs to make their
decision. It should have a nifty web interface (including with
authentication and restricted access for embargoed security updates) where
people can inspect the packages and approve/reject the packages if they
are part of the affected teams.

## Additional information

Some of the problem space described here is actually part of the reasons
why I decided to start debusine and why we inject Freexian money into
debusine:
https://freexian-team.pages.debian.net/debusine/devel/why.html

We want to improve the review workflow for LTS updates.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Debian should provide high quality ansible roles

[Raphael Hertzog]

Hi,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:
> 
>   https://salsa.debian.org/debian/grow-your-ideas/-/issues

I have filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/18
which states this:

# Debian should provide high quality ansible roles (and/or salt formulas, etc.)

## The problem

In the modern world, we don't configure services with debconf but with
tools like ansible, puppet, salt, etc. All those tools have some sort of
external repositories where users can share the automation that they
created but most of them share some common issues:

- there's few review and the quality is thus varying
- you often have multiple implementations to configure the same service
- you have no guaranty of maintenance over time
- the lack of standardization hurts when you try to combine multiple of those 
automations
- they might not have been tested on Debian

## Expected situation

Debian is very good at creating high-quality policies and applying them
consistently, and then maintaining the result over time.

Thus Debian should include in its goals to provide high quality ansible
roles (and/or salt formulas, etc.) that can be used to configure the
services that you would install with packages from the Debian OS. This
would require defining an "Ansible policy" to dictate how those roles
should work (how variables are named, how you feed data, etc.).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Services offered by Debian should be dogfooding the real packages on DSA hosts.

[Raphael Hertzog]

Hi,

On Tue, 25 Jan 2022, Phil Morrell wrote:
> I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15

Thanks for this, but this issue like a few others that have been filed do
describe problems but fail to provide "project/improvement ideas". We are
good at figuring out what's sub-optimal but we are not good at proposing
solutions and implementing them.

With the Freexian funding, I want to help find time/people to implement
(some of) them but it will be hard to spend the money if we don't have
people willing to spend brain cycles to figure out how we should fix all
those issues.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Q. What is the best practice about +dfsg and +ds extension?

[Raphael Hertzog]

On Sat, 02 Oct 2021, Sean Whitton wrote:
> > When upstream codebase require repackaging for (only) other reasons than
> > DFSG compliance I instead use the hint "ds" (as in "derived source").
> 
> Or "Debian source" :)

I always thought "ds" was for "debian specific" tarball. :-)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Reconsider sending ITP bugs to debian-devel: a new list?

[Raphael Hertzog]

Hi,

On Fri, 11 Jun 2021, Jonathan Carter wrote:
> Wouldn't it just be far simpler for those who wish not to receive the
> ITPs to filter them out to a subfolder of debian-devel or discard them?

Jonathan explained that it wasn't easy for him due to reading over NNTP
and I also think that it's a bad default to have lists where custom
filtering is desirable for many.

I tend to agree that we should move ITP elsewhere.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Thu, 10 Jun 2021, Helmut Grohne wrote:
> On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote:
> > I want to know it precisely in the context of selecting a worker. I don't
> > want to schedule a task on a worker and later get back an answer "sorry I
> > can't handle your task", and then have to schedule it on some other
> > worker.
> 
> I'm a little unsure what you mean precisely here. [...]
> Or do you want to locally decide whether your worker can handle
> it (e.g. using data previously acquired from the worker and cached on
> the scheduler)?

That's my plan, yes.

> I guess it is not the last variant, because you cannot validate the
> distribution in any way. I guess it also is not the first variant,
> because you don't want to call into every single worker for every single
> build object. Do you confirm that you want the second variant?

Yes.

> you can disable such a worker of course. Still, I suggest that you
> cannot rule out all possible worker-specific failure modes ahead of
> time.

Right.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Tue, 08 Jun 2021, Helmut Grohne wrote:
> With "look behind the abstraction", I think that you mean that debusine
> would have to implement the mdbp api to perform worker selection. While
> that would be possible indeed, I don't see this as required though.
[…]
> I do wonder though, in what kind of situation would you want to merely
> know whether a backend can perform a build as opposed to just attempting
> it and being able to tell backend issues from actual build failures
> apart.

I want to know it precisely in the context of selecting a worker. I don't
want to schedule a task on a worker and later get back an answer "sorry I
can't handle your task", and then have to schedule it on some other
worker.

When I have selected a worker, I want to be sure that the worker
is properly configured to be able to run that specific task.

> > It would not be enough for debusine yet (for debusine I need to be able to
> > export data from the worker and then make that decision on the server and
> > not on the build machine itself) but it would be nice step forward for the
> > local use case where you want "mdbp" to figure out alone which backend to
> > use based on what the user did setup earlier.
> 
> Yes, that makes sense. I note that the decision is meant to be made on
> the build-issuing side for mdbp as well. If you use the ssh backend, the
> relevant command might look like this:
> 
> mdbp-ssh someserver.somesite mdbp-mmdebstrap --mirror 
> http://mirror.somesite/debian

Yes, but using the ssh backend will require specific user configuration
while the sbuild/pbuilder one could potientially be auto-selected based
on whether the user did run the appropriate sbuild-create-chroot or
pbuilder --create earlier.

> > This abstraction definitely makes sense to me. Before looking closely
> > at your build_schema.json, but after having looked at your mail here,
> > I wrote this as a try to go in your direction:
> > https://freexian-team.pages.debian.net/debusine/devel/ontology.html#task-packagebuild
> 
> Great. Maybe that's the level where we can make best progress?

Likely, yes.

> I've taken the liberty to rather open a discussion issue at
> https://salsa.debian.org/freexian-team/debusine/-/issues/10. Hope this
> works for you.

Yes, thanks!

> > PS: I already hate the "mdbp" name after having it typed so many times.
> 
> I'm not attached to either. Any suggestions?

sbp for "standardized build package" is easier to type but not necessarily
nicer.

"justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I
don't care how it gets built!).

"deblord" or "debring" - the lord of the ring to tie all package builders
together

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Mon, 07 Jun 2021, Helmut Grohne wrote:
> My abstraction says nothing about workers or how to select them. The
> idea behind that was that a user should not have to care. Yes, you
> (debusine) do need a mapping between workers and available distributions
> somewhere. You can implement scheduler as a middleware (or router) in
> the abstraction I'm proposing to do this selection. What I don't see is
> where this hurts. The worker selection is something that you have to do
> anyway regardless of whether you use mdbp for the build abstraction.

The point is that if you have to look behind the abstraction to do some
other related tasks like selecting the worker, then using the abstraction
to actually execute the build doesn't bring you much, just supplementary
issues if the assumptions that you make no longer match the assumptions
implemented in the abstraction.

And it seems to me that aiming for "it works out of the box without having
to configure mdbp (if you already have sbuild schroot or pbuilder
tarball)" is a nice thing to aim for. So somehow it would be nice if your
various mdbp-* implementations could report whether they are able to
perform a given build.

It would not be enough for debusine yet (for debusine I need to be able to
export data from the worker and then make that decision on the server and
not on the build machine itself) but it would be nice step forward for the
local use case where you want "mdbp" to figure out alone which backend to
use based on what the user did setup earlier.

That said if you are willing to complexify your mdbp abstraction to
cover this use case, then there might be room to actually use mdbp in
debusine. I would still be annoyed by having to interface with CLI calls
to make basic requests like those and I would hope that we could define a
Python API instead.

> I'm actually interested in figuring this out as the fewer competing
> abstractions we end up with, the better they will be supported.

Sure.

> I note that my abstraction kinda has two levels. For one thing there is
> a build object (represented as json, but that really doesn't matter). It
> describes the action that is requested by the user (what to build,
> architectures, options, etc.).

This abstraction definitely makes sense to me. Before looking closely
at your build_schema.json, but after having looked at your mail here,
I wrote this as a try to go in your direction:
https://freexian-team.pages.debian.net/debusine/devel/ontology.html#task-packagebuild

There are some differences that we should strive to eliminate but I leave
that up to you to comment, it's too late for me right now. :-)

Feel free to submit merge requests to update my document to more
closely match yours (many entries are missing).

> The other is a command line interface that receives a build object and
> transmits (via files) the relevant artifacts. Maybe the build object
> level better addresses the needs of debusine while leaving some aspects
> unanswered (e.g. artifact transmission).

Yes, the "command line interface" does not really help for debusine,
unless you extend it to cover the requirements I explained above. And even
then I don't really like to have to run an external executable to be able
to answer a question like "can this worker handle this build request".

On the opposite, the fact that debusine will expose a "PackageBuild" task
matching your abstraction means that it will be trivial to write
mdbp-debusine.

Cheers,

PS: I already hate the "mdbp" name after having it typed so many times.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Fri, 04 Jun 2021, Helmut Grohne wrote:
> This is very sad. The whole point of me reaching out where was
> specifically trying to avoid this kind of fragmentation and now you're
> adding to it. While mdbp also is an implementation, it first and
> foremost is an API and I'd hope that it would be generic enough to be
> reused here.

I don't want to sound too negative but you can't put at the same level
"mdbp-ssh" and "mdbp-sbuild". Your abstraction is going too far by trying
to include remote building IMO.

And while abstractions are nice, for debusine I need to know how each
implementation work to be able to answer questions like "can I build for
that distribution on this worker" (i.e. do I have the required chroots) ?
And here your current abstraction is hurting more than it helps.

So I'm afraid that mdbp is just not suited for the needs of debusine at
this point.

Also given that you want to include support of building across multiple
machines, I don't really understand why you select a command line API
as the interface to drive this all. It's just not a good fit. Having one
process drive all the machines via ssh is just fragile and not really
scalable. And it requires all the machines to be directly adressable. In
debusine, only the server needs a public IP, the workers connect to it.

> Of course, you can turn this around and say that I'm the one fragmenting
> and I should be using the debusine abstraction. Unfortunately, I'd need
> a time machine to get it from the future. Otherwise, I'd really do that.

:-)

We managed to live without this for years, we can wait a few more months.
But it's not up to me to tell you what to work on.

> > As I said, I don't want to tightly couple it, it's just the easiest and
> > most useful first step for me.
> 
> I doubt this is true. You already learned the hard way that coming up
> with an abstraction for just sbuild is difficult. Using an existing
> abstraction saves you from a pile of thinking and quite certainly is
> easier.

Thanks for your feedback indeed, it improved the initial design and will
avoid some rework in the future when we add the abstraction.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Wed, 02 Jun 2021, Helmut Grohne wrote:
>  * debusine's build milestone implements a lock-in on sbuild. The
>abstraction that I'm seeking doesn't happen here.

Just to be clear, I think I want that kind of abstraction at some point.
Because one should be able to schedule a package build and it should be
able to build without preference on a worker where we have sbuild + the
appropriate chroot or on a machine where pbuilder has been setup or
on a machine with mdbp ;-)

But Freexian is paying someone to get this code so I'm doing it with small
steps that lead to a minimal viable product on which we can cooperate
further. Release early, release often. :-)

That abstraction will likely come later when someone implements a second
way to build packages.

> Possibly debusine could replace its sbuild task with a mdbp task?

I don't intend to restrict too much the number of "tasks" that I will
accept in debusine, we can have both if it makes sense. Though I believe
that this is an abstraction worth having at the debusine level without
delegating that abstraction to "mdbp".

> would automatically work on pbuilder and mmdebstrap for free. It also
> doesn't have to implement another method for issuing builds remotely and
> can concentrate on the scheduling part.

That's not really relevant, part of the goal of debusine is to let
you leverage a network of workers for any kind of task, not only for
package builds.

> > In the current design
> > (https://salsa.debian.org/freexian-team/debusine/-/issues/7) for the
> > current iteration, I don't have that level of details but it should
> > not be too hard to add this on top. Only the differentiated handling of
> > build/host architecture might be non-trivial as it will impact the 
> > scheduling
> > (identification of an appopriate worker).
> 
> Please get the architecture part right from the start. It is not that
> hard actually. Your issue already mentions an unspecific "architecture"
> field, so you already get to choose suitable workers. It is only the
> build architecture that affects worker choice. The host architecture is
> only a setting to pass down and debusine does not have to care about it
> at all.

I tried to fix it based on your feedback in the ticket but it looks like
it doesn't match your expectation. When I request a build for the "arm64"
architecture, I want "arm64.deb" as output, that's defined by the "host
architecture" right?

(In this context, I would not care if it's build by cross-compilation in
an amd64 build chroot or if it's build natively in an arm64 chroot)

> Maybe we can use some AWS credits to provide PBaaS to developers at some
> point. Or even archive rebuilds as a service.

Definitely.

> While Debian uses sbuild in official buildds, reproducible.d.n is fully
> built on pbuilder instead. It isn't that homogeneous in the end. In
> order to make debusine easier to set up, I think it should not tightly
> couple with sbuild.

As I said, I don't want to tightly couple it, it's just the easiest and
most useful first step for me.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Seeking feedback on a meta package builder

[Raphael Hertzog]

Hi,

On Mon, 31 May 2021, Helmut Grohne wrote:
> I see this tight coupling as a problem for mainly two reasons.
[...]
>  * As tasks grow, there is a desire to distribute builds to multiple
>machines. As such, the various tools typically grow their own
>strategy for moving build tasks between machines.

We already exchanged a while ago about "debusine", it ought to solve this
part a least.

https://freexian-team.pages.debian.net/debusine/

We're just starting to work on the project with the goal of handling
package builds as a first step:
https://salsa.debian.org/freexian-team/debusine/-/milestones/1

I invite you to "watch" the project on
https://salsa.debian.org/freexian-team/debusine so that you get
notification of comments on issues as that's where we are discussing
the design.

And feel free to file feature requests.

> So I set out to solve this. More precisely, I looked for an API that
> could abstract both sbuild and pbuilder (because they're the most common
> ones) and allow executing builds on remote machines. A tool performing
> builds should not have to care which one is in use and whether the build
> is performed locally or not. Since describing the settings of a build
> can be complex, I chose json for representation. Some aspects that you
> may want to set for a build are:
>  * build architecture / host architecture
>  * arch-only / indep-only / full
>  * DEB_BUILD_PROFILES
>  * DEB_BUILD_OPTIONS
>  * whether network access is permissible
>  * forcing a build path

In the current design
(https://salsa.debian.org/freexian-team/debusine/-/issues/7) for the
current iteration, I don't have that level of details but it should
not be too hard to add this on top. Only the differentiated handling of
build/host architecture might be non-trivial as it will impact the scheduling
(identification of an appopriate worker).

>  * Does the problem scope I've chosen make sense?

"Package Build as a Service" :-)

When thinking of debusine, I thought something of something similar, I
have set out to use sbuild in the first iteration because that what I
(and Debian) uses for official package builds but given the number of
different ways to build packages, I was wondering whether I should
consider to have a tool-agnostic "PackageBuild" task that can be scheduled
and that could then be performed by tool-specific implementations.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Raphael Hertzog]

On Fri, 12 Feb 2021, Peter Pentchev wrote:
> > Yeah, it would go a long way if pristine-tar would store the associated
> > signature and restore it as well. It's easy to forget to include it
> > when the uploads are not done by the same person.
> 
> It can, since version 1.41:
> 
> debcheckout confget
> cd confget
> git checkout pristine-tar
> git checkout master
> git checkout debian/master
> pristine-tar checkout -s ../confget_2.3.4.orig.tar.xz.asc 
> ../confget_2.3.4.orig.tar.xz

Well, then I assume that the git-buildpackage integration doesn't do
this automatically. Honestly, you should not have to specify that you
want to check out the associated signature at the same time or maybe with
a generic option --include-associated-files that would not fail if
there's no associated file.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Raphael Hertzog]

Control: block -1 by 876643

Hi,

thanks for your quick answer!

On Fri, 12 Feb 2021, Guillem Jover wrote:
> > If we assume that the archive is meant to store immutable content
> > under a given filename (and to me that requirement seems to be a good
> > idea), then we should question ourselves whether we really want to store
> > those signatures in a filename that's associated to the upstream version.
> > They should either be tied to the Debian revision (so that they can change
> > over time without any new upstream release) or be incorporated in the
> > Debian tarball.
> 
> The upstream signatures are important to determine the provenance of
> the source at the time of packaging, just like the signatures on .dsc,
> both lose relevance once they hit an archive.

I agree with this. Why do we want to upload them and store them forever
then?

> This seems mostly a tooling problem TBH.

Yeah, it would go a long way if pristine-tar would store the associated
signature and restore it as well. It's easy to forget to include it
when the uploads are not done by the same person.

Because I already saw the warning saying that I lack the signature file
(based on the idea that if we have the uptsream key we want to upload the
signature, but I don't buy this, I believe it's a help for the maintainer
to verify the tarball it downloads during uscan but I don't see the point
to upload it for eternity) and I saw it as a nuisance more than a help...
I would usually not check if there really was a signature file before or
not.

On Fri, 12 Feb 2021, Guillem Jover wrote:
> > This usually appears in the way of people uploading a package with the same
> > name and version of something that was removed long long ago and since then
> > archived and forgotten by dak.
> 
> Ah, sorry, right, that dak forgetfulness problem which seems
> contagious. :)
>
> Ok, so then these seems like two bugs in dak. dak sees the .asc, then
> they disappear and it forgets them, and then files with different
> content can then be uploaded.

FTR this is this bug that has been ignored for years and that also
affected Kali more than once:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876643

Kali would be happy to sponsor anyone who can tackle this bug in dak...

> While ideally dak would never forget, the problem here is that dak
> allows uploads that drop the .asc files, no?

Possibly... but then it means that you need to treat signature file
differently from any other extra file that you want to attach to the .dsc.
Because for extra .orig tarballs, we want the current behaviour where you
can add and drop them freely between Debian revisions.

So I'm not sure it's worth the extra logic.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Possible DEP proposal - contribution preferences

[Raphael Hertzog]

Hi Jelmer,

On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> One of the things that I've been wondering about is whether it would make
> sense to have a configuration file in Debian packages that allows
> maintainers to specify preferences for contributions. At the
> moment, this is not a well-formed proposal yet - but I'm curious as to
> your thoughts.

I must say that we keep adding layers of complexity and this would
just extend the amount of things that one should know about packaging.

We need more consistency and not more choices. But in the end, those
choices are differences that do already exist in practice.

In the grand scheme of things, we should have a Debian-wide
recommended way of handling packages and this configuration file
would only be needed when a maintainer really wants to deviate from
this recommended way.

The DEP we need is the one that defines this default way of handling
packages and contributions, and the file you want would only be a
by-product of this.

>  * Generally speaking, the preferences would be the same for
>all packages maintained by a specific team/person. Having to copy
>these preferences into every git repository in a set (e.g.
>perl-team) seems tedious and unnecessarily repetitive. Maybe this
>should live in a separate database somewhere, or perhaps it can be
>specified in salsa somehow on a per-team basis?

Somehow this ship has sailed, plenty of teams do commit debian/gbp.conf
and debian/salsa-ci.yml in all their repositories. At least the GitLab CI
has an URL include mechanism that makes it possible to create a team-wide
configuration and include it.

>  * Should this really be a separate file, or could it be folded
>in elsewhere?

I don't know of anything else but if we create a new file, I'd rather have
it in debian/source/ rather than right below debian.

>  * Allowing maintainers to specify preferences might also make it more
>likely that packaging habits diverge - and that could it make it
>harder rather than easier to contribute to packages. At the very
>least, we should be careful what sort of preferences can be
>specified.

+1

>  * A lot of these things can be detected with heuristics. In a
>way, adding a configuration file is an easy way out - instead of
>getting these tools to just do the right thing without making a
>human edit a file.

Indeed.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: About lintian

[Raphael Hertzog]

Hi,

On Tue, 19 Jan 2021, Antonio Terceiro wrote:
> > Can you expand on the kind of features that ci.debian.net offers and what
> > kind of mistakes we would likely avoid by reusing it?
> 
> To name a few:
> 
> - distributed processing
> - data retention policies
> - web interface

Thanks for your answer!

> - monitoring

What do you monitor?

> > From my own usage in Kali (autopkgtest.kali.org), I noticed you can't
> > even request to test a specific version of a package... you get whatever
> > version is available in the specific mirror that you are using for your
> > test, even if it's not (yet) in sync with the one used by the code that
> > requested that job.
> 
> autopkgtest does not support that, so debci doesn't offer it as well.

I see where you are coming from but I consider autopkgtest as the backend
and you feed it the packages and you get the results. You can feed the
packages directly or you can tell it to fetch them from a mirror, IMO
it's still the responsibility of the caller (debci) to feed the right
package to test.

> I didn't say it was ready for it now, but that it could be done.

Ok.

> My hope is that this, and other use cases, could be enabled by
> collaborating on existing infrastructure, instead of creating yet
> another one.

In general I agree with the need to collaborate more and not redo
everything but to be honest, at least for me, the fact that it's
written in Ruby and not Python makes it unlikely that I will contribute
to it.

For better or worse, the amount of Debian infrastructure built around
Python is growing and I think it would be best if such a core part could
be Python-based too. I really believe it's a "core" part because it ought
to be able to handle package building too...

At while ago, I started to draft a specification in this project:
https://salsa.debian.org/hertzog/debusine

Unfortunately, it's vaporware as I don't have time to invest into it.
Though I'm considering to put money towards its development through
https://salsa.debian.org/freexian-team/project-funding

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: About lintian

[Raphael Hertzog]

Hi,

On Mon, 18 Jan 2021, Antonio Terceiro wrote:
> FWIW, The ci.debian.net infrastructure is mostly independent from
> autopkgtest, so we could have different types of jobs there. This could
> be used for lintian, but also for on-demand rebuilds, and other types of
> checks that needs to be done to packages in the archive. the debci
> codebase has seen a lot of work to properly handle stuff like this in
> the last 6 years, and it would be a win if we can reuse that for other
> use cases, instead of someone having to start from scratch having to
> learn again everything that I did in the last 6 years working on ci.d.n.

Can you expand on the kind of features that ci.debian.net offers and what
kind of mistakes we would likely avoid by reusing it?

From my (relatively remote) point of view, ci.debian.net seems really
very basic in terms of features related to scheduling of jobs.

From my own usage in Kali (autopkgtest.kali.org), I noticed you can't
even request to test a specific version of a package... you get whatever
version is available in the specific mirror that you are using for your
test, even if it's not (yet) in sync with the one used by the code that
requested that job.

There's also no possibility to have differentiated workers (qemu vs
lxc-based) and have the jobs dispatched to appropriate workers.

Scheduling features might not be important for lintian processing but I
believe it's a must have if we want to consolidate more jobs in a single
place.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

On Fri, 18 Dec 2020, Jonas Smedegaard wrote:
> Who is keeping software out of Debian here?

We, collectively, with the fact that we have not adapted our rules and
tooling. (And yes you certainly did more than me on this front, in
particular in the tooling front, I'm not arguing against that)

> Me, considering proper packaging of greenbone-security-assistant a 
> possible task?
> 
> Or you, considering it an impossible task?

Please don't make it personal. I did not and I ask you to not do it.

I'm not saying it's impossible, I'm saying it's not realistic for
volunteer maintainers, and even for the few that have the chance to be
paid for it, they can't justify the expense to do it following the current
rules and policies.

> Or if you are talking about the Kali helper tool here, then please do 
> share more details of that wonderful tool, so we can know if you are 
> talking about a way to make the impossible-in-your-view possible while 
> still complying with Debian Policy, or the wonder really is in an 
> implied relaxing of packaging quality.

There's no wonderful tool. It's just that we don't have the same rules.
And I don't agree that the "packaging quality" is worse in this specific
case.

We have certainly made ugly things at times, but in this specific case,
relying on the uptsream build system is certainly not "bad quality", the
tool works and it likely works better when we can ensure that we use the
same set of libraries than upstream compared to the random versions that
happen to be in Debian at any given time.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

On Thu, 17 Dec 2020, Adrian Bunk wrote:
> > - ease of installation and reliability
> >   => we are doing bad now because many useful things are not packaged
> 
> What is the value added just by installing things through dpkg instead 
> of npm?

Why are you using Debian if you ask this?

On the top of my head:
- as a user, I like to have to only know about "apt/dpkg" instead
  of pip/npm/gem/...
- the Debian maintainer is ensuring some consistency that a random
  collection of uptsream installations are not enusring
- simple and consisten upgrade process
- etc.

> >   (due to the mismatch between our rules and those not-longer-so-new
> >   ecosystems) and when users have to manually install, the reliability
> >   goes down...
> 
> What reliability do you have with a 3 year old version of software where
> upstream only tells your users to upgrade to the latest versions?
> 
> The "changed paradigm" usually includes automatic updates to the latest
> version without any maintainance of older versions.

Indeed. We should have room for such software that should only be provided
within our rolling distribution and as backports.

> This is the easy part.
> How do you plan to fix all vulnerable versions?

By providing the latest and greatest version to all our users. As you
noticed, that kind of software does not mesh well with stable and LTS.

And at least anyone that is not installing the latest version can have
an idea of whether it's important/urgent for them to upgrade or not.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

On Thu, 17 Dec 2020, Jonas Smedegaard wrote:
> > said package was updated in Kali in a matter of hours.
> 
> That's great.
> 
> I mean - *either* it is great that Kali has a far better tool that we 
> might adopt - *or* it is great that Kali exists for those with different 
> needs than those of Debian.

I know that some people are happy when we keep software out of Debian, but
I don't share that view. For me the universal OS ought to to have a place
for any decently maintained free software.

We might not want to ship it in stable and include it in LTS, but we should be
able to provide the latest version and make it easy to install to our
users.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

On Thu, 17 Dec 2020, Pirate Praveen wrote:
> > - ensurance that we use DFSG free code only
> >   => we can have tool to review licenses of what has been
> >   downloaded during build and embedded in the binary packages
> 
> Then there would not be any value for Debian with such a scenario as people
> can do such analysis on any distro/container.
> 
> It would make debian irrelevant.

I don't think so. First the tool is here to help the maintainer do the
assertion, it's unlikely to be 100% automated, it will likely point
out files to inspect manually and so on.

And, as a user, even if the tool exists, I wouldn't want to run it manually,
I would continue to rely on Debian for the vetting process. I don't want
to have to do this on my own.

> >   => we are doing bad now because many useful things are not packaged
> >   (due to the mismatch between our rules and those not-longer-so-new
> >   ecosystems) and when users have to manually install, the reliability
> >   goes down...
> 
> This I agree, but this could be achived by a mix of vendoring and individual
> packages. We can vendor modules that are specific to a single app and
> package more useful libraries as individual packages.

For this to work at scale, you need to work with the upstream ecosystem so
that this works out of the box... AFAIK right now adding the required node
modules in build-depends will not avoid those modules to be downloaded by
the upstream build system and there's no simple flag that you can just add
to enable that behaviour. Is that correct ?

> > - possibility to rebuild from source
> >   => we could have some sort of proxy that would store everything
> >   downloaded and let us rebuild an identical package without net access
> >   even if the remote resources disappear
> 
> Why would anyone need to use debian in such a scenario?

I don't know for you but the reasons to use Debian would not be changed
by the addition of this mechanism. I know that I use only free software,
that all the tools are easy to install, that some sane default
configuration has been provided by the maintainer, that further
instructions are in README.Debian, etc.

> All the current trends are making it easy for developers to ship code
> directly to users. Which encourages more isolation instead of collaboration
> between projects. It also makes it easy for shipping more proprietary code,
> duplication of security tracking or lack of it. Debian and other
> distributions have provided an important buffer between developers and users
> as we did not necessarily follow the priorities or choices of upstream
> developers exactly always.

This I agree with. And I believe it still stays true even if we accept to
vendor large amount of stuff.

> We need to be doing what is the buzz of the time. Free Software was not a
> mainstream idea when we started.

I don't understand what you are trying to say here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

Hi,

On Thu, 17 Dec 2020, Jonas Smedegaard wrote:
> > Out of curiosity, I have run your script on the package.json file of 
> > greenbone-security-assistant and this just confirms that it's not 
> > realistic to package everything separately: 
> > https://wiki.debian.org/Javascript/Nodejs/Tasks/gsa
> 
> Nice.  Doesn't look like an impossible task to me.

It looks like a huge amount of work that does not bring any value compared
to the Kali package relying on the upstream build system without any
tinkering.

> In reality, most Nodejs modules declare too tight versioning for their 
[...]

I know this, but I also know that such an analysis is very time-consuming
and needs a good knowledge of the language and of the upstream package,
which I don't have.

> In your original post you seemingly already ruled out proper packaging 
> as a premise, and it seems you continue to use absolutes like 
> "everything" and "never".  I find that discouraging - plase consider a 
> less negative tone.

Sorry, I don't want to discourage you. But I'm also sure that I will never
be able to justify spending days and weeks on packaging (and then
maintaining) all those node modules for the benefit of pushing a single
package to Debian when said package was updated in Kali in a matter of
hours.

By trying to shoehorn node/go modules into Debian packages we are creating
busy work with almost no value. We must go back to what is the value
added by Debian and find ways to continue to provide this value while
accepting the changed paradigm that some applications/ecosystems have
embraced.

And for me selling points are:

- ensurance that we use DFSG free code only
  => we can have tool to review licenses of what has been
  downloaded during build and embedded in the binary packages

- ease of installation and reliability
  => we are doing bad now because many useful things are not packaged
  (due to the mismatch between our rules and those not-longer-so-new
  ecosystems) and when users have to manually install, the reliability
  goes down...

- possibility to rebuild from source
  => we could have some sort of proxy that would store everything
  downloaded and let us rebuild an identical package without net access
  even if the remote resources disappear

- security support
  => we need to be able to identify packages that are vulnerable because
  they have embedded a problematic version of a node/go module, again we
  need tools that analyze what got embedded in the binary package and make
  this easy to query

BTW, that's the kind of infrastructure development that would advance
the cause of Debian and that I would be glad to (start to) fund through
https://salsa.debian.org/freexian-team/project-funding

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

Hello,

On Thu, 17 Dec 2020, Pirate Praveen wrote:
> >1/ download all the node modules and add them to the source package, but
> >then it's just impossible to write a copyright file to document the source
> >package. That would be the best option though, the yarn.lock file
> >effectively locks a very specific version of each node module so
> >even though it's downloaded the net effect is very similar to "vendoring"
> >as is done by other projects.
> 
> This will only work for a subset of modules because most modules will
> not be just source (unlike golang), it will contain prebuilt files. The
> original source is usually ES6 or typescript usually and you need to
> build them using babel/rollup/typescript.

I don't understand what you mean. Are you trying to say that this won't
help much because we will have another DFSG-freeness problem in the sense
that what we would embed is not the source and that DFSG requires us to
provide the sources?

> I use this option for gitlab, but I want to eventually move it to main
> once I package all of them. Out of 1700+ node modules, I'm left with
> 270+ node modules pulled outside of main. I remove already packaged
> modules from package.json.

I appreciate all the efforts that you are doing here but to me it seems
like a dead end. Much like the idea of adding another repository to
accomodate the ever-growing list of go modules that nobody will ever
want to use except as a build-dependency.

To me it seems that we must adapt our rules, our expectations and our
tooling to cope with this paradigm shift where dependencies are downloaded
at build time.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: How should we handle greenbone-security-assistant?

[Raphael Hertzog]

Hi,

On Wed, 16 Dec 2020, Jonas Smedegaard wrote:
> 4/ analyze what yarn/npm would do during build, and translate that into 
> existing Debian Nodejs packages and actual need for custom work.  In the 
> JavaScript team we use this page as starting point for analyzing large 
> projects: https://wiki.debian.org/Javascript/Nodejs/Tasks

Out of curiosity, I have run your script on the package.json file of
greenbone-security-assistant and this just confirms that it's not
realistic to package everything separately:
https://wiki.debian.org/Javascript/Nodejs/Tasks/gsa

Even if you package everything, you will never ever have the right
combination of version of the various packages.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

How should we handle greenbone-security-assistant?

[Raphael Hertzog]

Hello,

in the pkg-security team we have greenbone-security-assistant (gsa)
which is a web interface for gvm (former openvas-manager), the
version currently in Debian no longer works with the latest gvm
so we have to update it to the latest upstream release... but the
latest upstream release has significant changes, in particular
it now relies on yarn or npm from the node ecosystem to download
all the node modules that it needs (and there are many of them,
and there's no way that we will package them individually).

The Debian policy forbids download during the build so we can't
run the upstream build system as is.

As I see it we have three options:

1/ download all the node modules and add them to the source package, but
then it's just impossible to write a copyright file to document the source
package. That would be the best option though, the yarn.lock file
effectively locks a very specific version of each node module so
even though it's downloaded the net effect is very similar to "vendoring"
as is done by other projects.

2/ disable this download during the package build, move the package
to contrib, and add some code in the postinst to download the required
node modules at package installation time (possibly with a debconf
confirmation prompt and a command that the user can rerun afterwards
to do it later).

3/ get rid of greenbone-security-assistant in debian and keep it in kali
only (all the work I do in pkg-security is part of my Kali work), that
would be a regression from the current situation and is something that I'd
like to avoid. We try to contribute back to Debian, but there's only so
much busy-work that I'm willing to do to achieve this goal.

What option shall we pick?

Shouldn't we relax some requirements to avoid having to resort to that
kind of hackery?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: DEP-14 update, second attempt

[Raphael Hertzog]

Hi,

On Sun, 29 Nov 2020, Paride Legovini wrote:
> I tried to do a synthesis of past August/September thread on the
> finalization of DEP-14 [1], see:
> 
> https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs

Looks good to me, thanks for your work! I merged your branch and
I updated the status of the DEP in the table on the index page too.

> I tried to stick to what I believe we had consensus on, however I think that
> point (3) has a shortcoming: it allows / branches, but
> doesn't cover cases where  has no development _suite_. For example
> it wouldn't allow the kali/kali-dev branch, as Kali doesn't have suites
> (IIUC). This case could be covered by adding:
> 
>However, when `` has no concept of suite for the
>development release but has a fixed codename for it, the
>use of the `/` scheme is accepted.
> 
> I'd like to include this, but I left it out as it wasn't discussed before.
> Let me know what you think.

I don't think this needs to be spelled out. First when you don't have
"suites", the difference between a suite and a codename doesn't matter
much, you can say that the name of the distribution is both a suite and a
codename (and in fact the Release file in kali shows this use of the same
name in both fields). Also in the specific case of Kali, I will likely
switch to kali/latest rather than kali/kali-dev. ;-)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Architecture: all binNMUs (was: deduplicating jquery/)

[Raphael Hertzog]

On Wed, 02 Dec 2020, Raphael Hertzog wrote:
> > potentially different content, breaking the important design principle
> > that things that are different should have different names.
[...]
> And as an aside, the archive has big holes when enforcing this "design
> principle":
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876643
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620356
> It would be nice to have this fixed.

I knem I missed one, there's this one too which caught me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949962

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Architecture: all binNMUs (was: deduplicating jquery/)

[Raphael Hertzog]

Hi,

On Tue, 01 Dec 2020, Simon McVittie wrote:
> If I understand correctly, one of the ftp team's objections to discarding
> and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3,
> and they discard my binary upload and rebuild it on the buildds, this
> would result in having two binary builds of foo-bin_1.2-3_amd64.deb and two
> binary builds of foo-data_1.2-3_all.deb with the same version number but
> potentially different content, breaking the important design principle
> that things that are different should have different names.

That objection is debatable for packages that have not yet reached the
archive. Dropping the binary after NEW review ought to be sufficient.

And as an aside, the archive has big holes when enforcing this "design
principle":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876643
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620356
It would be nice to have this fixed.

> At the moment, builds in OBS cannot make use of Debian's binNMU machinery
> for this, because if they did, they would break the same ${source:Version}
> assumption I described in my previous message. The result is that they
> have to behave as though +bsos1 was a new sourceful upload, and
> foo-bin_1.2-3+bsos1_amd64.deb and foo-data_1.2-3+bsos1_all.deb both have
> Source: foo (= 1.2-3+bsos1). Consumers have to "just know" that to
> get the source code for foo-bin_1.2-3+bsos1_amd64.deb, you strip the
> /\+bsos[0-9]+$/ suffix from the version number before looking for the
> foo=1.2-3 source package. Obviously, this scales poorly if you are looking
> at multiple derivatives each with its own pseudo-binNMU suffix.
>
> If we had a way to do Architecture: all binNMUs, then OBS would be able to
> use it for all builds: for instance, foo-bin_1.2-3+bsos1_amd64.deb and
> foo-data_1.2-3+bsos1_all.deb could both have Source: foo (= 1.2-3).

In fact, dpkg has support for such binary-only rebuild. Have your
changelog entry like this:
| foo (1.2-3+bsos1) unstable; urgency=low,binary-only=yes
| 
|   * Binary rebuild.
| 
|  -- Raphaël Hertzog   Wed, 02 Dec 2020 10:48:12 +0100

And then "arch: all" and "arch: any" packages will have the proper
"Source" entry with a value of "foo (1.2-3)".

I just tested it and it works (at least with raw dpkg-buildpackage).

But this has the obvious downside that "${source:Version}" is unchanged
and that you might have issues with dependencies against the arch: all
package.

In the end, the solution to make it easy to bump the version with a no-change
source upload is more likely to happen quickly.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Bug#972674: ITP: toolbox -- Unprivileged container development environment

[Raphael Hertzog]

Hi,

On Thu, 22 Oct 2020, Hayley Hughes wrote:
> * URL : 
> 
> Toolbox is a tool that offers a familiar package based environment for
> developing and debugging software that runs fully unprivileged using Podman.
[…]
> I have already made some progress which can be found on salsa
> () for my own benefit (please feel
> free to review it and suggest changes) and I thought that it might be an
> idea to make an attempt to properly package it and add it to the Debian
> archives.
> 
> Will be keen to hear what others think.

I was looking for the package and I'm glad that you are working on
packaging it.

I have put in CC Reinhard Tartler and Dmitry Smirnov that are the
Uploaders of podman and buildah, maybe they would be willing to sponsor
your package and integrate it in the pkg-go team.

As for the discussion about the package name, podman-toolbox or
container-toolbox looks good to me. 

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)

[Raphael Hertzog]

Control: clone -1 -2
Control: reassign -2 autopkgtest
Control: retitle -2 "autopkgtest: implement a podman backend"
Control: block -1 by -2

Hi,

On Sun, 29 Nov 2020, Johannes Schauer Marin Rodrigues wrote:
> The resulting tarball can then be used with the sbuild unshare backend. The
> only time you need be root is to execute
> 
> $ sudo sysctl -w kernel.unprivileged_userns_clone=1
> 
> But I guess you also need this for podman and buildah?

Yes.

> I'm absolutely for it! If somebody wants to implement and maintain it, please
> send patches for me to review. The person can then keep maintaining the podman
> chroot mode easily because sbuild is in the Debian group on salsa.
> 
> What I would like even more, would be to add a podman backend to autopkgtest.
> This has the following advantages:
> 
>  - it would already work with sbuild today (no changes in sbuild required)
>  - no duplicated work to have podman support in both sbuild and autopkgtest

Even better indeed, but some official way to build the container would
also be welcome... would that also be best done in autopkgtest with
a new autopkgtest-build-podman command?

Is the expectation that sbuild will use whatever "image/container/chroot"
is created by the respective autopkgtest-build- command? Or has
sbuild special requirements at this level?

Bonus point: adding this to autopkgtest means contributing Python code
instead of Perl. ;-)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Mass bugs filing: autopkgtest should be marked superficial

[Raphael Hertzog]

On Thu, 17 Sep 2020, Paul Gevers wrote:
> > And consider the case where the bug has been fixed in git but the package
> > has not been uploaded because that small change didn't warrant an upload
> > of its own. When the FTBFS bug pops up, the fix for the autopkgtest will
> > be uploaded.
> 
> For all maintainers that have done so, or something similar, by all
> means, you can lower the severity to avoid the autoremoval while marking
> the bug as pending.

Thanks, in fact I had done so for pkg-security before replying here
because I really didn't expect that this bug would be covered by
the release-team RC policy.

I just double checked that all the bugs that I lowered were marked as
pending.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Mass bugs filing: autopkgtest should be marked superficial

[Raphael Hertzog]

Hi,

On Thu, 17 Sep 2020, Paul Gevers wrote:
> This. I have written it done in response to bug [#969819]:
> 
> Notwithstanding the wording, the Release Team is happy with the bugs
> that Sudip is filing. Because of the way that autopkgtests are used in
> the Debian infrastructure to influence migration from unstable to
> testing [1], it is very important that autopkgtests are recognized for
> what they are. If an autopkgtest isn't really testing the installed
> binaries (and yes, the boundary is unfortunately not well defined) it's
> crucial that the test is marked as superficial, conform our rc_policy
> [2]. The Release Team has decided that the examples that Sudip tagged,
> i.e. --version, --help, checking for some installed file and the Python
> import check, are superficial.

That's very nice, but "superficial" has not been there from the start
so those situations are not necessarily maintainers trying to cheat
with the migration delay, and while I agree with the goal, your release
policy also says "Package are encouraged to implement autopkgtests." and
here you have package maintainers that followed early your suggestion and
that are forced to do busy-work for no gain just to add a superficial
flag.

This is demotivating. For pkg-security, I got 9 "marked for autoremoval"
mails...

Somehow we lack a way to mark a bug as "not urgent but must be fixed in
next upload".

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Mass bugs filing: autopkgtest should be marked superficial

[Raphael Hertzog]

On Thu, 17 Sep 2020, Sudip Mukherjee wrote:
> i think I will leave it for the Release Team to decide. But just
> consider the scenario when the severity of this bug for a package 'X'
> is reduced and then another FTBFS bug is raised on that same package.
> The FTBFS bug will be fixed and it will have an early migration as the
> test is not (yet) marked "superficial".

And consider the case where the bug has been fixed in git but the package
has not been uploaded because that small change didn't warrant an upload
of its own. When the FTBFS bug pops up, the fix for the autopkgtest will
be uploaded.

And if it's really something that release managers wants to enforce for
buster, the severities can be raised say 2 months before the freeze.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Mass bugs filing: autopkgtest should be marked superficial

[Raphael Hertzog]

Hi Graham,

On Thu, 17 Sep 2020, Graham Inggs wrote:
> On Thu, 17 Sep 2020 at 09:18, Raphael Hertzog  wrote:
> > Please reduce the severity of all the bugs that you opened to "normal"
> > or "minor".
> 
> Why?

Because the packages are not broken and do not deserve to be threatened by
a testing removal.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Mass bugs filing: autopkgtest should be marked superficial

[Raphael Hertzog]

On Fri, 04 Sep 2020, Sudip Mukherjee wrote:
> If the test done in the autopkgtest does not provide significant test
> coverage then it should be marked with "Restrictions: superficial".
> Ref: https://people.debian.org/~eriberto/README.package-tests.html

I agreed about those bugs being filed but I strongly disagree about the
"serious" severity that you used for those bugs. You should have mentioned
your intent to use a RC-level severity and I would have reacted.

Please reduce the severity of all the bugs that you opened to "normal"
or "minor".

Thank you.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Reaching out

[Raphael Hertzog]

Hello,

On Tue, 15 Sep 2020, Paul Sutton wrote:
> Just wondered, if it is worth me (or someone) trying to reach out to the
> team behind the Debian Administrators handbook

That would be me. :)

> I would assume we will be making use of the anyway or making references
> to this within lessons, so a quick how_to contribute, what skills are
> needed, what it it written in, for example may be useful,

https://debian-handbook.info/contribute/

> I am not sure if there is a package that just lets you write and it
> handles the xml tags in the background or you need to write this as you
> would perhaps pure html / latex / markdown and add tags manually or
> convert using something like pandoc.

I don't use any special editor. I use vim with a few shortcuts and
and a generic xml plugin.

I don't know of any opensource graphical editor for Docbook XML.

> As documentation writing is less about coding and more about writing it
> does then open up projects to a wider group of people who may posses
> those skills.  Getting documentation for any project within Debian up to
> scratch is also important, and especially if we as educators want to
> make reference to pre-existing information.

Your mail is a bit cryptic. What are you trying to do? Is this related to
the recent Debian akademy idea?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Sat, 12 Sep 2020, Sean Whitton wrote:
> There are arguments both ways here but as you're the person driving
> this, I'm still keen to hear more from you about why debian/unstable is
> to be preferred over debian/sid giving the existing convention
> established by dgit.  Thanks.

I don't have figures about their respective usage and I have no time to
look into collecting such statictics. However I have been convinced by
Simon Mc Vittie's request to document some sort of preference.

debian/unstable better matches what we put in the changelog: we
put unstable for upload to the development release (and we put a codename
for stable uploads).

debian/unstable is more expressive than debian/sid for persons who
are not very familiar with the debian release naming scheme.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: How to switch to DEP14 automatically for > 1000 existing repositories

[Raphael Hertzog]

On Fri, 11 Sep 2020, Andreas Tille wrote:
> My guess is that the Salsa API provides means to script everything.  Is
> there any existing script that supports this or is there any volunteer
> to write it.  I would start migrating Debian Med, Debian Science and
> R packaging team repositories once gbp also switched to DEP14.

The "salsa" command line tool can help. In pkg-security we have script
to apply our defaut configuration and it can rename a branch and update
HEAD.

See bin/update-repos and salsa-pkg-security.conf in
https://salsa.debian.org/pkg-security-team/pkg-security-team

Changing upstream to upstream/latest is likely not doable in a single
step however you have to go trough some intermediary branch.

(We have not followed DEP-14 in that regard yet)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Sat, 05 Sep 2020, Richard Laager wrote:
> > OK to use debian/unstable as default branch even if you are not a
> > complex package that require multiple branches, provided that you will
> > not use debian/unstable when you decide to push something to
> > experimental.
> 
> I do not see why we have to prohibit occasional uploads to experimental
> from debian/unstable. If this is permitted, then that also avoids the
> busywork of creating debian/experimental in that scenario.

To me it feels awkward to allow this. You can't really get it both ways
IMO. If you decide to use codename-based branches, then you should use
debian/experimental for an experimental upload.

What do other people think?

> > I don't think that you are wrong. Most packages definitely only target
> > unstable and never use experimental. 
> 
> Then why give up the simplicity of only one choice and the clarity (and
> tooling advantages) of debian/unstable as the typical case, in favor of
> debian/latest?

It's not clear to me that debian/latest has major disadvantages over
debian/unstable. It's a single choice too.

The "clarity" of debian/unstable is limited to Debian developers, upstream
developers might not know that unstable is the development branch. Random
outsiders neither.

And using codename by default for the development branch means that you
don't have uniformitiy across multiple vendors, which I find desirable
for the purpose of letting git packaging helper tools having a sane
cross-vendor default.

> > Another thing to take into account is that DEP-14 has been drafted
> > as a vendor-neutral recommendation. I use it in the context of Kali
> > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
> > only has codenames even for their development release.
> 
> What's wrong with kali/kali-dev?

We have kali twice in the name. We used to have "kali/stable" and
"kali/dev" at some point and we switched to "kali/master" when we
switched to a rolling-release model to standardize on DEP-14.

But what I meant is that "unstable" is only applicable to Debian and
that derivatives have different models and that we should not impose
too much to make sure we cater to the needs of derivatives too.

> I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would
> be better there. From my point of view (as someone who occasionally SRUs
> something in Ubuntu), having ubuntu/ is the right choice. When
> a new development release opens up, you would branch e.g. ubuntu/focal
> into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs
> (stable release updates). To me, my proposed branching model feels like
> it matches the Ubuntu development model 1:1.

Sure, if you put yourself in the feet of someone doing stable release
uploads, it's convenient to have a branch ready to use. But if you put
yourself in the shoes of someone doing Debian syncs, then maybe
ubuntu/latest would save you some hurdle.

In any case, Ubuntu has no "suite" name and it's to be expected that they
would use only "codename" even for their development releases. That
doesn't mean that it's the right choice for everybody nor that it should
be the default.

> DEP-14 starts this section with a broad, "In general, packaging branches
> should be named according to the codename of the target distribution."
> On that, I think we all agree. Then it continues, "We differentiate
> however the case of development releases from other releases."
> Fundamentally, the scope of that exception is what we are discussing.

Yes. (Though I would have hoped that it would not require so much
discussion at this point :-))

> Diffs available here (since this list refuses attachments and I can't
> figure out how to disable line wrapping in Thunderbird):
> https://paste.debian.net/1162793/

Bah 503 service unavailable right now.

> My personal view is now: B > A > D > C

Without having read your precise diff, I would believe my personal view
would be: C > D > B > A

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Fri, 04 Sep 2020, The Wanderer wrote:
> As long as this is being patched anyway, how about fixing the "others
> vendors" duplicate pluralization? I'd suggest either "but all other
> vendors should do so" or "as all others should do", but other variations
> are possible and I don't have a strong preference.

Fixed locally.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

(Resending without the attachment for posterity sinte the message didn't
make it to -devel, but I also had no bounce notifying me that it was
discarded...)

Hello,

On Sun, 30 Aug 2020, Richard Laager wrote:
> You could use debian/experimental all the time and then merge down to
> debian/unstable only when you're ready to upload and have chosen
> unstable. But I suspect your objection would be: that's unnecessary
> busywork. And I see that point. I would probably make the same
> objection, which means I think I agree with the debian/latest concept in
> your situation.

You perfectly understood my reasoning. Thank you for making that effort.

> I'm not sure if most package maintainers are doing this or not. I've
> always assumed that most people are targetting only unstable most of the
> time and that use of experimental is relatively rare. I could easily be
> wrong on that.

I don't think that you are wrong. Most packages definitely only target
unstable and never use experimental. 

But most packages also never need to maintain two development branches
in parallel. Only very big packages, linux or django for example, will
maintain different upstream versions in two parralel branches.

Another thing that's quite certain is that you never know what the future
will bring you. And while you never had to use experimental, you might
have to at some point.

In that sense, I find debian/latest more future-proof but I also
agree that for the few cases where we would have to use experimental,
it's not a big deal to have to create debian/experimental.

Another thing to take into account is that DEP-14 has been drafted
as a vendor-neutral recommendation. I use it in the context of Kali
and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu
only has codenames even for their development release.

Thus /latest is a better default for tools like git-buildpackage
and it makes sense for DEP-14 to endorse such a default branch as the
recommended name.

> That is, I'm generally always targetting unstable and _not_ regularly
> using multiple releases, so the DEP-14 language "prohibits" me from
> using debian/unstable. This is what feels backwards to me. If I'm always
> targetting unstable, debian/latest (and previously debian/master) is
> less clear than debian/unstable.
> 
> At a minimum, can we rework this in some way so the language does not
> require me to be regularly using multiple releases to use
> debian/unstable as a branch name?

That seems entirely reasonable, yes. Can you try to make a proposal ?

I attach the current markdown file with my not-yet pushed change that I
submitted for review here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Fri, 04 Sep 2020, Paride Legovini wrote:
> As the name of the development branch is not specified anymore, should dep14
> ask for it to be the repository default branch? Otherwise there's no safe

I took this as granted. But maybe we should make it explicit, yes. I also
clarified that those recommandations are really for the cases where you
mix upstream development and Debian packaging in the same branch. I can
imagine someone picking 3.0 (native) packaging but keeping a separate
"main" branch with only upstream code and hosting packaging in
debian/latest...

So here's my counter proposal:

--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -201,12 +201,16 @@ Native packages
 
 The above conventions mainly cater to the case where the upstream
 developers and the package maintainers are not the same set of persons.
-
-When upstream is Debian (or one of its derivative), the upstream vendor
-should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch does not have to be named after
-the codename of the target distribution (although you are free to still
-use the codename if you wish so).
+By contrast, this section applies to native packages where upstream is
+Debian (or one of its derivatives) and where the packaging and upstream
+source code are managed in the same branch(es).
+
+In that specific situation, the upstream vendor should not use the usual
+`/` prefix for their branches and tags (but all others vendors
+should do so) and they also don't have to follow the usual naming
+conventions for packaging branches (although they are free to do
+so if they wish). However the default branch of the repository (as pointed
+by the HEAD reference) should be a development branch.
 
 When the package is shipped as a native source package (i.e. a single
 tarball with no differentiation of the upstream sources and of the

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hi,

On Mon, 31 Aug 2020, Paride Legovini wrote:
> A tl;dr version of my idea is: let's remove the special treatment for
> development releases, treating e.g. debian/unstable like a stable
> release. Optionally use a 'debian/devel' branch for development work.
> The only "workflow" bit is: if you work on debian/devel, merge your
> changes to debian/unstable before uploading.

I understand this but you are imposing usage of multiple branches to some
persons who are happy to have a single branch alternating between unstable
and experimental. I don't want to go that extra mile. In particular
because this requirement has other drawbacks that you didn't list:

You hardcode the name of the Debian development release while I would
like DEP-14 to result in changes to packaging tools that can be useful
across multiple distribution vendors. And while tools can easily query
`dpkg-vendor --query vendor` there's currently no simple way
for a tool to learn the codename of the development release.

Thus I stand on the opinion that we need to have a generic name for the
default development branch. We can accept use of alternate default
branches, for those who have strong opinions in that direction, but the
default recommendation should be some generic name.

> (Could be made more generic by recommending optional branches named:
> 
>   - //devel
> 
> for development, to be merged to
> 
>   - /
> 
> before uploading. But this is probably overkill.)

That would not work. git is not allowing you to have those two branches at
the same time. A given path can't be a branch and a directory at the same
time.

> > We want to document what we can expect when you have debian/latest
> > and what you can expect when you have debian/unstable.
> 
> On this point: should there be a way for a package to declare its
> packaging repository follows dep14?

What would we gain from this?

> And you are right, however I think the current wording may be partially
> missing the opportunity to set stronger expectation of what is to be
> found in a Debian packaging repository in terms of branches, which is
> what my comment is about.

I'm trying to bring this DEP to some conclusion and I'm not going to
extend its scope.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Mon, 31 Aug 2020, Paride Legovini wrote:
> What I propose is to require for dep14 compliance that uploads to
>  are to be cut from debian/ branches, unless
>  is experimental. This allows to checkout the "maintainer
> view" of a given (nonexperimental) version of a package by knowing only:
> 
>  - the repository location
>  - the relevant d/changelog entry.

You are asking for more than what DEP-14 is trying to achieve.

DEP-14 does not mandate any specific workflow, it mainly tries to
stantardize the branch names for the various cases that we have.

We're not trying to impose one workflow or the other. So it's not
debian/unstable vs debian/latest. We want to document what we can
expect when you have debian/latest and what you can expect when
you have debian/unstable.

> This automatically allows:

I don't think that anything in the current wording is forbidding
anything that you list.

I already agreed that we can tweak the wording to document that it's
OK to use debian/unstable as default branch even if you are not a complex
package that require multiple branches, provided that you will not
use debian/unstable when you decide to push something to experimental.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Accepting / adopting DEP-14

[Raphael Hertzog]

On Sat, 29 Aug 2020, Emmanuel Arias wrote:
> DEP-14 will recommend the use of debian/latest  for a package uploaded
> to sid/unstable?  or debian/latest is a pre work before uploaded to
> sid/unstable?

It is to be expected that debian/latest keeps switching between different
states:
- in sync with sid
- in some "develop/test/pre-work" state (as you put) because you are
  working on a new uptsream release
- possibly in sync with experimental for a short while

> So, I think  would be a good recommendation to use debian/latest as a
> default branch for "develop" reasons, then when the package is ready to
> upload move that change to other branch debian/experimental, debian/sid,
> etc..

Multiplicating the branches has a (cognitive) cost and should only be done
for a good reason.

You can surely have a private "develop" branch if you want but there's no
point to have so many branches if you are not actively maintaining all
those versions in parallel.

The point of debian/latest is to accomodate for the case where you are
usually not actively maintaining multiple versions in parallel.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

On Sat, 29 Aug 2020, Richard Laager wrote:
> That said, I do understand we give a lot of deference to developers'
> workflows. So I have no objection to DEP-14 supporting this workflow
> with debian/latest. But I would like to see it (debian/latest)
> recharacterized as the alternate approach rather than the recommended
> method.

Your approach is perfectly valid but I don't really believe that it should
be the recommended approach. It doesn't seem to match the most common
workflow.

Most package maintainers are not actively working on two different
development branches, instead the single development branch keeps moving
between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- possible upload to experimental to gather feedback (buildd, users)
- back to ready for upload to unstable

In some rare cases, we will have to do some intermediary upload to
unstable because some RC bug popped up and we don't want to wait until
we're ready with the next upload. In that case, we will create a
debian/unstable branch starting from the last tag in debian/unstable.

IOW, while branches are cheap, I create them on request only when I need
them, I'm not using multiple branches until I have a real need for it.

But I might also do the opposite. If I know that the next upstream release
breaks backwards compatitibly and that it will have to mature a long time
in experimental until all other packages are ready, I might start to
package it rigth now in debian/experimental and continue to use
debian/latest for my unstable uploads.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Accepting / adopting DEP-14

[Raphael Hertzog]

On Wed, 26 Aug 2020, Geert Stappers wrote:
> On Wed, Aug 26, 2020 at 06:08:17PM +0100, Simon McVittie wrote:
> > On Wed, 26 Aug 2020 at 16:00:02 +0200, Jonas Smedegaard wrote:
> } }  [  ... good input ... ]
> 
> How to go from good input to accepting DEP-14 ?

FWIW I fully agree with Simon. The choice offered in DEP-14 is to accomodate
different workflows, not for the pleasure of allowing multiple names.

Since the choice between debian/master, debian/latest, debian/trunk,
debian/main, debian/devel is a matter of personal preference, we could
likely setup some (condorcet) poll among developers and just pick one.

But given that we recommend upstream/latest for the upstream branch, I'm now
leaning towards using debian/latest as default as well. I'll make a
concrete proposal and we'll see the feedback.

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

RFC: Final update of DEP-14 on naming of git packaging branches

[Raphael Hertzog]

Hello,

following the recent discussions of June and of the last days, I'm
proposing the changes below to DEP-14. Basically it replaces debian/master
with debian/latest for all the reasons already discussed earlier. And
it says that debian/unstable is preferred over debian/sid.

And it also marks the proposal as ACCEPTED given that it has gained
traction over the years and that we didn't feel the need to make
significant change to it.

I'm proposing debian/latest now because DEP-14 is already recommending
upstream/latest and that makes the result a bit more consistent. But if
enough person disagree with this choice, we can look into setting a poll
to choose among all the names proposed so far.

Let me know your thoughts:

diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
index 0316fe1..beb96ea 100644
--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -2,11 +2,11 @@
 
 Title: Recommended layout for Git packaging repositories
 DEP: 14
-State: DRAFT
-Date: 2016-11-09
-Drivers: Raphael Hertzog 
-URL: http://dep.debian.net/deps/dep14
-Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
+State: ACCEPTED
+Date: 2020-08-29
+Drivers: Raphaël Hertzog 
+URL: https://dep-team.pages.debian.net/deps/dep14/
+Source: 
https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep14.mdwn
 Abstract:
  Recommended naming conventions in Git repositories used
  to maintain Debian packages
@@ -92,24 +92,28 @@ For development releases
 
 
 Packages uploaded to the current development release should be prepared
-in a `/master` branch.
+in a `/latest` branch.
 
 However, when multiple development releases are regularly used (for
 example `unstable` and `experimental` in Debian), it is also accepted to
-name the branches according to the codename or the suite name of the
-target distribution (aka `debian/sid` or `debian/unstable`, and
-`debian/experimental`). Those branches can be short-lived (i.e. they exist
-only until they are merged into `/master` or until the version in
-the associated repository is replaced by the version in `/master`)
-or they can be permanent (in which case `/master` should not
-exist).
+name the branches according to the suite name of the
+target distribution (aka `debian/unstable`, and `debian/experimental`).
+Those branches can be short-lived (i.e. they exist only until they are
+merged into `/latest` or until the version in the associated
+repository is replaced by the version in `/latest`) or they can be
+permanent (in which case `/latest` should not exist).
+
+In the interest of homogeneity and of clarity, we recommend the use of
+`debian/unstable` over `debian/sid` as it better conveys its special nature
+as opposed to other branches named after codenames which are used for
+stable releases.
 
 NOTE: If the Git repository listed in debian/control's `Vcs-Git` field does
 not indicate an explicit branch (with the `-b ` suffix) then it should
 have its HEAD point to the branch where new upstream versions are being
 packaged (that is one of the branches associated to a development release).
 The helper tools that do create those repositories should use a command
-like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD
+like `git symbolic-ref HEAD refs/heads/debian/latest` to update HEAD
 to point to the desired branch.
 
 For stable releases
@@ -200,7 +204,7 @@ developers and the package maintainers are not the same set 
of persons.
 
 When upstream is Debian (or one of its derivative), the upstream vendor
 should not use the usual `/` prefix (but all others vendors should
-do so). The main development branch can be named `master` instead of
+do so). The main development branch does not have to be named after
 the codename of the target distribution (although you are free to still
 use the codename if you wish so).
 
@@ -293,3 +297,6 @@ Changes
 
 * 2014-11-05: Initial draft by Raphaël Hertzog.
 * 2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson.
+* 2020-08-29:
+  * Replace debian/master with debian/latest
+  * Recommend debian/unstable over debian/sid
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Accepting / adopting DEP-14

[Raphael Hertzog]

Hi,

On Mon, 24 Aug 2020, Geert Stappers wrote:
> The good things of https://dep-team.pages.debian.net/deps/dep14/ are in use.
> But https://dep-team.pages.debian.net/deps/dep14/ it self looks abandonned.

Why are you saying that?

> What is needed to official accept DEP-14?
> (and to give https://dep-team.pages.debian.net/deps/dep14/ status "adopted")

We could just mark it as accepted but then there's the naming issue that
was recently discussed.

https://lists.debian.org/debian-devel/2020/06/threads.html#00158
https://lists.debian.org/debian-devel/2020/06/msg00158.html

That discussion had no clear outcome and it would be nice to
tackle this before marking it as accepted.

My conclusion of that thread is that we would like to change to something
else but it was not clear what upstream git was going to use as default
name and that we should possibly better wait until we know more... that
said, re-reading the archive, some sort of rough consensus could emerge
for using debian/devel instead of debian/master.

Do we know more in between? How will git handle this transition?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: [Summary]: RFC: Standardizing source package artifacts build paths

[Raphael Hertzog]

On Sat, 02 May 2020, Scott Kitterman wrote:
> Personally, I don't see any real benefit of standardizing on (making up an 
> example here) debian/.build over debian/build.

Same here. The arguments against debian/build are very weak. If we care
about a source package building a binary package named "build" or
whatever, it's really a unique case and surely it can be built with
some overrides and passing a different path where needed.

There's also the precedence of debian/source that has taken over a part of
the namespace below the debian directory.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Raphael Hertzog]

Hi,

On Mon, 30 Mar 2020, Didier 'OdyX' Raboud wrote:
> > How should package maintainers deal with QR codes ethically?
> 
> Asking package maintainers to rebuild functionally-equivalent QR-codes during 
> the build-process seems entirely reasonable to me.

To me it looks like wasting my time. There are many pictures that are
not the preferred form of modification but we accept them as is when
there's no proof/evidence that some other source exist.

And here there's no other source really, the source is the string
associated to the QR code. QR code and the string are two different
representation of the same underlying data.

I don't see what it buys us to regenerate the picture during the build
process. Yes you gain the ability to change it, but changing it is not
really nice to the upstream developer (and changing the picture is as easy
as changing the source URL in debian/rules). And on the opposite, if upstream
changes the link, the you break it without noticing (unless you put even
more code to first extract the link from the picture and then re-encode
it).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: migration from cron.daily to systemd timers

[Raphael Hertzog]

On Wed, 08 Jan 2020, Daniel Leidert wrote:
> > This strikes me as clutter that will never be removed from debconf, so
> > let's not decide to do that for every package that might need a timer.
> 
> Why should this question ever been removed? What is your goal? Getting rid of
> cron-jobs?

The question is not yet added. We should ask ourselves if it's actually
useful before adding it. Is the feature important enough to ask 50+
translators translate a question on whether the user prefers to use cron
or systemd to run some periodic checks?

My answer is no. Yours is apparently yes.

> > How about modifying the shipped /etc/default/spamassassin to include a
> > comment explaining what's going on, and how to enable the timer instead?
> > 
> > Anyone who's set CRON=1 will then get warned about the maintainer's
> > modified version, which should catch their attention.  Everyone else
> > will get a handy hint about the new setup if they ever go to set CRON=1
> > in future.
> 
> And what s the benefit of this change: Getting rid of cron?

He explained the benefits. Informing users who care enough to look
into the relevant configuration files and/or those who modified the said
files, without annoying everybody else with a question that they don't
care about.

> The very simple thing is: CRON=1 enables a cron job. It does *not* say: 
> "Please
> enable something different as long as it achieves the same." There is nothing
> wrong with the cron job and it works perfectly fine. So I don't want to have 
> it
> replaced by something less transparent.

This is the third time that you are saying this in this thread. Please let
others disagree with you without repeating yourself.

FWIW, I agree with other that CRON=1 really means that the use desires to
have the periodic check running. I also agree that a debconf prompt is
overkill for this choice.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Sat, 28 Dec 2019, Alexander Wirt wrote:
> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> 
> > Hello!
> > 
> > I've seen many times before statements like these so I'd like to raise
> > some discussion around the topic:
> > 
> > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > The Salsa CA pipeline is recommended.
> > >
> > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > have to work through too much problems first.
> The salsa ci pipeline itself has some problematic implementation details
> waldi lined out in the past. Afaik nothing changed, we had several reports

This is not really true:
https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi

Out of 12 issues reported by waldi, 8 have been fixed/closed.

Among the remaining ones:

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
  (usage of LXC for autopkgtest)
  is likely the most problematic one even though you never explained
  what's the real issue... yeah it's virtualization over virtualization
  and it downloads a root tarball to do its work, but is this worth than
  downloading a docker image? It uses more resources than direct execution
  of autopkgtest but it hasn't broken anything so far?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/94
  (docker images accumulating in forks)
  this one should have improved a lot AFAIK as GitLab now supports what's
  required to remove images from the CI environment too and there's
  WIP on that front (it might even be live without anyone updating that
  bug, I'm not sure)

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/116
  This one is not clear to me. What jobs are using "docker-in-docker"
  without any legitimate use ?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/121
  (split into source and build)
  This one seems like wishlist and has no real impact on resources as long
  as we build for a single architecture...

> where people telling us things are not possible on our runners. In the end
> most of them turned out to be limitations of salsa ci. Salsa ci is also
> not very efficent, therefore the veto. 

Claims like "salsa ci is not very efficient" are not actionable. Bugs like
those above are more useful but you should at least take the time to
respond to queries of people, otherwise no progress can be made.

I don't think that salsa-ci is particularly problematic in terms of
"efficiency". With the exception of the LXC usage, there's not much
that can be "cut" to save resources.

> We are working on it and after my holidays are over I will plan another
> sprint for improving salsa. 

\o/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> I am sure there are many ways to help the team and it is not just
> about Salsa/Gitlab admin stuff, but also about creating structure in
> the team, triaging issues, spreading best practices for users and
> helping the most advanced users to grow into admins of Salsa etc.
> Right now we don't even have any kind of salsa-related discussion list
> on lists.debian.org. Thus I wanted to raise discussion on
> debian-devel. In my opinion Salsa is becoming a very central piece of
> the Debian infrastructure and it should have more attention on
> debian-devel and from the project leader.

+1 on everything you said. (And IMO you should have started a new thread
instead of replying to an old one)

I do hope we can find some constructive way to go forward because the current
settings are now too strict and are effectively hindering big packages
(exactly those that need help!) and some other advanced use of the
service.

I would also like to mention that we should have #salsa or #debian-salsa and
drop #alioth on IRC, sure it made sense at the start to continue to use
the same place as where we used to be but now it just makes it harder
to find the correct place to discuss issues with Salsa.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Namespaces for Lintian Tags

[Raphael Hertzog]

Hi,

On Wed, 20 Nov 2019, Felix Lechner wrote:
> There are many motivations:

Among those motivations, which one is the one that triggered this process
and which one are there as "additional benefits" that you could identify
to justify the change?

> 1. Shortens tag names.

I don't see that as a benefit, we copy/paste the tags into overrides
or full lines into lintian-info. We rarely need to type them.

> 2. Points to the code that issued the tag.

"grep -r" on the codebase has been working well for me. This mapping
is only really needed when you want to dig into the code anyway.

> 3. Frees up name space (good tags are rare).

Can you show examples of how this would help you concretely?

I have a hard time seeing how difficult it can be to invent
a new name for a new tag.

> 4. Multiple checks can use the same tag in different contexts (i.e. 
> 'spelling').

spelling-error-in-binary
spelling-error-in-description
spelling-error-in-changelog
etc

is perfectly fine.

> 5. Preempts name conflicts in case some check-writing is delegated to
> expert teams.

This is not a real problem, that's the kind of pseudo-benefit that you
try to imagine to justify the change that you want (I have done
that many times ;-)).

> 6. Quicker to split large checks when components reuse tag names.

I don't follow you. For me splitting checks means they get renamed and
thus your tag names are renamed too.

> 7. Brings consistency between Lintian and custom profile users, such
> pkg-perl-tools and pkg-js-tools, who already have private namespaces.

A very minor benefit IMO.


Now can you do the same analysis with the disadvantages?

Since the check is embedded in the tag name:
* It's harder to move a tag from one check to another.
* It's harder to rename a check.

What else can you come up with?

> The change is technically easy. (Lintian even has a way to track
> renamed tags for overrides.) On an optical level, however, the change

I was about to ask for overrides, but this would be a massive usage of
this rename feature and it will confuse many persons. People will start
to use the new name in overrides to avoid this confusion and it won't work
with old lintians (not a big deal but still).

> will affect a lot of people. It could even cause headaches for some
> users, for example in derivatives. We would like to solicit your
> input.

What kind of headaches are you referring to?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

[Raphael Hertzog]

On Tue, 08 Oct 2019, Holger Levsen wrote:
> On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote:
> > [...] as a last opportunity for
> > others to comment. 
> 
> what's the deadline to grok this 20k and respond?

It's in the subject: [comments by 11/05/2019]

November 5th.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Git Packaging: Native source formats

[Raphael Hertzog]

Hi,

On Wed, 28 Aug 2019, Sam Hartman wrote:
> Internet is faster and disks are cheaper.

I'm not sure that DSA (which is maintaining snapshot.debian.org) will
be happy with this assertion.

> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows.  It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream  versions  are the same.
> You don't need to synthesize a separate upstream tarball.

Do we really care about this if we assume that this work can be
transparent to the maintainer and entirely handled by tag2upload
(or some other equivalent service)?

It has all the information required to be able to build something
reusing an upstream tarball. It can:
- pick a pre-existing tarball if already in the archive
- pick the upstream tarball via the watch file
- pick the output of "git archive"

If there are still differences due to the use of an external tarball, it
can generate a supplementary patch to bring the content in line with the
content in the git repository.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: tag2upload service architecture and risk assessment - draft v2

[Raphael Hertzog]

Hi,

I reviewed the whole thread and the point of friction is the requirement
to sign the .dsc file to make sure that the source package matches what
the maintainer intended to upload. Ian doesn't want the maintainer to have
to deal with the .dsc and the ftpmasters wants to have a signature within
the archive to verify that the code that we build is the code that the
maintainer wanted to ship.

I have a proposal to get out of this impasse.

1/ When the maintainer generates the git tag, he will sign the tag
   but he will also sign the output of "git ls-tree -r HEAD"
   and that signature is stored in the tag long description.

   This signature will be the basis of the trust that ftpmaster are
   looking for.

2/ tag2upload constructs a .dsc that embeds a new field where the
   output of "git ls-tree -r HEAD" is provided (let's call it "Content")
   and a second field with the signature of the maintainer (let's call
   it "Content-Signature"). tag2upload signs the .dsc as a whole with
   its own key.

3/ "dpkg-source -x" is modified to remove any file that does not appear
   in the "Content" field. It could warn about missing files too (and maybe
   silently ignore for a few common files that are usually not part of the
   "make dist"). It could also verify the checksums and complain if they
   don't match.

4/ dak is modified to also verify the signature in "Content-Signature"

5/ profit, everybody should be happy.


Comments are welcome, obviously.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: salsa.debian.org partially down

[Raphael Hertzog]

On Fri, 16 Aug 2019, Alexander Wirt wrote:
> I am a bit surprised, from the first day on we said that there are limited
> ressources for ci and that you should be nice to the service. Thats even
> documented: 
> 
> "We mean that. Really. Be nice to the server. At some point in the future we 
> hope to add some dedicated Runners servers - Sponsors welcome! ;)"

And in the same message, you mention that you are looking for sponsors to
get more resources... so you clearly did not shut the door to grow the
service and I thank you for that.

I understand it's not always as easy as throwing additional resources on
it... otherwise it would not be a problem. You would not have too much
trouble to get more resources.

I saw an offer in this thread
(CAMr=8w4ArFb_rdAqr60U5zYuqwEFLbvGgj=scxflug9yfh+...@mail.gmail.com from
Aron Xu) and I also saw the discussion on IRC
suggesting that we should spend the money we got donated to actually buy
hardware we need. And I'm sure that a public call for sponsors would
get some significant results as well.

> And we mean it that way, so don't be surprised if we tell you that you
> overload things.

I'm not surprised, I learnt to expect it from you ;-)

> We are always improving things, but anyhow, there are
> limits - as it is for every other service within debian. 

Indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Raphael Hertzog]

On Wed, 14 Aug 2019, Sam Hartman wrote:
> Regardless of anything they are doing with Git, maintainers of a package
> are expected to process patches sent to the BTS.

Yes.

> You cannot respond to a patch telling someone they need to file a merge
> request to have it considered.

I would not hesitate to suggest it however... it would give me immediate
feedback on whether the package still compiles, on whether the testsuite still
passes, etc.

That in turn means that I'm more likely to process said patch in a timely
manner...

> Unmonitored Merge Requests Harmful
> ==

Ack.

> VCS Packaging Info
> ==
> 
> If you have a public repo then you should use vcs-git and vcs-browser.
> I'm reasonably sure this is even already well documented.

Ack.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Raphael Hertzog]

On Thu, 15 Aug 2019, Russ Allbery wrote:
> Jonathan Carter  writes:
> 
> > The Debian QA DDPO pages will show you whether you have MRs on the same
> > page where you see how many open bugs, RC bugs, lintian errors, etc you
> > have. This makes it super easy to notice MRs when doing routine checks
> > of your general package health overview.
> 
> Is there some way for me to get email when there's a new MR, the way that
> GitHub does?

Sure, you just need to configure your notification level for the group or
the project that you want to get notifications. The default is "Global"
(which equates to the global default setting which usually is
"Participate") and you want to change it to "Watch".

https://docs.gitlab.com/ce/workflow/notifications.html#project-settings

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Building GTK programs without installing dconf-service?

[Raphael Hertzog]

On Fri, 16 Aug 2019, Simon McVittie wrote:
> If there *is* consensus that "don't lose user configuration" is less
> important than "weaken dependencies where possible", then that's a good
> reason to weaken the dependency, although in practice that is likely to
> be wontfix until dh_installgsettings can do it. As far as I can tell,

FWIW, I don't think there's any such consensus... that whole thread seems
very futile to me and I almost skipped it right from the start because
it was started by someone unhappy with systemd who should just use chroots
or containers or VM to build and accept to have systemd-sysv installed in
a build chroot (even if he doesn't want to have systemd as its init on
his server).

I'm pretty happy that you are always willing to investigate thoroughly and
see if we can improve, but you justified all the relationships properly
and I think that we can stop here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: salsa.debian.org partially down

[Raphael Hertzog]

Hi,

On Fri, 16 Aug 2019, gregor herrmann wrote:
> From what I know, this what not a "foolish user action" but an action
> by a dedicated maintainer who enabled salsa-ci for all packages
> ("projects") of a specific team; so they used a service advertised by
> the salsa and salsa-ci teams. That this service doesn't work as
> advertised or at least doesn't work for the amount of packages a
> medium-sized team might have is deplorable and needs some action but
> I don't see any reason for calling this action itself foolish.

+1

FWIW, I did the same for Kali linux on 500 packages which are
hosted on https://gitlab.com/kalilinux/packages/ and it generated that many
pipelines as well without any significant issue.

Obviously, gitlab.com has certainly much more resources behind it
than salsa but I believe that we should be able to just do that without
bringing salsa to its knees. It's quite common to do mass-update to many
repositories with "mr" and that would generate just as many pipelines
too.

I understand that the Salsa admins will have to find ways to grow the
available resources and so far they did a very good job on this level,
(except the part where they always express their grumpyness in a way that
is hostile to many users) so I'm confident that they will find solutions.

They already moved most of the work to external Google VM to make the service
scale (at the start it was running entirely on the few dedicated
runners). Same for storage of many artifacts/log files.

When we looked into replacing FusionForge, GitLab was not necessarily
their preference (at least for formorer IIRC) but they listened to the
feedback from DD on this level and it's pretty clear (at least to me)
that the GitLab CI features are the reason why many DD voted for GitLab.

So, indeed, we should not blame users because they enable CI, we selected
GitLab because of those features.

In summary: thank you Salsa admins and keep up the good work! (And try to be
less grumpy)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab

[Raphael Hertzog]

Hi,

On Thu, 01 Aug 2019, Domenico Andreoli wrote:
> >Questions to be answered:
> >- Is the setting only a default applied to new projects?
> >- If yes, how do you inform users that a new project with
> >  /.gitlab-ci.yml will not work?
> >- If no, how do you inform users that an existing project with
> >  /.gitlab-ci.yml will stop working?
> 
> I don't like any of these questions, I would prefer not having to answer to 
> them.

The first question seems a legitimate question in order to evaluate the
impact. I guess however that the setting is a default applied to all
(existing) projects that have not overridden the setting.

IOW, changing the value will break legitimate users of .gitlab-ci.yml.
I am such a user for the "distro-tracker" and "debian-handbook"
repositories. And I will have to reconfigure my projects, but I also agree
with the request expressed here. It is much more painful to have
to reconfigure this for all the other packaging repositories that
we regularly create...

To the second question I would say that it's enough to document it
in the wiki where all other salsa-specific documentation is.

To the third question, I would say that an email to debian-devel-announce
ought be enough.

> Having a salsa global default different from the gitlab one is just
> surprising indeed, would "patch in" a solution for a quite specific case
> (plain debian package with default salsa-ci.yml) and would still leave
> diverging settings dead in the water at first clone.
> 
> I did not follow most closely this thread, is setting cloning being explored 
> already?

Filed upstream already:
https://gitlab.com/gitlab-org/gitlab-ce/issues/48180
https://gitlab.com/gitlab-org/gitlab-ce/issues/64805

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab

[Raphael Hertzog]

Hi,

On Thu, 25 Jul 2019, Daniel Leidert wrote:
> it has become quiet around this issue. So if you think such a configuration
> option is useful too please support
> 
> https://gitlab.com/gitlab-org/gitlab-ce/issues/41764

I added my +1.

Another request that is important to have proper CI result in merge
requests are those two (they are duplicate really but got triaged
differently):
https://gitlab.com/gitlab-org/gitlab-ce/issues/48180
https://gitlab.com/gitlab-org/gitlab-ce/issues/64805

Go ahead and add thumbs up! ;)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: git & Debian packaging sprint report

[Raphael Hertzog]

On Sun, 21 Jul 2019, Ian Jackson wrote:
> IME as a sponsor I get (AFAICT) no mails as a result of my sponsorship
> signatures so I think there are few automatic processes.

That's actualy not true, dak is sending mails to the person who signs the
upload when it has to send mails like NEW notifications, etc.

> Hrm, I think tracker may become confused.  It seems to be looking at the
> .dsc signatur.  So maybe the .dsc field is indeed needed.

Yes, definitely. 

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: default firewall utility changes for Debian 11 bullseye

[Raphael Hertzog]

Hi,

I'm replying to your questions but I have also other questions related to
this fresh transition...

On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote:
> as you may know, Debian 10 buster includes the iptables-nft utility by 
> default,
> which is an iptables flavor that uses the nf_tables kernel subsystem.
> Is intended to help people migrate from iptables to nftables.

It is intended that /proc/net/ip_tables_names and
/proc/net/ip6_tables_names is always empty when you use iptables-nft and
thus nf_tables under the hood?

This is breaking fwbuilder at least: 
https://github.com/fwbuilder/fwbuilder/issues/88

> Also, I believe the days of using a low level tool for directly configuring 
> the
> firewall may be gone, at least for desktop use cases. It seems the industry 
> more
> or less agreed on using firewalld [2] as a wrapper for the system firewall.

What would/should Debian recommend to configure the firewall on the server
case ?

I was recommending creating firewall rules with fwbuilder up to now (see
https://debian-handbook.info/browse/stable/sect.firewall-packet-filtering.html)
but while it's still maintained, it has not had any recent release
and still hasn't native nftables support
(https://github.com/fwbuilder/fwbuilder/issues/17).

> This email contains 2 changes/proposals for Debian 11 bullseye:
> 
> 1) switch priority values for iptables/nftables, i.e, make nftables Priority:
> important and iptables Priority: optional

Ack.

> 2) introduce firewalld as the default firewalling wrapper in Debian, at least 
> in
> desktop related tasksel tasks.

No objection. I think it's high time we have some default firewall
installed in particular with IPv6 getting more widely deployed...

The other desktop firewall that I know is "ufw" but it doesn't seem to
have any momentum behind it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

[Raphael Hertzog]

On Tue, 09 Jul 2019, Simon Richter wrote:
> Your proposal of generating some of the fields doesn't affect the API
> itself, as long as the fields are populated at the right time. We don't
> have a mechanism for updating the control file at build time, because any
> part of the build process that would be able to do so is after the part
> where the control file is consumed for the first time, so it would give an
> inconsistent view.

On a somewhat related topic, I filed this wishlist bug a long time ago:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597340

The idea is to have implicit substvars at the end of every field so that
you can extend the content of the field, and possibly introduce fields
that are not present in the original source tree.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Question about Debian build infrastructure

[Raphael Hertzog]

On Wed, 12 Jun 2019, Vincent Bernat wrote:
> It's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623
> 
> Maintainer doesn't seem to be interested or have no time to consider the
> patch since many years.

Another sticking point with reprepro is the lack of Acquire-by-hash
support:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820660

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

[Raphael Hertzog]

Hi,

On Mon, 03 Jun 2019, Paul Wise wrote:
> There are a few things that are possibly concerning:

Thanks for sharing those. Let me answer them.

> Freexian is essentially the only available-to-hire provider of
> services for Debian LTS, as the Freeside link doesn't lead anywhere
> useful. This means that Freexian essentially does not have any
> competition in the provision of these services. Individuals or
> companies who don't like Freexian's offering do not have any other
> choices, short of going to the general Debian consultants list, who
> may or may not have the needed skills and would take time to search
> through.

That's correct. But the agreement was always that the relationship
was non-exclusive from the Debian point of view. I.e. someone else
could setup "Debian LTS by " and Debian would not endorse one more
than the other.

> The funding breakdown for the LTS team appears to be 48% Freexian, 31%
> volunteer/unknown, 21% other companies. I don't have any data on the
> proportion of LTS work done by each of these groups, but I get the
> feeling that the majority of LTS uploads are done by Freexian folks.

That breakdown does not reflect reality at all. Indeed the vast majority
of the work is done by contributors paid by Freexian.

> This means that if Freexian decides to end its provision of services
> for Debian LTS, then the level of work done for LTS would go down
> significantly. Were this to happen, it would either significantly
> damage the image of Debian due to having to end the LTS effort or
> require us to do work which we have had a hard time finding volunteers
> for in the past.

That's correct. However, there's no reason for this to happen. I do care
about Debian and the uninteresting paper work that I have to do to keep
the Freexian service running is paid for.

That said there are multiple ways to avoid this:
- Debian organizes this by itself (it's possible, the criteria I use
  to allocate work hours to contributors are relatively transparent)
- Debian defines clear rules for external services leveraging the Debian
  name to fund Debian-related work and encourages to have more of those

> There is strong coupling between Debian and Freexian in the language
> on the Debian LTS pages and the Freexian pages. This is free
> advertising for Freexian's LTS services and representing Freexian's
> LTS services as "blessed" by Debian or somehow "official", which could
> be objected to by other companies who might decide to provide security
> support services. It may be prudent to remove or alter the language on
> the Debian LTS pages.

I don't see the need to act pro-actively here. The current description
is a fair representation of the reality. It might not be the ideal
situation that we want for Debian but then again I suggest we work on
defining criteria for all services/companies that would aim to have the
same kind of "Debian blessing".

> LTS. This means that the individuals/organisations doing consulting
> around Debian miss out on the opportunities to work on LTS.

This is not true. Many have joined the set of contributors paid by
Freexian. Some of the contributors are working as individuals
(freelancers) and others as members of an organization that invoices
Freexian (Codethink for Ben Hutchings for example).

You are saying that they don't have an opportunity to work on LTS
outside of Freexian. That's also not true but the easy path is
definitely to go through Freexian who has an established situation
and whose join rules are open-enough to avoid the need to create
a competitor.

> Freexian doesn't fund LTS contributors who are not DDs/DMs: this
> eliminates skilled developers from outside Debian who could contribute
> to LTS via Freexian and eventually work on Debian more generally. This
> seems to have prevented at least one former Debian member who was
> interested in Freexian's offer from contributing. It might also make
> LTS funding seem like a reward for Debian insiders.

Or it creates an incentive to contribute to Debian to be able to join
the set of paid developers.

I'm sorry that you see this as a problem. This job is about contributing
to Debian and we need persons who already know how to do this. Contrary to
GSOC and others, our purpose is not to train outsiders to contribute to
Debian.

> The structure of using existing Debian contributors and funnelling
> most of the funding to them through one company reduces incentives for
> companies wanting security support to direct their employees to work
> on Debian security support. This means that our contributor base stays
> more static and reduces the chance that new folks will join us. An
> alternate model where each of the companies currently sponsoring
> Freexian LTS services instead directed their employees to spend some
> hours on Debian security support seems more likely to lead to new
> people getting involved.

I certainly agree that the efficiency of the contributors paid by Freexian
means that companies 

Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Raphael Hertzog]

On Wed, 29 May 2019, Ansgar wrote:
> On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > > One of the popular answers to this and some other problems is "nobody sat
> > > down and wrote the code". Not sure what can we do about this class of
> > > reasons.
> > 
> > Use the $300,000 on our bank accounts?
> 
> I heard that this didn't work out well the last time ("dunc tank"),
> though that was before the time I followed Debian development.

Yes, I was there (and mention it briefly in the questions of the talk I
gave) but it's been a long time ago. There are things to learn
from this failed experiment (such as "don't let the DPL decide alone who
gets paid") but there are also many reasons to believe that we are no
longer in the same situation. At that time, the number of persons working
on open source as part of their paid work was rather low and the jealousy
aspect was likely more problematic than it would be today. We have been
getting used to have Debian contributors being paid (such as on LTS) and
we know that with appropriate rules, the social impact of the use of money
is acceptable.

The topic still needs to be approached carefully but I believe that we
should aim to have this discussion and build some framework where we can
leverage money to complete projects and tasks that we find important
but that have not gone forward through volunteer work.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

[Raphael Hertzog]

Hi,

On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> One of the popular answers to this and some other problems is "nobody sat
> down and wrote the code". Not sure what can we do about this class of
> reasons.

Use the $300,000 on our bank accounts?

https://lists.debian.org/debian-news/2019/msg2.html

And I heard of another $300,000 donation from Google (through Thomas Koch)
although I can't find any reference to it.

FWIW, I gave a talk on LTS and the topic of funding Debian work
at the minidebconf in Marseille (30 minutes):
http://meetings-archive.debian.net/pub/debian-meetings/2019/miniconf-marseille/2019-05-25/5_years_lts_funding.webm

My slides are here:
https://wiki.debian.org/DebianEvents/fr/2019/Marseille?action=AttachFile=view=debian-lts-5-years-of-funding.pdf

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Looking for a technical writer to update the Debian Handbook

[Raphael Hertzog]

Hello,

Roland and I, the authors of the Debian Administrator's Handbook (package
debian-handbook), we have not managed to update the book for Debian 9 and
I don't want this to happen again for Debian 10 buster.

I'm thus looking for a technical writer that would be willing to update
the book for Debian 10. This work would be paid by Freexian thanks to
the donation that we are collecting on https://debian-handbook.info/get/
(and thanks to the sales on lulu.com).

The ideal candidate would be someone who:
- loves the Debian OS and knows the ecosystem very well
- has experience with system administration of Debian servers
  (the book covers many common services)
- has good English writing skills
- is not afraid to edit Docbook XML in a text editor
- can emit invoices to Freexian for the work done
- can commit enough time to the task in the upcoming months
  (trying to get the book entirely updated for the buster release)

If you want to have a look at the project, it's hosted on salsa:
https://salsa.debian.org/hertzog/debian-handbook

If you are interested, please get back to me and we can discuss this
in more details.

If you don't have enough time to update the entire book, but would be
willing to update some chapters, please get in touch anyway, we might be
able to share the work between multiple persons.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Handling of entropy during boot

[Raphael Hertzog]

Hi,

On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
> Pointers, please?  Let's see them and investigate.  The primary issue
> I've been aware of to date has been on Fedora systems, and it's due to
> some Red Hat specific changes that they made for FEDRAMP compliance
> --- and Red Hat has dealt with those issues.

In Kali I had to install haveged by default due to this problem.
We got reports of having to wait up to 5 minutes to get to their desktop.
We got reports of sshd not working on first boot (in fact just taking too
long to start).

https://bugs.kali.org/view.php?id=5124
https://bugs.kali.org/view.php?id=4994
https://bugs.kali.org/view.php?id=5011

I haven't looked, but it seems likely that thin.service is trying to
generate some keys on initial startup. Which explains why it gets stalled.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Sending using my @debian.org in gmail

[Raphael Hertzog]

Hi,

On Tue, 04 Dec 2018, Marc Haber wrote:
> >> If I could vote for which idea Debian mail admin time is dedicated
> >> (which I cannot since Debian admins are volunteers and can choose what
> >> to work on), I'd vote for better spam filtering on
> >> @packages.debian.org and @alioth-lists.debian.net, probably using the
> >> crossassassin mechanism that @lists.debian.org already uses.
> >
> >If you are the list admin (or know him) I've had good success on
> >pkg-voip-maintainers setting this in header_filter_rules
> >
> >X-Alioth-Lists-Spam-Score-Int: [3-9][0-9]$
> >
> >(that means hold everything with a Score >= 3.0 for moderation, while
> >the cutoff level on alioth-lists is 5.0
> >
> >For pkg-voip-maintainers this had zero false-positives and about 1-2
> >spammails per day that are held for moderation. Of course you should
> >occasionally look at the moderation queue...
> 
> I am not even sure whether @packages.debian.org is a regular mailing
> list manager.

*@packages.debian.org are just a plain aliases to maintainer emails (and
to the package tracker). But when maintainer emails point to mailing
lists, the above advice might still be relevant.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hello,

On Thu, 29 Nov 2018, Adrian Bunk wrote:
> Qt already supports runtime ES/non-ES in the same library build on 
> Windows [2], something like that might also be doable for Linux if 
> anyone (Linaro? Canonical?) with a real interest in that would work
> on making it happen.
> 
> Some of the listed applications already set Qt::AA_UseOpenGLES or
> Qt::AA_UseDesktopOpenGL for the Windows case, but there would surely
> be additional application side fixes required after someone added
> dynamic OpenGL selection also for Linux to Qt.

FTR, I also think that this would be the best solution. Dmitry just filed
a bug requesting this so that we can have some feedback from the Qt
developers:
https://bugreports.qt.io/browse/QTBUG-72128

Feel free to up-vote the request.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hello Lisandro,

TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution, but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point 6.1.3
of the constitution https://www.debian.org/devel/constitution.en.html#item-6).

On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> It seems now clear that the general consensus seems to expect:
> = Qt available for both Desktop and ES OpenGL flavours
> = If no change is possible, keep arm64 with Desktop OpenGL support

I'm not pleased with how this discussion was handled. First of all,
you did not leave enough time for all stakeholders to participate in
the discussion (started on November 22th, closed November 25th, 3 days,
that's not a reasonable timeframe in particular when 2 of the 3 days
were in the week-end). I was aware of the discussion but did not
had the time to chime in, yet I was the person who re-opened the bug
#881333 in the first place.

I also invited someone else who is working on a concrete project involving
Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
now but he also did not have the time to contribute to the discussion.

Then I have read the whole discussion and I don't have the feeling that
any consensus has been reached. It was largely driven by Andy Simpkins
who explained his "gut feeling" as a tinkerer of arm* boards/devices and
Bret Curtis who contributes to some applications with very specific OpenGL
needs. While I value their contribution to the discussion, they both
represent very specific classes of users.

What I remember from this discussion is that the Windows build of Qt
use GLES 2 by default. It would have been interesting to find out the
rationale for this... because maybe the right decision for us would be
to switch to GLES 2 by default as well (on all architectures as jcristau
suggested). Someone else who likely also tried to ensure Qt for Windows is
usable on most hardware made that choice.

We got confirmation from many persons that almost all cards benefitting
from Desktop OpenGL would also work with OpenGL ES. So in terms of
hardware support, picking OpenGL ES is the right choice. In terms of
sofware support, it looks like that Desktop OpenGL is better as there
are a few applications that only work with Desktop OpenGL.

Software can be fixed/improved to also work with OpenGL ES. However
hardware, once bought, cannot be fixed to support Desktop OpenGL
when it has been designed for OpenGL ES only.

When taking all this into account, I believe that the right solution is
to use OpenGL ES on all architectures. This will provide the required
incentives for application developers who stick only to Desktop OpenGL
to support OpenGL ES (even it it's at the cost of using some intermediary
layer like https://github.com/p3/regal) and would maximize hardware
support on all architectures.

That said, I'm fine with a decision to change only arm64 since that's
an architecture were devices that support only OpenGL ES are in the
majority.

This is not a easy decision to make but we have a dedicated body to help
maintainers find the best technical decision when there are pros/cons
in both solutions, it's called the technical committee. Please consider
seeking their advice before taking your decision.

> Both Dmitry and I just learned that the RPI has the VC4 driver which enables 
> it to do hardware acceleration for Desktop OpenGL, we must admit that this is 
> a game changer in many ways, even if we are talking on just one board (but 
> quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use 
> Ubuntu.

I don't see why this affects the decision in any way. AFAIK the VC4 driver
also enables hardware acceleration for OpenGL ES. And this is only
relevant for the RPI3 which is the only arm64 hardware.

Bret Curtis clearly explained that we do get good performances on older
RPI (armhf-based) precisely because of the VC4 driver being able to
leverage OpenGL ES too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hello,

On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]

That's a different claim to what you made in a former message.

> The problem is that there are applications that make use of Qt that do
> not support GLES while Qt can support both. So these things can't be
> shipped on armel and armhf and now possibly arm64.
> 
> What applications does Debian have in its repo that only support GLES?

Wrong question. Maybe it makes sense for you at the application level for
the application that are hooking into OpenGL directly. But we are speaking
of having decent graphical performances for all Qt based-applications on
hardware that only support GLES and not Desktop OpenGL.

That kind of hardware does exist now and people who try to use Debian
on it will be disappointed because even LXQt will feel sluggish on them.

This is not a easy decision to make, in the ideal world we would support
both Qt stack but this is not realistic and we have to make a choice.

So basically there are two choices:

1/ 99% of users get decent performance with 98% of the Qt-based
   applications, but 2% of the applications will not work because
   they only support Qt with Desktop OpenGL or have some other
   incompatibility (2% is probably over-inflated, but the order
   is roughly correct and enough to get my point)

2/ 50% of the arm64 users have sluggish/unusable KDE/Qt-based applications
   and 50% of the users have the best performance with their Qt-based
   applications and those can also benefit from the 2% of the applications
   that would not be available otherwise. Those applications can be fixed
   to build with either OpenGL or GLES.
   (and here I'm saying 50% are losing but with the hardware available
   right now, it's certainly more than 50%... most arm64 boards are
   tailored for the embedded/mobile market)
   
In my opinion, Debian as a universal operating system should make choice
#1 so that most hardware bought by most users work well with most
applications. Getting 2% more applications or 20% more performance on the
applications at the cost of 50% of the users not being able to use their
hardware with decent performance is not the correct choice.

Cheers,

PS: None of the figures are accurate but I believe that they are not
misleading and are enough to understand my reasoning. For example,
I have no idea how much faster Qt with Desktop OpenGL vs Qt with GLES can
be.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hi,

On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.

Interesting.

> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at this point.

If those packages were broken on all architectures, I expect more people
will start to care about the problem and it might end up fixed. Right now
if affects almost nobody and the problem languishes...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hello Bret,

On Sat, 24 Nov 2018, bret curtis wrote:
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardware accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.

Can you back up this claim with some external documentation?
Or at least pointer the appropriate part of the code?

https://github.com/anholt/mesa/wiki/VC4-OpenGL-support says that the
VC4 hardware is a GLES 2.0 renderer and it would seem strange that
the mesa driver for it would not support OpenGL ES.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

On Sun, 28 Oct 2018, Wouter Verhelst wrote:
> On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > Debian can't afford to pay developers in general, and previous
> > proposals to pay specific developers were not well received.
> 
> That was over a decade ago. The circumstances at the time were also
> different.

That's true, but it's not clear that the result would be different.

And while I have certainly no objection in going down that route,
I also don't plan to actively push into this direction given that the
current situation seems to be working relatively well. I don't want to
break what's working given the time and energy I already invested in this
project.

I know that Luca is not 100% satisfied with the current situation but
while I acknowledge his message, I have not much to propose. Last time
I tried to bring LTS even closer to Debian (in terms of getting LTS
sponsors thanked on www.debian.org, etc.), the discussions quickly stalled.

If anybody wants to drive a change in the way the LTS funding works, I
will be happy to participate in the discussion/project but it needs to be
well prepared because handling so many sponsors with all the
invoicing/payments quirks is a non-trivial amount of work and moving
away from Freexian to a trusted organization is going to be supplementary
work. The scheme has been designed so that it can fund itself (the share
that Freexian is taking funds that part of administrative work) so it's
possible and it should sustainable in the long run once the initial cost
of moving has been paid.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

Hi,

On Tue, 23 Oct 2018, Noah Meyerhans wrote:
> The question
> here was simply about discoverability. If you're a Debian user just
> beginning exploration of public cloud alternatives, should we make it
> easy for you to launch LTS instead of stable?

I don't see any reason to make it hard, but it should definitely be shown
less prominently than the current stable release. And the difference in
the status must be clearly communicated.

> The perception, afaict, is that LTS only exists because people are paid
> to work on it. There has not traditionally been sufficient interest
> within Debian to sustain support of a release for 5 years, so some
> companies have provided financial incentives. That's fine, but potential
> somewhat fragile. If that funding goes away, does LTS go away?

LTS has been running for 4.5 years and rely on many sponsors so that nothing
stops when one sponsor goes away. It's not that fragile currently.

> Is LTS work, for pay, going to drain resources from volunteer work?

My experience has rather been the opposite. Most paid LTS contributors do
between 10 and 30 hours per month for LTS and in multiple cases it
allows them to spend many more hours of volunteer work in the project.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

Hi Steve,

On Tue, 23 Oct 2018, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

FWIW, I don't think that the right answer is to make LTS even more clearly
separate. We want to be able to say that Debian is supported for 5 years
and we don't want to have to put an asterisk pointing to a long list of
exceptions.

Instead we are rather aiming to integrate LTS more and more everywhere.
However, when LTS is becoming a burden on other teams, we should
definitely look how the LTS team can help to alleviate that burden.
Because as you know the LTS team has paid contributors to do that kind
of work.

I invite you to start a conversation between debian-lts and debian-cloud
to discuss how the LTS team can help you with the workload that you would
rather get rid of. Maybe we need to allocate some time each month to
update LTS images, maybe you need our help to improve your tooling to better
support LTS and that would be enough, etc. I don't know. Let's discuss.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature