Re: MySQL and MariaDB in Fedora
Il 15/04/2013 08:19, "Jóhann B. Guðmundsson" ha scritto: On 04/14/2013 07:10 PM, Matthias Runge wrote: On 04/14/2013 06:54 PM, "Jóhann B. Guðmundsson" wrote: Convincing this is about doing the right thing! I your intention was to ban mysql in the distribution then it should have been banned and dropped instead of this mess that you guys have created. IMHO you cannot ban/deprecate a package from the distro, if there's still a packager/contributor to the package. Also you can not force somebody to drop a package. I'm aware of that but we can force migration upon users on upgrades while we still provide and ship that component? If users have *chosen* to install component A and we *still* provide ( maintain,package and ship ) component A, the users should be upgraded to that components latest release upon upgrade. If users have *chosen* to install component A and we *no longer* provide ( maintain,package and ship ) component A then the argument can be made that we should "migrate" component A to component B during release upgrades if it provides same or similar functionality ( even thou I feel it's bad policy doing so and we would be better of doing nothing as in simply not upgrade or migrate that component unless it becomes absolutely necessary ) JBG +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
On 04/14/2013 07:10 PM, Matthias Runge wrote: On 04/14/2013 06:54 PM, "Jóhann B. Guðmundsson" wrote: Convincing this is about doing the right thing! I your intention was to ban mysql in the distribution then it should have been banned and dropped instead of this mess that you guys have created. IMHO you cannot ban/deprecate a package from the distro, if there's still a packager/contributor to the package. Also you can not force somebody to drop a package. I'm aware of that but we can force migration upon users on upgrades while we still provide and ship that component? If users have *chosen* to install component A and we *still* provide ( maintain,package and ship ) component A, the users should be upgraded to that components latest release upon upgrade. If users have *chosen* to install component A and we *no longer* provide ( maintain,package and ship ) component A then the argument can be made that we should "migrate" component A to component B during release upgrades if it provides same or similar functionality ( even thou I feel it's bad policy doing so and we would be better of doing nothing as in simply not upgrade or migrate that component unless it becomes absolutely necessary ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-04-15 @ 16:00 UTC - F19 Alpha Blocker Bug Review #7
# F19 Alpha Blocker Review meeting #7 # Date: 2013-04-15 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Again, we'll be having a blocker review meeting to follow up the QA meeting on Monday. Only a few bugs to look at, should be a quick one. We'll be running through the alpha blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the Alpha release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-04-15 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-04-15 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again today/tomorrow! Once again, F19 Alpha is the main topic: unfortunately we missed last week, but things look good for this week. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130415 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Fedora 19 Alpha status 2. Test Days 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does _hardened_build use "-z, relro" and not "-z, relro, -z, now" ?
On Fri, 12 Apr 2013, Tomas Mraz wrote: Huh? As far as I can see _hardened_build adds -z now, not relro. -Wl,-z,relro is supposed to be included in LDFLAGS. Or has this changed recently? Let me rephrase... Why is _hardened_build not using "-z,relro,-z,now" ? Because -Wl,-z,relro is supposed to be included in the default LDFLAGS for all packages already. Ahh, I see. Some of my packages lost that due to non-default handling of those options. It all makes sense now, thanks. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
Hi On Sun, Apr 14, 2013 at 7:08 PM, Dan Mashal wrote: > I think you misunderstand. > > 2 things: > > 1) I want to be able to login and click "My packages" and see all my > packages. > > 2) I want to be able to change acls without having to go back to > pkgdb. In fact, this might take exporting the pkdgb database and > putting it in to the same or seperate database Moksha uses. > > Don't get me wrong, I love this application but it needs work to fully > replace pkgdb.. unless that wasn't the intended purpose in the first > place.. in which case that would be unfortunate. > There is no misunderstanding. What you want is outside of the scope of the web application currently since it doesnt intend to replace pkgdb. It was within the scope of the "Fedora community" app but that became too complex and slow so the team has come up with this new targeted approach. Maybe they can extend the scope again but one step a time. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
Hi On Sun, Apr 14, 2013 at 7:31 PM, Kevin Kofler wrote: > Matthias Runge wrote: > > IMHO you cannot ban/deprecate a package from the distro, if there's > > still a packager/contributor to the package. Also you can not force > > somebody to drop a package. > > FESCo has done that even to a whole group of packages: > (separately-packaged) > kernel modules! It would make much more sense to do that here than there. > Kevin, You aren't going to convince anyone by repeating yourself constantly. Kindly stop. Thanks Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
Matthias Runge wrote: > IMHO you cannot ban/deprecate a package from the distro, if there's > still a packager/contributor to the package. Also you can not force > somebody to drop a package. FESCo has done that even to a whole group of packages: (separately-packaged) kernel modules! It would make much more sense to do that here than there. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sun, Apr 14, 2013 at 3:53 PM, Rahul Sundaram wrote: > Hi > > > On Sun, Apr 14, 2013 at 6:28 PM, Dan Mashal wrote: >> >> >> It returns you to pkgdb to set acls and the relationships tab gives an >> error. I was mainly looking at it to manage permissions (right now). >> >> And when I meant functional I meant FULLY functional, meaning I >> wouldn't have to touch pkdgb ever again. > > > It is functional for the purpose of searching packages which was the > original topic of the conversation. I have replaced the pkgdb link with a > reference to this new UI to avoid any confusion. > > Rahul > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel I think you misunderstand. 2 things: 1) I want to be able to login and click "My packages" and see all my packages. 2) I want to be able to change acls without having to go back to pkgdb. In fact, this might take exporting the pkdgb database and putting it in to the same or seperate database Moksha uses. Don't get me wrong, I love this application but it needs work to fully replace pkgdb.. unless that wasn't the intended purpose in the first place.. in which case that would be unfortunate. dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
Hi On Sun, Apr 14, 2013 at 6:28 PM, Dan Mashal wrote: > > It returns you to pkgdb to set acls and the relationships tab gives an > error. I was mainly looking at it to manage permissions (right now). > > And when I meant functional I meant FULLY functional, meaning I > wouldn't have to touch pkdgb ever again. > It is functional for the purpose of searching packages which was the original topic of the conversation. I have replaced the pkgdb link with a reference to this new UI to avoid any confusion. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sun, Apr 14, 2013 at 5:16 AM, Rex Dieter wrote: > Dan Mashal wrote: > >> On Sun, Apr 14, 2013 at 2:57 AM, Pierre-Yves Chibon >> wrote: > >>> Blahblahblahb >>> http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html > >> Let me know when it's functional. > > Like now. > > (at least https://apps.fedoraproject.org/packages/ was when I tried just > now) > > -- rex > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). And when I meant functional I meant FULLY functional, meaning I wouldn't have to touch pkdgb ever again. Other than that it IS beautiful and fast. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request for golang
Hi, I have a review request for the "golang" package, which obsoletes the old stale "go" package request. This package compliments the existing gccgo implementation already in Fedora. Someone interested in having the go-based go toolchain in Fedora should review it! https://bugzilla.redhat.com/show_bug.cgi?id=950281 Thanks, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
On 04/14/2013 06:54 PM, "Jóhann B. Guðmundsson" wrote: > > Convincing this is about doing the right thing! > > I your intention was to ban mysql in the distribution then it should > have been banned and dropped instead of this mess that you guys have > created. IMHO you cannot ban/deprecate a package from the distro, if there's still a packager/contributor to the package. Also you can not force somebody to drop a package. -- Matthias Runge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
On Apr 13, 2013, at 18:37, Kevin Kofler wrote: > Nico Kadel-Garcia wrote: >> For seriously lightweight window managers, I've been using "vtwm" for >> years, still published by the Penguin Liberation Front and listed at >> http://rpm.pbone.net/index.php3/stat/4/idpl/13029794/dir/mandriva_2010/com/vtwm-5.4.7-1plf.i586.rpm.html. > > Be warned that PLF packages are NOT intended for Fedora. Completely true: they often require some editing of dependency names for Fedora and RHEL. > >> The Penguin Liberation Front has been a very useful resource, for years, >> of components whose licenses are confusing or problematic: the old "xv" >> and "twm" programs, "libdvdcss" for ripping DVD's, MPEG libraries, and >> Pine and daemontools before they had their licensing revised. I understand >> why those components can't always be included in a completely open >> distribution with US based resources and primary maintainers like Fedora. >> But man, they're useful if you can accept the licensing personally or >> you're in a country with sane laws about DRM. > > For Fedora, there is RPM Fusion which provides such packages (and a separate > repository for libdvdcss at rpm.livna.org). > >Kevin Kofler Unfortunately, rpm.livna.org spends its whole front page saying it's all at RPMfusion, except one package which they *very, very, carefully* do not name or even list an actual directory URL to review. A bit of digging shows that the correct URL to see the *content* is http://rpm.livna.org/repo/, and you're right, it's libdvdcss. I'm glad it's available. The DRM craziness around that package is insane, and I'm glad when I can do the work in a country that does not have such onerous restrictions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Alpha Test Compose 6 (TC6) Available Now!
Maybe your hitting this: https://bugzilla.redhat.com/show_bug.cgi?id=950653 /Andreas 2013/4/14 Rahul Sundaram > Hi > > > On Sat, Apr 13, 2013 at 8:44 PM, Phil Dobbin wrote: > >> >> >> [snip for brevity] >> >> Live DVD boots as far as black screen after progress bars & no further >> with no output whatsoever running on KVM on Fedora 17 on a Lenovo >> ThinkCentre MT-8808. >> > > Do check bugzilla and file a bug report. Mark is at blocker if necssary > > Rahul > > -- > 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: New package group request
14.04.2013 19:09, Kevin Kofler: Bill Nottingham wrote: Note that most of the desktop environments already have specific groups for apps native to or curated for those environments. This would be the group for the Razor-Qt desktop environment, but first we should get that packaged in Fedora. 1. RazorQt is in queue - right after last qt-app (qxkb) will be reviewed. 2. There are some (many) problems with licensing. But... I'll start packaging tomorrow. 3. RazorQt has no _direct_ relation to other qt apps - as KDE or Gnome with their DE-wide "services" (like kio/gnome-vfs, DnD etc). Maybe (in future) it will (e.g. system-wide qt icon theme, VFS, DnD) - but this need patching qt. I agree that having a group of Qt-only apps without a matching workspace is not very helpful. FWIW, some of those apps might actually be interesting in the KDE group, but most of the stuff I've seen going through review so far only duplicates existing KDE apps (but using only Qt unlike the KDE equivalent), so the KDE group is the wrong place to put them. Qt applications not depends on kdelibs. And now there is no easy way to choose application set without kdelibs and gtk. But - yes, I agree that my arguments are not enough to create top-level package group. Qt environment is not all-sufficient yet. And will not in nearest future :-( -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
On 04/14/2013 03:11 PM, Tom Lane wrote: Kevin Kofler writes: Jóhann B. Guðmundsson wrote: If I installed mysql and have been running mysql then upgrade I expect the upgrade process to pick up the latest mysql we ship upgraded to that and I will be continuing to run mysql not be magically moved to fork of it mariadb. Sorry, but the point of the MariaDB feature is that MariaDB will be the default for everyone. Just like how LibreOffice replaced OpenOffice.org, Calligra replaced KOffice, X.Org X11 replaced XFree86 etc. It's worth pointing out here that the Oracle folk are intent on pushing that package to mysql 5.6 ASAP. (Honza and I have been recommending to them that they wait till the F20 timeframe, just to reduce the amount of change happening in F19, but in any case it's coming pretty darn soon.) At that point mariadb 5.5 will actually be the lesser-change option for people currently using mysql 5.5. So I don't find Jóhann's argument terribly convincing. There is no no-change update path on the table, and the path that we are making the default requires less change than the other one. So that seems to me to be the right thing; arguments based on the name of the package are pretty off-topic. Convincing this is about doing the right thing! I your intention was to ban mysql in the distribution then it should have been banned and dropped instead of this mess that you guys have created. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Alpha Test Compose 6 (TC6) Available Now!
Hi On Sat, Apr 13, 2013 at 8:44 PM, Phil Dobbin wrote: > > > [snip for brevity] > > Live DVD boots as far as black screen after progress bars & no further > with no output whatsoever running on KVM on Fedora 17 on a Lenovo > ThinkCentre MT-8808. > Do check bugzilla and file a bug report. Mark is at blocker if necssary Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [F18][ATI Rage XL] Problems with install on ATI Rage XP video driver
I have put in two bugzilla entries :- https://bugzilla.redhat.com/show_bug.cgi?id=951643 https://bugzilla.redhat.com/show_bug.cgi?id=951648 On for F18 and another for F19-Live as they seem to be different results. Aaron On 5 April 2013 12:58, Aaron Gray wrote: > Yeah I am getting the same messed up graphics results for F19 Alpha Live > Spin on both monitors. Better than with F18 which would only work using > VESA. > > BTW The Samsung has the following modes :- > >- IBM, 640 x 480 >- VESA, 800 x 600 >- VESA, 800 x 600 >- VESA, 1024 x 768 >- VESA, 1280 X 960 >- VESA, 1280 X 1024 >- VESA, 1600 X 1200 >- VESA, 1920 X 1200 > > > > > On 5 April 2013 12:41, Aaron Gray wrote: > >> On 5 April 2013 06:59, Felix Miata wrote: >> >>> On 2013-04-05 01:38 (GMT-0400) Aaron Gray composed: >>> >>> >>> Its quite strange. >>> >>> The Samsung monitor is 1920 x 1200 >>> >>> What other modes does it support? >> >> >> Quite a range AFAICT. >> >> This problem on F18 arose using a smaller 1280 by 1024 monitor, which is >> now giving the same results. >> >> --- >> Aaron >> > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Sun, 14 Apr 2013 12:59:06 +0200 Reindl Harald wrote: > if someone aks for a monthly patchday for Fedora > instead push updates after bugs are fixed who is > kidding there? I don't think anyone actually was asking for that. The proposal around monthly update packs includes the idea that people who want to use the current flow of updates process can continue to do so just fine. It's an additional setup for people who do not want a constant flow of updates. In any case it's not formally been proposed yet that I know of, so it's kind of silly to speculate about a plan the full details of which aren't available. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Am 14.04.2013 12:51, schrieb Dan Mashal: > On Wed, Apr 10, 2013 at 5:24 PM, Reindl Harald wrote: >> but Fedora IS NOT RHEL >> if you want the RHEL way use it >> > > WHO ARE YOU KIDDING? ?? if someone aks for a monthly patchday for Fedora instead push updates after bugs are fixed who is kidding there? who the hell needs this? if you do not want updates - FINE do not install them why do someone need handholding by such simple decisions? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
Kevin Kofler writes: > Jóhann B. Guðmundsson wrote: >> If I installed mysql and have been running mysql then upgrade I expect >> the upgrade process to pick up the latest mysql we ship upgraded to that >> and I will be continuing to run mysql not be magically moved to fork of >> it mariadb. > Sorry, but the point of the MariaDB feature is that MariaDB will be the > default for everyone. Just like how LibreOffice replaced OpenOffice.org, > Calligra replaced KOffice, X.Org X11 replaced XFree86 etc. It's worth pointing out here that the Oracle folk are intent on pushing that package to mysql 5.6 ASAP. (Honza and I have been recommending to them that they wait till the F20 timeframe, just to reduce the amount of change happening in F19, but in any case it's coming pretty darn soon.) At that point mariadb 5.5 will actually be the lesser-change option for people currently using mysql 5.5. So I don't find Jóhann's argument terribly convincing. There is no no-change update path on the table, and the path that we are making the default requires less change than the other one. So that seems to me to be the right thing; arguments based on the name of the package are pretty off-topic. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New package group request
Bill Nottingham wrote: > Note that most of the desktop environments already have specific groups > for apps native to or curated for those environments. This would be the group for the Razor-Qt desktop environment, but first we should get that packaged in Fedora. I agree that having a group of Qt-only apps without a matching workspace is not very helpful. FWIW, some of those apps might actually be interesting in the KDE group, but most of the stuff I've seen going through review so far only duplicates existing KDE apps (but using only Qt unlike the KDE equivalent), so the KDE group is the wrong place to put them. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Richard Hughes wrote: > Not true for the majority of GNOME and KDE packages. You can't test > gnome-control-center 3.9.1 without installing gnome-settings-daemon > 3.9.1 as well. Not because of any library interface issue, but because > g-s-d provides the D-Bus API used by g-c-c. The desktop, like it or > not, is getting more monolithic, not less. FWIW, that's a totally good > thing. Speaking of KDE because that's what I'm familiar with: * The KDE version upgrades are already being pushed as groups. All the 4.10.2 packages are in a single update in Bodhi. That makes a lot of sense because upstream releases them together at the same time. So doing monthly batching in Fedora will only mean we'll be out of sync with upstream, it would not provide any grouping that is not already being done. * In KDE land, you can actually use old kde* on new kdelibs (at least you should be able to; it's not really tested or supported for the core KDE packages because they are updated at the same time as kdelibs and thus expected to be used together), but not new kde* on old kdelibs. So it would be possible to test the updated packages separately in reverse dependency order. It's just neither practical (time-wise) nor necessary. The monthly grouping is already done by upstream there. * KDE is getting less monolithic, not more. KDE Frameworks 5 will even be taking the splitting to extreme levels. Basically, where upstream releases a large set of version updates simultaneously (e.g. KDE coordinated releases), we are already pushing them as one group and downstream batching would bring no benefits whatsoever, whereas for small leaf packages (e.g. colord-kde), the updates can easily be tested in isolation (even much better than when mixed with a huge batch of mostly unrelated changes; if, say, a batch of colord + kdelibs + colord-kde breaks colord-kde, how do we know which updated package broke it?). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
Jóhann B. Guðmundsson wrote: > It goes without saying that users should never be automatically moved > from component A to component B if component A is still being provided, > maintained and shipped in the distribution. Which is why IMHO MySQL should not be provided anymore at all. > If I installed mysql and have been running mysql then upgrade I expect > the upgrade process to pick up the latest mysql we ship upgraded to that > and I will be continuing to run mysql not be magically moved to fork of > it mariadb. Sorry, but the point of the MariaDB feature is that MariaDB will be the default for everyone. Just like how LibreOffice replaced OpenOffice.org, Calligra replaced KOffice, X.Org X11 replaced XFree86 etc. There are 2 possible upgrade paths for the same old software, which one we pick should be the decision of the package maintainer. Which project still carries the original name should be irrelevant. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
Steve Grubb wrote: > On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote: >> But it prevents (with probability (256^n-1)/256^n, where n is the size of >> the canary in bytes, which for n=4 is approximately .976717) >> exploiting the overflows to change the return address of any C function. > > There is the off chance that an attacker correctly guesses the canary > value. > :-) That's exactly why I wrote that it works with probability .976717 (assuming a 32-bit canary), not 1. :-) Of course, the larger you make the canary, the closer to 0 the probability of guessing it will be. And of course, talking about probabilities only makes sense if the way the canary gets generated can be reasonably considered random and uniformly distributed. > One thing that I found in doing a recent study was that there is a build > system, scons, where our defaults are not getting used during compile. For > example, the zfs-fuse package uses the scons build system. It did not have > PIE, RELRO, stack protector, or FORTIFY_SOURCE anywhere. Anything else > that uses scons should be inspected for similar problems. Yes, you need to use something like this: http://pkgs.fedoraproject.org/cgit/mingw-nsis.git/tree/nsis-2.43-rpm-opt.patch and RPM_LD_FLAGS should also be handled (it currently isn't in that patch). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: %doc path
On Sun, Apr 14, 2013 at 2:25 PM, Eugene Pivnev wrote:
> Sorry for stupid question - help me to find something like "doc must be in
> %{_docdir}/%{name}-%{version}/ but not in %{_docdir}/%{name}/" in
> guidelines.
> Or there is no such limit?
http://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
There is no such requirement in there.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
%doc path
Sorry for stupid question - help me to find something like "doc must be
in %{_docdir}/%{name}-%{version}/ but not in %{_docdir}/%{name}/" in
guidelines.
Or there is no such limit?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
Dan Mashal wrote: > On Sun, Apr 14, 2013 at 2:57 AM, Pierre-Yves Chibon > wrote: >> Blahblahblahb >> http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html > Let me know when it's functional. Like now. (at least https://apps.fedoraproject.org/packages/ was when I tried just now) -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130414 changes
Compose started at Sun Apr 14 09:16:31 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) >= 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [denemo] denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eruby] eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) >= 0:1.9.0 eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9 eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) >= 0:1.9.0 eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) [fawkes] fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0) fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8 fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8(LIBJPEG_8.0)(64bit) fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit) fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gearbox] gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [gorm] gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22 gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit) [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i68
Re: MySQL and MariaDB in Fedora
On 04/13/2013 09:42 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Users should not be switched automatically to Mariadb on upgrades Of course they should! That's the point of switching! It goes without saying that users should never be automatically moved from component A to component B if component A is still being provided, maintained and shipped in the distribution. If I installed mysql and have been running mysql then upgrade I expect the upgrade process to pick up the latest mysql we ship upgraded to that and I will be continuing to run mysql not be magically moved to fork of it mariadb. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130414 changes
Compose started at Sun Apr 14 08:15:19 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [diet] diet-2.8.1-5.fc19.i686 requires libxqilla.so.5 diet-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit) diet-examples-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eg] eg-1.7.5.2-1.fc20.noarch requires perl(one) eg-1.7.5.2-1.fc20.noarch requires perl(it) eg-1.7.5.2-1.fc20.noarch requires perl(an) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [kde-settings] kde-settings-kdm-19-17.fc20.1.noarch requires /lib/systemd/systemd-multi-seat-x [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [mapserver] php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [mygui] mygui-3.2.0-4.fc20.i686 requir
Re: Keeping old versions of packages
On Wed, Apr 10, 2013 at 5:24 PM, Reindl Harald wrote: > but Fedora IS NOT RHEL > if you want the RHEL way use it > WHO ARE YOU KIDDING? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sun, Apr 14, 2013 at 2:57 AM, Pierre-Yves Chibon wrote: > On Sun, 2013-04-14 at 02:39 -0700, Dan Mashal wrote: >> On Sat, Apr 13, 2013 at 2:52 PM, Kevin Kofler wrote: >> > John5342 wrote: >> >> I think searching applications by default is a stupid idea when that >> >> web app is mostly used by packagers >> > >> > I think it's a stupid idea, period. The default should be to search all >> > packages. >> > >> > Kevin Kofler >> > > >> +1 +1 > > Blahblahblahb > http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html > > Pierre > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Let me know when it's functional. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 13 April 2013 23:09, Kevin Kofler wrote: > Sure you can! It's a basic rule of QA that small isolated changes can be > debugged much better than a huge hodgepodge of many totally unrelated > changes. Not true for the majority of GNOME and KDE packages. You can't test gnome-control-center 3.9.1 without installing gnome-settings-daemon 3.9.1 as well. Not because of any library interface issue, but because g-s-d provides the D-Bus API used by g-c-c. The desktop, like it or not, is getting more monolithic, not less. FWIW, that's a totally good thing. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sun, 2013-04-14 at 02:39 -0700, Dan Mashal wrote: > On Sat, Apr 13, 2013 at 2:52 PM, Kevin Kofler wrote: > > John5342 wrote: > >> I think searching applications by default is a stupid idea when that > >> web app is mostly used by packagers > > > > I think it's a stupid idea, period. The default should be to search all > > packages. > > > > Kevin Kofler > > > +1 +1 Blahblahblahb http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
Le dimanche 14 avril 2013 à 01:43 +0200, Kevin Kofler a écrit : > Richard W.M. Jones wrote: > > This would be excellent, and projects in this area could make a > > significant contribution. I suspect that any general code-to-policy > > translator will hit the Halting Problem, since it seems trivial to > > write a program which would not be possible to translate, but that > > doesn't mean it can't be solved for many useful real world cases. > > That's exactly why SELinux policy is the wrong representation. It duplicates > information of the code without being automatically transformable either > way, requiring every change to be made twice. If a software say he can open any arbitrary files on the filesystem doesn't mean it should. The code is most of the time not adequate to explain the permission really needed, that's too low level. And the unix model of user is not really adequate either. You could argue the exact same things about unix permissions "why does apache requires me to modify permission on ~/public_html while I already expressed it can read them in code" or firewall "why should I open the port 80 when i already said in the code of apache that it will use this port". > I repeat: The proper solution is to prevent executing any machine code which > is not part of the program's source code. Block arbitrary-code execution > exploits and SELinux is just dead weight. Repeating doesn't make it right. For example, what do you do for javascript interpreters ? ( like the one we can find in webpages, or in pdf, etc ). Or libreoffice macros. Or php interpeter, whose source code do we take in account, the one of php, the one of apache, the one of the php application, ( unless someone add a plugin of course ) ? The whole point of having it in 2 different places is to have a proper inspection of what it need to do. That's defence in depth. And security bugs have been fixed due to that inspection, like software leaking file descriptors by errors. More over, SELinux do more than "blocking arbitrary code-execution exploit", it also allow to enforce access control to follow security model such as Bell-LaPadula model, it permit to have proper isolation for software like openshift origin, or SVirt. But you are welcome to convince any upstream directly to invest more time in stuff like seccomp-bpf as did by Chrome, vsftpd and others if you think that's the right approach to fix security issues. -- Michael Scherer !DSPAM:516a7a988771503385058! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sat, Apr 13, 2013 at 2:52 PM, Kevin Kofler wrote: > John5342 wrote: >> I think searching applications by default is a stupid idea when that >> web app is mostly used by packagers > > I think it's a stupid idea, period. The default should be to search all > packages. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel +1 +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sat, 06 Apr 2013 20:30:25 +0400 Eugene Pivnev wrote: > I can't find lightd, package in Fedora - If it was lightdm package you were looking for, repeat the test, but click "packages" -- Regards, Frank http//www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
