Fedora 21 updates broke support for 4K displays :(
I have used Fedora 21 with 4k display for almost a year, but few weeks ago some update broke support for 4k display resolution. I'm guessing that intel driver is at fault. Have any of have also noticed this issue with 4k displays on Intel hardware or also on some other hardware? Obligatory link to bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1238101 ps, I have Lenovo T440s with Haswell graphics. Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mpir soname bump
MPIR 2.7.0 has arrived, and brings an soname bump with it. As far as I can tell, nothing in Fedora uses mpir, so I don't think anything needs to be rebuilt. If I'm wrong about that, send me some hate mail and I'll rebuild your package. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ANNOUNCE] kexec-tools 2.0.10
On 07/01/15 at 09:08am, Peter Robinson wrote: > On Wed, Jul 1, 2015 at 1:36 AM, Dave Young wrote: > > Pratyush, > > > > Thanks for the effort, let's cc Fedora devel list, see if we can get help > > from Fedora experts. > > > > Summary the problem: > > Latest kexec-tools koji build in rawhide results in a wrong kexec binary, > > kexec load fails with something like below: > > R_X86_64_29 > > Unhandled rela relocation: R_X86_64_29 > > > > This kinds of errors usually caused by gcc unnecesarrily add options like > > -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which > > runs in kernel mode. > > > > I filed a bug below: > > https://bugzilla.redhat.com/show_bug.cgi?id=1236456 > > > > Appreciate for any hints how to fix the problem. > > I commented on the BZ > Peter, thank you. Resolved with your suggestion. Thanks Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Pre-nonresponsive maintainer request
On Qua, 2015-07-01 at 21:46 -0500, Richard Shaw wrote: > On Wed, Jul 1, 2015 at 9:44 PM, Sérgio Basto > wrote: > > > yeap , Xavier is the infrastructure maintainer of RPMFusion , > you find > him in irc:#rpmfusion-admin with Nick: SmootherFrOgZ . > But we must insist a bit and wait a lot :) > > > It sounds like it's not a priority for him, it may be better to give > it to someone who will more actively maintain it. Not that I'm > volunteering :) I've got more than enough at the moment. I agree , ask him that, please , he gave me commit permissions on packages gammu and wammu a while ago ... > Thanks, > Richard > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Pre-nonresponsive maintainer request
On Wed, Jul 1, 2015 at 9:44 PM, Sérgio Basto wrote: > > yeap , Xavier is the infrastructure maintainer of RPMFusion , you find > him in irc:#rpmfusion-admin with Nick: SmootherFrOgZ . > But we must insist a bit and wait a lot :) It sounds like it's not a priority for him, it may be better to give it to someone who will more actively maintain it. Not that I'm volunteering :) I've got more than enough at the moment. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Pre-nonresponsive maintainer request
On Qua, 2015-07-01 at 21:33 -0500, Richard Shaw wrote: > I haven't gone through all the requirements but it seems pretty clear > that brasero is unmaintained. > > > There are 15 open bugs and looking through the package changelog I > can't find the last time it was updated by it's maintainer, Xavier > Lamien . > > > There is also an unanswered admin request in pkgdb. > > > Has anyone heard from Xavier? yeap , Xavier is the infrastructure maintainer of RPMFusion , you find him in irc:#rpmfusion-admin with Nick: SmootherFrOgZ . But we must insist a bit and wait a lot :) > > Thanks, > Richard > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Pre-nonresponsive maintainer request
I haven't gone through all the requirements but it seems pretty clear that brasero is unmaintained. There are 15 open bugs and looking through the package changelog I can't find the last time it was updated by it's maintainer, Xavier Lamien < lxt...@gmail.com>. There is also an unanswered admin request in pkgdb. Has anyone heard from Xavier? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 02:13 schrieb Michael Catanzaro: On Thu, 2015-07-02 at 00:44 +0200, Reindl Harald wrote: the more important question: who do gnome developers think they are to make such decisions? Hi Reindl, If you know enough about TLS to decide whether to click the Load Anyway button in your browser on a particular site, or enough about DNSSEC to know whether you want to disable validation, then congratulations: you are the 1%. That's great, but we are building an operating system that needs to be safe to use for the 99%. An operating system that requires users to make confusing security-related decisions is not safe to use. Constructing such an operating system is not ethical. oh and because i know enough you will make it impossible for me too instead describe the implications and in the best case lead users to a wiki page so that there will be more users knowing about in the future? If you know what a session cookie is, that clicking the Load Anyway button in your browser leaks it to attackers, and why that matters, then you are the privileged minority, and our software is not designed for you alone. Our free software will respect users -- the entire user population, not just the 1% -- or it will be bullshit [1]. I don't expect you to agree with me on this, but there you have it. :) i am the the privileged minority because i come before developers treated their users like idiots - if i would start these days working with computers i likely would not have the chance to become interested due the "hide anything attitude" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: > Principles are good and well. But how many times did you actually USE > that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays. Last time I found a broken site that I wanted to visit, I complained about it on my blog [1], and it got fixed. Actually, there was another time recently: I was planning to use the Bugzilla instance of a certain highly popular third-party distributor of software for Fedora, at the request of one of the developers, but it was broken (I think it used a worthless cacert), so I went on with my life instead. [1] https://blogs.gnome.org/mcatanzaro/2015/01/30/mozilla-is -responsible-for-the-redhat-corpmerchandise-com-fiasco/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, 2015-07-02 at 00:44 +0200, Reindl Harald wrote: > the more important question: who do gnome developers think they are > to > make such decisions? Hi Reindl, If you know enough about TLS to decide whether to click the Load Anyway button in your browser on a particular site, or enough about DNSSEC to know whether you want to disable validation, then congratulations: you are the 1%. That's great, but we are building an operating system that needs to be safe to use for the 99%. An operating system that requires users to make confusing security-related decisions is not safe to use. Constructing such an operating system is not ethical. If you know what a session cookie is, that clicking the Load Anyway button in your browser leaks it to attackers, and why that matters, then you are the privileged minority, and our software is not designed for you alone. Our free software will respect users -- the entire user population, not just the 1% -- or it will be bullshit [1]. I don't expect you to agree with me on this, but there you have it. :) Michael [1] http://mjg59.dreamwidth.org/32686.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 1 Jul 2015, Michael Catanzaro wrote: Date: Wed, 1 Jul 2015 19:26:55 From: Michael Catanzaro To: devel@lists.fedoraproject.org Subject: Re: dnssec-trigger + GNOME + NetworkManager integration On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: That's the same as saying remove the "continue anyway" frmo the browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise it. I guess I prefer a "continue anyway" with brief non-techniacl text, but beggars can't be choosers. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Wed, 2015-07-01 at 18:40 -0400, Paul Wouters wrote: > That's the same as saying remove the "continue anyway" frmo the > browser. Yeah, I want to do that too; actually I added it to Epiphany myself, not because it's a good idea, but because I know we'll be in for complaints otherwise, because Firefox and Chrome let you continue and we have to be just like them Basically all browser vendors agree that the Continue Anyway button was a huge mistake, but everyone is afraid to remove it for fear users will switch to a competing browser, so it's here to stay I'm afraid Anyway, if you think it's absolutely essential to have an opt-out, I guess we could have one buried in the network panel. But we don't want to advertise it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 30 Jun 2015, Bastien Nocera wrote: Once DNSSEC is more widely deployed What is "more widely deployed" ? http://www.internetsociety.org/deploy360/wp-content/uploads/2013/04/2015-06-19-2015-06-19.png There are 991 zones in the root and 814 are signed and securely delegated. http://stats.labs.apnic.net/dnssec In North America and Europe, validation is about 20%. Overal in the world it is 12% It's really long overdue for us to make this the default and secure our users. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 00:40 schrieb Paul Wouters: On Tue, 30 Jun 2015, Michael Catanzaro wrote: What we basically do not want is to give the user an option for turning a security feature off. That's the same as saying remove the "continue anyway" frmo the browser. Only the human can determine if it is more important to be online insecurely or offline securely. At least we can hope when they click insecure that they won't go login to their banking site :P the more important question: who do gnome developers think they are to make such decisions? if someone wants the apple "we know what you have to do" way he can go out and by a apple machine - the reason for using a linux system is *exactly* the opposite signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Tue, 30 Jun 2015, Michael Catanzaro wrote: I'm confused on one point: why would the user ever want to turn off DNSSEC validation (except to get past a for captive portal)? It sounds like you have no shortage of safeguards in place to make sure this always works: for it to break the user would have to be on a network that doesn't support DNSSEC, that blocks VPN, with the Fedora infrastructure down, right? I think it's OK to fail connections in that case (provided we have a story for captive portals). As a frequent traveler, I do have at times needed to go 'insecure' because VPN was blocked and DNS transparently redirected to a very broken server. In fact, right now this is happening to me, where all A records have no RRSIG and the entire root server list is stuffed in the additional section :P What we basically do not want is to give the user an option for turning a security feature off. That's the same as saying remove the "continue anyway" frmo the browser. Only the human can determine if it is more important to be online insecurely or offline securely. At least we can hope when they click insecure that they won't go login to their banking site :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 Self Contained Change: io.js Technology Preview
On Wed, 2015-06-24 at 13:53 -0700, T.C. Hollingsworth wrote: > On Wed, Jun 24, 2015 at 12:56 PM, T.C. Hollingsworth > wrote: > > On Wed, Jun 24, 2015 at 1:21 AM, Peter Robinson < > > pbrobin...@gmail.com> wrote: > > > Why are we even bothering with this when io.js is merging back > > > into > > > node.js so from what I can see is that io.js won't really be > > > around > > > for much longer > > > > That's exactly why we're bothering with it. Everything in it will > > be > > in the nodejs package someday. Why not get ready now? > > For the benefit of those not reading the other thread, I might add > that io.js also adds support for the PowerPC architecture. That will > make it the only provider of /usr/bin/node on that platform. > So this was discussed at today's FESCo meeting[1]. Basically, we're not sure that it makes sense to have both interpreters in the distribution, particularly since they are merging back together in the future. Would you be willing to consider just packaging io.js *as* node.js in Fedora 23? Among other things, this would avoid the need to go through additional package reviews, rebuild nodejs-* packages to work with io.js, etc. My limited understanding of io.js is that it is essentially a superset of node.js functionality, so it seems like just moving to this instead of node.js 0.12.0 would make sense. Otherwise, will this Change require building NPM packages for iojs - rather than (or in addition to) nodejs-module? Can this be avoided by running them with an alternatives-provided /usr/bin/node? [1] http://meetbot.fedoraproject.org/fedora-meeting/2015-07 -01/fesco.2015-07-01-18.01.html signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2015-07-02 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-07-02 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-07-02 09:00 Thu US/Pacific PDT 2015-07-02 12:00 Thu US/Eastern EDT 2015-07-02 16:00 Thu UTC <- 2015-07-02 17:00 Thu Europe/London BST 2015-07-02 18:00 Thu Europe/Paris CEST 2015-07-02 18:00 Thu Europe/Berlin CEST 2015-07-02 21:30 Thu Asia/Calcutta IST --new day-- 2015-07-03 00:00 Fri Asia/Singapore SGT 2015-07-03 00:00 Fri Asia/Hong_Kong HKT 2015-07-03 01:00 Fri Asia/Tokyo JST 2015-07-03 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 = New business = #topic #547 SourceURL addition/clarification - Git Hosting Services .fpc 547 https://fedorahosted.org/fpc/ticket/547 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
API change + soname bump of libvirt-sandbox 0.6.0
The new libvirt-sandbox release 0.6.0 pushed to rawhide has a minor API change and corresponding soname bump of the library. I'll likely push this update to stable branches too, as it fixes a number of problems and I think its unlikely there are downstream apps linking to its library beyond the in-house virt-sandbox cli tool itself. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Driver 'mmcblk' needs updating - please use bus_type methods
Il giorno mar, 30/06/2015 alle 06.13 -0400, Bastien Nocera ha scritto: > It doesn't need updating, the error you're seeing is: > "DMA: Out of SW-IOMMU space for 65536 bytes at device :09:00.1" > > Which I reported upstream here: > http://thread.gmane.org/gmane.linux.kernel.mmc/32629 > but which didn't get any answers. > > You can test the work-around there though. Thanks Bastien, where I can find the "work around" for test it? > Cheers -- Dario Lesca (inviato dal mio Linux Fedora 22 con Gnome 3.16) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository
Kamil Paral a écrit:
>> Then, when the package N-udpate-V-R is later submitted to Bodhi, the
>> update creation process would query ResultDB for the result of the
>> relevant ABI check that happened at build time. The decision to allow
>> an automatic push of the update to stable will depend on the result of
>> that query.
>
> This feature might take some longer time. Until that is in place, the
> results will be visible in ResultsDB for anyone interested in looking
> at them, and hopefully we will start sending out fedmsg in the near
> future, so you can listen for it as well.
Right.
[...]
>>
>> * Have a Taskotron task that will use all of the above to
>> perform the ABI comparison and store the result in
>> ResultDB.
[...]
>> I still need to file a tracking issue for this. I guess I
>> can file it to Phabricator instance of Taskotron and assign
>> it to myself?
>
> Sure, you can use "new-check-ideas" project for that. We'll be happy
> to help.
Thanks.
>
>>
>> * Write a system wide change proposal for this project.
>
> I don't think that is needed until we're able to stop Bodhi from
> pushing an update (for Koji-based checks).
Right. I just meant the change proposal to be a kind of sheet of paper
where we write what needs to be done in one place. It won't be formally
submitted until we are ready -- like what you are suggesting -- of
course. So I have started it at
https://fedoraproject.org/wiki/Changes/CheckUpdatesABIChanges. Feel
free to update it too, if you see the need.
>> So this is where we stand at the moment.
>
> Also, one further request was to be able to retrieve a rule whitelist
> from distgit. A relevant discussion is occurring in the packaging
> mailing list ("Packages without a dist tag" subject).
Right. This was for a refinement further down the road.
Basically, when the first basics checks (checking that public ELF
symbols for exported functions and global variables that are present in
a stable package don't disappear in update packages) are in place, we'll
want to go further and check that the types of exported functions and
variables in update packages mean the same thing as in the initial
stable package.
But then, when you start doing deep comparison of types like that, you
need to support a level of "nuance" in determining if a given ABI change
is harmful or not. For instance, the same kind of ABI change can be
harmful in the context of a given project, and be harmless in another
project. So developers (package maintainers) need a way to provide a
kind of white list (or waiver specification) to say "In this particular
case, this ABI change is OK, thank you", so that the tool stops
considering the change as being harmful. abipkgdiff should support the
same kind waiver specification, formally called "suppression
specification" [1] that "abidiff" supports today.
It's those white list we think package developers might want to store in
distgit, per package, and that the abi checking service will eventually
consume, you are right.
But this is for after we have the basics in place :-)
[1]: Suppression specifications are extensively documented at
https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppression-specifications
Cheers,
--
Dodji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository
Hello, Martin Krizek a écrit: > From what I understood, the current status of the ABI comparison is that it > only > works with C/C++ programs. Right. > Have you given a thought on how do we know that the build under test > includes a C program and so we should run the comparison on it? The comparison program (abipkgdiff) inspects the debug information that is present int the debug info package associated to the current package being built. abipkgdiff should know if it can handle the binary or not. That is, if the binary was generated from C or C++, for instance. > Currently we just listen on fedmsgs that koji sends about completed > builds. So we need something that would tell us "this rpm includes a > program in X language - run Y check on it". This is essentially a > general concern for the future checks that would run on builds that > include programs in a specific language. I think, there is nothing to change in koji or Taskotron for this. The abi checking taskotron task gets triggered on every single RPM that it builds, and abipkgdiff is called on it. Then abipkgdiff decides if it can handle the RPM or not. I hope this helps. Cheers, -- Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150701 changes
Compose started at Wed Jul 1 05:15:04 UTC 2015 Broken deps for i386 -- [airsched] airsched-1.00.0-12.fc23.i686 requires libzmq.so.4 [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [aws] aws-tools-2015-2.fc23.i686 requires libaws_ssl.so [bluetile] bluetile-0.6-28.fc23.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [bustle] bustle-0.4.8-3.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so bustle-0.4.8-3.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) bustle-0.4.8-3.fc23.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [clearsilver] perl-clearsilver-0.10.5-29.fc22.i686 requires perl(:MODULE_COMPAT_5.20.1) perl-clearsilver-0.10.5-29.fc22.i686 requires libperl.so.5.20 [gammaray] gammaray-qt5-2.2.1-10.fc23.i686 requires qt5-qtbase(x86-32) = 0:5.4.2 [ghc-gtk] ghc-gtk-0.13.4-1.fc22.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) ghc-gtk-devel-0.13.4-1.fc22.i686 requires ghc-devel(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [ghc-hgettext] ghc-hgettext-0.1.30-8.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so ghc-hgettext-0.1.30-8.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) ghc-hgettext-devel-0.1.30-8.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so ghc-hgettext-devel-0.1.30-8.fc23.i686 requires ghc-devel(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) ghc-hgettext-devel-0.1.30-8.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) [ghc-hjsmin] ghc-hjsmin-0.1.4.7-7.fc23.i686 requires ghc(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf) ghc-hjsmin-devel-0.1.4.7-7.fc23.i686 requires ghc-devel(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf) [golang-github-samalba-dockerclient] golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/utils) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/timeutils) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/stdcopy) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/jsonlog) [hadoop] hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [julia] julia-0.3.7-2.fc23.i686 requires libspqr.so.1 julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so [klavaro] klavaro-3.01-0.pre1.1.fc23.1.i
Re: Thunderbird-38.0.1 integrates lightning? Very disturbing!!
On 1 July 2015 at 14:02, Ahmad Samir wrote: > On 1 July 2015 at 12:14, Ian Malone wrote: > >> >> It appears to have broken the ability to install the gdata provider, >> at least when I installed a new F22 system at the weekend I found I >> couldn't install it because it requires the lightning package which is >> obsoleted by current thunderbird. >> > > That's a packaging bug; either thunderbird should obsolete _and_ > provide thunderbird-lightning or thunderbird-lightning-gdata should be > changed to require thunderbird instead of -lightning. You should file > a bug so that the issue is tracked/fixed. > Thought that might be the case, but hadn't been able to find out whether the lightning package really had been retired or if it was just one of the metadata caching problems you occasionally run into. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mass bug filing proposal - switching to Python3
Hello everyone,
I would like to start with Mass bug filing process and as stated
at wiki, the first step is to gain consensus for what I want to make.
Note please that this mass bug filing is conditioned with acceptance of
'Python3 as default' change which will be discussed at todays (01-Jul)
meeting. This mass bug filing aims for python applications.
What is python application?
Application foo is not meant to be used within others python libraries via
`import foo`
and both python3 and python2 versions of foo provides same functionality and
therefore
only one version is needed. This also includes scripts. DevAssistant is an
*application*
- We invoke DA and we don't care if it is python2 and python3 based, both will
fulfill
our task.
Bug description proposal follows:
With the recent change in packaging and upcoming system wide
change 'Python3 as default' Fedora is switching from using Python2
interpreter as default to Python3. This means that all applications
accessible through default Fedora repositories running or using Python
should run on/use Python3.
FAQ:
Q: How do I know if my application is using Python?
A: If this bug is filled against your application it is using Python
yet mistakes happen so if your application does not use Python (and you
double checked on that) please close this bug with a comment stating that.
Q: How to switch to Python3?
A: First, make sure that upstream supports Python3. Next switch
all macros to its python3 equivalents[0] and change all shebangs
using python or python2 to use python3, also replace all the dependencies
python2 dependencies. If stuck contact the reporter.
Q: What if upstream doesn't support Python3?
A: Don't switch to python3, open a bug in upstream asking to support Python3,
help upstream with porting to Python3 (optional) and leave the fedora bug
opened
for tracking. Bug should be closed once the Python3 support is added.
[0]https://fedoraproject.org/wiki/Packaging:Python#Macros
Bug description ends.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository
- Original Message - > From: "Dodji Seketeli" > To: "Fedora Devel" > Cc: kpa...@fedoraproject.org, mkri...@fedoraproject.org, > skum...@fedoraproject.org, sgall...@fedoraproject.org, > tfl...@fedoraproject.org > Sent: Thursday, June 25, 2015 10:52:47 AM > Subject: An update about: Checking the ABI of packages submitted to the > updates-testing Fedora repository > > Hello, > > A little update about this project we have been tinkering about. > > First thing first, a tracking ticket has been opened against the > Taskotron project to follow the progress of this effort: > https://phab.qadevel.cloud.fedoraproject.org/T490. > > Just so you remember the big picture, for each stable package named > N-stable-V-R, whenever a new update N-update-V-R is submitted, we want > to compare the binaries (mostly C and C++ libraries) to see if there > has been any harmful ABI change. If there has been any, then the > update will not be pushed *automatically* to the stable repository > when it reaches the karma threshold; rather, it will require a > conscious decision by the maintainer. > > A number of things need to fall into place before we can actually > have a working system. > > After discussing this in the audit trail of the tracking issue and on > IRC, we are now heading toward triggering the ABI checks each time > someone submits a build N-update-V-R to Koji. Whenever the > information of a new build is broadcasted on the fedmsg bus, a > dedicated Taskotron task kicks off and performs the following steps: > > 1/ retrieve the relevant N-stable-V-R package > 2/ retrieve the debug info packages for N-stable-V-R and N-update-V-R > 3/ perform an ABI comparison between N-stable-V-R and N-update-V-R, >using their debug info as necessary input. > 4/ store the result of the comparison in the ResultDB database. > > Then, when the package N-udpate-V-R is later submitted to Bodhi, the > update creation process would query ResultDB for the result of the > relevant ABI check that happened at build time. The decision to allow > an automatic push of the update to stable will depend on the result of > that query. > > For this system to start working, we need a set of things to fall into > place. As noted in the tracking issue that I linked to above, we > need to: > > * Extend koji directive to allow the download of debug info > package. https://phab.qadevel.cloud.fedoraproject.org/T494. > This is done now. > > * Support "latest stable build" with koji > directive. https://phab.qadevel.cloud.fedoraproject.org/T491. > > * Have an abipkdiff tool, from the libabigail project that > would compare binaries embedded in two RPMs and produce a > report. This is tracked by > https://sourceware.org/bugzilla/show_bug.cgi?id=18426. > The tool recently started to work in the branch > ksinny/abipkgtool. We are still working on it, but it can > be used for prototyping already. > > * Have a Taskotron task that will use all of the above to > perform the ABI comparison and store the result in ResultDB. > > Note that in the beginning, we'll perform only a basic kind of > comparison: checking that no public symbols of functions and > variables present in the stable version disappeared in the > update. > > Obviously, the Libabigail tools can perform more sophisticated > comparison involving the full signature of the functions and > variables, including their sub-types. But we think that > should be left for later when the whole system works for the > basic kind of ABI checks first. > > I still need to file a tracking issue for this. I guess I > can file it to Phabricator instance of Taskotron and assign > it to myself? > > * Write a system wide change proposal for this project. > > So this is where we stand at the moment. > From what I understood, the current status of the ABI comparison is that it only works with C/C++ programs. Have you given a thought on how do we know that the build under test includes a C program and so we should run the comparison on it? Currently we just listen on fedmsgs that koji sends about completed builds. So we need something that would tell us "this rpm includes a program in X language - run Y check on it". This is essentially a general concern for the future checks that would run on builds that include programs in a specific language. Thanks! Martin > So if you have any comment, please do not hesitate. And more > importantly, if you feel like you can land us a helping hand, that would > be greatly appreciated because obviously, this is far far far from being > a one person project. I'd like to thank those who stepped up so far: > Tim Flink, Kamil Páral, Martin Krizek, Sinny Kumari and Ste
Re: Thunderbird-38.0.1 integrates lightning? Very disturbing!!
On 1 July 2015 at 12:14, Ian Malone wrote: > > It appears to have broken the ability to install the gdata provider, > at least when I installed a new F22 system at the weekend I found I > couldn't install it because it requires the lightning package which is > obsoleted by current thunderbird. > That's a packaging bug; either thunderbird should obsolete _and_ provide thunderbird-lightning or thunderbird-lightning-gdata should be changed to require thunderbird instead of -lightning. You should file a bug so that the issue is tracked/fixed. -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DisabledRepos and Software Center
I have question about https://fedoraproject.org/wiki/Changes/DisabledRepoSupport We (as Copr developers) are thinking about one RFE. We would like to create package which would contains .repo files and gpg keys for every Copr project. All of them with enabled=0 enabled_metadata=1 But I wonder what would be user experience? There would be no change for pure DNF users, but what about users of Software Center. What if there are multiple instances of the same application in several Copr project? What if the same application is already in Fedora? For example: Gimp. There is one in Fedora. Let assume there would be Copr project which rebuild Gimp with e.g. TIFF support disabled another project with Copression routines disabled. They can have higher or lower version. How will Software Center decide (or offer user) which version from which repository will be installed? I am especially courious about those scenarios: 1) Application is in Fedora, 3rd party repo (disabled, but metadata enabled) contains the same application with bigger NEVRA. 2) Application is not in Fedora, there are multiple 3rd party repos (disabled, but metadata enabled) which contains various version of the same Application. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Thunderbird-38.0.1 integrates lightning? Very disturbing!!
On 30 June 2015 at 16:33, Ahmad Samir wrote:
> On 30 June 2015 at 17:22, Reindl Harald wrote:
>>
>>
>> Am 30.06.2015 um 17:02 schrieb Ahmad Samir:
>>>
>>> IIUC, what's happening here is that they bundle the extension with
>>> Thunderbird 38 so it's installed and enabled by default; so when you
>>> create a new Thunderbird profile,
>>>
>>> /usr/lib*/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/
>>> will get copied to ~/.thunderbird//extensions; that also
>>> happens if you run 38.0.1 for the first time and didn't have the
>>> Lightning extension already installed (I was surprised to see the
>>> calendar pane in Thunderbird after updating to 38.0.1, since I didn't
>>> have that extension installed previously).
>>>
>>> Also (IIUC) Lightning will be updated in your profile, just like any
>>> other user-installed extension.
>>>
>>> So what you can do is just copy the dir from
>>> /usr/lib*/thunderbird/distribution/extensions and restart Thunderbird
>>> or re-install it from addons.mozilla.org, I think either would lead to
>>> the same result
>>
>>
>> but that all makes zero sense
>>
>> * i had lightning installed for many years as user extension
>> * i never used the rpm because it was always too late after TB updates
>> * now due start TB 38 it was updated
>> * it is still a user-extension in the profile
>> * if i uninstall it it's gone
>> * the files from the package still exists unused
>>
>> the point is if it is now part of the TB package it should be present after
>> uninstall the extension in the user-profile becasue the state now is no
>> improvement at all and just wasting space for no gain
>>
>
> This is an upstream change; from this blog post[1] I gather that
> upstream's intention is that Lightning is installed and enabled by
> default when you use the upstream binary tarball; the same applies for
> the distro-packaged version.
>
> - This change doesn't affect the user if he already has Lightning installed
> - With a new TB profile the user is presented with a notification
> about the extension, and he can disable/remove it
> - This is a one time "offer", so if the user uninstalls Lightning it
> won't be auto-installed again for that TB profile
>
> [1] https://blog.mozilla.org/thunderbird/2015/06/thunderbird-38-released/
>
It appears to have broken the ability to install the gdata provider,
at least when I installed a new F22 system at the weekend I found I
couldn't install it because it requires the lightning package which is
obsoleted by current thunderbird.
--
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ANNOUNCE] kexec-tools 2.0.10
On Wed, Jul 1, 2015 at 1:36 AM, Dave Young wrote: > Pratyush, > > Thanks for the effort, let's cc Fedora devel list, see if we can get help > from Fedora experts. > > Summary the problem: > Latest kexec-tools koji build in rawhide results in a wrong kexec binary, > kexec load fails with something like below: > R_X86_64_29 > Unhandled rela relocation: R_X86_64_29 > > This kinds of errors usually caused by gcc unnecesarrily add options like > -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which > runs in kernel mode. > > I filed a bug below: > https://bugzilla.redhat.com/show_bug.cgi?id=1236456 > > Appreciate for any hints how to fix the problem. I commented on the BZ > On 06/30/15 at 04:05pm, Pratyush Anand wrote: >> Hi Dave, >> >> Really not able to get whats the issue..let koji people look into.. >> >> kexec-tools-2.0.7-11.fc23.x86_64.rpm build failed >> http://koji.fedoraproject.org/koji/taskinfo?taskID=10249484 >> >> kexec-tools-2.0.9-1.fc23.x86_64.rpm does not work >> http://koji.fedoraproject.org/koji/taskinfo?taskID=10249201 >> >> kexec-tools-2.0.8-12.fc23.x86_64.rpm does not work >> http://koji.fedoraproject.org/koji/taskinfo?taskID=10249377 >> >> - so may be its not kexec-tools version issue >> >> kexec-tools-2.0.7-26.el7.x86_64.rpm work >> https://brewweb.devel.redhat.com/taskinfo?taskID=9439045 >> >> The only difference which I noticed between working brew and not >> working koji is that koji introduces >> "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" into gcc command >> line. >> >> However, I tried -fno-enforce-eh-specs >> (http://koji.fedoraproject.org/koji/taskinfo?taskID=10250889), but it >> did not work :( >> >> Only thing remaining is to try 2.0.9/8 in brew..will try that too. >> >> ~Pratyush >> > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
