crypto policy for Debian?

[Timo Aaltonen]

Hi!

I noticed that crypto-policies is packaged, but not really used 
anywhere. Would it be worthwhile to make it the official way to 
configure the system-wide crypto policy as it was implemented in Fedora 
[1]? This has been briefly mentioned before at least in bug 765512 [2], 
but nothing came out of it. I think it would benefit Debian if support 
for crypto-policies was added to packages, and make it a release goal 
for Bookworm. Or is it just a matter of JFDI and filing bugs & MR's 
against the affected packages?



[1] https://fedoraproject.org/wiki/Changes/CryptoPolicy
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765512


--
t

Bug#977127: ITP: astc-encoder -- ASTC image compression and decompression

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: astc-encoder
  Version : 2.1.0
  Upstream Author : ARM Limited
* URL : https://github.com/ARM-software/astc-encoder
* License : Apache-2.0
  Programming Lang: C++
  Description : ASTC image compression and decompression

The Adaptive Scalable Texture Compression (ASTC) format, developed by
Arm® and AMD, has been adopted as an official extension to the Open GL®,
OpenGL ES, and Vulkan® graphics APIs. It provides a major step forward
both in terms of image quality at a given bitrate, and in terms of the
format and bitrate flexibility available to content creators.

This package provides a C++ library and a command-line tool for ASTC
compression and decompression. It is a dependency of the Google Filament
rendering engine.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl/TSZAACgkQ+C8H+466
LVnBdgv8CvYB3r/vyi4SyDk0lJ6oqyjCsqQFtOqBJe7J7ZAtHhqcLRzUQL9fStnG
Ic81f3Vf8LY6hrj9d7Ph6MjUmVW/Sz9pur1th3zpP95EuoI26/73u0+Uy9htFNpo
+pJig1l//lUzhkE9zl7e8tjzZt5v/D1NNm6UgqaSO4OEI2fh3bL0m9FO1HLCaaXt
fKg41IhsdaPxjtLk+e88eFHMEpVzqjGNajUTLhMhzBYzY7M/0ombDTRBrUHgiaPT
LJjuA0JgUDc/+JEoSF+Ny793PnyAKtgw10zVAHZ/LkvvRyihPWRpQl18Xg9s5bny
j4gtW4FZ5+QDWdiPhY7SptWCOvDaN/tAwCFHtAasVNauXfLYnY49qYLjxTHld61d
wK2NFJkgsL640Ka2rB/MIKLtDljNau0x0GTGs5Y6EwezCrADGNGL0l0Iso8ctfYT
Ulk9Y6ekH/H4ervAYvmmPIJyAqAyVG6c1l2VddhF6rh9XUkx6VshDlfqDNS5Q8+J
Vd4z0rvo
=kcyK
-END PGP SIGNATURE-

Bug#977128: ITP: draco -- Library for compressing 3D geometric meshes and point clouds

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: draco
  Version : 1.4.0
  Upstream Author : The Draco Authors
* URL : https://github.com/google/draco
* License : Apache-2.0
  Programming Lang: C++
  Description : Library for compressing 3D geometric meshes and point clouds

Draco is a library for compressing and decompressing 3D geometric meshes
and point clouds. It is intended to improve the storage and transmission
of 3D graphics.

Draco is designed and built for compression efficiency and speed. The code
supports compressing points, connectivity information, texture coordinates,
color information, normals, and any other generic attributes associated with
geometry.

Draco is a dependency for the Google Filament rendering engine.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl/TTDYACgkQ+C8H+466
LVknkgwAmw4xcE/0fAmDJgRkoZUepFgByG47QolIUKFuc/0fycllEBnMb/cocJXq
FQYXceGOKp1S2hZpe5+gwRJhU0WU85FbNe97/1c16Djdpgd6izaboZxhEe951A8/
J25FykM3VyOrSVfqs+iT/BprfURoVgRKUuejAU5LrsRAJ8Kt1Rhvc7YQDmOGEYDz
rqklUUAzkAgn2utu2lKMZ6U5YgJSWrl2F6l7+bfaBPzX2Icm7t0niWoxqgdiHKwU
HI+sjD9qIowrG+PSS5lYWB/rqllhg5BP7CABPzdVPs4QXB4JYhCOYkDX8L9AaD3B
7Nzakl7Vjv2zKKwye2wuqdzTTIVfaikxaSr9wP0iJ8c+H50aymx08OBx/5Ix5gUH
LqYiR5/GWBolEhnVgXoxP17TNyYCBl6MLsbrRmwOJcW3/OFWoXCubWAPVH7lgmDx
1+Blmw4nbKggKyPaCyWR5c0snS+xDbUItpXkjOnWpSuO3PQ0rnVcdc+qn/Gn/KaQ
+Az6I072
=PgWD
-END PGP SIGNATURE-

Bug#977129: ITP: meshoptimizer -- Mesh optimizing library for 3D object rendering

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: meshoptimizer
  Version : 0.15
  Upstream Author : Arseny Kapoulkine 
* URL : https://github.com/zeux/meshoptimizer
* License : Expat
  Programming Lang: C++
  Description : Mesh optimizing library for 3D object rendering

When a GPU renders triangle meshes, various stages of the GPU pipeline have
to process vertex and index data. The efficiency of these stages depends on
the data you feed to them; this library provides algorithms to help optimize
meshes for these stages, as well as algorithms to reduce the mesh complexity
and storage overhead.

This library is a dependency for Google Filament.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl/TTYwACgkQ+C8H+466
LVlGvgv/e/jSy6ie06jQwhVK7KXDoSrCV75rAYMVh5HTN5QMzdyzqjLbtIlj9fmA
qffhEAg23D/uw0pfrFwDseAqpw3+D8SiZKUPLlQccyV/F0UaPCkG2xxEwb6yhMBF
rlpx+DTPjFFiThGE4CKk6hLTKSi7bZ7W9VgIFpl/XASyh33rMaiat9pDfipABKO5
6GxvuaiH4xNDTbflDJ4zpVoNuQhJybmotmstCBtvJ+DxKjS4brgi3pSxVMQBtR3I
GaZHfN5q8FX5QJF5VebgRLzRmoDpd9R8asTHacJ5BvUYe6fhzFVJsuLM9MTgy0t4
AgdUSrVZnL6zXR2PQftewztsdcnhNT8Bo9AMl120v+TzjJ/oV3hLwWQw1cES2Eea
i9CH3qpqX9mnd256fl20q66fmNWMqCGuHDXn2E6iizdSIa+BKnPQe+H2DeSAgn97
R6fxpe6oeYKVk9rrai74md9vvlhcA1XJS4Iw9W1avDe50x2oMS6UIrttZ7vINJbH
+pcPVhDY
=jXJf
-END PGP SIGNATURE-

MiniDebConf India 2021: Call for Proposals

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[sorry if you got another copy earlier, it seems pgp/mime is not
recognized by the lists as signed mail and I had to use an older
version of thunderbird with enigmail to get inline pgp working]

Dear Debianites,

The MiniDebConf India Content team would like to call for proposals for
the MiniDebConf India 2021[1] conference, which will take place online,
from January 23rd to 24th, 2021.

# Introduction
MiniDebConf India, organised by the Debian India community and supported
by Debian, will be streamed online so you can participate wherever you
are.
Aims to introduce and propagate Debian and Free Software in Indian
subcontinent.
We are currently set up for talks in English, Hindi and Malayalam.
However, if you are more comfortable presenting in another language from
the subcontinent, we would be more than happy to consider your proposal!
The event will run from 1000 to 2100 hours IST (0430-1530 UTC) over two
days.

# Submitting an Event
You can now submit an event proposal[2]. Events are not limited to
traditional presentations or informal sessions (BoFs): we welcome
submissions of tutorials, performances, art installations, debates, or
any other format of event that you think would be of interest to the
Debian community.

Regular sessions may either be 20 or 45 minutes long (including time for
questions), other kinds of sessions (workshops, demos, lightning talks,
…) could have different durations. Please choose the most suitable
duration for your session and explain any special requests.

In order to submit a talk, you will need to create an account on the
site. We suggest that Debian Salsa account holders (including DDs and
DMs) use their Salsa login when creating an account. However, this isn’t
required, as you can sign up with an e-mail address and password.

# Timeline
- - - Talk Submission deadline: Sunday, January 10th 2021
- - - Acceptance notification: Monday, January 11th 2021

# Topics can be anything that is relevant to Debian and Free Software.

# Online Talks
We expect speakers to pre-record their talks in advance. Live talks at
an online conference are prone to technical problems, resulting in bad
quality videos. We strongly encourage you to record your presentations
as instructed here[3]. You can interact with the audience on the IRC
channel.

# Code of Conduct
The event is covered by a Code of Conduct[4] designed to ensure
everyone’s safety and comfort. The code applies to all attendees,
including speakers, and to the content of all presentations. Do not
hesitate to contact us at india.m...@debconf.org if you have any
questions or are unsure about certain content you’d like to present.

# Video Coverage
As this is an online conference, talks will be streamed live over the
Internet. Unless speakers opt-out, all scheduled talks will be recorded
and published later under the DebConf license[5] (MIT/Expat), as well as
presentation slides and papers whenever available.

Please note that, although we will make your wishes known to the
participants, we cannot control whether attendees record and publish
your talk from the live stream.

# Questions/Queries
In case of any queries or issues that require redressal, reach out to
the organizers at india.m...@debconf.org

See you all at the conference!

MiniDebConf India Team

[1] https://in2021.mini.debconf.org
[2] https://in2021.mini.debconf.org/talks/new/
[3]
https://debconf-video-team.pages.debian.net/docs/advice_for_recording.ht
ml#advice-for-recording
[4] https://in2021.mini.debconf.org/about/coc/
[5] https://meetings-archive.debian.net/pub/debian-meetings/LICENSE
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE0whj4mAg5UP0cZqDj1PgGTspS3UFAl/Tcv0ACgkQj1PgGTsp
S3WZ6Q/+MEK5B5PGKl0jWgeFcJDOwUlFqnyxZviDN0vrTKSvPaALHLc2cDNBCaHP
203bDqXsoYEBcaKpUqp7W7mMTX6+aHEEzdTWmAj1pwXAES82cvxPHc0+w2X9Ni4+
LNCKcQJc8VjKvgsdeOP+EZx4vm5PQh2s0ZhlyZ5c3vy9s3VGsjTu/dZlhuP7nBVy
sX93o3UkpZeGpXz3uVYjEwi9M6ycmReyG6xkipUTxX25G570fMqsjfgfCrZyoObb
B2SxZM1JJfTqGpZi8OuM28SdtbhXwz4nRnELfpKbLXf/iCxTsca690jg+ygbxvGM
q0Lg+5UimHzPvoH5cr8iqjDLFpnBsRenLHhsnFjIwGiNtvRO9T9WTDoNI5aCcMLL
OAiTmsHzXJMky6MpPHlW9VFykm/Dr1awGFHy273e6qmnTOoUCreGP1/yEGPUaCPI
XkE46Z12iE/mqeRRzfkDlwii5UzoP5echZm6N+TpAvp+Qrs5XPiypwflX3oRqUdc
Ty+yngblW34VHmQfonnKQIw5HdZcwqE04bkdLi5CS3Go51RsKHqXKlEm1rpalDot
Bnc1sd992RJZUScujq2epwwoVrG+6Yzm1tPqK/as+dewA+Uzk7PExgBFhN5ig3Ji
uw4JMlCsXwJyiMoL9nfv58oY+ubRH8VS5d4un++VjU+YuMrFWZ8=
=SaLf
-END PGP SIGNATURE-

Re: [External] Re: Intel SOF audio firmware packaging

[Mark Pearson]

Hi Vincent

On 10/12/2020 13:53, Vincent Bernat wrote:
>  ❦ 10 décembre 2020 12:57 -05, Mark Pearson:
> 
>> I did have to comment out "overlay = True" in the gbp.conf - it gave me
>> an error that I'll have to dig into.
> 
> That's because you went for the first "classic" solution. I was pushing
> for the overlay solution as the upstream git repository is pushing some
> big files at each release and your git repository will become bigger and
> bigger. With the overlay solution, you only have a debian/latest branch
> and the user is expected to retrieve the tarball to make it work (this
> is automated by uscan, thanks to the debian/watch).
Ah - that makes sense.
Should I be looking at changing what I've done or is the current
solution OK? I'd like to get it as right as it can be.
> 
> However, you can keep your repository as is and add to gbp.conf:
> 
> upstream-branch = stable-v1.6
> upstream-tag = v1.6-rc3
> pristine-tar = False
Great - I've updated the repository with this change. Thank you.
> 
> This should do the trick. You may want to tag the upstream commit
> yourself with upstream/1.6 if you upstream is not consistent with
> tagging (which seems the case).
I'm not sure what I need to do here - do I create a tag on my repository
with the name 1.6 on the v1.6-rc3 branch?
Just want to make sure I do the right steps :)

> 
> You may want to either rename firmware-sof-signed.install to install or
> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
> missing at the top of the postinst script.
I think I've fixed this now
> 
> Most firmware-* packages seem to ship to /lib/firmware, not
> /usr/lib/firmware. As I am using a usr-merged system (this is the
> default now), I don't see a difference. From my understanding, in the
> future, packages need to ship this way. I think Linux will look into
> /lib/firmware only and therefore, this will fail on non-usr-merged
> systems. You can fix that by modifying the install file with:
> 
> builddir/usr/lib /
I've applied this fix - thank you
> 
> In debian/control, you also need to add Vcs-Browser and Vcs-Git fields
> to point to Salsa. Also, maybe the source pakcage could be
> `firmware-sof` instead of sof-bin, to match your repository name. Just
> update debian/control and debian/changelog.
I added the Vcs fields - hoepfully correctly.
Source has been updated to match the repo name
> 
> Everything else looks OK for me.
> 
Thank you for all the pointers - very much appreciated.

Let me know if you spot anything else that is wrong or can be improved.

As I understand it the next step is to find a DM or DD who can sponsor
this? Any recommendations on how that process works?

Thanks
Mark

Bug#977144: ITP: node-inflected -- port of ActiveSupport's inflector to Node.js

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : node-inflected
 Version : 2.1.0
 Upstream Author : Martin Andert
* URL : https://github.com/martinandert/inflected#readme
* License : Expat
 Programming Lang: JavaScript
 Description : port of ActiveSupport's inflector to Node.js

This library transforms words from singular to plural, class names to 
table
names, modularized class names to ones without, and class names to 
foreign

keys.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of miragejs which is in turn a dependency 
of gitlab.

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

owner 960788 markpear...@lenovo.com
quit

 ❦ 11 décembre 2020 12:15 -05, Mark Pearson:

>>> I did have to comment out "overlay = True" in the gbp.conf - it gave me
>>> an error that I'll have to dig into.
>> 
>> That's because you went for the first "classic" solution. I was pushing
>> for the overlay solution as the upstream git repository is pushing some
>> big files at each release and your git repository will become bigger and
>> bigger. With the overlay solution, you only have a debian/latest branch
>> and the user is expected to retrieve the tarball to make it work (this
>> is automated by uscan, thanks to the debian/watch).
> Ah - that makes sense.
> Should I be looking at changing what I've done or is the current
> solution OK? I'd like to get it as right as it can be.
>> 
>> However, you can keep your repository as is and add to gbp.conf:
>> 
>> upstream-branch = stable-v1.6
>> upstream-tag = v1.6-rc3
>> pristine-tar = False
> Great - I've updated the repository with this change. Thank you.
>> 
>> This should do the trick. You may want to tag the upstream commit
>> yourself with upstream/1.6 if you upstream is not consistent with
>> tagging (which seems the case).
> I'm not sure what I need to do here - do I create a tag on my repository
> with the name 1.6 on the v1.6-rc3 branch?
> Just want to make sure I do the right steps :)

Well, for all these questions, upstream versioning strategy is
confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which
is not part of the stable-v1.6 branch. We need to have a stable version
number. Either the branch stable-v1.6 doesn't move anymore or there are
tags, but upstream is inconsistent because there is no tag others than
v1.6-rc3. Other users are complaining about this as well:

https://github.com/thesofproject/sof-bin/issues/25

They seem to say future releases will be tagged. So, I think you should
use in gbp.conf:

upstream-tag = v%(version%~%-)s
pristine-tar = False

No need for upstream-branch since you won't use "gbp import-orig" as the
origin lives directly in git repository.

And you need to use 1.6~rc3-1 in debian/changelog since this is the
version you are packaging (1.6~rc3 and the -1 is the Debian part).
1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want
to use "~", while upstream uses "-".

Also, debian/watch is incorrect as it is watching branches instead of tags.
You need to fix it with:

version=4
opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%"
 \
 https://github.com/thesofproject/sof-bin/tags \
 (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate

You can test with "uscan --report --verbose".

As for using an overlay or not, let's stick to your current strategy. If
the repository becomes too big, it's always possible to start a new one.
Not using an overlay is easier for everybody since it's the most common
workflow.

>> You may want to either rename firmware-sof-signed.install to install or
>> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
>> missing at the top of the postinst script.
> I think I've fixed this now

You also added "#v+" and "#v-" markers. It was not part of the file.
Some mailers use this to mark code blocks, that's why I have added them.
It was unclear, sorry.

Also, nitpicking, but either use:

 - firmware-sof-signed.install and firmware-sof-signed.postinst
 - install and postinst

Since you have only one binary package, it's equivalent, but it's just
better to not mix the two.

Everything else looks good.

> As I understand it the next step is to find a DM or DD who can sponsor
> this? Any recommendations on how that process works?

Usually, you can go through mentors.debian.net, upload your package
there and file an "RFS" (request for sponsor). But you don't really need
to do that as I can upload it for you. So, fix the last details above,
I'll do another review and I'll upload if anything is correct.

Also, did you test the package on real hardware or do you need me to
test it? I can test it, I just need to spend 10 minutes doing it.

We should also take over the RFS. We were a bit fast in this process. I
am doing that in this email as well for you (with you as owner). We'll
wait a few days if anyone protests.
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain

Bug#977155: ITP: node-thenby: library that helps sorting arrays on multiple keys

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-thenby
  Version : 1.3.4+git20200720.0fd165a+ds-1
  Upstream Author : Teun Duynstee
* URL : https://github.com/Teun/thenBy.js
* License : Apache-2.0
  Programming Lang: Javascript
  Description : library that helps sorting arrays on multiple keys
 It allows users to use the native Array::sort()
 method of javascript, but pass in multiple
 functions to sort that are composed with
 firstBy().thenBy().thenBy() style.

This is a pre-dependency of q2-taxa
I shall maintain this package.

Re: CentOS and Debian/Ubuntu release cycles

[Thomas Goirand]

On 12/10/20 9:06 PM, Joel Wirāmu Pauling wrote:
> 
> 
> On Fri, Dec 11, 2020 at 8:51 AM Geert Stappers  > wrote:
> 
> On Thu, Dec 10, 2020 at 05:16:28PM +0100, Marco d'Itri wrote:
> > On Dec 10, Paul Wise mailto:p...@debian.org>> wrote:
> > > Both of these situations sound like things that should get solved by
> > > rewriting the vendor/O-O-T code and including it in mainline
> > > Linux/etc, is there any chance of that happening? Or alternatively,
> > The Fibre Channel drivers ARE all upstreamed, it's just that the
> inbox
> > drivers (i.e. distributed with the OS, in vendors speak) are not
> > qualified to receive support (and may be buggy, even in RHEL).
> > Storage vendors provide a support matrix with supported releases
> of the
> > storage firmware, FC switches firmware, network adapter firmware,
> OS and
> > OS driver. Anything else may not receive support.
> >
> > > for significant future hardware acquisitions, require mainline
> support
> > > before purchase.
> > Obviously, but I am not aware of any such FC/FCoE hardware (not
> just the
> > network adapters, but also the storages).
> 
> Acknowledge on that problem.
> Do know that it can and must be solved by wallet.
> So do talk with your purchase department.
> 
> 
> Being out of Kernel means it is out of support or an approved support
> exception, one of the benefits of paid RHEL is hardware vendors both
> reach out to us, and we reach out to them to ensure certification and
> capability. Generally prior to something going to market.
> 
> I hear your pain tho,  I have a heap of Dell servers with deprecated HBA
> controllers in RH8 that I need to schlep in elrepo modules for drives to
> show up. That decision however was made because no-one in mainline is
> able to solve vendor issues and the vendor has disappeared (related to a
> PowerPC chip design flaws in a heap of Sandybridge era Raid
> controllers). We went down the big red warnings route in RH7 and people
> ignored them and had data lost and then blamed RH. Which is untenable ;
> a lot of hardware specific support falls into this category; and 100%
> this is something careful selection solves and is part of your Risk
> assessment as an Org. It also puts a LTS CentOS at odds of being able to
> track our source trees, one of the problems this is attempting to
> ameloirate.
> 
> So in all those situations given here, yes,  CentOS drivers that exist
> only in CentOS land really put the entire premise of a Stable Long Lived
> and robust OS at odds with the reality yes, absolutely.
> 
> The ability to compile modules against the RHEL sources is not going
> away. So you can still run your junk with RHEL (out of support). The
> streams kernel also likely will solve this issue.

Gosh... reading that, I'm really happy I'm not (and never was) a CentOS
user. Seriously, this looks terrible!

Cheers,

Thomas Goirand (zigo)

Bug#977164: RFP: golang-github-victoriametrics-metricsql -- standalone PromQL and MetricsQL parser

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: golang-github-victoriametrics-metricsql
  Version : 0.8.0-1
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/metricsql
* License : Apache-2.0
  Programming Lang: Go
  Description : standalone PromQL and MetricsQL parser (library)

 The package metricsql implements the MetricsQL
 (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/MetricsQL)
 and PromQL
 (https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085)
 parsers in Go.

This is a required dependency for victoria-metrics.

I've got the tested and working packaging which I'll push into salsa once
this bug has been filed.

Thanks,
Guillem

Re: [External] Re: Intel SOF audio firmware packaging

[Mark Pearson]

Thanks Vincent

On 11/12/2020 14:22, Vincent Bernat wrote:
> owner 960788 markpear...@lenovo.com
> quit
> 
>  ❦ 11 décembre 2020 12:15 -05, Mark Pearson:
> 


>>>
>>> This should do the trick. You may want to tag the upstream commit
>>> yourself with upstream/1.6 if you upstream is not consistent with
>>> tagging (which seems the case).
>> I'm not sure what I need to do here - do I create a tag on my repository
>> with the name 1.6 on the v1.6-rc3 branch?
>> Just want to make sure I do the right steps :)
> 
> Well, for all these questions, upstream versioning strategy is
> confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which
> is not part of the stable-v1.6 branch. We need to have a stable version
> number. Either the branch stable-v1.6 doesn't move anymore or there are
> tags, but upstream is inconsistent because there is no tag others than
> v1.6-rc3. Other users are complaining about this as well:
> 
> https://github.com/thesofproject/sof-bin/issues/25
> 
> They seem to say future releases will be tagged. So, I think you should
> use in gbp.conf:
> 
> upstream-tag = v%(version%~%-)s
> pristine-tar = False
> 
> No need for upstream-branch since you won't use "gbp import-orig" as the
> origin lives directly in git repository.
> 
Got it - I've made these changes and pushed them to the repository

> And you need to use 1.6~rc3-1 in debian/changelog since this is the
> version you are packaging (1.6~rc3 and the -1 is the Debian part).
> 1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want
> to use "~", while upstream uses "-".
> 
> Also, debian/watch is incorrect as it is watching branches instead of tags.
> You need to fix it with:
> 
> version=4
> opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%"
>  \
>  https://github.com/thesofproject/sof-bin/tags \
>  (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate
> 
> You can test with "uscan --report --verbose".
> 
As a note, Stephan Lachlit previously mentioned that I didn't need
"debian uupdate" so I've removed that here too. Let me know if you
disagree. It all seems to work when I test it :)

> As for using an overlay or not, let's stick to your current strategy. If
> the repository becomes too big, it's always possible to start a new one.
> Not using an overlay is easier for everybody since it's the most common
> workflow.
Great - works for me!
> 
>>> You may want to either rename firmware-sof-signed.install to install or
>>> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
>>> missing at the top of the postinst script.
>> I think I've fixed this now
> 
> You also added "#v+" and "#v-" markers. It was not part of the file.
> Some mailers use this to mark code blocks, that's why I have added them.
> It was unclear, sorry.
> 
> Also, nitpicking, but either use:
> 
>  - firmware-sof-signed.install and firmware-sof-signed.postinst
>  - install and postinst
> 
> Since you have only one binary package, it's equivalent, but it's just
> better to not mix the two.
Agreed - this should be fixed in my latest, let me know if I'm missing
something.
> 
> Everything else looks good.
> 
>> As I understand it the next step is to find a DM or DD who can sponsor
>> this? Any recommendations on how that process works?
> 
> Usually, you can go through mentors.debian.net, upload your package
> there and file an "RFS" (request for sponsor). But you don't really need
> to do that as I can upload it for you. So, fix the last details above,
> I'll do another review and I'll upload if anything is correct.
Big thank you! That would be fantastic.
What do I need to do going forward to look after this? Is there anything
in particular that is needed as new sof firmware is released? Just
wanting to check what expectations are going forward and if there is
anything I should be looking out for etc.

> 
> Also, did you test the package on real hardware or do you need me to
> test it? I can test it, I just need to spend 10 minutes doing it.
Tested on my X1Carbon7 and it works well. I have a bunch of other
platforms I can try it on too if that helps but it will have to be next
week.

> 
> We should also take over the RFS. We were a bit fast in this process. I
> am doing that in this email as well for you (with you as owner). We'll
> wait a few days if anyone protests.
> 
Sounds good. This process went a lot faster than I expected too - really
appreciate all the help and feedback I got from various community
members. Very Cool!
I'll continue to keep an eye out for any other suggestions/corrections/etc

Mark

Re: Porter roll call for Debian Bullseye

[Wookey]

On 2020-11-02 22:23 +0200, Graham Inggs wrote:
> Hi
> 
> We are doing a roll call for porters of all release architectures.  If
> you are an active porter behind one of the release architectures [1]
> for the entire lifetime of Debian Bullseye (est. end of 2024), please
> respond with a signed email containing the following before Friday,
> November 27:
> 
>  * Which architectures are you committing to be an active porter for?

arm64,armhf,armel

>  * Please describe recent relevant porter contributions.

on-site support for buildds at arm.
process day-to-day buildd requests give-backs) 
investigate missing arm support (e.g. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711)
investigate compiler issues and push to arm compiler team if appropriate (e.g. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974058 )
run rebuilds across the arch occaisionally (currently planned for arm64 to test 
BTI support and armhf to test 64-bit timet release)


>  * Are you running/using Debian testing or sid on said port(s)?

yes. I have three arm64 buildds (I did have an arm64 desktop until we
all got sent home - it's now stuck in the office, but I should have an
arm64 laptop from next week...) (thunderx, softiron, Ampere emag). and
an assortment of armhf and armel devices including my home controller
(armel, balloonboard) (odroid, hikey, arndale, cubietruck, qnap). My home
server and mythtv backend was armhf until it croaked last month. An
emergency x86 box has been stuffed in until I work out what's wrong
with it/replace it.

>  * Are you testing/patching d-i for the port(s)?

Yes. Added multiple console support for last release.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature