On Fri, Jul 22, 2011 at 07:01:03PM -0500, Elías Alejandro wrote:
> > > > You mention that the upstream author *transformed* the image.
> > Mechanical
> > > > transformations (such as compilation of source code) do not normally
> > have
> > > > copyright associated with them, so the copyright of ca
> > > You mention that the upstream author *transformed* the image.
> Mechanical
> > > transformations (such as compilation of source code) do not normally
> have
> > > copyright associated with them, so the copyright of cat.pzl would
> probably
> > > be the same as for cat.jpg.
> > >
> > yes, wou
On 2011-07-22, Thomas Goirand wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand
>
> * Package name: blktap
> Version : 1.0.0
> Upstream Author : http://www.xen.org/products/cloudxen.html
> * URL : http://www.xen.org/products/cloudxen.html
> * License
On Fri, Jul 22, 2011 at 11:42:20AM -0500, Elías Alejandro wrote:
> On Fri, Jul 22, 2011 at 07:47:25AM +0200, Steve Langasek wrote:
> > debian/copyright should list the names of the actual copyright holders of
> > the work. debian-devel is not a great resource for helping you figure out
> > who tho
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: blktap
Version : 1.0.0
Upstream Author : http://www.xen.org/products/cloudxen.html
* URL : http://www.xen.org/products/cloudxen.html
* License : BSD
Programming Lang: C
Description :
> From what I've seen in Lennart's posts, adding systemd support doesn't
> seem to be too complicated.
No. No changes at all are necessary to be compatible with systemd.
This is a very impressive feature of systemd; at the same time, this is
what complicates systemd, and creates a dependency on c
On Fri, Jul 22, 2011 at 3:31 PM, Juliusz Chroboczek wrote:
>> From what I've seen in Lennart's posts, adding systemd support doesn't
>> seem to be too complicated.
>
> No. No changes at all are necessary to be compatible with systemd.
> This is a very impressive feature of systemd; at the same ti
Le jeudi 21 juil. 2011 à 19:39:00 (+0200 CEST), Simon McVittie a écrit :
> On Thu, 21 Jul 2011 at 19:16:50 +0200, Julien Valroff wrote:
> > When running this type of config, how do you avoid pushing the upstream
> > tags to the debian repository?
>
> To push individual tags, use "git push origin 1
On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek
wrote:
>>>No, I don't think so. If these external tools double fork then they
>>>are just wrong.
>
>> Double Forking has been the right way to do it for decades.
>
> It has been the default way for most daemons, granted. (Getty is
> a notable
Hi Steve,
On Fri, Jul 22, 2011 at 07:47:25AM +0200, Steve Langasek wrote:
> debian/copyright should list the names of the actual copyright holders of
> the work. debian-devel is not a great resource for helping you figure out
> who those copyright holders are, but if the upstream author has alrea
Le vendredi 22 juillet 2011 à 11:32 +0200, Stephan Seitz a écrit :
> So let systemd be part of Debian, but not as default init system. Maybe
> it can be used in about five years when all third party software is
> supporting it.
Seriously, I suggest that you document yourself instead of writing
2011/7/22 Picca Frédéric-Emmanuel
:
> Hello,
>
> I hope that this mailing list is the right one for that kind of questions.
>
> I am investigating the availability of packages for de IBM General
> Parallel File System (GPFS) [1] for Debian. It seems that this kind of
> distributed filesystem is of
Guus Sliepen writes:
> I would hardly call that a suitable comparison. How hard can it be to
> support both sysvinit and systemd?
For everything in Debian? Unless you're willing to write init scripts and
cripple systemd by making it use init scripts, it's a huge pain, since you
have to maintain
>>No, I don't think so. If these external tools double fork then they
>>are just wrong.
> Double Forking has been the right way to do it for decades.
It has been the default way for most daemons, granted. (Getty is
a notable exception.)
> Demanding from upstreams that they change their softwar
Am 22.07.2011 16:59, schrieb Stephan Seitz:
> On Fri, Jul 22, 2011 at 04:49:28PM +0200, Michael Biebl wrote:
>> The configuration file for rsyslog is /etc/rsyslog.conf resp.
>> /etc/rsyslog.d
>
> Configuration file for the daemon is /etc/default/rsyslog:
The canonical configuration file for the
On Fri, Jul 22, 2011 at 04:49:28PM +0200, Michael Biebl wrote:
The configuration file for rsyslog is /etc/rsyslog.conf resp.
/etc/rsyslog.d
Configuration file for the daemon is /etc/default/rsyslog:
# Options for rsyslogd
# -m 0 disables ‚MARK’ messages (deprecated, only used in compat mode
#
Am 22.07.2011 16:38, schrieb Stephan Seitz:
> On Fri, Jul 22, 2011 at 04:24:33PM +0200, Michael Biebl wrote:
>> We already have systemd in unstable (and soon testing) and even
>> a handful of packages shipping native systemd service files. The most
>> prominent ones are probably rsyslog, dbus, ud
On Fri, Jul 22, 2011 at 04:24:33PM +0200, Michael Biebl wrote:
We already have systemd in unstable (and soon testing) and even
a handful of packages shipping native systemd service files. The most
prominent ones are probably rsyslog, dbus, udev and network-manager.
Indeed, rsyslog has a servic
Am 22.07.2011 15:53, schrieb Stephan Seitz:
> On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote:
>> (Ignoring the kFreeBSD side of things for a bit): Why? As others have
>> pointed out, systemd uses sysvinit scripts just fine.
>
> Well, then why don’t we put systemd in testing as al
Am 22.07.2011 15:32, schrieb Russell Coker:
> On Fri, 22 Jul 2011, Tollef Fog Heen wrote:
>> Another would be to ship three systemd units, one being «smtp», one
>> being «queue runner» a third being «smtp+queue runner» or just generate
>> the .service file dynamically based on what the admin confi
On Fri, 22 Jul 2011, Tollef Fog Heen wrote:
> | Also, if systemd would use init scripts just fine, then one could
> | argue to just use SysV init scripts for everything, since then there
> | is no extra effort involved and people can easily swap init systems.
>
> You can, sure, but if we accept t
On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote:
(Ignoring the kFreeBSD side of things for a bit): Why? As others have
pointed out, systemd uses sysvinit scripts just fine.
Well, then why don’t we put systemd in testing as alternate init system
and release it as alternate init
]] Guus Sliepen
| On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote:
|
| > | How hard can it be to
| > | support both sysvinit and systemd? It's just two little files to
| > | maintain instead of one. We also have/had both .menu and .desktop
| > | files. Sure, they will be out of s
On Fri, 22 Jul 2011, Tollef Fog Heen wrote:
> Another would be to ship three systemd units, one being «smtp», one
> being «queue runner» a third being «smtp+queue runner» or just generate
> the .service file dynamically based on what the admin configures through
> debconf.
If there were systemd u
On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote:
> | How hard can it be to
> | support both sysvinit and systemd? It's just two little files to
> | maintain instead of one. We also have/had both .menu and .desktop
> | files. Sure, they will be out of sync once in a while, but other
]] Guus Sliepen
| On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
|
| > If you want a more suitable comparison, supporting two init systems
| > would be like supporting two packaging formats. It means more work for
| > all maintainers to support all possible combinations, and i
]] Marc Haber
Hi,
| exim4 is one example, and it adds some extra complexity. An exim4
| daemon does two jobs: Running the queue and listening for SMTP.
| Currently, you can configure in /etc/default/exim4 whether you want
| both jobs to be done by the same daemon, two dedicated daemons or only
|
2011/7/22 Luk Claes :
> On 07/22/2011 10:19 AM, Picca Frédéric-Emmanuel wrote:
>> Hello,
>
> Hi
>
>> I hope that this mailing list is the right one for that kind of questions.
>>
>> I am investigating the availability of packages for de IBM General
>> Parallel File System (GPFS) [1] for Debian. It
]] Robert Millan
|
| If portability was made a mandatory requirement for an init system to
| be adopted,
| would the systemd porters be willing to implement everything needed
| to support on non-Linux ports the packages using a non-traditional init
| configuration, in the way they consider appro
On Fri, Jul 22, 2011 at 9:20 AM, Fernando Lemos wrote:
> On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen wrote:
>> By the way, we already have the SysV init scripts, so we don't need to do
>> anything to keep supporting that, while it will take some time before every
>> package with a daemon has th
On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen wrote:
> By the way, we already have the SysV init scripts, so we don't need to do
> anything to keep supporting that, while it will take some time before every
> package with a daemon has the required systemd scripts in place, I think we
> should wait
Package: wnpp
Severity: wishlist
Owner: Guillaume Delacour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: whatweb
Version : 0.4.7
Upstream Author : Andrew Horton
* URL : http://www.morningstarsecurity.com/research/whatweb
* License : GPLv2
Package: wpnn
Severity: wishlist
Owner: "Edgar Antonio Palma de la Cruz"
* Package name: wizznic
Version : 0.9.2-preview2
Upstream Author : Jimmy Christensen
* URL : http://wizznic.sf.net/
* License : GPL3+
Programming Lang: C
Description : Implementat
On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
> If you want a more suitable comparison, supporting two init systems
> would be like supporting two packaging formats. It means more work for
> all maintainers to support all possible combinations, and it doesn’t
> change anything
On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
Le vendredi 22 juillet 2011 à 09:58 +0200, Stephan Seitz a écrit :
>So, since you don’t need it, other people don’t need it either?
No, since I don’t need it, I don’t want to be forced to use it.
So you prefer to force your crap
On 07/22/2011 10:19 AM, Picca Frédéric-Emmanuel wrote:
> Hello,
Hi
> I hope that this mailing list is the right one for that kind of questions.
>
> I am investigating the availability of packages for de IBM General
> Parallel File System (GPFS) [1] for Debian. It seems that this kind of
> distri
Le vendredi 22 juillet 2011 à 09:58 +0200, Stephan Seitz a écrit :
> On Thu, Jul 21, 2011 at 11:37:48PM +0200, Josselin Mouette wrote:
> >Le jeudi 21 juillet 2011 à 20:01 +0200, Stephan Seitz a écrit :
> >So, since you don’t need it, other people don’t need it either?
>
> No, since I don’t need i
Hello,
I hope that this mailing list is the right one for that kind of questions.
I am investigating the availability of packages for de IBM General
Parallel File System (GPFS) [1] for Debian. It seems that this kind of
distributed filesystem is of 1st importance for an European institut to
migra
On Thu, Jul 21, 2011 at 09:11:50PM -0500, Elías Alejandro wrote:
> Dear all,
> I've just read this thread. What do you think about this [1]
> [1] http://lists.debian.org/debian-mentors/2011/07/msg00427.html
debian/copyright should list the names of the actual copyright holders of
the work. debia
On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
wrote:
>No, I don't think so. If these external tools double fork then they
>are just wrong.
Double Forking has been the right way to do it for decades. Demanding
from upstreams that they change their software this fundamentally to
cater for a new
On Thu, Jul 21, 2011 at 11:37:48PM +0200, Josselin Mouette wrote:
Le jeudi 21 juillet 2011 à 20:01 +0200, Stephan Seitz a écrit :
So, since you don’t need it, other people don’t need it either?
No, since I don’t need it, I don’t want to be forced to use it.
You know, there are some who just w
Package: wnpp
Severity: wishlist
Owner: Andras Horvath
* Package name: tomld
Version : 0.38-1
Upstream Author : Andras Horvath
* URL : http://log69.com
* License : GPLv3
Programming Lang: C
Description : tomoyo learning daemon, fully automatic MAC con
42 matches
Mail list logo
