On 02/06/2013 08:42 AM, Stijn Hoop wrote:
On Tue, 05 Feb 2013 21:46:32 +0100
Ralf Corsepius wrote:
The actual problem is the current Gnome 3 being an entirely different
product than Gnome 2, which usability-wise has *nothing* in common
with Gnome2 and addresses a completely different target aud
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch wrote:
>We
>will need a method to enable/disable on a per-vendor basis as we
>added to RHEL in the udev rules that invoke (or don't) biosdevname.
>The suggestion of linking in (or not) rules files won't work for a
>distro-wide per-ve
On Fri, 08 Feb 2013 02:57:19 +0100
Petr Machata wrote:
> Hi there,
>
> I have just built boost 1.53. I didn't go through the side tag as
> originally envisioned, as tomorrow's mass rebuild should take care of
> it all in one fell swoop. I'll still be available for help if your
> package myster
On Thu, Feb 7, 2013 at 11:36 PM, Glen Turner wrote:
> On 29/01/13 05:32, Lennart Poettering wrote:
>
>> We figured in this it's better to just stick to a single name for each
>> iface, pick a good default scheme for it, and support alternative
>> schemes.
>
> The whole point of biosdevname was to
On Thu, Feb 7, 2013 at 12:07 PM, Bradley Baetz wrote:
> On 07/02/13 00:33, Michal Schmidt wrote:
>>
>> On 02/05/2013 02:53 AM, Scott Schmit wrote:
>>>
>>> Is there a program/script we can run that would tell us what the
>>> interface names would be without biosdevname (without running the new
>>>
On Thu, Feb 07, 2013 at 10:07:59PM +1100, Bradley Baetz wrote:
> What happens with USB network devices that are plugged into
> different slots? Currently my iPhone shows up as eth1, but using the
> above, depending on which of two adjacent ports I happen to plug it
> into, I get:
>
> $ udevadm inf
Hi there,
I have just built boost 1.53. I didn't go through the side tag as
originally envisioned, as tomorrow's mass rebuild should take care of it
all in one fell swoop. I'll still be available for help if your package
mysteriously fails or if there's just too many <'s and >'s in your
package
On Tue, 05.02.13 06:42, Sérgio Basto (ser...@serjux.com) wrote:
> On Ter, 2013-01-29 at 17:59 +, Sérgio Basto wrote:
> > On Ter, 2013-01-29 at 01:52 +0100, Lennart Poettering wrote:
> > > Yes, even then. udev will notice rules dropped there.
> >
> > OK I will test that
>
> I just test it a
On 29/01/13 05:32, Lennart Poettering wrote:
> We figured in this it's better to just stick to a single name for each
> iface, pick a good default scheme for it, and support alternative
> schemes.
The whole point of biosdevname was to move from a ennumeration-centric
view or a bus-centric view of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu 07 Feb 2013 02:26:48 PM EST, Jamie Nguyen wrote:
> On 07/02/13 19:24, Jamie Nguyen wrote:
>> Now that I'm a bit more familiar with node.js packaging (ie, never even
>> looked at node.js before this week...), I'll take it.
>>
>> I don't currently
On 07/02/13 19:24, Jamie Nguyen wrote:
> Now that I'm a bit more familiar with node.js packaging (ie, never even
> looked at node.js before this week...), I'll take it.
>
> I don't currently have any packages for you to review, so you get off
> scot-free. Well, for now at least ;)
Oops, looks lik
On 05/02/13 23:19, T.C. Hollingsworth wrote:
> Hi!
>
> Anyone want to swap reviews for some of my outstanding Node.js reviews?
>
> FPC recently approved guidelines for Node.js packaging that are fairly
> easy to check against:
> https://fedoraproject.org/wiki/Packaging:Node.js
>
> The most criti
On Thu, Feb 7, 2013 at 2:05 PM, L L wrote:
>
> the package: raspberrypi-kernel-3.6.11-1.20130205gitc5cb0b5.rpfr18.src.rpm
>
> posted at:
> http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/packages/source/
>
> is an RPM package, not a source RPM package --which is evidenced b
the package: raspberrypi-kernel-3.6.11-1.20130205gitc5cb0b5.rpfr18.src.rpm
posted at:
http://scotland.proximity.on.ca/raspberrypi/raspberrypi-fedora-remix/18/packages/source/
is an RPM package, not a source RPM package --which is evidenced by its 12M
file size.
Could someone please update this p
Can someone who knows firewalld please do a HOWTO to on setting up a
secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please
to go with the PXEBOOT HOWTO :-
http://linux-sxs.org/internet_serving/pxeboot.html
Hope someone can help, I put I message on the User List but got no
On Thu, Feb 07, 2013 at 08:34:18AM -0500, Dan Winship wrote:
> On 02/07/2013 07:27 AM, Daniel P. Berrange wrote:
> > The other potential impact is that gnutls no longer uses libgcrypt,
> > but instead uses nettle.
> >
> > This can impact apps that were using gnutls in a threaded environment
> > be
On 02/07/2013 07:27 AM, Daniel P. Berrange wrote:
> The other potential impact is that gnutls no longer uses libgcrypt,
> but instead uses nettle.
>
> This can impact apps that were using gnutls in a threaded environment
> because they probably have used 'gcry_control' to register a thread
> impl
On 02/06/2013 02:17 PM, James Hogarth wrote:
On 6 February 2013 12:33, Stephan Bergmann mailto:sberg...@redhat.com>> wrote:
On 02/06/2013 02:36 AM, Andrea Pescetti wrote:
About the "soffice" alias, it still breaks parallel installation
in F18
(just tried, the desktop
On Wed, Feb 06, 2013 at 09:59:36PM +0100, Tomas Mraz wrote:
> I'm rebasing gnutls in rawhide to gnutls-3.1.7. This is much awaited
> upgrade by many. However note that potentially patented ECC sources are
> removed.
>
> The rebase bumps soname to libgnutls.so.28. The other potentially
> disrupting
On 07/02/13 00:33, Michal Schmidt wrote:
On 02/05/2013 02:53 AM, Scott Schmit wrote:
Is there a program/script we can run that would tell us what the
interface names would be without biosdevname (without running the new
version of systemd on the box)?
If you have Fedora 18 with updates applie
Tomas Mraz wrote:
I'm rebasing libtasn1 in rawhide to libtasn1-3.2. As there is some
obsolete API dropped it is accompanied with SONAME bump from
libtasn1.so.3 to libtasn1.so.6. I will try to rebuild the dependencies.
Regards,
Added to upstream tracker for monitoring future API changes:
http:
21 matches
Mail list logo