On Thu, 2014-10-02 at 12:57 +0300, Dionysis Grigoropoulos wrote:
On Wed, Oct 01, 2014 at 10:33:07PM +0200, Matthias Runge wrote:
On Wed, Oct 01, 2014 at 01:28:04PM +0300, Dionysis Grigoropoulos wrote:
Hello,
as far as I can see, EPEL 7 currently provides packages `python-django`
The following Fedora EPEL 7 Security updates need testing:
Age URL
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2657/python-oauth2-1.5.211-7.el7
8
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2748/nodejs-0.10.32-1.el7,v8-3.14.5.10-14.el7
7
Hi,
On Thu, Oct 2, 2014 at 8:49 AM, Chris Adams li...@cmadams.net wrote:
Once upon a time, Rahul Sundaram methe...@gmail.com said:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
One thing that might be a good topic for consideration: is there a
reasonable way to allow different implementations to take the /bin/sh
symlink? Could this be handled through the alternatives system, so that
admins could choose
On 10/02/2014 08:33 AM, Lennart Poettering wrote:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows.
The login shell is a per-user configurable setting, thus the memory
On 10/02/2014 08:42 AM, Lennart Poettering wrote:
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
One thing that might be a good topic for consideration: is there a
reasonable way to allow different implementations to take the /bin/sh
symlink? Could this be handled through the
On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
On 2.10.2014 00:03, Dennis Gilmore wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 01 Oct 2014 09:56:32 +0200
Václav Pavlín vpav...@redhat.com wrote:
Hi,
Dennis, could you please build Alpha base image with updated bash?
(And probably also prepare F20 and Rawhide images so that
On 2 October 2014 07:33, Lennart Poettering mzerq...@0pointer.de wrote:
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/)
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android
On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
/bin/sh isn't supposed to stay in memory. It's for one-off scripts,
not for interactive use.
It will stay in memory around command invocations, and the executable
code and mapped data will remain in the page cache (hopefully).
Allegedly, dash
Hi
On Thu, Oct 2, 2014 at 4:04 AM, Richard W.M. Jones wrote:
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
For Ubuntu the stated reason to follow Debian was pretty bogus[1] --
Ubuntu didn't follow Debian here. It was the other way around.
It doesn't even avoid Debian
hello
Don't we consider using zsh?
Balint
On Thu, 2014-10-02 at 10:04 +0200, Florian Weimer wrote:
On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
/bin/sh isn't supposed to stay in memory. It's for one-off scripts,
not for interactive use.
It will stay in memory around command
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non
On 2014-10-02 10:25, Rahul Sundaram wrote:
It doesn't even avoid Debian Ubuntu having a security problem, since
they still need to fix bash.
Sure. Unless they stop shipping bash, they got to fix security problems.
That is no surprise. The real question is whether it reduced the impact of
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.
I don't know about the current situation, but e.g., the configure
scripts I just
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
On 1 October 2014 17:15, Tim Lauridsen tim.laurid...@gmail.com wrote:
Is it only me, that is thinking, that all there rules to make things looks
prettier in Gnome Software or you package will get excluded if you dont
live up to the rules
It's probably not just you.
is a little hostile for
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.
hm... Interesting, I
On 10/02/2014 11:04 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
It used to give significant boost for automake libtool based software
- however at some point
Compose started at Thu Oct 2 07:15:02 UTC 2014
Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) =
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires
On 10/02/2014 11:25 AM, Balint Szigeti wrote:
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and
Compose started at Thu Oct 2 05:15:04 UTC 2014
Broken deps for i386
--
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
Am 02.10.2014 um 09:14 schrieb Tomasz Torcz:
On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
since you have two packages to look after (Yes, by adding dash to the
default stack you just put the extra burden on Fedora to quickly
update two packages instead of just one in
On Thu, 2014-10-02 at 12:07 +0200, Ralf Corsepius wrote:
On 10/02/2014 11:25 AM, Balint Szigeti wrote:
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history,
On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
concern for their data or a corporate policy mandating full-disk
Rex Dieter wrote:
Till Maas wrote:
Hi,
On Sun, Sep 28, 2014 at 12:14:24PM +0200, Kalev Lember wrote:
It's now retired in both F21 and master. Feel free to go ahead with the
libinfinity builds.
thank you.
Rex, I prepared a new build for libqinfinity in the master branch, if
you
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
The shell is API.
Yep, and that API is the POSIX shell language, an extended version of
the Bourne shell. It is a Linux curiousity that came along to use bash
as /bin/sh.
Currently, if people write shell (#!/bin/sh) scripts
on
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows.
systemd (as PID 1, not counting additional required processes)
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything that depends on bash as /bin/sh is already getting Fedora
specific. Debian/Ubuntu don't use bash as /bin/sh for years, and none
of the other major
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).
I understand this is a rherotical argument but the symlink exists because
it is
On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything that depends on bash as /bin/sh is already getting Fedora
specific.
On 10/1/2014 22:39, Rahul Sundaram wrote:
Since the recent Shellshock aka Bashdoor vulnerability, there have
been some discussions about more distributions switching over...
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to
On 09/29/2014 09:57 PM, Bastien Nocera wrote:
Given that to generate them we would just crop the existing wallpapers, I'm not
sure what the point is.
The point is to ask photographers to take some photos in portrait orientation.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software
On Thu, 02.10.14 14:12, Daniel P. Berrange (berra...@redhat.com) wrote:
On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Anything
Hi
On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to abandon it altogether?
That is a mischaracterization. Bash will remain the interactive shell.
This discussion is limited
On 09/24/2014 06:16 PM, Stephen Gallagher wrote:
* Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.
Can you please explain to me, what is the difference between non-productized
Fedora and productized Fedora?
Do I
On Thu, 2014-10-02 at 15:33 +0200, Miroslav Suchý wrote:
On 09/24/2014 06:16 PM, Stephen Gallagher wrote:
* Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.
Can you please explain to me, what is the
On Thu, Oct 02, 2014 at 08:05:09AM -0500, Chris Adams wrote:
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage
On Thu, Oct 2, 2014 at 9:27 AM, Rahul Sundaram methe...@gmail.com wrote:
Hi
On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to abandon it altogether?
That is a
On 10/2/2014 09:27, Rahul Sundaram wrote:
That is a mischaracterization. Bash will remain the interactive
shell. This discussion is limited to switching the system shell
(/bin/sh) from Bash to potentially Dash.
While I appreciate your technical correction on the scope of this
proposed
Hi
On Thu, Oct 2, 2014 at 9:42 AM, Josh Boyer wrote:
But the prompt for doing so is a security incident that has already
been fixed. If this was really a worthwhile endeavour, why hasn't it
come up before?
Our needs continue to evolve. We didn't consider size as much before but
there is a
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell in
Fedora?
Why starting with changing target of /bin/sh?
Can we start with smaller step?
Like put in Packing Guidelines, that authors and maintainers of non-interactive
Once upon a time, Miroslav Suchý msu...@redhat.com said:
Like put in Packing Guidelines, that authors and maintainers of
non-interactive shell scripts should use
#!/usr/bin/dash
rather then
#!/bin/sh or
#!/usr/bin/bash
No, /bin/sh is the standard-defined definitive place for the
Hi
On Thu, Oct 2, 2014 at 9:49 AM, Tom Rivers wrote:
While I appreciate your technical correction on the scope of this proposed
switch, you conveniently failed to address the core argument I made which
is by far the larger issue: the impetus...
I didn't address it because it was not
Hi
On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý wrote:
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora?
Why starting with changing target of /bin/sh?
Can we start with smaller step?
Like put in Packing
On Thu, Oct 2, 2014 at 11:17 AM, Richard Hughes hughsi...@gmail.com wrote:
Designing an application for the lowest common denominator does not
give you a high-quality cohesive application that's easy to use and
nice on the eye. It gives you a miss-mash of ugly noise that's hard to
use. I
On Thu, Oct 02, 2014 at 03:21:33PM +0200, Lennart Poettering wrote:
I am more concerned about code written by admins and users. I kinda
hope that we don't ship too massive shell programs in Fedora, (well,
except of course autoconf scripts...), but I am pretty sure that shell
is one of the most
On 2 October 2014 15:17, Tim Lauridsen tim.laurid...@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager,
because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist
applications:
A file has been added to the lookaside cache for perl-Array-Unique:
e3fc4333a97c360348b8c7d0b6b94e83 Array-Unique-0.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
On 10/02/2014 03:07 PM, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Just look for brace expansion in spec files. It's use is *extremely*
common. And many of the failures are
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.laurid...@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager,
because they don't live up to some visual quality guidelines.
There's actually a whole load of
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very
relevant. The reasons for undertaking a project of this magnitude
should be
On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.laurid...@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager,
because they don't live up to
Am 02.10.2014 um 16:50 schrieb Pierre-Yves Chibon:
On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.laurid...@gmail.com wrote:
I think that is a bad idea to exclude applications from a
Hi all,
I have a proposal that would change how dependencies are defined in copr:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using
this dependent repo link we are able to build packages in coprA
On 2 October 2014 15:47, Reindl Harald h.rei...@thelounge.net wrote:
to make some distribution clown happy
If you read the link, if you ship an AppData file the 5 year rule
doesn't kick in. That's something useful that the packager *can* do to
the otherwise perfect desktop application.
Richard
https://bugzilla.redhat.com/show_bug.cgi?id=1139043
--- Comment #8 from Fedora Update System upda...@fedoraproject.org ---
perl-Array-Unique-0.08-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-Array-Unique-0.08-2.fc19
--
You are receiving
Hi
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very relevant.
Sure but the
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
Thanks for bringing up the discussion. Just as we shouldn't change things
for no reason, we
Hi
On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald wrote:
you misunderstood me
I don't think anyone misunderstood that you have trouble disagreeing
without also being insulting. You are pushing off people who might
otherwise be sympathetic to your perspective by constantly engaging in a
Hello,
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus
is
merely the backstory.
On the contrary, the rationale for your proposed change is very
Am 02.10.2014 um 17:34 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald wrote:
you misunderstood me
I don't think anyone misunderstood that you have trouble
disagreeing without also being insulting
my god i brought an cynical example what upstream may write
in
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able
Hi
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
OK, then; care to explicitly list the advantages you expect to see from
such a switch, and why they outweigh the disadvantages and the migration
costs?
I don't have a predrawn conclusion that I am advocating strongly for here
but I
On Thu, Oct 02, 2014 at 05:48:20PM +0200, Honza Horak wrote:
On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies
I don't see any real benefit to move to dash since we get rid of sysV
init, no security improvements, but a lot of breakages to fix (Debian
spent a lot of time to fix bashisms in their packages ...)
That doesn't mean that we shouldn't consider it -this is a sane to
periodically re-assess our
On Thu, Oct 02, 2014 at 11:53:18AM -0400, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
OK, then; care to explicitly list the advantages you expect to see from
such a switch, and why they outweigh the disadvantages and the migration
costs?
I
Am 02.10.2014 um 17:53 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
The expected security improvement is essentially nonexistent. In the
current case of importing functions from
the environment (and we could have a looong philosophical conversation
On 10/2/2014 11:13, Rahul Sundaram wrote:
Sure but the rationale isn't just security as I have explained
earlier. Do read the links and other mails fully.
I have read the emails fully. Sure, I see where you said there were
other reasons later in the discussion, but that's not what your
The expected security improvement is essentially nonexistent. In the current
case of importing functions from the environment (and we could have a looong
philosophical conversation about whether this is a vulnerability in bash or
in its callers, where the likely outcome is “not a vulnerability
2014-10-02 17:56 GMT+02:00 Tomasz Torcz to...@pipebreaker.pl:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most
On 30/09/14 08:46 +0100, Richard W.M. Jones wrote:
How does gccgo affect the packaging of libraries?
The libraries may have support for one or more versions of the go API,
or exclusively one version. Since the gccgo support is usually an API
version or so behind, this compatibility would need
On Thu, Oct 02, 2014 at 05:56:17PM +0200, Tomasz Torcz wrote:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
We don't need to follow Ubuntu or Debian in every not-so-smart decision they
make, we haven't followed them
Hi
On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald wrote:
i doubt that you people are that
hypersensitive about every single word in real life too
People wouldn't say this if it was the first time you wrote something like
this. Also since you asked, I am usually *far* more curt generally
Am 02.10.2014 um 18:04 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald wrote:
i doubt that you people are that
hypersensitive about every single word in real life too
People wouldn't say this if it was the first time you wrote
something like this
which
On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).
I understand this is a
On Thu, Oct 02, 2014 at 11:59:54 -0400,
Miloslav Trmač m...@redhat.com wrote:
As I said in the snipped part, anyone able to submit arbitrary input to a shell
can already cause it to do arbitrary things. The parser bugs do not give the
attacker anything they don’t already have, so they are
Unfortunately tomorrow is a public holiday in Germany, but if someone
else from the WG would run the meeting i've put together a proposed
agenda for tomorrow to give a few updates:
Agenda:
- Update buildrequires cleanup work (davids)
- Update Alpha base image
- Open Floor
Thanks regards,
Hi
On Thu, Oct 2, 2014 at 12:14 PM, Reindl Harald wrote:
which would be in fact more a reason to start realize that
people are different in how they express things and not all
is that insulting meant as it could be taken
https://fedoraproject.org/code-of-conduct
Please read the above link
Hi
On Thu, Oct 2, 2014 at 12:13 PM, Ralf Corsepius rc040...@freenet.de wrote:
No. /bin/sh is supposed to be a POSIX-compatible shell.
Right. This is what I meant. We can't just remove /bin/sh completely and
require users to always use dash or bash explicitly. Whether it is a
symlink and
Dne 2.10.2014 v 18:00 Haïkel napsal(a):
2014-10-02 17:56 GMT+02:00 Tomasz Torcz to...@pipebreaker.pl:
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
I don't see the point, now that we use systemd ...
Besides, even
On Thu, Oct 02, 2014 at 11:34:18AM -0400, Rahul Sundaram wrote:
I don't think anyone misunderstood that you have trouble disagreeing
without also being insulting. You are pushing off people who might
otherwise be sympathetic to your perspective by constantly engaging in a
discussion the way
On Thu, Oct 02, 2014 at 11:22:18AM -0500, Bruno Wolff III wrote:
I think the disconnect there was that people assumed that as long as
you controlled which environment variables (by name) were passed you
were OK. It was assumed that the values weren't processed outside of
what you explicitly
On Thu, Oct 02, 2014 at 13:05:27 -0400,
Matthew Miller mat...@fedoraproject.org wrote:
For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our current patch or %% upstream are scanned for
Am 02.10.2014 um 19:08 schrieb Bruno Wolff III:
On Thu, Oct 02, 2014 at 13:05:27 -0400,
Matthew Miller mat...@fedoraproject.org wrote:
For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our
Hi
On Thu, Oct 2, 2014 at 11:59 AM, Tom Rivers wrote:
You know, you could've simply replied to my original take on your
self-described opportunistic proposal with something like, No, Tom, I'm
not just making this proposal because of Shellshock. I really think there
are some merits to dash
On 2 October 2014 17:13, Ralf Corsepius rc040...@freenet.de wrote:
On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove
it
and make the bash dependency explicit (so
On 2 October 2014 13:59, Chris Adams li...@cmadams.net wrote:
Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
In general, I am pretty sure that except a couple of programming
language or UNIX aficionades very few people can actually correctly
separate bashisms from true
Hi
On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
because the conclusion that dash is not vulerable for
other things is invalid
I am afraid there was no such conclusions. To acknowledge known bugs in
bash doesn't require anyone to conclude that dash doesn't have bugs.
Rahul
--
Am 02.10.2014 um 22:45 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
because the conclusion that dash is not vulerable for
other things is invalid
I am afraid there was no such conclusions. To acknowledge known bugs in bash
doesn't require
Hi
On Thu, Oct 2, 2014 at 4:56 PM, Reindl Harald wrote:
then that paragraph refer to Shellshock was not really appropriate without
make really clear that this is not a panic reaction in context of already
fixed bash bugs
I didn't think one would assume it is just a panic reaction if they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 02 Oct 2014 18:28:40 +0200
Phil Knirsch pknir...@redhat.com wrote:
Unfortunately tomorrow is a public holiday in Germany, but if someone
else from the WG would run the meeting i've put together a proposed
agenda for tomorrow to give a
openSUSE 13.2, scheduled for release in November, will have btrfs as the
default filesystem. What are the chances that F22 will follow suit, assuming
openSUSE has no major problems with it?
https://news.opensuse.org/2014/09/22/
--
devel mailing list
devel@lists.fedoraproject.org
user: mrunge set for eseyman acl: watchcommits of package: perl-IPC-Signal
from: to: Approved on branch: master
To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
user: mrunge set for eseyman acl: approveacls of package: perl-IPC-Signal from:
to: Approved on branch: master
To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
user: mrunge changed point of contact of package: perl-IPC-Signal from: mrunge
to: eseyman on branch: el5
To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-IPC-Signal
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
1 - 100 of 207 matches
Mail list logo
