On 03/17/2013 11:13 PM, Kevin Kofler wrote:
Ralf Corsepius wrote:
"Unwanted/non-user-intended network access" => Must be disabled by
default and must explicitly activated by user action.
[snip]
I for one consider the approach of background updating to be a
conceptionally broken and flawed desi
On Sun, 2013-03-17 at 17:31 +0100, Reindl Harald wrote:
> Am 17.03.2013 17:12, schrieb Sérgio Basto:
> > On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote:
> >> [root@fileserver:~]$ system-config-users
> >> The value for the SHELL variable was not found the /etc/shells file
> >> This incident
On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov wrote:
> 2013/3/15 Lukáš Nykrýn :
>> After usr move packages should not install files to /sbin. Unfortunately
>> there is a lot of packages requiring /sbin/service, which was recently moved
>> to /usr/sbin/, and these packages were uninstallable. As
Lukáš Nykrýn wrote:
> After usr move packages should not install files to /sbin. Unfortunately
> there is a lot of packages requiring /sbin/service, which was recently
> moved to /usr/sbin/, and these packages were uninstallable. As a
> workaround I have put Provides: /sbin/service in the initscrip
Ralf Corsepius wrote:
> "Unwanted/non-user-intended network access" => Must be disabled by
> default and must explicitly activated by user action.
[snip]
> I for one consider the approach of background updating to be a
> conceptionally broken and flawed design, lacking generality and usability.
Th
Adam Williamson wrote:
> Then nothing would boot at all.
>
> It turns out this is because the release name of Fedora 19 is:
>
> Schrödinger's Cat
>
> with a single quote used as an apostrophe. That release name gets
> written into the grub entry for a kernel when you're installing it.
> Unfortun
Kees Cook wrote:
> AFD was a single specific program doing a very specific task and hardly
> represents an "average workload". I remain extremely disappointed that the
> default-on state was reverted. Ubuntu has had this feature enabled for
> YEARS now, and it stopped quite a few exploits cold.
Wh
Welcome.
You could start here
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
16.03.2013 23:14, Niyo Raoul wrote:
Greetings,
I am a system engineer at ORINUX BURUNDI. I am not experienced in big
development project. But i love programming and design.
However, i
14.03.2013 12:17, Remi Collet wrote:
Le 13/03/2013 17:16, Remi Collet a écrit :
php-magickwand
Upstream 1.0.9-2 (yes with a -) includes the fix (and the php54 patch)
Thanks.
It built too - http://koji.fedoraproject.org/koji/taskinfo?taskID=5134893
Remi.
--
devel mailing list
devel@lists
13.03.2013 20:24, Remi Collet wrote:
Le 13/03/2013 17:16, Remi Collet a écrit :
php-pecl-imagick
As you're the owner of this one, if you prefer to update it, see
http://svn.php.net/viewvc?view=revision&revision=329769
Patch incorporated, thanks again.
http://koji.fedoraproject.org/koji/taskinf
John Reiser wrote:
> It seems to me that the "private /tmp" feature of recent Fedora systems
> has removed a large percentage of the potential vulnerabilities here.
> If you cannot see anybody else's /tmp then you cannot create
> vulnerabilities in /tmp for them, and they cannot create vulnerabilit
Adam Williamson wrote:
> In my experience, nearly all even somewhat mature apps need intltool to
> compile, so it seems a reasonable thing to install by default in the
> 'development' group.
Only GNOME ones. :-)
The only file type it handles that's not GNOME/GTK+-specific is .desktop
files, and
drago01 wrote:
> On Thu, Mar 14, 2013 at 4:17 PM, Kevin Fenzi wrote:
>> It's simple: always do a rawhide build, then do your branched build.
>
> Nice way of wasting people's time . :/
Always building in Rawhide first is a good habit people should always get
into, plus this change solves a
Jaroslav Reznik wrote:
> Take Fn-1 - it's almost dead, nearly nobody cares about it anymore
> (as bugfixes/backporting are costly), and I'd say with our ability
> to push security updates... It's non sense to have it as supported
> release.
That's a result of the karma system. Most people have jus
Debarshi Ray wrote:
> It is a bit strange that we freeze before the release, and then move
> on to a Rawhide like environment where anything can be pushed by
> anybody at any point in time.
And the answer to that is to find a way to drop or relax the release
freezes. (I'd suggest to have Bodhi di
Debarshi Ray wrote:
> It is interesting how you redefine the meaning of "First". At the DevConf
> you were blaming NetworkManager for breaking KDE when they changed API and
> KDE could not keep up, while GNOME did.
We cannot push new versions of a library when the users of the library are
not rea
Jared K. Smith wrote:
> Yes, we heard you the first three times you said that -- and it's
> still not happening, at least for now.
Each of the three times pointed out a new showstopper-level problem with
having the 2 forks coexist. It's sad that no amount of technical
impossibility is convincing
2013/3/15 Lukáš Nykrýn :
> After usr move packages should not install files to /sbin. Unfortunately
> there is a lot of packages requiring /sbin/service, which was recently moved
> to /usr/sbin/, and these packages were uninstallable. As a workaround I have
> put Provides: /sbin/service in the init
Am 17.03.2013 17:12, schrieb Sérgio Basto:
> On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote:
>>
>> Am 16.03.2013 19:26, schrieb Rex Dieter:
>>> Lukáš Nykrýn wrote:
>>>
After usr move packages should not install files to /sbin.
>>>
>>> That's not necessarily true. Do our packaging
On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote:
>
> Am 16.03.2013 19:26, schrieb Rex Dieter:
> > Lukáš Nykrýn wrote:
> >
> >> After usr move packages should not install files to /sbin.
> >
> > That's not necessarily true. Do our packaging guidelines actually say that
> > anywhere?
>
Am 16.03.2013 19:26, schrieb Rex Dieter:
> Lukáš Nykrýn wrote:
>
>> After usr move packages should not install files to /sbin.
>
> That's not necessarily true. Do our packaging guidelines actually say that
> anywhere?
but WHY are they not saying it clearly?
until now UsrMove is a half-baken
Thanks Richard, I will post to the legal list for license questions. And
for packaging I will follow your suggestion to build everything as
subpackages.
Thanks also for the tips about the %install section ;-)
Mattia
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraprojec
17.03.2013 16:40, Rex Dieter пишет:
Pavel Alexeev wrote:
17.03.2013 05:39, Rex Dieter wrote:
As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue
with pkg-config in cmake is that it isn't always present on all of the
platforms that cmake supports. But it is still probably the
On Sun, Mar 17, 2013 at 01:16:38PM +0100, Mattia Verga wrote:
> Hello,
> I would like to package some additional catalogs for Skychart, but I
> have some questions regarding license and to the package process.
>
> First of all, as you can see on skychart download page [1], each
> package has more
Pavel Alexeev wrote:
> 17.03.2013 05:39, Rex Dieter wrote:
>>> As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue
>>> with pkg-config in cmake is that it isn't always present on all of the
>>> platforms that cmake supports. But it is still probably the way to go
>>> on Linux.
>
Hello,
I would like to package some additional catalogs for Skychart, but I
have some questions regarding license and to the package process.
First of all, as you can see on skychart download page [1], each package
has more than one catalog inside. All of these catalogs are known to be
public
17.03.2013 05:39, Rex Dieter wrote:
Orion Poplawski wrote:
On 03/16/2013 07:38 AM, Rex Dieter wrote:
Orion Poplawski wrote:
On 03/14/2013 09:34 AM, Orion Poplawski wrote:
Okay, looks like upstream cmake has a patch, I'll get it into rawhide
ASAP.
Scratch that, it was a hack for Arch Linux
27 matches
Mail list logo
