how to determain those no longer required packages
I'm reading APT and YUM source codes recently, and met the following question: for class apt.package.Package, there are a function "isAutoRemovable", which means: http://apt.alioth.debian.org/python-apt-doc/apt/package.html?highlight=isautoremovable#apt.package.Package.isAutoRemovable Return True if the package is no longer required. If the package has been installed automatically as a dependency of another package, and if no packages depend on it anymore, the package is no longer required. Do YUM codes have the same function as 'isAutoRemovable' feature?? or how to determine such no longer required rpm packages using yum CLIs? Thanks, Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firefox addon for Fedora-pkgdb search
Dne 28.8.2009 23:33, Adam Miller napsal(a): On Thu, Aug 27, 2009 at 5:16 PM, Milos Jakubicek wrote: I'm very very sorry for this as I'm sure that I've partially invalidated my/your/both work, which is just bad:( Could you try to merge my and your work somehow? I'd be glad if you would do this and keep an eye of this feature so that it will land on pkgdb's pages sooner or later. I honestly don't see how I can merge the two its just a little xml file and ours are actually using different versions of the OpenSearch spec and I'm using pkgdb's search function while you're using the suggest function (granted I don't know what those two do on the back end so it might be the same). Well, imo the point is that we should try to enable the users to get to the desired package info page (from which they can access builds/updates/sources/bugs) in shortest possible time, therefore I've implemented the suggestions (which, if running on a reliable box, provide an instant way how to ensure one type the package name properly). Otherwise, as I described: entering a nonexisting package results into search, otherwise you'll get to the package page in pkgdb. Regards, Milos -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 27 Aug 2009, Matthew Woehlke wrote: Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). This is a real shame. One of the selling points of Linux is that you *don't* need to reboot for every little upgrade (unlike a certain other OS I shan't name). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't "service network restart" and "service dhcpd restart" in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, please. Though maybe with prompting; we shouldn't go restarting possibly-critical services without good warning. As David said, for dhcpd, 'service restart dhcpd' should be fine. For dhclient I would question why /any/ restart is needed. If your dhcp connection is currently established, is dhclient even running? And even if it is, what benefit do you get cycling the interface /now/, if the new dhclient takes over whenever the interface cycles anyway? This is a limitation of the updates system, at least to my knowledge. I submit updates based on package builds, but cannot set things like 'suggests reboot' on a per subpackage basis. Since dhclient is a subpackage of dhcp, and I flag needs reboot for the dhcp package, dhclient inherits that. But I explained in the previous reply how to cycle the interface using either the network service or NetworkManager. I still view this as something more technical users will be familiar with and for the average user, simply rebooting the system is the easiest method. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqYYQ0ACgkQ5hsjjIy1VkmmAQCgyTlzwMUifVgU4xYYdKbeCZJS A9UAoKO1pnjuM82JLy3+gYxL8T0/Sxgn =O/sd -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
> Message du 27/08/09 16:38 > De : "Jindrich Novy" > A : fedora-devel-list@redhat.com > Copie à : fedora-fonts-l...@redhat.com, tcall...@redhat.com > Objet : Re: another spin of TeX Live 2009 packages > > > On Wed, Aug 26, 2009 at 03:02:18PM +0200, Jindrich Novy wrote: > > Hi, > > > > first off, thanks many people who sent me RFE and bugfix > > proposals. I've tried to fix most of them in the current package set > > in the testing repository: > > > > rpm -i > > http://jnovy.fedorapeople.org/texlive/texlive-release-2009-0.1.fc11.noarch.rpm > > Thanks a lot for continuing to work on sanitizing TEX packaging. I ll > > examine your font packages as soon as I can (probably mid september). At > > first look, it seems you re duplicating many existing packages because CTAN > > redistributes stuff it s not the actual upstream of. So IMHO you wont > > escape a package per package check for fonts (TEX specific stuff tends to > > be released at CPAN first, but that s not the case for generic resources > > like fonts) In the meanwhile please do check you re actually using the fontpackages-devel macros in your packages an try to run the audit script available there against your repo Regards -- Nicolas Mailhot Alt. 3790 m Créez votre adresse électronique prenom@laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
> 1. Since Fedora 4, Fedora doesn't support installing software from DVD "out > of the box". Fedora 8 is an exception here. Currently, it seems that the work > is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't > seem to need much work but unfortunately it seems that it is stopped. I think > requesting a small collaboration between the feature owner, PolicyKit and/or > GIO people is not too much. I have done that part 100% for yumex nextgen and it will work in F12 since the patch was accepted upstream (you just need to copy media.repo from the DVD to /etc/yum.repos.d/) but the PK implementation got a problem either we modify the file /usr/share/PolicyKit/policy/org.freedesktop.devicekit.disks.policy to grant root to access org.freedesktop.devicekit.disks.filesystem-mount or wait till the PK API is rewritten so that mounting is done in the non-privileged console user part and since the second option can't be done in F12 time and the first option is needs a policy change [which I can't change] you won't have this feature in F12 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Fri, 2009-08-28 at 23:53 +0200, Kevin Kofler wrote: > David Zeuthen wrote: > > We announced that this would happen long ago. And, FWIW, it was approved > > long ago by FESCO too. > > You (well, whoever from your team was there to talk about the feature) > promised to FESCo that PolicyKit 0.9 and 1.0 can coexist and that 0.9 can > stay around if somebody signs up to maintain the compat package. I can dig > up the log if you don't believe me. > > > So, sorry, but we will obsolete the old packages > > Obsoleting packages which somebody still wants to maintain is extremely bad > form. Especially if it's a library which is needed by other packages. Keeping dead stuff in the distro may be easier for the individual package maintainers, but the duplication of functionality and the confusion that is causes is a high price to pay for the distro as a whole. > > Indeed. And in this transition period where we've been shipping both set > > of packages, there has been a lot of confusion. I've witnessed that > > myself. We just don't want that to happen in a released OS. > > The compat lib would only ship on the KDE spin. It would certainly also ship on the DVD, alongside the polkit1 packages. And as we've learned, an unfortunate percentage of people prefers the DVD for whatever reasons. Anyway, this all seems to be a somewhat moot discussion, trying to nail us down on a 'promise to keep the old stuff around', when there already is a patch that can solve the whole dilemma. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Sat, Aug 29, 2009 at 12:26 AM, drago01 wrote: > On Sat, Aug 29, 2009 at 12:19 AM, Colin Walters wrote: >> On Fri, Aug 28, 2009 at 5:49 PM, drago01 wrote: >>> On Fri, Aug 28, 2009 at 11:31 PM, Colin Walters wrote: Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? >>> >>> No, you want Obsoletes: bug-buddy, so yum/anaconda will replace >>> bug-buddy with abrt. >> >> Ok, thanks. Should then the current >> >> %package addon-kerneloops >> [...] >> Conflicts: kerneloops >> >> Also be changed to Obsoletes? > > Yes a conflict will just prevent it from getting installed when > kerneloops is installed. (which is kinda useless and not what was > intended here) > Obsoleting a specific version would be even better: > Obsoletes: kerneloops <= lastestversion But do we even want to drop kerneloops from the distro? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Sat, Aug 29, 2009 at 12:19 AM, Colin Walters wrote: > On Fri, Aug 28, 2009 at 5:49 PM, drago01 wrote: >> On Fri, Aug 28, 2009 at 11:31 PM, Colin Walters wrote: >>> Hi internets, >>> >>> I was looking at the current state of ABRT (I tested on F11). The >>> core capturing seems to work well. In brief, I propose to apply the >>> (attached) patch to comps-f12.xml.in. >>> >>> For upgrades, we'll need to add a Conflicts: bug-buddy, correct? >> >> No, you want Obsoletes: bug-buddy, so yum/anaconda will replace >> bug-buddy with abrt. > > Ok, thanks. Should then the current > > %package addon-kerneloops > [...] > Conflicts: kerneloops > > Also be changed to Obsoletes? Yes a conflict will just prevent it from getting installed when kerneloops is installed. (which is kinda useless and not what was intended here) Obsoleting a specific version would be even better: Obsoletes: kerneloops <= lastestversion -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Fri, Aug 28, 2009 at 5:49 PM, drago01 wrote: > On Fri, Aug 28, 2009 at 11:31 PM, Colin Walters wrote: >> Hi internets, >> >> I was looking at the current state of ABRT (I tested on F11). The >> core capturing seems to work well. In brief, I propose to apply the >> (attached) patch to comps-f12.xml.in. >> >> For upgrades, we'll need to add a Conflicts: bug-buddy, correct? > > No, you want Obsoletes: bug-buddy, so yum/anaconda will replace > bug-buddy with abrt. Ok, thanks. Should then the current %package addon-kerneloops [...] Conflicts: kerneloops Also be changed to Obsoletes? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
David Zeuthen wrote: > We announced that this would happen long ago. And, FWIW, it was approved > long ago by FESCO too. You (well, whoever from your team was there to talk about the feature) promised to FESCo that PolicyKit 0.9 and 1.0 can coexist and that 0.9 can stay around if somebody signs up to maintain the compat package. I can dig up the log if you don't believe me. > So, sorry, but we will obsolete the old packages Obsoleting packages which somebody still wants to maintain is extremely bad form. Especially if it's a library which is needed by other packages. > Indeed. And in this transition period where we've been shipping both set > of packages, there has been a lot of confusion. I've witnessed that > myself. We just don't want that to happen in a released OS. The compat lib would only ship on the KDE spin. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Fri, Aug 28, 2009 at 11:31 PM, Colin Walters wrote: > Hi internets, > > I was looking at the current state of ABRT (I tested on F11). The > core capturing seems to work well. In brief, I propose to apply the > (attached) patch to comps-f12.xml.in. > > For upgrades, we'll need to add a Conflicts: bug-buddy, correct? No, you want Obsoletes: bug-buddy, so yum/anaconda will replace bug-buddy with abrt. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firefox addon for Fedora-pkgdb search
On Thu, Aug 27, 2009 at 5:16 PM, Milos Jakubicek wrote: > I'm very very sorry for this as I'm sure that I've partially invalidated > my/your/both work, which is just bad:( > > Could you try to merge my and your work somehow? I'd be glad if you would do > this and keep an eye of this feature so that it will land on pkgdb's pages > sooner or later. I honestly don't see how I can merge the two its just a little xml file and ours are actually using different versions of the OpenSearch spec and I'm using pkgdb's search function while you're using the suggest function (granted I don't know what those two do on the back end so it might be the same). -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ABRT for f12 status
Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? ABRT is a big step forward from bug-buddy in that the crashes are stored sanely in a persistent manner, and it captures crashes in the core OS as well. Concerns: == Getting the Data == My main concern is ensuring that we get the data reliably to the eyes of Fedora developers. The current abrt-desktop virtual package[1] depends on abrt-plugin-bugzilla, which has a default BugzillaURL = https://bugzilla.redhat.com/. To be able to successfully submit data, you have to go to: Edit->Preferences, click Bugzilla, click "Configure Plugin" and enter a username/password; there's no provision for creating a Bugzilla account here. I suggest that Fedora infrastructure instead provide a service where the data in /var/cache/abrt can be submitted via HTTP post as a tarball, anonymously. Then the crash UI can be just "A problem has been detected in [whatever]. Do you want to send this data to Fedora? [Submit] [ See Data ] [ Cancel ]": On the server side then we can later write tools to analyze the crash data (reuse kerneloops? socorro? write custom code?). Secondary concerns: == kernel/GNOME developer feedback == We should ensure Fedora is still sending crashes from the kernel to kerneloops.org; does ABRT handle this? Also, ideally on the server side there would be a web page where a GNOME developer (hi!) could go to http://crashes.fedoraproject.org/package/gnome-panel and see a list of crashes sorted by number. == Privacy == ABRT needs some explanation that the crash data may contain private information. We may need to restrict visibility of the data to only Fedora account holders by default or the like, to at least prevent any future effects like a Slashdot link to a trace where the submitter was viewing pornography or the like (yes, this happened with GNOME bugzilla). But in general, thanks for the work on ABRT, we should get this in by default for the F12 desktop target. [1] For RPM/dependency graph people: Why does this exist? I thought virtual packages were disallowed? Should just be in comps I think. Index: comps-f12.xml.in === RCS file: /cvs/pkgs/comps/comps-f12.xml.in,v retrieving revision 1.98 diff -u -r1.98 comps-f12.xml.in --- comps-f12.xml.in 27 Aug 2009 14:49:40 - 1.98 +++ comps-f12.xml.in 28 Aug 2009 21:13:54 - @@ -360,7 +360,7 @@ firstboot glx-utils gnome-packagekit - kerneloops + abrt-desktop krb5-auth-dialog openssh-askpass plymouth-system-theme @@ -2462,7 +2462,6 @@ scim-bridge-gtk at-spi brasero-nautilus - bug-buddy cheese compiz-gnome dasher -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
pkgs in rawhide which are obsoleted by something in rawhide
Working on something else I stumbled across this: http://fpaste.org/jDwM/ that's a list of pkgs in rawhide which are obsoleted by something else in rawhide. seems a bit dodgy to me. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
On Fri, 2009-08-28 at 22:45 +0200, Björn Persson wrote: > Caolán McNamara wrote: > > Well, FWIW there is the (rather weird) en_DK locale, which has > > -MM-YY dates (I think its the only locale where this is the default) > > Assuming you meant -MM-DD, sv_SE has that: I'd guess Japan would too, that's the standard date format there IIRC. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
Caolán McNamara wrote: > Well, FWIW there is the (rather weird) en_DK locale, which has > -MM-YY dates (I think its the only locale where this is the default) Assuming you meant -MM-DD, sv_SE has that: [be...@hactar beorn]$ locale LANG=sv_SE.utf8 LC_CTYPE="sv_SE.utf8" LC_NUMERIC="sv_SE.utf8" LC_TIME="sv_SE.utf8" LC_COLLATE="sv_SE.utf8" LC_MONETARY="sv_SE.utf8" LC_MESSAGES="sv_SE.utf8" LC_PAPER="sv_SE.utf8" LC_NAME="sv_SE.utf8" LC_ADDRESS="sv_SE.utf8" LC_TELEPHONE="sv_SE.utf8" LC_MEASUREMENT="sv_SE.utf8" LC_IDENTIFICATION="sv_SE.utf8" LC_ALL= [be...@hactar beorn]$ date +%x 2009-08-28 I don't think I have customized that because I have no idea how to do it. (If I knew how, I'd fix the time format to get a colon in the clock in the Gnome panel.) Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 early branch now available.
For those of you that wish to separate Fedora 12 stabalization work from future development, we are now ready to process branch requests for F-12. If you branch your package early, builds from your new F-12 branch will continue to go to the Fedora 12 targets. dist-f12 for now, and eventually dist-f12-updates-candidate. Builds from devel/ will be sent to dist-f13 and will be held for the Fedora 13 rawhide once we get Fedora 12 out the door. To request a branch, please continue to use the cvsadmin request method: https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
Hi. On Fri, 28 Aug 2009 11:43:00 -0500, Bruno Wolff III wrote > You might be referring to PPP which some (IMO only crappy ISPs do > this for DSL) DSL providers require you to use. PPP is pretty much standard for broadband access because it allows for some very useful tricks. Please note that I did not say that it is required, it is not, just that there are some convincing advantages to using it (at the provider side, and in not-so-obvious ways on the customer side as well). This is OT here, so mail me in private if you'd like to discuss this further. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 2009-08-28
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-28/fedora-meeting.2009-08-28-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-08-28/fedora-meeting.2009-08-28-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-28/fedora-meeting.2009-08-28-17.01.log.html --- 17:01:14 #startmeeting FESCo meeting 20090828 17:01:14 Meeting started Fri Aug 28 17:01:14 2009 UTC. The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:17 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:01:17 Current chairs: Kevin_Kofler dgilmore j-rod jds2001 jwb nirik notting sharkcz skvidal 17:01:21 * nirik is here. 17:01:26 hi 17:01:27 * sharkcz is here 17:02:02 anyone else? 17:02:08 * notting is here 17:02:27 ok, we have something of quorum :/ 17:02:57 #topic tbzatek provenpackager request 17:03:03 .fesco 246 17:03:04 jds2001: #246 (Request to become provenpackager - tbzatek) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/246 17:03:24 +1, we have no better way atm :/ 17:03:33 +1 17:03:53 +1, tbzatek has been around quite a while and knows what he's doing 17:03:55 +1 from here. It seems ok. 17:04:03 kkofler was +1 in the ticket 17:04:07 iirc 17:04:13 yep 17:04:30 #agreed tbzatek provenpackager is approved 17:04:40 oops, a little ordering issue 17:04:50 #topic provenpackager request - bruno 17:05:19 so there were objections to this, and I agree with them 17:05:21 I would say he should do more work and maintain more packages and come back in a while. 17:05:32 he's not met the 'proven' part 17:05:36 he's a great guy and has been very good maintaining the games spin. 17:05:38 i see no reason to override the opinions of his sponsor, for example. so -1. 17:05:39 yeah 17:05:45 but only has one package currently. 17:05:50 Two 17:06:20 oh, sorry. ;) Hi brunowolff. 17:06:46 I just picked up glest/glest-data last week when it was orphaned. 17:06:51 brunowolff: would you be willing to do some more packages and come back to us in a month or so? 17:07:03 but as with notting, I see no reason to override his sponsor on this. 17:07:16 But I am not necesarily disagreeing with the proven part not being met. 17:08:36 I am not so much looking to become the maintainer of more packages as much as to be able to simple rebuilds to things on the games 17:09:00 spin. Their are other ways (like asking others for help) to get that done. 17:09:48 Continuing doing that for for longer isn't a big deal. 17:10:00 OK, good. 17:10:02 yeah, but sometimes those simple rebuilds are not so simple. ;) Of course sometimes they are. 17:10:17 That's what make scratch-build is for. 17:10:34 I can still learn a lot more. 17:10:39 or local mock build 17:10:52 sharkcz: make mockbuild :) 17:11:03 just in case you didn't know about it :) 17:11:46 jds2001: I know :) but it deletes the chroot at the end so I rather do a manual mock build 17:12:30 anyhow, shall we move on? 17:13:14 yes, I agree with the rest of fesco, -1 for now 17:13:32 #agreed brunowolff provenpackager is declined for now, please come back later with more experience 17:13:52 #topic translations proposal 17:13:59 .fesco 243 17:14:01 jds2001: #243 (New entry of 'Build packages for which Fedora is upstream for all language translators' review & correction' for F12 schedule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/243 17:14:28 so I'm not sure what the scope of this is supposed to be anymore :) 17:14:38 crap 17:14:47 sorry - I got distracted from the meeting 17:14:54 skvidal: np 17:15:06 skvidal: you wanted to say something? 17:15:10 no 17:15:12 it's fine 17:15:18 k 17:15:22 none of the items on the agenda today worried me 17:15:29 for the most part they look procedural 17:15:38 except this one :) 17:15:47 well i guess it still is/ 17:15:55 anyway - go on 17:16:08 but anyhow, do we know what the scope of this proposal is precisely? 17:16:23 I thought it was "packages for which we are upstream and have translations" 17:16:41 but it seems to have gotten confused with "packages that have translations" 17:16:56 if it is the former then +1 17:17:00 if it is the latter then -1 17:17:11 * notting agrees with skvidal on both counts 17:17:21 * sharkcz too :-) 17:17:24 * jds2001 too 17:17:28 * nirik nods. 17:17:38 by 'we are upstream' you mean 'uses fedora tranisfex' ? 17:17:49 good question. 17:17:57 i guess so? :) 17:18:13 if they aren't using transifex how in the hell are we going to check this? 17:18:18 but transifex commits to upstream repos 17:18:35 so that means upstream has to do a release with the new translations, no? 17:18:41 yeah... 17:19:09 so I think that means 17:19:12 WE are upstream 17:19:16 ie: FEDORA 17:1
Re: Some ideas/questions about yum
On Fri, 28 Aug 2009, Hedayat Vatnakhah wrote: You don't need to know about all existing repositories, since you can still resolve file level dependencies. In such cases you'll be forced to download the other file I mentioned (primary_file_deps.db). I don't see why you'll need to recreate all repos when one of them changes! Sorry :( And its impossible to state anything about the last item. You're going to pretty much instantly download the complete filelists then b/c if you add ANY 3rd party repo you're going to need /bin/sh probably immediately along with various and sundry items in /etc/. Now - an argument could be made for nuking /bin/sh deps from orbit but that's going to have to happen at another layer than this. IMHO, even a single php/python script can provide such a XML RPC service (web service was just an example). Mirrors could get this file just like the other files when syncing. But well, it'll be http only. The GPG sign issue could be problematic, but would you really need to sign the traffic?! 1. a lot of our mirrors won't want to run any app 2. some of our mirrors are not running on linux (or sometimes not even on a unix) 3. it makes 'mirroring' things much harder in the traditional sense 4. yes you need to sign it otherwise you'll get the same set of problems we just dealt with last fall. We have to sign the metadata to make sure clients aren't screwed. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
Hi again! /*Florian Festi */ wrote on جمعه ۲۸ اوت ۰۹، ۱۷:۱۳:۱۰: On 08/28/2009 12:27 PM, Hedayat Vatnakhah wrote: Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?).It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. Bad idea as you never know all repositories existing. Bad idea because you don't want to recreate all repos when one of them changes. Bad idea because changing the data of the packages in the repo likely to lead to other problems. You don't need to know about all existing repositories, since you can still resolve file level dependencies. In such cases you'll be forced to download the other file I mentioned (primary_file_deps.db). I don't see why you'll need to recreate all repos when one of them changes! Sorry :( And its impossible to state anything about the last item. There have actually been efforts long ago to improve the set of files shipped with the primarydb to lower the need of downloading the filelist while still decrease the number of file shipped in the primarydb. AFAIK they got rejected by yum upstream at that time because the also needed cross repo closures (Although this was much less problematic as what you have suggested here). 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. True. What do you think about it: we can implement parts of yum at the server side (e.g. a web service), and do queries online. The client can submit queries to online repositories, aggregate the results (+using local repositories by itself) and do appropriate actions. It can also store received data to be used when offline or while they are valid. It'll be completely backward compatible with the current clients: those who use the old method can download repositories themselves, like what they do now. It is possible to think about further details and design it completely, but I want to know about your opinions about the whole idea. Web services have the problem that they don't mix well with our mirrors infrastructure of simple and stupid http/ftp/rsync servers largely provided by volunteers. It is also difficult to GPG sign external web services. Because of this the whole traffic of such web services would most likely need to run over Fedora infrastructure. IMHO, even a single php/python script can provide such a XML RPC service (web service was just an example). Mirrors could get this file just like the other files when syncing. But well, it'll be http only. The GPG sign issue could be problematic, but would you really need to sign the traffic?! When we think of a Fedora that has grown another order of magnitude (may be 2015) it will become hard to argue against a more centralized solution. Right now we are not at the point where the pain of the local repo db does out weight the complexity of a web service architecture IMHO. No, I don't want to invite to a centralized solution. But there is another way to drastically reduce the amount of data that has to be transferred: Delta meta data The repo data bases could be split up into deltas in a similar way as done with the delta rpms aka presto. As a result the meta data of each package would be downloaded (more or less) exactly once. While this idea is arround for a while an implementation is still missing... Yes, I know. In fact, at first I decided to start working on that. But you'll still need to download it once (while it's possible to put the Fedora repository's metadata into Fedora DVD!). I though that if the proposed solution works, it would be better than delta metadata files. Even if the whole client/server idea is considered bad, there might be some other ways of organizing the repository metadata so that yum would still download the data it needs rather than all data. But currently I'm interested to here about this Idea... Thanks, Hedayat Florian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
Hi again, On ۰۹/۰۸/۲۸ 04:50, Seth Vidal wrote: On Fri, 28 Aug 2009, Hedayat Vatnakhah wrote: Hi all, Currently, Fedora package management is one of the most annoying part of Fedora experience for new desktop users (at least for those without fast, always available internet connection). For such users, Fedora package management "Just Doesn't Work"! I've almost never been able to demonstrate using fedora package management tools for a fresh Fedora install without the need to use command line, editing yum configuration file(s), killing current running yum/package kit instance(s), installing some small rpm packages using rpm command instead of using yum or graphically, etc. And sometimes, I found it better to download yum metadata using another application and copying the downloaded file to yum cache; or even completely skip yum and use rpm and manually resolve dependencies when they are not too much! Have you filed bugs on any of these issues or are they strictly due to unreliable network connections? I've reported bugs for some of them (e.g. the bug you know about resuming downloding metadata files), I'll report some more, and some of them happened on systems of some users and I wasn't able to investigate them to file useful reports for them. And yes, many of them happen with poor (or no) network connection only. First, I've some suggestions/requests which doesn't seem to need much work, and then some ideas which I'd like to know your opinions about. 1. Since Fedora 4, Fedora doesn't support installing software from DVD "out of the box". Fedora 8 is an exception here. Currently, it seems that the work is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't seem to need much work but unfortunately it seems that it is stopped. I think requesting a small collaboration between the feature owner, PolicyKit and/or GIO people is not too much. Alsadi has done a great deal of work to make this happen and I believe it is likely it will go in for F13. I hope that happens. 2. Maybe yum could be a bit more forgiving about inaccessible repositories when running. Consider this case: a new offline user installs Fedora, and then runs "Add/Remove Software". Currently, if he clicks on "all packages", he'll see an error message that yum is unable to contact fedora repository. I think it is better to show a warning to user about being unable to contact online repositories and then show all installed packages + the packages from all accessible repositories. IMHO it is much more reasonable than expecting the user to disable all such repositories in such cases (yum/packagekit can be a bit more intelligent and do it itslef). Disabling repos which are unavailable/inaccessible is a pretty dangerous behavior. If you're doing a 'yum install foo' and the only 'foo' you have access to is insecure - but a secure 'foo' is in the updates dir - it would be better for you to not install 'foo' at all than install a bad one. And this is why the warning should be shown! The warning message could state that there might be security concerns too. But what if the user just wants to remove a package (maybe a separate section called "installed packages" in PackageKit will do the job in this case) or he just wants to install a package from a local repository (DVD) or rpmfusion?! I think the current frustration for the end user is not better than what you mentioned. Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?). It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. Except none of this will work for dependencies for 3rd party repos at all. Nor will it adequately handle any of the cases where we have multiple pkgs which provide the same file. For the first case, it'll work. Yum will download the file I mentioned (primary_file_deps.db) when it needs to resolve file dependencies. I do not know what do you do now about the latter case and what is that at all, so I'll be silent here! 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. no
Re: Some ideas/questions about yum
On Fri, Aug 28, 2009 at 14:57:44 +0430, Hedayat Vatnakhah wrote: > > Now, some ideas: > 3. AFAIK, currently yum's primary database file contains information > about packages, and all of the files in directories such as /usr/bin and > /usr/lib, so that it can resolve package and file level dependencies. > Isn't it possible to move file level information outside primary db > (e.g. to primary_file_deps.db) and translate internal dependencies from > file level dependencies to package level dependencies when creating > repositories? (So that provides and requires tables in primary db only > contain package references rather than file references?). It might be > even possible to do it for dependencies outside repository; for example > when creating updates repository, you can introduce fedora repository to > createrepo, so it can translate all of the file level dependencies of > updates packages also. Personally, I think dependencies of file names is a bad idea. I think they are getting used as a standin for interface names. I think we would be better off replacing the current set of file name requires with new provides and dump file name dependencies. However, the last time I brought this up, other people disagreed, so it's not something that's likely to change in the near future. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On Fri, Aug 28, 2009 at 15:29:50 +0300, Aioanei Rares wrote: > Oh, and speaking of anaconda, IMHO it should support DSL configuration > when using asknetwork. DSL is popular these days. If you actually file an RFE bug about this you'll need to be more specific. There is nothing inherently special about DSL that requires anaconda to know that you have a DSL connection. You might be referring to PPP which some (IMO only crappy ISPs do this for DSL) DSL providers require you to use. If you are referring to PPP support, that's what you should say, since other types of links (in particular dialup) use PPP. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to respin F11-install-dvd with GRUB on ext4?
2009/8/27 Joshua C. > > > 2009/8/27 Bruno Wolff III > >> On Thu, Aug 27, 2009 at 01:44:13 +0200, >> "Joshua C." wrote: >> > I'm trying to respin the f11.x86_64 install dvd in order to put the >> > new grub and anaconda packages, so that I can have grub on my ext4 >> > without a separete partition for it. I recompiled >> > grub-0.97-59.fc11.x86_64 and anaconda-12.0-1.fc11.x86_64 against the >> > current f11 packages. Everything worked fine. I also recompiled the >> > corresponding util-linux-ng and other deps. >> >> I thought new packages had already been pushed to F11 to allow this, so >> you shouldn't have had to recompile anything. >> > > I haven't heard of this. I'll switch to f11 but didn't want to use the > default install dvd because of the grub-on-ext3 problem. Even if new > packages have been pushed to f11 repos the install media haven't been > respin. Therefore I need ot do it thia way. > > >> > How can I recreate the install dvd? >> >> pungi is the tool used to build install images. >> > > I'll try it. thanks. > Ok I finally did it. After trying all version of anaconda from anaconda-12.0-1.fc12 to anaconda-12.7-1.fc12 (against the current f11 libs), they all gave me different sorts of errors. At the end I just patched the anaconda-11.5.0.59-1.fc11 with the following commits and recompiled it. commit 162c92b4838f9769f39b0c3a85f9c6e4a38a5913: x86 and EFI platforms can now have /boot on ext4. commit 11266dabba490baf732b85ba76e2841e6ae17733: Default to /boot on ext4 commit 9e83e8a43f8a609c65c39c6de8cf1c341d3f31ec: Allow /boot on ext4 now that we have a grub that allows it Now I have f11-install-dvd with grub (recompiled grub-0.97-59.fc11) on ext4 by default. It' works just fine. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 16:14:51 Jaroslav Reznik wrote: > On Friday 28 August 2009 15:36:19 Matthias Clasen wrote: > > On Fri, 2009-08-28 at 06:47 -0500, Rex Dieter wrote: > > > Matthias Clasen wrote: > > > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 > > > > in a matter of a few days. The KDE sig should really be able to get > > > > this port done. We really don't want to ship multiple authorization > > > > databases, that way lies confusion and madness. > > > > > > The PolicyKitOne feature page does include in its contingency plan: > > > "If not all ports listed above can be completed in time, keep PolicyKit > > > 0.9 around..." > > > > Right. But from what I've heard that is not the case. Jreznik just said: > > > > > > I have initial port [...] seems like it's working now and usable. > > Yes, I have port but I'm not sure how to combine it into current KDE as it > breaks polkit-qt API and I don't like shipping big patches that actually > forks project. I'd like to see it from upstream. And this apply only to polkit-qt-core, I'm not even sure it's easily possible to port polkit-qt-gui without mayor rewrite. Jaroslav > I'm working on this, we have topic for our next KDE SIG meeting. If you > could join, it would be great - > http://fedoraproject.org/wiki/SIGs/KDE/Meetings. > > Matthias, could you please look at > https://bugzilla.redhat.com/show_bug.cgi?id=519674 > > Thanks > Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090828 changes
On 08/28/2009 09:09 AM, Rawhide Report wrote: Broken deps for i386 -- paraview-3.6.1-4.fc12.i686 requires libssl.so.8 paraview-mpi-3.6.1-4.fc12.i686 requires libssl.so.8 3.6.1-5 is building now which should fix this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 16:23:07 David Zeuthen wrote: > On Thu, 2009-08-27 at 12:45 -0400, Matthias Clasen wrote: > > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > > packages (though renaming should not be needed as they already have > > > distinct names), to be used by KDE) for F12. It is my understanding > > > that those will not conflict with PolicyKit 1 and can coexist just > > > fine, if that's not the case, please correct me. So please don't > > > obsolete PolicyKit 0.9! > > We announced that this would happen long ago. And, FWIW, it was approved > long ago by FESCO too. And you've been aware of this long ago as well. > So, sorry, but we will obsolete the old packages and I'm afraid you will > need to deal with it. Just like everyone else. As I said - patches are mostly ready, only polishing is needed. What I don't like is that it is our fork of polkit-qt. I think we should discuss it at KDE SIG meeting, how to do it carefully. You can join us. It's Freedesktop.org hosted, so it should match releases of major desktop environments, not one distribution. Upstream is not using Fedora, they can't get it running (I'm not blaming anyone), so it looks I'm now upstream ;-) I know why are you pushing on this and I don't have objections. For Authentication Agent we'd like to use Gnome as I'm fighting with it. BeginAuthentication method should be OK, but daemon does not accept it's signature... Could I ping you sometime next week? I'm leaving soon today... Thanks Jaroslav > > We really don't want to ship multiple authorization > > databases, that way lies confusion and madness. > > Indeed. And in this transition period where we've been shipping both set > of packages, there has been a lot of confusion. I've witnessed that > myself. We just don't want that to happen in a released OS. > > David -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Thu, 2009-08-27 at 12:45 -0400, Matthias Clasen wrote: > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > packages > > (though renaming should not be needed as they already have distinct names), > > to be used by KDE) for F12. It is my understanding that those will not > > conflict with PolicyKit 1 and can coexist just fine, if that's not the > > case, > > please correct me. So please don't obsolete PolicyKit 0.9! We announced that this would happen long ago. And, FWIW, it was approved long ago by FESCO too. And you've been aware of this long ago as well. So, sorry, but we will obsolete the old packages and I'm afraid you will need to deal with it. Just like everyone else. > We really don't want to ship multiple authorization > databases, that way lies confusion and madness. Indeed. And in this transition period where we've been shipping both set of packages, there has been a lot of confusion. I've witnessed that myself. We just don't want that to happen in a released OS. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 15:36:19 Matthias Clasen wrote: > On Fri, 2009-08-28 at 06:47 -0500, Rex Dieter wrote: > > Matthias Clasen wrote: > > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > > > a matter of a few days. The KDE sig should really be able to get this > > > port done. We really don't want to ship multiple authorization > > > databases, that way lies confusion and madness. > > > > The PolicyKitOne feature page does include in its contingency plan: > > "If not all ports listed above can be completed in time, keep PolicyKit > > 0.9 around..." > > Right. But from what I've heard that is not the case. Jreznik just said: > > > I have initial port [...] seems like it's working now and usable. Yes, I have port but I'm not sure how to combine it into current KDE as it breaks polkit-qt API and I don't like shipping big patches that actually forks project. I'd like to see it from upstream. I'm working on this, we have topic for our next KDE SIG meeting. If you could join, it would be great - http://fedoraproject.org/wiki/SIGs/KDE/Meetings. Matthias, could you please look at https://bugzilla.redhat.com/show_bug.cgi?id=519674 Thanks Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
#! /usr/bin/perl preferred
Hello, at certain periods of time, it was recommended to use #!/usr/bin/env . Some people consider it ugly. (The humble opinion of the author of this mail is the same.) Currently there is popular mood to remove "/usr/bin/env python", see http://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython We could follow this movement and replace #! ?/(usr/)?bin/env perl by mere #! /usr/bin/perl To assist with this change, I searched all Fedora packages (on x86_64 only) for the issue. Attached below please find the list of affected files, grouped by maintainers and packages. Have a nice weekend, Stepan alexlan: perl-bioperl /usr/bin/bp_seqfeature_gff3.pl /usr/share/doc/perl-bioperl-1.6.0/examples/root/exceptions1.pl /usr/share/doc/perl-bioperl-1.6.0/examples/root/exceptions2.pl /usr/share/doc/perl-bioperl-1.6.0/examples/root/exceptions3.pl /usr/share/doc/perl-bioperl-1.6.0/examples/root/exceptions4.pl /usr/share/doc/perl-bioperl-1.6.0/examples/searchio/custom_writer.pl /usr/share/doc/perl-bioperl-1.6.0/examples/searchio/hspwriter.pl /usr/share/doc/perl-bioperl-1.6.0/examples/searchio/rawwriter.pl /usr/share/doc/perl-bioperl-1.6.0/examples/tools/seq_pattern.pl andriy: renrot /usr/bin/renrot athimm: mediawiki(mediawiki-nomath) /usr/share/mediawiki/maintenance/fetchInterwiki.pl vtk(vtk-devel) /usr/lib64/vtk-5.4/doxygen/doc_class2example.pl /usr/lib64/vtk-5.4/doxygen/doc_cleanhtml.pl /usr/lib64/vtk-5.4/doxygen/doc_codematch.pl /usr/lib64/vtk-5.4/doxygen/doc_contributors.pl /usr/lib64/vtk-5.4/doxygen/doc_header2doxygen.pl /usr/lib64/vtk-5.4/doxygen/doc_index.pl /usr/lib64/vtk-5.4/doxygen/doc_rmpath.pl /usr/lib64/vtk-5.4/doxygen/doc_version.pl /usr/share/doc/vtk-devel-5.4.2/Upgrading/DiagAttribute.pl /usr/share/doc/vtk-devel-5.4.2/Upgrading/UpgradeFrom32.pl atkac: tigervnc(tigervnc-server) /usr/bin/vncserver ausil: konversation /usr/share/kde4/apps/konversation/scripts/cmd /usr/share/kde4/apps/konversation/scripts/fortune /usr/share/kde4/apps/konversation/scripts/uptime bonii: teseq /usr/bin/reseq c4chris: lagan /usr/bin/lagan /usr/lib64/lagan/anal_gloc.pl /usr/lib64/lagan/rechaos.pl /usr/lib64/lagan/utils/cmerge2.pl /usr/lib64/lagan/utils/draft.pl /usr/lib64/lagan/utils/mextract.pl /usr/lib64/lagan/utils/mf2bin.pl /usr/lib64/lagan/utils/mpretty.pl /usr/lib64/lagan/utils/mproject.pl /usr/lib64/lagan/utils/mrun.pl /usr/lib64/lagan/utils/mrunfile.pl /usr/lib64/lagan/utils/mrunpairs.pl /usr/lib64/lagan/utils/mviz.pl cweyl: perl-Class-MOP /usr/share/doc/perl-Class-MOP-0.92/t/086_rebless_instance_away.t /usr/share/doc/perl-Class-MOP-0.92/t/307_null_stash.t /usr/share/doc/perl-Class-MOP-0.92/t/lib/SyntaxError.pm perl-Class-Method-Modifiers /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/000-load.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/001-error.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/002-cache.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/003-basic.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/004-around.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/005-return.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/010-before-args.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/011-after-args.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/012-around-args.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/020-multiple-inheritance.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/030-multiple-before.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/031-multiple-after.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/032-multiple-around.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/034-multiple-everything.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/035-multiple-everything-twice.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/040-twice-orig.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/041-modify-parent.t /usr/share/doc/perl-Class-Method-Modifiers-1.04/t/051-un
Re: PolicyKit 0.9 is going away
On Fri, 2009-08-28 at 06:47 -0500, Rex Dieter wrote: > Matthias Clasen wrote: > > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > > a matter of a few days. The KDE sig should really be able to get this > > port done. We really don't want to ship multiple authorization > > databases, that way lies confusion and madness. > > The PolicyKitOne feature page does include in its contingency plan: > "If not all ports listed above can be completed in time, keep PolicyKit 0.9 > around..." Right. But from what I've heard that is not the case. Jreznik just said: I have initial port [...] seems like it's working now and usable. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On Fri, 28 Aug 2009, Florian Festi wrote: May be we as upstream devs of the tool chain should just limit the number of packages and packaged files by decree ;)= this works for me. When should we meet to decide how next to rule the world? muahahahahahahaha -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Prelink and kdeinit4 problems persist(Rawhide)
Aioanei Rares wrote: There was a thread more than a month ago about kdeinit4 failing to start before one did as root a 'prelink -f /usr/bin/kdeinit4'. Well the problem is still here. Anyone knows anything? https://bugzilla.redhat.com/show_bug.cgi?id=515539 https://bugzilla.redhat.com/show_bug.cgi?id=519226 -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On 08/28/2009 02:47 PM, Seth Vidal wrote: no - I think it'll be hard to argue why we need 20K pkgs in a single repository. Or hell, why we need 20K pkgs AT ALL. Dream on! > ls -1 /mnt/archive/fedora/development/x86_64/os/Packages/ | wc 18382 18382 708766 Not yet counting http://fedoraproject.org/wiki/Features/TeXLive So we are already real close to 20k packages in one repository. Separating them into different repositories doesn't help much anyway (lowers the quadratic overhead a bit, though). When I am talking about another order of magnitude I mean 100k packages, btw. I would love that your argument would even apply to that number but I am not sure actually... May be we as upstream devs of the tool chain should just limit the number of packages and packaged files by decree ;)= Florian -- Reg. Adresse: Red Hat GmbH, Hauptstätter Str. 58, 70178 Stuttgart Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Prelink and kdeinit4 problems persist(Rawhide)
There was a thread more than a month ago about kdeinit4 failing to start before one did as root a 'prelink -f /usr/bin/kdeinit4'. Well the problem is still here. Anyone knows anything? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On Fri, 28 Aug 2009, Florian Festi wrote: When we think of a Fedora that has grown another order of magnitude (may be 2015) it will become hard to argue against a more centralized solution. Right now we are not at the point where the pain of the local repo db does out weight the complexity of a web service architecture IMHO. no - I think it'll be hard to argue why we need 20K pkgs in a single repository. Or hell, why we need 20K pkgs AT ALL. But there is another way to drastically reduce the amount of data that has to be transferred: Delta meta data The repo data bases could be split up into deltas in a similar way as done with the delta rpms aka presto. As a result the meta data of each package would be downloaded (more or less) exactly once. While this idea is arround for a while an implementation is still missing... 1. this is what he asked on yum-devel list. I told him there was the beginning of an implementation but it was never completed. He made it clear on yum-devel, at least, he didn't have the time to do any work on this - just that he wanted to tell us how he felt. 2. you still have to get the original metadata -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On 08/28/2009 12:27 PM, Hedayat Vatnakhah wrote: Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?).It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. Bad idea as you never know all repositories existing. Bad idea because you don't want to recreate all repos when one of them changes. Bad idea because changing the data of the packages in the repo likely to lead to other problems. There have actually been efforts long ago to improve the set of files shipped with the primarydb to lower the need of downloading the filelist while still decrease the number of file shipped in the primarydb. AFAIK they got rejected by yum upstream at that time because the also needed cross repo closures (Although this was much less problematic as what you have suggested here). 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. True. What do you think about it: we can implement parts of yum at the server side (e.g. a web service), and do queries online. The client can submit queries to online repositories, aggregate the results (+using local repositories by itself) and do appropriate actions. It can also store received data to be used when offline or while they are valid. It'll be completely backward compatible with the current clients: those who use the old method can download repositories themselves, like what they do now. It is possible to think about further details and design it completely, but I want to know about your opinions about the whole idea. Web services have the problem that they don't mix well with our mirrors infrastructure of simple and stupid http/ftp/rsync servers largely provided by volunteers. It is also difficult to GPG sign external web services. Because of this the whole traffic of such web services would most likely need to run over Fedora infrastructure. When we think of a Fedora that has grown another order of magnitude (may be 2015) it will become hard to argue against a more centralized solution. Right now we are not at the point where the pain of the local repo db does out weight the complexity of a web service architecture IMHO. But there is another way to drastically reduce the amount of data that has to be transferred: Delta meta data The repo data bases could be split up into deltas in a similar way as done with the delta rpms aka presto. As a result the meta data of each package would be downloaded (more or less) exactly once. While this idea is arround for a while an implementation is still missing... Florian -- Reg. Adresse: Red Hat GmbH, Hauptstätter Str. 58, 70178 Stuttgart Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On Fri, 28 Aug 2009, Aioanei Rares wrote: Thanks anyway, Hedayat Since it's idea time, I think it would be good for the user that uses yum to see in a listing (like yum search <$whatever>) to see the status of the package, like installed, not installed, virtual package et al. 'yum list pkgname' does this now. (well it shows installed, not installed) - since there is no such thing as a virtual package it doesn't show that. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
Oh, and speaking of anaconda, IMHO it should support DSL configuration when using asknetwork. DSL is popular these days. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On 08/28/2009 01:27 PM, Hedayat Vatnakhah wrote: Hi all, Currently, Fedora package management is one of the most annoying part of Fedora experience for new desktop users (at least for those without fast, always available internet connection). For such users, Fedora package management "Just Doesn't Work"! I've almost never been able to demonstrate using fedora package management tools for a fresh Fedora install without the need to use command line, editing yum configuration file(s), killing current running yum/package kit instance(s), installing some small rpm packages using rpm command instead of using yum or graphically, etc. And sometimes, I found it better to download yum metadata using another application and copying the downloaded file to yum cache; or even completely skip yum and use rpm and manually resolve dependencies when they are not too much! First, I've some suggestions/requests which doesn't seem to need much work, and then some ideas which I'd like to know your opinions about. 1. Since Fedora 4, Fedora doesn't support installing software from DVD "out of the box". Fedora 8 is an exception here. Currently, it seems that the work is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't seem to need much work but unfortunately it seems that it is stopped. I think requesting a small collaboration between the feature owner, PolicyKit and/or GIO people is not too much. 2. Maybe yum could be a bit more forgiving about inaccessible repositories when running. Consider this case: a new offline user installs Fedora, and then runs "Add/Remove Software". Currently, if he clicks on "all packages", he'll see an error message that yum is unable to contact fedora repository. I think it is better to show a warning to user about being unable to contact online repositories and then show all installed packages + the packages from all accessible repositories. IMHO it is much more reasonable than expecting the user to disable all such repositories in such cases (yum/packagekit can be a bit more intelligent and do it itslef). Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?). It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. What do you think about it: we can implement parts of yum at the server side (e.g. a web service), and do queries online. The client can submit queries to online repositories, aggregate the results (+using local repositories by itself) and do appropriate actions. It can also store received data to be used when offline or while they are valid. It'll be completely backward compatible with the current clients: those who use the old method can download repositories themselves, like what they do now. It is possible to think about further details and design it completely, but I want to know about your opinions about the whole idea. [1] http://www.fedoraproject.org/wiki/Features/MediaRepo Thanks anyway, Hedayat Since it's idea time, I think it would be good for the user that uses yum to see in a listing (like yum search <$whatever>) to see the status of the package, like installed, not installed, virtual package et al. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some ideas/questions about yum
On Fri, 28 Aug 2009, Hedayat Vatnakhah wrote: Hi all, Currently, Fedora package management is one of the most annoying part of Fedora experience for new desktop users (at least for those without fast, always available internet connection). For such users, Fedora package management "Just Doesn't Work"! I've almost never been able to demonstrate using fedora package management tools for a fresh Fedora install without the need to use command line, editing yum configuration file(s), killing current running yum/package kit instance(s), installing some small rpm packages using rpm command instead of using yum or graphically, etc. And sometimes, I found it better to download yum metadata using another application and copying the downloaded file to yum cache; or even completely skip yum and use rpm and manually resolve dependencies when they are not too much! Have you filed bugs on any of these issues or are they strictly due to unreliable network connections? First, I've some suggestions/requests which doesn't seem to need much work, and then some ideas which I'd like to know your opinions about. 1. Since Fedora 4, Fedora doesn't support installing software from DVD "out of the box". Fedora 8 is an exception here. Currently, it seems that the work is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't seem to need much work but unfortunately it seems that it is stopped. I think requesting a small collaboration between the feature owner, PolicyKit and/or GIO people is not too much. Alsadi has done a great deal of work to make this happen and I believe it is likely it will go in for F13. 2. Maybe yum could be a bit more forgiving about inaccessible repositories when running. Consider this case: a new offline user installs Fedora, and then runs "Add/Remove Software". Currently, if he clicks on "all packages", he'll see an error message that yum is unable to contact fedora repository. I think it is better to show a warning to user about being unable to contact online repositories and then show all installed packages + the packages from all accessible repositories. IMHO it is much more reasonable than expecting the user to disable all such repositories in such cases (yum/packagekit can be a bit more intelligent and do it itslef). Disabling repos which are unavailable/inaccessible is a pretty dangerous behavior. If you're doing a 'yum install foo' and the only 'foo' you have access to is insecure - but a secure 'foo' is in the updates dir - it would be better for you to not install 'foo' at all than install a bad one. Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?). It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. Except none of this will work for dependencies for 3rd party repos at all. Nor will it adequately handle any of the cases where we have multiple pkgs which provide the same file. 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. no - it can be said that yum if you have a lot of pkgs you have a lot of metadata. That's not a function of yum scaling that's a function of network connectivity. What do you think about it: we can implement parts of yum at the server side (e.g. a web service), and do queries online. The client can submit queries to online repositories, aggregate the results (+using local repositories by itself) and do appropriate actions. It can also store received data to be used when offline or while they are valid. It'll be completely backward compatible with the current clients: those who use the old method can download repositories themselves, like what they do now. It is possible to think about further details and design it completely, but I want to know about your opinions about the whole idea. That's what up2date and rhn did in rhl6->rhel3. There are multiple problems: 1. we need a single web service that many systems would access to query for depsolving If you want to talk about things NOT scaling 2. it would
Re: PolicyKit 0.9 is going away
Matthias Clasen wrote: > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > a matter of a few days. The KDE sig should really be able to get this > port done. We really don't want to ship multiple authorization > databases, that way lies confusion and madness. The PolicyKitOne feature page does include in its contingency plan: "If not all ports listed above can be completed in time, keep PolicyKit 0.9 around..." -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Some ideas/questions about yum
Hi all, Currently, Fedora package management is one of the most annoying part of Fedora experience for new desktop users (at least for those without fast, always available internet connection). For such users, Fedora package management "Just Doesn't Work"! I've almost never been able to demonstrate using fedora package management tools for a fresh Fedora install without the need to use command line, editing yum configuration file(s), killing current running yum/package kit instance(s), installing some small rpm packages using rpm command instead of using yum or graphically, etc. And sometimes, I found it better to download yum metadata using another application and copying the downloaded file to yum cache; or even completely skip yum and use rpm and manually resolve dependencies when they are not too much! First, I've some suggestions/requests which doesn't seem to need much work, and then some ideas which I'd like to know your opinions about. 1. Since Fedora 4, Fedora doesn't support installing software from DVD "out of the box". Fedora 8 is an exception here. Currently, it seems that the work is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't seem to need much work but unfortunately it seems that it is stopped. I think requesting a small collaboration between the feature owner, PolicyKit and/or GIO people is not too much. 2. Maybe yum could be a bit more forgiving about inaccessible repositories when running. Consider this case: a new offline user installs Fedora, and then runs "Add/Remove Software". Currently, if he clicks on "all packages", he'll see an error message that yum is unable to contact fedora repository. I think it is better to show a warning to user about being unable to contact online repositories and then show all installed packages + the packages from all accessible repositories. IMHO it is much more reasonable than expecting the user to disable all such repositories in such cases (yum/packagekit can be a bit more intelligent and do it itslef). Now, some ideas: 3. AFAIK, currently yum's primary database file contains information about packages, and all of the files in directories such as /usr/bin and /usr/lib, so that it can resolve package and file level dependencies. Isn't it possible to move file level information outside primary db (e.g. to primary_file_deps.db) and translate internal dependencies from file level dependencies to package level dependencies when creating repositories? (So that provides and requires tables in primary db only contain package references rather than file references?). It might be even possible to do it for dependencies outside repository; for example when creating updates repository, you can introduce fedora repository to createrepo, so it can translate all of the file level dependencies of updates packages also. 4. Even if the above solution is possible and can reduce the size of primary db, it won't solve the main problem: for large repositories, you'll need to download large database files. You'll need to download extra database files on some use cases anyway. So, it can be said that currently yum doesn't scale well. What do you think about it: we can implement parts of yum at the server side (e.g. a web service), and do queries online. The client can submit queries to online repositories, aggregate the results (+using local repositories by itself) and do appropriate actions. It can also store received data to be used when offline or while they are valid. It'll be completely backward compatible with the current clients: those who use the old method can download repositories themselves, like what they do now. It is possible to think about further details and design it completely, but I want to know about your opinions about the whole idea. [1] http://www.fedoraproject.org/wiki/Features/MediaRepo Thanks anyway, Hedayat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
On Thu, 2009-08-27 at 23:06 +0200, Kevin Kofler wrote: > Maybe we just need an en_INTL locale which defaults to US English > translations, but ISO standards everywhere else (ISO -mm-dd dates, ISO > A4 paper, metric units etc.)? (Currency would be a problem though, default > to €? $? The generic currency sign ¤ almost nobody actually uses? Or > something silly like "%f bucks"? ;-) ) Such a locale might even become the > default (though it'd irritate US folks ;-) ). I think it'd cover the needs > of most of the non-US users of en_US, and details could still be overidden > where needed. Well, FWIW there is the (rather weird) en_DK locale, which has -MM-YY dates (I think its the only locale where this is the default) English A4 Paper Metric units 1.000,00 decimal format 0xA4 "Currency Sign" Currency and then there is en_IE which has DD/MM/ dates English A4 Paper Metric units 1,000.00 decimal format € Currency Though I sort of reckon that the right-thing-to-do might be to instead have a utility which convinces the user to configure their locale setting *truthfully* but also support setting LANGUAGE, so that one can specify that you want messages and the UI in English anyway, without pulling in the extra baggage that comes with an en_US locale. e.g. taking a standard German_Germany example $ export LANG=de_DE.utf8 $ locale LANG=de_DE.utf8 LC_CTYPE="de_DE.utf8" LC_NUMERIC="de_DE.utf8" LC_TIME="de_DE.utf8" LC_COLLATE="de_DE.utf8" LC_MONETARY="de_DE.utf8" LC_MESSAGES="de_DE.utf8" LC_PAPER="de_DE.utf8" LC_NAME="de_DE.utf8" LC_ADDRESS="de_DE.utf8" LC_TELEPHONE="de_DE.utf8" LC_MEASUREMENT="de_DE.utf8" LC_IDENTIFICATION="de_DE.utf8" LC_ALL= $ echo "\""$LANGUAGE"\"" "" $ ls --help | head -n 1 Aufruf: ls [OPTION]... [DATEI]... $ date +%x 28.08.2009 assuming that English is the desired language for output and we're sort of geeky and want ISO dates, then we should have something friendly that allows one to configures things to get... export LANG=de_DE.utf8 export LANGUAGE=en_US.utf8 export LC_TIME=en_DK.utf8 would give the probable truly desired outcome of... $ locale LANG=de_DE.utf8 LC_CTYPE="de_DE.utf8" LC_NUMERIC="de_DE.utf8" LC_TIME=en_DK.utf8 LC_COLLATE="de_DE.utf8" LC_MONETARY="de_DE.utf8" LC_MESSAGES="de_DE.utf8" LC_PAPER="de_DE.utf8" LC_NAME="de_DE.utf8" LC_ADDRESS="de_DE.utf8" LC_TELEPHONE="de_DE.utf8" LC_MEASUREMENT="de_DE.utf8" LC_IDENTIFICATION="de_DE.utf8" LC_ALL= $ echo "\""$LANGUAGE"\"" "en_US.utf8" $ ls --help | head -n 1 Usage: ls [OPTION]... [FILE]... $ date +%x 2009-08-28 and that allows LANG to be retained for use as e.g. the default "content creation" language, i.e. default spell check using that setting, gettext LANGUAGE variable as the UI/output language, and the correct locale values for currency, paper, etc. C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
On Thursday 27 August 2009 18:34:38 Michael Schwendt wrote: > On Thu, 27 Aug 2009 12:14:43 -0400, Ben wrote: > > [KDE X session file] > > > So your issue is that kdebase-workspace puts it there, but it's > > not complete, so it shouldn't? > > Well, in case installing ktorrent shall drag in the packages > for a complete KDE desktop, the current dependencies are incomplete. > Some packages are missing. > > Alternatively, ktorrent shall drag in only what's really needed. > Would be tons better for the "Install KDE app on GNOME desktop" > scenario. That's what we are fighting on the other side of barricade - sometimes Gnome stuff brings so many strange dependencies. There's only one solution - report bug, defend it with arguments, it's not only about splitting but provides, etc... But sometimes status quo wins ;-) Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
On Thursday 27 August 2009 19:54:19 Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 25.08.2009 02:07, Kevin Kofler wrote: > > Rahul Sundaram wrote: > >> A quick way to actually check for such dependencies is to switch to > >> another desktop environment, say Xfce, remove all the KDE packages and > >> install one of the KDE apps. It usually reveals dependencies which > >> are rather silly. I have seen kde-settings, background packages and > >> kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus > >> et all are often used outside KDE. > > > > It's not like those dependencies bite. ;-) HDD space is cheap. > > This is incorrect question setup. HDD space not always cheap. This may > be very expensive, f.e. on embedded systems, on USB-stick, Live-CD > images... Additionally it additional bandwidth on updates, which cost > often is more significant. But at end, main point for me what it is > "incorrect". This is very monolithic, small user chose to manipulation, > big and, as showed before, often produce additional errors (dependency > and others). > > So, I do not call fanatic split all what we can find, but if we can > reasonably (ok, I do not want question and define it as at least > anything see in that sense) provide program separately - why you argue > with that? Hi Pavel, as Kevin has already pointed out - we already did some splits, we discuss it on our meeting, counting pros and cons. If you find something to be split, feel free to report the bug, join our meeting, defend it. With good arguments we can do it. But sometimes even one good reason is not enough to do it and there could be another reason why we shouldn't do it. Jaroslav > At and, we see there discussion about big packages, and some arguments > why it is not problem. But what main arguments to do NOT split some thus > packages on few? -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Thursday 27 August 2009 18:45:44 Matthias Clasen wrote: > On Thu, 2009-08-27 at 17:35 +0200, Kevin Kofler wrote: > > Jaroslav Reznik wrote: > > > PolicyKit-KDE is now integral part of kdebase-workspace, it is a KDE > > > 4.3 feature, we should disable it for now (untill we have new ported > > > version). Same problem is with PolicyKit-Qt as my quick port breaks > > > API. I'd like to prepare new PolicyKit-Qt, more powerful that actually > > > matches PolicyKit Authority DBUS interface. It's quite a bad timing > > > with switching to new PolicyKit. I'm not sure I'll have releasable > > > version in time of beta, I'll try it but there's still question with > > > API compatibility for KDE 4.3. There are no KDE apps utilizing PK-Qt > > > now so I think it's not problem to do not ship it now. What do you > > > think? > > > > System Settings uses it (well, 1 or 2 modules do). And PolicyKit > > integration is advertised as a KDE 4.3 feature by upstream and even our > > feature page. So I think just dropping it is not an option. > > > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > packages (though renaming should not be needed as they already have > > distinct names), to be used by KDE) for F12. It is my understanding that > > those will not conflict with PolicyKit 1 and can coexist just fine, if > > that's not the case, please correct me. So please don't obsolete > > PolicyKit 0.9! > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > a matter of a few days. The KDE sig should really be able to get this > port done. We really don't want to ship multiple authorization > databases, that way lies confusion and madness. I have initial port - it really took two days. It's not finished as I'm not sure about shipping such big change in KDE, practically our own fork of PolicyKitQt library. With 0.92 it wasn't even possible to use this library as it was intended! I can give a shot with 0.94, seems like it's working now and usable. I'll try to finish it but really I really don't want to ship this hack/fork. I'd like to have proper PolicyKit 1 support, based on library from scratch, using DBUS interface (I don't know how to combine C++ with Glib callbacks, any help?) and offering same API as Glib version. But this is more KDE 4.4. stuff. Next time please try to synchronize/coordinate with upstreams you are targeting ;-) I'd like to help upstream as it comes from Fedora. We're trying to be more proactive in this area but you know, we're few people right now (but growing!). Another problem as I've already described is that new Policy Kit does not run nearly anywhere, even I had to update to Rawhide (btw X server is really very broken by now). Jaroslav > > Matthias -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
On Thu, Aug 27, 2009 at 22:54, Matthew Woehlke wrote: > Dariusz J. Garbowski wrote: >> >> Hi, something that bothers me a bit... More and more system restart >> requests with each update (even if one doesn't use the package at the time). > > This is a real shame. One of the selling points of Linux is that you *don't* > need to reboot for every little upgrade (unlike a certain other OS I shan't > name). I also have the feeling that the reboot messages are getting a little bit out of hand recently. This might be because of the stickiness of these flag, but it also might be used more now than before. Except of kernel updates none of these should really be necessary. Is there any way to get some statistics out of the update system how many package updates require a reboot per day ? Christof -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpqarrayd for fedora 11 and 12
On 27/08/09 16:08, Peter Jones wrote: On 08/27/2009 06:02 AM, Howard Wilkinson wrote: I have had to patch the code for cpqarrayd to get it working under Fedora 11. It was failing with a stack smashing exception. I have fixed this by replacing stack structures with dynamic allocation. Where should I send the patch ... the last development on this was in 2007 so it is probably not being maintained, although I will try to contact the author. Congrats, you get to be maintainer (and possibly the only remaining user) of cpqarrayd. Is it really true that nobody else uses cpqarrayd? If so what do people use to monitor the HP/Compaq hardware in the Proliant range of servers? If I had found one I would use an SNMP plugin and monitor via SNMP, but not tracked one down yet! My 'fix' is just removing the 'cause' of the stack smash, it does not change any function hence maintaining this is not something I am (yet) qualified to do. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Policy on removing %changelog entries?
On Thu, 2009-08-27 at 13:21 -0400, Jeff Garzik wrote: > What is the policy regarding deletion of individual entries in the > middle of %changelog? > > A developer added a %changelog entry to each of my cloud daemons' > packages, on the main fedora-cvs devel branch of each. > > Then, a day or so later, after other %changelog entries had been added > by me... the same developer removed one %changelog entry from the > middle of %changelog, and added another entry at the top. > > I thought the policy was to never delete %changelog entries, ever? I've explained that the reason for removing that entry was that the package for which the changelog entry I've added first was never on the rawhide dist tag in koji. And as it was necessary to do another rebuild so the entry could be seen as duplicate I've removed that previous entry. However I understand that you don't want that to happen again so I won't do it again. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
