Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems

[Tobias Heider]

Hi Andreas,

On Fri, Aug 04, 2023 at 01:07:32PM +0200, Andreas Henriksson wrote:
> Hello Tobias Heider,
> 
> While I'm as entusiastic as anyone else here, I have to ask a few
> questions that might be a bit skeptical below...
> 
> On Fri, Jul 28, 2023 at 10:00:35PM +0200, Tobias Heider wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Tobias Heider 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> > 
> > * Package name: u-boot-asahi
> >   Version : 2023.04-2
> >   Upstream Authors: Mark Kettenis 
> >   URL : https://github.com/AsahiLinux/u-boot
> 
> This is a development repository and things are sent upstream
> to u-boot (mainline). The upstreaming effort is driven by the person you
> listed as author (while actual authors is usually someone else AFAIK).

I don't quite agree with calling it just a development repository.
It is the main repository for the Asahi Linux fork where releases
are tagged which are then packaged in their official ALARM (and soon Fedora)
distributions and also used by the unofficial ports listed here:
https://github.com/AsahiLinux/docs/wiki/SW%3AAlternative-Distros

You are right that there is work to upstream those changes, but the diff is
not small and I don't think the upstream support is at a point where it is
actually usable.

I wouldn't mind updating the Upstream Authors field if you think there is
a better name to put there.

> 
> Is there any other u-boot development forks being packaged in Debian and
> how viable do you think this is? Is the plan to eventually provide a
> migration to u-boot-asahi binary package provided by src:u-boot or how
> do you see the future path of this?

I am not aware of other forks being packaged at the moment.
I think it is useful because there are many users such as everyone
currently using Glanzmann's repo, but also those running Ubuntu or Deepin.

Ideally we'll be able to migrate to mainline u-boot at some point but I don't
see that happening too soon.

> 
> Is this targeting Trixie or Experimental?

Trixie, because that way it will be available for users of the Debian based
Asahi ports at some point.
Installing the packaged binaries in the boot path requires manual intervention
at the moment so the danger of breakage pretty low.

> 
> Is there any particular reason you're targeting u-boot? Are you planning
> on working on any installer? Also planning on packaging linux-asahi
> development repo?
>

Repeating what I said above, I think there are plenty of users for m1n1 and
u-boot even if not everything needed to install a fully working Debian system
is available from the official archive yet.
Both of them are relatively straightforward to package, have tagged releases
and are useful even without having a working kernel.
Also: we need to start somewhere.

I don't currenly have a good answer for the linux-asahi kernel.
Ultimately I would of course like to have a working kernel available.

> 
> Do you have contact with upstream about this? They have been very vocal
> about distros shipping things that causes additional problems for (users
> and then in turn for) the Asahi project in the past.
> (Also atleast some Asahi team members are already not publishing their
> development git branches because of fear of people dumping them into
> distros.)

I am a maintainer one of one of the community ports where we already ship
a packaged version of the asahi u-boot and so far that has not been a problem.

The problems you mention were caused by distributions packaging and publishing
versions of the upstream software that was neither tagged nor released for the
official Asahi distribution and had known bugs.

I don't think there is a problem here if we stick to upstream releases and
act responsibly, but I wouldn't mind asking for an official blessing from
the upstream maintainers if you prefer that.

> 
> How does this effort compare against Thomas Glanzmann effort[1]?
> Do you plan to provide a migration path (and why would users migrate
> over to debian-bananas effort instead of Glansmanns effort)?
> 
> (IMHO while Glanzmanns effort is not my preferable packaging style, it
> provides a very good stop gap solution until everything has been
> mainlined into u-boot, linux, mesa which in turn then and only then
> makes it ready for proper Debian packaging. Apart from mainlining work
> which hopefully will happen without any assintance from Debian, the
> biggest challange is probably to provide a sane installer solution
> acceptable for Debian. Is this a task the bananas team intends to take
> on?)

I have discussed my plan to package m1n1 and u-boot with Thomas Glanzmann
before I sent this mail to make sure it doesn't interfere with his work
or break existing installations.

The idea is that once we have them in the official archive, he and others
can switch to using those versions instead of maintaining their own.
Glanzmann's repo is still useful because it provides a convenient installer
and all the other packages we 

Bug#1012000: marked as done (ITA: python-pam -- Python interface to the PAM library)

[Debian Bug Tracking System]

Your message dated Fri, 04 Aug 2023 18:25:11 +
with message-id 
and subject line Bug#1012000: fixed in python-pam 0.4.2-17
has caused the Debian Bug report #1012000,
regarding ITA: python-pam -- Python interface to the PAM library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1012000: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012000
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp

The current maintainer of python-pam, Dima Barsky ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: python-pam
Binary: python3-pam
Version: 0.4.2-13.4
Maintainer: Dima Barsky 
Build-Depends: debhelper (>= 9), python3-all-dev, libpam0g-dev, dh-python
Architecture: any
Standards-Version: 4.5.0
Format: 1.0
Files:
 0a71dd1cc992a3c02b2b0777e2fc80c2 1729 python-pam_0.4.2-13.4.dsc
 e6e78959da5482b9a1aea1171589dd16 15115 python-pam_0.4.2.orig.tar.gz
 663bc2b64b4ca1dba193c9a2bea1d015 3808 python-pam_0.4.2-13.4.diff.gz
Checksums-Sha256:
 453b9c251b6cc6ff2d87214e842da4edad7fe448409034b78810478eeb362848 1729 
python-pam_0.4.2-13.4.dsc
 9ccce2e494c5869d99b20034fd40e368c35add4ef60ce3a33f5573c49a1e2edf 15115 
python-pam_0.4.2.orig.tar.gz
 d6c467bf2858f3cff8b2c1e0a4da604a58f4f2e2560793da4f75590b1527 3808 
python-pam_0.4.2-13.4.diff.gz
Package-List: 
 python3-pam deb python optional arch=any
Directory: pool/main/p/python-pam
Priority: source
Section: python

Package: python3-pam
Source: python-pam (0.4.2-13.4)
Version: 0.4.2-13.4+b3
Installed-Size: 70
Maintainer: Dima Barsky 
Architecture: amd64
Depends: python3 (<< 3.11), python3 (>= 3.9~), libc6 (>= 2.4), libpam0g (>= 
0.99.7.1)
Suggests: python3-pam-dbg
Description: Python interface to the PAM library
Description-md5: 4bae7680ea768021b6726c1ec6ac6cb8
Section: python
Priority: optional
Filename: pool/main/p/python-pam/python3-pam_0.4.2-13.4+b3_amd64.deb
Size: 12236
MD5sum: 432f0888c6851365091e151153616be3
SHA256: aae55da67f621ac1ff4bcdf9828b4b0908b02cecf3b9679a64a30ef86289aaf1


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: python-pam
Source-Version: 0.4.2-17
Done: Ileana Dumitrescu 

We believe that the bug you reported is fixed in the latest version of
python-pam, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1012...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ileana Dumitrescu  (supplier of updated 
python-pam package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 27 Jul 2023 22:08:11 +0300
Source: python-pam
Architecture: source
Version: 0.4.2-17
Distribution: unstable
Urgency: medium
Maintainer: Ileana Dumitrescu 
Changed-By: Ileana Dumitrescu 
Closes: 1012000
Changes:
 python-pam (0.4.2-17) unstable; urgency=medium
 .
   * d/changelog: Remove trailing whitespace
   * d/compat: Removed, replaced by debhelper-compat
   * d/control: Bump standards version to 4.6.2 from 4.5.0
Set Rules-Requires-Root to no
Add debhelper-compat and python3-setuptools to Build-Depends
New maintainer (Closes: #1012000)
Add Vcs-Git and Vcs-Browser
Remove debhelper from Build-Depends
Replace python3-all-dev with libpython3-all-dev and
  python3-all-dev:any
   * d/source/lintian-overrides: Ignore warnings related to upstream, since
 it does not exist
   * d/rules: Enable hardening
  Remove --with python, replace with 

Bug#1042739: O: repetier-host -- host controller for RepRap style 3D printers

[PaulLiu]

Hi Bastian,

I think you mean repsnapper rather than repetier-host?

repsnapper is another story. I think we can skip that. Yes it needs to be
ported to gtk3. But for the 3D printer market it seems to me that
repsnapper is less important. It is open source. And it is supposed to be
used on pure open source 3D printer (Prusa i3).
But another open source slicer program (cura), made by Ultimaker, now
dominates the market. So it is not very important right now.
repsnapper can be removed. Will have less impact. Anyone can correct me if
I'm wrong or someone have different idea.

But repetier-host is different. It is written in C# and build by Mono. I
think it is not related to GTK3.
repetier-host, due to its non-free property on Windows, there are still
some old men. Or some artisst, that are used to repetier-host on Windows.
When we sell some printers (non Ultimaker printers) to those schools, if
their computer doesn't have valid Licensed Windows, we will ship Debian
with repetier-host for those artists. If they have Windows, we will install
repetier-host for them as repetier-host is non-free but free-of-cost on
Windows.
It is hard to tell them to learn cura. Cura actually works better on
technical aspect, but since they are artists they have some post-processing
skills so they don't really care the little-less quality of slicing. They
just want something familiar and just work as before.

And for the local market I can say that repetier-host is still used a lot.
Not sure why popcon is so less. I remember I did turn on popcon on those
installations.

So that's why I'm still maintaining 0.85 on Debian. Just as a backend
solution. If you don't mind, I will re-introduce it into Debian.

Yours,
Paul






On Fri, Aug 4, 2023 at 10:35 PM Bastian Germann  wrote:

> Hi Paul,
>
> Am 03.08.23 um 01:11 schrieb Ying-Chun Liu (PaulLiu):
> > Hi Bastian,
> >
> > I'd like to know why you can orphan my package?
>
> In my observation, it is not standardized by the Policy but accepted
> practice to file orphan bugs for other mainainers' packages that are
> obviously not maintained anymore.
>
> > The problem here is repetier-host is still working.
> > And why it is not upgrading to 2.x.x is because 0.85 is the last open
> > source version we can have.
> > Since 0.95 the upstream choose to close source. So the open source
> > community can only use 0.85.
>
> I did not consider to investigate a license change or check whether the
> program was still available as source. I am very sorry that it went this
> way and will do everything to rectify this. May I suggest that I port
> the package to gtk3 and reintroduce it to Debian?
>
> > And 0.85 is still working quite well with most of the 3D printers.
> >
> > Yours,
> > Paul
>
> Yours,
> Bastian
>

Bug#1043027: ITP: tmpl -- A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

[Sergio Talens-Oliag]

El Fri, Aug 04, 2023 at 05:55:19PM +0200, Jonas Smedegaard va escriure:
> Quoting Sergio Talens-Oliag (2023-08-04 17:35:04)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sergio Talens-Oliag 
> > 
> > * Package name: tmpl
> >   Version : 0.4.0-1
> >   Upstream Author : krako
> > * URL : https://github.com/krakozaure/tmpl
> > * License : Expat
> >   Programming Lang: Go
> >   Description : A tool to apply variables from cli, env, JSON/TOML/YAML 
> > files to templates
> > 
> >  tmpl
> >  .
> >  tmpl allows to apply variables from JSON/TOML/YAML files, environment
> >  variables or CLI arguments to template files using Golang text/template
> >  and functions from the Sprig project.
> 
> Package "tmpl" already exists - seemingly from a different source but
> also written in Go.

Yes, just saw that after filling the ITP, in fact I've been asking about it on
the #debian-golang irc channel, I'm going to ask upstream for a name change to
avoid the issue.

Thanks for your feedback!

-- 
Sergio Talens-Oliag  
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69


signature.asc
Description: PGP signature

Bug#1043027: ITP: tmpl -- A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

[Sergio Talens-Oliag]

El Fri, Aug 04, 2023 at 04:51:50PM +0100, Adam D. Barratt va escriure:
> On Fri, 2023-08-04 at 17:35 +0200, Sergio Talens-Oliag wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sergio Talens-Oliag 
> > 
> > * Package name: tmpl
> >   Version : 0.4.0-1
> >   Upstream Author : krako
> > * URL : https://github.com/krakozaure/tmpl
> > * License : Expat
> >   Programming Lang: Go
> >   Description : A tool to apply variables from cli, env,
> > JSON/TOML/YAML files to templates
> > 
> 
> There's already a "tmpl" binary package in the archive, built from 
> https://tracker.debian.org/pkg/golang-github-benbjohnson-tmpl
> 
> Regards,
> 
> Adam
> 

Yes, just saw that after filling the ITP, in fact I've been asking about it on
the #debian-golang irc channel, I'm going to ask upstream for a name change to
avoid the issue

Thanks for the input!

-- 
Sergio Talens-Oliag  
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69


signature.asc
Description: PGP signature

Bug#1043027: ITP: tmpl -- A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

[Jonas Smedegaard]

Quoting Sergio Talens-Oliag (2023-08-04 17:35:04)
> Package: wnpp
> Severity: wishlist
> Owner: Sergio Talens-Oliag 
> 
> * Package name: tmpl
>   Version : 0.4.0-1
>   Upstream Author : krako
> * URL : https://github.com/krakozaure/tmpl
> * License : Expat
>   Programming Lang: Go
>   Description : A tool to apply variables from cli, env, JSON/TOML/YAML 
> files to templates
> 
>  tmpl
>  .
>  tmpl allows to apply variables from JSON/TOML/YAML files, environment
>  variables or CLI arguments to template files using Golang text/template
>  and functions from the Sprig project.

Package "tmpl" already exists - seemingly from a different source but
also written in Go.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1043027: ITP: tmpl -- A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

[Adam D. Barratt]

On Fri, 2023-08-04 at 17:35 +0200, Sergio Talens-Oliag wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sergio Talens-Oliag 
> 
> * Package name: tmpl
>   Version : 0.4.0-1
>   Upstream Author : krako
> * URL : https://github.com/krakozaure/tmpl
> * License : Expat
>   Programming Lang: Go
>   Description : A tool to apply variables from cli, env,
> JSON/TOML/YAML files to templates
> 

There's already a "tmpl" binary package in the archive, built from 
https://tracker.debian.org/pkg/golang-github-benbjohnson-tmpl

Regards,

Adam

Bug#1043027: ITP: tmpl -- A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

[Sergio Talens-Oliag]

Package: wnpp
Severity: wishlist
Owner: Sergio Talens-Oliag 

* Package name: tmpl
  Version : 0.4.0-1
  Upstream Author : krako
* URL : https://github.com/krakozaure/tmpl
* License : Expat
  Programming Lang: Go
  Description : A tool to apply variables from cli, env, JSON/TOML/YAML 
files to templates

 tmpl
 .
 tmpl allows to apply variables from JSON/TOML/YAML files, environment
 variables or CLI arguments to template files using Golang text/template
 and functions from the Sprig project.

-- 
Sergio Talens-Oliag  
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69


signature.asc
Description: PGP signature

Bug#1042948: O: mtools -- Tools for manipulating MSDOS files

[Chris Lamb]

Diederik de Haas wrote:

> Would it be useful to move it out of your personal namespace to f.e. 'debian'?

Sure thing… Done:

https://salsa.debian.org/debian/pkg-mtools


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Processed: Re: O: mtools -- Tools for manipulating MSDOS files

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:mtools
Bug #1042948 [wnpp] O: mtools -- Tools for manipulating MSDOS files
Added indication that 1042948 affects src:mtools

-- 
1042948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1042948: O: mtools -- Tools for manipulating MSDOS files

[Diederik de Haas]

Control: affects -1 src:mtools

On Thu, 03 Aug 2023 09:31:32 +0100 "Chris Lamb"  wrote:
> Package: wnpp
> 
> I am orphaning this package so that it can be more actively maintained.
> Full Git maintenance history is available - see its Vcs-Git entry.

Would it be useful to move it out of your personal namespace to f.e. 'debian'?

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

Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems

[Andreas Henriksson]

Hello Tobias Heider,

While I'm as entusiastic as anyone else here, I have to ask a few
questions that might be a bit skeptical below...

On Fri, Jul 28, 2023 at 10:00:35PM +0200, Tobias Heider wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tobias Heider 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: u-boot-asahi
>   Version : 2023.04-2
>   Upstream Authors: Mark Kettenis 
>   URL : https://github.com/AsahiLinux/u-boot

This is a development repository and things are sent upstream
to u-boot (mainline). The upstreaming effort is driven by the person you
listed as author (while actual authors is usually someone else AFAIK).

Is there any other u-boot development forks being packaged in Debian and
how viable do you think this is? Is the plan to eventually provide a
migration to u-boot-asahi binary package provided by src:u-boot or how
do you see the future path of this?

Is this targeting Trixie or Experimental?

Is there any particular reason you're targeting u-boot? Are you planning
on working on any installer? Also planning on packaging linux-asahi
development repo?

Do you have contact with upstream about this? They have been very vocal
about distros shipping things that causes additional problems for (users
and then in turn for) the Asahi project in the past.
(Also atleast some Asahi team members are already not publishing their
development git branches because of fear of people dumping them into
distros.)

How does this effort compare against Thomas Glanzmann effort[1]?
Do you plan to provide a migration path (and why would users migrate
over to debian-bananas effort instead of Glansmanns effort)?

(IMHO while Glanzmanns effort is not my preferable packaging style, it
provides a very good stop gap solution until everything has been
mainlined into u-boot, linux, mesa which in turn then and only then
makes it ready for proper Debian packaging. Apart from mainlining work
which hopefully will happen without any assintance from Debian, the
biggest challange is probably to provide a sane installer solution
acceptable for Debian. Is this a task the bananas team intends to take
on?)

Something that I think is missing in Glanzmanns effort is providing
https://github.com/AsahiLinux/alsa-ucm-conf-asahi which is needed
for audio out on the mic/headphone jack. Would be great if these files
found a home in some existing (or possibly new) package in Debian if
you're looking for somewhere to invest your time.
(The alsa-ucm-conf package currently provides all files currently
offered by Debian.)

> * License : GPL-2
>   Description : A u-boot bootloader for Apple silicon systems
> 
[... snip generic u-boot description ...]
> 
> u-boot is used as a second stage bootloader for Linux on M1/M2 Apple macs.

AFAIK and FWIW u-boot is in this case used to provide an EFI(-like)
environment (to be able to use generic distro bootloaders as the next
step in the boot chain).

> This will be maintained by the Debian Bananas team.

I'm not familiar with this team, is there anywhere to read up on its
purpose and background or maybe you can give an introduction to this
team?
I found https://salsa.debian.org/bananas-team which links to the
InstallingDebianOn/Apple/M1 wiki page which has no information
as far as I can see about the Bananas team.

Regards,
Andreas Henriksson

[1]: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian

Bug#1042827: [Pkg-sssd-devel] priv-wrapper?

[Timo Aaltonen]

Simon Josefsson kirjoitti 3.8.2023 klo 22.55:

Timo Aaltonen  writes:

I had a brief look at priv-wrapper packaging, and noticed it only
keeps the debian/ dir in git? The sssd-team packages have the full
upstream git as the base, with packaging added to the packaging
branch. I prefer those will remain like that :)


I usually also do the full git repo with upstream branch for most of the
packages I maintain, but for this new package I wanted to see if keeping
only debian/ in git worked, as I've had success with that in another
package.  What is really the upside of having upstream code in Debian's
git?  One downside is that it wastes space, although I don't think that
matters a lot these days.  Another downside is that it confuses what is
really the "upstream" in case the Debian git-repo's view of what
"upstream" is differs from the real upstream.


How do you pull a new upstream release, download the tarball? I don't 
like working with upstream tarballs as the source of a new release, git 
is much nicer. And it allows using snapshots when needed etc.



Just to clarify, did you mean that you would want priv-wrapper to use
the same style as the other packages, or merely that I shouldn't change
the other sssd-packages to use this debian/-only approach?  I wouldn't
do the latter.  Generally if you feel there is any subjective style
matter you don't agree with, I'm happy to follow what you prefer.  I
prefer to keep priv-wrapper as debian/-only if you think that is okay,
unless I learn some disadvantage with it that I am not aware of yet.


It's fine to have priv-wrapper as-is, no objections there.


/Simon

PS. Changing to your ubuntu.com email address since sending to your
debian.org address results in bounces when debian.org forwards it to
ubuntu.com because debian.org is not authorized to send emails on behalf
of si...@josefsson.org due to (probably) my SPF 'mx -all' preference.  I
think it is a problem with the debian.org forwarder..


Yeah email sucks. I can't send to gmail addresses (with @debian.org) 
because of my smtp provider which has no DKIM..



--
t