Hi,
On Sun, 03 Nov 2013 14:23:28 +0100
Kevin Kofler wrote:
> Michael Scherer wrote:
> > When statistics cost you money, yeah, I think that's important to
> > take them in account. Maybe your employer do not care about this,
> > but I strongly suspect mine does, and I strongly suspect that most
>
On 03.11.2013 20:25, Rahul Sundaram wrote:
> Hi
>
>
> On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
>
> Do I understand correctly that first problem could be solved by
>
> stabilizing APIs used in various Linux projects? Because developers
> don't want stabilizationt they invent
On 11/02/2013 07:02 PM, Kevin Kofler wrote:
>> plexus-mail-sender-1.0-0.a2.24.fc20.1.src.rpm 0.a2.24.fc20.1
>
> Alphatag before incrementable integer. See html401-dtds. Not fixable without
> Epoch bump.
It *is* fixable w/o epoch bump and I'm about to fix it.
$ rpmdev-vercmp 1.0-0.a2.24.fc20.1 1.
That's fine. The apps would ship directly from upstream, not from Fedora :)
- Original Message -
> On 03.11.2013 20:25, Rahul Sundaram wrote:
> > Hi
> >
> >
> > On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
> >
> > Do I understand correctly that first problem could be solved by
>
On Mon, Nov 4, 2013 at 9:03 AM, Mateusz Marzantowicz
wrote:
> On 03.11.2013 20:25, Rahul Sundaram wrote:
>> Hi
>>
>>
>> On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
>>
>> Do I understand correctly that first problem could be solved by
>>
>> stabilizing APIs used in various Linux projec
A file has been added to the lookaside cache for perl-DB_File:
5656235f7eb5ecac1662e1686b1a1385 DB_File-1.830.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/list
On 11/04/2013 10:45 AM, Bastien Nocera wrote:
That's fine. The apps would ship directly from upstream, not from Fedora :)
I realize Fedora throwing overboard it basic working principles (open
source) and trying to implement the working principles which for decades
have been responsible for o
On Mon, Nov 4, 2013 at 10:57 AM, Ralf Corsepius wrote:
> On 11/04/2013 10:45 AM, Bastien Nocera wrote:
>>
>> That's fine. The apps would ship directly from upstream, not from Fedora
>> :)
>>
>
> I realize Fedora throwing overboard it basic working principles (open
> source)
Apps shipping from ups
On Mon, Nov 4, 2013 at 11:03 AM, drago01 wrote:
> Firefox for instance could use that, or libreoffice, or eclipse. If a
> user needs a newer version (or nightly build) without having upstream
> worry about the specific distribution.
... or users having to update their *entire* system to
unstable/
On Sat, Nov 2, 2013 at 9:04 PM, Michael Schwendt wrote:
> On Sat, 02 Nov 2013 19:39:38 +0100, Xose Vazquez Perez wrote:
>
>> Kevin Kofler wrote:
>>
>> > Xose Vazquez Perez wrote:
>> >> BAD use of %{dist} tag(75):
>> >> ==
>> >> afpfs-ng-0.8.1-13.fc21.3.src.rpm 13.fc21.3
>>
On Mon, 4 Nov 2013 11:03:45 +0100
drago01 wrote:
> Apps shipping from upstream direcly does not have to be closed
> source. Firefox for instance could use that, or libreoffice, or
> eclipse. If a user needs a newer version (or nightly build) without
> having upstream worry about the specific dis
On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy wrote:
> On Mon, 4 Nov 2013 11:03:45 +0100
> drago01 wrote:
>
>
>> Apps shipping from upstream direcly does not have to be closed
>> source. Firefox for instance could use that, or libreoffice, or
>> eclipse. If a user needs a newer version (or nightl
- Original Message -
> On 11/04/2013 10:45 AM, Bastien Nocera wrote:
> > That's fine. The apps would ship directly from upstream, not from Fedora :)
> >
>
> I realize Fedora throwing overboard it basic working principles (open
> source)
Did I say that? No, I don't believe I did.
As an
- Original Message -
> On 1 November 2013 19:27, Tim Lauridsen wrote:
> > Cleaned up the appdata xml
>
> Thanks,
>
> > https://github.com/timlau/yumex/blob/master/misc/yumex.appdata.xml
> > but I get errors from appdata-validate
> > Can see what the problem is :(
>
> You've got some
A file has been added to the lookaside cache for perl-MIME-Lite:
5a6d90329e049eee77248d667343acc7 MIME-Lite-3.030.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/
On Mon, 4 Nov 2013 11:09:28 +0100, Dridi Boukelmoune wrote:
> > If anyone feels like adding an option to rpmdev-bumpspec, that one could
> > attempt at cleaning up Release tags -- but note that even least-significant
> > stuff right of the dist tag could be wanted by the package owner(s), so
> > s
> > This is what I've done [1] for a package to handle the epel '0.'
> > prefix mentioned in the guidelines.
>
> Where to find that in the guidelines?
> Such a prefix sounds questionable and is news to me (not being an EPEL dev).
Ah, probably this special exception:
http://fedoraproject.org/wiki/
Le Lun 4 novembre 2013 11:16, Bastien Nocera a écrit :
> I want upstream to control their
> distribution
> of software and not be reliant on distributions shipping this or that
> update
ie I don't want to make the api stabilization process in my software that
would make it safely shippable by dis
Le Dim 3 novembre 2013 19:34, drago01 a écrit :
> On Sun, Nov 3, 2013 at 6:44 PM, Reindl Harald
> wrote:
>
>> since it is a free operating system it does not need to be commerical
>> successfull and so it needs to satisfy it's *existing* and potential
>> userbase
>> but not obsessive attrative fo
On Mon, Nov 4, 2013 at 11:29 AM, Michael Schwendt wrote:
> On Mon, 4 Nov 2013 11:09:28 +0100, Dridi Boukelmoune wrote:
>
>> > If anyone feels like adding an option to rpmdev-bumpspec, that one could
>> > attempt at cleaning up Release tags -- but note that even least-significant
>> > stuff right o
Le Sam 2 novembre 2013 21:02, Richard Hughes a écrit :
> It's also impossible to do in a
> race-free way on a multiuser system. Quite frankly, I'm surprised
> online updates works as much as it does.
It works as much as it does because people have made it work for years
instead of giving up like
I've submitted some updates for stable >10 days ago and they are still
in testing.
For example
https://admin.fedoraproject.org/updates/FEDORA-2013-19510/slic3r-0.9.10b-5.fc20,perl-Role-Tiny-1.003002-1.fc20,perl-Moo-1.003001-2.fc20
Is there something broken in the process? Is this done by huma
On 04/11/13 11:07, Miro Hrončok wrote:
I've submitted some updates for stable >10 days ago and they are still
in testing.
For example
https://admin.fedoraproject.org/updates/FEDORA-2013-19510/slic3r-0.9.10b-5.fc20,perl-Role-Tiny-1.003002-1.fc20,perl-Moo-1.003001-2.fc20
Is there something brok
On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot <
nicolas.mail...@laposte.net> wrote:
> GNOME decided to break it all the time (can't even get extensions work
> from one gnome-shell version to the next one and no gracefully disabling
> is still functional breakage).
So what do you suggest? We can
Thanks a lot, I somehow missed that information.
Po 4. listopad 2013, 12:14:49 CET, Tom Hughes napsal:
On 04/11/13 11:07, Miro Hrončok wrote:
I've submitted some updates for stable >10 days ago and they are still
in testing.
For example
https://admin.fedoraproject.org/updates/FEDORA-2013-1951
On 04.11.2013 11:13, drago01 wrote:
> On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy wrote:
>> On Mon, 4 Nov 2013 11:03:45 +0100
>> drago01 wrote:
>>
>>
>>> Apps shipping from upstream direcly does not have to be closed
>>> source. Firefox for instance could use that, or libreoffice, or
>>> eclips
On Mon, 4 Nov 2013 11:41:17 +0100, Dridi Boukelmoune wrote:
> > The linked spec is an example where rpmdev-bumpspec does _not_ know
> > what to do because of the %rhel macro in the Release tag. As a result,
> > the tag will be bumped at the very right side only.
>
> I've tested it yesterday and t
Might be a good idea to show that info in bodhi.
Something like:
bodhi: This update has been submitted for stable by churchyard.
bodhi: There is an ongoing freeze, this will be pushed to stable after
the freeze is over.
Po 4. listopad 2013, 12:20:30 CET, Miro Hrončok napsal:
Thanks a lot, I
- Original Message -
>
> Le Lun 4 novembre 2013 11:16, Bastien Nocera a écrit :
> > I want upstream to control their
> > distribution
> > of software and not be reliant on distributions shipping this or that
> > update
>
> ie I don't want to make the api stabilization process in my soft
You're confusing stand-alone applications and extensions to the core desktop.
An easy mistake to make.
- Original Message -
>
> Le Dim 3 novembre 2013 19:34, drago01 a écrit :
> > On Sun, Nov 3, 2013 at 6:44 PM, Reindl Harald
> > wrote:
> >
> >> since it is a free operating system it doe
Unless the hammer has a cool new feature that you want to try out, or
a bug that was hampering your work has been fixed and you want to
test that the problem's solved.
You can see that analogies only get us so far...
- Original Message -
> On 04.11.2013 11:13, drago01 wrote:
> > On Mon, N
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree:
On x86_64:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires
perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires
perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-MIME-Lite-HTML-1.24-4
perl-BerkeleyDB has broken dependencies in the F-20 tree:
On x86_64:
perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21
On i386:
perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21
On armhfp:
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
Pl
perl-Language-Expr has broken dependencies in the F-20 tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc1
On 04.11.2013 12:18, Florian Müllner wrote:
> On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot
> mailto:nicolas.mail...@laposte.net>> wrote:
>> GNOME decided to break it all the time (can't even get extensions work
>> from one gnome-shell version to the next one and no gracefully disabling
>> is st
perl-PDL has broken dependencies in the F-20 tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2)
per
perl-Padre has broken dependencies in the F-20 tree:
On x86_64:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COM
slic3r has broken dependencies in the F-20 tree:
On x86_64:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On i386:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On armhfp:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.1
Le Lun 4 novembre 2013 12:28, Bastien Nocera a écrit :
> You're confusing stand-alone applications and extensions to the core
> desktop.
> An easy mistake to make.
And the distinction has zero merit for the end-users you want to won
And I suspect it has also zero merit for the famous third-party
On 11/04/2013 11:32 AM, Mateusz Marzantowicz wrote:
> Just see how others does this. Linux Kernel is one example, Django is
> another. This two projects from very different corners are able to
> provide stable API/ABI for some longer time period. I really appreciate
The kernel does not provide sta
Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :
> You can probably re-enact that famous scene from the Wickerman building
> this
> many strawmen.
Thank you for demonstrating the complete lack of respect you have for
anyone that disagrees with you.
--
Nicolas Mailhot
--
devel mailing l
On 11/02/2013 09:27 PM, Reindl Harald wrote:
instead going the easy windows-way and say "ok, you have to reboot"
I don't think this is a technically accurate characterization of the
Windows update mechanism. Windows even allows updating processes
through in-memory patching and compiles most
Am 04.11.2013 12:49, schrieb Florian Weimer:
> On 11/02/2013 09:27 PM, Reindl Harald wrote:
>
>> instead going the easy windows-way and say "ok, you have to reboot"
>
> I don't think this is a technically accurate characterization of the Windows
> update mechanism. Windows even allows
> updat
On 11/04/2013 12:32 PM, Mateusz Marzantowicz wrote:
On 04.11.2013 12:18, Florian Müllner wrote:
So what do you suggest? We can either
(1) restrict the functionality extension can provide (e.g. "add an icon
with a menu to the top bar" - of course that'd mean no alternate-tab,
shell-shape, alte
On Mon, Nov 4, 2013 at 6:42 AM, Nicolas Mailhot
wrote:
>
> Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :
>
>> You can probably re-enact that famous scene from the Wickerman building
>> this
>> many strawmen.
>
> Thank you for demonstrating the complete lack of respect you have for
> anyon
Compose started at Mon Nov 4 09:15:05 UTC 2013
Broken deps for armhfp
--
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[bwm-ng]
bwm-ng-0.6
On Mon, Nov 4, 2013 at 12:23 PM, Michael Schwendt wrote:
> On Mon, 4 Nov 2013 11:41:17 +0100, Dridi Boukelmoune wrote:
>
>> > The linked spec is an example where rpmdev-bumpspec does _not_ know
>> > what to do because of the %rhel macro in the Release tag. As a result,
>> > the tag will be bumped
Le lundi 04 novembre 2013 à 12:04 +0100, Nicolas Mailhot a écrit :
> > instead going the easy windows-way and say "ok, you have to reboot"
> > it would be more worth to optimize the handling *after* updates
> > without reboot and let the user decie wichi services are needed
> > to restart
>
> Not
- Original Message -
> On Fri, Nov 1, 2013 at 12:35 PM, Mateusz Marzantowicz
> wrote:
> > On 01.11.2013 15:24, Christian Fredrik Kalager Schaller wrote:
> >> Hi everyone,
> >> Attached is the draft PRD for the Workstation working group. The
> >> proposal tries to be relatively high level a
Le lundi 04 novembre 2013 à 12:21 +0100, Mateusz Marzantowicz a écrit :
> On 04.11.2013 11:13, drago01 wrote:
> > On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy wrote:
> >> On Mon, 4 Nov 2013 11:03:45 +0100
> >> drago01 wrote:
> >>
> >>
> >>> Apps shipping from upstream direcly does not have to be
Emacs is more than 30 years old, gnome-shell is nearing 3 years since its first
stable release. When gnome-shell is this mature, I'm sure the extensions
breaking will be less of a problem :)
- Original Message -
> On 11/04/2013 12:32 PM, Mateusz Marzantowicz wrote:
> > On 04.11.2013 12:1
On Mon, 04 Nov 2013 12:21:23 +0100
Mateusz Marzantowicz wrote:
> The average user don't use nightly builds and should not be
> interested in such experimental software.
They do if they believe version N+, will fix\give
feature X that is nice to have.
and give feedback to upstream on use.
--
R
On Mon, Nov 4, 2013 at 1:00 PM, Josh Boyer wrote:
> On Mon, Nov 4, 2013 at 6:42 AM, Nicolas Mailhot
> wrote:
>>
>> Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :
>>
>>> You can probably re-enact that famous scene from the Wickerman building
>>> this
>>> many strawmen.
>>
>> Thank you for
A lot of autoqa rpmlint jobs crash lately. Just to let you know, this is a
problem in rpmlint and I reported it here:
https://bugzilla.redhat.com/show_bug.cgi?id=1026328
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproj
On Mon, 2013-11-04 at 11:37 +0100, Nicolas Mailhot wrote:
> GNOME decided to break it all the time (can't even get extensions work
> from one gnome-shell version to the next one and no gracefully disabling
> is still functional breakage).
So, you take the one API that is explicitly declared non-s
On 4 November 2013 10:24, Bastien Nocera wrote:
> If you're not using libxml2, you should be.
I'm using GMarkup.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nfs-ganesha is a user-mode NFS v4 server. GlusterFS will use nfs-ganesha
for it's NFSv4 implementation.
https://bugzilla.redhat.com/show_bug.cgi?id=1026337
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Condu
On Mon, Nov 4, 2013 at 6:23 AM, Miro Hrončok wrote:
> Might be a good idea to show that info in bodhi.
>
> Something like:
>
> bodhi: This update has been submitted for stable by churchyard.
> bodhi: There is an ongoing freeze, this will be pushed to stable after the
> freeze is over.
That's not
On Mon, Nov 04, 2013 at 11:36:42AM +, Bryn M. Reeves wrote:
> The kernel does not provide stable APIs. If you've ever tried to
> maintain a non-trivial module or patch to the kernel out-of-tree for any
> length of time you'll understand how much work is involved in just
> keeping it working. Gn
On Mon, Nov 4, 2013 at 2:44 PM, Lars Seipel wrote:
> On Mon, Nov 04, 2013 at 11:36:42AM +, Bryn M. Reeves wrote:
>> The kernel does not provide stable APIs. If you've ever tried to
>> maintain a non-trivial module or patch to the kernel out-of-tree for any
>> length of time you'll understand h
Dne 4.11.2013 14:41, Josh Boyer napsal(a):
On Mon, Nov 4, 2013 at 6:23 AM, Miro Hrončok wrote:
Might be a good idea to show that info in bodhi.
Something like:
bodhi: This update has been submitted for stable by churchyard.
bodhi: There is an ongoing freeze, this will be pushed to stable afte
- Original Message -
> On Mon, Nov 4, 2013 at 6:23 AM, Miro Hrončok wrote:
> > Might be a good idea to show that info in bodhi.
> >
> > Something like:
> >
> > bodhi: This update has been submitted for stable by churchyard.
> > bodhi: There is an ongoing freeze, this will be pushed to stab
Maybe a new feature in Bodhi 2.0?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
A file has been added to the lookaside cache for perl-Perl-Critic:
d14676d579c4fbc2736106f9863d4d1f Perl-Critic-1.121.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/mail
Hi,
I think this is a pretty good starting point for our development direction, and
sets the stage for us making positive progress in the new working group model.
I do think we should keep it open to tweaks in the future as things
play out, (at
the discretion of the 9 members on the working group
Compose started at Mon Nov 4 08:15:03 UTC 2013
Broken deps for i386
--
[OpenEXR_CTL]
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-1.0.1-16
On Sat, Nov 2, 2013 at 9:02 PM, Richard Hughes wrote:
> On 2 November 2013 17:47, Matthew Miller wrote:
>> I'm not really excited about a lot of required rebooting, though -- I think
>> that might be worse than the disease. We should have most of the information
>> needed to determine if a reboot
On Sat, 2013-11-02 at 21:29 +0100, Björn Persson wrote:
> Fedora mustn't have third-party repositories like RPM Fusion enabled by
> default. Users must consciously configure them.
> Therefore Fedora mustn't download Cisco's binaries by default. It will
> have to be something that users must conscio
On Mon, 4 Nov 2013 13:31:00 +0100, Dridi Boukelmoune wrote:
> Now I'm in doubt, I'll double check that this evening. Also, do we
> want diverging releases for sub-packages ?
There may be use-cases.
A second Release tag in the spec file redefines %{release} for the
remainder of the spec file, so
On Sat, 2013-11-02 at 18:36 +0100, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > Another important point is that future versions of Firefox will download
> > and "install" (I'm not quite sure where) the binary from Cisco's
> > website, unless some about:config setting is disabled. I imagine th
On 11/04/2013 03:39 PM, Alberto Ruiz wrote:
On Sat, 2013-11-02 at 21:29 +0100, Björn Persson wrote:
Fedora mustn't have third-party repositories like RPM Fusion enabled by
default. Users must consciously configure them.
Therefore Fedora mustn't download Cisco's binaries by default. It will
have
https://bugzilla.redhat.com/show_bug.cgi?id=1026321
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 4 November 2013 14:31, Miloslav Trmač wrote:
> That's true in the _general_ case, and therefore the ability to have
> off-line updates is a good _general_ default. We should be able to do
> _much_ better for many common cases (at the very least, a package that
> only has one executable, or one
On Mon, 2013-11-04 at 14:48 +, Richard Hughes wrote:
> I like what ChromeOS
> does where it has a rescue-ish partition, to do the upgrade, but
> without something like btrfs that can switch roots on a running
> filesystem that's basically impossible on Linux.
This is precisely what https://wik
On Mon, Nov 4, 2013 at 3:48 PM, Richard Hughes wrote:
> On 4 November 2013 14:31, Miloslav Trmač wrote:
>> That's true in the _general_ case, and therefore the ability to have
>> off-line updates is a good _general_ default. We should be able to do
>> _much_ better for many common cases (at the
On Mon, Nov 04, 2013 at 12:18:16PM +0100, Florian Müllner wrote:
> > GNOME decided to break it all the time (can't even get extensions work
> > from one gnome-shell version to the next one and no gracefully disabling
> > is still functional breakage).
> So what do you suggest? We can either
> (1) r
On Mon, Nov 4, 2013 at 4:58 PM, Matthew Miller wrote:
> On Mon, Nov 04, 2013 at 12:18:16PM +0100, Florian Müllner wrote:
>> > GNOME decided to break it all the time (can't even get extensions work
>> > from one gnome-shell version to the next one and no gracefully disabling
>> > is still functiona
Hi everyone.
A quick update from my side regarding the Base Design WG:
- My proposed committee was approved by FESCO last Wednesday. One
negative vote came from Stephen Gallagher that he would have very much
preferred to have Lennart instead of Harald or Josh on the committee.
- IRC meetin
On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote:
Hi everyone,
Attached is the draft PRD for the Workstation working group. The
proposal tries to be relatively high level and focus on goals and
principles, but I have included some concrete examples at times to try
to provide some clari
On Mon, Nov 04, 2013 at 05:02:21PM +0100, drago01 wrote:
> > I think there's probably a third way. It used to be that Firefox extensions
> > broke with every update, but now that really rarely happens. That's partly
> > because the base program has kind of stablized, but also because there's a
> >
Michael Scherer wrote:
> As i say, we mostly have a fleet of laptop, and of course, the situation
> would be different if this was a set of workstation, but alas, this is
> not the case.
It's true that the problem is harder for laptops, which are often more
loosely administrated by necessity.
>
On Mon, Nov 4, 2013 at 5:17 PM, Matthew Miller wrote:
> On Mon, Nov 04, 2013 at 05:02:21PM +0100, drago01 wrote:
>> > I think there's probably a third way. It used to be that Firefox extensions
>> > broke with every update, but now that really rarely happens. That's partly
>> > because the base pr
Dne 4.11.2013 16:56, Toshio Kuratomi napsal(a):
@churchyard, as part of this we should probably come up with another list of
packages that do not have python3 versions for the packages in the critical
path.
Can we use that one?
St 30. říjen 2013, 21:37:14 CET, Ralph Bean napsal:
> - I got th
On 11/01/2013 03:42 AM, Paul W. Frields wrote:
Hi Fedora folks,
Hopefully some of you know me, possibly as a previous Fedora Project
Leader at Red Hat. If you don't, then salutations, and please feel
free to check out my Fedora wiki page[1] for my background. :-)
As of next Monday, I'll be the
On Mon, Nov 04, 2013 at 05:30:06PM +0100, drago01 wrote:
> > Instead, make it easy for extension authors to keep
> > their extensions up to date with the changes.
> Sure but given that extensions can modify pretty much anything that
> would imply documenting every code change.
Well, in an ideal wo
On Mon, Nov 4, 2013 at 6:10 PM, Matthew Miller wrote:
> I found this
> http://blog.fpmurphy.com/2011/11/updating-gnome-shell-extensions-to-work-with-gnome-3-2.html
> for Gnome 3.2, but unfortunately nothing like it for newer releases.
Because we didn't change that API since then. Those changes w
On Mon, Nov 04, 2013 at 05:21:26PM +0100, Miro Hrončok wrote:
>
>
> Dne 4.11.2013 16:56, Toshio Kuratomi napsal(a):
> >@churchyard, as part of this we should probably come up with another list of
> >packages that do not have python3 versions for the packages in the critical
> >path.
>
> Can we u
Chris Murphy wrote:
> Right, because that's a model for success that shouldn't be either
> emulated or improved upon, it's better for each little fiefdom's paradise
> to erect walls to ensure cross influence isn't happening.
Your insulting the Free Software community as a "fiefdom" really offends
On Mon, Nov 04, 2013 at 15:46:07 +0100,
Alberto Ruiz wrote:
While I agree that we shouldn't silently install non-free software (and
I'm sure Mozilla doesn't want to either), saying that they are
effectively non-free is a bit inaccurate, the _binaries_ are not
re-distributable under US jurisdi
Alberto Ruiz wrote:
> We still have a problem with MP3, but it does solve a fundamental
> problem.
We had the same type of solution (just with a different binary producer,
Fluendo) offered for MP3. We rejected it, due to both political (effectively
unmodifiable binary) and technical (interoperab
On Mon, Nov 04, 2013 at 06:14:05PM +0100, drago01 wrote:
> > I found this
> > http://blog.fpmurphy.com/2011/11/updating-gnome-shell-extensions-to-work-with-gnome-3-2.html
> > for Gnome 3.2, but unfortunately nothing like it for newer releases.
> Because we didn't change that API since then. Those c
The following Fedora EPEL 5 Security updates need testing:
Age URL
561
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
75
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5
51
https://admin.fedoraproject.org/updates/FEDO
The following Fedora EPEL 6 Security updates need testing:
Age URL
561
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
75
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6
36
https://admin.fedoraproject.org/updates/FEDO
Rahul Sundaram wrote:
> You assume that sandboxed apps means we get all the negatives and none of
> the benefits. That is unwarranted. We can adopt the good parts and
> improve upon it based on the lessons learned from adoption of app stores
> across multiple operating systems and mobile devices
https://bugzilla.redhat.com/show_bug.cgi?id=1026067
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from Fedo
https://bugzilla.redhat.com/show_bug.cgi?id=1026220
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from Fedo
https://bugzilla.redhat.com/show_bug.cgi?id=1026219
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from Fedo
On Mon, Nov 04, 2013 at 06:39:54PM +0100, Kevin Kofler wrote:
> The reason we are so strongly opposed to app stores is that we are fairly
> convinced that the mere fact of having them available WILL:
> * reduce the number of applications actually available in our repositories
> (because some ups
On Wed, 2013-10-30 at 15:22 -0400, Josh Boyer wrote:
> On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode wrote:
> > Hi,
> >
> > On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer
> > wrote:
> >> The other positions will be filled by general election
> >> every two years. As a special exception, four seats wi
Florian Müllner wrote:
> ... or users having to update their *entire* system to
> unstable/experimental versions if they want to try the lastest
> Firefox/Libreoffice/Eclipse
Then either upstream or the Fedora packager should just build the unstable
version against the stable Fedora in a PPA. See
1 - 100 of 218 matches
Mail list logo
