Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 10:27 PM, Iain Arnell wrote: On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen wrote: soft-deps (Suggests/Recommends) is really hard to handle at the depsolver level. A depsolver need to now the hard ones, not stuff like 'it would look very nice to have pink bracelet to my little pony'. It is hard to make good decisions based on that, a asking the user every time is not a good solution IMO. You will need to take a popquiz every time you what to install a package. I can see that the information can be useful at a high level gui or in some kind of appstore. People there have bought 'foo' have also bought 'bar'. But at the lowlevel like rpm/yum is not very useful, because we don't have the needed infomation to make a good decision. I wouldn't think it's that hard to implement. When installing a new package, simply treat Suggests as Requires; when removing a package just ignore Suggests completely. Only upgrading adds a little complexity - if new version Suggests something that the old version doesn't, treat it as Requires (so that I get new optional pony accessories automatically), otherwise ignore it (so that I can throw away that optional pink bracelet and not have it come back every time I update). Note that that would be horrible behaviour for also keeping a minimal packageset. -Toshio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen wrote: > > soft-deps (Suggests/Recommends) is really hard to handle at the depsolver > level. A depsolver need to now the hard ones, not stuff like 'it would look > very nice to have pink bracelet to my little pony'. It is hard to make good > decisions based on that, a asking the user every time is not a good solution > IMO. You will need to take a popquiz every time you what to install a > package. > I can see that the information can be useful at a high level gui or in some > kind of appstore. People there have bought 'foo' have also bought 'bar'. But > at the lowlevel like rpm/yum is not very useful, because we don't have the > needed infomation to make a good decision. I wouldn't think it's that hard to implement. When installing a new package, simply treat Suggests as Requires; when removing a package just ignore Suggests completely. Only upgrading adds a little complexity - if new version Suggests something that the old version doesn't, treat it as Requires (so that I get new optional pony accessories automatically), otherwise ignore it (so that I can throw away that optional pink bracelet and not have it come back every time I update). -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 11:34 PM, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 09:29:31PM +, Matej Cepl wrote: Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). Hear, hear!!! And add Suggests:/Recommends: (which is the other part of comps). +1000 +1001 ... I've just been involved with submitting a package for febootstrap to Debian [yay, build Fedora images on Debian!], and I'm reminded yet again what a good idea 'Suggests/Recommends' are. I can Suggest packages like 'filelight' for measuring the effects of image minimization, without making it a proper dependency and consequently pulling in the whole of KDE. Rich. soft-deps (Suggests/Recommends) is really hard to handle at the depsolver level. A depsolver need to now the hard ones, not stuff like 'it would look very nice to have pink bracelet to my little pony'. It is hard to make good decisions based on that, a asking the user every time is not a good solution IMO. You will need to take a popquiz every time you what to install a package. I can see that the information can be useful at a high level gui or in some kind of appstore. People there have bought 'foo' have also bought 'bar'. But at the lowlevel like rpm/yum is not very useful, because we don't have the needed infomation to make a good decision. Tim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
| From: Tom "spot" Callaway | On 05/26/2009 10:09 AM, Paul Wouters wrote: | > See above. Note that the Wassenaar Agreement excludes software that is | > in the "public domain", eg free/open source software. | | This is not correct. "Public Domain" has a very specific legal meaning, | and 99% of FOSS does _not_ meet it. Public Domain is when the copyright | holder has explicitly abandoned his/her/its copyright on the work and | placed it into the Public Domain. (Note: In some countries, such as | Germany, this is impossible) Tom is right about the meaning of "public domain" in US law. This is not the meaning in the Wassenaar Agreement. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Matej Cepl writes: > Jesse Keating, Tue, 26 May 2009 10:25:36 -0700: >> Oh, Europe won't help much, there are just as many silly laws there as >> there are in the US. > Better is some special place in Europe thinking ... what about Isle > of Man, it has some exceptions from many laws ... err, we wouldn't be > first Linux distro headquatered there :) Unless everyone working on Fedora *moves* to the Isle of Man (and obtains citizenship there), I don't think this sort of maneuver keeps us out of trouble anyway. Realistically we all have to worry about the laws of wherever we live. So as long as a significant fraction of Fedora contributors are in $country, $country laws will matter for Fedora. (Repeat above statement for a rather long list of $country.) regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Paul Wouters pisze: > On Tue, 26 May 2009, Stephen Gallagher wrote: > >>> Find us a Company in Europe that is not based in the US that is willing >>> to fund with people and money as much as Red Hat is doing now. >>> >>> Oh, Europe won't help much, there are just as many silly laws there as >>> there are in the US. > > 1) Your packets will still flow through the US anyway. 2) The US claim > jurisdiction even outside their national borders and >reserve the right to prosecute "offenses against American interests" >according to US law, irrespective of where they take place. > > In other words, you could be extradited even if the offense would not > actually be an offense in your country. For example, Dutch people have > been extradited for selling drugs to US citizens in The Netherlands, > even though marihuana is legal. (well, "its complicated") Really? Big Brother is watching ;) > > Also, you could never set foot in the US again without getting arrested, > and most of us don't think those T-6 countries are worh that. > >> Is there a reason that an interested party (in a locale where such >> export is legal) couldn't just create a custom spin on their own (and >> using their own build system) to create a Fedora-T6 spin (or for >> trademark reasons, rebrand it)? I can see this being a perfectly good >> premise for setting up a SIG... > > respin what? remove the crypto? Try removing nss, openssl, gnutls and > kerberos and see what's left of your system. Not much :P > And who would want it? Surely not the T6 countries :P > > Paul > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 2009-05-26 at 22:34 +0100, Richard W.M. Jones wrote: > On Tue, May 26, 2009 at 09:29:31PM +, Matej Cepl wrote: > > Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > > > Can we please not remove the Group tag, it is actually quite usefull. > > > What we need to remove / loose is comps. Having all this info in a > > > centralized database is stupid. The spec files should tell which > > > group(s) the package belongs in. So that when one adds a new package, > > > this gets done right more or less automatically (and is part of the > > > review). > > > > Hear, hear!!! And add Suggests:/Recommends: (which is the other part of > > comps). > > > > +1000 > > +1001 ... > > I've just been involved with submitting a package for febootstrap to > Debian [yay, build Fedora images on Debian!], and I'm reminded yet > again what a good idea 'Suggests/Recommends' are. I can Suggest > packages like 'filelight' for measuring the effects of image > minimization, without making it a proper dependency and consequently > pulling in the whole of KDE. Indeed - Mandriva's had Suggests for a year or two now, and I found it extremely convenient in several packages I maintain(ed). Isn't it going into upstream RPM soon, or in there already? I had this idea that it was. We'd likely still need comps in some form, though. MDV has Suggests and enforces Group tags, and still uses something similar to comps for fine-tuning ISO builds. -- 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: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, May 26, 2009 at 09:29:31PM +, Matej Cepl wrote: > Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > > Can we please not remove the Group tag, it is actually quite usefull. > > What we need to remove / loose is comps. Having all this info in a > > centralized database is stupid. The spec files should tell which > > group(s) the package belongs in. So that when one adds a new package, > > this gets done right more or less automatically (and is part of the > > review). > > Hear, hear!!! And add Suggests:/Recommends: (which is the other part of > comps). > > +1000 +1001 ... I've just been involved with submitting a package for febootstrap to Debian [yay, build Fedora images on Debian!], and I'm reminded yet again what a good idea 'Suggests/Recommends' are. I can Suggest packages like 'filelight' for measuring the effects of image minimization, without making it a proper dependency and consequently pulling in the whole of KDE. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Jesse Keating, Tue, 26 May 2009 10:25:36 -0700: > Oh, Europe won't help much, there are just as many silly laws there as > there are in the US. Better is some special place in Europe thinking ... what about Isle of Man, it has some exceptions from many laws ... err, we wouldn't be first Linux distro headquatered there :) Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > Can we please not remove the Group tag, it is actually quite usefull. > What we need to remove / loose is comps. Having all this info in a > centralized database is stupid. The spec files should tell which > group(s) the package belongs in. So that when one adds a new package, > this gets done right more or less automatically (and is part of the > review). Hear, hear!!! And add Suggests:/Recommends: (which is the other part of comps). +1000 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
On Di Mai 26 2009, Joe Nall wrote:
> Or polyinstantiate /var/tmp
This is something that one cannot change in rpm. Nevertheless rpm has fixed
the problem in a similiar way, because instead of using a buildroot below
/var/tmp, one below %{topir}/BUILDROOT is used, which is hopefully not in some
world writable directory.
Regards
Till
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
Re: Removing %clean
On May 26, 2009, at 3:50 PM, Till Maas wrote: On Di Mai 26 2009, Björn Persson wrote: Tom "spot" Callaway wrote: mkdir -p `dirname "$RPM_BUILD_ROOT"`\ mkdir "$RPM_BUILD_ROOT"\ Is that somehow better than just «mkdir -p "$RPM_BUILD_ROOT"»? Just curious. It prevents a race condition in case that $(dirname "$RPM_BUILD_ROOT") already exists or if all directories in the path to this directory are only writable by trustworthy users. In the default configuration, this was the / var/tmp directory, where every user could create a directory, make it writable for others and sneak content into the final rpm. Here is an explation, why 'mkdir -p "$RPM_BUILD_ROOT"' is vulnerable: http://lists.opensuse.org/opensuse-packaging/2007-02/msg5.html Or polyinstantiate /var/tmp joe -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
On Di Mai 26 2009, Björn Persson wrote: > Tom "spot" Callaway wrote: > > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > > mkdir "$RPM_BUILD_ROOT"\ > > Is that somehow better than just «mkdir -p "$RPM_BUILD_ROOT"»? Just > curious. It prevents a race condition in case that $(dirname "$RPM_BUILD_ROOT") already exists or if all directories in the path to this directory are only writable by trustworthy users. In the default configuration, this was the /var/tmp directory, where every user could create a directory, make it writable for others and sneak content into the final rpm. Here is an explation, why 'mkdir -p "$RPM_BUILD_ROOT"' is vulnerable: http://lists.opensuse.org/opensuse-packaging/2007-02/msg5.html Regards Till 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
Re: thinkpad and acpi events
[choe...@choeger6 ~]$ lsmod | grep think thinkpad_acpi 53944 0 hwmon 2148 1 thinkpad_acpi Seems like it's there. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
Till Maas (opensou...@till.name) said: > On Di Mai 26 2009, Tom "spot" Callaway wrote: > > On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: > > > * Set the BuildRoot to / and cause massive system destruction > > What about setting BuildRoot to /home or /etc, this would case similiar > massive system destruction? Well, also only if you're building as root. Which you shouldn't do anyways. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
On Di Mai 26 2009, Tom "spot" Callaway wrote:
> On 05/26/2009 04:10 AM, Richard W.M. Jones wrote:
> * Set the BuildRoot to / and cause massive system destruction
What about setting BuildRoot to /home or /etc, this would case similiar
massive system destruction?
> %__spec_install_pre %{___build_pre}\
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
> mkdir -p `dirname "$RPM_BUILD_ROOT"`\
> mkdir "$RPM_BUILD_ROOT"\
> %{nil}
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> ...
>
> %install
> rm -rf %{buildroot}
> make DESTDIR=%{buildroot} install
> ...
>
> %clean
> rm -rf %{buildroot}
> ...
>
> TO:
>
> ...
> %install
> make DESTDIR=%{buildroot} install
> ...
> %clean
> ...
>
> Is anyone opposed to that?
I am not, but it is a little strange to me that now that rpm is fixed that
there is no race condition by default with "mkdir $RPM_BUILD_ROOT", why is it
then possible to fix this for older versions of rpm in Fedora? This has
already been discussed atleast in March 2007 on the Fedora packaging
mailinglist. Nevertheless, please do this change. :-)
Regards
Till
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
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 26 May 2009, Adam Williamson wrote: On Tue, 2009-05-26 at 16:20 -0400, Seth Vidal wrote: So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that (Will has done most of the implementing in the last MANY releases of preupgrade) Sorry, I wasn't clear - by "it" I was talking about yum. You're the guy who implements yum :) And a number of other people: James Antill and Tim Lauridisen to name just two important ones. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 2009-05-26 at 16:20 -0400, Seth Vidal wrote: > >> So, I have to google about preupgrade. It's the first time I hear about. > >> I did the upgrade via yum since F5 successfuly... > > > > Sure. As I said, practically speaking, it's likely to work in many > > cases. It's just that if you talk to the people most involved in > > implementing it (Seth) and testing it (Will) they will tell you that > > (Will has done most of the implementing in the last MANY releases of > preupgrade) Sorry, I wasn't clear - by "it" I was talking about yum. You're the guy who implements yum :) -- 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: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 26 May 2009, Adam Williamson wrote: On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that (Will has done most of the implementing in the last MANY releases of preupgrade) doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline. The biggest problem you are likely to run into with a yum-based upgrade is situations where updating something takes out the foundation on which yum is running. The fontconfig bug comes to mind. If you want to run yum quasi-safely run it from a terminal, in screen. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Dead package notice: freetype1
freetype1 is gone from F12. Nobody's currently using it, and more importantly nobody ought to be, anywhere, ever. - ajax 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
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: > > We don't consider issues which would cause upgrading from release to > > release via yum to be blockers, but issues which would cause upgrading > > via preupgrade to fail usually would be. > > So, I have to google about preupgrade. It's the first time I hear about. > I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline. -- 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: Removing %clean
Tom "spot" Callaway wrote: > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > mkdir "$RPM_BUILD_ROOT"\ Is that somehow better than just «mkdir -p "$RPM_BUILD_ROOT"»? Just curious. 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
Re: Removing %clean
> "TC" == Tom \"spot\" Callaway writes: TC> Is anyone opposed to that? It's hard to oppose anything that frees us from carrying around all of this useless crap in every specfile. If we ever want our packaging to be considered sane, we have to make progress towards getting rid of stuff we don't really need and dumping the inexplicable random stuff that just gets included verbatim in every specfile without most folks understanding why it's there. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Bill Nottingham wrote: Peter Lemenkov (lemen...@gmail.com) said: ... what exactly are you trying to accomplish? Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. Patents are *currently* illegal in Europe, (though they may be granted). The patents offices being self-funding and all that. http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention "Article 52" Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Williamson schrieb: > On Tue, 2009-05-26 at 10:39 +0200, Uwe Kiewel wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> I checked the ability to upgrade from F10 to F11 (Rawhide) directly >> using yum. A couple of weeks ago, there were dependency errors with >> python. These errors are not fixed until now. >> >> In my point of view, this issue should be fixed until GA of Leonidas. > > Others have explained what you should do to test this properly, but to > address your final point: QA's stance on this is that the only supported > upgrade methods are via the install images or preupgrade. Upgrade via > yum has the status "not explicitly supported but may well work". I know, it is not explicitly supported. But, if you have a tool that worked four you in the past fine, you expect that behaviour for the future ;-) It's human thinking :-) > We don't consider issues which would cause upgrading from release to > release via yum to be blockers, but issues which would cause upgrading > via preupgrade to fail usually would be. So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Thanks, Uwe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShxAYkJXG7BUuynnAQIN3RAAyssNfDr1wxvq2HeAIR2FzPiPB0Hjr6J/ 7G6CpQ4M4vQbU00cJZNDxh5NgOmbK2DTUIa0Ije/gVDSEjvs7RD31o5hUp8DsUkj u+21e+V/wI1YSXJvTrjBxzxqaELwAsoPsn18f26xxO8mFqWKufgoal6yFutL9vIO f6VD9DLA72lrhhSh43AbGtTgdbHYd49Me5rtdd3SgdlIfjGj0RnU+CNdVnUc9B59 HJ5knXMUhywrumZlGtAnXp3p2WBA3A5QNRHzScI82tossfuy6ios4NiCc3ONuIAn p7gTsJoVu2dsc2DzKLkc3n9P54l8b+eskB4jZpOQc4cm+x7SdqSePrzSKiFZ6sDg oXD86N12IBIUezSffBf5si6atMnLY+FJ+UO522SxKt1bKNLwGSIUBayMKn02Drbu hMJRlmfCFkSWIJHKc1cFMJEyZMDOKjJG/t+hWtoA/S9WzRws57zMtmpLsKy8vBAL lRiHY5NABsLPo/xXJAIoiO5oPSDy7tdWLaVVtTvQMm/wEQ7vcKJN8pXrlfssklBb LspMRMHvwYoHJijXofBGnqQ7/NnAZdmaE419fxZ0UGm68LmcY0/gGElewiRHUr1U VvNIOBXY8wng7yjQxFfBVCqSyca6kWMZsicIhBnAMDCN9sqLqAcWVICdyHHXnlSG +Z/7Q7kipuA= =koHu -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting)
On Tue, May 26, 2009 at 03:02:47PM -0400, Tom spot Callaway wrote: > Is anyone opposed to that? Sounds like a very reasonable proposal. I'll note that Debian packages include a minimum compatible standards (version) number. The RPM equivalent would I suppose be something like: Min-RPM: 4.4 RPM would check this and refuse to run if its version number was less than this, and of course older versions of RPM would fail completely when they see this header[1]. 'Course we'd have to educate people not to just remove the header or diddle around with the version number at random 'until it works'. Which maybe makes the proposal not completely idiot proof. Rich. [1] Or do they ..? I checked and they give this error: error: line 7: Unknown tag: Min-RPM:1.1 -- Richard Jones, Emerging Technologies, Red Hat http://et.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/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting)
On 05/26/2009 04:10 AM, Richard W.M. Jones wrote:
> I vote for also removing the %clean section.
So, looking at this objectively, here are the technical problems:
* We're defining a BuildRoot in the spec, but that definition is no
longer used (Fedora 10 or higher), because rpm now automagically sets it
for us.
* We're typing rm -rf %{buildroot} multiple times in every single Fedora
specfile. We want to invoke it twice:
- As the very first operation of the %install scriptlet
- As the very first operation of the %clean scriptlet
The concerns around removing the BuildRoot from the spec is that if that
spec is taken to an older system, the spec would either
* Not work
* Set the BuildRoot to / and cause massive system destruction
The good news is that for all the Fedora targets that we care about, if
BuildRoot is unset, it is just unset. It never gets set to / on anything
we care about (including RHEL 4 and 5, I checked).
And I really don't think we need to care about anything older than RHEL
4 (roughly equivalent to Fedora 6). A comment in the packaging
guidelines should be sufficient, so simply dropping the unnecessary
BuildRoot definition as soon as Fedora 9 is EOL seems like a sane course
of action.
The %install scriptlet case is reasonably simple to solve with
redhat-rpm-config's customized macros file, simply add:
%__spec_install_pre %{___build_pre}\
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
mkdir -p `dirname "$RPM_BUILD_ROOT"`\
mkdir "$RPM_BUILD_ROOT"\
%{nil}
This ensures that every time %install is invoked in a spec file, it
checks that buildroot isn't / (which, it should never ever be, but given
the past history, doesn't hurt to check), then deletes it. Next, it
makes the basedir of $RPM_BUILD_ROOT, in case that doesn't exist, then
makes the buildroot for us, saving additional pain in some Fedora spec
files where the make install process is either too dumb to do this for
us (or non-existant).
The %clean scriptlet case is harder. Lets get the easy case out of the
way, removing the obligatory rm -rf %{buildroot} invocation:
%__spec_clean_pre %{___build_pre}\
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
%{nil}
With that, every time %clean is invoked in a spec file, it checks that
buildroot isn't /, and then deletes it if it is not.
However, that doesn't really resolve the deeper desire, which is as
Richard points out, is to remove the need to explicitly state the %clean
section at all. If we need to overload it beyond its defaults, we should
be able to invoke it manually and append to it, but if it is not set, it
should be invoked automagically.
RPM doesn't act this way. For all scriptlets, their absence does not
result in automatic invocation (there is no idea of "always executed"
default scriptlets in a spec), but instead is how they are omitted. I
can certainly see valid use cases where a package would not want %clean
to be invoked. It might be possible to change RPM's behavior to
introduce a disabler mechanism for default "always executed" scriptlets:
%disable %check
This would be a significant behavior change for RPM, and not something
we could do with distribution specific macro tweaks. It would also break
backwards compatibility with older RPM spec files, which has
traditionally been avoided.
*
So, given those facts, and assuming that RPM isn't changing its
behaviors anytime soon, we can make macro changes in redhat-rpm-config
and change from this:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
...
%install
rm -rf %{buildroot}
make DESTDIR=%{buildroot} install
...
%clean
rm -rf %{buildroot}
...
TO:
...
%install
make DESTDIR=%{buildroot} install
...
%clean
...
Is anyone opposed to that?
~spot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 02:39 PM, Chris Adams wrote: > Once upon a time, Tom spot Callaway said: >> Historically, we've only highlighted the export details onto people who >> are likely to redistribute Fedora as part of their normal activities >> (FreeMedia, Mirrors), but there is no reason we can't make it clear to >> everyone who signs the CLA. > > IIRC mirrors are not required to sign the CLA (I did, but that was > because I was working towards being a packager as well). Yes, but they are presented with the export restrictions. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 26 May 2009, Stephen Gallagher wrote: Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. 1) Your packets will still flow through the US anyway. 2) The US claim jurisdiction even outside their national borders and reserve the right to prosecute "offenses against American interests" according to US law, irrespective of where they take place. In other words, you could be extradited even if the offense would not actually be an offense in your country. For example, Dutch people have been extradited for selling drugs to US citizens in The Netherlands, even though marihuana is legal. (well, "its complicated") Also, you could never set foot in the US again without getting arrested, and most of us don't think those T-6 countries are worh that. Is there a reason that an interested party (in a locale where such export is legal) couldn't just create a custom spin on their own (and using their own build system) to create a Fedora-T6 spin (or for trademark reasons, rebrand it)? I can see this being a perfectly good premise for setting up a SIG... respin what? remove the crypto? Try removing nss, openssl, gnutls and kerberos and see what's left of your system. Not much :P And who would want it? Surely not the T6 countries :P Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009, Michael Schwendt wrote: On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: Michael Schwendt wrote: [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] Actually no, as the mirrorlists redirect you automatically. Well, great, but whatever very went wrong for Uwe (the OP), his Yum couldn't read the new XML mirrorlist and therefore couldn't construct a valid baseurl for "fedora" and other repos. From f10's yum? Can I get a yum version number for what he's running? I think F10 GA had 3.2.20 in it.. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 2009-05-26 at 13:29 -0400, Bill Nottingham wrote: > Peter Lemenkov (lemen...@gmail.com) said: > > >> Subj. As Debian folks did years ago. Such branching will be done very > > >> easy technically. > > > > > > Because all the builds and composition is done in the US, and the > > > trademarks > > > are held by a US entity. > > > > Not a serious reason. Why not to relocate then in Europe? > > ... what exactly are you trying to accomplish? ...that isn't achieved, in practical terms, just as well by the existence of RPMFusion? -- 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: export policy, was Re: Package Maintainers Flags policy
Once upon a time, Tom spot Callaway said: > Historically, we've only highlighted the export details onto people who > are likely to redistribute Fedora as part of their normal activities > (FreeMedia, Mirrors), but there is no reason we can't make it clear to > everyone who signs the CLA. IIRC mirrors are not required to sign the CLA (I did, but that was because I was working towards being a packager as well). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: > Michael Schwendt wrote: > > [And as long as there is no F11 GA repo yet, you need to enable rawhide > > manually.] > > Actually no, as the mirrorlists redirect you automatically. Well, great, but whatever very went wrong for Uwe (the OP), his Yum couldn't read the new XML mirrorlist and therefore couldn't construct a valid baseurl for "fedora" and other repos. > YumRepo Error: All mirror URLs are not using ftp, http[s] or file. > Eg. / > removing mirrorlist with no valid mirrors: > //var/cache/yum/fedora/mirrorlist.txt > Error: Cannot find a valid baseurl for repo: fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: compat c++
On Tuesday 26 May 2009, Jussi Lehtola wrote: > On Tue, 2009-05-26 at 17:11 +0200, Christoph Höger wrote: > > Hi, > > > > I was just wondering, if there is a compat c++ compiler package (or > > mode) available in fedora. The issue I encountered was that I got a lot > > of compiler errors because of strdup() malloc() etc. usages in c++ files > > without proper #include stuff. > > I am not a C++ expert, but I guess that there was a default behavior > > change between g++ 3 and 4. > > The best thing to do would of course be patching the code to respect the > standards, but you can > > # yum -y install compat-gcc-34-c++ > > and use g++34 in the mean time. ...or try if -fpermissive (applied selectively where needed) helps with the newer one. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 2009-05-26 at 10:39 +0200, Uwe Kiewel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I checked the ability to upgrade from F10 to F11 (Rawhide) directly > using yum. A couple of weeks ago, there were dependency errors with > python. These errors are not fixed until now. > > In my point of view, this issue should be fixed until GA of Leonidas. Others have explained what you should do to test this properly, but to address your final point: QA's stance on this is that the only supported upgrade methods are via the install images or preupgrade. Upgrade via yum has the status "not explicitly supported but may well work". We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. -- 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: rawhide report: 20090523 changes
On Tue, 2009-05-26 at 19:12 +0200, Till Maas wrote: > On Di Mai 26 2009, Bill Nottingham wrote: > > Kevin Kofler (kevin.kof...@chello.at) said: > > > Yet another insecure temporary file vulnerability. Why do we still not > > > polyinstantiate /tmp by default? We're wasting lots of time on security > > > measures which keep breaking apps such as SELinux, but simple things like > > > polyinstantiation are still not used, why? This code would be perfectly > > > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? > > > > ... send patches? It's techncially feasible, but no one's done the > > legwork to integrate it fully yet. > > It is already done on the Fedorapeople server: > https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Hey, nice. That should really be an F12 feature. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Chris Weyl wrote: > A US corporation is subject to US law no matter where it operates. Sounds > serious to me :) I think the idea is to found a Fedora foundation outside of the US to own Fedora instead of RH. The reason given for not creating a foundation was that US tax laws are problematic, creating it outside of the US would mean favorable tax laws could be chosen as well. That said, RH may still get into trouble for contributory infringement, and with a non-US foundation, RH may even get accused of tax evasion, so I'm not that surprised they aren't thrilled by the idea. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
> "J" == Jason L Tibbitts writes: J> The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC J> in the #fedora-meeting channel on chat.freenode.net. Due to lack of quorum, this meeting is postponed to Tuesday, 2009-06-02. I will send an updated agenda as the meeting approaches. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Stephen Gallagher (sgall...@redhat.com) said: > Is there a reason that an interested party (in a locale where such > export is legal) couldn't just create a custom spin on their own (and > using their own build system) to create a Fedora-T6 spin (or for > trademark reasons, rebrand it)? I can see this being a perfectly good > premise for setting up a SIG... The SIG would be under the auspices of the Fedora project, return to step 1, do not pass go. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On 05/26/2009 01:25 PM, Jesse Keating wrote: > On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: >> 2009/5/26 Bill Nottingham : >> Subj. As Debian folks did years ago. Such branching will be done very easy technically. >>> Because all the builds and composition is done in the US, and the trademarks >>> are held by a US entity. >> Not a serious reason. Why not to relocate then in Europe? >> >> >> -- >> With best regards! >> > > Find us a Company in Europe that is not based in the US that is willing > to fund with people and money as much as Red Hat is doing now. > > Oh, Europe won't help much, there are just as many silly laws there as > there are in the US. > > Is there a reason that an interested party (in a locale where such export is legal) couldn't just create a custom spin on their own (and using their own build system) to create a Fedora-T6 spin (or for trademark reasons, rebrand it)? I can see this being a perfectly good premise for setting up a SIG... -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
Michael Schwendt wrote: > [And as long as there is no F11 GA repo yet, you need to enable rawhide > manually.] Actually no, as the mirrorlists redirect you automatically. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, May 26, 2009 at 10:10 AM, Peter Lemenkov wrote: > 2009/5/26 Bill Nottingham : > > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the > trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? > A US corporation is subject to US law no matter where it operates. Sounds serious to me :) -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Peter Lemenkov (lemen...@gmail.com) said: > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? ... what exactly are you trying to accomplish? Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. Make it so we can ship to various T-6 countries? I'm sure many European countries have their own lists as well. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: > 2009/5/26 Bill Nottingham : > > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? > > > -- > With best regards! > Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. -- 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-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090523 changes
On Di Mai 26 2009, Bill Nottingham wrote: > Kevin Kofler (kevin.kof...@chello.at) said: > > Yet another insecure temporary file vulnerability. Why do we still not > > polyinstantiate /tmp by default? We're wasting lots of time on security > > measures which keep breaking apps such as SELinux, but simple things like > > polyinstantiation are still not used, why? This code would be perfectly > > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? > > ... send patches? It's techncially feasible, but no one's done the > legwork to integrate it fully yet. It is already done on the Fedorapeople server: https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Regards Till 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
Re: Why not to create Fedora-us and Fedora-non-us branches?
2009/5/26 Bill Nottingham : >> Subj. As Debian folks did years ago. Such branching will be done very >> easy technically. > > Because all the builds and composition is done in the US, and the trademarks > are held by a US entity. Not a serious reason. Why not to relocate then in Europe? -- With best regards! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Peter Lemenkov (lemen...@gmail.com) said: > Subj. As Debian folks did years ago. Such branching will be done very > easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
Johan Cwiklinski (maili...@x-tnd.be) said: > Considering this, I'm not sure simply removing flags for gcompris is the > thing to do. > > Any thoughts ? It's the right thing from a UI standpoint. That dialog is horrible. Here's an example, when started in es_MX.UTF-8: http://notting.fedorapeople.org/gcompris.png 1) I started it in the locale of the largest Spanish-speaking population on the globe. So I get a (broken) flag image for an entirely different country? 2) Say I'm a child who can't read the language but is supposed to pick the language via flag. Not only is it not using a flag that I'd recognize in my locale, how am I even supposed to know that it's a language configuration area? There's no other information other than a name of the language (or 'your system default', which also isn't going to make a lot of sense to most kids) 3) There's also entries there to change the timing of the game, the skin, whether to have music or sound effects, etc. None of these have iconographic representations to make them usable by the pre-literate set. So yes, long term, the flags should be removed. Ideally, upstream would be convinced to do it. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Why not to create Fedora-us and Fedora-non-us branches?
Subj. As Debian folks did years ago. Such branching will be done very easy technically. -- With best regards! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090523 changes
Kevin Kofler (kevin.kof...@chello.at) said: > Yet another insecure temporary file vulnerability. Why do we still not > polyinstantiate /tmp by default? We're wasting lots of time on security > measures which keep breaking apps such as SELinux, but simple things like > polyinstantiation are still not used, why? This code would be perfectly > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? ... send patches? It's techncially feasible, but no one's done the legwork to integrate it fully yet. (xguest goes a bit beyond what we'd want by default.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 12:13 PM, Mathieu Bridon (bochecha) wrote: >> The penalties for export violation are steep and >> serious, which is why all Fedora contributors are required to abide by >> the export policies. > > Maybe this should be mentioned in the CLA ? We (Fedora contributors) > have to sign it. Specifying it there would make it more widely known, > and could provide a way to make contributors respect it (as they > agreed and signed the CLA). > > Unless I miss it, it is not mentioned: > https://fedoraproject.org/wiki/Legal/Licenses/CLA Nope. We'll definitely take that into consideration as we rework the CLA. Historically, we've only highlighted the export details onto people who are likely to redistribute Fedora as part of their normal activities (FreeMedia, Mirrors), but there is no reason we can't make it clear to everyone who signs the CLA. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
> The penalties for export violation are steep and > serious, which is why all Fedora contributors are required to abide by > the export policies. Maybe this should be mentioned in the CLA ? We (Fedora contributors) have to sign it. Specifying it there would make it more widely known, and could provide a way to make contributors respect it (as they agreed and signed the CLA). Unless I miss it, it is not mentioned: https://fedoraproject.org/wiki/Legal/Licenses/CLA Regards, -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
Jesse Keating wrote: On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). ACK. Instead of abandoning rpm-Groups, it should be strengthened and comps be made strictly optional. Defining groups in the package is broken because different consumers of of the packages may wish to group those packages in different ways. When you define it in the package, you have to rebuild the package just to change how they're grouped. That's one of the big reasons why grouping should be done outside of the packages. Comps and Groups are addressing completely different issues. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 08:24:13 -0500, Bruno wrote: > updates and updates-testing are normal and are at the mirrors. For Everything > there is a fudge in the mirror list to point at f11 rawhide until GA. > Rawhide should move to f12 very soon now, so you probably don't want to > point to the rawhide repo unless you are careful. Is the Yum from F10 updates-testing needed to understand the XML mirrorlists? https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: compat c++
On Tue, 2009-05-26 at 17:11 +0200, Christoph Höger wrote: > Hi, > > I was just wondering, if there is a compat c++ compiler package (or > mode) available in fedora. The issue I encountered was that I got a lot > of compiler errors because of strdup() malloc() etc. usages in c++ files > without proper #include stuff. > I am not a C++ expert, but I guess that there was a default behavior > change between g++ 3 and 4. The best thing to do would of course be patching the code to respect the standards, but you can # yum -y install compat-gcc-34-c++ and use g++34 in the mean time. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: > > Can we please not remove the Group tag, it is actually quite usefull. > What we need to remove / loose is comps. Having all this info in a > centralized database is stupid. The spec files should tell which > group(s) the package belongs in. So that when one adds a new package, > this gets done right more or less automatically (and is part of the > review). Defining groups in the package is broken because different consumers of of the packages may wish to group those packages in different ways. When you define it in the package, you have to rebuild the package just to change how they're grouped. That's one of the big reasons why grouping should be done outside of the packages. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) 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
Re: unowned files and directories
On Sat, May 23, 2009 at 1:46 PM, Thorsten Leemhuis wrote: > > (¹) the list also leads to question like "why are there /.dbus and > /.pulse?" My guess is some code in the installation process running as root with $HOME set to "/" is trying to connect to the DBus session bus. For compatibility with some unfortunate scenarios libdbus will attempt to auto-launch a bus using dbus-launch which will then create ~/.dbus. I assume pulse is similar (ideally pulse uses dbus, then we only have this bug once, but that's another discussion). Something trying to talk to the session bus sound familiar to anyone working on the installer? If we can set $HOME to /root that would sidestep most of the issues, alternatively in libdbus we could avoid autolaunching for root, since it should never be needed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
compat c++
Hi, I was just wondering, if there is a compat c++ compiler package (or mode) available in fedora. The issue I encountered was that I got a lot of compiler errors because of strdup() malloc() etc. usages in c++ files without proper #include stuff. I am not a C++ expert, but I guess that there was a default behavior change between g++ 3 and 4. What I did was patching that package to get those #includes but as it contains a c++ code generator I also had to patch that. Although it seems to compile now, I still get zillions of "DO NOT CAST char* TO string YOU FOOL" warnings (wasn't there an option to get rid of them too?). Any kind of compat mode would make things alot easier (besides bringing the developers to write propert C++). regards christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, May 26, 2009 at 11:43:54 +0200, Uwe Kiewel wrote: > > I know this procedure. Do we have the F11 repos yet? I don't think so, > because F11 is not GA. updates and updates-testing are normal and are at the mirrors. For Everything there is a fudge in the mirror list to point at f11 rawhide until GA. Rawhide should move to f12 very soon now, so you probably don't want to point to the rawhide repo unless you are careful. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thinkpad and acpi events
2009/5/26 Christoph Höger : > Hi all, > > I encounter a little weirdness with the recent (aka > 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on > lid-shut nor reaction on power button work. It seems to me that there a > no events registered by the driver. Does anyone else see that? > Is there a way to log that events? > > regards > > christoph I noticed something similar on a T41, I think that the thinkpad_acpi(or whatever it's name was) module wasn't loaded. Didn't have the time to look in to it. Can you check the loaded modules? -- NV -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 07:39 PM, Paul Wouters wrote: > > This is technically a violation of GPL, and could mean that > anyone distributing Fedora with those restrictions has lost their rights > to use and/or distribute the GPL software contained within Fedora.here > they take place. FSF doesn't seem to think so http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009, Michael Schwendt wrote: On Tue, 26 May 2009 08:24:13 -0500, Bruno wrote: updates and updates-testing are normal and are at the mirrors. For Everything there is a fudge in the mirror list to point at f11 rawhide until GA. Rawhide should move to f12 very soon now, so you probably don't want to point to the rawhide repo unless you are careful. Is the Yum from F10 updates-testing needed to understand the XML mirrorlists? https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 yum 3.2.20 in f10-GA should work mostly fine. There have been some bug fixes since then but the majority of them are in the yum in updates released for F10. I know you don't need the version in updates-testing to read the metalinks. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 10:09 AM, Paul Wouters wrote: > See above. Note that the Wassenaar Agreement excludes software that is > in the "public domain", eg free/open source software. This is not correct. "Public Domain" has a very specific legal meaning, and 99% of FOSS does _not_ meet it. Public Domain is when the copyright holder has explicitly abandoned his/her/its copyright on the work and placed it into the Public Domain. (Note: In some countries, such as Germany, this is impossible) >> You may not download Fedora software or >> technical information if you are located in one of these countries, or >> otherwise affected by these restrictions. You may not provide Fedora >> software or technical information to individuals or entities located in >> one of these countries or otherwise affected by these restrictions. You >> are also responsible for compliance with foreign law requirements >> applicable to the import and use of Fedora software and technical >> information." > > This is just boilerplate for more "US law applies to non-US citizens > because we say so" doctrine. Keeping in mind the complexities of US export law are many, people who are directly affiliated with a US company are still required to follow US export law, or the US company can face serious legal risks (even if the non-US citizen who violates US export laws does not directly face any risk, or a minimized risk). In such a scenario, the individual could be perceived to have been acting as an agent of Fedora (Red Hat), making Red Hat liable. The penalties for export violation are steep and serious, which is why all Fedora contributors are required to abide by the export policies. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thinkpad and acpi events
Hi all, I encounter a little weirdness with the recent (aka 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on lid-shut nor reaction on power button work. It seems to me that there a no events registered by the driver. Does anyone else see that? Is there a way to log that events? regards christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Martes 26 Mayo 2009 15:44:56 Matthias Clasen escribió: > On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: > > Seems like direct DBus communication is the only way to do it from Qt/KDE > > apps as PolKit library requires gtk_init() somewhere in code... I've > > prepared patch for polkit-qt to the new PK1 Core API but... Or is there > > any other way to initialize glib without need for it? I'm not familiar > > with GTK app development... But library that expects gtk_init somewhere > > in application to be correctly intialized... > > Calling g_type_init() should be enough; there is no direct GTK+ > dependency in polkit-gobject. Even g_type_init() may be too much for KDE > apps to swallow though, so going directly to the bus is still a good > idea. Thanks, I'll try it. Shouldn't library do the proper initialization? Then it's OK for us and it's better for other nongtk projects (not only KDE) - I think once we have library it's useless to duplicate work. But we agreed with upstream that directly using dbus is best for us but first I tried to do port line by line according to your patches/docs/porting guide... > > PK1 should be split into parts - cross-desktop backends should be on > > freedesktop, gnome specific libraries should be in gnome repository. This > > should stop confusion. > > You mean like > > http://cgit.freedesktop.org/PolicyKit > http://git.gnome.org/cgit/PolicyKit-gnome > I thought polkit library which depends on glib initialization is not right cross desktop solution... 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
export policy, was Re: Package Maintainers Flags policy
On Tue, 26 May 2009, Tom "spot" Callaway wrote: Though I am also not a lawyer, I did look into things, being upstream for openswan and an author of a book containing crypto, a rather crypto heavy application and book... There are 6 countries that Fedora cannot be legally exported to (as a result of US export restrictions): Cuba, Iran, Iraq, North Korea, Sudan and Syria I think technically, this restriction only applies on the export of the software out of the US. For those outside the US, US law/doctrine does not apply (even though the US claims it does). Rather, for most Western countries, implementation of the Wassenaar Agreement in local law applies, where some countries have extended the export restrictios as set forth in the Wassenaar Agreement. In Europe, there is also the European Union Dual-Use Export laws. These are known as the "T-6" countries. No individual associated with the Fedora project (or mirror site) should provide Fedora software to anyone in those countries, even if they are not in the US. This is again US doctrine. It becomes even stranger as in my case, Fedora imports openswan from The Netherlands, and then tells me I could not obtain my own GPL licensed code to do what is legal within my country? Though in this case, there is a large overlap of implementation of the Wassenaar Agreement. "Because Fedora software contains encryption technology, Fedora software and technical information is subject to the U.S. Export Administration Regulations and other U.S. and foreign law, and may not be exported or re-exported to certain countries (currently Cuba, Iran, Iraq, North Korea, Sudan and Syria) See above. Note that the Wassenaar Agreement excludes software that is in the "public domain", eg free/open source software. or to persons or entities prohibited from receiving U.S. exports (including those (a) on the Bureau of Industry and Security Denied Parties List or Entity List, (b) on the Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons, and (c) involved with missile technology or nuclear, chemical or biological weapons). This is technically a violation of GPL, and could mean that anyone distributing Fedora with those restrictions has lost their rights to use and/or distribute the GPL software contained within Fedora. You may not download Fedora software or technical information if you are located in one of these countries, or otherwise affected by these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise affected by these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import and use of Fedora software and technical information." This is just boilerplate for more "US law applies to non-US citizens because we say so" doctrine. Though it does not apply to non-US citizens, there is a risk. I formulated it like this in the Openswan book: Unrecognised international claims Certain countries claim jurisdiction even outside their national borders. Most notably, France claims the right to “regulate information on foreign servers”, Italy assumes jurisdiction over sites "directed to an Italian audience" and the US reserve the right to prosecute "offenses against American interests" according to US law, irrespective of where they take place. You may want to consider the possibility that you can be sued or prosecuted in another country. Additionally, if you are physically in a country other than the Netherlands when you download our software, you are probably subject to that country's jurisdiction anyway. And if your download happens to pass a router under US control (say in Guam), the US might make additional claims to rights for restriction of your packets or even your person. Note that this text was written a few years ago. For an updated situation, one should probably consult their local lawyer, please the updates from http://www.wassenaar.org/ Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to create header.info file
On Tue, 26 May 2009, Pavel Lisy wrote: Hello I've made my repository for CentOS (3/4/5) with createrepo version 0.4.9. It makes these files repodata/filelists.xml.gz repodata/other.xml.gz repodata/primary.xml.gz repodata/repomd.xml Yum is working fine but on RHEL 4 I've got this error from up2date An HTTP error occurred: URL: http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info Status Code: 404 Error Message: Not Found How can I create this file and other files in headers directory? There is nothing in createrepo docs about these files. 1. this is not a fedora-devel question. 2. You can ask on the centos lists about this but a short answer though is - look up about yum-arch I will not respond to any other questions about the above on this list. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090526 changes
Compose started at Tue May 26 06:15:03 UTC 2009 Removed package CastPodder Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 0 Broken deps for ppc64 -- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
How to create header.info file
Hello I've made my repository for CentOS (3/4/5) with createrepo version 0.4.9. It makes these files repodata/filelists.xml.gz repodata/other.xml.gz repodata/primary.xml.gz repodata/repomd.xml Yum is working fine but on RHEL 4 I've got this error from up2date An HTTP error occurred: URL: http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info Status Code: 404 Error Message: Not Found How can I create this file and other files in headers directory? There is nothing in createrepo docs about these files. Can anybody help me? Pavel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: > > Seems like direct DBus communication is the only way to do it from Qt/KDE > apps > as PolKit library requires gtk_init() somewhere in code... I've prepared > patch for polkit-qt to the new PK1 Core API but... Or is there any other way > to initialize glib without need for it? I'm not familiar with GTK app > development... But library that expects gtk_init somewhere in application to > be correctly intialized... Calling g_type_init() should be enough; there is no direct GTK+ dependency in polkit-gobject. Even g_type_init() may be too much for KDE apps to swallow though, so going directly to the bus is still a good idea. > PK1 should be split into parts - cross-desktop backends should be on > freedesktop, gnome specific libraries should be in gnome repository. This > should stop confusion. You mean like http://cgit.freedesktop.org/PolicyKit http://git.gnome.org/cgit/PolicyKit-gnome ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Conflicts not being resolved
On Tue, 26 May 2009, Tom \"spot\" Callaway wrote: This seems like a great place for someone who is looking for a way to help out Fedora to work on, closing out these bugs. I wrote a script to dump out "potential file conflicts". This needs to be dumped into the auto-qa work so we can look for file conflicts w/o explicit pkg conflicts automatically. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Martes 26 Mayo 2009 11:16:14 Daniel P. Berrange escribió: > On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > > | From: Rex Dieter > > | > > | Seems frustrations are mounting: > > | "On policykit and standards" > > | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html > > > > [I'm an outsider. This thread is my introduction to the whole area. > > I'm not even a KDE user.] > > > > This certainly does not look like a healthy approach to standardization > > and cooperation. > > > > - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > > appears clearly biased towards GNOME, even though its URL and title > > suggest universality: the first substantial line talks about > > polkit-gobject-1 (I *think* that gobject means GNOME object) > > > > - in a well-constituted standards process (not a de facto standard), > > stakeholders are consulted before changes are made. It looks > > as if KDE folks have been stakeholders and have not been allowed to > > even sign-off on the design, let alone participate in it. > > > > - for good reason, the normal output of a standardization process is a > > document, not code. There appears to be no complete documentation. > > > > - all stakeholders ought to be treated respectfully and equitably. > > That means, for example, KDE ought not the be second to GNOME. > > More particularly, the architectures should be open-ended, allowing > > for more than KDE and GNOME. See, for example, > > http://c2.com/cgi/wiki?ZeroOneInfinityRule > > > > I admit that my reactions may be ill-founded. Perhaps this is meant > > You are attempting to create problems here which don't exist. David > has already pointed out in another mail that if apps don't want to use > the glib based library, they can talk to DBus directly. There are native > QT bindings for DBus, and pretty much any other language can talk to > DBus too with no deps on glib / gobject. Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized... PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion. Jaroslav > Daniel > -- > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ > |: :| http://libvirt.org -o- http://virt-manager.org -o- > |: http://ovirt.org :| http://autobuild.org -o- > |: http://search.cpan.org/~danberr/ :| GnuPG: 7D3B9505 -o- F3C9 553F A1DA > |: 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Package Maintainers Flags policy
On 05/23/2009 03:45 PM, Christopher Stone wrote: > What are the T-6 restrictions? A google search only came up with this thread. There are 6 countries that Fedora cannot be legally exported to (as a result of US export restrictions): Cuba, Iran, Iraq, North Korea, Sudan and Syria These are known as the "T-6" countries. No individual associated with the Fedora project (or mirror site) should provide Fedora software to anyone in those countries, even if they are not in the US. Here's the full legal paragraph: "Because Fedora software contains encryption technology, Fedora software and technical information is subject to the U.S. Export Administration Regulations and other U.S. and foreign law, and may not be exported or re-exported to certain countries (currently Cuba, Iran, Iraq, North Korea, Sudan and Syria) or to persons or entities prohibited from receiving U.S. exports (including those (a) on the Bureau of Industry and Security Denied Parties List or Entity List, (b) on the Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons, and (c) involved with missile technology or nuclear, chemical or biological weapons). You may not download Fedora software or technical information if you are located in one of these countries, or otherwise affected by these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise affected by these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import and use of Fedora software and technical information." Tom "spot" Callaway, Fedora Legal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package Maintainers Flags policy
On 05/22/2009 03:04 PM, Frank Murphy wrote: > 1: Has the flags policy, anything to do with RH becoming more prominent > on the site? > No problem with them becoming more prominent, they do sponsor a lot. > If yes, say so, likewise no No. The fact that I authored the original flag policy had more to do with my awareness of the prior unwritten "no flags" policy, and nothing at all to do with Red Hat. Red Hat Legal did offer advice as to some of the wording, but they did not mandate it, nor did Red Hat instigate the creation of the flag policy. > 2: Would our main Sponsor, suffer financially. > As a result of inclusion of certain flags? No. As Adam said, having a "no flags" policy would make things slightly simpler for Red Hat to compose RHEL, but not enough to suffer any significant financial consequence. > 3: Would the fedora project survive, if there was no main sponsor? Thankfully, this is a problem we do not have to be concerned about for the time being. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Breaking deps deliberately
On 05/23/2009 11:03 AM, Braden McDaniel wrote: > I didn't know about this until this subthread... and I asked a rather > senior packaging person about it some months ago and didn't get this > information. So I think this is poorly publicized; and perhaps poorly > positioned in the packaging guidelines. Always possible. I'm the first to admit that the packaging guidelines need a thorough reorganization. The information is documented here: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches Suggestions on improvements are always welcomed (as long as they are constructive). ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Conflicts not being resolved
On 05/23/2009 06:37 AM, Michael Schwendt wrote: > https://fedoraproject.org/wiki/Packaging/Conflicts > https://fedoraproject.org/wiki/Packaging/Conflicts#Other_Uses_of_Conflicts: > > | As a general rule, Fedora packages must NOT contain any usage of the > | Conflicts: field. > > | Keep in mind that implicit conflicts are NEVER acceptable. > > | If your package conflicts with another package, then you must either > | resolve the conflict, or mark it with Conflicts:. > > What happens so far is that packagers simply ignore it. > Again I see bz tickets from Nov 2008 which have not been responded to. > > The page doesn't point out that missing "Conflicts" tags are bad. > Implicit conflicts are not detected prior to an RPM transaction check. > Typically, implicit conflicts cause tools like Yum to fail, leaving it > to the user to do the head-scratching and to remove packages manually. This seems like a great place for someone who is looking for a way to help out Fedora to work on, closing out these bugs. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 12:14 PM, Rahul Sundaram wrote: On 05/26/2009 03:38 PM, Panu Matilainen wrote: Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. That's great. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under "Unspecified" but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. Yes, the packaging/review guidelines only care about comps grouping and not the Group tag. So for many packages, it is pretty arbitrary. I guess, we can just lose both build root and group tag to reduce noise. Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). I actually use a script checking for rpms with the Amusements/Games group which are not in the comps games group, nor in a blacklist I keep. Each time I run this, this results in me adding a few games to comps which people forgot to add. comps is broken, really it is, this whole central database concept sucks. I'm not saying the rpm Group tag is the answer, but we should search for an answer which consists of putting the data inside the spec file. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > >> rpm -Uvh >> ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm >> > > And to add some trouble-shooting myself, this new fedora-release package > points to a mirrorlist URL that returns an XML file instead of the old > plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to > handle it. But that doesn't prove that hardcoding the F11 repository > baseurls would not work. Especially if above you choose a local mirror > already anyway. > I think, thats the point, why it would no be possible to go the way described in http://fedoraproject.org/wiki/YumUpgradeFaq (yet) I will try it again after Leonidas is GA - expecting it won't work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvMdEJXG7BUuynnAQJ4pxAAjHKgNDOfDyh/8S0vUu9Gs75sZusJh+jW Y9Otp1EM7Kcwlo5HXLdqouBaL92mCumtmApU14a7emZ6e7IrnvhstDNHv4wAmXey 1JHnBCYh/8WygMkZRgoW6oWjsgNXBBbQNwJi64lfFxWfBKk+JUmcT1tiBcXLw57P OOaMN/IcERglmvvaJt5w2eaTd7rRIqf8ikn02bKvX4TTOWzCueE0Mp2y45rkgcRh OKINsulviRx8S8abzh7n2Ntg4GiIG60D5hOfT4OyCnBfQUP3uSm6ksPz72RBDyy6 FyAH0iMSwfzNTywEUmYcBvqjC9jLQNiRdZzQ7uAHKKliwGT9S+n/sSoHZCqyCn1f jWUvFmwQ3J3fTOUCavvVAo1PTakieNjwepriwIsvWdvGP4sRJD8pU5/RxCkqNkx2 DyMe5CFTdaaxdmkXKHQClRH+4pOPAQ7HvF4/RjHwM2UxB7D5TiA8tRA29Ok6WEJp EEhm0UrUZqD7JV1xPFuW8St6tM8olBcss0JZOu/NctDp/dzUQ5zq/Qu+P4lBs5PY Q9YMbc/1nkFZ+BRQ1B87D5BU7s/OYeH8viFbBYdlwD/IpnTJVy/0wxoxrRK9DGZH ghzx51t03iYPmGC9QHAV3eWTHK6xGYKKoIR2qoWtZKXgUEojxLwEIYgVRnp6IDcP bYHuAunh7B0= =z7ae -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > rpm -Uvh > ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm > And to add some trouble-shooting myself, this new fedora-release package points to a mirrorlist URL that returns an XML file instead of the old plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to handle it. But that doesn't prove that hardcoding the F11 repository baseurls would not work. Especially if above you choose a local mirror already anyway. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > That was not the right way: It is. > Error: Cannot find a valid baseurl for repo: fedora *sigh* I told you there is no F11 release repo _yet_. Hence you need to disable "fedora" and enable "rawhide". > another try: > > [r...@alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update > Loaded plugins: fastestmirror, refresh-packagekit > Loading mirror speeds from cached hostfile > YumRepo Error: All mirror URLs are not using ftp, http[s] or file. > Eg. / > removing mirrorlist with no valid mirrors: > //var/cache/yum/updates/mirrorlist.txt No idea what you get in there. Don't want to guess. Why didn't you do some minimal trouble-shooting? > Cannot find a valid baseurl for repo: updates wget 'http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f11&arch=i386' gives a list that looks good. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: > >>> With a Yum-based distribution upgrade, you typically perform an upgrade in >>> two steps. First you update to the right "fedora-release" package, so >>> variables like $releasever used in your *.repo files expand to '11' >>> instead of '10'. Then you run a plain "yum update", which automatically >>> chooses the Fedora 11 repos. >> I know this procedure. > > Then use it. ;) That was not the right way: rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm [r...@alberta ~]# yum clean all Loaded plugins: fastestmirror, refresh-packagekit Cleaning up Everything Cleaning up list of fastest mirrors [r...@alberta ~]# yum update Loaded plugins: fastestmirror, refresh-packagekit Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. / removing mirrorlist with no valid mirrors: //var/cache/yum/fedora/mirrorlist.txt Error: Cannot find a valid baseurl for repo: fedora [r...@alberta ~]# another try: [r...@alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. / removing mirrorlist with no valid mirrors: //var/cache/yum/updates/mirrorlist.txt Cannot find a valid baseurl for repo: updates [r...@alberta ~]# last try: yum --disablerepo=* --enablerepo=rawhide update and back to the errors of my very 1st posting... :-( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvBbUJXG7BUuynnAQJMiQ//VR/88spZ1C4oDiZx+XrZ0bT/SdeMrTmp VNYwCHLKA8nttxucdMRU3EBvehs7goMHGw8Rbfv0f0ioSMiXrUSOMmf/qiZfqb8+ IGB12T3kYEZmxiYhk4zIFIDZKiUT715bChZ0F5eW2uWiVDD3pCeadWjWHSH+6JE8 smIySAH4GnbULOBkH/XW6+ge7JU5HKZkx//gcKS6qOja7T4/+BQ88VyP/qoiJOHG o2Zw3UKBN+KLJiHN+4EgiyPOr0Azg2ZD6GBIk3gKpFlTZW8zBscKyFU4EVfLan4r 8pjqVQxhO1o6Q7X08liu7/YNWj3ZAuImMTrHS7/NJPCdHfCO+LyiRIxJu65ozxjK jtQnAKLMCnPZjxLshWtDeeunEhV9ZrSQR1djYMUhnTW2tksJ/W6s7HhBk5h7sa++ N4G75yLOGycNWX7shrETuppAKuauhP34pG8RAZb0CXi539fZpPytdM5dRqwc1hde WhDw/ZZQj6kzUCjzR+4FVkV9hnMQxsCVkvFP9NLLUiFlSgdbhSeLsbcsNSg73SNn Owh6LfMgfoOmQPHzBCNuTxgRHwrguVt1zzUG47Zos8w6WfDgoA9XF8hQkYpelTox 2Ofu0pUNEUceUtMO+LYLPHXqxtXsC/fLQe7w7FmrimgDF50obHLqHlvzBsWKIVgh EG7EnsXf7ic= =i5oW -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 03:38 PM, Panu Matilainen wrote: > Smart in GUI-mode and Synaptic currently use the Group tag to, well, > group the packages for viewing: > http://laiskiainen.org/tmp/smartpm-groups.png. That's great. Apt (and smartpm in > cli-mode) dont care. > > Without spec specified Group they all get lumped under "Unspecified" but > as the group tags are already wildly inconsistent, full of typos etc... > dunno if it's such a big loss. Yes, the packaging/review guidelines only care about comps grouping and not the Group tag. So for many packages, it is pretty arbitrary. I guess, we can just lose both build root and group tag to reduce noise. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 26 May 2009, Rahul Sundaram wrote: On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under "Unspecified" but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: > > With a Yum-based distribution upgrade, you typically perform an upgrade in > > two steps. First you update to the right "fedora-release" package, so > > variables like $releasever used in your *.repo files expand to '11' > > instead of '10'. Then you run a plain "yum update", which automatically > > chooses the Fedora 11 repos. > > I know this procedure. Then use it. ;) > Do we have the F11 repos yet? I don't think so, > because F11 is not GA. F11 "updates" and F11 "updates-testing" _are_ available F11 release Everything, however, is still in "development" (Rawhide). > > The more packages in F11 Updates, the more likely you need them in order > > to replace your F10 Updates, which may be seen as newer than F11 GA. Same > > applies to Test Updates. > > > > That will be a brake a possible option from the past. :-( No. With Yum it has always been like that and the primary reason for creating the old upgradecheck.py script from the Fedora Extras era. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 11:17:29 +0200, Uwe wrote: > >>> What set of repositories did you use when enabling updates-testing? >>> In your quote I see lots of references to F10 updates-testing, but >>> did you also enable F11 updates and F11 updates-testing? >> I think, yum only enables updates-testing for F10 if I type >> >> [r...@alberta ~]# yum --disablerepo=* >> - --enablerepo=rawhide,updates-testing update >> >> How to enable the other update channels? > > With a Yum-based distribution upgrade, you typically perform an upgrade in > two steps. First you update to the right "fedora-release" package, so > variables like $releasever used in your *.repo files expand to '11' > instead of '10'. Then you run a plain "yum update", which automatically > chooses the Fedora 11 repos. I know this procedure. Do we have the F11 repos yet? I don't think so, because F11 is not GA. > > Alternatively, you hardcode the baseurls of the repos you want to upgrade > to. > > [And as long as there is no F11 GA repo yet, you need to enable rawhide > manually.] > >>> [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. >>> Not only because of packaging bugs (F10 packages having a higher >>> EVR than F11 packages), but also because there is a growing number >>> of updates and test-updates for F11 already.] >>> >> Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? > > With Yum? Yes. > > The more packages in F11 Updates, the more likely you need them in order > to replace your F10 Updates, which may be seen as newer than F11 GA. Same > applies to Test Updates. > That will be a brake a possible option from the past. :-( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShu52UJXG7BUuynnAQIBLg/7BGAQBNd6hANrgPhy+JQrF1+Cx173UTaz N0Eo6hkUap6uqEcgRUjvSW6WQrupfUtNMdpbRDqLYUKl+iUrTZrfJd2ml7m8IBUt 1CmntDuyIaijC/KnGdOsd0wsX9L9wCY9/N2jzl1RHDbptzu/6PwS/JdPGpnZGlu/ R+fM1JM0vdQlp6ngIHQckWe3Licv807gIHYtD3vb4m8/hjWe5fEKr1GvB9K2poze Bg40kyq5iv76w4CEoKO+y3m/Ss196d6kXfjWpEKsujj3NZtTGwe1uQg+kXpKE4ee WBd1ghu0QqVKaxF4xodIZsac5XYPgG4NGBwgKXHoXTc6V58QamCrs1uqcs1AKPg0 UiGWDeeYTZE8T1tf0pSAOS/tSsSUBE37FVwEULhdYswTDiq8t2CYuBeb2a4E7jUE dLqi7DgaGNKbAin2ycNHFBPwY3e1V9bNvjMrxswaEa7Rl36Jl9SltYdUbHg2IPxH tHjPKEpW8Mt0xVWeB00tIOfWYHvOPupLxw3zwOr63xFSPTSgLpMbgaIWJh5MOObe u2Gcd8lmfeFjAq/RdJF+5UPol7K+EPJywEXJmqeJFyIeS8o++K2ETnuBDH/kMy04 QkyhCeAKe5j+Gu71ZtSxYanCDMMwg6YcL0UpHcI3xW+Bi1UdcUzFnieR8dSeWyxT t/dgokC4WyQ= =xJF4 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 11:17:29 +0200, Uwe wrote: > > What set of repositories did you use when enabling updates-testing? > > In your quote I see lots of references to F10 updates-testing, but > > did you also enable F11 updates and F11 updates-testing? > > I think, yum only enables updates-testing for F10 if I type > > [r...@alberta ~]# yum --disablerepo=* > - --enablerepo=rawhide,updates-testing update > > How to enable the other update channels? With a Yum-based distribution upgrade, you typically perform an upgrade in two steps. First you update to the right "fedora-release" package, so variables like $releasever used in your *.repo files expand to '11' instead of '10'. Then you run a plain "yum update", which automatically chooses the Fedora 11 repos. Alternatively, you hardcode the baseurls of the repos you want to upgrade to. [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] > > [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. > > Not only because of packaging bugs (F10 packages having a higher > > EVR than F11 packages), but also because there is a growing number > > of updates and test-updates for F11 already.] > > > > Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? With Yum? Yes. The more packages in F11 Updates, the more likely you need them in order to replace your F10 Updates, which may be seen as newer than F11 GA. Same applies to Test Updates. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 10:39:27 +0200, Uwe wrote: > >> I checked the ability to upgrade from F10 to F11 (Rawhide) directly >> using yum. A couple of weeks ago, there were dependency errors with >> python. These errors are not fixed until now. > > Nobody has posted the results of one of the upgradepathcheck scripts > for a long time. :( > >> In my point of view, this issue should be fixed until GA of Leonidas. > > What set of repositories did you use when enabling updates-testing? > In your quote I see lots of references to F10 updates-testing, but > did you also enable F11 updates and F11 updates-testing? I think, yum only enables updates-testing for F10 if I type [r...@alberta ~]# yum --disablerepo=* - --enablerepo=rawhide,updates-testing update How to enable the other update channels? > > [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. > Not only because of packaging bugs (F10 packages having a higher > EVR than F11 packages), but also because there is a growing number > of updates and test-updates for F11 already.] > Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? Thanks, Uwe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShuzqEJXG7BUuynnAQJYvQ/6AgRsZbYbIawgmunykKutdu278ODNsiHx l9KJlAibYbz00P0A7rm2CGlwqLVEUOGUM401jLB16AjNFEmDAIsE5GvjzFdeEQgR 0qrsfe4Thoek7RBRwdn1vr6YeYgqXy6WoYfeJ73OU34sS5eHMiyXtEnVNU8anVQq 2mGExPwZf5u2+S+uJPkZi73IV0PoZoD1Q3/lS5Z0qK7naim8gLyENjTVLlEtuUom RdF1TD1Z2PKN2ALTRSpciRSLJhVE4Ydhw/qhLQTIjkpKrBQLrt4+dZuECkbV7Pn0 aGpliuhGU+zv8ZihqduLykxR0uVi73am06vZ9ZfqyBWW/8N9e8TISD2zKvxZz8o+ 0O5eBUtHSBAtKr+kHcsn2rC8w7k3Zk6LBW6Ky2QEKLbKyyP1hp7N5pFFQO7knfQ9 K36AmL5/rJ1pXiXWUTURVlp/c6iRGBcxoNfDQX+UoDud6cin2G6nRO+GqgcUfV19 6UPh0q5jLfPh1h3cGPw1PKpAF0D9pwPk5giRs12wGPLyCdmD1sIpsl6oxLYrIWHJ ReVsl6jmdac/GLKbqFNZOyhpin0S7vZLioazvWQKDzmto6zj2kurJz5N74s8H9s3 e8K2zQ7O4iypSltlSOoP9P9k8LwqlkcYN5I5Zonwi3JASKD93be5F2MGd2awRkBf HNrdqxFuWS0= =hmb9 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > | From: Rex Dieter > > | Seems frustrations are mounting: > | "On policykit and standards" > | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html > > [I'm an outsider. This thread is my introduction to the whole area. > I'm not even a KDE user.] > > This certainly does not look like a healthy approach to standardization > and cooperation. > > - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > appears clearly biased towards GNOME, even though its URL and title > suggest universality: the first substantial line talks about > polkit-gobject-1 (I *think* that gobject means GNOME object) > > - in a well-constituted standards process (not a de facto standard), > stakeholders are consulted before changes are made. It looks > as if KDE folks have been stakeholders and have not been allowed to > even sign-off on the design, let alone participate in it. > > - for good reason, the normal output of a standardization process is a > document, not code. There appears to be no complete documentation. > > - all stakeholders ought to be treated respectfully and equitably. > That means, for example, KDE ought not the be second to GNOME. > More particularly, the architectures should be open-ended, allowing > for more than KDE and GNOME. See, for example, > http://c2.com/cgi/wiki?ZeroOneInfinityRule > > I admit that my reactions may be ill-founded. Perhaps this is meant You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
Le Mar 26 mai 2009 10:43, Rahul Sundaram a écrit : >> It seems like the Group tag is now optional in upstream RPM (since >> somewhere around F-11). > > Yes but there should be packaging guidelines adding a note that you > can > just drop it similar to built root. Does apt, smart and synaptic > support > comps though? do we care? I'd drop it from the font packaging spec templates at once if FPC & FESCO oked it. Each spurious line is pollution that frightens new packagers. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 10:39:27 +0200, Uwe wrote: > I checked the ability to upgrade from F10 to F11 (Rawhide) directly > using yum. A couple of weeks ago, there were dependency errors with > python. These errors are not fixed until now. Nobody has posted the results of one of the upgradepathcheck scripts for a long time. :( > In my point of view, this issue should be fixed until GA of Leonidas. What set of repositories did you use when enabling updates-testing? In your quote I see lots of references to F10 updates-testing, but did you also enable F11 updates and F11 updates-testing? [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. Not only because of packaging bugs (F10 packages having a higher EVR than F11 packages), but also because there is a growing number of updates and test-updates for F11 already.] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Tue, May 26, 2009 at 10:19:45AM +0200, Tomas Mraz wrote: > I'll orphan it and you can be the primary maintainer. Done. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unowned files and directories
On Sat, 23 May 2009 19:46:42 +0200, Thorsten wrote: > But I'm a bit unsure what to do with the results. Filing bugs likely > would be huge amount of work as well as and never-ending task for a > small gain. http://mschwendt.fedorapeople.org/dircheck-remote.py Example usage: ./dircheck-remote.py -r rawhide -n ^vtk ./dircheck-remote.py -r rawhide > Options? Just ignore? Or will the automatic test scripts QA iirc plans > to set up check for things like that in the future? Different strategy. Also to raise awareness of the problem. Focus on those unowned directories - which bear a risk of breaking tarball compilation (e.g. old unowned empty versioned API directories which confuse tarball configure scripts, not limited to %_includedir), - which look like files might be misplaced (e.g. unowned directories in suspicious paths), - which look like missing subpackage dependencies (e.g. "yum install foo-something" doesn't lead to working software since "foo" is not installed automatically) - which pile up usability crap, such as empty versioned %docdirs. [1] [1] The latter is annoying. It breaks tab completion in /usr/share/doc (but also makes it harder to browse documentation with graphical file managers). Additionally, some packagers tend to use %doc in almost every subpackage, and I'm not sure they are aware of the consequences. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: > On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: >> On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: >>> The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in >>> the #fedora-meeting channel on chat.freenode.net. >>> >>> FPC works from the agenda at >>> https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just >>> one item currently on the agenda: >>> >>> Phase out Buildroot - >>> https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 >> >> How about phasing out Group tag as well? > > It seems like the Group tag is now optional in upstream RPM (since > somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dependency errors while upgrading vom F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I checked the ability to upgrade from F10 to F11 (Rawhide) directly using yum. A couple of weeks ago, there were dependency errors with python. These errors are not fixed until now. In my point of view, this issue should be fixed until GA of Leonidas. Thanks, Uwe == What I have done: [r...@alberta ~]# yum --disablerepo=* --enablerepo=rawhide update I got: - --> Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 6:kdelibs-4.2.3-2.fc10.i386 from installed has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) Error: Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) Error: Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) [r...@alberta ~]# So, I tried to use updates-testing to fix, but more errors appeared: - --> Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) createrepo-0.9.7-7.fc10.noarch from updates-testing has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package createrepo-0.9.7-7.fc10.noarch (updates-testing) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) ntp-4.2.4p7-1.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libcrypto.so.7 is needed by package ntp-4.2.4p7-1.fc10.i386 (updates-testing) 1:qt-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libcrypto.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 6:kdelibs-4.2.3-3.
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 26 May 2009 09:10:15 +0100, Richard wrote:
> I vote for also removing the %clean section.
Complete removal or only making "rm -rf %{buildroot}" the default?
In case of the former, let's also add an implicit "rm -rf %{buildroot}" at
start of %install. There are still packagers who don't empty the buildroot
and who don't know rpmbuild's -bi --short-circuit options.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Tue, 2009-05-26 at 09:06 +0100, Richard W.M. Jones wrote: > On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: > > On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: > >> On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: > >>> is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like > >>> to orphan it. I might stay as a comaintainer if you want. > >> > >> It looks like Warren Togami has jumped in there to be co-maintainer. > >> If you need someone else I can help. > >> > >> Rich. > >> > > > > wait what? Why are you volunteering me for something I know nothing about? > > A simple misunderstanding - I looked at the ACLs and noticed that you > were there already, so I assumed you'd already taken co-maint for the > package. > > Tomas: If you still want me to co-maintain this package, let me know. I'll orphan it and you can be the primary maintainer. -- 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
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: > On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: > > The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in > > the #fedora-meeting channel on chat.freenode.net. > > > > FPC works from the agenda at > > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just > > one item currently on the agenda: > > > > Phase out Buildroot - > > https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 > > How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). I vote for also removing the %clean section. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: > On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: >> On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: >>> is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like >>> to orphan it. I might stay as a comaintainer if you want. >> >> It looks like Warren Togami has jumped in there to be co-maintainer. >> If you need someone else I can help. >> >> Rich. >> > > wait what? Why are you volunteering me for something I know nothing about? A simple misunderstanding - I looked at the ACLs and noticed that you were there already, so I assumed you'd already taken co-maint for the package. Tomas: If you still want me to co-maintain this package, let me know. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
