Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

On Mon, Aug 16, 2021 at 07:18:03PM +0200, Wouter Verhelst wrote:
> Well, then we disagree (and that's fine). Personally, I'd rather have my
> CI system try to find as many problems as possible, so I can fix them
> *before* I upload, rather than after.

I didn't try to build a CI system here, but rather a publishing system, which
only publishes reproducible releases. For development, a CI system which finds
problems, is nice. But I also want a system which can do releases and which
only does them when they are reproducible.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's climate crime, not climate change.


signature.asc
Description: PGP signature

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

On Mon, Aug 16, 2021 at 04:47:32PM +, Holger Levsen wrote:
> On Mon, Aug 16, 2021 at 03:59:50PM +0200, Wouter Verhelst wrote:
> > > because here, our focus would be to publish things :)
> > Sure. But also to find problems early rather than late, no?
> 
> no.

Well, then we disagree (and that's fine). Personally, I'd rather have my
CI system try to find as many problems as possible, so I can fix them
*before* I upload, rather than after.

YMMV, of course.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

On Mon, Aug 16, 2021 at 03:59:50PM +0200, Wouter Verhelst wrote:
> > because here, our focus would be to publish things :)
> Sure. But also to find problems early rather than late, no?

no.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If it feels like we’re breaking climate records every year, it’s because we are.


signature.asc
Description: PGP signature

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

Hi Holger,

On Wed, Aug 11, 2021 at 05:12:54PM +, Holger Levsen wrote:
> Hi Wouter,
> 
> sorry for the late reply but I think it's still relevant...
> (just thus rather leaving almost full quote as context.)
> 
> On Thu, Jul 08, 2021 at 11:25:26AM +0200, Wouter Verhelst wrote:
> > On Mon, Jul 05, 2021 at 12:31:10PM +, Holger Levsen wrote:
> > > On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote:
> > > > > Do you have plans to support publishing builds only if they've 
> > > > > produced
> > > > > bit by bit identical results on several builders? IOW, do you plan to
> > > > > support reproducible builds? :)
> > > > There is no specific support for reproducible builds. Currently,
> [...]
> > > > But reproducibility can be tested in GItlab jobs, before the upload.
> > > that's nice, but rather theoretic (however common it is today) in 
> > > practice :)
> > > It would be really interesting / a game changer, to have a publishing 
> > > option
> > > which would only allow publishing of builds proven in practice to be 
> > > identical.
> > It's actually fairly easy to do that:
> > 
> > - Create two runners, with different tags (e.g., one tagged "build1",
> >   and one tagged "build2"). One can be a docker runner, the other a
> >   shell runner, just to keep things interesting.
> > - Create two jobs that build the same source in ways that might trigger
> >   reproducability issues (I'm sure you're better at this than me). Make
> >   sure that they don't store their artifacts in the same location (e.g.,
> >   one job runs "dcmd mv ../*.changes products/build1/", and the other
> >   one does "dcmd mv ../*.changes products/build2/").
> > - Have a third job that depends on both the above two jobs, and that
> >   runs diffoscope over the artifacts of both jobs. If and only if the
> >   diffoscope doesn't reveal any issues, run dput to upload the packages.
> > 
> > I think the salsa-CI team can easily add support for this to their
> > generic pipeline...
> 
> that would be really nice, thank you for explaining this idea so well!
> 
> just one thing: here we do *not* want to trigger reproducibility issues,
> rather the opposite: if we manage to do two builds resulting in exactlty
> the same .deb(s), we are happy.

Yes, of course -- I didn't mean to say "you should make it fail", but
rather "I'm sure you know of ways in which it commonly fails that we
want to protect against".

> because here, our focus would be to publish things :)

Sure. But also to find problems early rather than late, no?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

Hi Wouter,

sorry for the late reply but I think it's still relevant...
(just thus rather leaving almost full quote as context.)

On Thu, Jul 08, 2021 at 11:25:26AM +0200, Wouter Verhelst wrote:
> On Mon, Jul 05, 2021 at 12:31:10PM +, Holger Levsen wrote:
> > On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote:
> > > > Do you have plans to support publishing builds only if they've produced
> > > > bit by bit identical results on several builders? IOW, do you plan to
> > > > support reproducible builds? :)
> > > There is no specific support for reproducible builds. Currently,
[...]
> > > But reproducibility can be tested in GItlab jobs, before the upload.
> > that's nice, but rather theoretic (however common it is today) in practice 
> > :)
> > It would be really interesting / a game changer, to have a publishing option
> > which would only allow publishing of builds proven in practice to be 
> > identical.
> It's actually fairly easy to do that:
> 
> - Create two runners, with different tags (e.g., one tagged "build1",
>   and one tagged "build2"). One can be a docker runner, the other a
>   shell runner, just to keep things interesting.
> - Create two jobs that build the same source in ways that might trigger
>   reproducability issues (I'm sure you're better at this than me). Make
>   sure that they don't store their artifacts in the same location (e.g.,
>   one job runs "dcmd mv ../*.changes products/build1/", and the other
>   one does "dcmd mv ../*.changes products/build2/").
> - Have a third job that depends on both the above two jobs, and that
>   runs diffoscope over the artifacts of both jobs. If and only if the
>   diffoscope doesn't reveal any issues, run dput to upload the packages.
> 
> I think the salsa-CI team can easily add support for this to their
> generic pipeline...

that would be really nice, thank you for explaining this idea so well!

just one thing: here we do *not* want to trigger reproducibility issues,
rather the opposite: if we manage to do two builds resulting in exactlty
the same .deb(s), we are happy.

because here, our focus would be to publish things :)

elsewhere we do have a well known setup to find problems... 
(=tests.r-b.o/debian)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

When this virus is over, I still want some of y'all to stay away from me.


signature.asc
Description: PGP signature

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Wouter Verhelst]

On Mon, Jul 05, 2021 at 12:31:10PM +, Holger Levsen wrote:
> On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote:
> > > Do you have plans to support publishing builds only if they've produced
> > > bit by bit identical results on several builders? IOW, do you plan to
> > > support reproducible builds? :)
> > 
> > There is no specific support for reproducible builds. Currently,
> > buildinfo files can be uploaded and are kept, with the metadata stored
> > in the DB. but nothing is done yet with those.
> 
> yeah :/
> 
> > But reproducibility can be tested in GItlab jobs, before the upload.
> 
> that's nice, but rather theoretic (however common it is today) in practice :)
> It would be really interesting / a game changer, to have a publishing option
> which would only allow publishing of builds proven in practice to be 
> identical.

It's actually fairly easy to do that:

- Create two runners, with different tags (e.g., one tagged "build1",
  and one tagged "build2"). One can be a docker runner, the other a
  shell runner, just to keep things interesting.
- Create two jobs that build the same source in ways that might trigger
  reproducability issues (I'm sure you're better at this than me). Make
  sure that they don't store their artifacts in the same location (e.g.,
  one job runs "dcmd mv ../*.changes products/build1/", and the other
  one does "dcmd mv ../*.changes products/build2/").
- Have a third job that depends on both the above two jobs, and that
  runs diffoscope over the artifacts of both jobs. If and only if the
  diffoscope doesn't reveal any issues, run dput to upload the packages.

I think the salsa-CI team can easily add support for this to their
generic pipeline...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Regarding the new "Debian User Repository"

[Hunter Wittenborn]

I'll be leaving the mailing list for the time being - if there's any further 
inquiries about the (now) MPR, I can be reached in the project's support rooms.



Glad we all came to an agreement. Thanks for the patience!

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

On Mon, Jul 05, 2021 at 02:09:36PM +0200, Mathieu Parent (Debian) wrote:
> > Do you have plans to support publishing builds only if they've produced
> > bit by bit identical results on several builders? IOW, do you plan to
> > support reproducible builds? :)
> 
> There is no specific support for reproducible builds. Currently,
> buildinfo files can be uploaded and are kept, with the metadata stored
> in the DB. but nothing is done yet with those.

yeah :/

> But reproducibility can be tested in GItlab jobs, before the upload.

that's nice, but rather theoretic (however common it is today) in practice :)
It would be really interesting / a game changer, to have a publishing option
which would only allow publishing of builds proven in practice to be 
identical.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

No mas pobres en un pais rico!


signature.asc
Description: PGP signature

Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

[Paul Wise]

On Mon, 2021-07-05 at 11:02 +, M. Zhou wrote:

> Supporting multiple ISA variants based on ld.so means a
> multiple of the current package size.

Apart from the -cc2-dbgsym package those seem fine to multiply,
especially since the intended users probably have lots of disk space.
There is also the option of splitting the hwcap files into one package
per ISA variant to keep each individual package small.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Mathieu Parent (Debian)]

Le lun. 5 juil. 2021 à 11:46, Holger Levsen  a écrit :
>
> Hi Mathieu,

Hi Holger,

> On Mon, Jul 05, 2021 at 10:37:31AM +0200, Mathieu Parent (Debian) wrote:
> > [2]: https://docs.gitlab.com/ee/user/packages/debian_repository/
>
> thanks, this looks nice and simple!

Thanks.

> Do you have plans to support publishing builds only if they've produced
> bit by bit identical results on several builders? IOW, do you plan to
> support reproducible builds? :)

There is no specific support for reproducible builds. Currently,
buildinfo files can be uploaded and are kept, with the metadata stored
in the DB. but nothing is done yet with those.

But reproducibility can be tested in GItlab jobs, before the upload.

Cheers,
-- 
Mathieu Parent

Re: Regarding the new "Debian User Repository"

[Jonathan Carter]

Hi Hunter

On 2021/07/05 05:50, Hunter Wittenborn wrote:
> In combination with some thoughts that have been said here, as well as
> from a branding perspective of what is currently the DUR, I think I'm
> going to change the naming for the project.
> 
> I'll be changing it to be called the "makedeb User Repository", which
> just makes more sense to me.
> 
> One, it removes the targeting towards Debian (when the project /does/
> first and foremost aim at Ubuntu), and two, it aligns more with the
> project's purpose, a user repository for use with makedeb.

That definitely sounds a lot more sensible, thanks!

-Jonathan

Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

[M. Zhou]

On Mon, 2021-07-05 at 02:09 +, Paul Wise wrote:
On Sun, Jul 4, 2021 at 11:20 AM Mo Zhou wrote:
> (2) use the "hardware capabilities" feature of ld.so(8)
...
> Solution (2) will result in very bulky binary packages;

Solution (2) seems like the only option that can be done entirely
within Debian, how bulky are the packages that use this?


For example, the latest tensorflow packaging (in NEW queue)
results in these binary debs:
(thanks to Wookey, Michael, and Andreas for their work!)

~/Debian/tensorflow  ls -lh *.deb   


 18:57:24
-rw-r--r-- 1 root root  36M Jul  5 15:25 libtensorflow-cc2_2.3.1-1_amd64.deb
-rw-r--r-- 1 root root 1.7G Jul  5 15:25 
libtensorflow-cc2-dbgsym_2.3.1-1_amd64.deb
-rw-r--r-- 1 root root 629K Jul  5 15:25 libtensorflow-dev_2.3.1-1_amd64.deb
-rw-r--r-- 1 root root 5.6M Jul  5 15:25 
libtensorflow-framework2_2.3.1-1_amd64.deb
-rw-r--r-- 1 root root 128M Jul  5 15:25 
libtensorflow-framework2-dbgsym_2.3.1-1_amd64.deb

Supporting multiple ISA variants based on ld.so means a
multiple of the current package size.

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

Hi Mathieu,

On Mon, Jul 05, 2021 at 10:37:31AM +0200, Mathieu Parent (Debian) wrote:
> [2]: https://docs.gitlab.com/ee/user/packages/debian_repository/

thanks, this looks nice and simple!

Do you have plans to support publishing builds only if they've produced
bit by bit identical results on several builders? IOW, do you plan to
support reproducible builds? :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

There are no jobs on a dead planet. (Also many other things but people mostly
seem to care about jobs.)


signature.asc
Description: PGP signature

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Mathieu Parent (Debian)]

Le sam. 3 juil. 2021 à 12:11, Simon McVittie  a écrit :
>
> On Fri, 02 Jul 2021 at 20:04:45 +0200, Mathieu Parent wrote:
> > On a related topic, I'm currently developing support for Debian
> > repositories in Gitlab (and transitively Salsa).
>
> That's great news - being able to build packages in CI and make the results
> easily installable seems like a big step forward, particularly for
> fast-moving non-core packages.
>
> Given the other discussion in this thread, perhaps it should be labelled
> "apt repositories" or ".deb repositories" or something else more
> distro-neutral, to avoid implying Debian approval or official status,
> while also making it obvious that if you want to build and publish
> packages for Ubuntu or Linux Mint or some other Debian derivative,
> this is also the right feature for those?

I'm not sure. "Debian repository" is the official term for the format,
as documented
in the wiki [1]. And here, Debian is not in the product name.

[1]; https://wiki.debian.org/DebianRepository/Format

As the doc is now live [2],any ambiguous usage of the Debian term can be
fixed, but I don't see any.

[2]: https://docs.gitlab.com/ee/user/packages/debian_repository/

-- 
Mathieu Parent

Re: Regarding the new "Debian User Repository"

[Brian Thompson]

On Mon, Jul 05, 2021 at 12:44:15AM -0500, Hunter Wittenborn wrote:
>> By the way, how many users do you currently have?
>
>At the time of checking there's 46 registered users.
>
>There's also a counter on the DUR website (bottom-right corner) that displays
>the amount of users.

Thanks, I haven't viewed the site yet. :)

Thanks for coming to the appropriate channel to discuss this and take
care of the legal side of things.
-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Re: Regarding the new "Debian User Repository"

[Hunter Wittenborn]

Hi,

In combination with some thoughts that have been said here, as well as 
from a branding perspective of what is currently the DUR, I think I'm 
going to change the naming for the project.


I'll be changing it to be called the "makedeb User Repository", which 
just makes more sense to me.


One, it removes the targeting towards Debian (when the project /does/ 
first and foremost aim at Ubuntu), and two, it aligns more with the 
project's purpose, a user repository for use with makedeb.


I think it would also give room for people at Debian to make a project 
with the "DUR" name without confusing it with mine, and allows me to 
keep my branding unique and specific as well.


The branding on the website itself should take effect in the coming 
days, but the URL change for the website (dur.hunterwittenborn.com) 
will take effect in about a week or two when I can schedule some 
downtime for users.


Thanks! Let me know if you have any comments on the course of action,
---
*Hunter Wittenborn*
hun...@hunterwittenborn.com

Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

[Paul Wise]

On Sun, Jul 4, 2021 at 11:20 AM Mo Zhou wrote:

> There are a few methods to bump the ISA baseline for a debian package
> for the official archive: (1) patch the code with gcc's fmv feature;
> (2) use the "hardware capabilities" feature of ld.so(8); (3) let the
> user modify debian/rules and rebuild package locally; (4) directly
> bump the ISA baseline for the whole archive; (5) Gentoo-style
> source-based partial Debian distribution.
...
> Solution (2) will result in very bulky binary packages;

Solution (2) seems like the only option that can be done entirely
within Debian, how bulky are the packages that use this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

[Mo Zhou]

Hi fellow devs,

As the previous attempt on debian user repository has been mentioned,
I'm
interested in recalling some key points of it and bits I've learned,
along
with some updates.

# how the initial attempt started

In terms of debian-related works, I mainly focus on scientific computing
and deep learning packages. These packages are very
performance-sensitive.
For example, the performance of BLAS / LAPACK significantly impacts the
performance of the whole inverse dependency tree including important
nodes
such as Numpy, Octave, etc. [8] Namely, a fast BLAS / LAPACK
implementation
benefits the whole tree wherever there is mathematical operations on
contiguous
numerical arrays.

However, tensorflow is an exception, as it is built upon eigen3 (a
header
only linear algebra library in C++) instead of BLAS/LAPACK. Eigen3 does
not support dynamic code branch selection based on CPU capability
(SSE/AVX/etc.),
and hence performs very poor if compiled against Debian's default AMD64
ISA
baseline.

There are a few methods to bump the ISA baseline for a debian package
for the official archive: (1) patch the code with gcc's fmv feature;
(2) use the "hardware capabilities" feature of ld.so(8); (3) let the
user modify debian/rules and rebuild package locally; (4) directly
bump the ISA baseline for the whole archive; (5) Gentoo-style
source-based
partial Debian distribution.

For (1), it's impossible to patch tensorflow (millions of lines of
code);
Solution (2) will result in very bulky binary packages; Solution (3)
is somewhat convincing to me since I think a serious user who need
performance
should learn to build optimized software (e.g. -march=native); Solution
(4) was implemented as SIMDebian (deprecated). Solution (5) is
implemented
as the previous attempt of Debian User Repository (deprecated).

I shall briefly review solution (4) and (5) in following sections

[8] If you are concerned about the BLAS/LAPACK performance on Debian:
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

# regarding SIMDebian

The core idea is a partial Debian archive (binary packages with bumped
ISA baseline) containing some selected packages which manifests
pronounced
performance gain [9]. My implementation modifies the default buildflags
of dpkg [10], and hence is able to inject "-march=xxx" into the package
building process without modifying the source of a debian package.
Thus we can automatically rebuild an optimized partial debian archive.

My knowledge on which package could benefit from this is rather limited
--
as far as I know only Eigen3 reverse dependencies do. We may borrow some
experience from the Gentoo community but I eventually stopped
experimenting
this idea, because there are still some other issues that this idea
cannot
deal with.

[9] https://github.com/SIMDebian/SIMDebian (discontinued)
[10]
https://github.com/SIMDebian/dpkg/commit/13b062567ac58dd1fe5395fb003d6230fd99e7c1

# regarding previous attempt on DUR

What if we just distribute packaging scripts and let users build the
packages on their localhost like Gentoo? In this way inserting
"-march=native"
in d/rules can be sensible in many cases.

The problematic license of Nvidia's non-free blob (e.g., cuDNN which is
inevitable for most deep learning users) can be bypassed if it is
downloaded
and locally-packed on the user's host. Apart from deep learning, the
CUDA
version of ffmpeg is useful for multimedia users, but can only be built
locally from source due to license.

The license issue of ToxicCandy [12] deep learning models can be
bypassed
if the user wants to take their own risks and install some fancy AI
toys.
Things can be more complicated if we combine an automatic code generator
[13]
and the GPL license. Anyway, Gentoo-style source-based user repository,
allows the legal issues to be offloaded to the endusers who are willing
to
accept them [14].

[11] https://github.com/dupr/duprkit/blob/master/doc/motivation.md
[12]
https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst
[13] https://copilot.github.com/
[14] I accept Nvidia's license as a personal user for deep learning
purpose.
 But I tend to refuse Nvidia's license when working for Debian ...
 Bypassing the license issue is the only viable way I can think of
 If we want to integrate more fancy AI stuff into the system in the
future.

# summary and further discussion

SIMDebian tries to bump the ISA baseline and create a binary partial
Debian
archive. The previous attempt of DUR tries to only distribute packaging
scripts to the enduser and let the users build packages locally, and
hence
simultaneously achieving package optimization, and legal issue
circumvent.

I find my proposed concept "ToxicCandy Model" rather interesting.
Identifying
such models can really prevent something tricky from sneaking into our
archive. We shall see how it works in the future.

Dealing with deep learning for Debian is basically a headache -- we need
performance, but we 

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Simon McVittie]

On Fri, 02 Jul 2021 at 20:04:45 +0200, Mathieu Parent wrote:
> On a related topic, I'm currently developing support for Debian
> repositories in Gitlab (and transitively Salsa).

That's great news - being able to build packages in CI and make the results
easily installable seems like a big step forward, particularly for
fast-moving non-core packages.

Given the other discussion in this thread, perhaps it should be labelled
"apt repositories" or ".deb repositories" or something else more
distro-neutral, to avoid implying Debian approval or official status,
while also making it obvious that if you want to build and publish
packages for Ubuntu or Linux Mint or some other Debian derivative,
this is also the right feature for those?

smcv

Re: Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Holger Levsen]

On Fri, Jul 02, 2021 at 08:04:45PM +0200, Mathieu Parent wrote:
> On a related topic, I'm currently developing support for Debian
> repositories in Gitlab (and transitively Salsa). [...]
 
wow, that's some very nice news!  Thanks for sharing it here now.
I'm looking forward to see it in production! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Re: Regarding the new "Debian User Repository"

[Jonathan Carter]

Hi Stephan

On 2021/07/02 19:16, Stephan Lachnit wrote:
> Today I discovered a relatively new project called "Debian User Repository" 
> [1].

For what it's worth, the Debian trademark team is already aware of this.

-Jonathan

Re: Regarding the new "Debian User Repository"

[Hunter Wittenborn]

Sorry, completely forgot to point to my reference.

[1]: 


---
*Hunter Wittenborn*
hun...@hunterwittenborn.com

Re: Regarding the new "Debian User Repository"

[Hunter Wittenborn]

Hi! Just thought I would pop in about some initial concerns Andrey 
raised:


> As long as it only targets Ubuntu and doesn't mention Debian it's 
indeed

only an Ubuntu problem.

It mainly *targets* Ubuntu, but there's no reason it wouldn't be 
functional on Debian distributions. Dependencies can be listed for both 
distros through makedeb's release-specific dependency functionality 
[1], allowing the DUR's (as stated before, I'm open to changing the 
name) PKGBUILDs to work and provide for any number of systems.


> ...it should at least be prominently described how does it work
and why can that be bad for the users.

If you visit the DUR website, it includes a link directly to the 
ArchWiki on how the AUR (which the DUR is based on, pretty much just 
with a reskin and some minor changes) works, as well as a guide for 
creating and setting up a PKGBUILD.


I've thought about redoing the PKGBUILD docs for makedeb, but it just 
felt like it would be redundant when the ArchWiki article is already 
has a plethora of information about it.


Regarding why the DUR could be bad for end users (i.e. from a security 
standpoint), the following is plastered on top of the DUR homepage (as 
well as the AUR's), in bold, which can be seen by all users before they 
log in:


> *DISCLAIMER: DUR packages are user produced content. Any use of the 
provided files is at your own risk.*

*
*
The same message can also be seen in the footer of all pages, whether 
logged in or not.

*
*
Lastly, again, I'm open to changing the name if it would be preferred 
by a decent amount of people on the Debian team. It really wouldn't be 
too much hassle for me, but if I were to do it, I would prefer to 
schedule some downtime for the users that are already currently using 
the DUR so I can change everything in a planned manner.


Thanks! Let me know if you have any thoughts,
---
*Hunter Wittenborn*
hun...@hunterwittenborn.com

Gitlab support for Debian repositories (Was: Regarding the new "Debian User Repository")

[Mathieu Parent]

Le ven. 2 juil. 2021 à 19:17, Stephan Lachnit
 a écrit :
>
> Today I discovered a relatively new project called "Debian User Repository" 
> [1].
>
> It's similar to the AUR, and much more than just in principle.

Hi,

On a related topic, I'm currently developing support for Debian
repositories in Gitlab (and transitively Salsa).

Work on this started 9 month ago , and basic support will probably be
shipped with Gitlab 14.1 behind a feature flag (i.e  July 22). You can
follow epic [1].

[1] https://gitlab.com/groups/gitlab-org/-/epics/6057#note_582697034

Cheers
-- 
Mathieu Parent

Re: Regarding the new "Debian User Repository"

[Andrey Rahmatullin]

On Fri, Jul 02, 2021 at 07:16:48PM +0200, Stephan Lachnit wrote:
> Thus, I think we should discuss whether we should ask the creator to change
> the name (he is open for that, I asked him).
I don't think there is something to discuss here, the name should be changed.

> The creator responded quite nicely and I think we shouldn't actively oppose
> the project itself. 
As long as it only targets Ubuntu and doesn't mention Debian it's indeed
only an Ubuntu problem. If it starts targetting Debian, as was planned by
the author, it should at least be prominently described how does it work
and why can that be bad for the users.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Regarding the new "Debian User Repository"

[Stephan Lachnit]

Today I discovered a relatively new project called "Debian User Repository" [1].

It's similar to the AUR, and much more than just in principle. Packages are
defined as PKGBUILD files and built via makepkg [2], the tool used in the AUR.
The packages are then converted to binary debs using makedeb [3].
Overall, the build process is designed to avoid "standard" Debian packaging
as much as possible.

I was trying to find out who made it - and this project is not related to Debian
at all (the creator, Hunter Wittenborn, is not in Debian's contributor
database).
Also, it's goal is not creating an "AUR" for Debian, but a central replacement
PPAs for Ubuntu LTS [4, 5]. For those of you who want to see my conversation
with the creator, it's in a public (though encrypted) Matrix room [6].

Why do I think this is relevant for Debian?
This was not the first attempt of building a "DUR" [7], and at least I
personally
think the name has too much weight for a project that is not related to Debian.
Thus, I think we should discuss whether we should ask the creator to change
the name (he is open for that, I asked him).

The creator responded quite nicely and I think we shouldn't actively oppose
the project itself. I think the project *can* be beneficial to Debian (at least
until someone creates a DUR that actually uses the Debian build process).

- Stephan

[1] https://dur.hunterwittenborn.com/
[2] https://wiki.archlinux.org/title/makepkg
[3] https://github.com/hwittenborn/makedeb
[4] https://docs.hunterwittenborn.com/makedeb/debian-user-repository/intro
[5] 
https://docs.hunterwittenborn.com/makedeb/debian-user-repository/dur-user-guidelines/package-relationships
[6] 
https://matrix.to/#/!MlOxXUNnNLifAJrRHM:hunterwittenborn.com/$-0F8SG0pk8RH3cPkhifBCT3lnyYiZdEn1XC3sE6WxRg?via=hunterwittenborn.com=matrix.org=grin.hu
[7] https://lists.debian.org/debian-devel/2019/04/msg00064.html