subject:"\[Idea\] Debian User Repository\? \(Not simply mimicing AUR\)"

Hi,

On Mon, Apr 08, 2019 at 01:59:04PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > Plus, letting users write PKGBUILD doesn't help them learn
> > Debian packaging at all...
> 
> Then I would try to diverge as little as possible
> from the classical way how Debian packaging works.

If you didn't read the code of fold/unfold and don't understand
why I declare that the cost of the proposed single-file format
has nearly zero-cost, please refer to the traditional style
alternative:

https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
I expect no one to argue about this "traditional" style.
This "traditional" style is exactly what you do for the
official debian development, in the "debian-directory-only"
git workflow.

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

On Mon, Apr 08, 2019 at 03:50:19PM +0300, Tzafrir Cohen wrote:
> Hi,
> 
> The README states a directory structure with a top-level collection
> directory, but the repository currently does not include one.

The github.com:dupr/DefaultCollection.git repo is indeed a specification
compliant if you mangle the first layer of directory structure.

```
--- a/README
+++ b/README
@@ -17,7 +17,7 @@ name. Plus, no one prevents you from submitting a debian 
directory.

 For example:

-A-Certain-Collection/
+A-Certain-Collection/  # For example, this git repository.
 library-foo/
 library-foo.durpkg
 library-foo-ubuntu.durpkg
```

> Looking at:
> 
> 
> https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg
> 
> I see that the name of the directory repeats quite a number of times.
> The clean function needs to state 'rm -rf' explicitly, which I hope
> won't lead to typos.

The repetition of "pushd" and "popd" is something that could be improved
later. So the same as the 'rm -rf' hook. The two problems have been
tracked here:
https://github.com/dupr/duprkit/issues/3
https://github.com/dupr/duprkit/issues/4

Please don't expect too much from a prototype rushed within several
hours. That's used for presenting the idea instead of presenting
a graceful implementation.

> The changelog is buried deep inside the package an needs to be updated
> whenever a version number is bumped.

AUR's PKGBUILD doesn't record changes. If you feel like that the dch
has been deeply buried, the usage of traditional debian/ directory
layout is still supported:
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
https://github.com/dupr/DefaultCollection/blob/master/rover-traditional/debian/changelog

One could easity convert the packaging between single-file format and
debian/ directory with a single-command-cost (virtually zero-cost).

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

2019-04-08 Thread Tzafrir Cohen

Hi,

On 08/04/2019 14:18, Mo Zhou wrote:
> Hi,
>
> The proposed idea is source-only-based, and is totally different
> from PPA (source+binary-based). I'm a PPA user and I don't have
> any reason to re-invent yet another PPA.
>
> The proposed idea is to take some advantages from source-based
> software distribution tools. Examples are available here:
> https://github.com/dupr/duprkit
> https://github.com/dupr/DefaultCollection

The README states a directory structure with a top-level collection
directory, but the repository currently does not include one.

Looking at:

https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg

I see that the name of the directory repeats quite a number of times.
The clean function needs to state 'rm -rf' explicitly, which I hope
won't lead to typos.

The changelog is buried deep inside the package an needs to be updated
whenever a version number is bumped.

-- Tzafrir

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Roberto C . Sánchez

On Mon, Apr 08, 2019 at 12:29:56PM +, Mo Zhou wrote:
> Hi,
> 
> On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> > > Hi,
> > > 
> > > As you wish, I added a disclaimer to the toolkit, and replaced every
> > > single "Debian" keyword in the repo with "D**ian", except for those
> > > in disclaimer.
> > 
> > Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> > practical.  After all, the whole exercise seems to be more focused on
> > the packaging and distribution of said packages, rather than "Debian the
> > GNU/Linux distribution" as a project.  If there are places where the
> > leading dot might be impractical or confusing, then perhaps "dotdeb" or
> > "dot-deb" might be more workable.
> 
> However the idea involves no distribution of any single ".deb" file.
> That's more likely a "User Recipe Repository", instead of a "User dishes
> Repository". People will ask "where on earth are your .deb files?" if
> I put ".deb" to the title.
> 
OK.  Thanks for the explanation.  It seems like I did not properly grasp
that aspect of it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi,

On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> > Hi,
> > 
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D**ian", except for those
> > in disclaimer.
> 
> Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> practical.  After all, the whole exercise seems to be more focused on
> the packaging and distribution of said packages, rather than "Debian the
> GNU/Linux distribution" as a project.  If there are places where the
> leading dot might be impractical or confusing, then perhaps "dotdeb" or
> "dot-deb" might be more workable.

However the idea involves no distribution of any single ".deb" file.
That's more likely a "User Recipe Repository", instead of a "User dishes
Repository". People will ask "where on earth are your .deb files?" if
I put ".deb" to the title.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Roberto C . Sánchez

On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> Hi,
> 
> As you wish, I added a disclaimer to the toolkit, and replaced every
> single "Debian" keyword in the repo with "D**ian", except for those
> in disclaimer.

Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
practical.  After all, the whole exercise seems to be more focused on
the packaging and distribution of said packages, rather than "Debian the
GNU/Linux distribution" as a project.  If there are places where the
leading dot might be impractical or confusing, then perhaps "dotdeb" or
"dot-deb" might be more workable.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread W. Martin Borgert


Quoting Mo Zhou :

Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...


Then I would try to diverge as little as possible
from the classical way how Debian packaging works.

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

Hi,

The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.

The proposed idea is to take some advantages from source-based
software distribution tools. Examples are available here:
https://github.com/dupr/duprkit
https://github.com/dupr/DefaultCollection

Only "packaging scripts" are provided. Upstream source are
downloaded by the scritps locally before the build. The proposed
idea will never involve "distributing resulting binary .deb packages".

Again, the idea is totally different from PPA.

On Mon, Apr 08, 2019 at 10:32:46AM +, Holger Levsen wrote:
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > > At the first glance I interpreted the sentence as
> > >  "This will only lead to flamewars"
> > > due to the meaning of bikeshed[1].
> > > 
> > > However, I got a hint from a fellow developer and learned that
> > > "Bikeshed" has its own meaning under Debian's context, according
> > > to some old mailing list fragments[2][3] -- which refers to a
> > > dak feature (This is the first time I heard of such thing).
> > This supports my (thus far) private feeling that naming this initiative
> > "Bikeshed" is a bad idea.
> 
> +1
> 
> I also think that using the name "D**ian" is a bad idea.
> 
> Just call it PPAs... millions of people know that term.

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

2019-04-08 Thread Ondřej Surý

Or DPA (Debian Personal Archive)...

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 12:32, Holger Levsen  wrote:
> 
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
>>> At the first glance I interpreted the sentence as
>>> "This will only lead to flamewars"
>>> due to the meaning of bikeshed[1].
>>> 
>>> However, I got a hint from a fellow developer and learned that
>>> "Bikeshed" has its own meaning under Debian's context, according
>>> to some old mailing list fragments[2][3] -- which refers to a
>>> dak feature (This is the first time I heard of such thing).
>> This supports my (thus far) private feeling that naming this initiative
>> "Bikeshed" is a bad idea.
> 
> +1
> 
> I also think that using the name "D**ian" is a bad idea.
> 
> Just call it PPAs... millions of people know that term.
> 
> 
> -- 
> tschau,
>Holger
> 
> ---
>   holger@(debian|reproducible-builds|layer-acht).org
>   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

2019-04-08 Thread Holger Levsen

On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > At the first glance I interpreted the sentence as
> >  "This will only lead to flamewars"
> > due to the meaning of bikeshed[1].
> > 
> > However, I got a hint from a fellow developer and learned that
> > "Bikeshed" has its own meaning under Debian's context, according
> > to some old mailing list fragments[2][3] -- which refers to a
> > dak feature (This is the first time I heard of such thing).
> This supports my (thus far) private feeling that naming this initiative
> "Bikeshed" is a bad idea.

+1

I also think that using the name "D**ian" is a bad idea.

Just call it PPAs... millions of people know that term.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Ondřej Surý

I don’t think you need to avoid using “Debian” in the name.

This is the least problem your proposal have.

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 12:27, Mo Zhou  wrote:
> 
> Hi,
> 
> D**ian may be pronounced as "Dasteriskian", i.e. "D-asterisk-ian"
> (Still sounds ugly). I'm really bad at naming things, neither.
> 
> AUR is not targeted on new Archlinux users. Likewise, the D**bian
> term is not expected to cause confusion to people who really
> need to use these scripts/tools. That said, I want a better name
> too.
> 
>> On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
>> Quoting Mo Zhou :
>>> As you wish, I added a disclaimer to the toolkit, and replaced every
>>> single "Debian" keyword in the repo with "D**ian", except for those
>>> in disclaimer.
>> 
>> Pardon, but replacing letters with '*' looks like Debian were a
>> swearword ("f*ck", "sh*t", ...) one likes to avoid. Also, it is
>> not a good name, because nobody knows how to pronounce it nor
>> which letters exactly were replaced. I'm bad at naming, sorry,
>> but please find something else before people get used to it :-)
>

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi,

D**ian may be pronounced as "Dasteriskian", i.e. "D-asterisk-ian"
(Still sounds ugly). I'm really bad at naming things, neither.

AUR is not targeted on new Archlinux users. Likewise, the D**bian
term is not expected to cause confusion to people who really
need to use these scripts/tools. That said, I want a better name
too.

On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D**ian", except for those
> > in disclaimer.
> 
> Pardon, but replacing letters with '*' looks like Debian were a
> swearword ("f*ck", "sh*t", ...) one likes to avoid. Also, it is
> not a good name, because nobody knows how to pronounce it nor
> which letters exactly were replaced. I'm bad at naming, sorry,
> but please find something else before people get used to it :-)

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Mon, Apr 08, 2019 at 03:46:15PM +0800, Paul Wise wrote:
> On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
> 
> > However, the translator itself is not trivial, as it might need
> > it's own shell parser or something alike to be reliable enough.
> 
> Couldn't you just run makepkg (with some hooks) and dpkg-deb to
> convert the results to Debian packages?

Worth a try. I'll dig into this on the weekend.
The enhancement is tracked here:
https://github.com/dupr/duprkit/issues/1

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Jonathan Dowland


On Sun, Apr 07, 2019 at 02:17:00PM +, Mo Zhou wrote:

This single sentence is quite ambiguous to non-native english speakers.

At the first glance I interpreted the sentence as
 "This will only lead to flamewars"
due to the meaning of bikeshed[1].

However, I got a hint from a fellow developer and learned that
"Bikeshed" has its own meaning under Debian's context, according
to some old mailing list fragments[2][3] -- which refers to a
dak feature (This is the first time I heard of such thing).


This supports my (thus far) private feeling that naming this initiative
"Bikeshed" is a bad idea.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Ole Streicher

Paul Wise  writes:
> On Sun, Apr 7, 2019 at 10:14 PM Peter Silva  wrote:
>> We would love to be able to upstream to debian, but haven't figured it out
>
> The process is pretty simple, but reliant on the limited number of
> Debian members who do package sponsorship. The ones we do have are
> fairly active though. The process is essentially; fix any quality
> issues, upload source packages to mentors.d.n, file a request for
> sponsor and reply to any responses you get.

For some fields, there are also additional possibilities: If you put
your packages into a Debian Pure Blend (like Debian Science, or Debian
Astro) and follow their rules, chances are big that someone from there
does the mentorship rather quickly.

Best

Ole

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Paul Wise

On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:

> However, the translator itself is not trivial, as it might need
> it's own shell parser or something alike to be reliable enough.

Couldn't you just run makepkg (with some hooks) and dpkg-deb to
convert the results to Debian packages?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi Paul,

I've ever thought about a PKGBUILD->Deb translator, and in this
way we can directly reuse all existing code in AUR without change.

However, the translator itself is not trivial, as it might need
it's own shell parser or something alike to be reliable enough.

The current (virtually) zero-overhead naive prototype, still allows the
reuse of existing debian packaging scripts and documentations.
Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...

On Mon, Apr 08, 2019 at 03:29:12PM +0800, Paul Wise wrote:
> On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote:
> 
> > Such idea about informal packaging repository has been
> > demonstrated successful by the Archlinux User Repository (AUR).
> > Hence, it should be valuable to think about it for Debian.
> 
> Seems like a PKGBUILD-to-deb script would be a simple way to do this
> and would also allow leveraging the existing PKGBUILD archive that is
> AUR and prevent splitting the community of people who make informal
> packaging.
> 
> In 2007 there was something similar for Gentoo ebuilds:
> 
> http://penta.debconf.org/dc7_schedule/events/69.en.html
> https://www.youtube.com/watch?v=Hy9ugWUuNBM
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Paul Wise

On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote:

> Such idea about informal packaging repository has been
> demonstrated successful by the Archlinux User Repository (AUR).
> Hence, it should be valuable to think about it for Debian.

Seems like a PKGBUILD-to-deb script would be a simple way to do this
and would also allow leveraging the existing PKGBUILD archive that is
AUR and prevent splitting the community of people who make informal
packaging.

In 2007 there was something similar for Gentoo ebuilds:

http://penta.debconf.org/dc7_schedule/events/69.en.html
https://www.youtube.com/watch?v=Hy9ugWUuNBM

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-08 Thread Paul Wise

On Sun, Apr 7, 2019 at 10:14 PM Peter Silva  wrote:

> We would love to be able to upstream to debian, but haven't figured it out

The process is pretty simple, but reliant on the limited number of
Debian members who do package sponsorship. The ones we do have are
fairly active though. The process is essentially; fix any quality
issues, upload source packages to mentors.d.n, file a request for
sponsor and reply to any responses you get.

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi,

As you wish, I added a disclaimer to the toolkit, and replaced every
single "Debian" keyword in the repo with "D**ian", except for those
in disclaimer.

```
Everything included in this repository is totoally unrelated to the Debian
Project, or any OFFICIAL Debian development. Debian Project is not responsible
for any consequence resulted by utilization of the D**ian User Package
Repository Toolkit or any related .durpkg collections or single .durpkg files.
Please Take your own risk utilizing the toolkit, and please review every line
of code before execution.
```

I hereby emphasize that

  * The idea of D**ian User Repository is TOTALLY UNRELATED TO OFFICIAL
Debian Development.

  * The Debian Project is unrelated and unresponsible for anything
included 

  * The D**ian User Repository stuff STRONGLY recommend every user to review
everything before execution.

  * My initiative is JUST getting scutwork done, instead of introducing
any legal risk to the Debian Project.

This thread on -devel is still meaningful if any user wants to integrate
the basic and unofficial D**ian ... Toolkit into Debian.

However, to be as much cooperative as I can, if this thread is
considered to be toxic or off-topic, that means my immediate termination
of involvement in this thread.

On Mon, Apr 08, 2019 at 01:25:22AM -0400, Scott Kitterman wrote:
> I don't think this should have Debian in it's name at all.  Fetching random 
> code from Github and building it isn't what we're about.
> 
> Scott K

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Vincent Bernat

 ❦  8 avril 2019 14:46 +10, Ben Finney :

>> yes, it can be done, but it is a lot more work for individual
>> packagers.
>
> Sure. And, on the other hand, providing an APT repository for arbitrary
> packages of unknown copyright status is also a lot of work to expect
> disinterested volunteers to do without motivation.

Disinterested volunteers are never forced to work for Debian. What is
the point of being so negative?
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Scott Kitterman

I don't think this should have Debian in it's name at all.  Fetching random 
code from Github and building it isn't what we're about.

Scott K

On Monday, April 08, 2019 05:00:21 AM Mo Zhou wrote:
> Plus, it's super important to write every packaging bit into a single
> file. That would enable simple copy from github or any other
> resources. If you provide a directory, things will become more
> complicated. More impotantly, the proposed single file specification
> virtually adds NO overhead.
> 
> If I were a rookie, I'd really like single-file specifications
> which allows simple copy
> 
> On Mon, Apr 08, 2019 at 04:54:51AM +, Mo Zhou wrote:
> > On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> > > +1, it's a good idea and I've thought of it before as well.
> > 
> > Nice!
> > 
> > > Reading some of the initial replies to your post, it seems like people
> > > don't entirely understand what you mean by an AUR-like service. This
> > > would definitely be different than PPAs (in the launchpad sense) or
> > > bikesheds (which is still a terrible name for all the confusion it
> > > causes).
> > 
> > Yes, and now real working example is available, see following.
> > 
> > > Have you put any thought in possible implementation yet? I don't think
> > > it's a good idea to devise any kind of new source packages. It's
> > 
> > Inventing yet-another wheel is unwise, undoubtedly. Only something
> > less than a tiny overhead is acceptable. Only in this way can
> > we use all existing mature development tools and documentations.
> > 
> > > probably not even necessary to use existing source packages. If you'd
> > > have the standard debian packaging for such an AUR^W... DUR? in a git
> > > repository (maybe like salsa.debian.org/dur/*) with a standardised git
> > > workflow for these, then it should be rather trivial to implement with a
> > > helper script that fetches the upstream source and just builds that
> > > package locally. So I think from a technical point of view, implementing
> > > something like AUR for Debian doesn't seem so hard. It can also act as a
> > > nice gateway to proper Debian development.
> > 
> > If we ignore the web part, a functional yet rushed demonstration is
> > available here:
> > 
> > https://github.com/dupr/duprkit
> > 
> > If you follow the instructions there, you will be able to pull the default
> > packaging collection, do searching by keyword, and build some demo
> > packages (they are really working).
> > 
> > Specifically, I drafted 2 new plain file format specifications:
> > f822 (means folded deb822), and durpkg (mimicing PKGBUILD).
> > 
> >  * f822 format allows you squash the whole debian/ directory into a single
> >  
> >plain file, with a specification that cannnot be simpler[1]
> >  
> >  * durpkg is a concatenation of a shell script and an f822 file[2].
> >  
> >the shell part[3] defines things like (1) how do prepare the source
> >(2) how to apply some patch (3) how to build the .deb packages
> >(4) how to clean (5) optionally user's customed hacks.
> >
> >Shell script introduces the MAXIMUM flexibility and allows the users
> >to do virtually anything they want.
> > 
> > An user contributed collection looks like [4], see readme for directory
> > layout specification for a DUR? collection. The "duprkit" can be
> > configured to use other, or private collections as well.
> > 
> > Everything looks hacky since it's rushed within several hours. Many
> > details could be improved. However, this demonstration is enough
> > to illusrate what I'm thinking.
> > 
> > [1] https://github.com/dupr/duprkit/blob/master/bin/unfold#L25
> > [2] https://github.com/dupr/duprkit/blob/master/bin/unfold#L74
> > [3]
> > https://github.com/dupr/DefaultCollection/blob/master/gotop/gotop.durpkg#
> > L1-L38 [4] https://github.com/dupr/DefaultCollection

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Plus, it's super important to write every packaging bit into a single
file. That would enable simple copy from github or any other
resources. If you provide a directory, things will become more
complicated. More impotantly, the proposed single file specification
virtually adds NO overhead.

If I were a rookie, I'd really like single-file specifications
which allows simple copy

On Mon, Apr 08, 2019 at 04:54:51AM +, Mo Zhou wrote:
> On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> > +1, it's a good idea and I've thought of it before as well.
> 
> Nice!
>  
> > Reading some of the initial replies to your post, it seems like people
> > don't entirely understand what you mean by an AUR-like service. This
> > would definitely be different than PPAs (in the launchpad sense) or
> > bikesheds (which is still a terrible name for all the confusion it causes).
> 
> Yes, and now real working example is available, see following.
> 
> > Have you put any thought in possible implementation yet? I don't think
> > it's a good idea to devise any kind of new source packages. It's
> 
> Inventing yet-another wheel is unwise, undoubtedly. Only something
> less than a tiny overhead is acceptable. Only in this way can
> we use all existing mature development tools and documentations.
> 
> > probably not even necessary to use existing source packages. If you'd
> > have the standard debian packaging for such an AUR^W... DUR? in a git
> > repository (maybe like salsa.debian.org/dur/*) with a standardised git
> > workflow for these, then it should be rather trivial to implement with a
> > helper script that fetches the upstream source and just builds that
> > package locally. So I think from a technical point of view, implementing
> > something like AUR for Debian doesn't seem so hard. It can also act as a
> > nice gateway to proper Debian development.
> 
> If we ignore the web part, a functional yet rushed demonstration is
> available here:
> 
> https://github.com/dupr/duprkit
> 
> If you follow the instructions there, you will be able to pull the default
> packaging collection, do searching by keyword, and build some demo
> packages (they are really working).
> 
> Specifically, I drafted 2 new plain file format specifications:
> f822 (means folded deb822), and durpkg (mimicing PKGBUILD).
> 
>  * f822 format allows you squash the whole debian/ directory into a single
>plain file, with a specification that cannnot be simpler[1]
> 
>  * durpkg is a concatenation of a shell script and an f822 file[2].
>the shell part[3] defines things like (1) how do prepare the source
>(2) how to apply some patch (3) how to build the .deb packages
>(4) how to clean (5) optionally user's customed hacks.
> 
>Shell script introduces the MAXIMUM flexibility and allows the users
>to do virtually anything they want.
> 
> An user contributed collection looks like [4], see readme for directory
> layout specification for a DUR? collection. The "duprkit" can be
> configured to use other, or private collections as well.
> 
> Everything looks hacky since it's rushed within several hours. Many
> details could be improved. However, this demonstration is enough
> to illusrate what I'm thinking.
> 
> [1] https://github.com/dupr/duprkit/blob/master/bin/unfold#L25
> [2] https://github.com/dupr/duprkit/blob/master/bin/unfold#L74
> [3] 
> https://github.com/dupr/DefaultCollection/blob/master/gotop/gotop.durpkg#L1-L38
> [4] https://github.com/dupr/DefaultCollection
>

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Ben Finney  writes:

> Peter Silva  writes:
>
> > With debian, it's kind of all or nothing. Etiher you're in Debian,
> > and it gets built on every platform using the build farm, or it's
> > not, so you get no help at all.
>
> That doesn't seem accurate. Have people tried setting up an APT
> repository and got “no help at all”? Does the maintenance of the
> packages to run an APT repository, and instructions on how to do it, not
> count as help in doing that?

As for the build farm: the parties who donate those to Debian did so on
the understanding that they took on the load of building only the
official Debian archive. Opening the gates to even unofficial Debian
packages would be a significant increase in that burden on many of those
donated machines.

I think it's good to keep the distinction between official Debian
archive (which is built on the official Debian build farm) versus
unofficial packages (which need someone else with their own reasons to
donate resources to build them).

-- 
 \   “The generation of random numbers is too important to be left |
  `\to chance.” —Robert R. Coveyou |
_o__)  |
Ben Finney

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> +1, it's a good idea and I've thought of it before as well.

Nice!

> Reading some of the initial replies to your post, it seems like people
> don't entirely understand what you mean by an AUR-like service. This
> would definitely be different than PPAs (in the launchpad sense) or
> bikesheds (which is still a terrible name for all the confusion it causes).

Yes, and now real working example is available, see following.

> Have you put any thought in possible implementation yet? I don't think
> it's a good idea to devise any kind of new source packages. It's

Inventing yet-another wheel is unwise, undoubtedly. Only something
less than a tiny overhead is acceptable. Only in this way can
we use all existing mature development tools and documentations.

> probably not even necessary to use existing source packages. If you'd
> have the standard debian packaging for such an AUR^W... DUR? in a git
> repository (maybe like salsa.debian.org/dur/*) with a standardised git
> workflow for these, then it should be rather trivial to implement with a
> helper script that fetches the upstream source and just builds that
> package locally. So I think from a technical point of view, implementing
> something like AUR for Debian doesn't seem so hard. It can also act as a
> nice gateway to proper Debian development.

If we ignore the web part, a functional yet rushed demonstration is
available here:

https://github.com/dupr/duprkit

If you follow the instructions there, you will be able to pull the default
packaging collection, do searching by keyword, and build some demo
packages (they are really working).

Specifically, I drafted 2 new plain file format specifications:
f822 (means folded deb822), and durpkg (mimicing PKGBUILD).

 * f822 format allows you squash the whole debian/ directory into a single
   plain file, with a specification that cannnot be simpler[1]

 * durpkg is a concatenation of a shell script and an f822 file[2].
   the shell part[3] defines things like (1) how do prepare the source
   (2) how to apply some patch (3) how to build the .deb packages
   (4) how to clean (5) optionally user's customed hacks.

   Shell script introduces the MAXIMUM flexibility and allows the users
   to do virtually anything they want.

An user contributed collection looks like [4], see readme for directory
layout specification for a DUR? collection. The "duprkit" can be
configured to use other, or private collections as well.

Everything looks hacky since it's rushed within several hours. Many
details could be improved. However, this demonstration is enough
to illusrate what I'm thinking.

[1] https://github.com/dupr/duprkit/blob/master/bin/unfold#L25
[2] https://github.com/dupr/duprkit/blob/master/bin/unfold#L74
[3] 
https://github.com/dupr/DefaultCollection/blob/master/gotop/gotop.durpkg#L1-L38
[4] https://github.com/dupr/DefaultCollection

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Peter Silva  writes:

> On Sun, Apr 7, 2019 at 11:10 PM Ben Finney  wrote:
>
> > If one needs to keep a close eye on changes to make sure they can
> > still be installed even on a years-old OS, the resulting packages
> > can be placed in a custom repository set up with the instructions at
> > https://wiki.debian.org/DebianRepository/Setup>. What am I
> > missing?

> yes, it can be done, but it is a lot more work for individual
> packagers.

Sure. And, on the other hand, providing an APT repository for arbitrary
packages of unknown copyright status is also a lot of work to expect
disinterested volunteers to do without motivation.

So it sounds like you know of at least enough individual developers that
you have a group motivated to maintain an unofficial APT repository.

That seems like an appropriate model: groups who want to make unofficial
packages available can put in the sys-admin effort to run an unofficial
APT repository with the existing tools.

The Debian project does not (and, I believe, should not) need to be the
home of third-party unofficial repositories; the tools to provide those
are already in the hands of anyone who wants to provide them.

> With debian, it's kind of all or nothing. Etiher you're in Debian, and
> it gets built on every platform using the build farm, or it's not, so
> you get no help at all.

That doesn't seem accurate. Have people tried setting up an APT
repository and got “no help at all”? Does the maintenance of the
packages to run an APT repository, and instructions on how to do it, not
count as help in doing that?

> Launchpad gives a nice middle road that suits us right now,
> and if something similar were available for debian, it would provide a
> stepping stone to being in Debian proper.

Conversely, I would argue that providing an APT repository for the
unofficial packages they want available is a way for grroups to, on
their own steam, provide that stepping stone.

-- 
 \“Beware of bugs in the above code; I have only proved it |
  `\ correct, not tried it.” —Donald Knuth, 1977-03-29 |
_o__)  |
Ben Finney

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 11:10 PM Ben Finney  wrote:

> Peter Silva  writes:
>
> > […] the launchpad.net model, which supports backporting seamlesslly
> > and allows to support the same version on all distro versions, works
> > better for us. This is something a debian version of launchpad would
> > get us.
>
> How does it handle “seamlessly” changes that make a package incompatible
> with the already-released Debian stable? If it doesn't handle that, is
> it right to call that seamless?
>
>
For the package in question, the changes are bug-fixes, 99% upward
compatible.
so yes, you're right it can't be totally seamless, we have release notes to
cover breakage events.
and other explicit communications.

> If one needs to keep a close eye on changes to make sure they can still
> be installed even on a years-old OS, the resulting packages can be
> placed in a custom repository set up with the instructions at
> https://wiki.debian.org/DebianRepository/Setup>. What am I missing?
>
>
yes, it can be done, but it is a lot more work for individual packagers.

launchpad.net combines:
   - very few clicks to build custom repositories.
   - a build environment for each OS, so that it runs "debuild" in the
currently patched version of the OS for which the package it built.

It saves people from having to build their own custom repository, and from
having to maintain a build environment for all supported OS versions and
architectures.  on Ubuntu,  packages are built for 14.04, 16,04, 18.04,
18.10, 19.04, and I get all those just from clicking one box for each one.
I think it also propagates re-building of packages when a build-dependency
changes, without my knowledge or interaction.  It leverages the ubuntu
build-farm for third-party packages.

With debian, it's kind of all or nothing.  Etiher you're in Debian, and it
gets built on every platform using the build farm, or it's not, so you get
no help at all. Launchpad gives a nice middle road that suits us right now,
and if something similar were available for debian, it would provide a
stepping stone to being in Debian proper.

-- 
>  \ “I think Western civilization is more enlightened precisely |
>   `\ because we have learned how to ignore our religious leaders.” |
> _o__)—Bill Maher, 2003 |
> Ben Finney
>
>

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Peter Silva  writes:

> […] the launchpad.net model, which supports backporting seamlesslly
> and allows to support the same version on all distro versions, works
> better for us. This is something a debian version of launchpad would
> get us.

How does it handle “seamlessly” changes that make a package incompatible
with the already-released Debian stable? If it doesn't handle that, is
it right to call that seamless?

If one needs to keep a close eye on changes to make sure they can still
be installed even on a years-old OS, the resulting packages can be
placed in a custom repository set up with the instructions at
https://wiki.debian.org/DebianRepository/Setup>. What am I missing?

-- 
 \ “I think Western civilization is more enlightened precisely |
  `\ because we have learned how to ignore our religious leaders.” |
_o__)—Bill Maher, 2003 |
Ben Finney

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 09:36:25PM -0400, Peter Silva wrote:
> 
>OK for unstable and testing, but I want to provide packages for stable
>versions of Debian using a separate repo that will be get frequent
>updates, even though the OS is stable. I get that with [4]launchpad.net.
>Your proposal makes no version ever available for a stable version.  yes,
>it contradicts the meaning of stable, but the idea is similar to the idea
>of using snaps, where certain applications require current versions, while
>most of the OS remains a stable platform.  
> 
Then I think that Ben Finney's observation is completely correct.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 8:41 PM Roberto C. Sánchez 
wrote:

> On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote:
> >
> >Hiring debian devs to get the packages into debian proper could make
> >sense. One thing that dampens our enthusiasm for that at the moment is
> >that our packages are still very unstable, in the sense that the we
> are
> >releasing materially better version incrementally, say once or twice a
> >month.  It is sort of analogous to a rolling release.  That works fine
> >with the launchpad model, but if it gets baked into debian, then we
> need
> >to support some random old version for many years. Perhaps once it has
> >stabilized, that would be something we could work with, but for now,
> the
> >[2]launchpad.net model, which supports backporting seamlesslly and
> allows
> >to support the same version on all distro versions, works better for
> us.
> >This is something a debian version of launchpad would get us.
> >
>
> You can already accomplish what you are describing today:
>
> - have packages uploaded to experimental
> - upload to unstable and file a release critical bug to prevent it
>   migrating to testing (look at https://bugs.debian.org/915050 for
>   instance)
>
> Both approaches get the package into Debian, available to users of
> unstable and/or experimental, as appropriate, and without risk of the
> package getting "baked in" to a Debian release for the long term.
>

OK for unstable and testing, but I want to provide packages for stable
versions of Debian using a separate repo that will be get frequent updates,
even though the OS is stable. I get that with launchpad.net. Your proposal
makes no version ever available for a stable version.  yes, it contradicts
the meaning of stable, but the idea is similar to the idea of using snaps,
where certain applications require current versions, while most of the OS
remains a stable platform.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Peter Silva  writes:

> One thing that dampens our enthusiasm for that at the moment is that
> our packages are still very unstable […], but if it gets baked into
> debian, then we need to support some random old version for many
> years.

By that description it is not a good candidate for putting into Debian
the operating system.

If the upstream project is not going to support specific releases for
years, that puts the onus on Debian package maintainers to choose a
version for support during the lifetime of a Debian release.

So would you agree, then, that the barrier to entry to the Debian system
is appropriate in this case?

-- 
 \  “I don't want to live peacefully with difficult realities, and |
  `\ I see no virtue in savoring excuses for avoiding a search for |
_o__)real answers.” —Paul Z. Myers, 2009-09-12 |
Ben Finney

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote:
> 
>Hiring debian devs to get the packages into debian proper could make
>sense. One thing that dampens our enthusiasm for that at the moment is
>that our packages are still very unstable, in the sense that the we are
>releasing materially better version incrementally, say once or twice a
>month.  It is sort of analogous to a rolling release.  That works fine
>with the launchpad model, but if it gets baked into debian, then we need
>to support some random old version for many years. Perhaps once it has
>stabilized, that would be something we could work with, but for now, the
>[2]launchpad.net model, which supports backporting seamlesslly and allows
>to support the same version on all distro versions, works better for us. 
>This is something a debian version of launchpad would get us.
> 

You can already accomplish what you are describing today:

- have packages uploaded to experimental
- upload to unstable and file a release critical bug to prevent it
  migrating to testing (look at https://bugs.debian.org/915050 for
  instance)

Both approaches get the package into Debian, available to users of
unstable and/or experimental, as appropriate, and without risk of the
package getting "baked in" to a Debian release for the long term.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 1:27 PM Roberto C. Sánchez 
wrote:

> On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote:
> >fwiw,  our organization doesn't have any debian devs.  We have a few
> >packages that we develop and deploy
> >for our internal needs, and make available to the internet with public
> >repositories.  they are (perhaps not perfectly) debian compliant
> packages,
> >but we aren't blessed debian devs (and frankly cannot be bothered to
> >become them.)
>
> There are many Debian developers who work as consultants specifically on
> Debian-related work, either independently or as part of a company that
> offers Debian-related services.
>
> Since you have done most of the work, you could easily hire one of those
> folks to help with a small number of hours worth of effort to take the
> package through the process of getting it into Debian.
>
> You can post to the debian-jobs list or check the Debian consultants
> page on the main Debian website for candidates.
>
> Regards,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>
Hiring debian devs to get the packages into debian proper could make sense.
One thing that dampens our enthusiasm for that at the moment is that our
packages are still very unstable, in the sense that the we are releasing
materially better version incrementally, say once or twice a month.  It is
sort of analogous to a rolling release.  That works fine with the launchpad
model, but if it gets baked into debian, then we need to support some
random old version for many years. Perhaps once it has stabilized, that
would be something we could work with, but for now, the launchpad.net
model, which supports backporting seamlesslly and allows to support the
same version on all distro versions, works better for us.  This is
something a debian version of launchpad would get us.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Phil Morrell

On Sun, Apr 07, 2019 at 07:01:28PM +0200, Alf Gaida wrote:
> For debian it could work the same way - just host the debian dir and be done
> with. Iirc the kde team work this way, they have only the debian dir in
> salsa. With a modified watch file it should be possible to get any source
> one want to. So the "only" thing needed is the infrastructure to host and
> maintain these repos. The rest is up to the user and a fundamental different
> approach as launchpad and ppa's.

I like it, and just wanted to share this related idea from the Gentoo
world about bootstrapping some automated trust without increasing
contribution friction too much:

https://dev.gentoo.org/~mgorny/articles/guru-a-new-model-of-contributing-to-gentoo.html#user-access-and-workflow
--
Phil Morrell


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote:
>fwiw,  our organization doesn't have any debian devs.  We have a few
>packages that we develop and deploy
>for our internal needs, and make available to the internet with public
>repositories.  they are (perhaps not perfectly) debian compliant packages,
>but we aren't blessed debian devs (and frankly cannot be bothered to
>become them.)

There are many Debian developers who work as consultants specifically on
Debian-related work, either independently or as part of a company that
offers Debian-related services.

Since you have done most of the work, you could easily hire one of those
folks to help with a small number of hours worth of effort to take the
package through the process of getting it into Debian.

You can post to the debian-jobs list or check the Debian consultants
page on the main Debian website for candidates.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 02:34:05PM +, Mo Zhou wrote:
> Hi,
> 
> The problem is not "who is responsible for implementing this", but "is
> this valuable enough to implement".
> 
> If a group of people think it worthwhile to do something, they will be
> glad to work together on a common belief, spontaneously.  I as the
> initiator of the idea would definitely take action if I got enough
> positive feedbacks.
> 
I recommend that you start implementing something then request feedback.
Otherwise the whole exercise is just academic.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Alf Gaida

On 07.04.19 17:40, gregor herrmann wrote:

I'm one of those people.
And I still don't know what "an AUR-like service" is, or what
"packaging scripts" are.

After reading the intro at
https://wiki.archlinux.org/index.php/Arch_User_Repository I guess,
translated to Debian terms, we are talking about user-provided source
packages?

Cheers,
gregor

Maybe a simple example of how things could work - the AUR consists of
several things

* the website https://aur.archlinux.org/
* the git repo
* some not official (and not really needed) helper scripts

The wiki put it in the best possible way:

Users can search and download PKGBUILDs from the AUR Web Interface. These PKGBUILDs can be built into installable packages using makepkg, then installed using pacman.

Let's take lxqt-about as example: It is both in the regular archlinux
repository and in the AUR:

* https://www.archlinux.de/packages/community/x86_64/lxqt-about
* https://aur.archlinux.org/packages/lxqt-about-git/

So - what is the difference in this case: the community repository
points to the release, the AUR package points to git master. The
packaging consits only of the PKGBUILD aka the "build script". Thats all.

One can download these scripts and build with a simple `makepkg`.
After building the package one can install the local packate with pacman:
* Repo: pacman -S lxqt-about
* local: pacman -U lxqt-about*tar.xz

And thats the whole magic - the only thing that the arch guys host is
the PKGBUILD, maybe some patches and install instructions. So they don't
have to care about any licensing or limitations - they only host the
receipe.

For debian it could work the same way - just host the debian dir and be
done with. Iirc the kde team work this way, they have only the debian
dir in salsa. With a modified watch file it should be possible to get
any source one want to. So the "only" thing needed is the infrastructure
to host and maintain these repos. The rest is up to the user and a
fundamental different approach as launchpad and ppa's.

Cheers Alf

PS: Please don't hit/yell at me if i've overly simplified some things. :)

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread gregor herrmann

On Sun, 07 Apr 2019 16:31:24 +0200, Jonathan Carter wrote:

> Reading some of the initial replies to your post, it seems like people
> don't entirely understand what you mean by an AUR-like service. This
> would definitely be different than PPAs (in the launchpad sense) or
> bikesheds (which is still a terrible name for all the confusion it causes).

I'm one of those people.
And I still don't know what "an AUR-like service" is, or what
"packaging scripts" are.

After reading the intro at
https://wiki.archlinux.org/index.php/Arch_User_Repository I guess,
translated to Debian terms, we are talking about user-provided source
packages?
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Furry Lewis: Billy lyons & stack o' lee


signature.asc
Description: Digital Signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Andrey Rahmatullin

On Sun, Apr 07, 2019 at 02:17:00PM +, Mo Zhou wrote:
> However, I got a hint from a fellow developer and learned that
> "Bikeshed" has its own meaning under Debian's context, according
> to some old mailing list fragments[2][3] -- which refers to a
> dak feature (This is the first time I heard of such thing).
Yes, I've meant this thing.
As you can see, the idea is old, but the ideas are not enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Adrian Bunk

On Sun, Apr 07, 2019 at 01:26:12PM +, Mo Zhou wrote:
>...
> (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep
> Neural Network) library, which dominates the field of high performance
> neural network training and inference. I really hate reading NVIDIA's
> non-free legal texts, and in such repository we can avoid reading the
> license and just get the scutwork done and make users happy.
> 
> (3) Data with obscure licensing. In this repository we can feel free to
> package pre-trained neural networks or training data without carefully
> examing the licensing.

The requirements for distributing software in the system you want to 
setup wouldn't be much different from what is required for non-free.

Anything that is legal to distribute can likely go into non-free.

>...
> (5) Packages that utilizes SIMD instructions heavily. Such package is
> very easy to package in such repo. (So this Proposal actually suppresses
> and replaces my SIMDebian project).

Run-time autodetection is the best solution.

We also have packages that build several versions of a program,
with a tiny wrapper that selects the best at startup.

> 2. Allows us to offload some low-popcon, or QA-questionable packages
> from the archive. Debian's archive size is continuously increasing, but
> the number of Debian Developers has been staying around 1000 for many
> many years. Saturation will definitely happen in the future if we do
> nothing to change - or saturation has already happended. An Archlinux
> Developer's saturation point may be several thousand (See Felix Yan, an
> Arch Dev), but a Debian Developer often saturate at, maybe 30~100?

You make it sound as if the number of packages would be what matters most.
Which is not true.

A low-popcon package that is old and stable and stale and doesn't depend 
on changing libraries usually just continues working with close to zero 
effort.

Most work is in the volatile areas of the archive, e.g. tensorflow as
one package might create more work than whatever you would consider
the saturation point for a single developer.

> Handing over some workload to the user community is not a bad thing,

"user community" sounds like a "somebody" that is in reality "nobody".

>...
> 3. Allows us to accept potential contributors friendly, and possibly
> form a new user community. The high quality standard of Debian may scare
> some potential contributors away.
>...

Package installation runs as root, which means you are granting root
access to the package creator of every single package you are installing.

Be it malicious intention or just a packaging mistake,
trust and quality are not really optional items.

> Best,
> Mo.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi,

The problem is not "who is responsible for implementing this", but "is
this valuable enough to implement".

If a group of people think it worthwhile to do something, they will be
glad to work together on a common belief, spontaneously.  I as the
initiator of the idea would definitely take action if I got enough
positive feedbacks.

On Sun, Apr 07, 2019 at 03:36:51PM +0200, Ondřej Surý wrote:
> > Can we implement it?
> 
> Who is “we”? This is the usual problem with missing
> DPA/bikesheds/whatever, the most productive developer “Somebody”
> hasn’t joined Debian yet...
> 
> Ondrej -- Ondřej Surý 
> 
> > On 7 Apr 2019, at 15:26, Mo Zhou  wrote:
> > 
> > Can we implement it?

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Jonathan Carter

On 2019/04/07 15:26, Mo Zhou wrote:
> 3. Allows us to accept potential contributors friendly, and possibly
> form a new user community. The high quality standard of Debian may scare
> some potential contributors away. In the informal packaging area, it's
> easier for people to contribute. Look at AUR and Archlinux Trusted Users
> as example. Of course, we can promote high quality creations from users
> into debian archive.
> 
> Just a few of my naive thoughts. If this idea came true, I'll
> denfinitely be able to continue with TensorFlow and PyTorch packaging,
> at an significantly lower cost. I'm also happy to throw some of my
> low-popcon packages to this area, so I can focus on more valuable ones.
> This idea really excites me. Can we implement it?

+1, it's a good idea and I've thought of it before as well.

Reading some of the initial replies to your post, it seems like people
don't entirely understand what you mean by an AUR-like service. This
would definitely be different than PPAs (in the launchpad sense) or
bikesheds (which is still a terrible name for all the confusion it causes).

Have you put any thought in possible implementation yet? I don't think
it's a good idea to devise any kind of new source packages. It's
probably not even necessary to use existing source packages. If you'd
have the standard debian packaging for such an AUR^W... DUR? in a git
repository (maybe like salsa.debian.org/dur/*) with a standardised git
workflow for these, then it should be rather trivial to implement with a
helper script that fetches the upstream source and just builds that
package locally. So I think from a technical point of view, implementing
something like AUR for Debian doesn't seem so hard. It can also act as a
nice gateway to proper Debian development.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 10:05:35PM +0800, Shengjing Zhu wrote:
> 
> Why not just start this as a personal project? And prove it works.

This is going to be a non-trivial initial work. On a non-business
and free-software basis, listen to the others first would be very
helpful. Positive feedbacks always help you strive forward on
volunteered works, right?

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Hi,

This single sentence is quite ambiguous to non-native english speakers.

At the first glance I interpreted the sentence as
  "This will only lead to flamewars"
due to the meaning of bikeshed[1].

However, I got a hint from a fellow developer and learned that
"Bikeshed" has its own meaning under Debian's context, according
to some old mailing list fragments[2][3] -- which refers to a
dak feature (This is the first time I heard of such thing).

Do you mean I should stop and forget such thoughts, or just mean "This
is just the initiative of the 'Bikeshed' feature of dak"?

[1] https://www.urbandictionary.com/define.php?term=bikeshed
[2] https://lists.debian.org/debian-devel/2013/05/msg00131.html
[3] http://debian.2.n7.nabble.com/DAK-Commands-for-Bikesheds-td3650941.html

On Sun, Apr 07, 2019 at 06:32:37PM +0500, Andrey Rahmatullin wrote:
> Isn't the Bikesheds initiative just this?
> 
> -- 
> WBR, wRAR

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

fwiw,  our organization doesn't have any debian devs.  We have a few
packages that we develop and deploy
for our internal needs, and make available to the internet with public
repositories.  they are (perhaps not perfectly) debian compliant packages,
but we aren't blessed debian devs (and frankly cannot be bothered to become
them.) (fwiw:
https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-daily )

We have been publishing products on launchpad.net for years.  We were able
to do that relatively quickly.  We would love to be able to upstream to
debian, but haven't figured it out.  There is a much higher barrier to
entry.  Our only option at the moment is likely suse build service, but we
haven't bothered to figure that out either... We use ubuntu internally, and
that's enough for internal use, so the others are nice to haves.  for
nearly anything on launchpad, it should be pretty straightforward for adapt
to whatever gets done for debian.  It also provides an intermediate on-ramp
for gettting packages into Debian.

as non-debian devs, something like launchpad looks useful to us.

On Sun, Apr 7, 2019 at 9:54 AM Karsten Merker  wrote:

> On Sun, Apr 07, 2019 at 01:26:12PM +, Mo Zhou wrote:
>
> > The absense of a centralized, informal Debian package repository where
> > trusted users could upload their own packaging scripts has been
> > long-forgotten. As an inevitable result, many user packaging scripts
> > exist in the wild, scattered like stars in the sky, with varied
> > packaging quality. Their existence reflects our users' demand,
> > especially the experienced ones', that has not been satisfied by the
> > Debian archive. Such idea about informal packaging repository has been
> > demonstrated successful by the Archlinux User Repository (AUR). Hence,
> > it should be valuable to think about it for Debian.
> >
> > Assume that Debian has an informal packaging repository similar to AUR,
> > which distrbutes packaging scripts only and requires to be built
> > locally. According to my observation and experience, such a repository:
> >
> > 1. Allows packaging in some compromised manner to exist, which means
> > they dont fully comply with DFSG or Policy. This makes great sense for
> > several kinds of packages:
> >
> > (1) Packages that are extremely hard to made compliant to Policy. For
> > example, bazel the build system of TensorFlow and other Google products
> > - No Debian Developer can make it meet the Policy's requirement without
> > great sacrifice. The outcome doesn't worth the waste in time and energy.
>
> This is something that would probably be acceptable to me on
> Debian-hosted infrastructure, but ...
>
> > (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep
> > Neural Network) library, which dominates the field of high performance
> > neural network training and inference. I really hate reading NVIDIA's
> > non-free legal texts, and in such repository we can avoid reading the
> > license and just get the scutwork done and make users happy.
> >
> > (3) Data with obscure licensing. In this repository we can feel free to
> > package pre-trained neural networks or training data without carefully
> > examing the licensing.
>
> ... this is something that I personally have a big problem with
> because it would set a precedent that I don't want the Debian
> project to set.  We as a project host a non-free repository
> (which is fine for me), but before we take packages into
> non-free, we put a lot of effort into checking the licenses for
> problems (besides them being non-free).  Hosting a repository on
> Debian infrastructure that effectively states "we don't care for
> any license terms" is a no-go for me, even if it contains only
> packaging scripts and not the actual non-free components.
>
> Regards,
> Karsten
> --
> Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
> Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
> sowie der Markt- oder Meinungsforschung.
>
>

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Shengjing Zhu

On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou  wrote:
>
> Hi folks,
>
> The absense of a centralized, informal Debian package repository where
> trusted users could upload their own packaging scripts has been
> long-forgotten. As an inevitable result, many user packaging scripts
> exist in the wild, scattered like stars in the sky, with varied
> packaging quality. Their existence reflects our users' demand,
> especially the experienced ones', that has not been satisfied by the
> Debian archive. Such idea about informal packaging repository has been
> demonstrated successful by the Archlinux User Repository (AUR). Hence,
> it should be valuable to think about it for Debian.
>
> Assume that Debian has an informal packaging repository similar to AUR,
> which distrbutes packaging scripts only and requires to be built
> locally. According to my observation and experience, such a repository:
>
> 1. Allows packaging in some compromised manner to exist, which means
> they dont fully comply with DFSG or Policy. This makes great sense for
> several kinds of packages:
>
> (1) Packages that are extremely hard to made compliant to Policy. For
> example, bazel the build system of TensorFlow and other Google products
> - No Debian Developer can make it meet the Policy's requirement without
> great sacrifice. The outcome doesn't worth the waste in time and energy.
>
> (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep
> Neural Network) library, which dominates the field of high performance
> neural network training and inference. I really hate reading NVIDIA's
> non-free legal texts, and in such repository we can avoid reading the
> license and just get the scutwork done and make users happy.
>
> (3) Data with obscure licensing. In this repository we can feel free to
> package pre-trained neural networks or training data without carefully
> examing the licensing.
>
> (4) Packages with dirty hacks, or targeted on testing the water. This
> makes sense for packages that doesn't worth the effort to make it fully
> compliant with Debian's quality requirement and some user just wants it.
>
> (5) Packages that utilizes SIMD instructions heavily. Such package is
> very easy to package in such repo. (So this Proposal actually suppresses
> and replaces my SIMDebian project).
>
> 2. Allows us to offload some low-popcon, or QA-questionable packages
> from the archive. Debian's archive size is continuously increasing, but
> the number of Debian Developers has been staying around 1000 for many
> many years. Saturation will definitely happen in the future if we do
> nothing to change - or saturation has already happended. An Archlinux
> Developer's saturation point may be several thousand (See Felix Yan, an
> Arch Dev), but a Debian Developer often saturate at, maybe 30~100?
> Handing over some workload to the user community is not a bad thing,
> especially for the cold packages.
>
> 3. Allows us to accept potential contributors friendly, and possibly
> form a new user community. The high quality standard of Debian may scare
> some potential contributors away. In the informal packaging area, it's
> easier for people to contribute. Look at AUR and Archlinux Trusted Users
> as example. Of course, we can promote high quality creations from users
> into debian archive.
>
> Just a few of my naive thoughts. If this idea came true, I'll
> denfinitely be able to continue with TensorFlow and PyTorch packaging,
> at an significantly lower cost. I'm also happy to throw some of my
> low-popcon packages to this area, so I can focus on more valuable ones.
> This idea really excites me. Can we implement it?
>

Why not just start this as a personal project? And prove it works.


-- 
Shengjing Zhu

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Ondřej Surý

> Can we implement it?

Who is “we”? This is the usual problem with missing DPA/bikesheds/whatever, the 
most productive developer “Somebody” hasn’t joined Debian yet...

Ondrej
--
Ondřej Surý 

> On 7 Apr 2019, at 15:26, Mo Zhou  wrote:
> 
> Can we implement it?

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

2019-04-07 Thread Andrey Rahmatullin

Isn't the Bikesheds initiative just this?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

[Idea] Debian User Repository? (Not simply mimicing AUR)