On 11.04.19 09:44, Mo Zhou wrote:
> Different from that, duprkit's design don't hope to limit> the user with any
> pre-defined "sequence", but enable the users to>
selectively call the functions they need. In other words, the> user can
define how to deal with the prepared source+debian
On 10.04.19 16:56, Helmut Grohne wrote:
Hi,
> I looked into this. Your reasons are sound and you are scratching your> itch.
> This is great.
ACK. It's always good when people make their hands dirty and work on
solving actual problems. Even if the actual output (=code, etc) finally
doesn't get
On 10.04.19 03:53, Russ Allbery wrote:
Hi,
> Possibly my least favorite> thing about RPMs is the spec files, because by
> smashing everything>
together into the same file, the syntax of that file is absurd. This
bit> is a shell script! This bit is a configuration file! This bit is>
On Sun, Apr 14, 2019 at 4:02 AM Thomas Goirand wrote:
>
> On 4/8/19 7:16 PM, Shengjing Zhu wrote:
> >> from PPA (source+binary-based).
> >
> > If people just want a PPA which supports Debian, please just take a
> > look at OBS[1].
> >
> > I've seen many upstreams provide packages with OBS, and
On 4/8/19 7:16 PM, Shengjing Zhu wrote:
>> from PPA (source+binary-based).
>
> If people just want a PPA which supports Debian, please just take a
> look at OBS[1].
>
> I've seen many upstreams provide packages with OBS, and most
> distributions are supported.
> Not only deb, but also rpm, from
On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote:
> Flatpak treats /usr as immutable (with the exception of mounting
> "extensions" on pre-prepared empty directories) and mounts it read-only in
> the container. If it didn't, it wouldn't be able to use content-addressed
> storage (the storage
On Fri, 12 Apr 2019 at 10:49:57 +0800, Paul Wise wrote:
> Is there any reason that making /app a
> symlink to /usr (or a directory containing only links to /usr)
> wouldn't work inside Flatpak packages?
Flatpak treats /usr as immutable (with the exception of mounting
"extensions" on pre-prepared
On Thu, Apr 11, 2019 at 7:01 PM Simon McVittie wrote:
> The "app" (directly-user-facing part) in a Flatpak package will be mounted
> on /app and so is expected to be built with --prefix=/app, so you can't
> reuse a compiled binary .deb unless it's for something that happens to be
> relocatable
On Thu, 11 Apr 2019 at 09:54:47 +, Mo Zhou wrote:
> On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> > On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> > It might be interesting to look at game-data-packager, which is another
> > tool that builds and optionally installs
On Thu, Apr 11, 2019 at 09:54:47AM +, Mo Zhou wrote:
> Any link please? Both apt-file-search and google found nothing.
It's in contrib.
https://tracker.debian.org/pkg/game-data-packager
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi,
On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> It might be interesting to look at game-data-packager, which is another
> tool that builds and optionally installs .deb files for data that is
> not suitable for the
On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> > It seems that a key aspect of this thing is avoiding to (re)distribute
> > sources.
It might be interesting to look at game-data-packager, which is another
tool that builds
Hi Helmut,
Thank you very much for the detailed review! :-)
On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> It seems that a key aspect of this thing is avoiding to (re)distribute
> sources. You give good reasons for why this is needed and I see no need
> to reiterate or discuss
Hi,
On Thu, Apr 11, 2019 at 08:40:07AM +0200, Thomas Goirand wrote:
> On 4/7/19 4:34 PM, Mo Zhou wrote:
> > I as the
> > initiator of the idea would definitely take action if I got enough
> > positive feedbacks.
>
> Great! Go ahead, and get in touch with the FTP team.
Much progress has been
On 4/7/19 4:34 PM, Mo Zhou wrote:
> Hi,
>
> The problem is not "who is responsible for implementing this", but "is
> this valuable enough to implement".
Opposite way. The problem is who's implementing. We all know this has a
lot of values.
> If a group of people think it worthwhile to do
Hi Mo,
On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote:
> 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
I looked into this. Your
> "Marc" == Marc Haber writes:
Marc> On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote:
>> The design of .durpkg is permissive enough because the header
>> part, i.e. the shell script is fully controled by the user. In
>> this shell script, one could just copy the nearby
Hi,
On Wed, Apr 10, 2019 at 09:46:28AM +0200, Marc Haber wrote:
> On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote:
> >The design of .durpkg is permissive enough because the header part, i.e.
> >the shell script is fully controled by the user. In this shell script,
> >one could just copy the
On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote:
>The design of .durpkg is permissive enough because the header part, i.e.
>the shell script is fully controled by the user. In this shell script,
>one could just copy the nearby debian directory to the root dir of
>source tree, and/or optionally
Hi,
On Tue, Apr 09, 2019 at 06:53:44PM -0700, Russ Allbery wrote:
> Mo Zhou writes:
>
> This is one of those vi vs. Emacs things: I don't think you're going to
> convince anyone who prefers it the other way. Possibly my least favorite
> thing about RPMs is the spec files, because by smashing
Mo Zhou writes:
> 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
>
* Vincent Bernat [190409 01:26]:
> ❦ 9 avril 2019 08:41 +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
❦ 9 avril 2019 08:41 +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
>> >
Vincent Bernat writes:
> ❦ 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
After a build, you get this
https://salsa.debian.org/science-team/python-xrayutilities/-/jobs/147913/artifacts/browse/debian/output/
Is it enought for you.
Mayve you can discuss with the salsa pipeline team and request a target in
order to produce a better repo.
cheers
Paul Wise writes:
> 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
> from PPA (source+binary-based).
If people just want a PPA which supports Debian, please just take a
look at OBS[1].
I've seen many upstreams provide packages with OBS, and most
distributions are supported.
Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and
even Archlinux,
On Mon, 2019-04-08 at 16:05 +, PICCA Frederic-Emmanuel wrote:
> now we have the salsa pipeline.
>
> does it fit your needs ?
Does this allow non-DD's to host packages? Nobody at Kitware is a DD,
we just host an unofficial third-party repository, similar to PPA.
Kyle
now we have the salsa pipeline.
does it fit your needs ?
On Mon, 2019-04-08 at 00:02 -0400, Peter Silva 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
> >
DUR is fine, DPA is fine PPA is not - as it is used before in a totally
different context.
The idea just to require git is really nice, putting all the things into
a single file is not. Not even Arch does it. (patches, install, config
...) - so the default debian dir should be enough.
On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote:
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.
Sorry I appreciate that *your* idea is different, and effectively
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
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
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
>
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
> > >
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
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
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.
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:
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
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
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
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.
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)
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
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
>
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
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)
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
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
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
❦ 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
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
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
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
>
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
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
> >
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
> >
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
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.
>
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
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
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
>
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
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
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
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,
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
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
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
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
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
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
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
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
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
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,
> 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?
Isn't the Bikesheds initiative just this?
--
WBR, wRAR
signature.asc
Description: PGP signature
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.
81 matches
Mail list logo
