Question about Debian build infrastructure

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about Debian build infrastructure

Kyle Edwards
Hello all,

I have been preparing Ubuntu releases for CMake on our own APT
repository for several months now. We did this by preparing our own
repository infrastructure - we have a machine that builds packages, and
a machine that hosts an Aptly instance and pushes the repository to our
web server. However, all of these things had a lot of manual steps to
set up and use, and I'm wondering how Debian handles this problem. Here
are some of my questions:

1. What software do the official Debian repositories use? Do they use
Aptly or reprepro or something else? Is there a downloadable OS image
which comes with this pre-set up? Does it run on a cron job or does it
have some sort of continuous monitoring? (We have ours run on a cron
job every 10 minutes.)
2. According to https://wiki.debian.org/BuilddSetup, there seems to be
a distinction between the build broker (wanna-build) and the build
workers (buildd). Do either of these roles have their own OS images one
can download?
3. I understand that source packages are signed by developers before
being sent to the build farm, but what about the binary packages built
by the build farm and uploaded to the repository? Do the build farm
servers have their own GPG keys? Does the repository server recognize
these keys?

Thanks in advance, all this info would be helpful for me as I expand
our Ubuntu build infrastructure.

Kyle

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Matthias Klumpp
Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards
<[hidden email]>:

>
> Hello all,
>
> I have been preparing Ubuntu releases for CMake on our own APT
> repository for several months now. We did this by preparing our own
> repository infrastructure - we have a machine that builds packages, and
> a machine that hosts an Aptly instance and pushes the repository to our
> web server. However, all of these things had a lot of manual steps to
> set up and use, and I'm wondering how Debian handles this problem. Here
> are some of my questions:

Hello! :-)
I am not involved with either the ftpmasters team or the wanna-build
admins, but I did set up infrastructure like this a few times already.
For the last time for the PureOS derivative and for the first time for
the Tanglu derivative where the goal was to explicitly "use what
Debian uses", so I gained quite a bit of insight into the process.
Some information I have may be dated by now though, so please correct
me in these cases.

> 1. What software do the official Debian repositories use? Do they use
> Aptly or reprepro or something else?

The main Debian repositories use dak, the Debian Archive Kit.
You can find more information on it at [1] and get its code on Salsa at [2].
Dak was written specifically for Debian's needs and was in the past
quite Debian-specific with lots of hardcoding of Debianisms (like
suite names) and expectations on the host environment. This has
changed quite a bit in the past few years, and while there are still a
bunch of Debian-hardcoded parts, dak is generally useful for
non-Debian repositories as well.
Its setup is still orders of magnitudes more complex than using
reprepro or Aptly (you will need to write some dedicated scripts for
your distribution), but for huge package repositories it is from my
experience one of the most performant and painless options. You also
gain all the features the Debian archive has instantly.
If your repository is small though, using dak may be overkill - it
really shines if you have thousands of packages, with just a few
reprepro could get the job done easier with less manual work.

> Is there a downloadable OS image which comes with this pre-set up?

No, unfortunately not.

> Does it run on a cron job or does it
> have some sort of continuous monitoring? (We have ours run on a cron
> job every 10 minutes.)

Dak actions are triggered by multiple cronjobs which run different
actions. There is one to process incoming uploads which runs roughly
every 15min, hourly, daily, weekly and monthly cleanup and
statistics-generating actions as well as the "dinstall" task which
will run about 4 times a day and publish new packages in the archive
so users can access them. The dinstall task is actually comprised of
many individual actions, which deal with different aspects of the
archive (e.g. translations and AppStream metadata), so summarizing it
is not that easy.
In order to not have the autobuilder network wait on publication, dak
can maintain special queues for the builders to fetch packages from
prior to them being published officially.

> 2. According to https://wiki.debian.org/BuilddSetup, there seems to be
> a distinction between the build broker (wanna-build) and the build
> workers (buildd). Do either of these roles have their own OS images one
> can download?

AFAIK there are no OS images, but I would bet that the buildd machines
have an Ansible recipe or something similar somewhere, as those are
continuously updated and refreshed. I would strongly advise against
using wanna-build for anything - when I tried to use it in the past
that attempt turned out to be virtually impossible because there was
no documentation on it and it heavily relied on grown structures
within Debian itself. If you dig into it, you will also find some
interesting historical trivia, e.g. apparently in the past an
autobuilder was building a package and then sending the build log to a
developer, which then looked over it, signed it and submitted it back
to get the build actually accepted in the archive.
So, IMHO wanna-build is really not something that should be used in
new projects...

> 3. I understand that source packages are signed by developers before
> being sent to the build farm, but what about the binary packages built
> by the build farm and uploaded to the repository? Do the build farm
> servers have their own GPG keys?

Indeed they have - they sign the package with their own key which is
valid for binary uploads of the builder's respective architecture.

> Does the repository server recognize
> these keys?

Yes, they do - builders are registered with dak as well.

> Thanks in advance, all this info would be helpful for me as I expand
> our Ubuntu build infrastructure.

I don't know how about the scale of your build farm, but if it is a
small-ish amount of packages, using Jenkins+reprepro may be all you
need. For bigger things, I had some success with Debile[3] in the past
which was building all of Tanglu for a while and was used within
Debian for builds and tests. Unfortunately that project seems to be
dead now.
Launchpad and the Open Build Service[4] may also be very interesting
options. The Open Build Service comes with a few of its own problems
(by being designed for RPM in the first place), but in general it is
very neat and may be exactly what you want for this usecase - it's
definitely a solution to look into, and I know some people use it to
manage repositories for internal deployments.

When making Tanglu we threw a lot of Debian code and new code together
and came up with a Debian-like solution in the end, complete with
non-reusable now Tanglu-specific parts. After I learned that a lot of
people actually want to set up some more advanced repository
management and I also had to do all of the things again for PureOS, I
started to develop a software called "Laniakea"[5] out of the code
that was already running Tanglu.
Laniakea is (currently) built around dak and takes over a lot of
archive maintenance and QA tasks, including package building. For
package building, Laniakea has its own master server and a worker
software, which in turn builds packages in systemd-nspawn containers
via debspawn[6].
Laniakea is a complete suite of tools which one day should make
setting up a new Debian derivative a matter of few commands, but sadly
we are not there yet and using it is still a bit experimental - there
is just too many changes still happening in the project, and test
coverage lousy.
(With the exception for debspawn, that's a handy tool).

So, tl;dr, maybe reprepro/Jankins/Aptly is actually what you need here
(assuming you don't have hundreds of packages). If you want, look at
Open Build Service, and if you feel adventurous try out dak &
Laniakea.

Hope this helps! (this reply in the end contained a lot more opinion
pieces than I originally wanted to have)

Cheers,
    Matthias

[1]: https://wiki.debian.org/DebianDak
[2]: https://salsa.debian.org/ftp-team/dak
[3]: https://github.com/opencollab/debile
[4]: https://openbuildservice.org/
[5]: https://github.com/lkorigin/laniakea
[6]: https://github.com/lkorigin/debspawn
[7*]: Laniakea's web UI can be viewed at https://master.pureos.net/
and https://software.pureos.net/ to get an impression of what it
currently does.

--
I welcome VSRE emails. See http://vsre.info/

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

smcv
On Sat, 08 Jun 2019 at 02:25:44 +0200, Matthias Klumpp wrote:

> Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards
> <[hidden email]>:
> > 2. According to https://wiki.debian.org/BuilddSetup, there seems to be
> > a distinction between the build broker (wanna-build) and the build
> > workers (buildd). Do either of these roles have their own OS images one
> > can download?
>
> AFAIK there are no OS images, but I would bet that the buildd machines
> have an Ansible recipe or something similar somewhere, as those are
> continuously updated and refreshed.

I think the Debian sysadmin team (DSA) use Puppet for this.
<https://salsa.debian.org/dsa-team/mirror/dsa-puppet/> is a public mirror.

> Launchpad and the Open Build Service[4] may also be very interesting
> options. The Open Build Service comes with a few of its own problems
> (by being designed for RPM in the first place), but in general it is
> very neat and may be exactly what you want for this usecase - it's
> definitely a solution to look into, and I know some people use it to
> manage repositories for internal deployments.

My employer (Collabora) uses OBS for Debian derivatives, but we've had
to make some changes to make it work better with .dsc/.deb. I'm not sure
how many of our changes have gone upstream already and how many are still
delta in the Debian packages; at one point we also had downstream delta
beyond what's in Debian, but I hope that has all been fixed now.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Kyle Edwards
In reply to this post by Matthias Klumpp
On Sat, 2019-06-08 at 02:25 +0200, Matthias Klumpp wrote:

> Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards
> <[hidden email]>:
> >
> >
> > Hello all,
> >
> > I have been preparing Ubuntu releases for CMake on our own APT
> > repository for several months now. We did this by preparing our own
> > repository infrastructure - we have a machine that builds packages,
> > and
> > a machine that hosts an Aptly instance and pushes the repository to
> > our
> > web server. However, all of these things had a lot of manual steps
> > to
> > set up and use, and I'm wondering how Debian handles this problem.
> > Here
> > are some of my questions:
> Hello! :-)
> I am not involved with either the ftpmasters team or the wanna-build
> admins, but I did set up infrastructure like this a few times
> already.
> For the last time for the PureOS derivative and for the first time
> for
> the Tanglu derivative where the goal was to explicitly "use what
> Debian uses", so I gained quite a bit of insight into the process.
> Some information I have may be dated by now though, so please correct
> me in these cases.
>
> >
> > 1. What software do the official Debian repositories use? Do they
> > use
> > Aptly or reprepro or something else?
> The main Debian repositories use dak, the Debian Archive Kit.
> You can find more information on it at [1] and get its code on Salsa
> at [2].
> Dak was written specifically for Debian's needs and was in the past
> quite Debian-specific with lots of hardcoding of Debianisms (like
> suite names) and expectations on the host environment. This has
> changed quite a bit in the past few years, and while there are still
> a
> bunch of Debian-hardcoded parts, dak is generally useful for
> non-Debian repositories as well.
> Its setup is still orders of magnitudes more complex than using
> reprepro or Aptly (you will need to write some dedicated scripts for
> your distribution), but for huge package repositories it is from my
> experience one of the most performant and painless options. You also
> gain all the features the Debian archive has instantly.
> If your repository is small though, using dak may be overkill - it
> really shines if you have thousands of packages, with just a few
> reprepro could get the job done easier with less manual work.
>
> >
> > Is there a downloadable OS image which comes with this pre-set up?
> No, unfortunately not.
>
> >
> > Does it run on a cron job or does it
> > have some sort of continuous monitoring? (We have ours run on a
> > cron
> > job every 10 minutes.)
> Dak actions are triggered by multiple cronjobs which run different
> actions. There is one to process incoming uploads which runs roughly
> every 15min, hourly, daily, weekly and monthly cleanup and
> statistics-generating actions as well as the "dinstall" task which
> will run about 4 times a day and publish new packages in the archive
> so users can access them. The dinstall task is actually comprised of
> many individual actions, which deal with different aspects of the
> archive (e.g. translations and AppStream metadata), so summarizing it
> is not that easy.
> In order to not have the autobuilder network wait on publication, dak
> can maintain special queues for the builders to fetch packages from
> prior to them being published officially.
>
> >
> > 2. According to https://wiki.debian.org/BuilddSetup, there seems to
> > be
> > a distinction between the build broker (wanna-build) and the build
> > workers (buildd). Do either of these roles have their own OS images
> > one
> > can download?
> AFAIK there are no OS images, but I would bet that the buildd
> machines
> have an Ansible recipe or something similar somewhere, as those are
> continuously updated and refreshed. I would strongly advise against
> using wanna-build for anything - when I tried to use it in the past
> that attempt turned out to be virtually impossible because there was
> no documentation on it and it heavily relied on grown structures
> within Debian itself. If you dig into it, you will also find some
> interesting historical trivia, e.g. apparently in the past an
> autobuilder was building a package and then sending the build log to
> a
> developer, which then looked over it, signed it and submitted it back
> to get the build actually accepted in the archive.
> So, IMHO wanna-build is really not something that should be used in
> new projects...
>
> >
> > 3. I understand that source packages are signed by developers
> > before
> > being sent to the build farm, but what about the binary packages
> > built
> > by the build farm and uploaded to the repository? Do the build farm
> > servers have their own GPG keys?
> Indeed they have - they sign the package with their own key which is
> valid for binary uploads of the builder's respective architecture.
>
> >
> > Does the repository server recognize
> > these keys?
> Yes, they do - builders are registered with dak as well.
>
> >
> > Thanks in advance, all this info would be helpful for me as I
> > expand
> > our Ubuntu build infrastructure.
> I don't know how about the scale of your build farm, but if it is a
> small-ish amount of packages, using Jenkins+reprepro may be all you
> need. For bigger things, I had some success with Debile[3] in the
> past
> which was building all of Tanglu for a while and was used within
> Debian for builds and tests. Unfortunately that project seems to be
> dead now.
> Launchpad and the Open Build Service[4] may also be very interesting
> options. The Open Build Service comes with a few of its own problems
> (by being designed for RPM in the first place), but in general it is
> very neat and may be exactly what you want for this usecase - it's
> definitely a solution to look into, and I know some people use it to
> manage repositories for internal deployments.
>
> When making Tanglu we threw a lot of Debian code and new code
> together
> and came up with a Debian-like solution in the end, complete with
> non-reusable now Tanglu-specific parts. After I learned that a lot of
> people actually want to set up some more advanced repository
> management and I also had to do all of the things again for PureOS, I
> started to develop a software called "Laniakea"[5] out of the code
> that was already running Tanglu.
> Laniakea is (currently) built around dak and takes over a lot of
> archive maintenance and QA tasks, including package building. For
> package building, Laniakea has its own master server and a worker
> software, which in turn builds packages in systemd-nspawn containers
> via debspawn[6].
> Laniakea is a complete suite of tools which one day should make
> setting up a new Debian derivative a matter of few commands, but
> sadly
> we are not there yet and using it is still a bit experimental - there
> is just too many changes still happening in the project, and test
> coverage lousy.
> (With the exception for debspawn, that's a handy tool).
>
> So, tl;dr, maybe reprepro/Jankins/Aptly is actually what you need
> here
> (assuming you don't have hundreds of packages). If you want, look at
> Open Build Service, and if you feel adventurous try out dak &
> Laniakea.
>
> Hope this helps! (this reply in the end contained a lot more opinion
> pieces than I originally wanted to have)
>
> Cheers,
>     Matthias
>
> [1]: https://wiki.debian.org/DebianDak
> [2]: https://salsa.debian.org/ftp-team/dak
> [3]: https://github.com/opencollab/debile
> [4]: https://openbuildservice.org/
> [5]: https://github.com/lkorigin/laniakea
> [6]: https://github.com/lkorigin/debspawn
> [7*]: Laniakea's web UI can be viewed at https://master.pureos.net/
> and https://software.pureos.net/ to get an impression of what it
> currently does.
>

Matthias,

Thank you for all the info! We will certainly not be building hundreds
of packages, maybe a dozen at most. We are currently using Aptly with a
cronjob that processes incoming packages every 10 minutes and then
rsyncs the published repository to our web server. Getting it set up
was a lot of manual work, and that's why I wondered if there was some
existing image that could do everything we're doing.

My actual build process is currently a Docker image that fetches the
CMake source and builds an Ubuntu package out of it. At the moment I
run this manually, but at some point I might integrate it into our
Buildbot setup. My end goal (some day) is "push button, get CMake
release" with as few manual steps as possible.

If you're using GPG on the published repository, how does your
repository server handle its signing GPG key? Does someone have to type
in a password every time it wants to publish a package, or is it
unattended, with either an unencrypted private key or a passhprase
file? Does the key live on the same server as the repository, or do you
have a dedicated signing server? Keeping unattended GPG keys secure is
tough...

Kyle

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Jeremy Stanley
On 2019-06-10 11:18:35 -0400 (-0400), Kyle Edwards wrote:
[...]
> If you're using GPG on the published repository, how does your
> repository server handle its signing GPG key? Does someone have to type
> in a password every time it wants to publish a package, or is it
> unattended, with either an unencrypted private key or a passhprase
> file? Does the key live on the same server as the repository, or do you
> have a dedicated signing server? Keeping unattended GPG keys secure is
> tough...

A few tips borne out of past experience, in no particular order:

1. Maintain (at least) two valid master keys and keep them in
different places, only signing with one and holding the other in
reserve for emergencies; this way if you ever need to revoke a
master key in an emergency, you're not left with a sudden
bootstrapping problem.

2. Don't place all your trust key revocation, instead plan a
rotation schedule so that even if a key falls into the wrong hands
it's more likely users will smell something fishy when they see it
used to sign new artifacts after expiration, even if they're not
regularly checking for key revocations.

3. Use signing-only subkeys in your automation, not your master
keys; this way the master keys can kept symmetrically encrypted
somewhere you only access to create or revoke subkeys (maybe even on
the other side of an air gap or locked up in an HSM).

4. Package the public keys and make sure your pregeneration/rotation
schedule takes into account a slowest reasonable update frequency,
so that your users are likely to have your next key in place and
trusted before you transition to signing anything with it.

5. It probably goes without saying, but always generate a revocation
certificate for every master key when you create that key, and keep
it somewhere safe as a precaution in case you lose control of the
master.

6. To allow for easier manual verification of key transitions,
always sign new keys with their predecessors when creating them.

7. You *may* want to separate signing and artifact building onto
different systems so you have tighter control over key distribution
and can shield key material from processes involving the running of
less-trusted/arbitrary code, though this still comes with its own
"chain of custody" problem as you need some way for the signing
system to trust not only the build system but now also the channel
through which the artifacts are transferred.

8. Publishing fingerprints and validity dates for your keys
alongside your release documentation/announcements is sometimes
beneficial for bootstrapping initial trust (we also publish full
copies of our public keys on their own page, in addition to pushing
them into the public keyserver network).

9. As an added step, we have the infrastructure team members
responsible for generating and maintaining the keys sign them with
their own personal keys, which are fairly well-established in our
community's web of trust (and a number of our community release
managers transitively attest to those public keys as well for added
coverage).

There's probably more I'm forgetting, but that's at least a good
start at mitigating unattended use of unencrypted keys while
maintaining a robust and resilient signing infrastructure.
--
Jeremy Stanley

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Kyle Edwards
On Mon, 2019-06-10 at 16:56 +0000, Jeremy Stanley wrote:
> 2. Don't place all your trust key revocation, instead plan a
> rotation schedule so that even if a key falls into the wrong hands
> it's more likely users will smell something fishy when they see it
> used to sign new artifacts after expiration, even if they're not
> regularly checking for key revocations.

We generate new keys once a year, publishing them in a keyring package
6 months before they start being used. We are currently signing with
the 2019 key, and will generate the 2020 key in a few weeks.

> 3. Use signing-only subkeys in your automation, not your master
> keys; this way the master keys can kept symmetrically encrypted
> somewhere you only access to create or revoke subkeys (maybe even on
> the other side of an air gap or locked up in an HSM).

We are doing this already :)

> 4. Package the public keys and make sure your pregeneration/rotation
> schedule takes into account a slowest reasonable update frequency,
> so that your users are likely to have your next key in place and
> trusted before you transition to signing anything with it.

We are publishing a keyring package which takes care of this.

> 5. It probably goes without saying, but always generate a revocation
> certificate for every master key when you create that key, and keep
> it somewhere safe as a precaution in case you lose control of the
> master.

We are doing this already :)

> 6. To allow for easier manual verification of key transitions,
> always sign new keys with their predecessors when creating them.

We haven't signed the new key at the GPG key-signing level, but we've
effectively signed it at the APT level by publishing it in the
repository 6 months before it gets used.

> 7. You *may* want to separate signing and artifact building onto
> different systems so you have tighter control over key distribution
> and can shield key material from processes involving the running of
> less-trusted/arbitrary code, though this still comes with its own
> "chain of custody" problem as you need some way for the signing
> system to trust not only the build system but now also the channel
> through which the artifacts are transferred.

The only place where the APT key gets used is to publish the APT
repository itself. Internally, the build process signs with a
disposable, unpublished GPG key that can easily be revoked if it's
compromised. (The Aptly server is also only visible inside our network,
so outsiders can't upload to it anyway.)

> 8. Publishing fingerprints and validity dates for your keys
> alongside your release documentation/announcements is sometimes
> beneficial for bootstrapping initial trust (we also publish full
> copies of our public keys on their own page, in addition to pushing
> them into the public keyserver network).

I've published the key and installation instructions on our APT landing
page.

> There's probably more I'm forgetting, but that's at least a good
> start at mitigating unattended use of unencrypted keys while
> maintaining a robust and resilient signing infrastructure.

It sounds like I'm doing most of this already. Thank you for all the
advice!

Kyle

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Jeremy Stanley
On 2019-06-10 13:09:52 -0400 (-0400), Kyle Edwards wrote:
> On Mon, 2019-06-10 at 16:56 +0000, Jeremy Stanley wrote:
[...]
> > 6. To allow for easier manual verification of key transitions,
> > always sign new keys with their predecessors when creating them.
>
> We haven't signed the new key at the GPG key-signing level, but we've
> effectively signed it at the APT level by publishing it in the
> repository 6 months before it gets used.
[...]

Yep, it's effectively the same if your focus is solely on "secure
APT" package repository signing. For us the signing of keys directly
becomes more useful where they're employed to secure other sorts of
artifacts (source tarballs, language-ecosystem-specific packages,
docker images, even our Git tags are signed by automation following
review and approval of a release request).
--
Jeremy Stanley

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Benjamin Drung-6
In reply to this post by Kyle Edwards
Hi,

Am Donnerstag, den 06.06.2019, 14:32 -0400 schrieb Kyle Edwards:

> Hello all,
>
> I have been preparing Ubuntu releases for CMake on our own APT
> repository for several months now. We did this by preparing our own
> repository infrastructure - we have a machine that builds packages,
> and
> a machine that hosts an Aptly instance and pushes the repository to
> our
> web server. However, all of these things had a lot of manual steps to
> set up and use, and I'm wondering how Debian handles this problem.
> Here
> are some of my questions:
>
> 1. What software do the official Debian repositories use? Do they use
> Aptly or reprepro or something else? Is there a downloadable OS image
> which comes with this pre-set up? Does it run on a cron job or does
> it
> have some sort of continuous monitoring? (We have ours run on a cron
> job every 10 minutes.)
> 2. According to https://wiki.debian.org/BuilddSetup, there seems to
> be
> a distinction between the build broker (wanna-build) and the build
> workers (buildd). Do either of these roles have their own OS images
> one
> can download?
> 3. I understand that source packages are signed by developers before
> being sent to the build farm, but what about the binary packages
> built
> by the build farm and uploaded to the repository? Do the build farm
> servers have their own GPG keys? Does the repository server recognize
> these keys?
>
> Thanks in advance, all this info would be helpful for me as I expand
> our Ubuntu build infrastructure.

You already got a bunch of responses. I was responsible for our inhouse
Debian build chain and faced similar questions than you - except that I
took over the maintenance of the existing setup. Here are some tips:

* We use sbuild to build the packages (for using the same tool than
Debian and for the nice looking logs). To speed up, use an overlay
placed it on tmpfs.

* I had to patch reprepro to support multiple versions:
https://github.com/profitbricks/reprepro

* The build bots upload the binary packages to the repository host with
dput. The repository host uses restricted-ssh-commands to allow only
the upload.

* We use gluing code in lot of places, e.g. as wrapper around sbuild,
for package approval, etc.

When I had to start from scratch, I would probably have a look at
laniakea, because things like testing migration with britney and
autopkgtest is something useful to have.

--
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: [hidden email] | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Paul Wise via nm
On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote:

> * I had to patch reprepro to support multiple versions:
> https://github.com/profitbricks/reprepro

I think it would be very helpful to a lot of derivative distros and
small or private apt repositories if this patch could be merged
upstream and made available to Debian users. Has Profitbricks
considered working on that?

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Vincent Bernat-3
 ❦ 12 juin 2019 14:02 +08, Paul Wise <[hidden email]>:

>> * I had to patch reprepro to support multiple versions:
>> https://github.com/profitbricks/reprepro
>
> I think it would be very helpful to a lot of derivative distros and
> small or private apt repositories if this patch could be merged
> upstream and made available to Debian users. Has Profitbricks
> considered working on that?

It's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623

Maintainer doesn't seem to be interested or have no time to consider the
patch since many years.
--
Choose a data representation that makes the program simple.
            - The Elements of Programming Style (Kernighan & Plauger)

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

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

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

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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

signature.asc (535 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about Debian build infrastructure

Benjamin Drung-6
In reply to this post by Paul Wise via nm
Am Mittwoch, den 12.06.2019, 14:02 +0800 schrieb Paul Wise:
> On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote:
>
> > * I had to patch reprepro to support multiple versions:
> > https://github.com/profitbricks/reprepro
>
> I think it would be very helpful to a lot of derivative distros and
> small or private apt repositories if this patch could be merged
> upstream and made available to Debian users. Has Profitbricks
> considered working on that?

Considered and done from the start (Debian bug #570623). The initial
patch was ugly, but nowadays it is a set of around 70 individual
patches that are small enough for a review.

--
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: [hidden email] | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet