On Mon, 24 Jun 2013 16:42:22 -0700
Adam Williamson wrote:
> (Our legal obligations may be discharged simply by the fact we keep
> the entire frozen tree, including SRPMs, for each release on the
> mirror, but that's an entirely different bikeshed and IANAL).
https://www.gnu.org/licenses/old-lice
As per the Fedora 19 schedule [1], Fedora 19 Final Release Candidate 1
(RC1) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5623#comment:18 . Please see the
following pages for download links (including delta ISOs) and t
On Tue, 25 Jun 2013 00:45:25 +0200
drago01 wrote:
>
> Do people download / use the SRPM DVDs rather then just download the
> ones they are interested in?
https://fedoraproject.org/freemedia/FreeMedia-form.html
It's the downloading bit that can be the problem.
--
Regards,
Frank "When in dou
On Mon, 2013-06-24 at 16:37 -0700, John Reiser wrote:
> >> Do people download / use the SRPM DVDs rather then just download the
> >> ones they are interested in?
>
> > It does seem a tad...vestigial.
>
> If you want to give away copies of the DVD with binaries,
> then under GPL you must offer the
On Mon, 24 Jun 2013, Richard W.M. Jones wrote:
Note there is still a problem that an LDFLAGS hack was needed in the
spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?=
Paul
--
devel mailing lis
>> Do people download / use the SRPM DVDs rather then just download the
>> ones they are interested in?
> It does seem a tad...vestigial.
If you want to give away copies of the DVD with binaries,
then under GPL you must offer the source similarly,
or promise to maintain for 3 years a download sit
On Tue, 2013-06-25 at 00:45 +0200, drago01 wrote:
> On Tue, Jun 25, 2013 at 12:13 AM, Frank Murphy wrote:
> > Freemedia Hat on.
> >
> > Seeing the other thread where size limits have been spoken about:
> > https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html
> >
> > Looking at:
>
On Tue, Jun 25, 2013 at 12:13 AM, Frank Murphy wrote:
> Freemedia Hat on.
>
> Seeing the other thread where size limits have been spoken about:
> https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html
>
> Looking at:
> http://torrent.fedoraproject.org/ Fedora-18-source-DVD.torrent 8
Freemedia Hat on.
Seeing the other thread where size limits have been spoken about:
https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html
Looking at:
http://torrent.fedoraproject.org/ Fedora-18-source-DVD.torrent 8.8GB
Hazard a guess F19 will be similar.
It's pushed the limit of s
On Mon, 2013-06-24 at 07:22 -0400, Jaroslav Reznik wrote:
> > that is, with the old spin-kickstarts and without the above update,
> > we're 19215872 bytes oversize; with the update but old spin-kickstarts,
> > we're 17118720 bytes oversize (the update saves ~2.1MB); and with the
> > update and lat
On Mon, 2013-06-24 at 15:21 +0200, drago01 wrote:
> On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham wrote:
> > Bruno Wolff III (br...@wolff.to) said:
> >> On Sun, Jun 23, 2013 at 18:04:55 -0400,
> >> Matthias Clasen wrote:
> >> >rpm db 82M
> >>
> >> I vaguely remember a discussion abo
On Mon, Jun 24, 2013 at 08:46:51PM +0100, Richard W.M. Jones wrote:
> On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
> > On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones
> > wrote:
> > > but the plugins from that build are not hardened fully:
> > Isn't it possible that the plu
On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
> On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones wrote:
> > but the plugins from that build are not hardened fully:
> Isn't it possible that the plugins are just so trivial that there were
> no opportunities for hardening?
>
> >
Am 24.06.2013 20:57, schrieb Bill Nottingham:
> Florian Weimer (fwei...@redhat.com) said:
>> Does udev/systemd actually process files in rhis directory? I found
>> a couple of files in that directory, from the isdn4k-utils package
>> and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory i
On 06/24/2013 08:57 PM, Bill Nottingham wrote:
Florian Weimer (fwei...@redhat.com) said:
Does udev/systemd actually process files in rhis directory? I found
a couple of files in that directory, from the isdn4k-utils package
and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't
menti
Reindl Harald (h.rei...@thelounge.net) said:
>
>
> Am 24.06.2013 20:57, schrieb Bill Nottingham:
> > Florian Weimer (fwei...@redhat.com) said:
> >> Does udev/systemd actually process files in rhis directory? I found
> >> a couple of files in that directory, from the isdn4k-utils package
> >> a
On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones wrote:
> but the plugins from that build are not hardened fully:
Isn't it possible that the plugins are just so trivial that there were
no opportunities for hardening?
> $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so
>
2013/6/24 Florian Weimer
> Does udev/systemd actually process files in rhis directory? I found a
> couple of files in that directory, from the isdn4k-utils package and from
> libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in
> udev(7), and I can't find it in the /usr/lib/syst
Florian Weimer (fwei...@redhat.com) said:
> Does udev/systemd actually process files in rhis directory? I found
> a couple of files in that directory, from the isdn4k-utils package
> and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't
> mentioned in udev(7), and I can't find it in t
Does udev/systemd actually process files in rhis directory? I found a
couple of files in that directory, from the isdn4k-utils package and
from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned
in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd
binary.
--
Here's the problem (found by Björn Esser):
https://bugzilla.redhat.com/show_bug.cgi?id=977446#c10
and then later on:
https://bugzilla.redhat.com/show_bug.cgi?id=977446#c14
So it seems as if _hardened_build for some reason doesn't work for
libtool-compiled libraries. It does look as if the
On 24/06/2013, at 9:00 PM, Chris Adams wrote:
> Once upon a time, Glen Turner said:
>> What we don't want is a scenario where configuring these protocols on
>> servers has to be done by network engineers. We want them configured from a
>> GUI and supervised by a master daemon. Let's call that "
On 06/24/2013 07:22 AM, John Reiser wrote:
Device sizes vary according to manufacturer and model. 3% is not uncommon.
[snip examples]
Flash drives, like RAM, (technically, they are non-volatile RAM) always
come in binary units. The difference between the nominal and actual
capacity is spa
On Mon, Jun 24, 2013 at 04:05:35PM +0200, Nicolas Mailhot wrote:
> > The situation I described above is a feature, not a side-effect.>
> It's a feature for the cloud infra provider. It's an antifeature for
> everyone else. There is value in providing more features infra-side. There
> is no value i
Am 24.06.2013 13:08, schrieb Matthew Miller:
> On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
>> Sun's tagline of "the network is the computer" was true. But for servers
>> these days "the computer is the network" is also the case. It's nothing
>> for a server today to statically NA
On 06/20/2013 04:53 PM, Mario Ceresa wrote:
Thanks Don, for your answer. How can I follow progress in this area? Is there a
mailing list, or a wiki page for that?
upstream qemu list primarily;
potentiall lkml &/or pci-list if vfio gets modified for it.
@Lars: I'll try the preview repo noneth
On 06/24/2013, Jaroslav Reznik wrote:
> Do we have to be byte strict here? For physical medium sizes, we had to
> be, this 1 GB is more "we set it as we think it's a good idea". Or maybe
> 1 GB sticks (what's the real size one can use + overlay?) but it's not
> as strict, as you could pick up bigg
Le Lun 24 juin 2013 14:40, Matthew Miller a écrit :
> I'm not sure it's the "same reasoning" because I have no idea how what I
> said relates to replacing the BIOS wiith ESXi, but it's certainly the case
> that VMware has been hugely successful. And part of that success is
> because
> addressing
On Mon, Jun 24, 2013 at 12:53:14 +0300,
Panu Matilainen wrote:
On 06/24/2013 03:27 AM, Bruno Wolff III wrote:
The __db.* files hopefully are not included on live images to begin
with. It might be possible to drop the indexes too: current rpm
Those are the files I was referring to and my
On Mon, 2013-06-24 at 09:15 -0400, Bill Nottingham wrote:
> Bruno Wolff III (br...@wolff.to) said:
> > On Sun, Jun 23, 2013 at 18:04:55 -0400,
> > Matthias Clasen wrote:
> > >rpm db 82M
> >
> > I vaguely remember a discussion about dropping this for live images
> > because it gets reb
On Mon, 2013-06-24 at 09:14 -0400, Bill Nottingham wrote:
> > - We have both js and mozjs17. js is still used by gjs, libpeas,
> > libproxy-mozjs and gnome-shell. Possible savings: 7M
>
> I thought Colin was fixing everything to use mosjz17. Is that a F-20
> thing?
It missed f19, yes.
--
devel
Hello,
a new DNF build has been built and pushed to updates-testing for F19
today[1]. It includes the latest upstream libsolv, hawkey, librepo and
DNF with bugfixes, see the DNF 0.3.8 release notes[2].
Ales
[1] http://bit.ly/19vfFeu
[2] http://akozumpl.github.io/dnf/release_notes.html#id7
--
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham wrote:
> Bruno Wolff III (br...@wolff.to) said:
>> On Sun, Jun 23, 2013 at 18:04:55 -0400,
>> Matthias Clasen wrote:
>> >rpm db 82M
>>
>> I vaguely remember a discussion about dropping this for live images
>> because it gets rebuilt ever
Bruno Wolff III (br...@wolff.to) said:
> On Sun, Jun 23, 2013 at 18:04:55 -0400,
> Matthias Clasen wrote:
> >rpm db 82M
>
> I vaguely remember a discussion about dropping this for live images
> because it gets rebuilt every boot when needed. My memory is that we
> ended up removing th
> - We have both js and mozjs17. js is still used by gjs, libpeas,
> libproxy-mozjs and gnome-shell. Possible savings: 7M
I thought Colin was fixing everything to use mosjz17. Is that a F-20
thing?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/l
Compose started at Mon Jun 24 09:15:02 UTC 2013
Broken deps for x86_64
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.x86_64 requires
libphobos-ldc.so.60()(64bit)
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 require
Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 19.
Thursday, June 27, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)
"Before each public release Development, QA and Release Engineering meet
to determine if the
On Mon, Jun 24, 2013 at 01:41:16PM +0200, Nicolas Mailhot wrote:
> > So, the converse is that as actual workloads move to VMs (let alone
> > cloud), the host systems become a special case, and the "normal" case
> > for a server tends to become much more simple: either a single interface
> > probabl
On Mon, Jun 24, 2013 at 01:22:03PM +0200, Reindl Harald wrote:
> yes, and all these setups are more than satisfied with network.service
> and do not need more complexity with a running daemon like NM
If you'd be interested in packaging and maintaining a network.service that
handles static addressi
Compose started at Mon Jun 24 08:15:03 UTC 2013
Broken deps for x86_64
--
[aries-blueprint]
aries-blueprint-0.3.1-5.fc19.noarch requires asm2
[chmsee]
chmsee-2.0-5.git0acc572a.fc20.x86_64 requires libxpcom.so()(64bit)
[cxf]
Le Lun 24 juin 2013 13:08, Matthew Miller a écrit :
> So, the converse is that as actual workloads move to VMs (let alone
> cloud),
> the host systems become a special case, and the "normal" case for a server
> tends to become much more simple: either a single interface probably with
> fixed-addr
* Chris Adams [24/06/2013 06:30] :
>
> You think hundreds of servers (with untold numbers of VMs), or any
> complicated networking setups, are going to each have their network
> configuration managed by a GUI?
I believe Glen meant that in the sense "an admin is running a GUI app
on his workstation
Once upon a time, Glen Turner said:
> What we don't want is a scenario where configuring these protocols on servers
> has to be done by network engineers. We want them configured from a GUI and
> supervised by a master daemon. Let's call that "NetworkManager".
You think hundreds of servers (wit
- Original Message -
> - Original Message -
> > On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote:
> > > On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
> > > > On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote:
> > > >
> > > > >
> > > > > https://bugzilla.
- Original Message -
> On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote:
> > On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
> > > On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote:
> > >
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Fin
On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
> Sun's tagline of "the network is the computer" was true. But for servers
> these days "the computer is the network" is also the case. It's nothing
> for a server today to statically NAT or bridge IPv4 to VMs. Even in that
> case it's be
On 06/24/2013 11:59 AM, Aleksandar Kurtakov wrote:
I believe Debian relaxes the OSGi-generated dependencies on system
libraries. Fedora should do the same thing in its Eclipse packaging.
Just to clarify a bit - this is not a limitation of OSGi. It's the Eclipse
implementation being faulty of
Le Lun 24 juin 2013 11:59, Aleksandar Kurtakov a écrit :
> This shows another problem though: expressing version range in a spec file
> e.g there is no easy way to say I want a package that provides osgi(smth)
> [1.0.0, 1.5.0). If you try to express it with RPM requires as two
> statements:
> Req
Krzysztof,
unrelated to this thread, but I've noticed the "Face" header in your
email, which exceeds the maximum size of such headers. As such, it breaks
the hard limits of some servers as well as clients, such as Claws Mail.
http://quimby.gnus.org/circus/face/
--
Fedora release 19 (Schrödinge
- Original Message -
> From: "Florian Weimer"
> To: devel@lists.fedoraproject.org
> Sent: Friday, June 21, 2013 3:00:36 PM
> Subject: Re: A need for build triggers & automatic rebuilds
>
> On 06/21/2013 08:28 AM, Krzysztof Daniel wrote:
>
> > OSGI records that there is a file
> > org.ecl
On 06/24/2013 03:27 AM, Bruno Wolff III wrote:
On Sun, Jun 23, 2013 at 18:04:55 -0400,
Matthias Clasen wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images
because it gets rebuilt every boot when needed. My memory is that we
ended up removing this
On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
>
> On 22/06/2013, at 7:23 PM, Richard W.M. Jones wrote:
> >
> > (2) Write a shell script that contains the ifconfig/route add (or ip ...)
> > commands they need and have it run at boot. Most simple static
> > network configs are 2 or
52 matches
Mail list logo
