On Fri, Feb 07, 2014 at 08:07:41PM -0500, James McCoy wrote:
> On Fri, Feb 07, 2014 at 10:32:52AM +0100, Daniel Leidert wrote:
> > James McCoy wrote:
> > >Part of the reason I chose to use debian/upstream/ is that an extensible
> > >location for upstream related information (similar in spirit to
>
Greetings Fellow Developers,
I would like to put here some words that I had in mind since I
discovered the problem with the upstream file/dir in debian/.
It is already a respectable while that we use the debian/upstream
*file* for the documentation of bibliographic data in packages that
might ha
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: ipig
Version : SVN r5
Upstream Author : Mathias Kuhring
* URL : http://sourceforge.net/projects/ipig/
* License : BSD
Programming Lang: Java
Description : integrating PSMs into genom
Hi,
On Mon, 10 Feb 2014, Filippo Rusconi wrote:
> I discovered recently that upstream was to become a directory in
> debian/. While I think that such a choice might be a reasonably good
> idea, I have to admit my astonishment at the total absence of
> information/discussion around that matter, fro
Please a GR to override this bullshit.
There are 100 people who have chosen to use systemd. Yet they override everyone
else because they are in the right position.
Fuck systemd from the bottom of my heart.
Fuck it.
Fuck it.
FUCK SYSTEMD.
I do not want to learn systemd.
I do not want to deal w
A general resolution is needed. The 100 systemd users shouldn't be
able to take over debian linux. They're in the right place at the
right time
(they always seem to be), but their decision to foist this on us
should be overruled.
The systemd developers and supporters seek to enforce their vision o
Hi,
On Mon, Feb 10, 2014 at 11:42:20AM +0100, Raphael Hertzog wrote:
> This change was also suggested by Guillem Jover in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735840#20 and I tend
> to agree with the logic of grouping upstream related meta-data
> in a single directory.
Quoting this
Please a GR to override this bullshit.
There are 100 people who have chosen to use systemd. Yet they override
everyone else because they are in the right position.
Hello Craig!
On 02/10/2014 12:37 PM, Craig Bransworth wrote:
> Please a GR to override this bullshit.
Please consider being more respectful and keep a polite tone. You are
achieving nothing with this attitude except that you risk of
being banned from the lists.
Everyone is free to share their ow
On 10 February 2014 11:37, Craig Bransworth wrote:
> Please a GR to override this ...
>
The Debian Project welcomes and encourages participation by everyone.
No matter how you identify yourself or how others perceive you: we
welcome you. We welcome contributions from everyone as long as they
int
On Mon, Feb 10, 2014 at 01:28:38PM +0100, John Paul Adrian Glaubitz wrote:
> Please consider being more respectful and keep a polite tone. You are
> achieving nothing with this attitude except that you risk of
> being banned from the lists.
>
> Everyone is free to share their own opinion and you s
Le 9 févr. 2014 22:10, "Joerg Jaspert" a écrit :
>
> On 13482 March 1977, Bastien ROUCARIES wrote:
>
> > I would like to add license-problem-md5sum-non-free and ont
distibutable.
>
> Lets see, the following license-problem-* sound interesting beside the
> json-evil we already have:
>
> license-pro
previously on this list Peter Palfrader contributed:
> > I would really like to standardize on some prefix.
>
> > I like _ as a prefix because adduser doesn't allow the local sysadmin to
> > create accounts with that prefix without special flags, which I think
> > makes it a more useful reserve
previously on this list Sergey B Kirpichev contributed:
> Doesn't matter) rc.local shouldn't be used by local
> admin to start services from. Why not use usual init-script?
I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a
On Sat, 08 Feb 2014 04:01:53 +0100, Vincent Lefevre wrote:
> On 2014-02-06 13:44:30 +, Felipe Sateler wrote:
>> On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote:
>> > On 06.02.2014 00:39, Jaromír Mikeš wrote:
>> >> -ffast-math
>> >
>> > this is dangerous it changes results, sometimes s
On 10/02/14 13:46, Kevin Chadwick wrote:
> So I'd agree with the underscore but see the not allowing the local
> sysadmin to create accounts easily with it as a bad thing as they could
> perfectly well want to avoid collisions with packages as much as a
> debian dev.
A concrete example, please? If
[Sergey B Kirpichev]
> Probably init-d-script could pass some cli-specified options to sh
> with set builtin. To allow something like this:
>
> /etc/init.d/script -x start
> or
> /etc/init.d/script start -x
I ended up with this instead: 'DEBUG=true /etc/init.d/script start'
The new /lib/init/in
On 09/02/2014 13:14, Thomas Goirand wrote:
> Is it too late to fix this as a release goal, so that we get every
> init script to use /bin/sh?
Whether this is worth the effort or not (and not just *your* effort, the
effort of maintainers of packages with init scripts, even if just to
review and app
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: giira
Version : 0.0.20140210
Upstream Author : Franziska Zickmann
* URL : http://sourceforge.net/projects/giira/
* License : GPLv3
Programming Lang: Java, Python
Description : RNA-Se
On 10/02/14 14:55, Jonathan Dowland wrote:
> On 09/02/2014 13:14, Thomas Goirand wrote:
>> Is it too late to fix this as a release goal, so that we get every
>> init script to use /bin/sh?
>
> Whether this is worth the effort or not (and not just *your* effort, the
> effort of maintainers of packag
On Sat, Feb 08, 2014 at 12:30:18PM +0100, Tobias Frost wrote:
> Hallo Oleg,
>
> thanks for the report, but you should file a bug against the package
> ltsp (using the Debian BTS) as this is the general Debian devel list.
> (You can use e.g the tool "reportbug" for that, a "reportbug ltsp"
> shoul
Le 6 févr. 2014 14:37, "Thomas Goirand" a écrit :
>
> On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote:
> >> Since last summer, OpenRC has full support for LSB headers. Also, I
> >> believe that OpenRC is the only init system replacement which allows
> >> to mix dependencies with LSB or it's own
Even when I dislike systemd approach, you act as a spammer and you annoy
people.
This is the reason you are banned, not the paranoidal crap with "systemd
fanboys blah blah blah".
On Mon, Feb 10, 2014 at 7:44 PM, wrote:
> That was a great article against systemd (note: you'll be banned if you
>
On Mon, Feb 10, 2014, Craig Bransworth wrote:
> Fuck systemd from the bottom of my heart.
> Fuck it.
> Fuck it.
>
> FUCK SYSTEMD.
>
> I do not want to learn systemd.
> I do not want to deal with systemd.
> I hate the way it does things.
> I hate the way their community works.
Hi Craig. And t
On 02/11/2014 12:33 AM, Sam Hocevar wrote:
> On Mon, Feb 10, 2014, Craig Bransworth wrote:
>
>> Fuck systemd from the bottom of my heart.
>> Fuck it.
>> Fuck it.
>>
>> FUCK SYSTEMD.
>>
>> I do not want to learn systemd.
>> I do not want to deal with systemd.
>> I hate the way it does things.
>> I
Excerpts from Thomas Goirand's message of 2014-02-10 09:22:08 -0800:
> On 02/11/2014 12:33 AM, Sam Hocevar wrote:
> > On Mon, Feb 10, 2014, Craig Bransworth wrote:
> >
> >> Fuck systemd from the bottom of my heart.
> >> Fuck it.
> >> Fuck it.
> >>
> >> FUCK SYSTEMD.
> >>
> >> I do not want to lear
previously on this list Simon McVittie contributed:
> > So I'd agree with the underscore but see the not allowing the local
> > sysadmin to create accounts easily with it as a bad thing as they could
> > perfectly well want to avoid collisions with packages as much as a
> > debian dev.
>
> A co
On 02/10/2014 06:47 PM, Clint Byrum wrote:
> It is pretty ridiculous to me to consider the basic plumbing on the
> system as replaceable as the thing that decides where on the screen my
> shortcut to Google search for "lolcatz" goes.
I fully agree on that and other DDs already mentioned that in
th
Excuse me, but this reply isn't appropriate, just as much as the OP.
Redirecting him to another Unix distribution isn't the thing to do.
Instead, you should have informed the OP that we will continue to
support not only systemd, upstart, or whichever becomes the default.
Because that's the plan.
On Mon, 2014-02-10 at 19:41 +0100, John Paul Adrian Glaubitz wrote:
> We don't even manage to maintain two versions of ffmpeg (the original
> and the fork) even though many users actually prefer the original. How
> should this even work with the init system then?
Hi,
What about agreeing on a com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Le 10/02/2014 08:36, Andreas Tille a écrit :
> I wonder in how far it is to late for debian/watch and not for the file
> debian/upstream. Yey, I'm aware that we have two to three orders of
> magnitude more debian/watch files than debian/upstream fi
Hi John
On 10/02/2014 20:41, John Paul Adrian Glaubitz wrote:
> On 02/10/2014 06:47 PM, Clint Byrum wrote:
> Neglecting reliability and maintainability for the sake of being
> able to choose such a core component is a bad idea. I do not
> think it's really feasible to maintain several init systems
Hi David,
On Mon, Feb 10, 2014 at 03:37:54PM -0400, David Prévot wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Le 10/02/2014 08:36, Andreas Tille a écrit :
>
> > I wonder in how far it is to late for debian/watch and not for the file
> > debian/upstream. Yey, I'm aware that we
On 02/10/2014 08:13 PM, Svante Signell wrote:
> What about agreeing on a common syntax for a start? For example there is
> a proposal floating around in debian-devel by Petter Reinholdtsen
> entitled: Two line init.d scripts
Yes, I have seen Petter's suggestion and I don't think it's a good
soluti
Hi,
On Montag, 10. Februar 2014, John Paul Adrian Glaubitz wrote:
> There are many core components where you cannot be choose between
> different alternatives and no one bats an eye, yet everyone loses
> their mind when it comes to init.
Amen.
And really, please everybody (re-)read the above and
Hello!
We are well into the planning for DebConf14 which will take place in
Portland, Oregon, USA during the 23rd-31st of August, 2014.
It looks like it is again going to be a great event and hope that
everyone can come, but to make it happen we need your help.
We are now contacting potential sp
On 02/10/2014 08:27 PM, Jonathan Carter (highvoltage) wrote:
> sysvinit has hit its limit with it's dependency-based nature, and the
> only way to fix many outstanding bugs is by switching to an event-based
> system.
No, event-based is not the proper design to model the dependencies
between servic
Hi,
On Mon, Feb 10, 2014 at 09:10:56PM +0100, John Paul Adrian Glaubitz wrote:
> Again, I do not understand how our users will actually profit from
> being able to choose their init system.
I am a minimalist - I like sysvrc as it is today and i dont like
the "i can build a daemon which replaces m
>It is pretty ridiculous to me to consider the basic plumbing on the
>system as replaceable as the thing that decides where on the screen
my
>shortcut to Google search for "lolcatz" goes.
>
>Perhaps that is just me though. ;)
See, systemd pushers are always trying to make their thing the only
thing
Le Mon, Feb 10, 2014 at 09:06:06PM +0100, Andreas Tille a écrit :
>
> Thanks. Any helping hand is welcome. I simply want to make sure that
> the thing you are proposing will be really sustainable in the first
> place. The only problem I have with this issue is that changes like
> this should ha
Hello,
On Sun, Feb 09, 2014 at 02:11:21AM -0500, Filipus Klutiero wrote:
> There is no particular issue with migrating icedove to testing. Are
> you saying you intend to upload icedove 24 to wheezy?
not direct to wheezy, we'll use stable-security to push icedove 24 to
wheezy. This is the same way
On Mon, Feb 10, 2014 at 09:21:02AM +0100, Andreas Tille wrote:
> I wonder whether you have further files in mind which should end up in
> debian/upstream/ dir. Could your please give some reasons why you
> dropped the previously used location, debian/upstream-signing-key.pgp,
Quoting my initial e
> "debianfan" == debianfan writes:
debianfan>I would like to propose forking Debian if the ctte
debianfan> committee selects systemd
It's with great hesitation that I jump in here, and I know what I'm
doing is wrong.
I hope I've earned enough credibility over the years in the
Le Mon, Feb 10, 2014 at 08:38:51PM -0500, James McCoy a écrit :
>
> I'm not trying to be confrontational. I'm trying to do work towards
> what I thought you had agreed was an amenable solution as long as
> someone does the work.
…
> I've stated from the start that I would work on a transition, b
On Tue, Feb 11, 2014 at 11:08:44AM +0900, Charles Plessy wrote:
> Le Mon, Feb 10, 2014 at 08:38:51PM -0500, James McCoy a écrit :
> >
> > I'm not trying to be confrontational. I'm trying to do work towards
> > what I thought you had agreed was an amenable solution as long as
> > someone does the
Le Mon, Feb 10, 2014 at 09:39:09PM -0500, James McCoy a écrit :
>
> That wasn't clear to me in your previous messages, which is why I
> presumed you were wanting someone to transition the consumers of the
> file not the files themselves. That also seems like it's unnecessary to
> do immediately s
Sigh.
On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote:
> Using packages to support upstream development is a common problem and
> this is exactly where things get awkward.
No, it is not a *problem*; it is a *method* of doing things.
It is not your place (nor mine) to question anoth
Excerpts from Sam Hartman's message of 2014-02-10 17:29:47 -0800:
> > "debianfan" == debianfan writes:
>
> debianfan>I would like to propose forking Debian if the ctte
> debianfan> committee selects systemd
>
> It's with great hesitation that I jump in here, and I know what I'm
On 02/11/2014 02:41 AM, John Paul Adrian Glaubitz wrote:
> On 02/10/2014 06:47 PM, Clint Byrum wrote:
>> It is pretty ridiculous to me to consider the basic plumbing on the
>> system as replaceable as the thing that decides where on the screen my
>> shortcut to Google search for "lolcatz" goes.
>
Excerpts from Thomas Goirand's message of 2014-02-10 20:20:36 -0800:
> On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote:
> > Do we allow users to choose their FireWire stack, WiFi or Audio Driver
> > stack in the kernel? There were several alternative implementations
> > of these, yet we onl
On Mon, 2014-02-10 at 20:53 -0800, Clint Byrum wrote:
> So, perhaps if we teach Upstart and OpenRC to read systemd unit files,
> and they all can be expected to behave similarly, this will work out.
> Otherwise, giving everyone a choice just makes work for little gain.
Why should OpenRC and Upsta
Am 08.02.2014 um 20:03 schrieb Andrei POPESCU :
> On Vi, 07 feb 14, 19:22:06, Christoph Ender wrote:
>>
>> I’m currently thinking about creating a virtual package for "fizmo". [...]
>> I'd like to drop the transitional "fizmo" package for the jessie release
>> and provide a virtual package of the
52 matches
Mail list logo
