* License : (GPL-2)
Programming Lang: (Bash)
Description : Build a Gitlab-PPA using GitLab CI
Gitlab-buildpkg-tools is a set of tools to build a "Gitlab-PPA" using GitLab
CI, with automatic package rebuild triggered by a push/merge on a branch of
your own repository.
Afte
hi Alec,
please stop mailing this thread and just use an epoch.
Before adding^wintroducing an epoch one should consult debian-devel@l.d.o,
you have done this, arguments were exchanged and (IMNSHO) no better
solution was found, so please do what has done to >1000 source packages
in the archive alr
On 03/07/2024 10:10, Philip Hands wrote:
Alec Leamas writes:
It seems better to take an "If we build it, they will come" approach.
New installs will likely get the Debian version without ever needing to
discover the PPA, and the rumour will spread (assuming the Debian
package work
cause pain.
>
> AIUI the botching was done by whoever put the PPA together.
>
> If that's the same as upstream, fair enough, but it seemed to me (having
> glanced at the repo) that upstream has been using sane versions
> throughout.
<83d8755d-5f57-47e1-bda3-553
Alec Leamas writes:
> On 02/07/2024 20:46, Gunnar Wolf wrote:
>> Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
>>> So, at least three possible paths:
>>>
>>> 1. Persuade users to uninstall PPA packages before installing official
>>> pac
IOhannes m zmölnig (Debian GNU|Linux) writes:
> anyhow here's my 2¢:
> according to you¹, upstream have simply botched their package
> versioning, which i would consider *a bug*.
> bugs cause pain.
AIUI the botching was done by whoever put the PPA together.
If that'
On 7/3/24 00:28, Alec Leamas wrote:
The upstream shall consider adopting 5 digit release version numbering
[...]
The upstream "shall" not do anything, they are open for discussions but
certainly not for dictates.
thou shalt not ask if thou wisheth for no answers.
(please keep in mind tha
ta2, 5.9.3-beta3 so this ordering
is, although a bit strange, still ok.
However, a quite large user base have PPA packages installed. These
have versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
number, so they are ordered. but all these versions are higher than
anything
nge, still ok.
However, a quite large user base have PPA packages installed. These have
versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
number, so they are ordered. but all these versions are higher than
anything like 5.9.x.
[...]
The upstream shall consider adopti
On 02/07/2024 20:46, Gunnar Wolf wrote:
Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
So, at least three possible paths:
1. Persuade users to uninstall PPA packages before installing official
packages and also generation 2 PPA packages with sane versions like 5.10.x
2. Use
Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
> So, at least three possible paths:
>
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x
>
> 2. Use versions like 90
Hi!
On Tue, 2024-07-02 at 03:32:53 +0200, Guillem Jover wrote:
> On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> > Quite. People are quite resistant to spoiling neat version numbers
> > with epochs, and no-one likes them, but they don't do any actual harm
> > (except sometimes break scripts
On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.
yes.
[...]
> Basically, you'd be burning a lot of social capital with upstream for no
> really good reason and you probably still wouldn't be able to convince
> them. I don't think it's worth it.
yes.
> I wo
Hi Jens,
On 02/07/2024 06:38, Jens Reyer wrote:
You may avoid the epoch if upstream is willing to provide a separate
package for about 2 years. (I did something similar to get rid of an
epoch in Ubuntu's wine packages a few years ago, replacing them with our
Debian packages):
package 9000.5
unifying the Debian, Ubuntu, and PPA
version numbers in such a way that packages from those repositories can be
used interchangeably.
I would suggest that you work with upstream on how they will version things in
the future, so you aren't bumping the epoch every year.
Agreed.
I have many
r that either being 9001 or 9000.1.
>>
>> Or, possibly, they could encourage everyone to uninstall the PPA package
>> before installing an official one. For example, release a new package to
>> their
>> PPA that displays a message encouraging everyone to uninstall
(sorry, I replied thinking I've read the entire thread, I didn't notice
that there is a second thread broken off of this one)
--
WBR, wRAR
signature.asc
Description: PGP signature
Is this a case where using a epoch is justified? If
> > > not,
> > > why?
> >
> > Adding epochs to work around 3rd-party repo version problems sounds quite
> > wrong.
> > We don't even add epochs that Ubuntu itself adds.
> >
>
> But th
Hi!
On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> On 2024-07-01 23:59 +0200, Alec Leamas wrote:
> > But this is not about third parties, it's about upstream which publishes PPA
> > packages. So far these are by far the most used Linux packages.
> >
> >
On July 2, 2024 12:26:49 AM UTC, Soren Stoutner wrote:
>Alec,
>
>On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
>> For Debian users we backport opencpn which works well. However, the
>> Ubuntu backport process is, well, interesting (been there, done that).
>
Alec,
On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
> For Debian users we backport opencpn which works well. However, the
> Ubuntu backport process is, well, interesting (been there, done that).
>
> The PPA represents a much better way to publish backports to curr
HI again,
This becomes somewhat more complicated than it perhaps is.
On 02/07/2024 02:08, Soren Stoutner wrote:
Although I generally agree with your conclusions, using a PPA is the type of
end user task that involved them making modifications to the repositories on
their systems. I would
Alec Leamas writes:
> So, at least three possible paths:
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like
> 5.10.x
> 2. Use versions like 9000.5.10, 9000.5.12. etc.
> 3. Use an ep
Alec,
Is upstream planning to maintain their PPA after the packages are released into
Debian?
Or, will it be more like Gentoo, OpenSUSE, or Mageia, where the OpenCPN website
simply links to the official packages?
https://opencpn.org/OpenCPN/info/downloadopencpn.html[1]
On Monday, July 1
Alec,
On Monday, July 1, 2024 4:59:26 PM MST Alec Leamas wrote:
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x
[...]
> Of these I would say that 1. is a **very** hard sell upstream.
ating that version 1.0 is newer than 2024.01.05.
So have I also understood it.
And this is more or less the situation. For all practical purposes the
PPA is the current upstream packages, it's not some random packaging of
opencpn. I have some control over both the PPA and the debian/ubuntu
Soren et. al.,
On 02/07/2024 01:31, Soren Stoutner wrote:
Alec,
If upstream wants to fix this problem, they could just make their next release
version 9000, with the one after that either being 9001 or 9000.1.
Or, possibly, they could encourage everyone to uninstall the PPA package
before
On 2024-07-01 23:59 +0200, Alec Leamas wrote:
> But this is not about third parties, it's about upstream which publishes PPA
> packages. So far these are by far the most used Linux packages.
>
> I also hesitate to add an epoch, after all they are basically considered
> evil.
ting that version 1.0 is newer than 2024.01.05. This is to
support upgrades of official Debian packages in Debian repositories from one
version to the next.
Epocs are not typically used to fix problems in .debs published in some PPA
that was never an official part of Debian. This case is a little odd
On July 1, 2024 11:25:59 PM UTC, Alec Leamas wrote:
>On 02/07/2024 01:19, Alec Leamas wrote:
>
>> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
>
>Looking at this from another point of view: is there any situation where an
>epoch is appropriate?
Yes. I don't th
;s just a
> sad legacy.
>
> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
>
> --a
If upstream wants to fix this problem, they could just make their next release
version 9000, with the one after that either being 9001 or 9000.1.
Or, possibly
On 02/07/2024 01:19, Alec Leamas wrote:
Let's drop this subthread, keeping eyes on the ball: what is a sane
version?
Looking at this from another point of view: is there any situation where
an epoch is appropriate?
--alec
Hi again
On 02/07/2024 01:13, Scott Kitterman wrote:
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in
this situat
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:54, Scott Kitterman wrote:
> > On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> >> If you switch hats for a moment: have you any advice for upstream in
> >> this situation?
> >
> > 8763.5.10
>
> Yes, I have ha
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in
this situation?
8763.5.10
Yes, I have had a similar idea using 1 instead of 8763 to make it
stand out less. In m
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:31, Scott Kitterman wrote:
>
> HI again
>
> > On July 1, 2024 10:18:07 PM UTC, Alec Leamas
wrote:
> >> But here the situation is that upstream do care and wants to fix it. But
> >> they need our help (an epoch) to acco
On 02/07/2024 00:31, Scott Kitterman wrote:
HI again
On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote:
But here the situation is that upstream do care and wants to fix it. But they
need our help (an epoch) to accomplish this to handle the legacy.
We could be helpful, or not. Why not giv
On July 1, 2024 10:18:07 PM UTC, Alec Leamas wrote:
>On 02/07/2024 00:10, Scott Kitterman wrote:
>
>Hi Scott,
>
>> Upstream can change the versioning however they want. They are upstream. If
>> they don't care to fix it, then I think we assume they are fine with it and
>> leave it as is.
>
>
On 02/07/2024 00:10, Scott Kitterman wrote:
Hi Scott,
Upstream can change the versioning however they want. They are upstream. If
they don't care to fix it, then I think we assume they are fine with it and
leave it as is.
But here the situation is that upstream do care and wants to fix it.
on problems sounds quite
> > wrong. We don't even add epochs that Ubuntu itself adds.
>
> But this is not about third parties, it's about upstream which publishes
> PPA packages. So far these are by far the most used Linux packages.
>
> I also hesitate to add an epoch
version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.
But this is not about third parties, it's about upstream which publishes
PPA packages. So far these are by far the most used Linux packages.
I also hesitate to add an epoch, after all they are basically
On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
> On 01/07/2024 20:48, Alec Leamas wrote:
> > Dear list,
> >
> > Still working with the opencpn package. Now trying to normalize the
> > Ubuntu PPA builds so they can are based on the same debian/ directory
&g
On 01/07/2024 20:48, Alec Leamas wrote:
Dear list,
Still working with the opencpn package. Now trying to normalize the
Ubuntu PPA builds so they can are based on the same debian/ directory
and tools as the existing Debian opencpn package.
opencpn is currently in a beta phase targeting a
Dear list,
Still working with the opencpn package. Now trying to normalize the
Ubuntu PPA builds so they can are based on the same debian/ directory
and tools as the existing Debian opencpn package.
opencpn is currently in a beta phase targeting a 5.10.1 release. The
beta versions are like
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung
X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org
* Package name: ppa-dev-tools
Version : 0.5.0
Upstream Contact: Bryce Harrington
* URL : https://launchpad.net/ppa-dev-tools
* License : GPL
Hello,
Von: "Steve McIntyre"
An: debian-devel@lists.debian.org
Betreff: Re: DPA instead of PPA
In article <518b7cf6.3080...@debian.org> you write:
>>On 09/05/13 07:38, Raphael Hertzog wrote:
>>> bikeshed \o/
>>
>>You probably meant this to be a comment
Packages
> SPA = Special Package Archive
Hi all,
Fist of all, many thanks to Joerg and the FTP team to push this project
forward. I find it exciting and innovative and I like that it is not simply
reproducing Ubuntu's PPAs, but rather aims at providing a direct benefit to
Debian's
On Thu, 09 May 2013, Steve McIntyre wrote:
> In article <518b7cf6.3080...@debian.org> you write:
> >On 09/05/13 07:38, Raphael Hertzog wrote:
> >> bikeshed \o/
> >
> >You probably meant this to be a comment on the discussion rather than a
> >suggested name, but "until it gets uploaded to unstable,
In article <518b7cf6.3080...@debian.org> you write:
>On 09/05/13 07:38, Raphael Hertzog wrote:
>> bikeshed \o/
>
>You probably meant this to be a comment on the discussion rather than a
>suggested name, but "until it gets uploaded to unstable, you can get
>GNOME 3.8 from the GNOME Team bikeshed" ac
On 2013-05-09 22:55:33 +0800 (+0800), Thomas Goirand wrote:
[...]
> And I seriously wished it wasn't the case, and that upstream
> understood better what the distribution requirements are.
[...]
Actually, in this case (OpenStack) from what I've seen the upstream
community understands the distribut
On 05/07/2013 03:34 PM, Joerg Jaspert wrote:
> While there are certainly use cases that will stay in a PPA forever
> (Thomas described one)
And I seriously wished it wasn't the case, and
that upstream understood better what the
distribution requirements are.
This should be considered
point is, if I had PPAs, I
> > > wouldn't at all upload to SID and wait for a migration to
> > > testing, because it would be better if the packages were
> > > living in the PPA only (that would be a lot more flexible and
> > > adapted to my use case).
&
Another opportunity these XPAs will bring, especially the ones that will
be used for staging large transitions, is to run piuparts and related
tests to discover (and fix) problems before they get introduced into
unstable.
Andreas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
On 09/05/13 07:38, Raphael Hertzog wrote:
> bikeshed \o/
You probably meant this to be a comment on the discussion rather than a
suggested name, but "until it gets uploaded to unstable, you can get
GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a
reasonable sentence to write. :-)
(O
On 05/07/2013 04:12 PM, Tollef Fog Heen wrote:
> Providing backports doesn't free you from the burden of making sure
> upgrades work. Thomas is facing a very large chunk of work to make sure
> upgrades from the no-longer-supported E release to whatever might be in
> jessie, since upstream breaks A
gt; To be fair, "Personal" is probably not relevant either. I expect many of
> those repositories to be maintained by teams.
>
> DSPA = Debian Special Purpose Archive
> DSPR = Debian Special Purpose Repository
> DASP = Debian Archive of Special Packages
> SPA = Special Packag
do that.
>> Also, the rules in backports is that packages should be already migrated
>> to testing. The point is, if I had PPAs, I wouldn't at all upload to SID
>> and wait
>> for a migration to testing, because it would be better if the packages were
>> living in t
Hi,
On Wed, 08 May 2013, Holger Levsen wrote:
> I actually really like this idea! (Though I suggest "Debian Personal
> Archive".)
>
> It's really different from what people know as PPAs.
To be fair, "Personal" is probably not relevant either. I expect many of
those repositories to be maintained
Hi,
On Dienstag, 7. Mai 2013, Thorsten Glaser wrote:
> > I think you may have misunderstood the Debian PPA proposal. It will
> > not be like the Ubuntu PPA system where anyone can upload a package to
> Call it DPA then?
> Debianprojectmember Personal Archive
I actually rea
On 07/05/13 15:34, Paul Wise wrote:
> On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote:
>> Debian backports offers me *one* repository. I need 3 of them:
>> - stable -1 (currently OpenStack Folsom)
>
> Ignore, is there any reason why an old version is interesting?
Because Debian testing has
The point is, if I had PPAs, I wouldn't at all upload to SID
> and wait
> for a migration to testing, because it would be better if the packages were
> living in the PPA only (that would be a lot more flexible and adapted to my
> use case).
I think that would be a bit sad and
Paul Wise debian.org> writes:
> I think you may have misunderstood the Debian PPA proposal. It will
> not be like the Ubuntu PPA system where anyone can upload a package to
Call it DPA then?
Debianprojectmember Personal Archive
bye,
//mirabilos
--
To UNSUBSCRIBE, email to deb
On 05/07/2013 03:11 PM, Brian May wrote:
> On 7 May 2013 17:03, Thomas Goirand <mailto:z...@debian.org>> wrote:
>
> Now, if I had PPA, then I could follow upstream release cycles.
> Every 6
> months, I would destroy the PPA for OpenStack stable -2, and create a
]] Brian May
> On 7 May 2013 17:03, Thomas Goirand wrote:
>
> > Now, if I had PPA, then I could follow upstream release cycles. Every 6
> > months, I would destroy the PPA for OpenStack stable -2, and create a
> > new stable PPA. I could put all the backport software
On 13204 March 1977, Adrian Alves wrote:
> Why I vote NO for ppa in Debian,
Unless someone runs a GR, its not a vote.
Im happy for changes/improvements, but it will come, so a "no" isn't the way.
> Something that everybody loves about debian is you have everything in
On 7 May 2013 17:03, Thomas Goirand wrote:
> Now, if I had PPA, then I could follow upstream release cycles. Every 6
> months, I would destroy the PPA for OpenStack stable -2, and create a
> new stable PPA. I could put all the backport software I need in there.
> No need to worry a
On 05/07/2013 12:23 PM, Adrian Alves wrote:
> Why I vote NO for ppa in Debian,
>
> Something that everybody loves about debian is you have everything in
> one repo for stable testing or development, the use of PPA it couse
> things like happens in ubuntu when u need something imp
> looking for something? YPPA in ubuntu has it own PPA u get my point?
I think you may have misunderstood the Debian PPA proposal. It will
not be like the Ubuntu PPA system where anyone can upload a package to
Launchpad and have it autobuilt for multiple releases. I suggest that
you
On Tue, May 7, 2013 at 1:42 AM, Brian May wrote:
> On 7 May 2013 14:23, Adrian Alves wrote:
>
>> am not saying PPA is bad just worried about not to lose the magic of
>> debian who has everything in one place.
>>
>
> This is already the case. Not everything I packag
On 7 May 2013 14:23, Adrian Alves wrote:
> am not saying PPA is bad just worried about not to lose the magic of
> debian who has everything in one place.
>
This is already the case. Not everything I package deserves to go into
Debian main. e.g. because it is specific to a problem I a
Why I vote NO for ppa in Debian,
Something that everybody loves about debian is you have everything in one
repo for stable testing or development, the use of PPA it couse things like
happens in ubuntu when u need something important you need to install it
from a PPA because is not in the repo
❦ 2 mai 2013 20:29 CEST, Pau Garcia i Quiles :
> This model has been working very well for me for years and users are happy.
> Sadly, there are no Debian PPAs and I'm forced to use the OpenSuse Build
> Service, which I don't really like (no dput, censored main archive, etc).
I am also using OB
* Jan Hauke Rahm (j...@debian.org) [110502 19:22]:
> On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> > > I guess I'm misunderstanding you here, so please help me out. If a
> > > package is being worked on in different PPAs regarding different
> > > problems (thinking of serializing
On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> * Jan Hauke Rahm (j...@debian.org) [110502 18:34]:
> > On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > > - APT entry
* Jan Hauke Rahm (j...@debian.org) [110502 18:34]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > build-depe
On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > build-dependencies not satisfiable in the target suite)
>
> Why not
* Roger Leigh (rle...@codelibre.net) [110501 19:04]:
> WRT the signing key, there would need to be some form of trust path
> or else the signature would be worthless. If packages are being
> uploaded to Debian infrastructure, and are under our control, can't
> we use a single signing key? We pres
On Sun, May 01, 2011 at 06:24:00PM +0200, Stéphane Glondu wrote:
> I was thinking of a request that would include a base suite (e.g.
> squeeze, wheezy, or sid), files to drop in /etc/apt/sources.list.d (and
> /etc/apt/preferences.d), and the key used to sign unofficial
> repositories. Of course, th
t; > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > build-dependencies not satisfiable in the target suite)
> >
> > Why not just use one location - shouldn't be an issue unless you plan
> > to have the same packages and version n
On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> * Raphael Hertzog (hert...@debian.org) [110501 18:23]:
> > On Sun, 01 May 2011, Andreas Barth wrote:
> > How can we submit jobs to a buildd?
> > - APT entry to add (i.e. URL of the PPA so that the buildd
* Stéphane Glondu (glo...@debian.org) [110501 18:24]:
> Le 01/05/2011 17:16, Andreas Barth a écrit :
> > Well yes, but how many autobuilding suites should we add? 50? 100?
> > 200? How do we do key management so that we know that the autobuilder
> > build the packages that they should?
>
> Why wou
ding (even if that happens this afternoon). It
> > needs however done in a way where buildds only pick up source packages
> > from one place, and upload to one place, independend whether the
> > source package is mozilla, ocaml, or something else.
>
> Another aspect is that t
Le 01/05/2011 17:16, Andreas Barth a écrit :
>> I don't understand why this is only point 5. Setting up a custom
>> repository easily usable is quite easy... and done already
>> (mozilla.debian.net has been mentioned; I also happen to provide
>> unofficial packages on ocaml.debian.net).
>
> It's e
way where buildds only pick up source packages
> from one place, and upload to one place, independend whether the
> source package is mozilla, ocaml, or something else.
Another aspect is that the PPA in question must be activated in the buildd
chroot so that build-dependencies can be solved in
* Stéphane Glondu (glo...@debian.org) [110501 17:00]:
> Le 01/05/2011 15:34, Andreas Barth a écrit :
> > 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> > coordinated with ftp-masters, so that the same method could be used
> > later on for uploading into
Le 01/05/2011 15:34, Andreas Barth a écrit :
> 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> coordinated with ftp-masters, so that the same method could be used
> later on for uploading into unstable.)
>
> 2. How could we create new ppa repositories easy en
* Pierre Habouzit (madco...@madism.org) [110501 01:32]:
> - link that PPA stuff to the main repository in a way that "merging"
> PPA into unstable is just a matter of one single command, or a few.
>
> - make it easy for users to subscribe to PPAs, meaning you have t
oint I was going to make before I read this para
was, the problem with running a copy of LP is getting all those other services
(bugs etc.) which we don't need - in fact, most likely, actively don't want, to
avoid diluting our existing services. Would installing and maintaining a
On Thu, Sep 23, 2010 at 07:17:22AM +0200, Marc 'HE' Brockschmidt wrote:
> Actually, the proposed project [1] also included work on the dak side
I read that as "dark side"... but the effect was just the same ;)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
al applications. And you wouldn't want or need to run
all of Launchpad's services.
> > It does require some changes to work with Debian's suites, but that
> > would be far easier than reimplementing all the functionality yourself.
>
> Given the above, I str
t; would be far easier than reimplementing all the functionality yourself.
Given the above, I strongly doubt that. Adding PPA-like functionality
to FusionForge *might* be easier, since we already have Alioth, but even
that would be a significant amount of work, if only to setup the
build-daemons for that n
> would be far easier than reimplementing all the functionality yourself.
This was discussed in the past already. Nothing "prevents" us to do
that, but PPA is actually quite tied to Launchpad infrastructure which
is significantly different than the Debian infrastructure which is m
> I still believe that this can and should be implemented. If someone is
> interested, I'm happy to help; I assume the same holds for Joerg.
True.
--
bye, Joerg
Yeah, patching debian/rules sounds like changing shoes while running the
100 meters track.
-- Michael Koch
--
To UNSUBSCRIBE, ema
ome way to get random packages autobuilt
> >>> would already be helpful (call that ppa if you want).>>
> >> I seem to recall, ftpmaster was planning something like that. Or wanted to?
> >> If so, what the status? If not, shall we start it? I think so.
> > HE proposed
Julien Cristau writes:
> On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote:
>> On Mittwoch, 22. September 2010, Mike Hommey wrote:
>>> PS: for my personal needs, some way to get random packages autobuilt
>>> would already be helpful (call that ppa if you wa
On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote:
> Hi,
>
> On Mittwoch, 22. September 2010, Mike Hommey wrote:
> > PS: for my personal needs, some way to get random packages autobuilt
> > would already be helpful (call that ppa if you want).
>
> I se
Hi,
On Mittwoch, 22. September 2010, Mike Hommey wrote:
> PS: for my personal needs, some way to get random packages autobuilt
> would already be helpful (call that ppa if you want).
I seem to recall, ftpmaster was planning something like that. Or wanted to?
If so, what the status? If not,
97 matches
Mail list logo
