W dniu 6 października 2010 05:01 użytkownik Eric Sandeen
napisał:
> Michał Piotrowski wrote:
>> 2010/10/6 Eric Sandeen :
>>> Michał Piotrowski wrote:
Hi,
I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any
problems with this tool?
>>> It's had really limited test
Michał Piotrowski wrote:
> 2010/10/6 Eric Sandeen :
>> Michał Piotrowski wrote:
>>> Hi,
>>>
>>> I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any
>>> problems with this tool?
>> It's had really limited testing, and the kernel interface has had
>> some problems in the past (though I
On 05/10/10 08:40 AM, FlorianFesti wrote:
> On 10/05/2010 03:15 PM, Nathaniel McCallum wrote:
>> If the lid is open, both output should be enabled by default (you are
>> free to manually disable one). If the lid is closed on battery power
>> the system should suspend (unless you choose otherwise
2010/10/6 Jesse Keating :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/5/10 3:43 PM, Micha? Piotrowski wrote:
>> Is there somewhere a list of packages potentially broken on F14?
>
> http://fpaste.org/7dvk/ is a list of "broken" F14 builds. The syntax is:
Thanks. I hope that all of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 3:59 PM, Mamoru Tasaka wrote:
>> To handle the F14 scene I've come up with this strategy:
>> > * For things tagged in dist-f14 and no newer build elsewhere, do a bump,
>> > build and tag directly into dist-f14. While there is some risk of
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 3:56 PM, Tom Lane wrote:
> Could you provide a list of the packages you are intending to rebuild?
See my reply to Michal
> Or at least the exact dates where the bad gcc was in use?
The bad gcc was tagged into dist-f14 on Fri Sep 10 20:24:
2010/10/6 Eric Sandeen :
> Michał Piotrowski wrote:
>> Hi,
>>
>> I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any
>> problems with this tool?
>
> It's had really limited testing, and the kernel interface has had
> some problems in the past (though I guess that's irrelevant to
> sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 3:43 PM, Micha? Piotrowski wrote:
> Is there somewhere a list of packages potentially broken on F14?
http://fpaste.org/7dvk/ is a list of "broken" F14 builds. The syntax is:
packagename : detected bad build : tag that build is in
This wa
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15. Items built with this could have unde
Jesse Keating writes:
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15. Items built with this could have undefined behavior, which
> could lead to data corruption.
> ...
> I detected all th
Michał Piotrowski wrote:
> Hi,
>
> I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any
> problems with this tool?
It's had really limited testing, and the kernel interface has had
some problems in the past (though I guess that's irrelevant to
shipping the userspace)
I guess it's a
Hi,
I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any
problems with this tool?
Regards,
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi,
2010/10/6 Jesse Keating :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15. Items built with this could have undefined behavior, whic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you might be aware, there was a period of roughly two weeks where a
gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
Fedora 15. Items built with this could have undefined behavior, which
could lead to data corruption.
Unfortun
Another Graphics Test Week has gone by, so here's the statistical recap!
A foreword - participation was substantially down this year, for which I
entirely blame myself; it kind of crept up on me and I didn't get enough
advance publicity out there. Most especially I didn't get the word out
to Phoro
Jesse Keating wrote, at 10/06/2010 05:58 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/5/10 1:36 PM, Severin Gehwolf wrote:
>> Hi,
>>
>> I am maintaining eclipse-egit and eclipse-jgit. Since
>> eclipse-egit depends on eclipse-jgit it makes sense to
>> use chain-builds when b
===
#fedora-meeting: FESCO (2010-10-05)
===
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-05-19.30.log.html
Meeting summary
-
On Tue, Oct 5, 2010 at 9:14 PM, Jesse Keating wrote:
> There was a change in glibc during the F14 development cycle that
> requires running a newer kernel in order to run the f14 binaries.
>
> You could probably cheat a new kernel onto F11 and then do the pungi
> compose in a mock chroot of f14 c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 1:36 PM, Severin Gehwolf wrote:
> Hi,
>
> I am maintaining eclipse-egit and eclipse-jgit. Since
> eclipse-egit depends on eclipse-jgit it makes sense to
> use chain-builds when building them (this is simply
> faster than waiting for eclipse
Hi,
I am maintaining eclipse-egit and eclipse-jgit. Since
eclipse-egit depends on eclipse-jgit it makes sense to
use chain-builds when building them (this is simply
faster than waiting for eclipse-jgit to build, and
become available in the repos before eclipse-git can
be built).
Ok, that works fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 12:59 PM, mike cloaked wrote:
> For the past year or so I have built private builds of current Fedora
> install isos on an old test machine running f11 using mock/pungi, and
> this has generally worked well for me. I use this method to get f
For the past year or so I have built private builds of current Fedora
install isos on an old test machine running f11 using mock/pungi, and
this has generally worked well for me. I use this method to get fully
up to date isos for installs that need almost no updates applying for
the current stable
On Tue, Oct 5, 2010 at 8:00 PM, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 07:53:25PM +0100, Peter Robinson wrote:
>> On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett wrote:
>> >> The BIOS generally manages to get that one correct, can we not query
>> >> and keep the current state on boot?
>
On Tue, Oct 05, 2010 at 07:53:25PM +0100, Peter Robinson wrote:
> On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett wrote:
> >> The BIOS generally manages to get that one correct, can we not query
> >> and keep the current state on boot?
> >
> > It really doesn't.
>
> Seems to work just fine from a
On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote:
>> On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson wrote:
>> > So we could at least cover the case where you plug in an external
>> > monitor, then close the lid? That would be
On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote:
> On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson wrote:
> > So we could at least cover the case where you plug in an external
> > monitor, then close the lid? That would be better than nothing. I assume
> > the problem case is bootin
On Tue, Oct 05, 2010 at 02:27:27PM -0400, Nathaniel McCallum wrote:
> On 10/05/2010 02:25 PM, Matthew Garrett wrote:
> > The range of ways that lid switches can be broken is large. One machine
> > I've seen tries to read from a GPIO that's off by 16, because Intel's
> > GPIO/GPE numbering is comp
On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
>> On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
>>
>> > don't we already have default behaviours based on the lid switch,
>> > anyway? So why don't we have this pr
On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
>
> > don't we already have default behaviours based on the lid switch,
> > anyway? So why don't we have this problem with those? IIRC, we default
> > to suspending the syst
On 10/05/2010 02:25 PM, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote:
>
>> Agreed, the hardware may lie, but the kernel is the arbiter of truth, at
>> least in this case.
>
> The range of ways that lid switches can be broken is large. One machine
>
On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote:
> Agreed, the hardware may lie, but the kernel is the arbiter of truth, at
> least in this case.
The range of ways that lid switches can be broken is large. One machine
I've seen tries to read from a GPIO that's off by 16, becau
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Bundled library in mldonkey - ocaml-bitstring
https://bugzilla.redhat.com/show_bug.cgi?id=640399
Summary: Bundled library in mldonkey - ocaml-bitstring
On 10/05/2010 12:18 PM, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:07 +0100, Matthew Garrett wrote:
>> On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote:
>>> On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote:
I think the fun will come from systems that don't properl
On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
> don't we already have default behaviours based on the lid switch,
> anyway? So why don't we have this problem with those? IIRC, we default
> to suspending the system when the lid is closed on battery power - so
> are we suspending
On Tue, Oct 05, 2010 at 11:16:44AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote:
> > No, but there is a use case where you'd want to have an external monitor
> > connected and the system report that the lid is closed, but still have
> > the internal sys
On Tue, 2010-10-05 at 19:07 +0100, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote:
> > On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote:
> > > I think the fun will come from systems that don't properly report their
> > > lid
> > > status. I think
On 10/05/2010 02:16 PM, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote:
>> On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote:
>>
>>> Maybe just 'lid closed and external monitor connected' would be close
>>> enough? Is there a use case where you'd wan
On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote:
> On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote:
>
> > Maybe just 'lid closed and external monitor connected' would be close
> > enough? Is there a use case where you'd want to have an external monitor
> > connected and th
On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote:
> > I think the fun will come from systems that don't properly report their lid
> > status. I think this is one of the complaints from the X developers.
>
> *shrug* those
On Mon, Oct 4, 2010 at 09:24, Brandon Lozza wrote:
> On Mon, Oct 4, 2010 at 11:14 AM, Rahul Sundaram wrote:
>>
> I'll refrain from replying further on until I have a reply from
> Richard, but you're totally wrong and your love for Firefox is
> blinding your principals (if you have any). You woul
On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote:
> Maybe just 'lid closed and external monitor connected' would be close
> enough? Is there a use case where you'd want to have an external monitor
> connected and the internal system's lid closed, but still have the
> internal system
On Tue, 2010-10-05 at 11:46 -0400, Brandon Lozza wrote:
> I don't blanket label everything with open code as "free software".
> Some stuff bundles things which make it non-free. Code open-ness !=
> free. You can call Firefox open source if you want, but it's not free
> software.
You certainly hav
https://bugzilla.redhat.com/show_bug.cgi?id=625335
https://bugzilla.redhat.com/attachment.cgi?id=451735&action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
On Tue, Oct 05, 2010 at 11:59:44AM -0400, Neal Becker wrote:
> mercurial has hard-wired to install .mo files under python_sitearch, and
> i18n.py has hard-coded to look there.
>
> On fedora, find-lang.sh is usually used to find these files, but expects to
> find them in e.g., /usr/share/locale
>
On Tue, 2010-10-05 at 13:14 -0400, Toshio Kuratomi wrote:
> > Practically speaking, it would add an extra burden to the maintainers,
> > who already do not have enough resources to deal with all the issues.
> > Again, the reason we don't carry non-upstream patches in Firefox has
> > nothing to do
On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote:
> Yeah, I think this is the main issue. It can cause two problems:
>
> - The login screen appears on the laptop screen (which is closed)
> - New windows or the desktop toolbar appear on the laptop screen (which is
> closed)
>
> I think
On Tue, Oct 05, 2010 at 08:22:57AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 08:34 -0400, Brandon Lozza wrote:
> > On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson wrote:
> > > that's the entire point of having trademarks. Free software projects are
> > > obliged to allow you to access
On Tue, Oct 05, 2010 at 02:56:34PM +0200, Thorsten Leemhuis wrote:
> Kevin Kofler wrote on 02.10.2010 00:56:
> > Sven Lankes wrote:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=577653
> >> Looking at how rigorous new packages with bundled libs are fought we
> >> should really stop shipping fir
On Tue, Oct 5, 2010 at 5:42 PM, Brandon Lozza wrote:
> On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson wrote:
>>> You have to remove MoFo's artwork and perform a name
>>> change or you're required to get permission from Mozilla to
>>> redistribute a modified binary. That's not free.
>>
>> Yes, i
mercurial has hard-wired to install .mo files under python_sitearch, and
i18n.py has hard-coded to look there.
On fedora, find-lang.sh is usually used to find these files, but expects to
find them in e.g., /usr/share/locale
Not sure what's the best way to fix this. Either leave .mo files where
On 10/05/2010 09:53 AM, Adam Williamson wrote:
> On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote:
>> On 5 October 2010 05:30, Orion Poplawski wrote:
>>> Are we really stuck with gdm/kdm/lxdm/...dm
>>> implementing it?
>>
>> No, I think what we need to do is to teach GPM how to turn off the
On 10/05/2010 11:53 AM, Adam Williamson wrote:
> On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote:
>> On 5 October 2010 05:30, Orion Poplawski wrote:
>>> Are we really stuck with gdm/kdm/lxdm/...dm
>>> implementing it?
>>
>> No, I think what we need to do is to teach GPM how to turn off the
On Tue, Oct 5, 2010 at 9:16 PM, Brandon Lozza wrote:
>
>
> I don't blanket label everything with open code as "free software".
> Some stuff bundles things which make it non-free. Code open-ness !=
> free. You can call Firefox open source if you want, but it's not free
> software.
>
You claimed t
On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote:
> On 5 October 2010 05:30, Orion Poplawski wrote:
> > Are we really stuck with gdm/kdm/lxdm/...dm
> > implementing it?
>
> No, I think what we need to do is to teach GPM how to turn off the
> internal panel when docked and with the lid clos
On Tue, 2010-10-05 at 11:42 -0400, Brandon Lozza wrote:
> On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson wrote:
> >> You have to remove MoFo's artwork and perform a name
> >> change or you're required to get permission from Mozilla to
> >> redistribute a modified binary. That's not free.
> >
> >
On 10/05/2010 02:35 AM, Richard Hughes wrote:
> On 5 October 2010 05:30, Orion Poplawski wrote:
>> Are we really stuck with gdm/kdm/lxdm/...dm
>> implementing it?
>
> No, I think what we need to do is to teach GPM how to turn off the
> internal panel when docked and with the lid closed. The only m
On Tue, Oct 5, 2010 at 10:58 AM, Rahul Sundaram wrote:
> On 10/05/2010 06:26 PM, Thorsten Leemhuis wrote:
>> Maybe I'm missed something, but there is a (relative) simple question
>> that always pops up in my head when I read things like this. I never
>> bothered to ask it in public, but I'll do n
Compose started at Tue Oct 5 13:15:37 UTC 2010
Broken deps for x86_64
--
almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
frysk-0.
On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson wrote:
>> You have to remove MoFo's artwork and perform a name
>> change or you're required to get permission from Mozilla to
>> redistribute a modified binary. That's not free.
>
> Yes, it is.
>
In a sense that you're "free" to do whatever Mozilla
commit 41a83cd84e2a800e4e8ef13b1ad98e699ca358b6
Author: Iain Arnell
Date: Tue Oct 5 17:25:38 2010 +0200
update to 1.14
- update BR perl(Class:MOP) >= 1.05
- new BR perl(Test::Requires) >= 0.05
- new R/BR perl(Package::DeprecationManager) >= 0.04
.gitignore |1 +
On 10/05/2010 11:21 AM, Christoph Frieben wrote:
> 2010/10/5 Florian Festi:
>> I wonder if there are latops that can be booted with lid closed and that
>> make a subtle sematic difference between the lid was just being closed
>> and is lid was already closed when we booted up.
>
> IBM ThinkPad T23
On Tue, 2010-10-05 at 08:34 -0400, Brandon Lozza wrote:
> On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson wrote:
> > that's the entire point of having trademarks. Free software projects are
> > obliged to allow you to access and modify their code. They are not
> > obliged to allow you to benefit f
2010/10/5 Florian Festi:
> I wonder if there are latops that can be booted with lid closed and that
> make a subtle sematic difference between the lid was just being closed
> and is lid was already closed when we booted up.
IBM ThinkPad T23.
--
devel mailing list
devel@lists.fedoraproject.org
htt
On Tue, Oct 5, 2010 at 2:34 PM, Brandon Lozza wrote:
> On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson wrote:
>> that's the entire point of having trademarks. Free software projects are
>> obliged to allow you to access and modify their code. They are not
>> obliged to allow you to benefit from t
On 10/05/2010 06:26 PM, Thorsten Leemhuis wrote:
> Maybe I'm missed something, but there is a (relative) simple question
> that always pops up in my head when I read things like this. I never
> bothered to ask it in public, but I'll do now:
>
> * Why haven't those that want iceweasel and icedove
Summary of changes:
3a650b7... update to 1.08 (*)
(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mail
On 5 October 2010 15:51, Brandon Lozza wrote:
> It really wouldn't be a fork at all. From what I can tell it's a build
> flag that can be enabled or disabled and automatically takes out the
> trademark and copyright artwork. People just don't want to remove the
> branding because they presume they
On Tue, Oct 5, 2010 at 8:56 AM, Thorsten Leemhuis wrote:
> Maybe I'm missed something, but there is a (relative) simple question
> that always pops up in my head when I read things like this. I never
> bothered to ask it in public, but I'll do now:
>
> * Why haven't those that want iceweasel and
On 10/05/2010 03:15 PM, Nathaniel McCallum wrote:
> If the lid is open, both output should be enabled by default (you are
> free to manually disable one). If the lid is closed on battery power
> the system should suspend (unless you choose otherwise in GPM prefs).
>
I wonder if there are latops
commit 3a650b7cd85cf4b25519e4f4b52e30dc164dd649
Author: Iain Arnell
Date: Tue Oct 5 16:34:59 2010 +0200
update to 1.08
- new BR perl(Test::Requires) >= 0.05
- new R/BR perl(Package::DeprecationManager) >= 0.04
.gitignore |1 +
perl-Class-MOP.spec | 16 +
A file has been added to the lookaside cache for perl-Class-MOP:
7d0bf52ba3689d9973f1631d894c83ca Class-MOP-1.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/l
A file has been added to the lookaside cache for perl-Moose:
99241b8e7b59e6c020e5f36e083ab23d Moose-1.14.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/
On 2 October 2010 11:23, Richard Hughes wrote:
> On 2 October 2010 09:51, Richard W.M. Jones wrote:
>> ..., then (sometimes, not always) displays some sort of
>> error[1].
>
> Yes, it's fixed upstream, apologies. There's a new release on Monday
> which will be pushed to F14.
https://admin.fedora
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=637110
Fedora Update System changed:
What|Removed |Added
--
On 10/05/2010 09:12 AM, Dariusz J. Garbowski wrote:
> On 05/10/10 07:09 AM, Nathaniel McCallum wrote:
>> On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote:
>>> On 05/10/10 05:00 AM, Peter Robinson wrote:
On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes
wrote:
> On 5 October 2010 09:5
On 05/10/10 07:09 AM, Nathaniel McCallum wrote:
> On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote:
>> On 05/10/10 05:00 AM, Peter Robinson wrote:
>>> On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes wrote:
On 5 October 2010 09:55, FlorianFesti wrote:
> Sorry for my may be naive questio
On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote:
> On 05/10/10 05:00 AM, Peter Robinson wrote:
>> On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes wrote:
>>> On 5 October 2010 09:55, FlorianFesti wrote:
Sorry for my may be naive question: Why do we need to know if we are
docked or not
On 05/10/10 05:00 AM, Peter Robinson wrote:
> On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes wrote:
>> On 5 October 2010 09:55, FlorianFesti wrote:
>>> Sorry for my may be naive question: Why do we need to know if we are
>>> docked or not. Isn't there exactly the same situation if the external
>
Kevin Kofler wrote on 02.10.2010 00:56:
> Sven Lankes wrote:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=577653
>> Looking at how rigorous new packages with bundled libs are fought we
>> should really stop shipping firefox and start shipping Iceweasel.
> +1
>
> I really don't see why the Firef
On Mon, Oct 4, 2010 at 6:06 PM, Jesse Keating wrote:
> We knew that this would happen. We would lose some people. When a
> project like us goes basically directionless for years it picks up
> people who have different ideas about what they want to create and where
> they want to go with it. Whe
Compose started at Tue Oct 5 08:15:22 UTC 2010
Broken deps for x86_64
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
bluefish-2.0.2-1.fc15.1.x86_64 requires libgucharmap.so.7()(64bit)
clutter-gst-de
On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson wrote:
> that's the entire point of having trademarks. Free software projects are
> obliged to allow you to access and modify their code. They are not
> obliged to allow you to benefit from their reputation. It doesn't make
> any sense to say 'I thin
On Tue, Oct 5, 2010 at 12:01 AM, Ralf Corsepius wrote:
> On 10/05/2010 12:37 AM, Adam Williamson wrote:
>> On Mon, 2010-10-04 at 11:08 -0400, Brandon Lozza wrote:
>>
>>> That's what i've been saying all day. It's only free software if you
>>> change the name, in which case you may loose brand reco
On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes wrote:
> On 5 October 2010 09:55, FlorianFesti wrote:
>> Sorry for my may be naive question: Why do we need to know if we are
>> docked or not. Isn't there exactly the same situation if the external
>> Monitor is directly connected to the laptop? If
On 5 October 2010 09:55, FlorianFesti wrote:
> Sorry for my may be naive question: Why do we need to know if we are
> docked or not. Isn't there exactly the same situation if the external
> Monitor is directly connected to the laptop? If there is an external
> monitor and the lid is closed don't w
On 10/05/2010 10:35 AM, Richard Hughes wrote:
> No, I think what we need to do is to teach GPM how to turn off the
> internal panel when docked and with the lid closed. The only missing
> piece is for the kernel to export some kind of sysfs boolean saying
> "in-dock". From talks with mjg59, detec
On 5 October 2010 05:30, Orion Poplawski wrote:
> Are we really stuck with gdm/kdm/lxdm/...dm
> implementing it?
No, I think what we need to do is to teach GPM how to turn off the
internal panel when docked and with the lid closed. The only missing
piece is for the kernel to export some kind of s
On 05/10/10 07:27, Jon Ciesla wrote:
> In my experience, git add the patch, fedpkg commit -p, fedpkg build.
> The tag is based on the git revision hash, so it's unique, no need to
> bump the EVR.
Cool, thanks, will do.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproj
88 matches
Mail list logo
