Re: F-13 Branched report: 20100409 changes
> gnome-shell-2.29.1-4.i686 requires gjs >= 0:0.6 > gnome-shell-2.29.1-4.i686 requires mutter >= 0:2.29.1 I've tagged the newer gjs/mutter builds to go through to stable for the next push. If the gnome-shell people ping me I can coordinate the updates if they think it would make it easier. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: geos soname bump in F-12 updates
On 04/10/2010 03:26 AM, Alex Lancaster wrote: > > Broken deps in releases is my number 1 peeve with Fedora and although > it's been actively worked on now, it's taken a very long time to do so. > It would be nice if Red Hat put some more engineering resources into > part of QA because it definitely overlaps into the infrastructure side > of things that "community" maintainers don't have access to Is there parts of Fedora infrastructure that non Red Hat people don't have any access to? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CD install delta from F-12 to F-13 current
On 04/09/2010 07:29 PM, Colin Walters wrote: > > The LiveCD is operating on the assumption that you have an internet > connection, you just want to download something relatively small to > get started, and can install new apps afterwards, whether that's > Abiword, OpenOffice, or whatever else. > Have you looked into the experience of a user trying to install Openoffice.org? Search for office or even openoffice and you will get dozens and dozens of packages and it is going to be very hard for a user to actually figure out what to pick to get the right apps. We need to fix that problem if we are not going to include even a word processor by default. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 xulrunner/firefox security update: need to rebuild dependents
On Sat, Apr 10, 2010 at 1:18 AM, Michel Alexandre Salim wrote: > The update, > > https://admin.fedoraproject.org/updates/xulrunner-1.9.2.3-1.fc13,firefox-3.6.3-1.fc13 > > was pushed out yesterday, however, other packages depending on > xulrunner are not rebuilt, and thus users with any of these installed > will not be able to install the updates. I'm not sure how to fix this, > beyond rebuilding the related packages and pushing the builds out > ASAP. > I've referred to the list of packages rebuilt for xulrunner/firefox for F-12, and rebuilt the necessary ones. Here are the list of updates that should be pushed out soon for F-13, so that the Firefox fix can be applied by all F-13 users: https://admin.fedoraproject.org/updates/galeon-2.0.7-27.fc13,gnome-python2-extras-2.25.3-17.fc13,mozvoikko-1.0-9.fc13.1 https://admin.fedoraproject.org/updates/Miro-3.0-1.fc13 Cheers, -- Michel Alexandre Salim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 16:19 -0800, Jeff Spaleta wrote: > Once a testing package is obsoleted by newer testing packages, why do > we need to keep those packages in bodhi's interface? To keep the contents of bodhi and the repository consistent at all times (subject to mirroring). As soon as the obsolete packages are unpushed from the repository, I have no objection to the update disappearing from bodhi. But this is really a separate issue from my main complaint, which was about old feedback appearing on the update page. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 16:31 -0800, Jeff Spaleta wrote: > I'll repeat. If a testing package is missing in bodhi...it means its > obsoleted by a newer one. This surprised me. I assumed updates were immutable and did not find any suggestion to the contrary until today. > Bodhi has a search interface which will let you find the newer ones. > The bugzilla tickets have the reference to the newer ones. > > Keeping the obsoleted packages in the bodhi interface would only > encourage you to add comments that are no longer relevant..no longer > useful to the maintainer. Yes its unfortunate that you installed an > outdated testing package. It happens...because testing revisions can > be quite fast paced when maintainers are on the ball and your local > mirror might not sync as fast as others so you are a step or three > behind the current conversation. > > And in this case, even if you found the package listing you were > looking for...any comment you would have added...any karma you would > have added..would just be wasted effort because the relevant > conversation had moved on to the newer package. And we certainly > don't want you to waste even more effort adding karma or a comment on > an obsoleted testing package. We want you using and commenting on the > testing packages that are most current. I understand that! Once I saw that my package was obsolete, I did not comment about the bugs. As you have said, feedback on obsolete packages is irrelevant. So it is confusing to see it on the page for the new update. I have to remember to start reading after the last "This update has been submitted". If the feedback log would be cleared upon resubmission, then the outcome would be indistinguishable from my proposal. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 4:20 PM, Matt McCutchen wrote: > There's another possible explanation for that policy: users who don't > participate in testing know that any update with an ID went to stable > and won't be distracted by references to IDs of testing updates in > various forums. But actually, I would prefer giving every update an ID. Clearly you would. And you'd burn through the ID numbering scheme with no real auditting benefit. I'll repeat. If a testing package is missing in bodhi...it means its obsoleted by a newer one. Bodhi has a search interface which will let you find the newer ones. The bugzilla tickets have the reference to the newer ones. Keeping the obsoleted packages in the bodhi interface would only encourage you to add comments that are no longer relevant..no longer useful to the maintainer. Yes its unfortunate that you installed an outdated testing package. It happens...because testing revisions can be quite fast paced when maintainers are on the ball and your local mirror might not sync as fast as others so you are a step or three behind the current conversation. And in this case, even if you found the package listing you were looking for...any comment you would have added...any karma you would have added..would just be wasted effort because the relevant conversation had moved on to the newer package. And we certainly don't want you to waste even more effort adding karma or a comment on an obsoleted testing package. We want you using and commenting on the testing packages that are most current. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 4:09 PM, Matt McCutchen wrote: > Better comparison: Bugzilla does not allow the content of an attachment > to be edited once it is submitted. Instead, people submit a new > attachment and obsolete the old one. Yes and koji keeps builds around to even when they aren't in a published tree. Doesn't make that behavior appropriate for what bodhi is trying to accomplish. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 16:10 -0800, Jeff Spaleta wrote: > On Fri, Apr 9, 2010 at 3:57 PM, Matt McCutchen wrote: > > The comparison to bugs is not valid. A bug is the same bug until it is > > fixed. An update consisting of different packages is a different > > update. > > What? We don't tag testing-updates with an ID. There's another possible explanation for that policy: users who don't participate in testing know that any update with an ID went to stable and won't be distracted by references to IDs of testing updates in various forums. But actually, I would prefer giving every update an ID. > Testing packages...are > implicitly in flux...there's no intention to provide an audit trail > via a mechanism like our ID nomenclature that tags a collection of > packages as an identifiable update when the packages are in testing. > I think your overly narrowing the flexibility inherent in the testing > process with your attempt to define a testing updating they way you > just did. Why is this "flexibility" a good thing? All it does is confuse testers like me. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen wrote: > It confuses the people who put in the effort to test your packages. I > updated to NetworkManager-0.8.0-4.git20100325.fc12.x86_64 and hit bugs > 576925 and 578141. I wanted to leave negative feedback on the update, > but I could not find one for that package version. See... that's where I would have stopped and asked myself the following: Self, why can't a find this package in bodhi it must be obsoleted by a newer version. Hey let me search via the web interface and see...yes..yes it was. I'll give it a day and let my mirrors sync up so I can get the latest _test_ update so I can provide feedback that will be useful. Good thinking self, you've earned a beer and a baconiase infused devilled egg. Once a testing package is obsoleted by newer testing packages, why do we need to keep those packages in bodhi's interface? Why do we need to duplicate this at all? If you can't find a package in bodhi any longer that means its no longer the latest available update and its no longer relevant to the discussion. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vga_switcharoo
On 04/09/2010 09:42 AM, Adam Jackson wrote: ignored from then on? > > Depends on your laptop. There seem to be two major varieties. > > One is where there's a BIOS option and you can pick. Your options will > typically be "integrated" (where we'll pick intel), "discrete" (where > we'll pick nouveau), or "OS switchable" (where you'll see both in lspci, > but the intel one will be the one that powers up on boot, so we'll pick > that one and power down the nv chip). > > The other is where there isn't a BIOS option, which acts like "OS > switchable". > > - ajax > Hi - laptop is Asus UL30vt - dont think there's a BIOS option .. sound good - thank you. Sounds like I may be able to try f12 rather than f13 which is what I had been assuming till now. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=573510#c2 > > How hard is it to use Bodhi properly? And then at the bottom of the bug report... there's newer packages...and newer links. There's no value in commenting on testing packages that are already superceded by newer testing packages. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 3:57 PM, Matt McCutchen wrote: > The comparison to bugs is not valid. A bug is the same bug until it is > fixed. An update consisting of different packages is a different > update. What? We don't tag testing-updates with an ID. Testing packages...are implicitly in flux...there's no intention to provide an audit trail via a mechanism like our ID nomenclature that tags a collection of packages as an identifiable update when the packages are in testing. I think your overly narrowing the flexibility inherent in the testing process with your attempt to define a testing updating they way you just did. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 19:57 -0400, Matt McCutchen wrote: > On Fri, 2010-04-09 at 15:32 -0800, Jeff Spaleta wrote: > > When someone is publishing updates and putting them into testing > > specifically to address known bugs... and they get the fix wrong in > > some way... I think its perfectly acceptable to reuse the same update > > notice for the testing packages in order to do a series of such test > > packages...letting intermediate test packages expire out of existence. > > > > You can make the same argument about confusion in the bugzilla > > comments to. Unless people take the time to state which version they > > are using in every comment if there are several intermediate attempts > > to fix a bug handed out to users..whether it be via bodhi or even just > > koji builds..bug reports get harder to follow...unless people state > > which versions they are testing. And I certainly wouldn't expect > > people to refile a new bug report each time a testing package is spun > > up just to keep the flow of commentary clear as to which version > > everyone was referring to when they were providing feedback. > > The comparison to bugs is not valid. A bug is the same bug until it is > fixed. An update consisting of different packages is a different > update. Better comparison: Bugzilla does not allow the content of an attachment to be edited once it is submitted. Instead, people submit a new attachment and obsolete the old one. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 16:26 -0700, Dan Williams wrote: > That would be nice. Though in the end, as long as the update has not > reached stable, is editing a testing update to fix regressions really > that big of a deal... It confuses the people who put in the effort to test your packages. I updated to NetworkManager-0.8.0-4.git20100325.fc12.x86_64 and hit bugs 576925 and 578141. I wanted to leave negative feedback on the update, but I could not find one for that package version. It took me a minute to realize that you had edited the update to contain newer packages. Edits also break the links that the update system posts on Bugzilla, such as the ones here: https://bugzilla.redhat.com/show_bug.cgi?id=573510#c2 How hard is it to use Bodhi properly? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, 2010-04-09 at 15:32 -0800, Jeff Spaleta wrote: > When someone is publishing updates and putting them into testing > specifically to address known bugs... and they get the fix wrong in > some way... I think its perfectly acceptable to reuse the same update > notice for the testing packages in order to do a series of such test > packages...letting intermediate test packages expire out of existence. > > You can make the same argument about confusion in the bugzilla > comments to. Unless people take the time to state which version they > are using in every comment if there are several intermediate attempts > to fix a bug handed out to users..whether it be via bodhi or even just > koji builds..bug reports get harder to follow...unless people state > which versions they are testing. And I certainly wouldn't expect > people to refile a new bug report each time a testing package is spun > up just to keep the flow of commentary clear as to which version > everyone was referring to when they were providing feedback. The comparison to bugs is not valid. A bug is the same bug until it is fixed. An update consisting of different packages is a different update. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Sat, 2010-04-10 at 01:20 +0200, Till Maas wrote: > There are nine bugs mentioned in the update. Do you really suggest that > the update submitter should always manually copy them from an old update > to a new update? Yes. What's so hard about that? It's a single copy and paste. > But it would be nice if Bodhi would support to create a new update using > an old update as a template, then editing the builds attached to an > update would probably not be needed. I entered a ticket: https://fedorahosted.org/bodhi/ticket/413 -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [SECURITY] Fedora 13 Update: xulrunner-1.9.2.3-1.fc13
Thank you for breaking every explicit gecko-libs dependency out there in a branch close to release. :/ You know gecko-libs provides/requires are there exactly to avoid this sort of thing, right? Both callion and xhorak can probably share some tips with you about doing xulrunner/firefox + deps upgrades en masse without bothering all dep maintainers. The fact that this got directly in stable without accounting the (avoidable) breakage is another different and unfortunate failure of process. I'll wait a bit for someone to do the responsible thing here... On Fri, 2010-04-09 at 04:02 +, upda...@fedoraproject.org wrote: > > Fedora Update Notification > FEDORA-2010-6204 > 2010-04-09 03:39:24 > > > Name: xulrunner > Product : Fedora 13 > Version : 1.9.2.3 > Release : 1.fc13 > URL : http://developer.mozilla.org/En/XULRunner > Summary : XUL Runtime for Gecko Applications > Description : > XULRunner provides the XUL Runtime environment for Gecko applications. > > > Update Information: > > Update to new upstream Firefox version 3.6.3, fixing a security issue detailed > in the upstream advisory:http://www.mozilla.org/security/known- > vulnerabilities/firefox36.html#firefox3.6.3 > > References: > > [ 1 ] Bug #577029 - CVE-2010-1121 firefox: arbitrary code execution via > memory corruption > https://bugzilla.redhat.com/show_bug.cgi?id=577029 > > > This update can be installed with the "yum" update program. Use > su -c 'yum update xulrunner' at the command line. > For more information, refer to "Managing Software with yum", > available at http://docs.fedoraproject.org/yum/. > > All packages are signed with the Fedora Project GPG key. More details on the > GPG keys used by the Fedora Project can be found at > https://fedoraproject.org/keys > > ___ > package-announce mailing list > package-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/package-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 9, 2010 at 3:10 PM, Matt McCutchen wrote: > Thoughts? Am I missing something? When someone is publishing updates and putting them into testing specifically to address known bugs... and they get the fix wrong in some way... I think its perfectly acceptable to reuse the same update notice for the testing packages in order to do a series of such test packages...letting intermediate test packages expire out of existence. You can make the same argument about confusion in the bugzilla comments to. Unless people take the time to state which version they are using in every comment if there are several intermediate attempts to fix a bug handed out to users..whether it be via bodhi or even just koji builds..bug reports get harder to follow...unless people state which versions they are testing. And I certainly wouldn't expect people to refile a new bug report each time a testing package is spun up just to keep the flow of commentary clear as to which version everyone was referring to when they were providing feedback. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Sat, 2010-04-10 at 01:20 +0200, Till Maas wrote: > On Fri, Apr 09, 2010 at 07:10:59PM -0400, Matt McCutchen wrote: > > The log of the following update shows that it was submitted five times, > > I assume with newer packages each time: > > > > https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-6.git20100408.fc12,ModemManager-0.3-9.git20100409.fc12 > > > > The top of the page now shows the newest package versions, but much of > > the feedback referred to older versions, which are not listed. IMO, > > this is a terribly confusing practice and Bodhi shouldn't allow it. New > > packages should be submitted in a new update so that feedback remains > > associated with the correct package versions. > > > > Thoughts? Am I missing something? > > There are nine bugs mentioned in the update. Do you really suggest that > the update submitter should always manually copy them from an old update > to a new update? > > But it would be nice if Bodhi would support to create a new update using > an old update as a template, then editing the builds attached to an > update would probably not be needed. That would be nice. Though in the end, as long as the update has not reached stable, is editing a testing update to fix regressions really that big of a deal... Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi allows resubmitting an update with different packages?!
On Fri, Apr 09, 2010 at 07:10:59PM -0400, Matt McCutchen wrote: > The log of the following update shows that it was submitted five times, > I assume with newer packages each time: > > https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-6.git20100408.fc12,ModemManager-0.3-9.git20100409.fc12 > > The top of the page now shows the newest package versions, but much of > the feedback referred to older versions, which are not listed. IMO, > this is a terribly confusing practice and Bodhi shouldn't allow it. New > packages should be submitted in a new update so that feedback remains > associated with the correct package versions. > > Thoughts? Am I missing something? There are nine bugs mentioned in the update. Do you really suggest that the update submitter should always manually copy them from an old update to a new update? But it would be nice if Bodhi would support to create a new update using an old update as a template, then editing the builds attached to an update would probably not be needed. Regards Till pgploWN8EJGjw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 xulrunner/firefox security update: need to rebuild dependents
The update, https://admin.fedoraproject.org/updates/xulrunner-1.9.2.3-1.fc13,firefox-3.6.3-1.fc13 was pushed out yesterday, however, other packages depending on xulrunner are not rebuilt, and thus users with any of these installed will not be able to install the updates. I'm not sure how to fix this, beyond rebuilding the related packages and pushing the builds out ASAP. The list below is produced using repoquery --alldeps --whatrequires xulrunner | sort -- I just updated and built Miro, but could someone who normally pushes out xulrunner update rebuild the rest? azureus-0:4.3.1.4-1.fc13.noarch eclipse-rcp-1:3.5.1-28.fc13.x86_64 eclipse-swt-1:3.5.1-28.fc13.x86_64 esc-0:1.1.0-10.fc12.x86_64 ethos-0:0.2.2-4.fc13.i686 ethos-0:0.2.2-4.fc13.x86_64 galeon-0:2.0.7-25.fc13.x86_64 galeon-0:2.0.7-26.fc13.x86_64 gecko-sharp2-0:0.13-13.fc13.x86_64 gjs-0:0.5-1.fc13.i686 gjs-0:0.5-1.fc13.x86_64 gjs-0:0.6-1.fc13.i686 gjs-0:0.6-1.fc13.x86_64 gnome-python2-gtkmozembed-0:2.25.3-16.fc13.x86_64 gnome-shell-0:2.28.1-0.1.20100128git.x86_64 gnome-web-photo-0:0.9-4.fc13.x86_64 hulahop-0:0.7.1-2.fc13.x86_64 java-1.6.0-openjdk-plugin-1:1.6.0.0-35.b17.fc13.x86_64 kazehakase-0:0.5.8-5.svn3870_trunk.fc13.x86_64 libproxy-mozjs-0:0.2.3-12.fc12.x86_64 libproxy-mozjs-0:0.3.1-4.fc13.x86_64 Miro-0:2.5.4-3.fc13.x86_64 mozilla-vlc-0:1.0.5-1.fc13.x86_64 mozvoikko-0:1.0-9.fc13.x86_64 openvrml-javascript-0:0.18.5-2.fc13.x86_64 perl-Gtk2-MozEmbed-0:0.08-6.fc13.12.x86_64 pytrainer-0:1.6.0.8-1.fc12.noarch ruby-gtkmozembed-0:0.19.3-5.fc13.x86_64 yelp-0:2.29.5-1.fc13.x86_64 -- Michel Alexandre Salim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi allows resubmitting an update with different packages?!
The log of the following update shows that it was submitted five times, I assume with newer packages each time: https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-6.git20100408.fc12,ModemManager-0.3-9.git20100409.fc12 The top of the page now shows the newest package versions, but much of the feedback referred to older versions, which are not listed. IMO, this is a terribly confusing practice and Bodhi shouldn't allow it. New packages should be submitted in a new update so that feedback remains associated with the correct package versions. Thoughts? Am I missing something? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: geos soname bump in F-12 updates
> "JS" == Jeff Spaleta writes: JS> On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski wrote: >> Looks like the geos update for F-12 bumped the soname: >> python-basemap-0:0.99.2-6.fc12.i686 JS> Sigh thanks for the heads up. I'll push a rebuild now. JS> -jef"Not to be picky, but it sure would be nice if there was some JS> way I could get a heads up about this sort of problem before a JS> soname change lands in updates-released so I can help as the basemap JS> package maintainer before unsuspecting users see breakage."spaleta Indeed, that's what I've been requesting for about 3 years now: https://fedorahosted.org/bodhi/ticket/79 i.e. a way of preventing pushes that break deps, and get warn maintainers of abi/soname bumps that they need to co-ordinate with all dependent packages to do a single co-ordinated push. Broken deps in releases is my number 1 peeve with Fedora and although it's been actively worked on now, it's taken a very long time to do so. It would be nice if Red Hat put some more engineering resources into part of QA because it definitely overlaps into the infrastructure side of things that "community" maintainers don't have access to. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fp.org
On Fri, 2010-04-09 at 16:17 -0500, Mike McGrath wrote: > On Fri, 9 Apr 2010, Mike Chambers wrote: > > > I burned the cd/dvd iso from that site and tried to boot with it to test > > doing an install with F13. But the problem is during boot, it wants to > > configure net0 for networking (wired built-in ethernet on computer) and > > fails. Is it suppose to do net0 or shouldn't it do eth0 or whatever? > > > > boot.fedoraproject.org is not actually booting Linux, it's booting a boot > loader to then boot Linux. I believe gpxe does refer to the network > interfaces netX. Were you having problems getting network to work? > Using DHCP or manual configuration? What network card? Never got the option to configure neither one as it failed to detect or whatever, can't remember exact wording. Network is builtin to the motherboard, an eMachine, via nvidia chipset motherboard. 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) Subsystem: Acer Incorporated [ALI] Device 0181 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 28 Memory at dbf7d000 (32-bit, non-prefetchable) [size=4K] I/O ports at d480 [size=8] Capabilities: Kernel driver in use: forcedeth Kernel modules: forcedeth Uses the forcedeth module for networking. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fp.org
On Fri, 9 Apr 2010, Mike Chambers wrote: > I burned the cd/dvd iso from that site and tried to boot with it to test > doing an install with F13. But the problem is during boot, it wants to > configure net0 for networking (wired built-in ethernet on computer) and > fails. Is it suppose to do net0 or shouldn't it do eth0 or whatever? > boot.fedoraproject.org is not actually booting Linux, it's booting a boot loader to then boot Linux. I believe gpxe does refer to the network interfaces netX. Were you having problems getting network to work? Using DHCP or manual configuration? What network card? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot.fp.org
I burned the cd/dvd iso from that site and tried to boot with it to test doing an install with F13. But the problem is during boot, it wants to configure net0 for networking (wired built-in ethernet on computer) and fails. Is it suppose to do net0 or shouldn't it do eth0 or whatever? -- Mike Chambers Madisonville, KY "Best lil town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: non-responsive maintainer: thomasvs
W dniu 09.04.2010 11:42, Thomas Vander Stichele pisze: > Hi, > >> Anyway, when it comes to the update, I'm happy to help. The total number >> of downstream packages dependent on twisted is 33. Should we expect >> breakage? Were there any API changes in twisted? > > Twisted in general is really good about keeping API, but they do > deprecate stuff. When they do so they typically make it clear with > DeprecationWarning's. I think it's mostly just a matter of testing the > applications using it by someone who knows the application. > > Just to be clear, we want to do this for F-13 only, right ? Or are you > thinking about upgrading F-12 too ? Well, F-13 for sure. Then, depending if hell breaks loose or not, we might think about other branches. >> I think we could start by dividing the list of the packages fifty-fifty, >> and check if they work at all. > > Do you have newly built twisted packages ? Not yet, but I can try to prepare them over the weekend. >> Then, I think it would be a good idea to >> bring maintainers into the loop since they actually know what the >> packages are supposed to do. The cleaned-up list follows below: > >> desktopcouch-0:0.6.3-3.fc12.noarch > > I didn't know this was in already; I'm going to assume they're based on > my packages from a few months ago but I'll check. > >> elisa-base-0:0.5.35-2.fc12.noarch >> elisa-plugins-bad-0:0.5.35-2.fc12.noarch >> elisa-plugins-ugly-0:0.5.35-1.fc11.noarch > > I can check these. > >> flumotion-0:0.6.1-1.fc12.x86_64 > > This is mine, I'll take this. > >> python-desktopcouch-0:0.6.3-3.fc12.noarch > > Same as desktopcouch above. > >> python-nevow-0:0.9.32-3.fc12.noarch > > nevow is another library - not sure if anything else depends on nevow. > > Thomas > Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo feature drop task
On Fri, Apr 09, 2010 at 10:58:02AM -0400, Bill Nottingham wrote: > Paul W. Frields (sticks...@gmail.com) said: > > I'd like to request that upon dropping features, FESCo notify the > > Marketing and Docs lists. Both of these teams maintain content that > > describe features for the upcoming release. In the event a feature is > > dropped, that content often needs to be changed by maintainers who may > > not be watching the devel@ list for FESCo notes. > > I don't see a problem with this. Is bouncing of the meeting notes > sufficient? A quick trim and a "Here's a list of changes to the feature list" would be helpful, but not required. Bouncing would work OK. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FYI: Taking ownership of orphaned inkscape in EPEL 4/5
Here's the notice that I'm taking ownership of orphaned inkscape in EPEL 4/5. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, Apr 09, 2010 at 01:42:54PM -0400, Adam Jackson wrote: > On Fri, 2010-04-09 at 17:54 +0100, Richard W.M. Jones wrote: > > On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote: > > > Depending on fixed paths seems like a bad idea. > > > > It depends on fixed paths because fixed paths are used to build the > > appliance. Therefore the dependencies tell us when something isn't > > going to work at runtime, instead of having the package silently > > broken by changes such as the one discussed in the OP. > > > > Now you may think that this is a bad way to build an appliance, but no > > one has come up with any better ideas for that so far. > > I thought I did suggest how to do this better: > > http://lists.fedoraproject.org/pipermail/devel/2010-February/131091.html > > Is there a reason why that won't work? It's not just libraries, the appliance gets built from many different types of files. To do this quickly, in 1/5th of a second, we start with a list of filenames[0] (wildcards, actually) that we want to pick up from the host system. We use a C program[1], that for speed reasons doesn't call out to any external programs, to generate the cpio-format initramfs. It turns out that binaries moving between /s?bin and /usr/s?bin, or libraries moving, are quite rare events. In the very few cases where there are libraries that frequently churn we've added exceptions for them. We added an exception for libntfs-3g.so more than a month ago, and that's been it since. Patches welcomed if you want to have a go at solving a very challenging problem better. Rich. [0] http://annexia.org/tmp/hostfiles.txt [1] http://git.annexia.org/?p=libguestfs.git;a=blob;f=appliance/libguestfs-supermin-helper.c;hb=HEAD -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Release Engineering meeting summary for 2010-04-09
Minutes:http://meetbot.fedoraproject.org/fedora- meeting/2010-04-09/fedora-releng.2010-04-09-17.03.html Minutes (text): http://meetbot.fedoraproject.org/fedora- meeting/2010-04-09/fedora-releng.2010-04-09-17.03.txt Log:http://meetbot.fedoraproject.org/fedora- meeting/2010-04-09/fedora-releng.2010-04-09-17.03.log.html Meeting summary --- * Roll Call (Oxf13, 17:04:08) * present is Oxf13, notting, and dgilmore (Oxf13, 17:06:18) * rdieter also present (Oxf13, 17:06:26) * BETA!!! (Oxf13, 17:06:35) * poelcat also present (Oxf13, 17:06:45) * RC5 went gold (Oxf13, 17:06:53) * Beta staged for mirrors (Oxf13, 17:07:04) * ACTION: Oxf13 to setup the torrents (Oxf13, 17:07:40) * ACTION: Oxf13 to coordinate with early torrent seeders (Oxf13, 17:07:49) * Updates pushes to F13 stable have recommenced (Oxf13, 17:08:05) * poelstra has finished export control filing w/ confirmation from legal (poelcat, 17:08:20) * SOPs (Oxf13, 17:12:00) * LINK: https://fedoraproject.org/wiki/Update_branched_Last_Known_Good (poelcat, 17:13:48) * LINK: https://fedoraproject.org/wiki/Fedora_package_announce_update (poelcat, 17:13:49) * Open Floor (Oxf13, 17:16:07) Meeting ended at 17:21:46 UTC. Action Items * Oxf13 to setup the torrents * Oxf13 to coordinate with early torrent seeders signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, 2010-04-09 at 17:54 +0100, Richard W.M. Jones wrote: > On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote: > > Depending on fixed paths seems like a bad idea. > > It depends on fixed paths because fixed paths are used to build the > appliance. Therefore the dependencies tell us when something isn't > going to work at runtime, instead of having the package silently > broken by changes such as the one discussed in the OP. > > Now you may think that this is a bad way to build an appliance, but no > one has come up with any better ideas for that so far. I thought I did suggest how to do this better: http://lists.fedoraproject.org/pipermail/devel/2010-February/131091.html Is there a reason why that won't work? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100409 changes
Compose started at Fri Apr 9 08:15:08 UTC 2010 Broken deps for i386 -- anaconda-14.3-1.fc14.i686 requires fcoe-utils >= 0:1.0.12-3.20100323git evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 gnome-shell-2.29.1-4.i686 requires gobject-introspection >= 0:0.6.9 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 perl-Gtk2-MozEmbed-0.08-6.fc14.12.i686 requires gecko-libs = 0:1.9.2.2 rss-glx-0.9.1.p-2.fc13.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires libMagickWand.so.2 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- anaconda-14.3-1.fc14.x86_64 requires fcoe-utils >= 0:1.0.12-3.20100323git evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcouchdb-glib-1.0.so.1()(64bit) gnome-shell-2.29.1-4.x86_64 requires gobject-introspection >= 0:0.6.9 hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) paperbox-0.4.4-2.fc12.x86_64 requires libtrackerclient.so.0()(64bit) perl-Gtk2-MozEmbed-0.08-6.fc14.12.x86_64 requires gecko-libs = 0:1.9.2.2 rss-glx-0.9.1.p-2.fc13.x86_64 requires libMagickCore.so.2()(64bit) rss-glx-0.9.1.p-2.fc13.x86_64 requires libMagickWand.so.2()(64bit) rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package OpenLP Open source Church presentation and lyrics projection application New package RBTools Tools for use with ReviewBoard New package bacula2 Backup client for bacula version 2 server New package garden An innovative old-school 2D vertical shoot-em-up New package gwaei A Japanese dictionary for Gnome New package lcgdm LHC Computing Grid Data Management New package perl-Compress-Raw-Zlib Low-Level Interface to zlib compression library New package rstp Rapid Spanning Tree User Space Daemon New package rubygem-parseconfig Ruby Configuration File Parser New package rubygem-xmpp4r-simple A simplified Jabber client library Removed package emotion Removed package epsilon Removed package ewl Removed package unicap Updated Packages: ModemManager-0.3-8.git20100408.fc14 --- * Thu Apr 08 2010 Dan Williams - 0.3-8.git20100408 - mbm: fix retrieval of current allowed mode - gsm: fix initialization issues with some devices (like Blackberries) NetworkManager-0.8.0-6.git20100408.fc14 --- * Thu Apr 08 2010 Dan Williams - 0.8-6.git20100408 - core: fix automatic WiFi connections on resume (rh #578141) * Thu Apr 08 2010 Dan Williams - 0.8-5.git20100408 - core: more flexible logging - core: fix crash with OLPC mesh devices after suspend - applet: updated translations - applet: show mobile broadband signal strength and technology in the icon - applet: fix continuous password requests for 802.1x connections (rh #576925) - applet: many updated translations abiword-2.8.3-2.fc14 * Thu Apr 08 2010 Marc Maurer - 1:2.8.3-2 - Update .desktop patch * Thu Apr 08 2010 Marc Maurer - 1:2.8.3-1 - New upstream release amarok-2.3.0-5.fc13 --- * Thu Mar 25 2010 Rex Dieter - 2.3.0-5 - fix mp3 support logic * Mon Mar 22 2010 Rex Dieter - 2.3.0-4 - rebuild (libgpod) * Mon Mar 22 2010 Rex Dieter - 2.3.0-3 - workaround info applet crasher (kde#227639,kde#229756) audacious-plugins-2.2-31.fc14 - * Thu Apr 08 2010 Michael Schwendt - 2.2-31 - Merge minor enhancements to the Status Icon patch to improve where it pops up with fast mouse movement. audtty-0.1.12-1.fc13 * Mon Mar 22 2010 Fabian Affolter - 0.1.12-1 - Removed compression of the man page - Added patch to fix DSOLinking (#564659) - Updated to new upstream version 0.1.12 avrdude-5.10-2.fc13 --- binutils-2.20.51.0.7-1.fc14 --- * Thu Apr 08 2010 Nick Clifton - 2.20.51.0.7-1 - Rebase on 2.20.51.0.7 tarball. - Delete redundant patches: binutils-2.20.51.0.2-add-needed.patch, binutils-2.20.51.0.2-do-not-set-ifunc.patch, binutils-2.20.51.0.2-enable-gold.patch, binutils-2.20.51.0.2-gas-expr.patch, binutils-2.20.51.0.2-ifunc-ld-s.patch, binutils-2.20.51.0.2-lwp.patch, binutils-2.20.51.0.2-ppc-hidden-plt-relocs.patch, binutils-2.20.51.0.2-x86-hash-table.patch, - Do not allow unique symbols to be bound locally. (PR ld/11434) - Add support for DWARF4 debug information. bison-2.4.2-2.fc14 -- * Thu Apr 08 2010 Petr Mac
Re: Moving libcrypto.so.* back to /lib
On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote: > So I got convinced that libcrypto.so.* should be moved back to /lib in > the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* > will stay in /usr/lib though. > > I will do that change in F14 packages. Till Maas asked me for this > change also in F13, but I am a little hesitant to do this as I am afraid > of regressions. Do you think this change could break things in F13? Will it break anaconda? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
Once upon a time, Richard W.M. Jones said:
> On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones said:
> > > libguestfs builds its appliance on the fly by concatenating together
> > > files [library files, binaries and data files] from the host. We
> > > express this requirement by mapping the location of those files into
> > > dependencies.
> >
> > Why can't it just depend on libcrypto.so., and then use the
> > linker to find the libraries at run-time?
>
> Because it's not linking with the library, it's copying it (along with
> many other non-library-like files) into an appliance.
So?
$ ldconfig -p | grep "libcrypto\.so\." | sed 's/.* => //'
/lib/libcrypto.so.8
Granted, it would take another line or two to handle multilib, but
that's it.
If you wanted to get fancy, you could use the C compiler (avoids having
to directly deal with multilib), but that requires -devel packages
installed. Even better would be to do this at RPM build time; link an
empty program against all of the libraries you need and just install the
resulting no-op binary somewhere. Then use "ldd" to find all the
dependencies (like the old mkinitrd script did).
$ echo 'main(){}' | cc -lcrypto -o findlib -x c -
$ ldd findlib
linux-vdso.so.1 => (0x7fffdab7c000)
libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x00354ae0)
libc.so.6 => /lib64/libc.so.6 (0x0038f220)
libdl.so.2 => /lib64/libdl.so.2 (0x0038f2a0)
libz.so.1 => /lib64/libz.so.1 (0x0038f320)
/lib64/ld-linux-x86-64.so.2 (0x0038f1e0)
You copy everything from the ldd output (except for the VDSO bit
obviously), which should make sure you get any dependencies (except for
dlopen() libraries, but that is actually hard to handle in an automated
way).
> Now you may think that this is a bad way to build an appliance, but no
> one has come up with any better ideas for that so far.
It isn't hard to find a shared library without hard-coding static paths.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > libguestfs builds its appliance on the fly by concatenating together > > files [library files, binaries and data files] from the host. We > > express this requirement by mapping the location of those files into > > dependencies. > > Why can't it just depend on libcrypto.so., and then use the > linker to find the libraries at run-time? Because it's not linking with the library, it's copying it (along with many other non-library-like files) into an appliance. > Depending on fixed paths seems like a bad idea. It depends on fixed paths because fixed paths are used to build the appliance. Therefore the dependencies tell us when something isn't going to work at runtime, instead of having the package silently broken by changes such as the one discussed in the OP. Now you may think that this is a bad way to build an appliance, but no one has come up with any better ideas for that so far. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo feature drop task
On Fri, 9 Apr 2010 08:12:48 -0400 "Paul W. Frields" wrote: > I'd like to request that upon dropping features, FESCo notify the > Marketing and Docs lists. Both of these teams maintain content that > describe features for the upcoming release. In the event a feature is > dropped, that content often needs to be changed by maintainers who may > not be watching the devel@ list for FESCo notes. > > Whether a feature is dropped at a milestone point or during the cycle, > this kind of notification would be very helpful for the many > volunteers working on those teams. Thanks for your consideration, and > for maintaining the feature process! Sounds like a good plan to me. I will try and see this is done moving forward. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, Apr 09, 2010 at 04:21:53PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote: > > So I got convinced that libcrypto.so.* should be moved back to /lib in > > the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* > > will stay in /usr/lib though. > > > > I will do that change in F14 packages. Till Maas asked me for this > > change also in F13, but I am a little hesitant to do this as I am afraid > > of regressions. Do you think this change could break things in F13? > > It'll temporarily break libguestfs, but a simple rebuild will fix it. > If you are a provenpackager, feel free to bump and rebuild it > yourself. > > libguestfs builds its appliance on the fly by concatenating together > files [library files, binaries and data files] from the host. We > express this requirement by mapping the location of those files into > dependencies. According to repoquery, libguestfs is the only package doing this: $ repoquery --releasever 13 --whatrequires /usr/lib\*/libcrypto.so\* libguestfs-1:1.0.85-2.fc13.4.i686 libguestfs-1:1.0.85-2.fc13.4.x86_64 You may need a patched repoquery to use the releasever commandline option on F12 or earlier, but for F13 it can be skipped anyhow. Regards Till pgpd84KikG1ea.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
Once upon a time, Richard W.M. Jones said: > libguestfs builds its appliance on the fly by concatenating together > files [library files, binaries and data files] from the host. We > express this requirement by mapping the location of those files into > dependencies. Why can't it just depend on libcrypto.so., and then use the linker to find the libraries at run-time? Depending on fixed paths seems like a bad idea. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, Apr 09, 2010 at 10:17:25AM +0200, Tomas Mraz wrote: > So I got convinced that libcrypto.so.* should be moved back to /lib in > the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* > will stay in /usr/lib though. > > I will do that change in F14 packages. Till Maas asked me for this > change also in F13, but I am a little hesitant to do this as I am afraid > of regressions. Do you think this change could break things in F13? It'll temporarily break libguestfs, but a simple rebuild will fix it. If you are a provenpackager, feel free to bump and rebuild it yourself. libguestfs builds its appliance on the fly by concatenating together files [library files, binaries and data files] from the host. We express this requirement by mapping the location of those files into dependencies. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo feature drop task
Paul W. Frields (sticks...@gmail.com) said: > I'd like to request that upon dropping features, FESCo notify the > Marketing and Docs lists. Both of these teams maintain content that > describe features for the upcoming release. In the event a feature is > dropped, that content often needs to be changed by maintainers who may > not be watching the devel@ list for FESCo notes. I don't see a problem with this. Is bouncing of the meeting notes sufficient? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CD install delta from F-12 to F-13 current
Hi, On Thu, Apr 8, 2010 at 11:42 PM, Rahul Sundaram wrote: > > How does it make sense to remove Abiword and add Planner? I assume a > project management tool is much less used than a word processor. Good question! So the story on this is that we have 3 different desktops: * LiveCD install * DVD/kickstart * Upgrade from F-(x-1) The goal is to reduce the delta between these and get to the point where we really have one default install, which might be subject to constraints based on space. Upgrades currently don't reflect removals or comps additions for example. There were additions to the LiveCD that weren't in the DVD/kickstart install such as Abiword. The LiveCD is operating on the assumption that you have an internet connection, you just want to download something relatively small to get started, and can install new apps afterwards, whether that's Abiword, OpenOffice, or whatever else. Now, I understand the desire to pack the LiveCD with as much Free Software as we can fit in the space constraints. However, we have to balance this with creating different desktop experiences. This said, I wouldn't really have a problem with adding Abiword back on the CD. The far bigger problem in my mind in terms of comps unification was the random removals that weren't for space reasons (acpid, nfs-utils). For that kind of thing we need to be fixing the base operating system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving libcrypto.so.* back to /lib
On Fri, 2010-04-09 at 10:17 +0200, Tomas Mraz wrote: > So I got convinced that libcrypto.so.* should be moved back to /lib in > the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* > will stay in /usr/lib though. > > I will do that change in F14 packages. Till Maas asked me for this > change also in F13, but I am a little hesitant to do this as I am afraid > of regressions. Do you think this change could break things in F13? It shouldn't. DSO lookup is by soname, not by path. The only thing that could break is if a package had a file dependency on the old path. Which is a ragingly stupid thing to do, so anyone it does break deserves it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vga_switcharoo
On Thu, 2010-04-08 at 20:40 -0400, Mail Lists wrote: > On 04/08/2010 08:56 AM, Matthew Garrett wrote: > > nouveau has powered down the nvidia if it's not in use for some time > > now. > > > > Ah that is good news ... which kernel are we speaking about here and > are you saying this will happen even without vga_switcharoo ? Pretty sure this was in F12. And yes, doesn't depend on the switcher code at all. > Do I assume then when I install f12 (f12?) that the intel wins the race > to fedora's display heart and nvidia will be powered down ... and > ignored from then on? Depends on your laptop. There seem to be two major varieties. One is where there's a BIOS option and you can pick. Your options will typically be "integrated" (where we'll pick intel), "discrete" (where we'll pick nouveau), or "OS switchable" (where you'll see both in lspci, but the intel one will be the one that powers up on boot, so we'll pick that one and power down the nv chip). The other is where there isn't a BIOS option, which acts like "OS switchable". - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libsoup (Re: PolicyKit-authentication-agents in Fedora)
In article you wrote: >> libsoup itself is a nice thing because it enables asynchronous HTTP >> access. But our libsoup package ic compiled against GConf, so it's >> rather GNOME than GTK. > > since lx* triggered this thread, > > I guess their (light desktops users) preferred browser is midori a > webkitgtk one, and that depends on libsoup which is compiled in fedora > with GConf support. > > so it seems that GConf is almost a must in fedora even when using lxde > or xfce I have rebuilds of both libsoup and webkitgtk to not include these dependencies (webkitgtk goes without geoclue). Before I publish the repo URL/config for yum, I'd be interested to see how much interest it would be for me to maintain them and which release/arch combos to support. It's just patches on the .spec file from Fedora and a rebuild and P/O over the dependency chained one. As for a lightweight browser, I'd recommend uzbl[1] for those looking for slim applications. The default configuration/scripts assume zenity and pygtk which can be a little big, but Xdialog works just as well I've found. --Ben pgp8aUCjjzvYW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
Quoting Radek Vokál (radekvo...@gmail.com): > On 04/08/2010 10:49 PM, Steve Grubb wrote: > > On Tuesday 06 April 2010 04:47:22 pm Radek Vokál wrote: > >>I need few suggestions about this .. > >> https://blog.wireshark.org/2010/02/running-wireshark-as-you/ .. Gerald > >> Combs, the upstream maintainer of wireshark, suggests to use > >> capabilities instead of consolehelper+root privileges for > >> dumpcap/wireshark. It makes whole lot of sense, so I've looked if other > >> apps in Fedora are already using it and I haven't found any. Honestly > >> I'm not sure about right way to use them. The idea is to add something > >> like following to %post > >> > >> # groupadd -g wireshark > >> # chgrp wireshark /usr/bin/dumpcap > >> # setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap > >> # setcap cap_net_raw,cap_net_admin+eip /usr/bin/tshark > >> > >> Suggestions? Ideas? Spec file patches? > > > > rpm supposedly has native support for capabilities. That would mean that you > > don't need to call setcap. > > > > -Steve > > > > Are there any docs for that? I haven't found any so far. Thread starting here: http://www.mail-archive.com/rpm-ma...@lists.rpm.org/msg01015.html -serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo feature drop task
I'd like to request that upon dropping features, FESCo notify the Marketing and Docs lists. Both of these teams maintain content that describe features for the upcoming release. In the event a feature is dropped, that content often needs to be changed by maintainers who may not be watching the devel@ list for FESCo notes. Whether a feature is dropped at a milestone point or during the cycle, this kind of notification would be very helpful for the many volunteers working on those teams. Thanks for your consideration, and for maintaining the feature process! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libsoup (Re: PolicyKit-authentication-agents in Fedora)
> libsoup itself is a nice thing because it enables asynchronous HTTP > access. But our libsoup package ic compiled against GConf, so it's > rather GNOME than GTK. since lx* triggered this thread, I guess their (light desktops users) preferred browser is midori a webkitgtk one, and that depends on libsoup which is compiled in fedora with GConf support. so it seems that GConf is almost a must in fedora even when using lxde or xfce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from
Denis Leroy wrote: > After maintaining the gtkmm stack for 7 years or so, as well as a number > of other packages, I am now orphaning the remaining packages that were > still under my care. I do find that contributing to Fedora is not as fun > as it once was, and as such find it more and more difficult to commit > the time and care these packages deserve. > > The following are orphaned in the pkg database: > > The main gtkmm stack (ideally should be owned by the same person, some > C++ experience is helpful but not striclty required): > > glibmm24 > pangomm > gtkmm24 > gconfmm26 > gnome-vfsmm26 > libgnomemm26 > libgnomeuimm26 > libglademm24 > libgnomecanvasmm26 > > Others: > > libsigc++ > libsigc++20 > bakery > compat-libgda > distcc > Taken. And thanks, and best of luck, Denis. > glom > goocanvasmm > gstreamermm > gtksourceviewmm > libburn > libgda > libgnomedb > libnotifymm > libpanelappletmm > libxml++ > wp_tray > > > -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libsoup (Re: PolicyKit-authentication-agents in Fedora)
Am Freitag, den 09.04.2010, 14:38 +0300 schrieb Muayyad AlSadi: > > It's not only GConf but also other things like gnome-keyring, **libsoup**, > > sorry for this off-topic, > is libsoup a light gtk library, or a deeply integrated gnome library > I'm asking this because webkitgtk depends on it > rpm -qR webkitgtk | grep libsoup > libsoup-2.4.so.1 libsoup itself is a nice thing because it enables asynchronous HTTP access. But our libsoup package ic compiled against GConf, so it's rather GNOME than GTK. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit-authentication-agents in Fedora
> It's not only GConf but also other things like gnome-keyring, **libsoup**, sorry for this off-topic, is libsoup a light gtk library, or a deeply integrated gnome library I'm asking this because webkitgtk depends on it rpm -qR webkitgtk | grep libsoup libsoup-2.4.so.1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from Fedora packaging
Am Freitag, den 09.04.2010, 09:40 +0200 schrieb Nikola Pajkovsky: > On 04/09/2010 01:03 AM, Denis Leroy wrote: > > libburn > > > Taken. Since libburn is a dependency of Xfburn I'd like to invite you to become co-maintainer of it, so you can do the necessary rebuilds after updating libburn. I can in turn co-maintain libburn. This is how Denis and me worked together and it worked pretty well for us. I'd like to take the opportunity to thank Denis for all his efforts. Sad to see him leave. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: non-responsive maintainer: thomasvs
Hi, > Anyway, when it comes to the update, I'm happy to help. The total number > of downstream packages dependent on twisted is 33. Should we expect > breakage? Were there any API changes in twisted? Twisted in general is really good about keeping API, but they do deprecate stuff. When they do so they typically make it clear with DeprecationWarning's. I think it's mostly just a matter of testing the applications using it by someone who knows the application. Just to be clear, we want to do this for F-13 only, right ? Or are you thinking about upgrading F-12 too ? > I think we could start by dividing the list of the packages fifty-fifty, > and check if they work at all. Do you have newly built twisted packages ? > Then, I think it would be a good idea to > bring maintainers into the loop since they actually know what the > packages are supposed to do. The cleaned-up list follows below: > desktopcouch-0:0.6.3-3.fc12.noarch I didn't know this was in already; I'm going to assume they're based on my packages from a few months ago but I'll check. > elisa-base-0:0.5.35-2.fc12.noarch > elisa-plugins-bad-0:0.5.35-2.fc12.noarch > elisa-plugins-ugly-0:0.5.35-1.fc11.noarch I can check these. > flumotion-0:0.6.1-1.fc12.x86_64 This is mine, I'll take this. > python-desktopcouch-0:0.6.3-3.fc12.noarch Same as desktopcouch above. > python-nevow-0:0.9.32-3.fc12.noarch nevow is another library - not sure if anything else depends on nevow. Thomas -- You either earn your keep or you don't get kept. -- Moovida - future TV today ! http://www.moovida.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning manedit
Hello, all: I've just released the ownership of manedit since I don't use this anymore. If you are interested in maintaining manedit, please take the ownership of this package. https://admin.fedoraproject.org/pkgdb/acls/name/manedit http://freshmeat.net/projects/manedit/ Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from Fedora packaging
@Dennis: i appreciated your work on the Gtkmm stack. took : gtksourceviewmm;, libnotifymm, gstreamermm, libxml++, libgda, bakery, glom btw, libgnomedb is dead package as it's abandonned by upstream and most of it will be integrated in libgda-ui 4.2 Co-maintainers are welcome H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning redet
I would like to orphan redet [1] and redet-doc [2] since I don't use them. I will release them in PackageDB if someone is interested. Happy hacking, Debarshi [1] https://admin.fedoraproject.org/pkgdb/acls/name/redet [2] https://admin.fedoraproject.org/pkgdb/acls/name/redet-doc -- "Nearly all men can stand adversity, but if you want to test a man's character, give him power." -- Abraham Lincoln -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two new applications to package and add to Fedora
Hi, On 04/07/2010 02:34 PM, Damian Brasher wrote: > Hi List > > I'm new to this list, a brief intro - I currently work for the University > of Southampton (ECS) as a systems administrator / programmer and also run > my small development company, Interlinux Ltd. See LinkedIn > http://www.linkedin.com/in/dbrasher > > 'to the chase: > > I have coded two projects (beta1 and beta2) that I would like to package > and add to Fedora (extras?). I hope this archive this over several weeks > and I (my company) will be the long-term maintainer. > > 1) DIASER (2005-2010) - Long-term geo-redundancy archiving software [for > the cloud] written in Perl. > > https://sourceforge.net/projects/diaser/ > > 2) DSI (2001-2010) - Pristine (code) Space Invaders clone written in C and > recently revived for fun and to support DIASER. > You will want to rename that, at least for Fedora, but since you are upstream you may want to give it a different name upstream too, see: https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from Fedora packaging
For the moment I am picking up the following because these are the ones I use and understand best: glibmm24 gtkmm24 libsigc++20 Co-mainitainers welcome. Happy hacking, Debarshi -- "Nearly all men can stand adversity, but if you want to test a man's character, give him power." -- Abraham Lincoln -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit-authentication-agents in Fedora
On Friday 09 April 2010 02:27:59 Christoph Wickert wrote: > Am Donnerstag, den 08.04.2010, 17:01 -0700 schrieb Jesse Keating: > > Part of the solution here is to not rely entirely on yum depsolving, and > > instead add explicitly which polkit you want in the comps group, so that > > a provider is already selected. > > Yes, I already wrote that in my very first mail. Additionally one core > component of each desktop (e.g. gnome-session, kdebase-workspace, > xfce4-session and lxsession) should also explicitly require the agent We explicitly require polkit-kde from F-12 in combination with polkit-1 (in kdebase-workspace). F-11 still require PolicyKit-authentication-agent. Library/desktop purist, don't read it :D: For non Gnome/KDE environments it could be nice to have something less bloated but first criteria should be quality of implementation and that's where -gnome one wins (I don't know how mature is lxde one) - it's developed by polkit developers. We are on slip while trying to catch current development. Jaroslav > > This is what we should do for critpath as well, mark the gnome policy > > kit explicitly as part of the critpath. > > +1 > > Regards, > Christoph -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Moving libcrypto.so.* back to /lib
So I got convinced that libcrypto.so.* should be moved back to /lib in the https://bugzilla.redhat.com/show_bug.cgi?id=559953 The libssl.so.* will stay in /usr/lib though. I will do that change in F14 packages. Till Maas asked me for this change also in F13, but I am a little hesitant to do this as I am afraid of regressions. Do you think this change could break things in F13? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from Fedora packaging
On 04/09/2010 01:03 AM, Denis Leroy wrote: > libburn > Taken. -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
On 04/08/2010 10:49 PM, Steve Grubb wrote: > On Tuesday 06 April 2010 04:47:22 pm Radek Vokál wrote: >>I need few suggestions about this .. >> https://blog.wireshark.org/2010/02/running-wireshark-as-you/ .. Gerald >> Combs, the upstream maintainer of wireshark, suggests to use >> capabilities instead of consolehelper+root privileges for >> dumpcap/wireshark. It makes whole lot of sense, so I've looked if other >> apps in Fedora are already using it and I haven't found any. Honestly >> I'm not sure about right way to use them. The idea is to add something >> like following to %post >> >> # groupadd -g wireshark >> # chgrp wireshark /usr/bin/dumpcap >> # setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap >> # setcap cap_net_raw,cap_net_admin+eip /usr/bin/tshark >> >> Suggestions? Ideas? Spec file patches? > > rpm supposedly has native support for capabilities. That would mean that you > don't need to call setcap. > > -Steve > Are there any docs for that? I haven't found any so far. Radek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CD install delta from F-12 to F-13 current
> A quick report on the current delta between F-12 and F-13's CD <> > The full report is attached. Apparently the sections were sorted numerically by change in byte size. It would have been helpful to say so explicitly, and to emphasize that fact by aligning the numerical change in a tabulated column that was placed to the left of the package name. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
