On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote:
> But a growing number of upstreams disagree, so those upstreams are
> likely to be actively opposed to your recommendation to patches which
> remove non-source files from the VCS repository.
I wonder about the basis for that disagreement. I thin
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: flot-plugin-collection
Version : n/a
Upstream Author : Joe Loughton
* URL : https://github.com/oughton/flot-plugin-collection
* License : MIT
Programming Lang: Javascript
Description :
Michal,
On Wed, Nov 19, 2014 at 09:34:22AM +0100, Michal Suchanek wrote:
> On 19 November 2014 08:02, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit :
> >> On 18 November 2014 18:57, Jordi Mallach wrote:
> >> > El dl 17 de 11 de 2014 a les 15:41 +
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: flot-plugin-byte
Version : n/a
Upstream Author : Anthony Ryan
* URL : https://github.com/whatbox/jquery.flot.byte
* License : MIT
Programming Lang: Javascript
Description : plugin for Fl
Paul Wise writes:
> Upstreams that want to cater to end-users can distribute prebuilt
> binary packages separately, in separate branches, zip/tarballs, binary
> packages or "app" installers.
You'll get no disagreement from me on that.
But a growing number of upstreams disagree, so those upstrea
On Thu, Nov 20, 2014 at 12:48 PM, Ben Finney wrote:
> In my experience, many upstreams have an aversion to an explicit build
> step, because they see VCS as not only a VCS, but also as an end-user
> distribution platform.
I would suggest that VCSen are for developers, packagers and advanced
users
Paul Wise writes:
> I think the best solution is to send upstream some patches that remove
> the files in question from the VCS and add commands to their build
> system to build the files in question from their source.
In my experience, many upstreams have an aversion to an explicit build
step,
On Thu, Nov 20, 2014 at 3:19 AM, Salvo Tomaselli wrote:
> Generic question. In my experience some upstream include some redistributable
> binary files. For example some binary stuff to create a .app on osX, minified
> javascript, and whatever.
Could you include some information about the upstream
Quoting Simon McVittie (2014-11-19 21:49:49)
> On 19/11/14 19:41, Jonas Smedegaard wrote:
>> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
>> then suppressing that deamon with policy-rc.d will be circumvented
>> when cron triggers log rotation.
>
> If it uses "update-rc.d f
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: mars-dkms
Version: 0.1.09
Upstream Author: Thomas Schoebel-Theuer
URL: http://schoebel.github.io/mars/
License: GPL-2+, GFDL-1.3+
Description: Asynchronous Block-Level Sto
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: caliper
Version : 1.0-beta-1
Upstream Author : Gregory Kick
* URL : http://code.google.com/p/caliper/
* License : Apache-2.0
Programming Lang: Java
Description : framework for writing,
Hi,
Quoting Salvo Tomaselli (2014-11-19 20:19:59)
> Generic question. In my experience some upstream include some
> redistributable binary files. For example some binary stuff to create
> a .app on osX, minified javascript, and whatever.
>
> Now, assuming that:
>
> - these files are redistribu
On Wed Nov 19 2014 at 11:48:18 PM Rebecca N. Palmer
wrote:
> Anyone else seeing this problem?
>
> $ git pull
> fatal: unable to access
> 'https://anonscm.debian.org/git/pkg-opencl/beignet.git/': Failed to
> connect to anonscm.debian.org port 443: Connection refused
>
> https://alioth.debian.org/
Anyone else seeing this problem?
$ git pull
fatal: unable to access
'https://anonscm.debian.org/git/pkg-opencl/beignet.git/': Failed to
connect to anonscm.debian.org port 443: Connection refused
https://alioth.debian.org/ in a browser gives "can't establish a connection"
--
To UNSUBSCRIBE,
Hi,
On Wed, Nov 19, 2014 at 12:40:00AM -0800, Keith Packard wrote:
>
> I'd like to apologize to the systemd maintainer team, and to Tollef in
> particular for my TC vote on the libpam-systemd bug.
>
> The discussion on this issue was an excellent model of the Debian
> community at work:
Thank y
Simon McVittie writes:
> If you meant service, I think the answer is "that's a bug". service
> intentionally doesn't respect "enabledness" either, under at least
> sysvinit and systemd, so it's a bug even in the absence of policy-rc.d.
Right, service is a tool for the local administrator. servi
On 19/11/14 19:41, Jonas Smedegaard wrote:
> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> then suppressing that deamon with policy-rc.d will be circumvented when
> cron triggers log rotation.
If it uses "update-rc.d force-restart" then it will fail, because that
isn't a
Jonas Smedegaard writes:
> Which implies, I believe, that any other way of starting daemons should
> also respect policy-rc.d if it can lead to automated triggering.
> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> then suppressing that deamon with policy-rc.d will be c
On 19/11/14 19:19, Salvo Tomaselli wrote:
> Generic question. In my experience some upstream include some redistributable
> binary files. For example some binary stuff to create a .app on osX, minified
> javascript, and whatever.
...
> - these files are redistributable, so there is no legal probl
Salvo Tomaselli writes:
> Should the upstream tarball be repackaged to remove them, or not?
First, note that the source package of any package in Debian is also
covered by the Social Contract. (Some people are surprised by this, so
it bears stating explicitly.)
Second, the Social Contract (in t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/11/14 20:33, Marco d'Itri wrote:
> On Nov 19, Salvo Tomaselli wrote:
>
>> Should the upstream tarball be repackaged to remove them, or
>> not?
> They do not need to be removed at least if they can be rebuilt from
> the source in the package
Quoting Russ Allbery (2014-11-19 19:28:09)
> Bob Proulx writes:
>
> > No. That is too late. By the time you are disabling something it has
> > already been installed and started in postinst scripts. Using
> > policy-rc.d is the only way to prevent unknown anythings from being
> > enabled befor
On Nov 19, Salvo Tomaselli wrote:
> Should the upstream tarball be repackaged to remove them, or not?
They do not need to be removed at least if they can be rebuilt from the
source in the package (but they do not have to).
--
ciao,
Marco
pgpY1j9xGsHSF.pgp
Description: PGP signature
Hello,I have an investment project to propose to you or your firm.Please
contact me via georgewhitehead...@gmail.com for details.George Whitehead on
behalf of Howard Maxim +447087696373(AWH GLOBAL SERVICES)
Hello,
Generic question. In my experience some upstream include some redistributable
binary files. For example some binary stuff to create a .app on osX, minified
javascript, and whatever.
Now, assuming that:
- these files are redistributable, so there is no legal problem in hosting
them on d
Bob Proulx writes:
> No. That is too late. By the time you are disabling something it has
> already been installed and started in postinst scripts. Using
> policy-rc.d is the only way to prevent unknown anythings from being
> enabled before installing.
Ah, yes, that's true.
> P.S. Related to
Russ Allbery wrote:
> Bob Proulx writes:
> > Maybe I am missing a better alternative?
>
> update-rc.d disable
No. That is too late. By the time you are disabling something it has
already been installed and started in postinst scripts. Using
policy-rc.d is the only way to prevent unknown anyth
On Wed, Nov 19, 2014 at 03:41:12PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > As I explained in the earlier discussion with Henrique, there are more
> > things than just : and ~ which are perfectly legal in debian version
>
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: nailgun-mcagents
Version : 0.0.1
Upstream Author : OpenStack Development Mailing List
* URL : https://github.com/thomasgoirand/nailgun-mcagents
* License : Apache-2.0
Programming Lang: R
On Wed, 19 Nov 2014, Michal Suchanek wrote:
> >> Release: testing
> I had Ubuntu base system on this particular PC some years ago and I
Hah! I’m not the only one then ☺
bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...
--
To UNSUBS
On Tue, 18 Nov 2014, Helmut Grohne wrote:
> From this little exercise, it seems that it is not well understood in
> what way services should be signalled after log rotation. In particular,
> it seems to me that service and invoke-rc.d should not be both valid. So
I’ve experimented a bit with this
Am Dienstag, 18. November 2014, 23:31:53 schrieb Steve Langasek:
> On Tue, Nov 18, 2014 at 07:47:59PM +0100, Matthias Urlichs wrote:
> > Your specific package may well have different and non-general
> > requirements,
> > in which case
> >
> > > >> ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINI
Le 19/11/2014 14:55, Michael Meskes a écrit :
> Also, as a bonus question to the Debian folks, should we try
> establishing a cloudstack packaging group or do we push the effort into
> the java packaging group?
Cloudstack is more than welcome under the pkg-java umbrella if that
helps you getting
Hi Wido / Michael,
I would like to be part of this group, have some RPM packaging experience in
Cloudstack and Cloudplatform.
Regards,
Rayees
-Original Message-
From: Michael Meskes [mailto:mes...@debian.org]
Sent: Wednesday, November 19, 2014 5:56 AM
To: debian-devel@lists.debian.
Hi,
On Wed Nov 19, 2014 at 14:55:51 +0100, Michael Meskes wrote:
> Hi,
>
> Wido and I have been talking about bringing Cloudstack into Debian.
> There is quite a bit of work involved because several dependencies are
> not yet packaged.
>
> This obviously brings up the question if anyone else on
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As I explained in the earlier discussion with Henrique, there are more
> things than just : and ~ which are perfectly legal in debian version
> strings, but are illegal constructs in git refnames.
AFAICT[1], the
On 19 November 2014 16:12, Gunnar Wolf wrote:
> Before anything else, Michal: Please remember Debian is a
> volunteer-run project. It is sometimes tempting to reply mails in a
> haste and making ironic remarks to drive your points further. But
> mails such as this one are not welcome in Debian. Pl
Before anything else, Michal: Please remember Debian is a
volunteer-run project. It is sometimes tempting to reply mails in a
haste and making ironic remarks to drive your points further. But
mails such as this one are not welcome in Debian. Please assume good
faith, and treat everybody with respec
Laurent Bigonville writes ("Re: Re: init system policy"):
> Matthias Urlichs wrote:
> > See "man 5 sudoers" for details.
>
> You probably want to use "runuser" that has been introduced recently in
> utils-linux
Or `really' from chiark-really (from chiark-utils).
Ian.
--
To UNSUBSCRIBE, email
Hi,
Wido and I have been talking about bringing Cloudstack into Debian.
There is quite a bit of work involved because several dependencies are
not yet packaged.
This obviously brings up the question if anyone else on either of the
developer lists is interested in working on it? Please raise your
Eric Valette wrote:
> well, debconf seems like a win here.
> There's no reasonable default so it's desirable to make it easy for
the
> admin to specify and so you'd probably want to use normal best
practice
> for debconf updates.
I agree with this but unf
Matthias Urlichs wrote:
> Hi,
>
> Steve Langasek:
> > The disadvantage of the sudo method is that you are spawning a PAM
> > session, which is not desirable for any service.
> >
> Ah. Thanks for the reminder; mentioning the session issue completely
> slipped my mind. :-/
>
> If one does need to
On 18 November 2014 00:52, Thomas Goirand wrote:
> On 11/18/2014 03:50 AM, Michal Suchanek wrote:
>> With
>> current sysvinit the serial console is also used as main but
>> sysvinit-core does not produce any messages on tty0 whatsoever and so
>> does not mislead the user into thinking that useful
> well, debconf seems like a win here.
> There's no reasonable default so it's desirable to make it easy for the
> admin to specify and so you'd probably want to use normal best practice
> for debconf updates.
I agree with this but unfortunately original minidlna package as no
debconf setup :-)
--
I'd like to apologize to the systemd maintainer team, and to Tollef in
particular for my TC vote on the libpam-systemd bug.
The discussion on this issue was an excellent model of the Debian
community at work:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578
Josh Triplett (who is
Le mercredi, 19 novembre 2014, 09.34:22 Michal Suchanek a écrit :
> On 19 November 2014 08:02, Didier 'OdyX' Raboud
wrote:
> > Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit :
> >> I had Ubuntu base system on this particular PC some years ago and I
> >> noticed this issue and spe
On 19 November 2014 08:02, Didier 'OdyX' Raboud wrote:
> Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit :
>> On 18 November 2014 18:57, Jordi Mallach wrote:
>> > El dl 17 de 11 de 2014 a les 15:41 +0100, en/na Michal Suchanek va
>> > escriure:
>> >> -- System Information:
>> >> D
❦ 19 novembre 2014 08:45 +0100, Matthias Urlichs :
>> The disadvantage of the sudo method is that you are spawning a PAM session,
>> which is not desirable for any service.
>>
> Ah. Thanks for the reminder; mentioning the session issue completely
> slipped my mind. :-/
>
> If one does need to u
48 matches
Mail list logo
