On Fri, 2009-11-20 at 20:02 -0600, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
> > 1. Needs GRUB hackery to support transparently. (For the DVD, Anaconda can
> > detect the architecture and install a kernel accordingly, but for a live
> > CD,
> > we don't have any such support.)
>
On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson wrote:
> On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote:
>> Hi folks,
>>
>> I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and
>> while going through the yum remove/add maneuver I pondered:
>> - is there ever a time whe
On Saturday 21 November 2009 01:38:35 am drago01 wrote:
> We should just use release epochs, people might hate them for whatever
> reasons, but they would easily prevent such issues from happing.
The problem with this system, which has been pointed out before, is that
upgrades using the Fedora N
On Sat, Nov 21, 2009 at 10:49 AM, Conrad Meyer wrote:
> On Saturday 21 November 2009 01:38:35 am drago01 wrote:
>> We should just use release epochs, people might hate them for whatever
>> reasons, but they would easily prevent such issues from happing.
>
> The problem with this system, which has
On Fri, 20 Nov 2009 18:17:57 -0800, Adam Williamson wrote:
> To me, this is the wrong fix. The problem here isn't RPM's version
> comparison logic, which is perfectly sound. Instead of nerfing up RPM
> comparisons, which are already full of enough hidden mines, we should
> just improve Fedora's pac
On Sat, 2009-11-21 at 00:42 +, Colin Walters wrote:
> Look at it this way - it's *more* information than you had before, not
> less. And I personally have often been able to find a problem with no
> more than a traceback (especially given -debuginfo being installed, or
> an enthusiast/develope
On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
> We should just use release epochs, people might hate them for whatever
> reasons, but they would easily prevent such issues from happing.
Vendor Epochs have been discussed years ago and have been rejected.
The normal %{epoch} in RPM Version Com
On Sat, Nov 21, 2009 at 12:00 PM, Michael Schwendt wrote:
> On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
>
>> We should just use release epochs, people might hate them for whatever
>> reasons, but they would easily prevent such issues from happing.
>
> Vendor Epochs have been discussed years
On Sat, 21 Nov 2009 12:40:45 +0100, drago01 wrote:
> > On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
> >
> >> We should just use release epochs, people might hate them for whatever
> >> reasons, but they would easily prevent such issues from happing.
> >
> > Vendor Epochs have been discussed
Compose started at Sat Nov 21 08:15:08 UTC 2009
New package covered
Verilog code coverage analyzer
New package dia-CMOS
Dia CMOS Shapes
New package dia-Digital
Dia Digital IC logic shapes
New package dia-electric2
Dia Digital IC logic shapes
New package dia-electron
2009/11/20 Pádraig Brady :
> Jesse Keating wrote:
>> You're making the assumption that the change was made to save space. It
>> wasn't. I can't find the original thread right now, but it's part of a
>> cleanup on configuration tools. Upstream felt it no longer necessary to
>> expose this
>
> Wow
On Nov 21, 2009, at 1:38, drago01 wrote:
On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson
wrote:
On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote:
Hi folks,
I also got bitten by the "FC11 packages 'newer' than FC12" hickup,
and
while going through the yum remove/add maneuver I
On Nov 21, 2009, at 3:00, Michael Schwendt wrote:
On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
We should just use release epochs, people might hate them for
whatever
reasons, but they would easily prevent such issues from happing.
Vendor Epochs have been discussed years ago and ha
On Sat, 21 Nov 2009, Jesse Keating wrote:
>
>
> On Nov 21, 2009, at 1:38, drago01 wrote:
>
> > On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson
> > wrote:
> > > On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote:
> > > > Hi folks,
> > > >
> > > > I also got bitten by the "FC11 packages 'ne
On 09-11-21 06:40:45, drago01 wrote:
...
> You misunderstood me, I was not suggesting adding another epoch but
> simply bump the %{epoch} for every release.
If this were really important to do, just putting the release first in
the version would take care of it without dragging in Epochs.
Epoc
On Sat, 21 Nov 2009 09:43:58 -0600 (CST), Mike wrote:
> Epochs are nasty. Can anyone think of any other mechanism they could use
> with rpm? I'm not talking about what rpm can do today, but any other
> mechanism we could make rpm do tomorrow that could replace epoch?
Given that Epoch can make a
On Fri, 2009-11-20 at 21:28 -0500, Jeff Garzik wrote:
> On 11/20/2009 09:19 PM, James Morris wrote:
> > Are we moving toward a model where the user and the administrator are no
> > longer really separated? Things seem to be regressing according to
> > whatever use-case some desktop developer think
On Sat, 2009-11-21 at 09:43 -0600, Mike McGrath wrote:
> > > We should just use release epochs, people might hate them for whatever
> > > reasons, but they would easily prevent such issues from happing.
> > >
> >
> > Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12.
> > Real
On Sat, 21 Nov 2009 11:31:27 -0500, Tony wrote:
> On 09-11-21 06:40:45, drago01 wrote:
> ...
> > You misunderstood me, I was not suggesting adding another epoch but
> > simply bump the %{epoch} for every release.
>
> If this were really important to do, just putting the release first in
> the
On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote:
> I was going to suggest what seems an obvious alternative way to do what
> Christian wants, without changing anything in rpm. Instead of:
>
> foobar-1.0-1.fc12.x86-64
>
> have:
>
> foobar-fc12-1.0-1.x86-64
Insufficient.
Making %dist most-signi
On Sat, 2009-11-21 at 18:03 +0100, Michael Schwendt wrote:
> Remember that you need to consider %epoch in any explicitly version
> Requires/BuildRequires/Obsoletes/Conflicts, too.
>
> Requires: foo > 2.10
>
> would become what to get accurate? And considering upstream's versioning
> scheme flaw
On Sat, 2009-11-21 at 18:07 +0100, Michael Schwendt wrote:
> On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote:
>
> > I was going to suggest what seems an obvious alternative way to do what
> > Christian wants, without changing anything in rpm. Instead of:
> >
> > foobar-1.0-1.fc12.x86-64
> >
> > h
On Sat, 21 Nov 2009 09:30:33 -0800, Adam wrote:
> On Sat, 2009-11-21 at 18:07 +0100, Michael Schwendt wrote:
> > On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote:
> >
> > > I was going to suggest what seems an obvious alternative way to do what
> > > Christian wants, without changing anything in rp
On Sat, 2009-11-21 at 18:50 +0100, Michael Schwendt wrote:
> You said "without changing anything in rpm". How that?
>
> If you move anything like "fc12" (using a '-' bears a risk) into
> %version makes it necessary to consider the change value in all
> versioned dependencies, too.
as I said, it
On 11/20/2009 07:42 PM, Colin Walters wrote:
Look at it this way - it's *more* information than you had before, not
less.
More information is not necessarily a good thing. We call this concept
"noise."
--CJD
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.
On Sat, 2009-11-21 at 14:23 -0500, Casey Dahlin wrote:
> More information is not necessarily a good thing. We call this concept
> "noise."
Who is we? The information theory community certainly doesn't, either
it's information or noise :)
I think automatic bugreports do have value. You (as a bug
On Thu, Nov 5, 2009 at 9:23 AM, Andy Shevchenko wrote:
> Hello.
>
> Nowadays the jack project has two branches - old jack (1) branch with
> version 0.116.2 and new one called jack2 version 1.9.3.
> I'd like to gather opinions and suggestions about applying new version for
> F13.
> Please, share yo
On Saturday 21 November 2009 05:54:56 Caolán McNamara wrote:
> On Sat, 2009-11-21 at 00:42 +, Colin Walters wrote:
> > Look at it this way - it's more information than you had before, not
> > less. And I personally have often been able to find a problem with no
> > more than a traceback (espec
On Sat, Nov 21, 2009 at 01:19:12PM +1100, James Morris wrote:
> On Fri, 20 Nov 2009, Matthew Garrett wrote:
> > I don't think I'd agree with that. The common case for F10 and F11 will
> > be for people to have installed a package once with the root password
> > and then ticked the "Remember authe
On Fri, Nov 20, 2009 at 07:43:58PM -0700, Stephen John Smoogen wrote:
> On Fri, Nov 20, 2009 at 7:19 PM, James Morris wrote:
> >> I know basically nobody who, on a generally single user system,
> >> explicitly switches to a console to log in as root and perform package
> >> installs there.
> >
> >
Am 2009-11-21 11:00, schrieb drago01:
On Sat, Nov 21, 2009 at 10:49 AM, Conrad Meyer wrote:
On Saturday 21 November 2009 01:38:35 am drago01 wrote:
We should just use release epochs, people might hate them for whatever
reasons, but they would easily prevent such issues from happing.
The prob
As part of our ever vigilant stance towards security around our
packaging process, we have added a new feature to upload.cgi (which
accepts file uploads into the lookaside cache) which will email the
package owner (-ow...@fedoraproject.org, specifically) and
fedora-extras-comm...@redhat.com wheneve
Hi Lubomir,
On Fri, 2009-11-20 at 17:20 +0100, Lubomir Rintel wrote:
> Hi,
>
> Alexander pointed out that I was suggesting a wrong name for Saxon 9
> package [1]. In fact there's a couple of packages in repositories now
> that violate the naming policy [2] in the very same way. Apart from
> wonde
Matthew Garrett writes:
> The reason I find it hard to believe that this practice is the standard
> one even amongst traditional UNIX users is that if it were, there'd be
> no SUID bit on the su binary.
Su with suid is a security risk, removing the suid bit is a normal
practice for me.
--
Krz
On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
> FWIW, there is a syslinux module named ifcpu64 that will load different
> kernels/initrds based on whether the cpu is 64-bit.
Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
image on a 64-bit CD that would say, "sorry, you g
On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
> On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
> > FWIW, there is a syslinux module named ifcpu64 that will load different
> > kernels/initrds based on whether the cpu is 64-bit.
>
> Cool, do syslinux modules work in isolinux? We could ha
36 matches
Mail list logo
