Re: *countable infinities only
On Thu, 2012-06-14 at 04:19 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > > On Wed, 2012-06-13 at 10:25 +0200, Ralf Corsepius wrote: > > > >> I am inclined to believe, the spirit behind Linux has changed, changed > >> away from being idealistic to playing issues low for commerial interests. > > > > I'm not going to agree or disagree, but purely as background, remember > > that the spirit behind _Linux_ has never been particularly idealistic. > > Linus is a pure pragmatist and has stated multiple times that he chose > > the GPL on practical grounds, not idealistic ones. > > And that's exactly why incorrectly calling GNU/Linux just "Linux" (as both > Ralf and you did) is a mistake. > > Linus started only the kernel. The complete operating system was started by > the GNU Project, which is very much idealistic. I hereby declare this thread officially dead. Is there a Godwin's Law equivalent that applies to the invocation of the 'GNU/ debate'? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: buildsys-build group renamed to build?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Jun 2012 10:33:32 -0600 Kevin Fenzi wrote: > On Wed, 13 Jun 2012 07:13:13 + (UTC) > Petr Pisar wrote: > > > Hello, > > > > Can a comps maintainer confirm that yum group used for installing > > minimal build-root in F18 has been renamed from `buildsys-build' to > > `build'? > > I don't see that change here. > > > buildsys-build > <_name>Buildsystem building group > > > I just started getting failures in my local mock configurations > > today because regarding this group name. > > Odd. > > Not sure what it could be... any further logs or debugging available? if your only using koji repos then yes you need to use build as thats what koji uses internally buildsys-build predates koji in fedora. but you really shouldnt use koji only repos with fedora configs. you should use the koji mock-config command in koji to get a koji mock config. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/ZYbsACgkQkSxm47BaWfc7JQCgiF+jUH5p1rCxzZuoMAG6ovOf xaMAni9Tu3QKyx9fJkgpyDwPktKRW1hZ =17PU -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Once upon a time, Kevin Kofler said: > Linus started only the kernel. The complete operating system was started by > the GNU Project, which is very much idealistic. And where would GNU be if it weren't for Linux? I remember gcc and glibc before Linux came along (and then there was RMS's ugly "lignux" renaming attempt). There's a large chunk of GNU software that has received significan benefit from the Linux community. A Linux kernel with only software from GNU (as implied by the name "GNU/Linux") would be pretty useless, so ignoring all the other software that goes into making a useful OS is also rude. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[headsup] Haskell Platform 2012.2 coming soon to Rawhide
Hi, Just a quick heads-up that haskell-platform in Rawhide will be soon be updated to the new 2012.4 release. [1] As usual there will be quite a bit of dependency breakage while all the reverse dependencies get rebuilt: I have already tested it locally and committed required changes to git. At the same time we will also be updating various libraries to their latest versions. In other Haskell news, ghc-7.4.2 was finally released. [2] I am still a bit split on whether we should ship it in F18. It is a bugfix release but it is not clear yet if Haskell Platform will see an official release in time for F18 - it needs a change to their schedule anyway, which is under discussion. ghc-7.4.2 also has ghci support for ARM. I guess it comes down to whether we give priority to ghc or haskell-platform: e.g. Ubuntu 12.04 shipped ghc-7.4.1 and an unofficial haskell-platform-2012.1 (whereas F17 is still on ghc-7.0.4 and the last official haskell-platform-2011.4 release). Debian is currently transitioning ghc-7.4.1 and haskell-platform-2012.2 to testing too. Jens [1] http://hackage.haskell.org/platform/ [2] http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Felix Miata wrote: > Is "never" appropriate even if one's own experience is with 3 systems? 7 > systems? 13 systems? 40 systems? Never say never, or always. ;-) That can widen the class of affected devices, but from there to "all Intel WiFi" is still a long stretch. (For a starter, last I checked they didn't even all use the same driver, but some legacy chipsets had legacy drivers. Then AFAIK there are different code paths in iwlwifi for different device generations, and also different firmware. And then of course different hardware behaves differently. Plus, WiFi issues also tend to depend on the exact configuration you're using, in particular on how the access point is set up. And finally there can be interaction with other hardware or drivers on the machine.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Josh Boyer wrote: > The person that submits the update gets emails for every comment added > to the update. This particular one had a couple things that happened > though. > > 1) It got the requisite karma for stable rather quickly > 2) Justin was on vacation when the negative karma was submitted. Bodhi > only emails the update submitter and the rest of the kernel team didn't > notice. > > I'm sure that it would have been pulled if Justin was actually around > or if the rest of the kernel team had remembered to go check the > update. It's something that can be looked at in the future. Why is karma automatism being enabled (by the submitters, it's optional!) on kernel updates in the first place? IMHO, kernels should always be pushed manually. (I actually consider karma automatism entirely broken, but the kernel is one of the worst packages to use it on!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
Orcan Ogetbil wrote: > The only official doc is on how to modify the html footer > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Doxygen_footers Please do NOT add such workarounds to all packages. The doxygen maintainer is going to ship a fixed doxygen ASAP. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Adam Williamson wrote: > On Wed, 2012-06-13 at 10:25 +0200, Ralf Corsepius wrote: > >> I am inclined to believe, the spirit behind Linux has changed, changed >> away from being idealistic to playing issues low for commerial interests. > > I'm not going to agree or disagree, but purely as background, remember > that the spirit behind _Linux_ has never been particularly idealistic. > Linus is a pure pragmatist and has stated multiple times that he chose > the GPL on practical grounds, not idealistic ones. And that's exactly why incorrectly calling GNU/Linux just "Linux" (as both Ralf and you did) is a mistake. Linus started only the kernel. The complete operating system was started by the GNU Project, which is very much idealistic. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Peter Jones wrote: > I find it pretty hard to believe this position. Through my role working > on our bootloaders at Red Hat, I've seen a fair amount of pre-production > hardware, and I've spent a lot of time looking at hardware that implements > Secure Boot, and how it does so. I've seen the firmware interfaces so far. > They've gotten a lot better than when they initially started shipping, but > there are still plenty of them where /I/ can't figure out what the > firmware options mean. The user only needs to be able to touch the "Secure Boot" setting, not the "Frobnicate the XYZ unit" setting nobody understands the meaning of. > It's pretty disingenuous to think that our users are going to be able to > figure this out. In our target userbase? Are you sure? Oh, and the tax forms I have to fill out every so often have plenty of cryptical things I'm supposed to fill in somehow, yet the government expects me to be able to figure it out. I think disabling "Secure" Boot is probably actually easier than filling out the average tax form. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
login/logout hooks in fedora 17?
Hi all, Any suggestions on how I may run a script when a user logins or logouts of the graphical console? I used to do this with gdm by customizing the Post* and Pre* scripts in /etc/gdm. I see that the login/logout process is (appears to be) controlled by systemd. What would be a good approach to getting the system to run a script before a user logs in and after a user logs out (ie: for local users sitting at the console - probably now called a seat if I understand things correctly). Thanks for any advice! -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120613 changes
On Wed, Jun 13, 2012 at 01:47:05PM +, Fedora Rawhide Report wrote: > [cduce] > cduce-0.5.4-4.fc18.x86_64 requires ocaml(runtime) = 0:3.12.1 (etc) The remaining OCaml packages are all waiting upstream fixes. Sorry about the noise, but we should have it done in a week. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM status meeting minutes 2012-06-13
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-13/fedora-meeting-1.2012-06-13-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-13/fedora-meeting-1.2012-06-13-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-06-13/fedora-meeting-1.2012-06-13-20.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Am Mittwoch, den 13.06.2012, 12:07 -0700 schrieb Adam Williamson: > On Wed, 2012-06-13 at 09:36 -0400, Josh Boyer wrote: > > On Wed, Jun 13, 2012 at 9:24 AM, Roman Kennke wrote: > > > Would it make sense to require more karma than just the default 3? > > > Looking at: > > > > > > https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17 > > > > > > I see that there are 5 oks and 2 denys, which actually point to bug > > > reports, both sound fairly important. How does the karma system work if, > > > e.g., update requires +3, the update gets +4 and -1, and this -1 is > > > something that can be considered a release critical bug? data corruption > > > sounds quite release-critical? Is there a mechanism that prevents the > > > update to happen in this case? > > > > Good questions. > > > > The person that submits the update gets emails for every comment added > > to the update. This particular one had a couple things that happened > > though. > > > > 1) It got the requisite karma for stable rather quickly > > 2) Justin was on vacation when the negative karma was submitted. Bodhi > > only emails the update submitter and the rest of the kernel team didn't > > notice. > > > > I'm sure that it would have been pulled if Justin was actually around > > or if the rest of the kernel team had remembered to go check the > > update. It's something that can be looked at in the future. > > This can also serve as my quarterly reminder that Bodhi 2.0 is _still_ > supposed to be coming, with much better feedback features. The simple > +/- points system in Bodhi 1.0 isn't really adequate for any number of > scenarios, including this one. I have posted before about what benefits > a better feedback system would have: > https://lists.fedoraproject.org/pipermail/devel/2011-November/159874.html What you lay out there sounds useful indeed! I hope it's coming. One thing that might be useful to think about is the way Debian handles transitions. (Forgive me if the following is not 100% correct, I am only remotely familiar with what I am saying.) Packages in testing (or unstable) can only transition to the next more stable repository if certain conditions are fulfilled. One is to be the at least X days, another is to not have any (new) release critical bugs in it. (I think there are more, but those two seem important.) In order to accomplish this, the package update system (I guess it would be comparable to Fedora's Bodhi) is linked to the bug DB, and bugs for a package can have a severity of 'release critical' which basically blocks transitions of the package. I think something similar could be useful for Fedora as well, i.e. link Bodhi to bugzilla and react on certain things like severity of bugs. Of course, it still means that somebody actually needs to test it in order to find and file bugs... Roman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On Wed, 2012-06-13 at 13:22 -0700, Adam Williamson wrote:
> On Wed, 2012-06-13 at 20:10 +0200, Pierre-Yves Chibon wrote:
> > On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
> > > On Mon, 23 Apr 2012 14:08:05 -0600
> > > Orion Poplawski wrote:
> > >
> > > > %global commit bd245c9
> > > >
> > > > Source0:
> > > >
> > > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
> > > >
> > > > %setup -q -n jukka-pcfi-%{commit}
> > >
> > > I do not understand how this is supposed to work in the face of
> > > "yum update".
> >
> > But if you read his email carefully, Orion isn't speaking about the
> > version.
> > So commit will be bd245c9 but the version might very well be
> >
> > Version: 20120613git%{commit}
> >
> > and as long as the date gets updated, yum will be happy with it.
>
> The guidelines actually require an integer before the date/rcs rev part,
> which should be incremented at every build. Like so:
>
> 1.20110102git9e88d7e
> 2.20110102git9e88d7e
> 3.20120201git8fg34f6
> 4.20120201git8fg34f6
>
> It doesn't get reset when you bump the snapshot, to double-plus-ensure
> that no mess in the snapshot bit of the tag can ever cause problems.
Erf. I forgot that if it's a pre-release snapshot, you make it
%{version}-0.X.%{snapshot} .
The rules are a bit complex :) but all make sense, and if you follow
them, you should never get in trouble with updates not superseding. You
should _always_ include a version, even if it has to be notional, and if
it's notional, do everything you can to make sure it's lower than any
possible version number upstream might actually release in future.
Always include X (post-release) or 0.X (pre-release, so that the first
actual release build can always be 1) before the snapshot bit, whatever
snapshot naming format you're using.
There are some good examples given on the page right under 'Pre-Release
packages', it's worth looking at those.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On Wed, 2012-06-13 at 20:10 +0200, Pierre-Yves Chibon wrote:
> On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
> > On Mon, 23 Apr 2012 14:08:05 -0600
> > Orion Poplawski wrote:
> >
> > > %global commit bd245c9
> > >
> > > Source0:
> > >
> > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
> > >
> > > %setup -q -n jukka-pcfi-%{commit}
> >
> > I do not understand how this is supposed to work in the face of
> > "yum update".
>
> But if you read his email carefully, Orion isn't speaking about the
> version.
> So commit will be bd245c9 but the version might very well be
>
> Version: 20120613git%{commit}
>
> and as long as the date gets updated, yum will be happy with it.
The guidelines actually require an integer before the date/rcs rev part,
which should be incremented at every build. Like so:
1.20110102git9e88d7e
2.20110102git9e88d7e
3.20120201git8fg34f6
4.20120201git8fg34f6
It doesn't get reset when you bump the snapshot, to double-plus-ensure
that no mess in the snapshot bit of the tag can ever cause problems.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dd_rescue ddrescue upstream versions
Hello Developers, please does anyone know how to contact Andreas Thienemann ? I was trying to contact him related to the packages dd_rescue and ddrescue for upgrade to upstream versions. https://bugzilla.redhat.com/show_bug.cgi?id=591042";>https://bugzilla.redhat.com/show_bug.cgi?id=591042 https://bugzilla.redhat.com/show_bug.cgi?id=807220";>https://bugzilla.redhat.com/show_bug.cgi?id=807220 Best regards Michal Ambroz < Původní zpráva < Od: Michal Ambrozmailto:re...@seznam.cz">mailto:re...@seznam.cz";>re...@seznam.cz> < Předmět: dd_rescue ddrescue upstream versions < Datum: 14.5.2012 22:31:30 < < Hello Andreas, < please could you consider upgrading the ddrescue and dd_rescue versions in < Fedora? < https://bugzilla.redhat.com/show_bug.cgi?id=591042">https://bugzilla.redhat.com/show_bug.cgi?id=591042";>https://bugzilla.redhat.com/show_bug.cgi?id=591042 < https://bugzilla.redhat.com/show_bug.cgi?id=807220">https://bugzilla.redhat.com/show_bug.cgi?id=807220";>https://bugzilla.redhat.com/show_bug.cgi?id=807220 < < Thank you < Michal Ambroz < < < < -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, 2012-06-13 at 09:36 -0400, Josh Boyer wrote: > On Wed, Jun 13, 2012 at 9:24 AM, Roman Kennke wrote: > > Would it make sense to require more karma than just the default 3? > > Looking at: > > > > https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17 > > > > I see that there are 5 oks and 2 denys, which actually point to bug > > reports, both sound fairly important. How does the karma system work if, > > e.g., update requires +3, the update gets +4 and -1, and this -1 is > > something that can be considered a release critical bug? data corruption > > sounds quite release-critical? Is there a mechanism that prevents the > > update to happen in this case? > > Good questions. > > The person that submits the update gets emails for every comment added > to the update. This particular one had a couple things that happened > though. > > 1) It got the requisite karma for stable rather quickly > 2) Justin was on vacation when the negative karma was submitted. Bodhi > only emails the update submitter and the rest of the kernel team didn't > notice. > > I'm sure that it would have been pulled if Justin was actually around > or if the rest of the kernel team had remembered to go check the > update. It's something that can be looked at in the future. This can also serve as my quarterly reminder that Bodhi 2.0 is _still_ supposed to be coming, with much better feedback features. The simple +/- points system in Bodhi 1.0 isn't really adequate for any number of scenarios, including this one. I have posted before about what benefits a better feedback system would have: https://lists.fedoraproject.org/pipermail/devel/2011-November/159874.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, 2012-06-13 at 14:33 -0400, Felix Miata wrote: > On 2012/06/13 11:22 (GMT-0700) Adam Williamson composed: > > > Your own personal experience is _never_ sufficient grounds for > > concluding that the bug you're experiencing affects a much broader class > > of devices. > > Is "never" appropriate even if one's own experience is with 3 systems? 7 > systems? 13 systems? 40 systems? Never say never, or always. ;-) *fist shake* -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On Wed, Jun 13, 2012 at 08:10:14PM +0200, Pierre-Yves Chibon wrote:
> On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
> > On Mon, 23 Apr 2012 14:08:05 -0600
> > Orion Poplawski wrote:
> >
> > > %global commit bd245c9
> > >
> > > Source0:
> > >
> > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
> > >
> > > %setup -q -n jukka-pcfi-%{commit}
> >
> > I do not understand how this is supposed to work in the face of
> > "yum update".
>
> But if you read his email carefully, Orion isn't speaking about the
> version.
> So commit will be bd245c9 but the version might very well be
>
> Version: 20120613git%{commit}
>
> and as long as the date gets updated, yum will be happy with it.
>
Also, probably want to keep all of this out of the version field. The
Guidelines say to stick it in release.
Putting it in Version: runs the risk of upstream making a release like 1.0
which would then sort lower than the date (20120613).
-Toshio
pgp2VxKOJ0NiT.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upcoming libdb/db4/compat-db reorganization
On Wed, 13 Jun 2012 11:15:08 -0500, Bruno Wolff III wrote: > On Wed, Jun 13, 2012 at 09:44:37 -0600, >Orion Poplawski wrote: > >On 05/04/2012 12:23 PM, Michael Schwendt wrote: > > > >Rawhide is in bad shape too: > > > >https://bugzilla.redhat.com/show_bug.cgi?id=816284 > > > >Transaction Check Error: > > file /usr/include/db.h conflicts between attempted installs of > >db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 > > file /usr/include/db_185.h conflicts between attempted installs of > >db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 > > file /usr/include/db_cxx.h conflicts between attempted installs of > >db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 > > file /usr/lib64/libdb.so conflicts between attempted installs of > >db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 > > My memory is that db4 was going to be retired in F18. But it hasn't > happened yet. There is a Rename Request for db4 -> libdb4 in the package review queue: https://bugzilla.redhat.com/816124 That's where all the fun related to the packaging conflicts and errors takes places. ;) -- Fedora release 17 (Beefy Miracle) - Linux 3.4.0-1.fc17.x86_64 loadavg: 0.26 0.48 0.47 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
Xavier Bachelot wrote: > Does anyone have any pointer on how to fix a multilib conflict with a > doxygen generated pdf file ? I was able to fix the same multilib issue > with the html files by modifying the footer to not include the > timestamp, but I don't find any pointer on how to proceed for the pdf > file. pretty sure these are all a doxygen packaging bug, it is supposed to default timestamps to off, but doesn't erroneously. I think I got this fixed in doxygen-1.8.1.1-2.fc18 : http://koji.fedoraproject.org/koji/buildinfo?buildID=325050 I'll talk to than about getting a fixed build for f17 too -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On 2012/06/13 11:22 (GMT-0700) Adam Williamson composed: Your own personal experience is _never_ sufficient grounds for concluding that the bug you're experiencing affects a much broader class of devices. Is "never" appropriate even if one's own experience is with 3 systems? 7 systems? 13 systems? 40 systems? Never say never, or always. ;-) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, 2012-06-13 at 12:51 +0200, Roman Kennke wrote: > I cannot believe that I am the only one > on an Intel Wifi chip. I haven't yet read the rest of the thread, but I just wanted to point out this common fallacy. As a general rule, all $VENDOR_$DEVICETYPE devices do not act the same. You cannot assume that all Intel wifi adapters are subject to the same bug you saw. You can't even assume that the same adapter _in another system_ would be subject to the same bug. This goes for everything: you can't assume all Intel video adapters behave the same, or all AMD video adapters, or all Broadcom wireless adapters, or _anything_. I wish it _were_ true, believe me. It'd make testing (and I'm sure development) a lot easier if all we had to do was have one of each type of device from each manufacturer and then we could happily say 'okay, this kernel works with every piece of hardware in existence'. Boy, that'd be nice. Sadly, it just isn't the case at all. Practical extensions from this rule: 1. Just because your NVIDIA graphics card doesn't work, don't assume that the developers / testers are such idiots they didn't test (whatever it is) on _any_ NVIDIA graphics cards at all. 2. Just because your Intel bluetooth adapter doesn't work, don't go around telling people on forums, IRC etc that they can't use any Intel bluetooth adapter with Fedora, because it's perfectly likely that lots of others work just fine. (Both of these are real-life examples I've seen more than once). The only good grounds for acting as if you're subject to a bug which is affecting a very broad class of hardware is if you have detailed reports from multiple other people with devices in the same class of hardware, detailed enough that it is clear they are all suffering from the same bug. Your own personal experience is _never_ sufficient grounds for concluding that the bug you're experiencing affects a much broader class of devices. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [LGA 1155 motherboards] Multi-Monitor does NOT work when 1 monitor uses Intel GPU and another monitor uses Nvidia GPU -- (Sandy Bridge & Ivy Bridge iGPU)
I have an ASUS P8Z68-V/GEN3 main board which can run the Intel HD3000 graphics which is builtin, using a i5 Sandy Bridge CPU. The box also has an nVidia GeForce GT 430 card (PCI 10de:0de1 rev a1). I usually run only one monitor (from the nVidia card), but I decided to experiment. The American Megatrends BIOS (version 0301 [original; now old]) has System Agent Configuration options Initiate [Initial] Graphic Adapter, and iGPU Multi-monitor. I set iGPU as the initial monitor, and iGPU Multi-monitor to Enabled, and connect two monitors: one to the VGA port of the Intel graphics, one to the VGA port of the nVidia card. Upon reboot, then both LCD monitors turn on their backlights. The monitor connected to the Intel VGA port gets the BIOS and GRUB displays, and becomes the normal monitor. The monitor connected to the nVidia VGA port gets no normal display, and after a few seconds the hardware in the monitor detects "No display" and turns itself off. The F-17 Gnome3 desktop System Settings > Displays detects only the display that is connected to the Intel VGA port. xrandr also shows only the ports that are associated with the builtin Intel hardware. /var/log/Xorg.0.log shows only the monitor with the normal display. Only the VGA ports seem to be active in this two-monitor attempt. Using anything other than VGA ports (both cards have DVI and HDMI ports, too; both monitors have VGA and DVI connectors) produces no display on any non-VGA connection. One monitor (6 years old; 1280x1024) reports EDID info, the other does not (9 years old; 1024x768.) Interchanging monitor<->"card" connections has no observed effect on behavior. So, it seems to me that this setup "fails multi-monitor usage" in the manner that Malcolm Turmel describes. My box has no other operating system installed, so I cannot say anything about whether multi-monitor works with any other operating system. syslog (/var/log/messages) detects the Intel graphics hardware as: Jun 13 10:24:49 f17e64 kernel: [1.020600] agpgart-intel :00:00.0: Intel Sandybridge Chipset Jun 13 10:24:49 f17e64 kernel: [1.020698] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K mappable Jun 13 10:24:49 f17e64 kernel: [1.021529] agpgart-intel :00:00.0: detected 65536K stolen memory Jun 13 10:24:49 f17e64 kernel: [1.021610] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000 Jun 13 10:24:49 f17e64 kernel: [2.494960] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver Jun 13 10:24:49 f17e64 kernel: [2.495798] fbcon: inteldrmfb (fb0) is primary device Jun 13 10:24:49 f17e64 kernel: [2.660097] fb0: inteldrmfb frame buffer device Jun 13 10:24:49 f17e64 kernel: [ 11.189735] hda_intel: Disabling MSI syslog detects the nVidia hardware as: Jun 13 10:24:49 f17e64 kernel: [1.501442] [drm] Initialized drm 1.1.0 20060810 Jun 13 10:24:49 f17e64 kernel: [1.507444] [drm] nouveau :01:00.0: Detected an NVc0 generation card (0x0c1080a1) Jun 13 10:24:49 f17e64 kernel: [1.513098] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN Jun 13 10:24:49 f17e64 kernel: [1.522820] [drm] nouveau :01:00.0: ... BIOS signature not found Jun 13 10:24:49 f17e64 kernel: [1.522822] [drm] nouveau :01:00.0: Attempting to load BIOS image from PROM Jun 13 10:24:49 f17e64 kernel: [1.821809] [drm] nouveau :01:00.0: ... appears to be valid Jun 13 10:24:49 f17e64 kernel: [1.821811] [drm] nouveau :01:00.0: BIT BIOS found Jun 13 10:24:49 f17e64 kernel: [1.821813] [drm] nouveau :01:00.0: Bios version 70.08.29.00 Jun 13 10:24:49 f17e64 kernel: [1.821815] [drm] nouveau :01:00.0: TMDS table version 2.0 Jun 13 10:24:49 f17e64 kernel: [1.822011] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do Jun 13 10:24:49 f17e64 kernel: [1.822013] [drm] nouveau :01:00.0: DCB version 4.0 Jun 13 10:24:49 f17e64 kernel: [1.822015] [drm] nouveau :01:00.0: DCB outp 00: 01000302 00020030 Jun 13 10:24:49 f17e64 kernel: [1.822016] [drm] nouveau :01:00.0: DCB outp 01: 02000300 Jun 13 10:24:49 f17e64 kernel: [1.822017] [drm] nouveau :01:00.0: DCB outp 02: 04011310 00020020 Jun 13 10:24:49 f17e64 kernel: [1.822019] [drm] nouveau :01:00.0: DCB outp 03: 02022362 00020010 Jun 13 10:24:49 f17e64 kernel: [1.822020] [drm] nouveau :01:00.0: DCB conn 00: 1030 Jun 13 10:24:49 f17e64 kernel: [1.822021] [drm] nouveau :01:00.0: DCB conn 01: 0100 Jun 13 10:24:49 f17e64 kernel: [1.822022] [drm] nouveau :01:00.0: DCB conn 02: 2261 Jun 13 10:24:49 f17e64 kernel: [1.822036] [drm] nouveau :01:00.0: Adaptor not initialised, running VBIOS init tables. Jun 13 10:24:49 f17e64 kernel: [1.822037] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0x6BB6 Jun 13 10:24:49 f17e64 kernel: [1.882705] [drm] nouveau :01:00.0: Parsing VBIOS init
Re: GitHub is a terrible upstream
On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
> On Mon, 23 Apr 2012 14:08:05 -0600
> Orion Poplawski wrote:
>
> > %global commit bd245c9
> >
> > Source0:
> >
> https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
> >
> > %setup -q -n jukka-pcfi-%{commit}
>
> I do not understand how this is supposed to work in the face of
> "yum update".
But if you read his email carefully, Orion isn't speaking about the
version.
So commit will be bd245c9 but the version might very well be
Version: 20120613git%{commit}
and as long as the date gets updated, yum will be happy with it.
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
Le mercredi 13 juin 2012 à 19:49 +0200, Pierre-Yves Chibon a écrit :
> On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
> > Suppose I cut a package last year:
> > swift3-1.0.0-878c23.tag.xz
> > Then I build an RPM:
> > openstack-swift-plugin-swift3-1.0.0-878c23-1.fc17.noarch.rpm
> >
> > Today I run the same git-archve and get:
> > swift3-1.0.0-5c74ba.tag.xz
> > openstack-swift-plugin-swift3-1.0.0-5c74ba-1.fc18.noarch.rpm
> >
> > Great, how do I update from the old one to the new one?
>
> That's why the guidelines are saying:
> 20110102snap
> 20110102git
> 20110102git9e88d7e
> using the date as well as the git hash
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag
>
> Pierre
$ git log -r -1
log + date
$ git rev-parse --short HEAD // short hash to use
$ git checkout < short hash to use >
$ git archive --prefix=-%%{alphatag}/ HEAD | xz > ../-%
%{alphatag}.xz
where alphatag is git
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote: > Suppose I cut a package last year: > swift3-1.0.0-878c23.tag.xz > Then I build an RPM: > openstack-swift-plugin-swift3-1.0.0-878c23-1.fc17.noarch.rpm > > Today I run the same git-archve and get: > swift3-1.0.0-5c74ba.tag.xz > openstack-swift-plugin-swift3-1.0.0-5c74ba-1.fc18.noarch.rpm > > Great, how do I update from the old one to the new one? That's why the guidelines are saying: 20110102snap 20110102git 20110102git9e88d7e using the date as well as the git hash http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On Mon, 23 Apr 2012 14:08:05 -0600
Orion Poplawski wrote:
> %global commit bd245c9
>
> Source0:
> https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
>
> %setup -q -n jukka-pcfi-%{commit}
I do not understand how this is supposed to work in the face of
"yum update".
Suppose I cut a package last year:
swift3-1.0.0-878c23.tag.xz
Then I build an RPM:
openstack-swift-plugin-swift3-1.0.0-878c23-1.fc17.noarch.rpm
Today I run the same git-archve and get:
swift3-1.0.0-5c74ba.tag.xz
openstack-swift-plugin-swift3-1.0.0-5c74ba-1.fc18.noarch.rpm
Great, how do I update from the old one to the new one? Please do not
suggest epoch.
-- Pete
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 13:16:24 -0400, Aleksandar Kurtakov wrote: If we means all people subscribed to fedora-devel I think everyone should run with updates-testing enabled. This definition of we is the people that make Fedora happen so we should always test our stuff - non-stop. Regular updates are for users. From my POV everyone sending messages to fedora-devel is supposed to run with updates-testing enabled. And excuses like "no time" and etc. doesn't make sense as this case is showing that one can not simply care about his packages only because there is always something else that your package collaborates with that needs testing too. While I would enourage Fedora contributors to run with updates-testing available, I don't think everyone on the devel list needs to. We all have to make trade offs of time and the project may benefit more from some people spending their time on other things than testing updates before they get to stable. Note that not everyone subscribed to the devel list is a packager and that packagers have other ways to install their package updates without using the updates-testing repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
- Original Message - > From: "Ian Malone" > To: "Development discussions related to Fedora" > > Sent: Wednesday, June 13, 2012 7:27:03 PM > Subject: Re: Important kernel update should not break stuff > > On 13 June 2012 13:31, Aleksandar Kurtakov > wrote: > > > - Original Message - > >> From: "Roman Kennke" > >> To: "Development discussions related to Fedora" > >> > >> Sent: Wednesday, June 13, 2012 3:15:14 PM > >> Subject: Re: Important kernel update should not break stuff > > >> > - How can problems like the one I described above be > >> > avoided? > >> > Is there > >> > anything I and others can help with? > > > >> Ok, fair enough. The question remains, how can we avoid such bad > >> things > >> to happen in the future? Should I regularily try out kernel builds > >> on > >> their way to stable, and object to their stable-release when I > >> find a > >> problem? And how would I do that? (I.e. how can I find out when a > >> new > >> kernel is about to go to stable, and when to test it, etc) And > >> what > >> about the other base components of the system? (Although, to be > >> fair, > >> the kernel seems to be the most problematic one..) > > > > Try having updates-testing repo enabled test and provide karma via > > bodhi. +1 is as needed as -1 as without it we never know whether > > people simply installed and it worked so they stopped at that > > point. See http://fedoraproject.org/wiki/Bodhi for details. There > > is also fedora-easy-karma to ease mass reporting via bodhi. > > Note that this would not make it easier for you short term as you > > would spot the problems just a bit earlier. But if enough people > > do that problems might even be spotted before you update next time > > and the build untagged so you never see the broken build/update at > > all. > > This kind of workflow is effective only if we manage to gather > > critical mass. > > > > I get the need for people to volunteer and test and that's fine. But > the thing I can't square here is why then we aren't all on > updates-testing all the time? The kernel is one of the few packages > you can guarantee everyone is using. We'd all like to know if an > upcoming kernel has problems that will affect us, but you can't know > that until you run it. If we means all people subscribed to fedora-devel I think everyone should run with updates-testing enabled. This definition of we is the people that make Fedora happen so we should always test our stuff - non-stop. Regular updates are for users. From my POV everyone sending messages to fedora-devel is supposed to run with updates-testing enabled. And excuses like "no time" and etc. doesn't make sense as this case is showing that one can not simply care about his packages only because there is always something else that your package collaborates with that needs testing too. Alex > > So the answer is to test it by being on updates-testing, but this > means you put yourself in the way of every possible kernel update and > open yourself to more potential problems. I don't have a solution for > that, but it's clearly something that needs some thought (as someone > who has quite a few times been stuck on old kernels and trying > updates-testing ones to see if they fix a newly introduced problem). > > One question is why are regressions quite so common for some > components? iwlwifi for example seems to show up quite a bit. > > -- > imalone > http://ibmalone.blogspot.co.uk > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Wed, 2012-06-13 at 10:25 +0200, Ralf Corsepius wrote: > I am inclined to believe, the spirit behind Linux has changed, changed > away from being idealistic to playing issues low for commerial interests. I'm not going to agree or disagree, but purely as background, remember that the spirit behind _Linux_ has never been particularly idealistic. Linus is a pure pragmatist and has stated multiple times that he chose the GPL on practical grounds, not idealistic ones. (For double clarification, this does not necessarily mean I personally agree or that I think the Fedora project does/should. I mention it entirely as a note.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 17:27:03 +0100, Ian Malone wrote: I get the need for people to volunteer and test and that's fine. But the thing I can't square here is why then we aren't all on updates-testing all the time? The kernel is one of the few packages you can guarantee everyone is using. We'd all like to know if an upcoming kernel has problems that will affect us, but you can't know that until you run it. So the answer is to test it by being on updates-testing, but this means you put yourself in the way of every possible kernel update and open yourself to more potential problems. I don't have a solution for that, but it's clearly something that needs some thought (as someone who has quite a few times been stuck on old kernels and trying updates-testing ones to see if they fix a newly introduced problem). Different people may be more comfortable with dealing with kernel problems then others. This can vary based on the persons skills and how they are using the affected machines. Part of my contribution to Fedora is being a guinea pig using updates-testing and rawhide. However, dealing with these issues occasionally sucks up a lot of time and I can certainly see why others would need to not do this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upcoming libdb/db4/compat-db reorganization
On 06/13/2012 10:15 AM, Bruno Wolff III wrote: On Wed, Jun 13, 2012 at 09:44:37 -0600, Orion Poplawski wrote: On 05/04/2012 12:23 PM, Michael Schwendt wrote: Rawhide is in bad shape too: https://bugzilla.redhat.com/show_bug.cgi?id=816284 Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 My memory is that db4 was going to be retired in F18. But it hasn't happened yet. Looks like RPC is gone from libdb 5. Is there a suggested replacement? Should projects just stop using it? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: buildsys-build group renamed to build?
On Wed, 13 Jun 2012 07:13:13 + (UTC) Petr Pisar wrote: > Hello, > > Can a comps maintainer confirm that yum group used for installing > minimal build-root in F18 has been renamed from `buildsys-build' to > `build'? I don't see that change here. buildsys-build <_name>Buildsystem building group > I just started getting failures in my local mock configurations today > because regarding this group name. Odd. Not sure what it could be... any further logs or debugging available? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On 13 June 2012 13:31, Aleksandar Kurtakov wrote: > - Original Message - >> From: "Roman Kennke" >> To: "Development discussions related to Fedora" >> >> Sent: Wednesday, June 13, 2012 3:15:14 PM >> Subject: Re: Important kernel update should not break stuff >> > - How can problems like the one I described above be >> > avoided? >> > Is there >> > anything I and others can help with? >> Ok, fair enough. The question remains, how can we avoid such bad >> things >> to happen in the future? Should I regularily try out kernel builds on >> their way to stable, and object to their stable-release when I find a >> problem? And how would I do that? (I.e. how can I find out when a new >> kernel is about to go to stable, and when to test it, etc) And what >> about the other base components of the system? (Although, to be fair, >> the kernel seems to be the most problematic one..) > > Try having updates-testing repo enabled test and provide karma via bodhi. +1 > is as needed as -1 as without it we never know whether people simply > installed and it worked so they stopped at that point. See > http://fedoraproject.org/wiki/Bodhi for details. There is also > fedora-easy-karma to ease mass reporting via bodhi. > Note that this would not make it easier for you short term as you would spot > the problems just a bit earlier. But if enough people do that problems might > even be spotted before you update next time and the build untagged so you > never see the broken build/update at all. > This kind of workflow is effective only if we manage to gather critical mass. > I get the need for people to volunteer and test and that's fine. But the thing I can't square here is why then we aren't all on updates-testing all the time? The kernel is one of the few packages you can guarantee everyone is using. We'd all like to know if an upcoming kernel has problems that will affect us, but you can't know that until you run it. So the answer is to test it by being on updates-testing, but this means you put yourself in the way of every possible kernel update and open yourself to more potential problems. I don't have a solution for that, but it's clearly something that needs some thought (as someone who has quite a few times been stuck on old kernels and trying updates-testing ones to see if they fix a newly introduced problem). One question is why are regressions quite so common for some components? iwlwifi for example seems to show up quite a bit. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upcoming libdb/db4/compat-db reorganization
On Wed, Jun 13, 2012 at 09:44:37 -0600, Orion Poplawski wrote: On 05/04/2012 12:23 PM, Michael Schwendt wrote: Rawhide is in bad shape too: https://bugzilla.redhat.com/show_bug.cgi?id=816284 Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 My memory is that db4 was going to be retired in F18. But it hasn't happened yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Razor-Agent] Perl 5.16 rebuild
commit a5a4deb2794c2f81c5c871b70aa6e4a5202afde8
Author: Petr Písař
Date: Wed Jun 13 17:47:19 2012 +0200
Perl 5.16 rebuild
perl-Razor-Agent.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Razor-Agent.spec b/perl-Razor-Agent.spec
index 1fd2e9a..ec49212 100644
--- a/perl-Razor-Agent.spec
+++ b/perl-Razor-Agent.spec
@@ -4,7 +4,7 @@
Summary: Use a Razor catalogue server to filter spam messages
Name: perl-Razor-Agent
Version: 2.85
-Release: 10%{?dist}
+Release: 11%{?dist}
License: Artistic 2.0
Group: Applications/Internet
URL: http://razor.sourceforge.net/
@@ -76,6 +76,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man*/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 2.85-11
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 2.85-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Object-InsideOut] Perl 5.16 rebuild
commit 90466dca1be530cc84c48f40aee7a020313830e2
Author: Petr Písař
Date: Wed Jun 13 17:47:08 2012 +0200
Perl 5.16 rebuild
perl-Object-InsideOut.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Object-InsideOut.spec b/perl-Object-InsideOut.spec
index 3f35165..88ae965 100644
--- a/perl-Object-InsideOut.spec
+++ b/perl-Object-InsideOut.spec
@@ -1,6 +1,6 @@
Name: perl-Object-InsideOut
Version:3.94
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Comprehensive inside-out object support module
Group: Development/Libraries
License:GPL+ or Artistic
@@ -77,6 +77,9 @@ make test
%changelog
+* Wed Jun 13 2012 Petr Pisar - 3.94-2
+- Perl 5.16 rebuild
+
* Fri May 11 2012 Petr Pisar - 3.94-1
- 3.94 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-Client-DNS] Perl 5.16 rebuild
commit 2f0fb759636f5a57dfc57f71e442de2cd35d6da8
Author: Petr Písař
Date: Wed Jun 13 17:39:46 2012 +0200
Perl 5.16 rebuild
perl-POE-Component-Client-DNS.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-Client-DNS.spec
b/perl-POE-Component-Client-DNS.spec
index 53fa62d..6a621fa 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Component-Client-DNS
Version:1.051
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Non-blocking/concurrent DNS queries using Net::DNS and POE
Group: Development/Libraries
@@ -70,6 +70,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.051-6
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 1.051-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: upcoming libdb/db4/compat-db reorganization
On 05/04/2012 12:23 PM, Michael Schwendt wrote: On Tue, 17 Apr 2012 15:24:17 +0100, PR (Peter) wrote: On Tue, Apr 17, 2012 at 3:10 PM, Joe Orton wrote: On Tue, Apr 17, 2012 at 02:21:36PM +0200, Jindrich Novy wrote: So the plan is: 1) remove 4.5, 4.6 and 4.7 from compat-db 2) put 4.8 to compat-db 3) make db4 a dead package (db4 package name is not very descriptive any more as we have libdb-5.3 ...) Sounds great. For Fedora 17 also, right? #768846 is bad. No! Changes of this level should only be done for rawhide, F-17 is in stabilisation stage. The libdb packaging in F-17 is broken. Several things in the spec file simply don't make any sense. Major changes are needed to fix that. Additionally, there are lots of implicit conflicts with db4* in the subpackages. With bug reports in bugzilla even. Rawhide is in bad shape too: https://bugzilla.redhat.com/show_bug.cgi?id=816284 Transaction Check Error: file /usr/include/db.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_185.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/include/db_cxx.h conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 file /usr/lib64/libdb.so conflicts between attempted installs of db4-devel-4.8.30-10.fc18.x86_64 and libdb-devel-5.3.15-3.fc18.x86_64 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] color man-pages, bash history, clear console
On 2012-06-13, Xose Vazquez Perez wrote: > >== https://bugzilla.redhat.com/815790 == > clear_console: New helper program to clear the *console*, > including the _scrollback buffer_. > > DESCRIPTION > > clear_console clears your console if this is possible. It looks in > the environment for the terminal type and then in the terminfo > database to figure out how to clear the screen. To clear the buffer, > it then changes the foreground virtual terminal to another > terminal and then back to the original terminal. > I added new escape sequence into Linux to clear the scroll-back buffer directly. I think enhancing `clear' utility is the right option. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Math-BigInt-GMP-1.37.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Math-BigInt-GMP: d11bf69c0471e38191f33144079d0373 Math-BigInt-GMP-1.37.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MooseX-Types-DateTime-ButMaintained] 0.15 bump
commit 8ea37c2a12dea025bb9eb6f83fddf8c98fc39ef1
Author: Petr Šabata
Date: Wed Jun 13 16:36:04 2012 +0200
0.15 bump
.gitignore|1 +
perl-MooseX-Types-DateTime-ButMaintained.spec | 12
sources |2 +-
3 files changed, 10 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cf273bd..9f71ba2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
MooseX-Types-DateTime-ButMaintained-0.11.tar.gz
/MooseX-Types-DateTime-ButMaintained-0.13.tar.gz
/MooseX-Types-DateTime-ButMaintained-0.14.tar.gz
+/MooseX-Types-DateTime-ButMaintained-0.15.tar.gz
diff --git a/perl-MooseX-Types-DateTime-ButMaintained.spec
b/perl-MooseX-Types-DateTime-ButMaintained.spec
index f934517..680f061 100644
--- a/perl-MooseX-Types-DateTime-ButMaintained.spec
+++ b/perl-MooseX-Types-DateTime-ButMaintained.spec
@@ -1,6 +1,6 @@
Name: perl-MooseX-Types-DateTime-ButMaintained
-Version:0.14
-Release:2%{?dist}
+Version:0.15
+Release:1%{?dist}
Summary:DateTime related constraints and coercions for Moose
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,7 +25,7 @@ BuildRequires: perl(Moose::Util::TypeConstraints)
BuildRequires: perl(Test::Exception) >= 0.27
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::use::ok) >= 0.02
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
# DateTime >= 0.4302 rounded to two places
Requires: perl(DateTime) >= 0.44
# DateTime::Locale >= 0.4001 rounded to two places
@@ -44,7 +44,7 @@ designed to work with the DateTime suite of objects.
%build
# switch off cpan installation
-PERL5_CPANPLUS_IS_RUNNING=1 %{__perl} Makefile.PL INSTALLDIRS=vendor
+PERL5_CPANPLUS_IS_RUNNING=1 perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
@@ -62,6 +62,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Šabata - 0.15-1
+- 0.15 bump
+- Drop command macros
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.14-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index dfb390f..b54cc86 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-538bccff2603b75bcb36665eee1bb0b6
MooseX-Types-DateTime-ButMaintained-0.14.tar.gz
+3934fd87da0c8eeb21447884d4711541
MooseX-Types-DateTime-ButMaintained-0.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File MooseX-Types-DateTime-ButMaintained-0.15.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-MooseX-Types-DateTime-ButMaintained: 3934fd87da0c8eeb21447884d4711541 MooseX-Types-DateTime-ButMaintained-0.15.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: gutenprint update in rawhide, soname bump
On Wed, Jun 13, 2012 at 08:59:08AM -0500, Jiri Popelka wrote: > Hi > > I built gutenprint 5.2.8 in rawhide. > This introduces a soname bump (libgutenprint.so.2 to .3). > > These packages (owners CCed) need rebuilding: > > cinepaint > photoprint Photoprint scratch build succeeded, picked up libgutenprint.so.3. Normal build started. If someone else wanted to take over this package, I'd be happy to pass it off. It hasn't seen a point release in nearly 3 years, or even a prerelease in 2, so maintenance on it is very light, but I find it useful, so I've done the minimal work to keep it going. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gutenprint update in rawhide, soname bump
Hi I built gutenprint 5.2.8 in rawhide. This introduces a soname bump (libgutenprint.so.2 to .3). These packages (owners CCed) need rebuilding: cinepaint photoprint -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On 06/13/2012 01:39 PM, Josh Boyer wrote: Yes, that is true. However it also speaks to the extremely small usage of rawhide and the relative lack of variety in both test hardware and setups. I have no magical solutions to those problems. We simply need more people testing rawhide kernels in general. A lot of us from the QA community who are not on rawhide are the running the rawhide kernels on F17 ( I'm currently on 3.5.0-0.rc2.git0.1.fc18.x86_64 ) and I have not noticed ( hence not reported ) any issue. I think the problem is actually the other way around those of us that are in the QA community aren't actually using official update GA kernel. And getting reporters to actually stay on a GA release once rawhide gets in usable shape ( which by my experience is around alpha ) is a problem. ( one of the thing that proven tester concept was supposed to address to ensure we had people testing GA ) And to add insult to injury reporters on update-testing have been routinely in the past been redirected from the test list to the user list with any issue they have discovered. Something I tried to address a while back amongst other things but certain people in our QA community want to keep the list rawhide only... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-App-cpanminus] 1.5014 bump
commit 8d5b5790fef36be6909ca9fe55a228b2cb40146d
Author: Petr Šabata
Date: Wed Jun 13 15:41:15 2012 +0200
1.5014 bump
.gitignore |1 +
perl-App-cpanminus.spec | 12
sources |2 +-
3 files changed, 10 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cc7c9d7..95ee913 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,3 +29,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.5010.tar.gz
/App-cpanminus-1.5011.tar.gz
/App-cpanminus-1.5013.tar.gz
+/App-cpanminus-1.5014.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 4e599fb..3a180b5 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,6 +1,6 @@
Name: perl-App-cpanminus
-Version:1.5013
-Release:2%{?dist}
+Version:1.5014
+Release:1%{?dist}
Summary:Library for get, unpack, build and install CPAN modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,7 +9,7 @@ Source0:
http://www.cpan.org/authors/id/M/MI/MIYAGAWA/App-cpanminus-%{ver
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
# Required by bin/cpanm
Requires: perl(Cwd)
Requires: perl(ExtUtils::Install) >= 1.46
@@ -46,7 +46,7 @@ scripting. When running, it requires only 10 MB of RAM.
%setup -q -n App-cpanminus-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
@@ -66,6 +66,10 @@ make test
%{_bindir}/cpanm
%changelog
+* Wed Jun 13 2012 Petr Šabata - 1.5014-1
+- 1.5014 bump
+- Drop command macros
+
* Mon Jun 11 2012 Petr Pisar - 1.5013-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index 8a63569..77b73c8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-156e69fbf3734814c0bd2e44fa706849 App-cpanminus-1.5013.tar.gz
+660a714119b1a0601f0618ee256486e9 App-cpanminus-1.5014.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 8:53 AM, Bruno Wolff III wrote: > On Wed, Jun 13, 2012 at 14:49:25 +0200, > Nikola Pajkovsky wrote: >> >> >> imo, kernel maintainers should have released 3.3.8 or 3.4.1, not 3.4.0 >> for f17 > > > 3.4.2 is available, though the last I checked the build hadn't been pushed > to testing. I don't know if that is an oversight or if they didn't feel the > kernel was suitable for releasing. I believe it's a matter of getting caught up. There are at least 2 more patches added after the 3.4.2 build that should probably get included in the next update. > The 3.4 kernels were being tested in rawhide before it was released to f17 > and at least of us weren't seeing any regressions with them. So there was > reason to believe they would work for people without problems. Yes, that is true. However it also speaks to the extremely small usage of rawhide and the relative lack of variety in both test hardware and setups. I have no magical solutions to those problems. We simply need more people testing rawhide kernels in general. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 9:24 AM, Roman Kennke wrote: > Would it make sense to require more karma than just the default 3? > Looking at: > > https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17 > > I see that there are 5 oks and 2 denys, which actually point to bug > reports, both sound fairly important. How does the karma system work if, > e.g., update requires +3, the update gets +4 and -1, and this -1 is > something that can be considered a release critical bug? data corruption > sounds quite release-critical? Is there a mechanism that prevents the > update to happen in this case? Good questions. The person that submits the update gets emails for every comment added to the update. This particular one had a couple things that happened though. 1) It got the requisite karma for stable rather quickly 2) Justin was on vacation when the negative karma was submitted. Bodhi only emails the update submitter and the rest of the kernel team didn't notice. I'm sure that it would have been pulled if Justin was actually around or if the rest of the kernel team had remembered to go check the update. It's something that can be looked at in the future. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SVG-Graph] Specify all dependencies
commit d1abe3e2639e090a187de9d6eafe452c5ed71bb0
Author: Petr Písař
Date: Wed Jun 13 15:34:30 2012 +0200
Specify all dependencies
perl-SVG-Graph.spec | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
---
diff --git a/perl-SVG-Graph.spec b/perl-SVG-Graph.spec
index a282934..523897d 100644
--- a/perl-SVG-Graph.spec
+++ b/perl-SVG-Graph.spec
@@ -10,13 +10,23 @@ Source1:LICENSE.fedora
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(SVG) >= 2.27
+# Run-time
+BuildRequires: perl(base)
+BuildRequires: perl(constant)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Math::Spline)
BuildRequires: perl(Statistics::Descriptive) >= 2.6
+BuildRequires: perl(SVG) >= 2.27
BuildRequires: perl(Tree::DAG_Node) >= 1.04
-BuildRequires: perl(Math::Derivative)
-BuildRequires: perl(Math::Spline)
+# Tests
+BuildRequires: perl(Test)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
-Requires: perl(Tree::DAG_Node)
+Requires: perl(Statistics::Descriptive) >= 2.6
+Requires: perl(SVG) >= 2.27
+Requires: perl(Tree::DAG_Node) >= 1.04
+
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Statistics::Descriptive|SVG|Tree::DAG_Node)\\)$
%description
SVG::Graph is a suite of perl modules for plotting data. SVG::Graph
@@ -60,6 +70,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Wed Jun 13 2012 Petr Pisar - 0.02-10
- Perl 5.16 rebuild
+- Specify all dependencies
* Fri Jan 13 2012 Fedora Release Engineering
- 0.02-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File App-cpanminus-1.5014.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-App-cpanminus: 660a714119b1a0601f0618ee256486e9 App-cpanminus-1.5014.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 9:14 AM, M A Young wrote: > On Wed, 13 Jun 2012, Nikola Pajkovsky wrote: > >> imo, kernel maintainers should have released 3.3.8 or 3.4.1, not 3.4.0 >> for f17 > > > I believe the 3.4.0 kernel package was effectively 3.4.1 anyway. Yes, it was. Justin added the patches queued for the 3.4.1 release before he submitted the build. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
Xavier Bachelot writes: > Does anyone have any pointer on how to fix a multilib conflict with a > doxygen generated pdf file ? I was able to fix the same multilib issue > with the html files by modifying the footer to not include the > timestamp, but I don't find any pointer on how to proceed for the pdf file. Yeah, I find that the sgml to pdf toolchain also likes to put timestamps into the PDF file. The solution I've used for many years is to build the PDF doc once during package preparation, and upload it as an additional sources file. This eliminates the timestamp skew problem and also greatly reduces the BuildRequires footprint of the package. You can look into the postgresql package if you want to borrow any details (the generate-pdf.sh script is probably pretty postgresql specific, but the packaging details around its use might be worth stealing). regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Am Mittwoch, den 13.06.2012, 14:29 +0200 schrieb Stijn Hoop: > Hi, > > On Wed, 13 Jun 2012 14:15:14 +0200 > Roman Kennke wrote: > > Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: > > > I think the reason for shipping the latest upstream kernel is based > > > on the fact that backporting would be too much work. > > > http://fedoraproject.org/wiki/KernelRebases > > > Gives a good overview and probably prevents us from repeating > > > arguments in the discussion. > > > > Ok, fair enough. The question remains, how can we avoid such bad > > things to happen in the future? Should I regularily try out kernel > > builds on their way to stable, and object to their stable-release > > when I find a problem? And how would I do that? (I.e. how can I find > > out when a new kernel is about to go to stable, and when to test it, > > etc) And what about the other base components of the system? > > (Although, to be fair, the kernel seems to be the most problematic > > one..) > > Check > > https://admin.fedoraproject.org/updates/kernel > > for updates. Provide negative karma for them in Bodhi as well: > > http://fedoraproject.org/wiki/QA/Updates_Testing Thanks everybody! I subscribed to the above updates/kernel RSS feed and will try to test kernels before they go to stable. Would it make sense to require more karma than just the default 3? Looking at: https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17 I see that there are 5 oks and 2 denys, which actually point to bug reports, both sound fairly important. How does the karma system work if, e.g., update requires +3, the update gets +4 and -1, and this -1 is something that can be considered a release critical bug? data corruption sounds quite release-critical? Is there a mechanism that prevents the update to happen in this case? Roman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, 13 Jun 2012, Nikola Pajkovsky wrote: imo, kernel maintainers should have released 3.3.8 or 3.4.1, not 3.4.0 for f17 I believe the 3.4.0 kernel package was effectively 3.4.1 anyway. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Dump-Streamer] Perl 5.16 rebuild
commit ceadb77331fb49e23c837d60b1031dbca7240c76
Author: Petr Písař
Date: Wed Jun 13 14:57:36 2012 +0200
Perl 5.16 rebuild
perl-Data-Dump-Streamer.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-Dump-Streamer.spec b/perl-Data-Dump-Streamer.spec
index 9a717ff..176838e 100644
--- a/perl-Data-Dump-Streamer.spec
+++ b/perl-Data-Dump-Streamer.spec
@@ -1,6 +1,6 @@
Name: perl-Data-Dump-Streamer
Version:2.34
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Accurately serialize a data structure as Perl code
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f
{} \;
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 2.34-2
+- Perl 5.16 rebuild
+
* Sat Jun 09 2012 Iain Arnell 2.34-1
- update to latest upstream version
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-File-DesktopEntry] Perl 5.16 rebuild
commit bb5e74b610bac83e24a7b1e8cf2ef95d31ec3ecf
Author: Petr Písař
Date: Wed Jun 13 14:57:29 2012 +0200
Perl 5.16 rebuild
perl-File-DesktopEntry.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-DesktopEntry.spec b/perl-File-DesktopEntry.spec
index 96e3909..2dbe102 100644
--- a/perl-File-DesktopEntry.spec
+++ b/perl-File-DesktopEntry.spec
@@ -1,6 +1,6 @@
Name: perl-File-DesktopEntry
Version:0.04
-Release:16%{?dist}
+Release:17%{?dist}
Summary:Object to handle .desktop files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.04-17
+- Perl 5.16 rebuild
+
* Fri Apr 27 2012 Marcela Mašláňová - 0.04-15
- apply patch from MozBug for fixing encoding of utf-8 files 816809, cpan#76843
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Crypt-Rijndael] Perl 5.16 rebuild
commit a1d3bdb6186d6abe64326b85d868e70ade4ed28e
Author: Petr Písař
Date: Wed Jun 13 14:57:14 2012 +0200
Perl 5.16 rebuild
perl-Crypt-Rijndael.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Crypt-Rijndael.spec b/perl-Crypt-Rijndael.spec
index 06bf38f..7fd5fc2 100644
--- a/perl-Crypt-Rijndael.spec
+++ b/perl-Crypt-Rijndael.spec
@@ -1,6 +1,6 @@
Name: perl-Crypt-Rijndael
Version:1.09
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Crypt::CBC compliant Rijndael encryption module
License:LGPLv2+
Group: Development/Libraries
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.09-8
+- Perl 5.16 rebuild
+
* Sat Jan 14 2012 Iain Arnell 1.09-7
- BuildRequires perl(Digest::MD5)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-HTTP-Server-Simple] Perl 5.16 rebuild
commit 507f1bf4d5dfb900cb49f9850e50cbc394df1fbb
Author: Petr Písař
Date: Wed Jun 13 14:56:03 2012 +0200
Perl 5.16 rebuild
perl-Test-HTTP-Server-Simple.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-HTTP-Server-Simple.spec
b/perl-Test-HTTP-Server-Simple.spec
index d0b7890..f71274f 100644
--- a/perl-Test-HTTP-Server-Simple.spec
+++ b/perl-Test-HTTP-Server-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Test-HTTP-Server-Simple
Version:0.11
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Test::More functions for HTTP::Server::Simple
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.11-8
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.11-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Config-Tiny] Perl 5.16 rebuild
commit 3786f1f42ed00dbf762acad7f17888c9f853300d
Author: Petr Písař
Date: Wed Jun 13 14:55:53 2012 +0200
Perl 5.16 rebuild
perl-Config-Tiny.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Config-Tiny.spec b/perl-Config-Tiny.spec
index a8800f0..8567c49 100644
--- a/perl-Config-Tiny.spec
+++ b/perl-Config-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-Config-Tiny
Version: 2.14
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: Perl module for reading and writing .ini style configuration
files
Group: Development/Libraries
License: GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Config::Tiny.3pm*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 2.14-4
+- Perl 5.16 rebuild
+
* Thu Jan 19 2012 Paul Howarth - 2.14-3
- Reinstate compatibility with older distributions like EL-5
- Run release tests as well as the regular test suite
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 14:49:25 +0200, Nikola Pajkovsky wrote: imo, kernel maintainers should have released 3.3.8 or 3.4.1, not 3.4.0 for f17 3.4.2 is available, though the last I checked the build hadn't been pushed to testing. I don't know if that is an oversight or if they didn't feel the kernel was suitable for releasing. The 3.4 kernels were being tested in rawhide before it was released to f17 and at least of us weren't seeing any regressions with them. So there was reason to believe they would work for people without problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-POE-Filter-IRCD] Perl 5.16 rebuild
commit 03f7fcbd8b50be7461f8827f4313030af787f353
Author: Petr Písař
Date: Wed Jun 13 14:53:31 2012 +0200
Perl 5.16 rebuild
perl-POE-Filter-IRCD.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Filter-IRCD.spec b/perl-POE-Filter-IRCD.spec
index f268df6..cd5d77d 100644
--- a/perl-POE-Filter-IRCD.spec
+++ b/perl-POE-Filter-IRCD.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Filter-IRCD
Version:2.42
-Release:4%{?dist}
+Release:5%{?dist}
Summary:A POE-based parser for the IRC protocol
Group: Development/Libraries
@@ -67,6 +67,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jun 13 2012 Petr Pisar - 2.42-5
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 2.42-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Time-OlsonTZ-Download] Perl 5.16 rebuild
commit 3a562626d4352b2a5dc1af3dbd9f24a914081219
Author: Petr Písař
Date: Wed Jun 13 14:53:03 2012 +0200
Perl 5.16 rebuild
perl-Time-OlsonTZ-Download.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Time-OlsonTZ-Download.spec b/perl-Time-OlsonTZ-Download.spec
index e8edd64..032d63e 100644
--- a/perl-Time-OlsonTZ-Download.spec
+++ b/perl-Time-OlsonTZ-Download.spec
@@ -1,6 +1,6 @@
Name: perl-Time-OlsonTZ-Download
Version:0.003
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Olson timezone database from source
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,5 +54,8 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.003-2
+- Perl 5.16 rebuild
+
* Sun Mar 25 2012 Iain Arnell 0.003-1
- Specfile autogenerated by cpanspec 1.79.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Hash-MoreUtils] Perl 5.16 rebuild
commit 9fc82af38e0cf349a3ddc33f75adc21c6ed5857e
Author: Petr Písař
Date: Wed Jun 13 14:50:39 2012 +0200
Perl 5.16 rebuild
perl-Hash-MoreUtils.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Hash-MoreUtils.spec b/perl-Hash-MoreUtils.spec
index c2cf1fb..b397926 100644
--- a/perl-Hash-MoreUtils.spec
+++ b/perl-Hash-MoreUtils.spec
@@ -1,6 +1,6 @@
Name: perl-Hash-MoreUtils
Version:0.02
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Provide the stuff missing in Hash::Util
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.02-4
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.02-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
Roman Kennke writes: > Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: >> >> >> On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke >> wrote: >> > Today something happened, that happens over and over again >> with Fedora, >> > and it makes me angry. I am running Fedora 17, and so far it >> worked well >> > with the initial kernel 3.3.x (except that it would panic on >> shutdown... >> > but that was not important to me, but still embarassing). >> Today I was >> > notified of an important security update in the kernel. >> Curiously, it >> > would update from 3.3 to 3.4 (a major version upgrade, which >> should not >> > happen in such a core package anyway, IMO). Reboot into the >> new kernel, >> > everything comes up --- until I want to actually want to >> read email, >> > surf web, or anything that requires my network. I am on an >> Intel Wifi >> > card, iwlwifi module. I *can* connect to the network, but >> everything is >> > suuper slow or times-out every now and then. Completely >> unusable. >> > Reboot into the older kernel, things work well again. Now I >> am left with >> > the choice of running a new kernel w/o network or an >> unsecure kernel. >> > Thank you very much! >> > >> > This sort of thing I would expect in rawhide/development >> builds, but not >> > in a supposed-to-be stable release. I can understand the >> underlying idea >> > of being on the bleeding edge, but I don't want to actually >> be bleeding. >> > At least the base system components should not undergo major >> version >> > updates. Security fixes should be backported to the software >> version >> > that is in the stable release (1 year release cycle >> shouldn't be too >> > demanding for this), and only security fixes and absolutely >> important >> > fixes should go into stable releases. (Not to mention that >> some fixes >> > that I *would* consider important enough to go into stable >> never end up >> > there.) If major version updates are really really >> necessary, they >> > should undergo serious testing. I cannot believe that I am >> the only one >> > on an Intel Wifi chip. The way it is now, Fedora feels like >> a constantly >> > rolling development version that is almost unusable (because >> any update, >> > even security, has a fairly high risk of breaking things) >> for day-to-day >> > work. >> > >> > Bugzilla report: >> > https://bugzilla.redhat.com/show_bug.cgi?id=831571 >> >> >> Since I just received an email in private pointing out that >> emails like >> mine above might be discouraging and not helpful... let me >> apologize for >> this. My intention is not to bash other people's best efforts, >> but >> instead try to help out (otherwise I would not bother to >> diligently file >> bugreports and mention my concerns on this list). I am willing >> to help >> track down and fix the problem. However, I see a more general >> problem >> and maybe we can turn this into a discussion how to address >> (or answer) >> it. >> >> - Why do we allow new major versions of core components into a >> stable >> release? What sort of testing is performed before a major >> kernel update >> hits Fedora stable? >> - What is the policy with regards to risky changes (like >> unnecessary >> feature updates, ABI changes, etc) in stable? >> - How can problems like the one I described above be avoided? >> Is there >> anything I and others can help with? >> >> Roman >> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> I think the reason for shipping the latest upstream kernel is based on >> the fact that backporting would be too much work. >> http://fedoraproject.org/wiki/KernelRebases >> Gives a good overview and probably prevents us from repeating >> arguments in the discussion. > > Ok, fair enough. The question remains, how can we avoid such bad things > to happen in the future? Should I regularily try out kernel builds on > their way to stable, and object to their stable-release when I find a > problem? And how would I do that? (I.e. how can I find out when a new > kernel is about to go to stable, and when to test it, etc) And what > about the other base components of the system? (Al
[perl-Lexical-Var] Perl 5.16 rebuild
commit 9a85ee7844c5072d63711c45a5df6881e01dcc5e
Author: Petr Písař
Date: Wed Jun 13 14:35:06 2012 +0200
Perl 5.16 rebuild
perl-Lexical-Var.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Lexical-Var.spec b/perl-Lexical-Var.spec
index 90a8ec7..2dd9a29 100644
--- a/perl-Lexical-Var.spec
+++ b/perl-Lexical-Var.spec
@@ -1,6 +1,6 @@
Name: perl-Lexical-Var
Version:0.007
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Static variables without name space pollution
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,5 +47,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.007-2
+- Perl 5.16 rebuild
+
* Tue May 22 2012 Jitka Plesnikova 0.007-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Variable-Magic] Perl 5.16 rebuild
commit 59f299f23685202544d0a752bd8cf393b23fb7b2
Author: Petr Písař
Date: Wed Jun 13 14:34:58 2012 +0200
Perl 5.16 rebuild
perl-Variable-Magic.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Variable-Magic.spec b/perl-Variable-Magic.spec
index 893b3d7..0194225 100644
--- a/perl-Variable-Magic.spec
+++ b/perl-Variable-Magic.spec
@@ -1,6 +1,6 @@
Name: perl-Variable-Magic
Version:0.49
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Associate user-defined magic to variables from Perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.49-2
+- Perl 5.16 rebuild
+
* Sat Jun 09 2012 Emmanuel Seyman - 0.49-1
- Update to 0.49
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-SimpleLog] Perl 5.16 rebuild
commit a6c97cba7208d2b65d04bba487d352c37a66e798
Author: Petr Písař
Date: Wed Jun 13 14:32:24 2012 +0200
Perl 5.16 rebuild
perl-POE-Component-SimpleLog.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-SimpleLog.spec
b/perl-POE-Component-SimpleLog.spec
index 0bb4f73..d7102ad 100644
--- a/perl-POE-Component-SimpleLog.spec
+++ b/perl-POE-Component-SimpleLog.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Component-SimpleLog
Version:1.05
-Release:9%{?dist}
+Release:10%{?dist}
Summary:A simple logging system for POE
Group: Development/Libraries
@@ -65,6 +65,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.05-10
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 1.05-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-EOL] Perl 5.16 rebuild
commit c8b7ae865ef7b78da78d85eb7ce8d9dae940b4b7
Author: Petr Písař
Date: Wed Jun 13 14:32:02 2012 +0200
Perl 5.16 rebuild
perl-Test-EOL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-EOL.spec b/perl-Test-EOL.spec
index c5f76c4..8ea566b 100644
--- a/perl-Test-EOL.spec
+++ b/perl-Test-EOL.spec
@@ -3,7 +3,7 @@
Name: perl-Test-EOL
Version: 1.1
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check the correct line endings in your project
Group: Development/Libraries
License: GPL+ or Artistic
@@ -64,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::EOL.3pm*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.1-2
+- Perl 5.16 rebuild
+
* Mon Jan 16 2012 Paul Howarth 1.1-1
- Update to 1.1
- Fix test fails on < 5.8 perls
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
- Original Message - > From: "Roman Kennke" > To: "Development discussions related to Fedora" > > Sent: Wednesday, June 13, 2012 3:15:14 PM > Subject: Re: Important kernel update should not break stuff > > Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: > > > > > > On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke > > wrote: > > > Today something happened, that happens over and over > > > again > > with Fedora, > > > and it makes me angry. I am running Fedora 17, and so far > > > it > > worked well > > > with the initial kernel 3.3.x (except that it would panic > > > on > > shutdown... > > > but that was not important to me, but still embarassing). > > Today I was > > > notified of an important security update in the kernel. > > Curiously, it > > > would update from 3.3 to 3.4 (a major version upgrade, > > > which > > should not > > > happen in such a core package anyway, IMO). Reboot into > > > the > > new kernel, > > > everything comes up --- until I want to actually want to > > read email, > > > surf web, or anything that requires my network. I am on > > > an > > Intel Wifi > > > card, iwlwifi module. I *can* connect to the network, but > > everything is > > > suuper slow or times-out every now and then. > > > Completely > > unusable. > > > Reboot into the older kernel, things work well again. Now > > > I > > am left with > > > the choice of running a new kernel w/o network or an > > unsecure kernel. > > > Thank you very much! > > > > > > This sort of thing I would expect in rawhide/development > > builds, but not > > > in a supposed-to-be stable release. I can understand the > > underlying idea > > > of being on the bleeding edge, but I don't want to > > > actually > > be bleeding. > > > At least the base system components should not undergo > > > major > > version > > > updates. Security fixes should be backported to the > > > software > > version > > > that is in the stable release (1 year release cycle > > shouldn't be too > > > demanding for this), and only security fixes and > > > absolutely > > important > > > fixes should go into stable releases. (Not to mention > > > that > > some fixes > > > that I *would* consider important enough to go into > > > stable > > never end up > > > there.) If major version updates are really really > > necessary, they > > > should undergo serious testing. I cannot believe that I > > > am > > the only one > > > on an Intel Wifi chip. The way it is now, Fedora feels > > > like > > a constantly > > > rolling development version that is almost unusable > > > (because > > any update, > > > even security, has a fairly high risk of breaking things) > > for day-to-day > > > work. > > > > > > Bugzilla report: > > > https://bugzilla.redhat.com/show_bug.cgi?id=831571 > > > > > > Since I just received an email in private pointing out that > > emails like > > mine above might be discouraging and not helpful... let me > > apologize for > > this. My intention is not to bash other people's best > > efforts, > > but > > instead try to help out (otherwise I would not bother to > > diligently file > > bugreports and mention my concerns on this list). I am > > willing > > to help > > track down and fix the problem. However, I see a more > > general > > problem > > and maybe we can turn this into a discussion how to address > > (or answer) > > it. > > > > - Why do we allow new major versions of core components > > into a > > stable > > release? What sort of testing is performed before a major > > kernel update > > hits Fedora stable? > > - What is the policy with regards to risky changes (like > > unnecessary > > feature updates, ABI changes, etc) in stable? > > - How can problems like the one I described above be > > avoided? > > Is there > > anything I and others can help with? > > > > Roman > > > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > I think the reason for shipping the latest upstream kernel is based > > on > > the fact
[perl-Tk-ColoredButton] Perl 5.16 rebuild
commit 30d6351b66d947ed6d6c039fe1ab8a7adae96f5a
Author: Petr Písař
Date: Wed Jun 13 14:31:01 2012 +0200
Perl 5.16 rebuild
perl-Tk-ColoredButton.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk-ColoredButton.spec b/perl-Tk-ColoredButton.spec
index 23316c3..c88142f 100644
--- a/perl-Tk-ColoredButton.spec
+++ b/perl-Tk-ColoredButton.spec
@@ -1,6 +1,6 @@
Name: perl-Tk-ColoredButton
Version:1.05
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Button widget with background gradient color
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,5 +56,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.05-2
+- Perl 5.16 rebuild
+
* Wed Feb 22 2012 Petr Pisar 1.05-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Email-MessageID] Perl 5.16 rebuild
commit 42cf8c62d9a5447256e31ef0b5ffcd09d523a54d
Author: Petr Písař
Date: Wed Jun 13 14:30:55 2012 +0200
Perl 5.16 rebuild
perl-Email-MessageID.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Email-MessageID.spec b/perl-Email-MessageID.spec
index e964b8e..ed92f44 100644
--- a/perl-Email-MessageID.spec
+++ b/perl-Email-MessageID.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MessageID
Version:1.401
-Release:11%{?dist}
+Release:12%{?dist}
Summary:Generate world unique message-ids
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Jun 13 2012 Petr Pisar - 1.401-12
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 1.401-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
On 13/06/12 13:15, Roman Kennke wrote: Ok, fair enough. The question remains, how can we avoid such bad things to happen in the future? Should I regularily try out kernel builds on their way to stable, and object to their stable-release when I find a problem? And how would I do that? (I.e. how can I find out when a new kernel is about to go to stable, and when to test it, etc) Test the kernels when they arrive in testing-updates. Well in advance of stable. Give\Deny karma as appropriate. based on what problems may occur. -- Regards, Frank "Jack of all, fubars" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 8:15 AM, Roman Kennke wrote: >> I think the reason for shipping the latest upstream kernel is based on >> the fact that backporting would be too much work. >> http://fedoraproject.org/wiki/KernelRebases >> Gives a good overview and probably prevents us from repeating >> arguments in the discussion. > > Ok, fair enough. The question remains, how can we avoid such bad things > to happen in the future? Should I regularily try out kernel builds on > their way to stable, and object to their stable-release when I find a > problem? And how would I do that? (I.e. how can I find out when a new Yes, testing would be very much appreciated. > kernel is about to go to stable, and when to test it, etc) And what > about the other base components of the system? (Although, to be fair, > the kernel seems to be the most problematic one..) The kernel maintainers push all updates through updates-testing for this very reason. It is very rare that one is pushed directly to stable. You can use 'yum update --enablerepo=updates-testing kernel' (or similar commands) to only update the kernel from updates testing if you wish. Then you provide karma in Bodhi. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Hi, On Wed, 13 Jun 2012 14:15:14 +0200 Roman Kennke wrote: > Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: > > I think the reason for shipping the latest upstream kernel is based > > on the fact that backporting would be too much work. > > http://fedoraproject.org/wiki/KernelRebases > > Gives a good overview and probably prevents us from repeating > > arguments in the discussion. > > Ok, fair enough. The question remains, how can we avoid such bad > things to happen in the future? Should I regularily try out kernel > builds on their way to stable, and object to their stable-release > when I find a problem? And how would I do that? (I.e. how can I find > out when a new kernel is about to go to stable, and when to test it, > etc) And what about the other base components of the system? > (Although, to be fair, the kernel seems to be the most problematic > one..) Check https://admin.fedoraproject.org/updates/kernel for updates. Provide negative karma for them in Bodhi as well: http://fedoraproject.org/wiki/QA/Updates_Testing Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Array-Base] Perl 5.16 rebuild
commit 443fee68d1675c73a28cfbbac7a679495a0f664b
Author: Petr Písař
Date: Wed Jun 13 14:17:38 2012 +0200
Perl 5.16 rebuild
perl-Array-Base.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Array-Base.spec b/perl-Array-Base.spec
index 6d380c0..fc5c34c 100644
--- a/perl-Array-Base.spec
+++ b/perl-Array-Base.spec
@@ -1,6 +1,6 @@
Name: perl-Array-Base
Version:0.005
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Array index offsetting
License:GPL+ or Artistic
Group: Development/Libraries
@@ -52,5 +52,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.005-2
+- Perl 5.16 rebuild
+
* Fri Jun 08 2012 Jitka Plesnikova 0.005-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Color-Library] Perl 5.16 rebuild
commit 083a45849e1a614eb6813d1104162bcc4be370b2
Author: Petr Písař
Date: Wed Jun 13 14:17:33 2012 +0200
Perl 5.16 rebuild
perl-Color-Library.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Color-Library.spec b/perl-Color-Library.spec
index 284fa03..ce1a345 100644
--- a/perl-Color-Library.spec
+++ b/perl-Color-Library.spec
@@ -1,6 +1,6 @@
Name: perl-Color-Library
Version:0.02
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Easy-to-use and comprehensive named-color library
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.02-11
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.02-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Term-Size-Any] Perl 5.16 rebuild
commit 98e9df6797dfe4558067b15654a35d3a5f94bfb7
Author: Petr Písař
Date: Wed Jun 13 14:17:27 2012 +0200
Perl 5.16 rebuild
perl-Term-Size-Any.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Term-Size-Any.spec b/perl-Term-Size-Any.spec
index d22ab7e..df85f67 100644
--- a/perl-Term-Size-Any.spec
+++ b/perl-Term-Size-Any.spec
@@ -1,6 +1,6 @@
Name: perl-Term-Size-Any
Version:0.002
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Retrieve terminal size
License:GPL+ or Artistic
Group: Development/Libraries
@@ -48,6 +48,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.002-9
+- Perl 5.16 rebuild
+
* Sun Apr 22 2012 Iain Arnell 0.002-8
- update to latest upstream version
- clean up spec for modern rpmbuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Base] Perl 5.16 rebuild
commit 92170892d9b77e0a61c4398433a36e8174eb4786
Author: Petr Písař
Date: Wed Jun 13 14:17:04 2012 +0200
Perl 5.16 rebuild
perl-Test-Base.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Base.spec b/perl-Test-Base.spec
index 455be09..98276f7 100644
--- a/perl-Test-Base.spec
+++ b/perl-Test-Base.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Base
Version:0.60
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Data Driven Testing Framework
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.60-4
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.60-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Hash-Merge] Perl 5.16 rebuild
commit 88c4856e7c9f9a8e0b74353c56ff60840ffbb487
Author: Petr Písař
Date: Wed Jun 13 14:17:04 2012 +0200
Perl 5.16 rebuild
perl-Hash-Merge.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Hash-Merge.spec b/perl-Hash-Merge.spec
index 7950b14..53ceba8 100644
--- a/perl-Hash-Merge.spec
+++ b/perl-Hash-Merge.spec
@@ -1,6 +1,6 @@
Name: perl-Hash-Merge
Version:0.12
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Merges arbitrary deep hashes into a single hash
Group: Development/Libraries
License:GPL+ or Artistic
@@ -48,6 +48,9 @@ rm -rf %{buildroot}
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.12-8
+- Perl 5.16 rebuild
+
* Mon Apr 09 2012 Iain Arnell 0.12-7
- explicitly require perl(Clone)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: multilib conflict with doxygen generated pdf
On 06/13/2012 01:10 PM, Orcan Ogetbil wrote: On Wed, Jun 13, 2012 at 5:12 AM, Xavier Bachelot wrote: Hi, Does anyone have any pointer on how to fix a multilib conflict with a doxygen generated pdf file ? I was able to fix the same multilib issue with the html files by modifying the footer to not include the timestamp, but I don't find any pointer on how to proceed for the pdf file. The only official doc is on how to modify the html footer http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Doxygen_footers To my knowledge, doxygen was not generating different PDFs on each separate build until recently. There was no need for instructions for PDFs. Alternatively, I can probably put the doc files in a noarch -doc subpackage, or even don't generate the pdf file at all, but I'd rather fix the issue in a different way. Yes I think these are the only options at the time. I don't think the noarch subpackage option will work because I seem to recall the sub-packages from the different arch builds get compared at the end of the koji task and the build fails if the noarch sub-packages are not all the same. Or is that a figment of my imagination? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Compile] Perl 5.16 rebuild
commit d8e1bbd4ffc788147b05c45b9772772b7bc340af
Author: Petr Písař
Date: Wed Jun 13 14:15:23 2012 +0200
Perl 5.16 rebuild
perl-CGI-Compile.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Compile.spec b/perl-CGI-Compile.spec
index 4ee0237..47a9091 100644
--- a/perl-CGI-Compile.spec
+++ b/perl-CGI-Compile.spec
@@ -1,7 +1,7 @@
Name: perl-CGI-Compile
Summary:Compile .cgi scripts to a code reference like ModPerl::Registry
Version:0.15
-Release:3%{?dist}
+Release:4%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/CGI-Compile-%{version}.tar.gz
@@ -53,6 +53,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Wed Jun 13 2012 Petr Pisar - 0.15-4
+- Perl 5.16 rebuild
+
* Sun Jan 22 2012 Iain Arnell 0.15-3
- drop tests subpackage; move tests to main package documentation
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Important kernel update should not break stuff
Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: > > > On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke > wrote: > > Today something happened, that happens over and over again > with Fedora, > > and it makes me angry. I am running Fedora 17, and so far it > worked well > > with the initial kernel 3.3.x (except that it would panic on > shutdown... > > but that was not important to me, but still embarassing). > Today I was > > notified of an important security update in the kernel. > Curiously, it > > would update from 3.3 to 3.4 (a major version upgrade, which > should not > > happen in such a core package anyway, IMO). Reboot into the > new kernel, > > everything comes up --- until I want to actually want to > read email, > > surf web, or anything that requires my network. I am on an > Intel Wifi > > card, iwlwifi module. I *can* connect to the network, but > everything is > > suuper slow or times-out every now and then. Completely > unusable. > > Reboot into the older kernel, things work well again. Now I > am left with > > the choice of running a new kernel w/o network or an > unsecure kernel. > > Thank you very much! > > > > This sort of thing I would expect in rawhide/development > builds, but not > > in a supposed-to-be stable release. I can understand the > underlying idea > > of being on the bleeding edge, but I don't want to actually > be bleeding. > > At least the base system components should not undergo major > version > > updates. Security fixes should be backported to the software > version > > that is in the stable release (1 year release cycle > shouldn't be too > > demanding for this), and only security fixes and absolutely > important > > fixes should go into stable releases. (Not to mention that > some fixes > > that I *would* consider important enough to go into stable > never end up > > there.) If major version updates are really really > necessary, they > > should undergo serious testing. I cannot believe that I am > the only one > > on an Intel Wifi chip. The way it is now, Fedora feels like > a constantly > > rolling development version that is almost unusable (because > any update, > > even security, has a fairly high risk of breaking things) > for day-to-day > > work. > > > > Bugzilla report: > > https://bugzilla.redhat.com/show_bug.cgi?id=831571 > > > Since I just received an email in private pointing out that > emails like > mine above might be discouraging and not helpful... let me > apologize for > this. My intention is not to bash other people's best efforts, > but > instead try to help out (otherwise I would not bother to > diligently file > bugreports and mention my concerns on this list). I am willing > to help > track down and fix the problem. However, I see a more general > problem > and maybe we can turn this into a discussion how to address > (or answer) > it. > > - Why do we allow new major versions of core components into a > stable > release? What sort of testing is performed before a major > kernel update > hits Fedora stable? > - What is the policy with regards to risky changes (like > unnecessary > feature updates, ABI changes, etc) in stable? > - How can problems like the one I described above be avoided? > Is there > anything I and others can help with? > > Roman > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I think the reason for shipping the latest upstream kernel is based on > the fact that backporting would be too much work. > http://fedoraproject.org/wiki/KernelRebases > Gives a good overview and probably prevents us from repeating > arguments in the discussion. Ok, fair enough. The question remains, how can we avoid such bad things to happen in the future? Should I regularily try out kernel builds on their way to stable, and object to their stable-release when I find a problem? And how would I do that? (I.e. how can I find out when a new kernel is about to go to stable, and when to test it, etc) And what about the other base components of the system? (Although, to be fair, the kernel seems to be the most problematic one..) Roman -- devel mailing list devel@lists.fedoraproject.org https://adm
Re: multilib conflict with doxygen generated pdf
On Wed, Jun 13, 2012 at 5:12 AM, Xavier Bachelot wrote: > Hi, > > Does anyone have any pointer on how to fix a multilib conflict with a > doxygen generated pdf file ? I was able to fix the same multilib issue with > the html files by modifying the footer to not include the timestamp, but I > don't find any pointer on how to proceed for the pdf file. > The only official doc is on how to modify the html footer http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Doxygen_footers To my knowledge, doxygen was not generating different PDFs on each separate build until recently. There was no need for instructions for PDFs. > Alternatively, I can probably put the doc files in a noarch -doc subpackage, > or even don't generate the pdf file at all, but I'd rather fix the issue in > a different way. > Yes I think these are the only options at the time. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke wrote: > > Today something happened, that happens over and over again with Fedora, > > and it makes me angry. I am running Fedora 17, and so far it worked well > > with the initial kernel 3.3.x (except that it would panic on shutdown... > > but that was not important to me, but still embarassing). Today I was > > notified of an important security update in the kernel. Curiously, it > > would update from 3.3 to 3.4 (a major version upgrade, which should not > > happen in such a core package anyway, IMO). Reboot into the new kernel, > > everything comes up --- until I want to actually want to read email, > > surf web, or anything that requires my network. I am on an Intel Wifi > > card, iwlwifi module. I *can* connect to the network, but everything is > > suuper slow or times-out every now and then. Completely unusable. > > Reboot into the older kernel, things work well again. Now I am left with > > the choice of running a new kernel w/o network or an unsecure kernel. > > Thank you very much! > > > > This sort of thing I would expect in rawhide/development builds, but not > > in a supposed-to-be stable release. I can understand the underlying idea > > of being on the bleeding edge, but I don't want to actually be bleeding. > > At least the base system components should not undergo major version > > updates. Security fixes should be backported to the software version > > that is in the stable release (1 year release cycle shouldn't be too > > demanding for this), and only security fixes and absolutely important > > fixes should go into stable releases. (Not to mention that some fixes > > that I *would* consider important enough to go into stable never end up > > there.) If major version updates are really really necessary, they > > should undergo serious testing. I cannot believe that I am the only one > > on an Intel Wifi chip. The way it is now, Fedora feels like a constantly > > rolling development version that is almost unusable (because any update, > > even security, has a fairly high risk of breaking things) for day-to-day > > work. > > > > Bugzilla report: > > https://bugzilla.redhat.com/show_bug.cgi?id=831571 > > Since I just received an email in private pointing out that emails like > mine above might be discouraging and not helpful... let me apologize for > this. My intention is not to bash other people's best efforts, but > instead try to help out (otherwise I would not bother to diligently file > bugreports and mention my concerns on this list). I am willing to help > track down and fix the problem. However, I see a more general problem > and maybe we can turn this into a discussion how to address (or answer) > it. > > - Why do we allow new major versions of core components into a stable > release? What sort of testing is performed before a major kernel update > hits Fedora stable? > - What is the policy with regards to risky changes (like unnecessary > feature updates, ABI changes, etc) in stable? > - How can problems like the one I described above be avoided? Is there > anything I and others can help with? > > Roman > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I think the reason for shipping the latest upstream kernel is based on the fact that backporting would be too much work. http://fedoraproject.org/wiki/KernelRebases Gives a good overview and probably prevents us from repeating arguments in the discussion. Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
> Today something happened, that happens over and over again with Fedora, > and it makes me angry. I am running Fedora 17, and so far it worked well > with the initial kernel 3.3.x (except that it would panic on shutdown... > but that was not important to me, but still embarassing). Today I was > notified of an important security update in the kernel. Curiously, it > would update from 3.3 to 3.4 (a major version upgrade, which should not > happen in such a core package anyway, IMO). Reboot into the new kernel, > everything comes up --- until I want to actually want to read email, > surf web, or anything that requires my network. I am on an Intel Wifi > card, iwlwifi module. I *can* connect to the network, but everything is > suuper slow or times-out every now and then. Completely unusable. > Reboot into the older kernel, things work well again. Now I am left with > the choice of running a new kernel w/o network or an unsecure kernel. > Thank you very much! > > This sort of thing I would expect in rawhide/development builds, but not > in a supposed-to-be stable release. I can understand the underlying idea > of being on the bleeding edge, but I don't want to actually be bleeding. > At least the base system components should not undergo major version > updates. Security fixes should be backported to the software version > that is in the stable release (1 year release cycle shouldn't be too > demanding for this), and only security fixes and absolutely important > fixes should go into stable releases. (Not to mention that some fixes > that I *would* consider important enough to go into stable never end up > there.) If major version updates are really really necessary, they > should undergo serious testing. I cannot believe that I am the only one > on an Intel Wifi chip. The way it is now, Fedora feels like a constantly > rolling development version that is almost unusable (because any update, > even security, has a fairly high risk of breaking things) for day-to-day > work. > > Bugzilla report: > https://bugzilla.redhat.com/show_bug.cgi?id=831571 Since I just received an email in private pointing out that emails like mine above might be discouraging and not helpful... let me apologize for this. My intention is not to bash other people's best efforts, but instead try to help out (otherwise I would not bother to diligently file bugreports and mention my concerns on this list). I am willing to help track down and fix the problem. However, I see a more general problem and maybe we can turn this into a discussion how to address (or answer) it. - Why do we allow new major versions of core components into a stable release? What sort of testing is performed before a major kernel update hits Fedora stable? - What is the policy with regards to risky changes (like unnecessary feature updates, ABI changes, etc) in stable? - How can problems like the one I described above be avoided? Is there anything I and others can help with? Roman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[RFE] color man-pages, bash history, clear console
hi, == https://bugzilla.redhat.com/815790 == clear_console: New helper program to clear the *console*, including the _scrollback buffer_. DESCRIPTION clear_console clears your console if this is possible. It looks in the environment for the terminal type and then in the terminfo database to figure out how to clear the screen. To clear the buffer, it then changes the foreground virtual terminal to another terminal and then back to the original terminal. == https://bugzilla.redhat.com/815810 == add "shopt -s histappend" to /etc/bashrc to avoid it. histappend: If set, the history list is appended to the file named by the value of the HISTFILE variable when the shell exits, rather than overwriting the file. == https://bugzilla.redhat.com/819129 == add MANPAGER=most to /etc/profile and "most" should be in the base install or the "less" trick: https://wiki.archlinux.org/index.php/Man_Page#Colored_man_pages -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
On Wed, 13 Jun 2012 11:12:18 +0200, Xavier Bachelot wrote: > I was able to fix the same multilib issue with the html files by modifying > the footer to not include the timestamp, Could you suggest how in: popt-devel.i586 conflicts with popt-devel.x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=533829 > or even don't generate the pdf file at all, but I'd rather fix the issue in > a different way. It would be nice to standardize what formats of doc are shipped, I tried it in [Fedora-packaging] HTML format preferred over INFO documents http://lists.fedoraproject.org/pipermail/packaging/2011-February/007634.html https://fedoraproject.org/wiki/PackagingDrafts/HtmlDocs But it did not get accepted. Currently gdb-doc ships info + html + pdf. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Important kernel update should not break stuff
Hi folks, Today something happened, that happens over and over again with Fedora, and it makes me angry. I am running Fedora 17, and so far it worked well with the initial kernel 3.3.x (except that it would panic on shutdown... but that was not important to me, but still embarassing). Today I was notified of an important security update in the kernel. Curiously, it would update from 3.3 to 3.4 (a major version upgrade, which should not happen in such a core package anyway, IMO). Reboot into the new kernel, everything comes up --- until I want to actually want to read email, surf web, or anything that requires my network. I am on an Intel Wifi card, iwlwifi module. I *can* connect to the network, but everything is suuper slow or times-out every now and then. Completely unusable. Reboot into the older kernel, things work well again. Now I am left with the choice of running a new kernel w/o network or an unsecure kernel. Thank you very much! This sort of thing I would expect in rawhide/development builds, but not in a supposed-to-be stable release. I can understand the underlying idea of being on the bleeding edge, but I don't want to actually be bleeding. At least the base system components should not undergo major version updates. Security fixes should be backported to the software version that is in the stable release (1 year release cycle shouldn't be too demanding for this), and only security fixes and absolutely important fixes should go into stable releases. (Not to mention that some fixes that I *would* consider important enough to go into stable never end up there.) If major version updates are really really necessary, they should undergo serious testing. I cannot believe that I am the only one on an Intel Wifi chip. The way it is now, Fedora feels like a constantly rolling development version that is almost unusable (because any update, even security, has a fairly high risk of breaking things) for day-to-day work. Bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=831571 Best regards, Roman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weekly ARM status meeting - Wed 2012/06/13
Paul Whalen wrote: > CST: 10pm FYI, we normally call this time zone CEST, not CST. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
multilib conflict with doxygen generated pdf
Hi, Does anyone have any pointer on how to fix a multilib conflict with a doxygen generated pdf file ? I was able to fix the same multilib issue with the html files by modifying the footer to not include the timestamp, but I don't find any pointer on how to proceed for the pdf file. Alternatively, I can probably put the doc files in a noarch -doc subpackage, or even don't generate the pdf file at all, but I'd rather fix the issue in a different way. Regards, Xavier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/12/2012 07:43 PM, Bill Nottingham wrote: Jay Sulzberger (j...@panix.com) said: There is here no irrestible tide. Rather, Fedora is jumping to surrender before engagement. Secret discussions with Microsoft is perhaps part of this engagement. But such discussion is not the whole battle. Fedora should call a conference to organize fighting back, rather than attempting to defend on this list the serious tactical error which Fedora is about to commit. No offense, but you seem to have a very unusual idea about how much leverage Fedora has anywhere. None ... Linux and the spirit of freedom behind it matters. Why would hardware vendors listen to a community distribution that they never preinstall, have no plans to preinstall, and brings them absolutely no money? ... think Adaptec... ca. 15-20 years ago. I am inclined to believe, the spirit behind Linux has changed, changed away from being idealistic to playing issues low for commerial interests. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
buildsys-build group renamed to build?
Hello, Can a comps maintainer confirm that yum group used for installing minimal build-root in F18 has been renamed from `buildsys-build' to `build'? I just started getting failures in my local mock configurations today because regarding this group name. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
