Re: How to create a custom Debian ISO

[Paul Wise]

On Sat, 2024-05-11 at 08:21 +, Aditya Garg wrote:

> 1. I want to add a custom kernel that supports my Hardware.
> 2. I want to add my own Apt repo which hosts various software
> packages to support my hardware.

Please consider adding that hardware support to the mainline Linux
kernel and to the Debian Linux kernel packages and to Debian itself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: How to create a custom Debian ISO

[Bernd Zeimetz]

Hi,



> I'm getting error 500 when attempting to open the source code. 

just try again later. Salsa seems to be having issues.


> Also, I'd prefer an offline install since the wifi firmware for the
> t2 Macs is extracted from macOS by the user and copied over to Linux.
> It cannot be redistributed legally.

You can still use the netinstall image. Its smaller, easier to
distribute and you or a user can add new things. You don't need to
distribute large parts of Debian just to replace the kernel and add a
repo.

But at the end the installers are all similar, it shouldn't make a
difference if you modify the netinstall or DVD installer.

Keep in mind that various kernel modules are loaded at install time as
needed, you might need to provide the appropriate udebs for your kernel
or modify the installer to be satisfied with what your kernel provides.

So yes, looking at the reform installer might be a good start.



Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1071262: ITP: libqofonoqext -- Qt bindings for ofono extensions

[Mike Gabriel]

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

* Package name: libqofonoqext
  Version : 1.0.32
  Upstream Contact: https://sailfishos.org/contact/
* URL : https://github.com/sailfishos/libqofonoext.git
* License : LGPL-2.1+
  Programming Lang: C++
  Description : Qt bindings for ofono extensions

 A library for accessing ofono extensions, and a declarative plugin for it.
 .
 This package is required by the Lomiri Addressbook App backend stack.
 .
 This package will be maintained by the Debian UBports Packaging team.

Re: Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

[Prasanna Venkadesh]

On 15 May 2024 12:33:49 am IST, Nilesh Patra  wrote:
>On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote:
>>It seems, there is no packaging team available yet for Nim lang.
>>I am not looking for co-maintainers, it's not complex.
>
>There does exist a nim team.
>
>   https://salsa.debian.org/nim-team

Oh! I couldn't find the team in this wiki https://wiki.debian.org/Teams

In that case, I would like the package to be managed under the team. I also 
notice that the package names for libraries follow nim-* pattern.

How about hybrids, when its both a CLI app & a library?

What are my next steps?




>
>Best,
>Nilesh

Bug#1071286: ITP: mkcal -- SQlite storage backend for KCalendarCore development files

[Mike Gabriel]

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

* Package name: mkcal
  Version : 0.7.26
  Upstream Contact: https://sailfishos.org/contact
* URL : https://github.com/sailfishos/mkcal.git
* License : LGPL-2+
  Programming Lang: C++
  Description : SQlite storage backend for KCalendarCore development files

 Extends KDE calendar core library and provides an SQlite backend.
 .
 Required by Lomiri's calendar / contacts (new) storage backend.
 .
 This package will be maintained by the Debian UBports Packaging Team.
 Co-maintenance by the KDE team welcome (if required).

Re: Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

[Nilesh Patra]

On Fri, May 17, 2024 at 08:52:00PM +0530, Prasanna Venkadesh wrote:
> 
> 
> On 15 May 2024 12:33:49 am IST, Nilesh Patra  wrote:
> >On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote:
> >>It seems, there is no packaging team available yet for Nim lang.
> >>I am not looking for co-maintainers, it's not complex.
> >
> >There does exist a nim team.
> >
> > https://salsa.debian.org/nim-team
> 
> Oh! I couldn't find the team in this wiki https://wiki.debian.org/Teams
> 
> In that case, I would like the package to be managed under the team. I also 
> notice that the package names for libraries follow nim-* pattern.
> 
> How about hybrids, when its both a CLI app & a library?

I suppose you need to name a package in a way that has more weight. Is it more
likely to be used by end users as a library or application? Name the source
package based on what makes more sense. As for battinfo, it makes more sense to
have an application name (battinfo instead of nim-battinfo).

> 
> What are my next steps?

You could contact the owners of nim team to grant you access to the salsa
namespace. If there's too much delay/you are in a hurry, you could use another
namespace for now.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1071287: ITP: golang-github-aymanbagabas-go-osc52-v2 -- Golang terminal ANSI OSC52 wrapper

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-github-aymanbagabas-go-osc52-v2
  Version : 2.0.1
  Upstream Contact: Ayman Bagabas 
* URL : https://github.com/aymanbagabas/go-osc52
* License : Expat
  Programming Lang: Go
  Description : Golang terminal ANSI OSC52 wrapper

  A terminal Go library to copy text to clipboard from anywhere.
  It does so using ANSI OSC52. The Copy() function defaults to
  copying text from terminals running locally.

Bug#1071126: Info received (Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 w...@debian.org
 Prasanna Venkadesh 

If you wish to submit further information on this problem, please
send it to 1071...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

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

About i386 support

[Victor Gamper]

Hello everyone,
Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?
If so, I'd like to ask to reconsider this seeing as there is still a
plethora of i386 machines and i386 is as of now still the
second most used architecture according to popcon with 8437
reports there, if I understand correctly.
I personally use the i386 version on multiple machines,
including a ThinkPad T60 (on which I'm writing this on) and a
Transmeta Efficeon, which I'm using as a router and access point.

I personally don't understand why you'd want to deprecate i386,
especially if you compare it to other official architectures
(s390, ppc64el and armel have way less reports on popcon. I don't
want to suggest to deprecate any of these architectures, but just
compare the amount of users there). For many tasks an i386
machine still offers more than enough capabilities and deprecating
i386 now would brick many otherwise completely functional machines.

Just not shipping an i386 iso would still be deprecating an architecture,
as many people don't have the knowledge and/or patience to set up
debian over debootstrap which would again practically brick i386 machines
for many users. Also, deprecating i386 would probably make it
difficult or downright impossible for downstream distributions to
themself keep the i386 version maintained,
as they'd have to invest much more effort to keep i386.

Is there a reason to do this? If so, what would be required to keep
the i386 version, seeing as it still is important and used?

regards,
Maite Gamper (zeldakatze)

Re: About i386 support

[Johannes Schauer Marin Rodrigues]

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep the i386
> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other areas
which are needed to keep i386 more alive for longer?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: About i386 support

[Thomas Hochstein]

Victor Gamper wrote:

> Is there a reason to do this? If so, what would be required to keep
> the i386 version, seeing as it still is important and used?

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

> > what would break where, and how to fix it? I only found autopkgtest
> so
> > far, which uses /tmp/ in the guest and expects it to survive across
> > reboots, and I have a MR up already for that. Anything else?
> 
> Perhaps whatever makes these files in /tmp? i think something to do
> with
> X/gdm/gnome?
> 
> /tmp/.X0-lock
> /tmp/.X1024-lock
> /tmp/.X1025-lock
> 
> /tmp/.X11-unix
> /tmp/.X1-lock
> 
> /tmp/.XIM-unix
> 
> /tmp/.font-unix
> 
> /tmp/.ICE-unix

These are all already covered by /usr/lib/tmpfiles.d/x11.conf

-- 
Kind regards,
Luca Boccassi


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

Re: About i386 support

[rhys]

That depends. What would be required of such a person? I also have several 
i386-class machines that run Debian (though only one that can run Debian 12). 

--J 

Sent from my mobile device.

From: Johannes Schauer Marin Rodrigues 
Sent: Friday, May 17, 2024 15:48
To: Victor Gamper; debian-devel@lists.debian.org
Subject: Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep the i386
> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other areas
which are needed to keep i386 more alive for longer?

Thanks!

cheers, josch

Re: About i386 support

[Paul Gevers]

Hi

On 17-05-2024 9:58 p.m., Victor Gamper wrote:

Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?


Our current position is described here: 
https://lists.debian.org/debian-devel-announce/2023/12/msg3.html


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature