Control: reassign -1 wnpp
Control: retitle -1 RFP: klogg -- Really fast log explorer based on glogg
project
On Mi, 08 sep 21, 12:08:32, Daniele Mte90 Scasciafratte wrote:
> Package: klogg
> Version: 21.09.0.1162
> Severity: wishlist
> X-Debbugs-Cc: mte90...@gmail.com
>
>
really basic thread-safe progress bar for Golang
applications
A very simple cross-platform, OS agnostic thread-safe progress bar in Golang.
--
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15 3D1F 4FA2 70F5 CD36 71F9
signature.asc
Description: PGP signature
On Sun, 2021-01-17 at 12:53 +, Simon McVittie wrote:
> On Sun, 17 Jan 2021 at 11:49:00 +, Philip Wyett wrote:
> > I am no Pipewire expert like you
>
> Please don't mistake me for a Pipewire expert! I'm only doing drive-
> by
> uploads because we need it for GNOME. I do not have the bandwid
On Sun, 17 Jan 2021 at 11:49:00 +, Philip Wyett wrote:
> I am no Pipewire expert like you
Please don't mistake me for a Pipewire expert! I'm only doing drive-by
uploads because we need it for GNOME. I do not have the bandwidth to be
responsible for Pipewire and you'll notice I have deliberatel
On Sun, 2021-01-17 at 10:31 +, Simon McVittie wrote:
> On Sun, 17 Jan 2021 at 05:01:30 +, Philip Wyett wrote:
> > Installing Debian testing and now also using bullseye-DI-alpha3,
> > the
> > default desktop install/gnome is still installing vino and not
> > installing gnome-remote-desktop b
On Sun, 17 Jan 2021 at 05:01:30 +, Philip Wyett wrote:
> Installing Debian testing and now also using bullseye-DI-alpha3, the
> default desktop install/gnome is still installing vino and not
> installing gnome-remote-desktop by default.
The version of meta-gnome3 in GNOME team git Suggests gno
Hi,
Installing Debian testing and now also using bullseye-DI-alpha3, the
default desktop install/gnome is still installing vino and not
installing gnome-remote-desktop by default.
As we know, vino does not work with wayland and is not being actively
developed and focus has shifted to the wayland
Your message dated Tue, 28 Jul 2020 16:09:46 +0200
with message-id <1ca5332ecc18afa1b6e0294cd0c52af09f91a46e.ca...@43-1.org>
and subject line Re: are binary-indep -dev packages really worth the space
savings?
has caused the Debian Bug report #745656,
regarding are binary-indep -dev pa
> "Alexander" == Alexander Wirt writes:
>> I'm sorry, but Bastian's statement was inherently official. He
>> was a Salsa Admin, saying something that could only be said in
>> his official role. When I took it as an official statement and
>> acted on it, he thanked me rather
On Wed, Oct 09, 2019 at 09:51:09AM -0400, Marvin Renich wrote:
> * Alexander Wirt [191009 08:45]:
> > If we want to announce something, we announce it. Until we do something like
> > this: of course there can be a (temporary) veto. You can't expect us to
> > allow
> > things that will break the s
* Alexander Wirt [191009 08:45]:
> If we want to announce something, we announce it. Until we do something like
> this: of course there can be a (temporary) veto. You can't expect us to allow
> things that will break the service for everybody without stepping in. That
> doesn't mean that such thin
On Wed, 09 Oct 2019, Sam Hartman wrote:
> > "Alexander" == Alexander Wirt writes:
>
> Alexander> On Sun, 15 Sep 2019, Jonas Meurer wrote:
> >> Sam Hartman: >> "Bastian" == Bastian Blank
> >> writes:
> >> >
> >> > Bastian> Hi Sam
> >> > Bastian> On Sun, Sep 0
> "Alexander" == Alexander Wirt writes:
Alexander> On Sun, 15 Sep 2019, Jonas Meurer wrote:
>> Sam Hartman: >> "Bastian" == Bastian Blank
>> writes:
>> >
>> > Bastian> Hi Sam
>> > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman
wrote:
>> >
That repository is more of a remote backup, but I would be happy to collaborate
on something more useful to general DD public...
There’s some additional content in this ticket that might go into the readme:
https://github.com/oerdnj/deb.sury.org/issues/1092
Ondrej
--
Ondřej Surý
> On 8 Apr 20
Hey,
check https://jenkins.rfc1925.org and f.e. https://packages.sury.org/php/
--
Ondřej Surý
> On 8 Apr 2019, at 18:22, Holger Levsen wrote:
>
> Hi Ondřej,
>
>> On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
>> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job
Hi Ondřej,
On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
>
> https://salsa.debian.org/ondrej/jenkins-job-builder.git
>
> The launchpad PPAs are still slightly better (I cant rebuild individual
> matrix
It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
https://salsa.debian.org/ondrej/jenkins-job-builder.git
The launchpad PPAs are still slightly better (I cant rebuild individual matrix
combinations from Jenkins), but only slightly. With qemu-user-static the even
the ar
Description : Really basic (dumb really) logging mostly for flashlight
Provides logging used in many getlantern components.
--
This is a dependency of the riseup VPN, see #919937.
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Herbert Parentes Fortes Neto
* Package name: static3
Version : 0.7.0
Upstream Author : Roman Mohr
* URL : https://github.com/rmohr/static3
* License : LGPL-2.1
Programming Lang: Python
Description : Really
On Mon, Dec 19, 2016 at 4:30 PM, Daniel Pocock wrote:
> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, in
Daniel Pocock writes:
> - While looking through the list, I noticed that some of them (or at
> least files with similar names) are also included within other web
> packages.
Those packages would be similarly buggy in Debian, if so.
> What is the latest opinion on when JavaScript libs can be inc
Hello Daniel,
There has been extensive discussion of this on debian-devel over the
past few months. Though it was mainly about nodejs libs, the discussion
applies to libjs-* packages too.
The outcome of the discussions:
- the advantages of packaging these libs separately outweigh the
disadvan
hey may make sense, sometimes another
environment sucks really bad and the best way for us is to deal with it.
--
bye, Joerg
Hi Daniel,
On 19-12-16 09:30, Daniel Pocock wrote:
> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into
I had a look at packaging homer-ui (ITP[1]) for HOMER[2]. It is a
powerful web application based on AngularJS for troubleshooting SIP
applications. It is particularly useful for troubleshooting many of the
SIP products we include in Debian and also for learning about SIP, SDP
and RTP.
There ar
t the
> current maintainer, Reijo Tomperi, directly? It would be better to coordinate
> with him if possible.
Yes, I tried, no answer. We tried again, and again after few months.
Also MIA team is aware of the issue, and I'm ccing Reijo directly right now
>
>
>> I really w
loaded a delayed NMU already, but that is just
ixing bug #735502, not a new version. Have you also tried to contact the
current maintainer, Reijo Tomperi, directly? It would be better to coordinate
with him if possible.
> I really would like to comaintain this package, but this is out of the s
hip
procedure as outlined on mentors.debian.net [1]; I can assure you that
there actually are DDs who track debian-mentors and RFS requests (e.g.
yours truly), and you'll get a fairly quick response from me if it
deals with a RC bug.
The diff looks fine for a NMU, so I'll go ahead and upload t
On 12/05/14 11:47, Gianfranco Costamagna wrote:
> Hi debian developers,
>
> cppcheck [1] has been removed from testing [2] because of a sourceless
> javascript file [3].
Hi, Gianfranco.
Not a DD here, but:
There are mixed opinions about cases like this. cppcheck doesn't need
jQuery to work (or
ntors?
Great tools shouldn't just disappear from debian IMAO.
I really would like to comaintain this package, but this is out of the scope of
this mail.
cheers,
Gianfranco
[1] http://packages.qa.debian.org/c/cppcheck.html
[2] http://packages.qa.debian.org/c/cppcheck/news/20140227T16391
>
>>> In some years, the patch will maybe be incompatible with the new version.
>>> The Debian project authorize that (but encourage to do not do that, but
>>> that's not suffiscient).
>>>
>>> The Debian project authorize too certain licenses which is
stic License 1.0 is very old, the Clarified and 2.0 versions are
free, both by DFSG and FSDG. And even Artistic License 1.0 is
considered free by FSDG if it's part of the disjunctive license of
Perl. Note that in dfsg text when "Artistic" license example is given,
it does really mean th
On Sun, 27 Apr 2014 14:16:31 +0200
Solal wrote:
> > I see that you don't like the DFSG. But as already has been said: We
> > are Debian and follow our own contract and not a contact of some other
> > project/company.
> > I think if you have problems with the DFSG you should propose changes
> > to
e that (but encourage to do not do that, but
>> that's not suffiscient).
>>
>> The Debian project authorize too certain licenses which is too vague for
>> talk about free (the Artistic License 1.0, for example).
>>
>> The DFSG is really bad, too laxist and
that, but
> that's not suffiscient).
>
> The Debian project authorize too certain licenses which is too vague for
> talk about free (the Artistic License 1.0, for example).
>
> The DFSG is really bad, too laxist and useless.
I see that you don't like the DFSG. But
or example).
The DFSG is really bad, too laxist and useless.
Le 26/04/2014 22:13, Dimitri John Ledkov a écrit :
> On 25 Apr 2014 15:15, "Solal" wrote:
>>
>> Why not just take the Free Software Definition[0] instead lose a lot of
>> time in specific guidelines.
&g
On 25 Apr 2014 15:15, "Solal" wrote:
>
> Why not just take the Free Software Definition[0] instead lose a lot of
> time in specific guidelines.
> I think use the Free System Distribution Guidelines published by the
> FSF[1] is the best way. Use the FSDG instead of the DFSG will :
> -Be more effici
On Fri, Apr 25, 2014 at 10:34 PM, Sven Bartscher wrote:
> nonfree [...], which we don't want to drop (as far as I know).
Some Debian members definitely wanted to drop it in 2004, not sure
about today though.
https://www.debian.org/vote/2004/vote_002
https://www.debian.org/vote/2004/gr_non_free_t
On Fri, 25 Apr 2014 15:14:49 +0200
Solal wrote:
> Why not just take the Free Software Definition[0] instead lose a lot of
> time in specific guidelines.
> I think use the Free System Distribution Guidelines published by the
> FSF[1] is the best way. Use the FSDG instead of the DFSG will :
> -Be m
Quoting Solal (2014-04-25 15:14:49)
> Why not just take the Free Software Definition[0] instead lose a lot
> of time in specific guidelines.
> I think use the Free System Distribution Guidelines published by the
> FSF[1] is the best way. Use the FSDG instead of the DFSG will :
> -Be more efficien
Why not just take the Free Software Definition[0] instead lose a lot of
time in specific guidelines.
I think use the Free System Distribution Guidelines published by the
FSF[1] is the best way. Use the FSDG instead of the DFSG will :
-Be more efficient instead of lose a lot of time in the DFSG.
-Be
cture independent. If you really need some newer -dev
version you should be able to do this with an updated build dependency.
A source upload for a library always requires a rebuild on any architecture, so
there is no buildd time savings to make the -dev package architecture
independent.
So wh
On 11/24/2013 09:52 PM, intrigeri wrote:
> Hi,
>
> FYI there's an ongoing discussion on the debian-security list
> about this.
Thanks for the pointer. Let's keep it there, rather than -devel.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscri
Hi,
FYI there's an ongoing discussion on the debian-security list
about this.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-devel-req
On Sun, 24 Nov 2013, Thomas Goirand wrote:
> I haven't checked for these facts myself due to lack of time, which is
> why I just post here. I think this paper is interesting anyway, and
> worth sharing.
I read that paper sometime ago, and as far as I recall, it mostly deals with
C code that has un
On Sun, Nov 24, 2013 at 09:21:35PM +0800, Thomas Goirand wrote:
> http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
>
> Thoughts anyone?
>
See the thread on -security starting at
<52900522.9040...@affinityvision.com.au>
Neil
--
signature.asc
Description: Digital signature
Hi,
I came across this paper:
http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
>From this PDF:
"We implement this approach in a static checker called Stack, and use it
to show that unstable code is present in a wide range of systems
software, including the Linux kernel and the Postgres data
They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the "other" graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.
Or adding something like a firewire card which happens to be based on a
PCIe to PCI bridge chip would
Hi,
On Samstag, 20. Juli 2013, Thomas Goirand wrote:
> The problem isn't that OpenRC isn't fit. The problem is that *NONE* of
> the projects are fitting *ALL* of our requirements. All of the 3
> solutions have problems.
so, there is systemd and there is upstart. what is the 3rd solution?
After
: Sass
Description : really simple media queries with Sass
Compass is a CSS authoring framework which uses the Sass stylesheet
language to make writing stylesheets powerful and easy.
.
Breakpoint makes writing media queries in Sass super simple. Create a
variable using a simplified syntax
nts. Yes, some folks will
> > choose not to contribute to it on upstream's terms, but there are still
> > plenty of others who will.
> I don't really want to go into the CLA debate (others have better
> things to share than me about it). But I think we all agree that,
&g
re still
> plenty of others who will.
I don't really want to go into the CLA debate (others have better
things to share than me about it). But I think we all agree that,
for some in Debian (I'm not talking about myself here), the Ubuntu
CLA is (at least) annoying, to the point it
On Tue, Dec 04, 2012 at 06:42:37PM +, Ian Jackson wrote:
> Barry Warsaw writes ("Re: Contributor agreements and copyright assignment
> (was Re: Really, about udev, not init sytsems)"):
> > FTR: http://www.canonical.com/contributors
> That allows Canonical to make
Ian Jackson writes:
> Barry Warsaw writes ("Re: Contributor agreements and copyright assignment
> (was Re: Really, about udev, not init sytsems)"):
>> FTR: http://www.canonical.com/contributors
>
> That allows Canonical to make proprietary forks of the code
On Dec 04, 2012, at 06:42 PM, Ian Jackson wrote:
>That allows Canonical to make proprietary forks of the code (eg, to
>engage in the dual licensing business model). This is very
>troublesome for me; it's too asymmetric a relationship.
Not to diminish your own concerns, but it doesn't bother me.
Barry Warsaw writes ("Re: Contributor agreements and copyright assignment (was
Re: Really, about udev, not init sytsems)"):
> FTR: http://www.canonical.com/contributors
That allows Canonical to make proprietary forks of the code (eg, to
engage in the dual licensing business model).
On Dec 01, 2012, at 07:21 AM, Clint Byrum wrote:
>Just any FYI, Canonical no longer requires copyright assignment in their
>CLA. You are still giving Canonical an unlimited perpetual license on the
>code, but you retain your own copyrights.
FTR: http://www.canonical.com/contributors
with embedde
> start-stop-daemon already supports waiting for processes to exit when
> stopping them. See the --retry option.
Isn't that open to race conditions, as new processes could be spawn with the
same pid in the meanwhile?
> You can't call waitpid on processes that aren't your children.
True sorry,
Salvo Tomaselli writes:
> Just opened a bug[1] about the issue, since many daemons use start-stop-
> daemon, fixing it there would solve many race conditions.
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694980
You can't call waitpid on processes that aren't your children.
start-stop
> Those are also race conditions, and bugs. If the stop and start commands
> return control before the action is completed, the results cannot be relied
> on. The 'restart' command is not the only way that an admin may
> programmatically stop and start a service; you might do this with something
gt; laptop...) are because of:
>
>> case "${1}" in
>> restart|reload|force-reload)
>> ${0} stop
>> sleep 1
>> ${0} start
>> ;;
>
>> which I don't think is (so much of) a problem in itself. Unless you
>> also cons
t; restart|reload|force-reload)
> ${0} stop
> sleep 1
> ${0} start
> ;;
> which I don't think is (so much of) a problem in itself. Unless you
> also consider the above as a race condition (which, really, could
> be a real one...).
Those are also race cond
On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> the discussion that systemd is a bad design because it uses the same
> configuration file syntax as Windows ini files or XDG .desktop files,
> adding the statement that these are too difficult to parse.
If you are referin
On Dec 1, 2012, at 0:45, Wouter Verhelst wrote:
> On Fri, Nov 30, 2012 at 09:14:20AM +0100, Tollef Fog Heen wrote:
>> Are you equating the FSF and the PSF with a private, for-profit company
>> here? That seems to be stretching it a bit.
>
> Not really, IMO.
>
> Pers
(but of course, it is much harder and error prone than an event driven
system, I'm just stating that it is really possible to write things
correctly, even with sysv)
More over, most of the sleep calls you will find in init scripts (and I
believe that is what your grep shows, because that'
On Sat, Dec 01, 2012 at 03:17:03PM +0100, Stefano Zacchiroli wrote:
> Please stop fueling these threads already (especially when the subject
> is not meaningful at all).
Hey, didn't I say several times already that I would like to leave it?
Please don't address me, I have been tired of this for se
On Sat, Dec 01, 2012 at 10:12:15PM +0800, Thomas Goirand wrote:
> On 12/01/2012 05:34 PM, John Paul Adrian Glaubitz wrote:
> > systemd is not Lennart, he is one of the many contributors.
> This statement is simply false.
Thomas, John Paul Adrian, seriously, we have had enough of these debates
on -
On Sat, Dec 01, 2012 at 10:12:15PM +0800, Thomas Goirand wrote:
> On 12/01/2012 05:34 PM, John Paul Adrian Glaubitz wrote:
> > systemd is not Lennart, he is one of the many contributors.
>
> This statement is simply false.
>
> I just checked with "git blame". Out of 381 473 lines of code in
> the
On 12/01/2012 05:34 PM, John Paul Adrian Glaubitz wrote:
> systemd is not Lennart, he is one of the many contributors.
This statement is simply false.
I just checked with "git blame". Out of 381 473 lines of code in
the Git, git blame reports 152 787 lines with "Poettering" in it.
That's more tha
On 01.12.2012 06:18, Michael Biebl wrote:
> For b/ there is already a bug report for initramfs-tools [1]. It's
> probably too late to get that into wheezy. But we should follow up there
> to get that into wheezy.
^
jessie, of course.
--
Why is it that all o
On Vi, 30 nov 12, 18:03:41, Harald Jenny wrote:
>
> Yes a dedicated list (maybe just a temporary one) especially meant for
> the early adopter/tester of systemd/upstart/OpenRC, preferrable people
> who are DDs/DMs themselves and can describe/triage problems properly...
I don't think this would be
Le samedi 01 décembre 2012 à 09:52 +0100, Wouter Verhelst a écrit :
> On Thu, Nov 29, 2012 at 03:58:05PM +0100, Josselin Mouette wrote:
> > Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit :
> > > Now if someone wants to fork the particular bits of upstream software so
> > > makin
On Sat, Dec 01, 2012 at 09:31:37AM +0100, Wouter Verhelst wrote:
> On Fri, Nov 30, 2012 at 01:00:01AM +0200, Uoti Urpala wrote:
> > Systemd does much better than its competitors as a social activity.
>
> ROTFL.
>
> I don't have much to say about the quality of Lennert's code, but his
> social ski
On Thu, Nov 29, 2012 at 08:51:47PM +0100, John Paul Adrian Glaubitz wrote:
> On Thu, Nov 29, 2012 at 03:28:40PM +0100, Wouter Verhelst wrote:
> > http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF
> >
> > the most recent processor you can find there was released in January
> > 2012
On Thu, Nov 29, 2012 at 03:58:05PM +0100, Josselin Mouette wrote:
> Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit :
> > Now if someone wants to fork the particular bits of upstream software so
> > making use of a separate /usr is still possible, even if you think it's
> > totall
On Fri, Nov 30, 2012 at 09:14:20AM +0100, Tollef Fog Heen wrote:
> Are you equating the FSF and the PSF with a private, for-profit company
> here? That seems to be stretching it a bit.
Not really, IMO.
Personally, I'm not comfortable signing off my copyright to the FSF, for
the very
On Fri, Nov 30, 2012 at 01:00:01AM +0200, Uoti Urpala wrote:
> Systemd does much better than its competitors as a social activity.
ROTFL.
I don't have much to say about the quality of Lennert's code, but his
social skills are sorely lacking.
--
Copyshops should do vouchers. So that next time so
On 30.11.2012 03:39, Steve Langasek wrote:
> that's fine; I've been convinced myself that it's not reasonable to have a
> system with /usr on a separate partition and expect that to work without an
> initramfs, and think we *should* simplify our overall architecture rather
> than continuing to put
ll be installed in /usr and not work
> >properly. Example configuration options to install things the
> >traditional way are in INSTALL."
> >
> > Just stating the facts. I see no reason to discuss these issues any
> > further.
> «default location» vs «architec
On Thu, Nov 29, 2012 at 10:32:46PM +0100, Bernhard R. Link wrote:
> > > Claiming that it will work for everyone and that
> > > anyone not being able to name a problem existing now has no arguments
> > > does not help.
> > Do System V Init or Upstart work in EVERY single use case?
> Actually, all
> I do not agree that reconfiguring your machine to avoid an initrd is a
> normal standard desktop configuration. There's also several other things
> about your setup which I would argue are not standard (see below)
Well no but are you trying to argue that my problems are due to my kernel
configu
On 30.11.2012 18:43, Thomas Goirand wrote:
On 11/30/2012 11:57 PM, John Paul Adrian Glaubitz wrote:
I never meant to start any redundant discussion about which init
system
is best. And, as Russ already pointed out, we're not going to make
that decision this time. So please, just leave it for no
On Fri, Nov 30, 2012 at 07:23:12PM +0100, Bernhard R. Link wrote:
> * Jon Dowland [121130 16:06]:
> > I do not agree that reconfiguring your machine to avoid an initrd is a
> > normal
> > standard desktop configuration. There's also several other things about your
> > setup which I would argue ar
On Fri, Nov 30, 2012 at 07:23:12PM +0100, Bernhard R. Link wrote:
> * Jon Dowland [121130 16:06]:
> > I do not agree that reconfiguring your machine to avoid an initrd is a
> > normal
> > standard desktop configuration. There's also several other things about your
> > setup which I would argue ar
On 11/30/2012 11:57 PM, John Paul Adrian Glaubitz wrote:
> Sorry, but if I remember correctly, it was you who came here to
> discuss Gentoo-related problems on a Debian development list and who
> admitted that he enjoyed starting flame wars because you were bored.
>
> Honestly, you should remember
* Jon Dowland [121130 16:06]:
> I do not agree that reconfiguring your machine to avoid an initrd is a normal
> standard desktop configuration. There's also several other things about your
> setup which I would argue are not standard (see below)
Will Debian come by default with initrds on all rel
Hi Andrei
On Fri, Nov 30, 2012 at 06:57:28PM +0200, Andrei POPESCU wrote:
> On Vi, 30 nov 12, 17:47:20, Harald Jenny wrote:
> >
> > Maybe some sort of mailing list could be dedicated to a discussion about
> > the actual usage of different init system so people may share their
> > experiences?
>
On Vi, 30 nov 12, 17:47:20, Harald Jenny wrote:
>
> Maybe some sort of mailing list could be dedicated to a discussion about
> the actual usage of different init system so people may share their
> experiences?
Do you mean some list other than debian-user?
Kind regards,
Andrei
--
Offtopic discus
Hi again :-)
On Thu, Nov 29, 2012 at 04:35:17PM -0800, Russ Allbery wrote:
>
> I really think this is a case where personal experience is going to speak
> louder than any possible argument, which is why I think the next step is
> to make it simple and documented to switch init sys
emd as their init
> process in Debian.
>
First thanks for your post.
While I really enjoy reading debian-devel I'm really kinda irritated by
the way in which people seem to drive this to an epic war in the form of
StarWars/LOTR/WOW... (you name it). From all the mails I've read most o
On Thu, Nov 29, 2012 at 06:12:14PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Harald,
Hi Adrian
>
> On Thu, Nov 29, 2012 at 04:58:35PM +0100, Harald Jenny wrote:
> > I have tried systemd but as it does not support the Debian extensions to
> > cryptsetup (namely the crypttab keyscript parameter
On 11/30/2012 09:10 AM, Uoti Urpala wrote:
> This thread was started by an "anti-systemd" poster
Since I started this thread, I guess you're talking about me.
I do not accept that you categorize me this way.
*No*, I'm not an "anti-systemd" guy. I believe that systemd
is nice, that it has very coo
On Fri, Nov 30, 2012 at 11:51:24PM +0800, Thomas Goirand wrote:
> On 11/30/2012 07:49 AM, John Paul Adrian Glaubitz wrote:
> > And for me, the most annoying thing is the neverending circlejerk of
> > systemd bashing on a non-technical basis. If anyone of these people
> > would
On 11/30/2012 07:49 AM, John Paul Adrian Glaubitz wrote:
> And for me, the most annoying thing is the neverending circlejerk of
> systemd bashing on a non-technical basis. If anyone of these people
> would really take the time to read into the design rationales
So, basically, anyone w
On Nov 30, 2012, at 09:14 AM, Tollef Fog Heen wrote:
>There's a significant difference whether your contractual counterpart is
>somebody who has the public good or profits in the pockets of its owners
>in mind.
In the abstract, the non-profit or for-profit status of an organization is
little indi
On Fri, Nov 30, 2012 at 12:19:22PM +0100, Salvo Tomaselli wrote:
> I am using systemd on my laptop, i have a very default system configuration,
> (except that i compile my own kernel to avoid initrd)…
^^
> …if I, with a normal, standard desktop co
> I can't say anything about the fetchmail problem, but I just tried to
> reproduce the problem you explained in #693522 and it works on my
> installation.
>
> So we will probably need more input to debug this.
Please post on the bug what kind of test you want me to do.
I was just pointing out h
On Fri, Nov 30, 2012 at 12:19:22PM +0100, Salvo Tomaselli wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693522
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694048
I can't say anything about the fetchmail problem, but I just tried to
reproduce the problem you explained in #693522
> Again, I am constantly asking here what these reasons might be and yet
> people always come with strawman arguments.
You should bother to read the answers to your question then :-)
I am using systemd on my laptop, i have a very default system configuration,
(except that i compile my own kern
]] Barry Warsaw
> On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote:
>
> >Plus, you have to sign a contributor's agreement with Canonical which leaves
> >a bad taste in my mouth. That shouldn't be the case with true free software,
> >should it?
>
> In an ideal world maybe it shouldn
1 - 100 of 423 matches
Mail list logo
