Re: soname changing parted heading for rawhide

Adam Williamson (awill...@redhat.com) said: > > [h...@localhost ~]$ sudo repoquery -q --whatrequires > > 'libparted-1.9.so.0()(64bit)' > > qtparted-0:0.4.5-22.fc12.x86_64 > > DeviceKit-disks-0:009-3.fc12.x86_64 (now udisks) > > gparted-0:0.4.8-1.fc12.x86_64 > > kde-partitionmanager-0:1.0.0-2.fc12

Re: Orphaning Candidate packages for removal due to FTBFS, implications

Matt Domsch (matt_dom...@dell.com) said: > > With nobody handling the incoming bugzilla tickets. With some bug > > reports having been killed in an automated way at dist EOL. And > > worse if it turns out that packages which do build are unmaintained > > nevertheless, with the same symptoms in bug

Re: yum-presto and comps

Kevin Kofler (kevin.kof...@chello.at) said: > +1 > > In fact, we voted in FESCo that it should be added to one of the base groups > instead (@base, I guess). It makes no sense to have it in @gnome-desktop nor > in the KDE .ks file (which is where it is at the moment – for KDE, it's in > the .k

Re: yum-presto and comps

Jens Petersen (peter...@redhat.com) said: > I meant to add that the reason this came up was I was trying to work out > where to put yum-langpacks in comps: yum-presto being one of the reference > packages I searched for. > > So where can/should yum-langpacks live? Probably in base. Now whether i

[RFC PATCH] use sulogin in single-user mode

We have an existing bug where if you're in single-user mode, and SELinux is active, various commands don't print to the console. The root of this is the single-user shell isn't running in the right SELinux context, as there's nothing to distinguish this from the 'normal' shells run during bootup.

Re: [RFC PATCH] use sulogin in single-user mode

Jon Ciesla (l...@jcomserv.net) said: > My thoughts exactly. What are the less simple fixes that don't change > this behaviour? Essentially, introducing new scripts solely for this purpose that can be given a special label and some policy. It's a hack. Note that you can still do without-passwor

Re: [RFC PATCH] use sulogin in single-user mode

Chris Adams (cmad...@hiwaay.net) said: > How about moving /usr/bin/runcon to /bin and using that to call bash > instead? The problem is that the context it needs to run at isn't static; it depends on the policy of the machine. Hence, you don't want to hardcode a runcon call in the script. Bill -

Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?

Richard Zidlicky (r...@linux-m68k.org) said: > > .. just wondering why it's under /sbin and not under > > /etc/sysconfig/network-scripts/ > > > > It doesn't feel very good to add custom configuration under /sbin. > > same opinion here. I have actually used this for a while, adds one more thing

Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?

Tony Nelson (tonynel...@georgeanelson.com) said: > > > same opinion here. I have actually used this for a while, adds > > > one more thing that needs be verified after system upgrades, not > > > very nice. > > > > Realistically, the conglomeration of configuration and scripts in > > /etc/syscon

Re: Multilib help?

Richard W.M. Jones (rjo...@redhat.com) said: > Is there better documentation on how multilib works and how to resolve > multilib problems than > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks ? I > understand that it uses various heuristics before it corrupts files, > but those don'

Re: Moving lspci and setpci from /sbin to /usr/sbin?

Michal Hlavinka (mhlav...@redhat.com) said: > Do you think moving this is a bad idea? I think it should not break anything, > only problem can be with separate /usr partition but because of library in > /usr it would be already broken and I've not seen any complain about it ever. Furthermore, m

Re: abrt not working in current Rawhide?

Adam Williamson (awill...@redhat.com) said: > Just checking if I'm the only one - I can't find a bug report, though > I'll probably file one. abrt doesn't seem to work in current Rawhide. > The daemon and applet both claim to be running, but I never get an abrt > pop-up when anything crashes (whic

Re: New merge review tickets being opened

Jason L Tibbitts III (ti...@math.uh.edu) said: > Some Red Hat employees are opening new merge review tickets for packages > which were in extras long before the big core-extras merge. It looks > like all of these packages are so old that the reviews predate the use > of Red Hat's bugzilla for the

Re: --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???

Owen Taylor (otay...@redhat.com) said: > Looking at the build logs for F-12, e.g.: > > http://kojipkgs.fedoraproject.org/packages/glib2/2.22.4/1.fc12/data/logs/i686/build.log > > we seem to have things set up to run configure as: > > --build=i386-redhat-linux-gnu > --host=i386-redhat-linux-gn

Re: [RFC PATCH] use sulogin in single-user mode

Chris Adams (cmad...@hiwaay.net) said: > One other note about this: this would break with a separate /usr and a > failure in mounting /usr, because (at least in F12) /sbin/sulogin is > linked against libfreebl3.so (which is in /usr/lib{,64}). It looks like > libfreebl3.so was moved from /lib{,64}

Re: --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???

Panu Matilainen (pmati...@laiskiainen.org) said: > > %{_host} is set by the rpm package in the macros file, %{_build} defaults > > to the value of %{_host}. %{_target_platform} comes from --target on > > the command line, plus the usual vendor/OS bits > > > > --target is what is set by rpm/mock. I

Re: Board efforts: scope, concept, and permission?

Toshio Kuratomi (a.bad...@gmail.com) said: > I think that the Fedora Project's target audience needs to be people who > want to work on open source operating systems. If you want to market the > Fedora Project, that's the audience that needs to be addressed. > > If you want to market a physical

Re: Board efforts: scope, concept, and permission?

Toshio Kuratomi (a.bad...@gmail.com) said: > My other mail suggests that one way to work with this is to create new > conflicting packages that are optimized for the different usages. There's > other ways as well but the general theme is that we need to be looking at > ways to open up what people

Re: Board efforts: scope, concept, and permission?

Adam Miller (maxamill...@fedoraproject.org) said: > > Furthermore, you then leave 'downstream' higher-level packages and > > applications having to, for example, code to PolicyKit0, PolicyKit1, or > > consolehelper, depending on what each 'product' use case might use. Or, > > having to build their

Re: Board efforts: scope, concept, and permission?

Adam Miller (maxamill...@fedoraproject.org) said: > On Tue, Feb 2, 2010 at 2:29 PM, Bill Nottingham wrote: > > > Take a random downstream app. (Firefox is an example, but there are many > > others.) Right now, it only needs to track a single version of python, > > or

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

Lennart Poettering (mzerq...@0pointer.de) said: > And here's another addition: you might also want to run this command > when upgrading from older rwahide to current F-14/rawhide: > > # systemctl enable graphical.target > > This makes sure the default.target link is created properly I still b

Re: [ACTION REQUIRED] orphaned packages in F-14

Michael Schwendt (mschwe...@gmail.com) said: > > Unblocked orphan librsvg2 > > What's going on here? The procedure used to be for various gnome-y packages in the days before provenpackager to just assign a single maintainer and a whole slew of co-maintainers, so anyone in the Desktop SIG could u

Re: [ACTION REQUIRED] orphaned packages in F-14

Petr Pisar (ppi...@redhat.com) said: > > I suggest that these be just built without NAS support. NAS is basically an > > older competitor to PulseAudio with fewer features (it focuses on network > > transparency, which is just one of the things PulseAudio does), it is not > > compatible with Pu

Re: Plan for tomorrow's FESCo meeting (2010-08-10)

Michael Schwendt (mschwe...@gmail.com) said: > > * LINK: http://fedoraproject.org/PackageReviewStatus/MERGE.html > > (nirik, 19:59:05) > > * AGREED: : encourage provenpackagers to commit to rawhide fixes for > > merge reviews. said pp's should not be the reviewer. > > Pardon? What exa

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

Lennart Poettering (mzerq...@0pointer.de) said: > > Yes, that is correct. An already built version on f15 will always be > > "newer" than anything coming up from f14. > > Can I "undo" such a build? I did that mostly because I forgot that the > branching already happened when I built systemd the

Re: The slip down memory lane

Matthias Clasen (mcla...@redhat.com) said: > > This is a collective failure. > > I'd like to question that premise. Why is it a failure if we adjust our > release schedule to meet our release criteria ? Well, ideally we'd be able to schedule such that we can accomplish our release criteria wit

Re: F14/F13 - system-config-display - should it work?

Felix Miata (mrma...@earthlink.net) said: > So users of absent or dysfunctional DDC and/or EDID should be committed to > 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still > working just fine) displays Just as a point, if the EDID/DDC is dysfunctional, then I don't think

Re: The slip down memory lane

Jon Ciesla (l...@jcomserv.net) said: > I disagree that a clockwork release schedule is required for quality, or > even perceived quality. If that's the sort of metric being looked at, > the user is probably best suited to RHEL, CentOS, etc. It would be interesting to look at RHEL/CentOS to see

Re: New bodhi release in production

Toshio Kuratomi (a.bad...@gmail.com) said: > So I've kept my voice out of this... and hopefully, now that you know that > it's not just hte KDE SIG, I can go back to doing so again. ... how does that help? You've mentioned that you don't like 'this change' ... which part of it are you referring

Re: New bodhi release in production

Ryan Rix (r...@n.rix.si) said: > available (sometimes in front of it)... Yet even now, we can't keep up with > what (some of) our users want: the latest KDE, on KDE's release day, whether > it's a major release, or a point release. Yes, not every one of our users is > this way, but many are, an

[ACTION REQUIRED, v2] orphaned packages in F-14

The attached list shows currently orphaned packages in F-14. If they are not claimed by the end of next week, they will be blocked, potentially breaking dependencies (and causing more things to be blocked...) If you already co-maintain the package, please step up and take it. (If you don't, it may

Re: systemd and filesystems with noauto

Lennart Poettering (mzerq...@0pointer.de) said: > So, to turn this around. Do you think this behaviour is problematic? Can > you make a good case for dropping this automatism? If so I'd be willing > to do so. Yes, 'noauto' has defined semantics of 'not automatically mounted at boot'; breaking tha

Re: systemd and changes

Matthew Miller (mat...@mattdm.org) said: > So, I'm honestly asking: what are the odds that these few things are the > only improvements that cause a disruptive change to user interaction? I > don't think it's unreasonable to wonder if there are other changes which fit > this category. My concern

Re: systemd and changes

Mike McGrath (mmcgr...@redhat.com) said: > > My concern with this line of thinking is that you're asking us to quantify > > the unknown unknown, and define a time period of testing which is > > 'long enough' for us to catch all the unknown unknowns. This seems > > impractical, in as much as it doe

systemd acceptance, packaging guidelines (was Re: systemd and changes)

(intentionally breaking thread) Toshio Kuratomi (a.bad...@gmail.com) said: > Maybe I should start a new thread since this isn't really a bug, but it is > a blocker -- we need to get some packaging guidelines out for systemd. > I think that the last message on the subject was this one: > > http:/

Re: Packages on which Thunderbird functionality depends!

Stephen Gallagher (sgall...@redhat.com) said: > I'm not a Thunderbird maintainer, so I don't know how feasible this is, > but perhaps we could create a subpackage like > 'thunderbird-sound-support' that has the appropriate dependencies on it. > Then at least someone doing a yum search on thunderbi

Re: F-14 Branched report: 20100824 changes

Richard W.M. Jones (rjo...@redhat.com) said: > On Tue, Aug 24, 2010 at 04:42:17PM +, Branched Report wrote: > > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 > > This seems to be a warning about an older version than what's > currently in F14: > > http://koji.fedoraproject

Re: Bodhi updates

Stephen Gallagher (sgall...@redhat.com) said: > Bodhi updates can have multiple packages associated with a single update > as long as they are on different branches. Why this restriction? > > At least in the case of something like a security update, I would think > that it would be beneficial to

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Matthew Miller (mat...@mattdm.org) said: > How about: > > - If /etc/inittab exists and contains an initdefault line, the default > target will be set accordingly. > - any other non-comment, non-blank lines in /etc/inittab will be logged as > warnings. > > This leaves a migration path (ditch

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Miroslav Lichvar (mlich...@redhat.com) said: > On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: > > SERVICE HANDLING > > - Running 'chkconfig <(null)|on|off>' on a service managed by systemd > > will return the correct code/perform an approp

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Matthias Clasen (mcla...@redhat.com) said: > > BOOTUP > > - System boots successfully to GUI, when configured. > > - System boots successfully to text mode, when configured. > > - System properly handles being passed [1-5], 'single', 'S', 's', '-s', > > booting to the appropriate 'runlevel' (0 a

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

seth vidal (skvi...@fedoraproject.org) said: > > > You mean 'being passed on the kernel cmdline', I assume ? > > > Do we consider interactive boot essential (I think not) ? > > > Should mention something about forced fsck, maybe. > > > What about selinux relabeling ? > > > > I can't remember inte

Re: systemd and changes

Lennart Poettering (mzerq...@0pointer.de) said: > BTW, was there a written down policy on how to package Upstart > jobs/services? Yes. It was "Don't". (Specifically because issues like this weren't answered.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.o

Re: systemd and changes

Till Maas (opensou...@till.name) said: > I did not want to imply that PulseAudio is useless. I doubt that you > would have implemented it, if you did not have any use for it. Probably > a lot of people who bought their soundcard without considering to buy > one capable of hardware mixing will also

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Matthew Miller (mat...@mattdm.org) said: > > The intent is not to do so in the final release, AIUI. We're only > > keeping it around during pre-release, so that if we decide we need to > > fall back to upstart for final release, it's easy to do. As far as I > > know, the plan is to decide later (p

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

seth vidal (skvi...@fedoraproject.org) said: > > I'll test it in rhel6 in just a sec. > > Doesn't work in rhel6 :( If you hold down the key long enough at the right time, it sort of works. That's not really how we want to have it going forward, for obvious reasons. Bill -- devel mailing list d

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Lennart Poettering (mzerq...@0pointer.de) said: > > - init shall support a mechanism to re-exec itself to not cause dirty > > inodes on shutdown; initscripts will use this method on shutdown. > > This is bad. While we support this just fine I think it is a really bad > idea to reexec init at sh

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Chris Adams (cmad...@hiwaay.net) said: > > > This is a very big change. chkconfig has worked for a long, long time. Its > > > elegance and simplicity is one of the nice administrative features of Red > > > Hat based distributes. People like it. > > > > Yes, and they should continue to use it -- f

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

Lennart Poettering (mzerq...@0pointer.de) said: > Hmm, so this is about files that are deleted but still mapped by init, > and which can only be deleted when init stops referencing them, but that > is required to remount the fs r/o? Did I get this right? Correct. > I am not really convinced tha

Re: a note on order of arguements to systemctl command

Matthew Miller (mat...@mattdm.org) said: > I'm not saying that systemctl's syntax needs to be changed. I am saying, > however, that it's important to get the service command working with > systemctl so that people can use that instead. FYI, this is done in git, will be built today/tomorrow. Bill

Re: systemd or why will user fall away from fedora?

dr johnson (d...@www.uk.linux.org) said: > That would be all grand and spiffy if it were actually faster bootup. > > Bootchart here reports that systemd is 8 seconds *SLOWER* than upstart. No > idea why, but systemd just hangs for 8 seconds doing "nothing" that I can > see. No logs anywhere tha

Re: systemd v8 for rawhide?

Matthew Miller (mat...@mattdm.org) said: > On Thu, Aug 26, 2010 at 01:58:41AM +0200, Lennart Poettering wrote: > > Sorry for breaking this (again), but with this in place things should be > > at the appropriate places now for F14. > > What about for Rawhide, where I'm testing all of this? It look

Re: systemd v8 for rawhide?

Matthew Miller (mat...@mattdm.org) said: > > > What about for Rawhide, where I'm testing all of this? It looks like the > > > update was just built on F14. > > rawhide's currently inheriting systemd from F-14; it will get the new > > version when it gets to the stable tree. > > Really? I haven't

Re: If you cannot boot after installing systemd v8...

M A Young (m.a.yo...@durham.ac.uk) said: > > Note that version 8-2 waiting in bodhi should now handle upgrades from > > the alpha without problems. > > Does it cope with the shutdown problem? After I updated systemd to 8 I > couldn't shut the computer down, because (if I am remembering > correc

Re: systemd v8 for rawhide?

Matthew Miller (mat...@mattdm.org) said: > I'm willing to sacrifice my stable rawhide desktop system in the name of > getting Fedora more testing. Where should this discussion be had? FESCo. rel-eng will implement it (it's a one-line koji command), but the decision isn't really rel-eng's to make

Re: applied, non-theoretical use of systemd

Petrus de Calguarium (kwhisk...@gmail.com) said: > 1. I noticed that one can no longer (with v8-2) turn off the computer by > clicking the > 'turn off computer' button in KDE. I figured out, with help of recent > threads, that one > has to run: systemctl isolate poweroff.target. It worked. Is

Re: drop default MTA for Fedora 15

Chris Adams (cmad...@hiwaay.net) said: > Once upon a time, Garrett Holmstrom said: > > While it may be debatable what benefit one might get from removing it > > from the default install, can we at least remove MTAs from @core to help > > make things easier for appliance folks? One can still go

Re: applied, non-theoretical use of systemd

Petrus de Calguarium (kwhisk...@gmail.com) said: > So, the problem reduces to the Shut Off Computer button in KDE not working. OK. So the question is ... what does this button do? Invoke 'halt'? Invoke 'shutdown -h now'? Invoke ConsoleKit's Stop() method? Bill -- devel mailing list devel@lists.

Orphan packages retired for F-14 (and rawhide)

In accordance with the normal process, the following packages have been orphaned for Fedora 14 and rawhide. JSDoc bzr-gtk cdf crun django-authopenid drpython fedora-security-guide-en-US fet fish gg2 gnomecatalog gperiodic impressive kasablanca kflickr lazygal libmspack mapbender mediawiki-HNP medi

Re: fedora mission (was Re: systemd and changes)

Gerard Braad (gbr...@fedoraproject.org) said: > > aggressively > > I do not agree this strategy is wise or even the correct way. Certain > Fedora versions dropped hardware support. We can't dictate people wht > they can or can not do. I still know people who run old redhat > releases (5.x) as the

Re: fedora mission (was Re: systemd and changes)

Jeff Spaleta (jspal...@gmail.com) said: > On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman > wrote: > > Same goes for programs that scrape web pages (I'm thinking of gcstar but > > I'm sure there are others). If the page layout changes, the page scraper > > needs to be updated and that usually in

Re: fedora mission (was Re: systemd and changes)

Jeff Spaleta (jspal...@gmail.com) said: > On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham wrote: > > That's gross. (I realize you're blocked on the sites you rely on, but > > geez, can't you find sites with real APIs?) > > It is what it is. Though I

Re: Starting Java SIG

Stanislav Ochotnicky (sochotni...@redhat.com) said: > Agenda TBD, but for now the idea is to: > * go through Tasks listed on [1] Can non-SIG members add tasks? If we have a Java SIG, I'd like there to be some agreement on how to handle orphaned packages - right now, we've got about 30 java packa

Re: systemd and changes

Ben Boeckel (maths...@gmail.com) said: > I actually have a bug to file about that. The setting for NM_CONTROLLED > is still set even if NetworkManager isn't installed. It (or Ananconda) > should scrub the configs before installing the settings used during the > install. IMO, NM_CONTROLLED should

Re: Starting Java SIG

Stanislav Ochotnicky (sochotni...@redhat.com) said: > I believe most of them have already been taken (by me, Alexander > Kurtakov or someone else). But a list of the remainining would be nice > of course. Sure, here you go (obviously, some of this is more eclipse-focused rather than core java):

Re: Twitter support broken in Pino

Gianluca Sforna (gia...@gmail.com) said: > """ > Most FOSS client developers have simply chosen to embed their keys in > their source code with the hope that Twitter won't notice. I was about > to give up on Gwibber, but Canonical intervened on my behalf (special > thanks to Ken VanDine) and negot

Re: Pino & twitter

Alex Hudson (fed...@alexhudson.com) said: > https://bugzilla.redhat.com/show_bug.cgi?id=629192 > > I read through my archive and all I can see is a short discussion > proposing changing to gwibber. > > Is anyone actively trying to get an exception for pino a la gwibber? Or > should someone

Re: Pino & twitter

Arun SAG (saga...@gmail.com) said: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=629192 > > This bug is now a F14 blocker. Nomintated as one; it needs to go through the normal review process. And the fix for this may not invo

Re: Twitter support broken in Pino

Bill Nottingham (nott...@redhat.com) said: > The other option would be to switch to gwibber (which has been > un-desktop-couched in Fedora 14, so it theoretically won't bring in > nearly as much to the live image. So, actual testing - building a livecd with gwibber instead of pino

Re: Broadcom wifi drivers in F-14?

Ric Wheeler (rwhee...@redhat.com) said: > Can we use the firmware that they have for the existing broadcom wireless > driver? 'No' is what I've been told. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

Máirín Duffy (du...@fedoraproject.org) said: > Only 5 of the 9 FESCo members voted on this issue. If all 9 had voted, > even with the current 3 for / 2 against vote, systemd could easily have > enough votes for inclusion in F14. I have a couple of questions for you, > FESCo, since I honestly don't

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

drago01 (drag...@gmail.com) said: > The only real issues pointed out where lack of documentation and > system-config-service integration for native services. > Neither that we have with upstart so not really a regression and thus > warrant a reject. system services have not been migrated to upsta

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

Richard Hughes (hughsi...@gmail.com) said: > On 14 September 2010 23:01, Kevin Fenzi wrote: > > 21:33:35 The other 2 items I had were: > > 21:33:56 application installer issues > > 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968 > > 21:34:04 and > > 21:34:05 BuildIdBuild infrastr

Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)

Toshio Kuratomi (a.bad...@gmail.com) said: > Actually, iiuc, tomasz is talking about migrating sysv-init scripts to > systemd unit files. There is a blocker to doing that in F15 which is that > lennart, notting, and walters (that I remember) are against doing a mass > migration to unit files unti

Re: Linux and application installing

Arthur Pemberton (pem...@gmail.com) said: > > Can someone please elaborate a bit what pieces of information are really > > needed? The .desktop files as a whole? > > Wouldn't that require the tool to download every package just to get > the embedded information. Not if it's provided in the RPM h

Re: rawhide: upstart-sysvinit replacing systemd-sysvinit?

Matthew Miller (mat...@mattdm.org) said: > > I know, systemd got reverted for F-14. But unless I missed something, > > the plan is/was to keep it the default for F-15, and in rawhide. This > > means the package dependencies need to be different in rawhide please. > > Ditto. Will be fixed shortly

Re: ImageMagick soname bump for F14

Pavel Alexeev (aka Pahan-Hubbitus) (fo...@hubbitus.com.ru) said: > 16.09.2010 18:35, Orion Poplawski wrote: > > Do we really want to do this, especially for a FTBS issue presumably > > against F15? > > > > https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14 > > > Please excuse me

FYI: rawhide now requires systemd to boot by default

While upstart is still in the repo, the initscripts package now pulls in systemd and systemd-sysvinit. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

Jaroslav Reznik (jrez...@redhat.com) said: > It's not "some random day" - it's when you actually accept an update! It's > not > easy to estimate impact of update - but banning completely is not a solution > neither. We do not give nearly enough information in our updates for the user to make a

Re: docbook and glibc breakage?

Richard Hughes (hughsi...@gmail.com) said: > On 27 September 2010 19:58, Jaroslav Skarvada wrote: > > The character class must be inside bracketed expression, thus double > > brackets, please see man grep. The new grep-2.7 checks for this common > > fault: > > Right, but you could argue it's a

Re: x86_64 as Fedora's primary platform

Mike McGrath (mmcgr...@redhat.com) said: > > The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) > > continue to promote i686 installs over x86_64, the result being that > > only a third of fedora users are on x86_64. > > > > When will the Fedora project begin recommending x86_64

Re: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27

Michael Schwendt (mschwe...@gmail.com) said: > The following packages in the repository suffer from broken dependencies: > > == > The results in this summary consider Test Updates! > ==

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

Orcan Ogetbil (oget.fed...@gmail.com) said: > What I am trying to say is, a redesign of an interface _usually_ have > valid reasons. Those users who don't want their menu items moving > around want to live like automated machines. Forbidding such changes > promotes lazyness. > > If the update rem

Re: FAILED: BuildrootError: could not init mock buildroot

Neal Becker (ndbeck...@gmail.com) said: > FAILED: BuildrootError: could not init mock buildroot, mock exited with > status 30; see root.log for more information > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2506706 > > DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64

Re: FAILED: BuildrootError: could not init mock buildroot

Neal Becker (ndbeck...@gmail.com) said: > Thanks, what should I do next? Wait for the build repo to regenerate and then resubmit. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

Matthew Garrett (mj...@srcf.ucam.org) said: > > But I cannot list all the RHEL6 bugs. > > Why not? Strip partner names if necessary, but please make it possible > for people to decide whether a given update is a benefit to them. Well, he could list them in the bug field, but bodhi would elide t

Re: Ubuntu 10.10's installer looks rather nice

Matthias Clasen (mcla...@redhat.com) said: > That is certainly a big part of the problem. Anaconda does a _ton_ of > crap that only very few users care about. And keeping all these minority > features from falling apart is leaving you no time to polish the user > experience for the large majority

Re: Ubuntu 10.10's installer looks rather nice

Chris Lumens (clum...@redhat.com) said: > > - downloads updates in parallel too > > Package updates? 1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that pa

'milkymist' group in comps?

1) When you added this to F14/F15/EL6, you added a typo; this broke the F-14 branched compose and the EPEL updates push. *Please* verify your changes before pushing. 2) Aside from that... how does this merit a separate group? - We already have the electronic lab group - If we add a group each for

Re: 'milkymist' group in comps?

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: > Milkymist community builds and enhance their own toolchain (currently > not fully supported by Fedora). They have contributors who contribute > for tools such as gcc, qemu, other libraries (too software for FEL > goals). They have many patches th

Re: A comps group for the Design Suite

Ankur Sinha (sanjay.an...@gmail.com) said: > Since the design team is using a "design suite", would it be possible to > please create a group in comps for the purpose? It would make > installation of the design suite much easier for end users. > > The alternative is to create a meta package whic

Re: 'milkymist' group in comps?

Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: > > OK, that's clear. But I am worried that if we go down this road, we'll > > eventually have 20 or 30 groups for different SoCs for embedded use, > > and that seems like it will eventually be problematic. Is there some > > generic moniker that co

Re: 'milkymist' group in comps?

James Laska (jla...@redhat.com) said: > > 1) When you added this to F14/F15/EL6, you added a typo; this > > broke the F-14 branched compose and the EPEL updates push. > > *Please* verify your changes before pushing. > > How did the compose break? The comps file in git failed to parse, such that

Re: 'milkymist' group in comps?

James Laska (jla...@redhat.com) said: > > No, this is well before the tree gets to that state. It would need to > > be implemented as a check on git push. > > We attempt to validate comps in this test using the comps.rng in git > (see results logs posted earlier). I'm not tremendously familiar w

Re: A comps group for the Design Suite

Nicu Buculei (nicu_fed...@nicubunu.ro) said: > > There appears to be a lot of overlap here with the graphics group > > (and some with other groups). Perhaps it's best to just expand > > that group into a more full-fledged design suite? > > They are different things: the graphics group is the sum

Re: ethtool not in default system anymore?

Matthew Miller (mat...@mattdm.org) said: > On Tue, Oct 12, 2010 at 07:06:50PM -0500, Chris Adams wrote: > > It looks like up through F12, initscripts required ethtool (so it was > > definately installed by default). I see this in the RPM changelog: > > Still the case in RHEL5, FWIW. I'm assumin

Re: ethtool not in default system anymore?

Matthew Miller (mat...@mattdm.org) said: > On Wed, Oct 13, 2010 at 11:54:43AM -0400, Bill Nottingham wrote: > > > > It looks like up through F12, initscripts required ethtool (so it was > > > > definately installed by default). I see this in the RPM changelog: > >

Re: A comps group for the Design Suite

Nicu Buculei (nicu_fed...@nicubunu.ro) said: > >> Do you mean getting rid of the "Graphics" group and creating a new > >> "Design Suite" group? > >> > >> Is there a procedure for this? I mean like filing a ticket some place? > > > > I'm confused about the whole conversation. What exactly are you t

Re: rawhide report: 20101019 changes

Peter Jones (pjo...@redhat.com) said: > Because we haven't decided to merge those together. That's really the only > reason - there's no over-arching technical reason they need to be separate. > It's entirely a historical consideration. Somewhere in the recesses of my memory I remember a UNIX whe

Re: rawhide report: 20101019 changes

Cleaver, Japheth (jclea...@soe.sony.com) said: > A ton of this work was already done in initscripts through the use of the > /etc/sysconfig/readonly-root hooks. Isn't that already working well enough > now for that purpose, future systemd changes aside? Given that it involves bind-mounting *fil

  1   2   3   4   5   6   7   8   9   10   >