On Tue, 13 May 2014 12:13:21 +1200, Chris Bannister wrote:
> On Tue, May 13, 2014 at 12:56:34AM +0200, Lubomir Rintel wrote:
> > * Package name: libdatabase-dumptruck
> > Version : 1.2
> > Upstream Author : Lubomir Rintel
> > * URL : https://metacpan.org/release/Datab
Hi!
On Mon, 2014-05-12 at 22:50:39 -0700, Noah Meyerhans wrote:
> There are two reasons I use su in /etc/cron.daily/spamassassin. One is
> to change uid/gid, and the other is to reset the shell environment to a
> base state. The need for this was highlighted in bug 738951. I doubt
> that this is a
On 13 May 2014 16:15, Cameron Norman wrote:
> It looks like it already does this. I assume the user running the command
> manually would not hurt anything, correct?
>
I think the user running the command manually would have the same problems.
Especially as it is a daemon.
Is this is something D
El Mon, 12 de May 2014 a las 10:53 PM, Brian May
escribió:
On 13 May 2014 15:44, Cameron Norman wrote:
I found another use of su that may need to be added to your list.
rabbitmq (oddly) wraps itself up in a shell script,
/usr/sbin/rabbitmq-server, which asserts the user is root or
rabbitmq,
On Mon, May 12, 2014 at 07:01:14PM -0700, Russ Allbery wrote:
> Dependency-based boot, the change to /bin/sh, and UUID-based mounting were
> all not drop-in replacements by that criteria.
Note that also none of them were forced on existing installations. The change
of /bin/sh to dash (which is wh
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
>What about the task of running a short program for a brief duration, e.g.
>from cron scripts? Is using su considered acceptable?
>e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su.
There are two reason
Le 13 mai 2014 03:01, "Michael Biebl" a écrit :
>
> Am 13.05.2014 02:54, schrieb Russ Allbery:
> > Steve Langasek writes:
> >
> >> AFAIK, d-i disabling of s-s-d is a historical workaround for packages
> >> not using invoke-rc.d (back in the days before it was a Policy "must").
> >> Maybe it's tim
On 13 May 2014 15:44, Cameron Norman wrote:
> I found another use of su that may need to be added to your list. rabbitmq
> (oddly) wraps itself up in a shell script, /usr/sbin/rabbitmq-server, which
> asserts the user is root or rabbitmq, and drops down to rabbitmq if it is
> root (using su), the
El Mon, 12 de May 2014 a las 6:01 PM, Michael Biebl
escribió:
Am 13.05.2014 02:54, schrieb Russ Allbery:
Steve Langasek writes:
AFAIK, d-i disabling of s-s-d is a historical workaround for
packages
not using invoke-rc.d (back in the days before it was a Policy
"must").
Maybe it's time
Hi Gianfranco,
On Mon, May 12, 2014 at 11:47 AM, Gianfranco Costamagna
wrote:
> Hi debian developers,
>
> cppcheck [1] has been removed from testing [2] because of a sourceless
> javascript file [3].
[...]
> So, please, can anybody sponsor this package and upload or just reject it
> from mentor
On 13 May 2014 12:47, Norbert Preining wrote:
> Yes, that is true, because at that time it was about booting with
> init=/bin/systemd
> and *not* about automatic upgrade to systemd without any checking back.
>
No, the title of the bug was changed to "systemd drops into emergency mode
if
> > If a device is not available but listed without "noauto" or "nofail"
> > in /etc/fstab, systemd drops into emergency mode.
> >
>
> Maybe I am mistaken, however I thought this was standard behaviour for SYSV
> boot systems too
No, it is not standard behaviour. It warns you, but continues b
On Mon, 12 May 2014, Russ Allbery wrote:
> In this case, maybe we can add some transitional smarts to the same
> package that takes responsibility for upgrade prompting. What comes to
> mind is scanning /etc/fstab and look for filesystems that aren't set
> noauto or nofail but that aren't mounted
On Tue, May 13, 2014 at 03:01:10AM +0200, Michael Biebl wrote:
> Am 13.05.2014 02:54, schrieb Russ Allbery:
> > Steve Langasek writes:
> >> AFAIK, d-i disabling of s-s-d is a historical workaround for packages
> >> not using invoke-rc.d (back in the days before it was a Policy "must").
> >> Maybe
Norbert Preining writes:
> This can happen on *any* server that has been booting happily since many
> many years. Thus, systemd is *not* a drop-in replacement for now.
We should be realistic about this: it's not going to be, either, at least
for a definition of drop-in replacement that involves
On 13 May 2014 11:11, Norbert Preining wrote:
> #743265: systemd: booting with init=/bin/systemd drops into emergency mode
>
> If a device is not available but listed without "noauto" or "nofail"
> in /etc/fstab, systemd drops into emergency mode.
>
Maybe I am mistaken, however I thought this wa
On Mon, 12 May 2014, Steve Langasek wrote:
> Bug #746587 is a prime example. But more generally, I'm looking for
> evidence that we're being systematic about making sure the packages that
> hook into early boot, either via /etc/rcS.d or /etc/network/if-up.d, will
> still work correctly after the t
Am 12.05.2014 05:09, schrieb Russ Allbery:
> Bas Wijnen writes:
>
>> If the order of the dependencies of libpam-systemd is switched, so it
>> becomes systemd-shim | systemd-sysv, the result will be:
>
>> - If systemd is not installed, systemd-shim will be installed and the
>> original init sys
Am 13.05.2014 02:54, schrieb Russ Allbery:
> Steve Langasek writes:
>
>> AFAIK, d-i disabling of s-s-d is a historical workaround for packages
>> not using invoke-rc.d (back in the days before it was a Policy "must").
>> Maybe it's time to drop this diversion of s-s-d?
>
> Yeah, that's just what
Steve Langasek writes:
> AFAIK, d-i disabling of s-s-d is a historical workaround for packages
> not using invoke-rc.d (back in the days before it was a Policy "must").
> Maybe it's time to drop this diversion of s-s-d?
Yeah, that's just what I was thinking. Any software that doesn't honor an
i
On Fri, May 09, 2014 at 08:30:22PM +0200, Michael Biebl wrote:
> Am 09.05.2014 19:56, schrieb Steve Langasek:
> > I don't think systemd integration is in a state today that this is ready to
> > become the default.
> What are you missing?
Bug #746587 is a prime example. But more generally, I'm l
On Mon, May 12, 2014 at 04:21:56PM -0700, Josh Triplett wrote:
> > > Consider a system which has systemd installed, systemd-sysv *not*
> > > installed, and systemd used as PID 1 via init=/bin/systemd. Since
> > > systemd-sysv is not already installed, "systemd-shim | systemd-sysv" will
> > > pull
On Tue, May 13, 2014 at 01:21:08AM +0100, Colin Watson wrote:
> On Sat, May 10, 2014 at 11:11:10PM -0700, Steve Langasek wrote:
> > On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
> > > The name "start-stop-daemon" would suggest this is inappropriate for cron
> > > jobs, is that an inval
On Sat, May 10, 2014 at 11:11:10PM -0700, Steve Langasek wrote:
> On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
> > The name "start-stop-daemon" would suggest this is inappropriate for cron
> > jobs, is that an invalid assumption I made?
>
> Perhaps a better name could have been chose
On Tue, May 13, 2014 at 12:56:34AM +0200, Lubomir Rintel wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian Perl Group
>
> * Package name: libdatabase-dumptruck
> Version : 1.2
> Upstream Author : Lubomir Rintel
> * URL : https://metacpan.org/release/Database
Steve Langasek wrote:
> On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > > I don't think I understand what you mean. What does "having systemd
> > > installed" mean, if not that it's being used as the init system? And if
> > > it isn't used as the init system (presumably because
Thorsten Glaser wrote:
> On Sun, 11 May 2014, Marc Haber wrote:
[...]
> On Sun, 11 May 2014, Cyril Brulebois wrote:
>
> > Marc Haber (2014-05-11):
> > > Just curious as the maintainer of another package using su in an
> > > init script since 2001, how am I supposed to start a non-root
> > > proce
Charles Plessy writes:
> Le Mon, May 12, 2014 at 12:16:48PM +0200, Andrew Shadura a écrit :
>> On 12 May 2014 11:54, Josselin Mouette wrote:
>>> Systemd is the default init system for jessie, and it should be listed
>>> as the first alternative. The fact that an alternative codepath exists
>>> f
El Mon, 12 de May 2014 a las 3:48 PM, Charles Plessy
escribió:
Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
There *is* a reason we should push our users away from the
non-default
init: we want to make sure that only the users who specifically
*want* a
non-default init
Package: wnpp
Severity: wishlist
Owner: Debian Perl Group
* Package name: libdatabase-dumptruck
Version : 1.2
Upstream Author : Lubomir Rintel
* URL : https://metacpan.org/release/Database-DumpTruck
* License : Artistic or GPL-1+
Programming Lang: Perl
Des
Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
>
> There *is* a reason we should push our users away from the non-default
> init: we want to make sure that only the users who specifically *want* a
> non-default init run one, and those are exactly the users prepared to
> deal wit
On Mon, 2014-05-12 at 21:16 +0200, Bas Wijnen wrote:
>
> > It's easy enough for any user who *does* care to select a different set of
> > installed packages.
>
> It's not so much about caring which init system to use. It's about being in
> control over your own computer. There are many package
Package: wnpp
Severity: wishlist
Owner: Sergio Schvezov
* Package name: golang-uuid
Version : 0.0~hg20140512-1
Upstream Author : Paul Borman
* URL : https://code.google.com/p/go-uuid/
* License : BSD-3-Clause
Programming Lang: Go
Description : Go bindi
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
On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > In other words: what isn't handled properly? What should happen, and what
> > does
> > happen?
>
> Consider a system which has systemd installed, systemd-sysv *not* installed,
> and systemd used as PID 1 via init=/bin/systemd. S
On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > I don't think I understand what you mean. What does "having systemd
> > installed" mean, if not that it's being used as the init system? And if
> > it isn't used as the init system (presumably because the user chose no
> > to do t
Hi debian developers,
cppcheck [1] has been removed from testing [2] because of a sourceless
javascript file [3].
Because of this I packaged (with patch and thanks from Octavio) a new dfsg
version and uploaded on mentors [4] some time ago.
(I'm uploading it again right now since I forgot to put
On Mon, May 12, 2014 at 11:54:43AM +0200, Josselin Mouette wrote:
> Le vendredi 09 mai 2014 à 21:13 +0200, Bas Wijnen a écrit :
> > I think it would be good for libpam-systemd to list systemd-shim first.
> Certainly not.
> Systemd is the default init system for jessie, and it should be listed
>
Bas Wijnen wrote:
> On Mon, May 12, 2014 at 09:19:40AM -0700, Josh Triplett wrote:
> > Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not
> > properly
> > handle systems that already have systemd installed but not systemd-sysv.
>
> I don't think I understand what you mean. Wh
Quoting James Cloos (2014-05-12 17:48:53)
> > "JS" == Jonas Smedegaard writes:
>
> JS> I believe it does not violate DFSG to ship e.g. JFIF or GIF files
> JS> which was upstream distributed with copyright-protected but not
> JS> freely licensed ICC profiles, if repackaged to strip those ICC
>
At Sun, 11 May 2014 19:04:07 -0400,
David Prévot wrote:
> Q. Are profiles copyrighted?
>
> A. ICC has no formal position on the use of profiles. It is really up to
> the software vendor. However, since the software vendor effectively
> holds copyright on the profile (which is specified in a tag) t
On 2014-05-12 18:19 +0200, Josh Triplett wrote:
> Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not
> properly
> handle systems that already have systemd installed but not systemd-sysv.
Could you please elaborate what exactly does not work properly in such a
situation? I ha
On May 12, 2014, at 05:46 PM, Thijs Kinkhorst wrote:
>Mailman 3 is completely different from Mailman 3 and I see no synergy in
>basing anything on the existing package. As of now, to my knowledge no
>migration or upgrade scenarios exist from MM 2 to MM 3, and I'm not sure
>if such code will be the
On Mon, May 12, 2014 at 09:19:40AM -0700, Josh Triplett wrote:
> Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not
> properly
> handle systems that already have systemd installed but not systemd-sysv.
I don't think I understand what you mean. What does "having systemd instal
Le 12 mai 2014 17:51, "James Cloos" a écrit :
>
> > "JS" == Jonas Smedegaard writes:
>
> JS> I believe it does not violate DFSG to ship e.g. JFIF or GIF files
> JS> which was upstream distributed with copyright-protected but not
> JS> freely licensed ICC profiles, if repackaged to strip those
Bas Wijnen wrote:
> On my system, I see systemd-sysv being pulled in by libpam-systemd, which is
> required by network-manager and policykit-1.
>
> libpam-systemd will accept systemd-shim instead of systemd-sysv as well, but
> it's listed later, so the user has to manually select it if they want t
> "JS" == Jonas Smedegaard writes:
JS> I believe it does not violate DFSG to ship e.g. JFIF or GIF files
JS> which was upstream distributed with copyright-protected but not
JS> freely licensed ICC profiles, if repackaged to strip those ICC
JS> profiles.
Note that you cannot just strip colour
On Mon, May 12, 2014 17:00, Clint Adams wrote:
> On Mon, May 12, 2014 at 10:02:35AM -0400, Barry Warsaw wrote:
>> I don't have time to work on Alioth, but JFTR, we (the GNU Mailman
>> development team) recently announced the first full-suite beta release
>> for Mailman 3. It's possible that even wi
On Thu, May 08, 2014 at 11:45:24AM +0200, Thorsten Glaser wrote:
> This is a bug in doxygen. Replacing the embedded jquery copy
> in the Debian package shipping it with a link to the jquery
> version in Debian should be the right thing to do. Maybe this
Your criticism is unconstructive. I agree th
On Mon, May 12, 2014 at 10:50:34AM +0200, Josselin Mouette wrote:
> Le dimanche 11 mai 2014 à 15:53 +0200, Marc Haber a écrit :
> > On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
> > wrote:
> > >For other distributions (and other Unix based OS) most of (all?) the
> > >initscripts are alre
On Mon, May 12, 2014 at 10:02:35AM -0400, Barry Warsaw wrote:
> I don't have time to work on Alioth, but JFTR, we (the GNU Mailman development
> team) recently announced the first full-suite beta release for Mailman 3.
> It's possible that even with the usual beta-quality issues, that MM3 would
> m
On 2014-05-12, Bas Wijnen wrote:
> A default is only relevant at the time the functionality is first installed.
> After that, whatever was installed should stay until the user requests to
> change it (or there is a technical reason that it can no longer be installed).
> In the case of an init syst
On Mon, May 12, 2014 at 11:54:43AM +0200, Josselin Mouette wrote:
> Systemd is the default init system for jessie, and it should be listed
> as the first alternative.
Can you please explain what is wrong with my reasoning?
A default is only relevant at the time the functionality is first installe
On 12 May 2014 14:56, Ben Hutchings wrote:
>>
>> I think the following points may be interesting:
>> * in which state/shape is the nftables framework?
>> * what about the iptables and the compat layer? The next upstream
>> release of iptables will, by default, use the nf_tables kernel
>> subsyst
On May 12, 2014, at 07:57 AM, Charles Plessy wrote:
>For mailing lists, I read in the thread that it may not be a problem anyway,
>but I just wanted to add one thing: in many cases the lists to be created are
>a maintainer list and a commit list, and this could be replaced completely by
>the “new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/12/2014 08:52 AM, Norbert Preining wrote:
>> [..] configurations nobody will actually ever use.
>
> There you are plainly *wrong*... unless you on purpose make it to not
> work so that nobody can use it ... which I don't hope!!!
Not to menti
> [..] configurations nobody will actually ever use.
There you are plainly *wrong*... unless you on purpose make it
to not work so that nobody can use it ... which I don't hope!!!
Norbert
PREINING, Norbert
On Fri, 2014-05-09 at 09:18 +0200, Arturo Borrero Gonzalez wrote:
> On 8 May 2014 19:16, Frank Bauer wrote:
> > Hi,
> >
> > Jessie currently contains linux 3.13, which includes the successor of
> > iptables - nftables.
> > Unfortunately, the userspace tools (nftables) are still missing even in
> >
> ___
>
> "There are two ways of constructing a software design. One is to make
> it so simple that there are OBVIOUSLY no deficiencies. And the other is
> to make it so complicated that there are no OBVIOUS deficiencies"
>
>
Le lundi 12 mai 2014 à 12:16 +0200, Andrew Shadura a écrit :
> > As far as GDM is concerned, any bug reported with systemd-shim installed
> > will be ignored. The bug script should probably be updated to that
> > effect, BTW.
>
> This sort of behaviour is precisely why so many people not only
> d
Le lundi 12 mai 2014 à 13:26 +0200, Thorsten Glaser a écrit :
> What *is* a “desktop seat manager”? I’d not want it on servers
> (and some coworkers are even running N-M on some of them…), and
> Linux desktops (and nōn-Linux ones) have not needed those until
> now either. So, I (still) question th
Hello,
On 12 May 2014 13:35, Tollef Fog Heen wrote:
>> This sort of behaviour is precisely why so many people not only
>> dislike systemd, but also it's maintainers.
> Are you aware that Joss isn't a systemd maintainer? (He's one of the
> GNOME maintainers.)
I am. I never claimed he is.
--
C
On Sat, 10 May 2014, Bas Wijnen wrote:
> > So please get dirmngr fixed instead of blaming systemd/logind.
>
> This is the part you should _NEVER_ do. It is YOUR responsibitiliy, as a
> maintainer (you are the maintainer, right?), to make sure that a bug that is
> reported in the wrong place gets
]] Andrew Shadura
> Hello,
>
> On 12 May 2014 11:54, Josselin Mouette wrote:
> > Systemd is the default init system for jessie, and it should be listed
> > as the first alternative. The fact that an alternative codepath exists
> > for users with specific needs is nice for them, but it is not wh
At Mon, 12 May 2014 12:16:48 +0200,
Andrew Shadura wrote:
>
> On 12 May 2014 11:54, Josselin Mouette wrote:
> > Systemd is the default init system for jessie, and it should be listed
> > as the first alternative. The fact that an alternative codepath exists
> > for users with specific needs is ni
On Fri, 9 May 2014, Steve Langasek wrote:
> > > >> ii systemd 204-10
> > > >> ii systemd-sysv 204-10
>
> > You can purge them. Install sysvinit-core at the same time.
>
> This is unconstructive advice.
No, it is not, for someone who wants s
On Mon, 12 May 2014 12:00:48 +0200
A debian dev wrote:
> Nobody cares.
>
> Please go away.
You apparently don't care that an official debian document is making
sweeping incorrect statements even though I have told you I have
professional experience in this area and pointed debian to a buildroot
Hi Carlos and Marc,
At Mon, 12 May 2014 04:21:10 +0200,
Carlos Alberto Lopez Perez wrote:
>
> On 11/05/14 09:18, Marc Haber wrote:
> > Something along the lines of systemd is technically needed and a good
> > idea, but the people behind it do not come along nice.
> >
>
> Completely agree.
Whil
On Sun, 11 May 2014, Marc Haber wrote:
> On Sat, 10 May 2014 22:13:01 +0200, Matthias Urlichs
> wrote:
> >I also would not expect an "end user" to add "su foo -c /do/whatever" to
> >/etc/rc.local. Your opinion may differ, that's OK.
>
> Especially people who are not as Debian-centric as we are t
(Context: a thread about OpenSSL's custom malloc wrapper on a non-public
mailing list; I'm only quoting bits that are explicitly non-private,
which is why this mail might seem rather disjointed)
Steinar H. Gunderson wrote:
>> No malloc() sends a syscall for every malloc()/free(), except for
>> big
Le Mon, May 12, 2014 at 12:16:48PM +0200, Andrew Shadura a écrit :
>
> On 12 May 2014 11:54, Josselin Mouette wrote:
> > Systemd is the default init system for jessie, and it should be listed
> > as the first alternative. The fact that an alternative codepath exists
> > for users with specific ne
Hello,
On 12 May 2014 11:54, Josselin Mouette wrote:
> Systemd is the default init system for jessie, and it should be listed
> as the first alternative. The fact that an alternative codepath exists
> for users with specific needs is nice for them, but it is not what we
> should focus our efforts
Le vendredi 09 mai 2014 à 21:13 +0200, Bas Wijnen a écrit :
> I think it would be good for libpam-systemd to list systemd-shim first.
Certainly not.
Systemd is the default init system for jessie, and it should be listed
as the first alternative. The fact that an alternative codepath exists
for u
Le dimanche 11 mai 2014 à 15:53 +0200, Marc Haber a écrit :
> On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
> wrote:
> >For other distributions (and other Unix based OS) most of (all?) the
> >initscripts are already different anyway.
>
> Is it right to force that?
No, this is why we ar
On Sun, May 11 2014, Marco d'Itri wrote:
> I do this for the inn2 package and it has worked well for years.
> Another (much simpler) example is kmod, which build a deb and a udeb.
> If ./configure is not buggy and works when called from a build directory
> then building two binary packages from t
Le 11 mai 2014 23:06, "Michael Biebl" a écrit :
>
> Am 11.05.2014 19:37, schrieb Helmut Grohne:
>
> > I trust you to be technically right on this. Still the number of
> > packages getting this wrong is stunning[1]. Therefore I'd argue that
>
> > [1]
http://codesearch.debian.net/search?q=su+-c+path
76 matches
Mail list logo
