Re: ARM architectures

[Andrei POPESCU]

On Sb, 05 iun 21, 19:01:36, Adam Borowski wrote:
> On Sat, Jun 05, 2021 at 03:04:45PM +0300, Andrei POPESCU wrote:
> 
> > The PINE A64+ (2 GB RAM) is very stable for me, unless I put significant 
> > load on the USB connection (specifically *heavy* writing to an external 
> > HDD in a powered enclosure), but it could also be a power issue.
> 
> It's only USB2 -- in a board that has reliable gigabit ethernet.  Plus,
> there's no such thing as stable USB-connected disk, anywhere.

Yeah, learned that the hard way. SATA (or better) is a must for any 
storage application (NAS, etc.).

SATA-to-USB adapters can have other subtle side effects as well, like 
messing the detection of 4K blocks. Apparently SMART could also be an 
issue, though it seemed to work for me.

> I'd recommend using nbd instead.

Sure, unless the device is the one with all the storage ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: ARM architectures

[Ralph Aichinger]

Hello, hope this works, am not normally subscribed to debian-devel

> If you'd have took time to explain the real reason behind why choosing a
> RPi4 maybe a good idea versus simply saying they are better than other
> choices. Then I would have considered much more knowledgeable your
> opinions and fact based.

May I chime in with another vote for the RPi4? 

I've been using the RPi family of boards since the first revision 
years ago continuously, and before that I had used the sheevaplug
family of ARM systems, all running 24/7. My sheevaplugs died from 
the typical power supply failures, the first incarnations of the
RPi were really a pain, especially when it came to flaky USB support.

But with all justified criticism oft the RPi foundation, there 
has been one theme in all these years: The Raspberry Pi foundation
really does the work of improving their products. They do not deny
problems. If they mess up (producing boards that can be crashed with
camera flashes or incorrectly wired USB-C ports) they do not hide this
fact, but are very open about it. And -- unlike many manufacturers
of cheap chinese boards -- they improve their stuff by working on
firmware, hardware improvements etc. They do not just "forget" their
"old" boards after two years or so, but improve their stuff
continuously. Yes, they should still be more open and have less blobs
in their firmware, but their track record IHMO is one that shows in
the right direction.

Since about the RPi2 or RPi3 generation the Raspberry Pi has become
incredibly stable. It is really in no way less reliable than amd64 
stuff. With the RPi4 there has been another development: While before
you had to use the Raspbian/PiOS flavoured binaries, since a while
booting vanilla Debian on RPi4 not only works just fine, but gives
you an excellent, clean, stable and fast 64 bit ARM system.

I am running the RPi 4 in various server duties for months now as 
Vanilla Debian 64bit bullseye systems, without having any problems, and
without them being any different from amd64, really.

Everything is stable, and while I cannot speak for GUI stuff (I use the
systems headlessly as servers) the only thing really missing from my setup
are WiFi drivers of the embedded WiFi components. Not that I miss them.

My setup for continuously running low power servers is currently:

Raspberry Pi 8GB (or 4GB) (€75?)

Akasa Gem Pro Aluminium Case (about €30), yes, this is expensive
but it gives incedibly good cooling for a board that needs some
cooling under load. And it looks attractive, to me this is important
in some home settings. No fans to make noises or break. 

Official RPi4 Power Supply (€6-10) in white. This is stable and
cheap. It has 0.1V or so higher output voltage than typical
chargers, this helps. White is better to me, because about 
every other power brick is black, makes them easier to find
in a dark rack.

Western Digital WD My Passport SSD Mobile 512GB (the black/silver
one): First bought this because I read about people using this on
their RPis, and have not regretted it. No problems at all in 
years of usage. It is expensive at about 95€ or so currently. It
is powered from the USB-port of the RPi without any trouble.
No USB errors, no power problems, no overheating in countinuous
use in a warm server rack, etc.

Yes, I could buy a cheap Nuc-Box for all that money, but it would
use quite a bit more power in the long run. I do realize, that 
above components are quite the "luxury setup" when it comes to
buying RPi accessories. Above setup has been running for 3? Years
now (first with a RPi3, then RPi4 4GB Raspbian, then RPi4 8GB 
Vanilla Debian 64 bit) without any problems or instabilities.
Before the SSD i had used various HDs. I never had luck with
SD cards, they always gave me trouble. The RPi4 does no longer
need a card to boot, and I am very happy about that. Before I 
had them mounted read only. Ah, and the Akasa case is a new
addition, before I had open boards with aluminium coolers on
them. The RPi4 does need a bit of cooling/spreading out heat.

> I'd prefer a 64 bit solution.

> I cited those ARM Cortex A7 because you seem to say all of them we're
> limited to 1 GB and dual core.

Then go this way: RPi4 8GB, Debian Vanilla arm64:

https://www.raspberrypi.org/forums/viewtopic.php?t=282839

This is really the best way IMHO to install Debian on these
boards. The install matches very closely other architectures,
there are almost no differences or specific things to the RPi
architecture in this setup. Just follow all the steps, it works
perfectly.

This setup is really much closer to a pure Debian system than
anything else I have found till now. You get a machine with
UEFi, that looks and acts like a "normal" PC. I do understand
that this might be not to everybodys liking, but it makes 
installing Debian so easy, without any exotic workarounds. 

/ralph

Re: ARM architectures

[Marc Haber]

On Sat, 5 Jun 2021 13:19:10 -0400, Polyna-Maude Racicot-Summerside
 wrote:
>I think you didn't get much what I said...

Probably.

>If you'd have took time to explain the real reason behind why choosing a
>RPi4 maybe a good idea versus simply saying they are better than other
>choices. Then I would have considered much more knowledgeable your
>opinions and fact based.

I apologize for assuming knowlegde.

I personally prefer the Raspi 4 because it can run plain Debian in a
way supported by a Debian Developer, and their overwhelming market
share in nearly all segments greatly increases the possibility of
finding solutions for problems that might arise, and developer
motivation for fixing issues that appear on the platform.

>I cited those ARM Cortex A7 because you seem to say all of them we're
>limited to 1 GB and dual core.

I didnt say that. I gave that as the reason for specifically phasing
out MY Banana Pi machines. You'll surely leave the decision what I do
with MY hardware to me, or do I need your permission for throwing the
Bananas out?

>Also, there's a balance between price, size, power consumption...

Right. You cannoot expect a ten year old platform to be able to
compete with the bang-for-the-buck or the bang-for-the-watt factors of
current hardware. I'd prefer a modern dual core over a ten year old
quad core any time.

When comparing the Banana Pi with the Raspberry Pi 4, one is actually
comparing a ten year old dual core with a four year old quad core.

>Does the RPi4 is totally 64 bit ?

It can run plain Debian arm64. Is that "total 64 bit"?
As far as I know, it can also run 32bit flavors of Linux, but I don't
know whether a multi-arch installation is possible.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: ARM architectures

[Marc Haber]

On Sun, 6 Jun 2021 05:44:21 +, Paul Wise  wrote:
>On Sat, Jun 5, 2021 at 4:28 PM Marc Haber wrote:
>
>> I haven't advanced to package cross-building yet.
>
>Some resources related to that:
>
>http://crossqa.debian.net/
>https://wiki.debian.org/CrossCompiling

Thanks!

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: ARM architectures

[Aaron Dewes]

I personally prefer the Raspi 4 because it can run plain Debian in a
way supported by a Debian Developer


I'm interested in this version, do you know how it is built (Manually,
or is there a build script to verify the images)?


Does the RPi4 is totally 64 bit ?

It can run plain Debian arm64. Is that "total 64 bit"?
As far as I know, it can also run 32bit flavors of Linux

This is the default OS they provide, the 64 bit version is still hidden
as Beta.

but I don't know whether a multi-arch installation is possible.


The official Raspberry Pi OS (the arm64 version of it) supports both
armhf and arm64 debian packages out of the box (And has support for
these enabled in dpkg).

Greetings

Aaron

Re: ARM architectures

[Andrey Rahmatullin]

On Sun, Jun 06, 2021 at 12:43:53PM +0200, Aaron Dewes wrote:
> > I personally prefer the Raspi 4 because it can run plain Debian in a
> > way supported by a Debian Developer
> 
> I'm interested in this version, do you know how it is built (Manually,
> or is there a build script to verify the images)?
https://raspi.debian.net/daily-images/ may be helpful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: ARM architectures

[Ralph Aichinger]

On Sun, 2021-06-06 at 12:43 +0200, Aaron Dewes wrote:
> > I personally prefer the Raspi 4 because it can run plain Debian in
> > a
> > way supported by a Debian Developer
> 
> I'm interested in this version, do you know how it is built
> (Manually,
> or is there a build script to verify the images)?

If you go that route here:

https://www.raspberrypi.org/forums/viewtopic.php?t=282839

you install using the official netinst images from ftp.debian.org,
so this ist built just the same way that amd64 is (on Debian
infrastructure with official tooling). As you use the official
installer, there is also no weird preseeding of host keys or 
other questionable practices.

> The official Raspberry Pi OS (the arm64 version of it) supports both
> armhf and arm64 debian packages out of the box (And has support for
> these enabled in dpkg).

Yes, but when I update my rasbperry pis and my amd64 boxes, I really
get identical versions from the same servers. My /etc/apt/sources.list
reads like:

# deb cdrom:[Debian GNU/Linux testing _Bullseye_ - Official Snapshot
arm64 NETINST 20210521-08:45]/ bullseye main
deb http://ftp.debian.org/debian bullseye main contrib non-free

You cannot really get much more vanilla than that.

/ralph

Re: Bug#989523: RFP - Nanosaur - An OpenSource Port of PangeaSoft‘s MacOS Game for modern systems

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist

On Du, 06 iun 21, 10:58:32, Sarah wrote:
> Package: Nanosaur
> > Project Page: > https://github.com/jorio/nanosaur
> >
> > Context: Nanosaur is a 1998 Macintosh game by Pangea Software. In it, 
> > you’re a cybernetic dinosaur from the future who’s sent back in time 20 
> > minutes before a giant asteroid hits the Earth. And you get to shoot at 
> > T-Rexes with nukes. Nanosaur > was bundled with the original iMac and ran 
> > on Mac OS 8. It’s also notable for being a prominent showcase of QuickDraw 
> > 3D’s capabilities, which was Apple’s high-level 3D graphics API during the 
> > 90s. In 1999, Pangea released>  > Nanosaur’s source code 
> > >  > to the public. This 
> > port is based on that release.
> >
> > Build Information: > https://github.com/jorio/Nanosaur/blob/master/BUILD.md
> >
> > (Relies on OpenGL, > libsdl2-dev,…)
> > ​
> >
> >

Reassigning to correct (pseudo)-package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Re: Bug#989524: RFP - Bugdom - An OpenSource Port of Pangea Software's Bugdom for modern systems

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist

On Du, 06 iun 21, 10:59:03, Sarah wrote:
> Package: Bugdom 
> 
> > Project Page: > https://github.com/jorio/Bugdom
> >
> > License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 
> > International Public License (> 
> > https://github.com/jorio/Bugdom/blob/master/LICENSE.md> )
> >
> > Build Information: > https://github.com/jorio/Bugdom/blob/master/BUILD.md
> > (For the Moment Bugdom relies on jorio‘s custom fork of Quesa)
> >
> >

Reassigning to correct (pseudo-)package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#989527: ITP: python-markuppy -- module to generate HTML/XML content

[Carsten Schoenert]

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

* Package name: python-markuppy
  Version : 1.14
  Upstream Author : Tyler Bakke 
* URL : https://pypi.org/project/MarkupPy
* License : MIT public-domain
  Programming Lang: Python
  Description : module to generate HTML/XML content

 MarkupPy is a Python module that attempts to make it easier to generate
 HTML/XML from a Python program in an intuitive, lightweight,
 customizable and pythonic way.

MarkupPy is derived from markup.py.
There is a GitHub project for this library, unfortunately it's lagging
far behind the visible data on PyPi.

https://github.com/tylerbakke/MarkupPy

This library is a new build and install dependency for python3-tablib
which I intend updating to the current usptream version.

This package will get maintained within The Python Modules Team.

Bug#989528: ITP: kquickimageeditor -- Image editing components

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-qt-...@lists.debian.org

* Package name: kquickimageeditor
  Version : 0.1.3
  Upstream Author : Carl Schwan 
* URL : https://invent.kde.org/libraries/kquickimageeditor
* License : LGPL-2.1-or-later
  Programming Lang: C++
  Description : Image editing components

A QtQuick plugin providing Image editing components.

This package will me maintained in the Debian Qt/KDE group.

Bug#989529: ITP: neochat -- Client for Matrix chat

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-qt-...@lists.debian.org

* Package name: neochat
  Version : 1.2.0
  Upstream Author : 2020 Carl Schwan 
2020 Noah Davis 
2020 Tobias Fella 
2021 Srevin Saju 
(and others)
* URL : https://invent.kde.org/network/neochat
* License : GPL-2+ etc
  Programming Lang: C++
  Description : Client for Matrix chat

A client for matrix, the decentralized communication protocol.

This package will be maintained in the Qt/KDE group.

Re: ARM architectures

[Christoph Biedl]

Marc Haber wrote...

> On Sat, 5 Jun 2021 10:50:20 +0200, Christoph Biedl
>  wrote:

> >For me, the biggest downside of the RPi4 is the need for an extra power
> >plug as they take up to three amps - while for example a BananaPi can be
> >powered using some unused USB (<= 3.0) port.
>
> Mine run via PoE very nicely. The hat kind of destroys the form factor
> though and it runs warm.

Good to know, but not always an option in my situations.

> >For CPU-hungry tasks (package building) I've switched from a CubieTruck
> >to an RPi4 a few months ago and the performance boost was mindblowing.
>
> My Raspi Kernels are being cross-built. Wasn't it you who taught me
> to? I haven't advanced to package cross-building yet.

Possibly, and I still cross-build the kernels today, including doing nasty
things like

dh_gencontrol -DArchitecture=armel (...)

that might some people make kick me off the Debian boat. Luckily, none
of this is public.

For any other package (personal, private backports, modified packages)
I've switched to native building a long time ago. At least using the
qemu-user-static binaries caused a lot of trouble, especially if
threading was involved. Also the emulation overhead resulted in build
times close to doing it on (slower) native hardware. I guess the
situation has improved in the past years, at least mixing endianesses
should no longer triggers instant segfaults from ld (never checked), but
I've lost trust in the entire idea.

Christoph


signature.asc
Description: PGP signature

Re: ARM architectures

[Marc Haber]

On Sun, 6 Jun 2021 12:43:53 +0200, Aaron Dewes 
wrote:
>> I personally prefer the Raspi 4 because it can run plain Debian in a
>> way supported by a Debian Developer
>
>I'm interested in this version, do you know how it is built (Manually,
>or is there a build script to verify the images)?

Guido has documented that.

But I also like the way cited in this thread using the UEFI loader and
the plain Debian installer. Will try that next week.

>The official Raspberry Pi OS (the arm64 version of it) supports both
>armhf and arm64 debian packages out of the box (And has support for
>these enabled in dpkg).

So it is multi-arch arm64/armhf? Nice.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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: Figuring how to work with team-maintained packages on salsa

[Sean Whitton]

Hello Helmut,

On Fri 04 Jun 2021 at 08:49PM +02, Helmut Grohne wrote:

> On Fri, Jun 04, 2021 at 07:43:59PM +0200, Florian Weimer wrote:
>> I want to add a few patches to this repository:
>>
>>   
>>
>> Surely there must be some tool support to help with that?  I know how
>> to do it manually (perhaps even involving quilt).  Has every Debian
>> developer their own script for that?  (It's like this in RPM land …)
>
> There is no homogeneity on git repositories. The sad truth is that if
> you want to work with arbitrary packages in a homogeneous way, it is
> best to avoid git entirely and work with .debdiffs instead. Eventually,
> dgit might solve this, but its adoption still is fairly low.

dgit has already mostly solved working with arbitrary packages in a
homogeneous way -- `dgit clone` gets you something standard, and you can
then just cherry-pick/format-patch your work to share with the
maintainer.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Figuring how to work with team-maintained packages on salsa

[Sean Whitton]

Hello,

On Sun 06 Jun 2021 at 11:20AM -07, Sean Whitton wrote:

> Hello Helmut,
>
> On Fri 04 Jun 2021 at 08:49PM +02, Helmut Grohne wrote:
>
>> On Fri, Jun 04, 2021 at 07:43:59PM +0200, Florian Weimer wrote:
>>> I want to add a few patches to this repository:
>>>
>>>   
>>>
>>> Surely there must be some tool support to help with that?  I know how
>>> to do it manually (perhaps even involving quilt).  Has every Debian
>>> developer their own script for that?  (It's like this in RPM land …)
>>
>> There is no homogeneity on git repositories. The sad truth is that if
>> you want to work with arbitrary packages in a homogeneous way, it is
>> best to avoid git entirely and work with .debdiffs instead. Eventually,
>> dgit might solve this, but its adoption still is fairly low.
>
> dgit has already mostly solved working with arbitrary packages in a
> homogeneous way -- `dgit clone` gets you something standard, and you can
> then just cherry-pick/format-patch your work to share with the
> maintainer.

Sorry, that reply was a too quick, not taking adequate account of what
Helmut wrote.

If you want to produce patches/commits to share with the maintainer,
then `dgit clone` enables you to work with arbitrary packages in a
homogeneous way, regardless of adoption of `dgit push`.  It can also
help you NMU; see dgit-nmu-simple(7).  I am not sure what Helmut has in
mind with the mention of .debdiffs -- could you perhaps explain why you
feel you have to fall back to these, even with dgit?

What dgit doesn't really help you with is integrating those patches
directly into the maintainer's repo, if the maintainer invites you to
push your changes directly, which is perhaps what Florian was looking
for.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Figuring how to work with team-maintained packages on salsa

[Helmut Grohne]

Hi Sean,

On Sun, Jun 06, 2021 at 11:40:47AM -0700, Sean Whitton wrote:
> If you want to produce patches/commits to share with the maintainer,
> then `dgit clone` enables you to work with arbitrary packages in a
> homogeneous way, regardless of adoption of `dgit push`.  It can also
> help you NMU; see dgit-nmu-simple(7).  I am not sure what Helmut has in
> mind with the mention of .debdiffs -- could you perhaps explain why you
> feel you have to fall back to these, even with dgit?

For one thing, you answer your question below and I think this also is
what Florian was looking for.

There is another issue affecting me, that may derail from the original
topic. When I work with packages I tend to fix bugs that are reported by
some CI system on unstable. When I dgit clone, I may get the unstable
version or I may get unreleased changes that may work or may be broken.
That's not what I want. Instead, I strongly prefer working with exactly
that version that produced the failure in CI. Even accidentally using
experimental often produces wildly differing results. Beyond that, I
don't want my trust root for software to reside in SSL certificates. I
haven't found a way to ask dgit to produce a git tree that exactly
produces the source package signed by unstable reliably.

Admittedly, not working with unreleased changes makes integrating them
harder for the maintainer. That's certainly a trade-off between my time
and their time. I've chosen that I'm unwilling to work with unreleased
changes of arbitrary packages. Their quality is too unpredictable to me.

> What dgit doesn't really help you with is integrating those patches
> directly into the maintainer's repo, if the maintainer invites you to
> push your changes directly, which is perhaps what Florian was looking
> for.

Yes, that. debdiff kinda is the universal format here as it is
recommended in the developers reference and can be produced for
arbitrary packages. bugs.debian.org is a universal communication method
to package maintainers. It's a bit annoying, but universal (inside
Debian).

Thinking more about this, there is one project of Jelmer that is getting
closer to reintegrating changes. It is silver-platter, which really
attempts to grok maintainers' idiosyncrasies and produce patches in the
way they desire. As far as I know, it actually works with a significant
portion of the archive already as it backs janitor.d.n.

If everyone was using dgit, then yes it would be providing that
homogeneity much like dh does provide homogeneity on the packaging
helper level now. The way it currently is, dgit unfortunately is
https://xkcd.com/927/ (standards). We really cannot have both workflow
diversity and homogeneity. Either of them must be unhappy and dgit
chooses not to make the workflow diversity people unhappy. The price for
homogeneity is telling a significant number of people that they cannot
continue using their workflow and making them very unhappy that way.

Helmut

Re: Figuring how to work with team-maintained packages on salsa

[Daniel Leidert]

Am Freitag, dem 04.06.2021 um 19:43 +0200 schrieb Florian Weimer:
> I want to add a few patches to this repository:
> 
>   
> 
> Surely there must be some tool support to help with that?  I know how
> to do it manually (perhaps even involving quilt).  Has every Debian
> developer their own script for that?  (It's like this in RPM land …)

Looks like an "overlay"-layout (debian/-only approach). I'd suggest to fork the
repository, download the tarball to some directory using apt-get source -d, and
create .git/gbp.conf enabling the overlay layout, setting debian-dir to "sid"
or using ignore-branch, and possibly defining tarball-dir.

E.g.
https://salsa.debian.org/ruby-team/ruby-jekyll-titles-from-headings/-/blob/debian/sid/debian/gbp.conf

Then you can use `gbp buildpackage` to export the source, work in it, create
patches, add those patches to git (I'd like to see `gbp pq` handle this layout
though - it would make things a lot easier). Then create a merge request.

To be honest there are different layouts, but just a few. IMHO one can easily
learn them. I haven't seen anything unusable with git-buildpackage yet.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Re: ARM architectures

[Paul Sutton]

On 06/06/2021 11:43, Aaron Dewes wrote:

I personally prefer the Raspi 4 because it can run plain Debian in a
way supported by a Debian Developer


I'm interested in this version, do you know how it is built (Manually,
or is there a build script to verify the images)?


Does the RPi4 is totally 64 bit ?

It can run plain Debian arm64. Is that "total 64 bit"?
As far as I know, it can also run 32bit flavors of Linux

This is the default OS they provide, the 64 bit version is still hidden
as Beta.

but I don't know whether a multi-arch installation is possible.


You would think, as the Raspberry Pi is about education and learning 
about coding, it would be easier to get involved with testing etc.


Would be good to help test or at least do have the 64 bit downloadable 
easily (with warnings of course) so it can be tested.  I am hopefully 
running a CoderDojo once we are back up out of lock down in the UK.


Paul



OpenPGP_signature
Description: OpenPGP digital signature